IGA Capability: Access Certification
Alternative names
-
Re-certification
-
Attestation
Access Certification Functions
-
Full certification campaign. Certification done on large scale. Certifying access of a large group of users, typically distributed among many certifiers. Campaigns are usually executed periodically, they have a limited time duration.
-
Microcertification. Certification done on a very small scale. Typically certifying access of a single user, done by one or just a couple of certifiers. Microcertifications are usually triggered by identity lifecycle events (such as organizational change) or changes in risk landscape.
-
Certification of role definitions. Certification of the components of a role, such as included roles, entitlements and so on.
Overview
Access privileges have a tendency to grow and accumulate. There are many ways to efficiently grant a privilege: formal access request processes, privileges are granted manually by system administrators and various informal side channels. However, privilege accumulation is a risk, as people often keep their privileges forever. Access certification is a process to remove privileges that are no longer necessary. During access certification process, responsible persons must certify that users still need the privileges that were granted to them.
Certification is a process designed to counter-act ad-hoc assignment of roles. Whether the roles were assigned by a formal access request process, or they were assigned manually by an uncontrolled process, they all need to be certified eventually. Otherwise, the number of roles assignments will grow out of control, and with the number of role assignments the overall risk grows too. Certification is perhaps the only practical mechanism that can limit the risk posed by ad-hoc role assignments.
However, there are typically many ad-hoc role assignments in a typical organization, and especially in a dynamic enterprise environment where the situation changes frequently. Therefore, certification processes must be designed to handle a large number of decisions very efficiently. Simply re-running the approval processes will not work. There would be too many approvals to make, too many clicks in too many dialogs. Therefore, certification user interfaces are designed specifically for the purpose of making a lot of decisions very quickly, usually in one user interface dialog.
Certification decisions are almost always made by (business) managers, usually by direct manager of the user whose access is certified. Direct manager usually has the best overview of the job that a user does, which also means there is a good chance that the manager can spot roles that the user no longer needs. This approach has an additional effect of distributing the certification effort among many certifiers, thus reducing the overall time needed to complete the certification.
There are usually two types of certification:
-
Certification campaigns aim at certification of all the roles (other other "access") that a large group of users have. This is a "mass" action, with many decisions that need to be made by many certifiers in a relatively short time interval. The users are divided to groups, usually according to organizational structure. Certification work is distributed to many certifiers, usually managers of organizational units. The campaign has a fixed duration, usually in order of weeks. Campaigns are usually repeated based on a regular schedule (e.g. annually).
-
Microcertifications, also known as triggered certification or ad-hoc certification. This is usually certification of role assignments of access granted to a single user, done by a single certifier. Microcertification is often triggered by significant events in the identity lifecycle, such as change of organizational assignment of the user. In that case the new manager of the user has to certify user’s role assignments, as the new manager assumes some form of responsibility for user’s actions. Microcertifications can also be triggered by other events, such as overall risk of user’s entitlements growing above a specified threshold, detection of a user as an outlier, or even a completely random selection aimed at mapping the state of role assignments.
Certification campaigns are systematic, broad-scale solution that has a good potential to address privilege accumulation problem. However, it is quite difficult to use certification campaigns well. Certification campaigns require many decisions to be many by many people, resulting in huge overall effort. Common recommendations in the past were to conduct full certification campaign annually, or even twice a year. However, the more frequent the campaigns are, the less likely it is to detect excessive role assignments. If certification campaigns are considered "boring necessary paperwork", the certifiers are likely to certify everything without too much thinking, just to get it done. Therefore, frequent large certification campaigns can produce completely useless results.
Current certification recommendations favor smart use of microcertifications instead of frequent certification campaigns. Microcertifications of a single user should be triggered by important lifecycle events, such as change of organizational assignment. Even more importantly, certifications should be risk-based, triggering microcertification or small certification camp of users that pose higher risk, or users that have unusual combination of access rights (a.k.a. outliers). Smart use of smaller certifications does not eliminate the need for full certification campaigns. However, it allows to dramatically reduce the frequency of these costly and painful campaigns.
Role structure significantly influences certification effort. Good role engineering results in well-specified business roles, with high degree of re-use. This means that a typical user will have just a couple of business roles, that are relatively easy to certify. On the other hand, poor role engineering means that large number of application roles is assigned directly to users. This means that a typical users will have tens, or even hundreds of roles. The result is a huge certification effort, and a very low quality of certification result. Such situation often results in cases where access request process is over-used, where business role engineering and maintenance is neglected and the users often request the same set of roles as their colleagues. Such approach inevitable leads to an unmaintainable, and hence insecure system.
Despite good role engineering and smart use of microcertifications, certification is always time-consuming and somehow painful activity, with questionable results, that are very difficult to quality-control. Similarly to access request process, certification is necessary component of almost every comprehensive IGA deployment. However, it is more than desirable to keep both of these to a necessary minimum. The more roles, entitlements and privileges are assigned (and hence unassigned) automatically, the less need for access request and certification effort. There is also less room for errors, much more visibility and hence less residual risk. Therefore, the primary goal of IGA deployment should be as much automation of role assignments as practically possible.
Most access certification activities are concerned with certification of user-role assignments. However, certification mechanisms can be used to certify other parts of the policy, such as role definitions.
The ultimate goal of access certification is to keep user access to assets as slim as possible. Access certification is a mechanism to bring the system closer to an ideal state dictated by the principle of least privilege. There are many mechanisms in IGA system that tend to make user access broader. Access certification is one of a very few tools that work in the opposite direction, making user access thinner. That makes access certification a precious tool in the IGA toolbox. Access certification is a must-have tool, especially in case that access request (or similar) process is used. Despite being an essential tool, access certification is relatively difficult to use. If not used well, it can produce huge amount of wasted effort, leading to no tangible result at all. Similarly to many other IGA tools, it must be used wisely.
Notes
Access certification is almost always used in role-based systems, such as systems based on role-based access control (RBAC) principles. The roles are natural concepts to be used by both access request and access certification mechanisms. In theory, access certification can be used also in systems that are not based on roles, such as attribute-based access control (ABAC) systems. However, as such systems usually do not have a formal concept of what "access" means, it is much more difficult to define and manage access certification campaigns. Access certification in ABAC system usually means certification of user attribute values. While such approach is possible, it is usually quite labor-intensive, and it is seldom feasible.
Recent trend is to use machine learning (presented as "artificial intelligence", AI) to reduce the certification effort. While machine learning can reduce the certification effort, great care must be taken to maintain the quality of the result. Certification is designed as a manual process for good reasons. The certification decisions have to be made by humans, to counter-act other human decisions that might have put the system at risk. The problem with machine learning is that the results are only as good as the data that were used to train the system. As every organization is different, the roles, policies and practices tend to be different as well. Therefore pre-made training data from other systems cannot be used to train the machine, only data produced by your organization can be used for that purpose. If decisions of your certifiers are not good (e.g. almost always certifying everything), then the AI will be doing equally bad decisions. This could lead to a problem that is difficult to see, hidden from the eyes for years and years. This can be extremely dangerous, as access certification is often the only mechanism protecting against dangerous accumulation of privileges.
Rather than relaying on AI for automation of access request and access certification, the effort should be directed to a proper role and entitlement engineering. Better roles and entitlements, together with rules for their automated assignment/unassignment can dramatically reduce both the access request and access certification process, increasing transparency at the same time. Machine learning should better be employed to improve role engineering, such as use of role mining to suggest good role definitions.
Relevant MidPoint Features
Following midPoint features are relevant to this IGA capability:
| IGA Function | MidPoint Features |
|---|---|
Full certification campaign |
|
Microcertification |
Micro-certification |
Certification of role definitions |