Attestation and (re)certification – five things you need to know
1 What’s the problem?
Organizations typically have many systems and applications with data to which users need access. When people want access they shout about it until they get it. However, it is rare for someone to make a fuss about having access they don’t need. Most organizations do not have a process for controlling permissions that is formal and complete (like Roles Based Access Control – RBAC) which means that they are reliant on the diligence of their IT administrators, and also reliant on them not making mistakes. The result is that many users have permissions they should not have.
2 The terminology
Permissions are usually expressed in terms of a membership of some kind of group, or an attribute against their account. Attestation and certification (in the sense we are using these terms) are the same thing – the action of checking that people do have the correct permissions (and if necessary revoking them).
It usually takes the form of a campaign done in one go, which remains authoritative for a period of time (perhaps 6 months). After that there is a new campaign – and so on. It is cyclical, and so the term recertification is also used.
The people that will affirm or revoke permissions – the stewards – are usually the managers who are responsible for the systems and applications concerned, and therefore understand them, and why anyone should be allowed access, and what type of access (or not).
3 It is a vital aspect of permission management
The way organizations manage permissions range from totally ad-hoc, to a formal and automated roles-based access control approach (RBAC).
Most of us are somewhere in between:
- Most organizations would like to move that needle to the right, so that they have a formal means of assigning the correct permissions to the right people, when they need it.
- Many organizations are realizing the potential negative consequences of not doing so.
- Some have suffered damage as a result – sometimes very publicly. At best they lose credibility and reputation; at worst it hits the bottom line. Hard.
Wherever you sit on this scale a regular pattern of attestation/certification campaigns will be of benefit. It could be the only tool you use, or it could be a vital check that your formalized system is doing its job properly.
4 So what is a campaign? what does it look like?
A campaign can be entirely manual, but there are huge benefits in an automated, workflow based approach:
- The existing users and permissions are pulled directly from systems concerned – the campaign works with real up to date data.
- The administrator of the campaign can track the campaign, seeing who has done what, and taking appropriate action to ensure completion.
- Familiar tools are used (like browsers and email), which reduces friction.
- If a permission is revoked, this can be immediately applied.
5 On-premises or cloud
Either, or both! This all applies to on-premises and cloud users and permissions. The migration to cloud offers an opportunity to ‘clean things up’, but in the rush to get into the cloud many organizations are simply replicating the same state of affairs in the cloud. Co-existence, or ‘hybrid’ (users and groups in Active Directory and Azure Active Directory) is more or less normal – so preferably you need an attestation/certification tool that will work for both (and synchronization may be your friend here – get it right on-premises and sync to the cloud).
It is just too big to start!
No it isn’t!
It is true that many organizations have looked at RBAC, and inertia has got in the way – but attestation/certification isn’t like that. You can start small with high value, high risk areas. As you see the benefits you may be able to move down the risk ladder – but you will be doing good as soon as you start.
In any case, implementation does not have to be difficult.