Introduction

1. Identity & role repository

• ​The number of users (per department or organizational unit, per manager, …)
• The number of newly created users
• The number of disabled users
• The number of (organizational, container, IT, business, technical, …) roles
• The number of entitlements
• The number of applications integrated in the current IAM system
• The number of roles relative to the number of departments
• The number of IT roles relative to the number of business roles. This can, of course, be done for any type of roles of interest.
• The number of entitlements relative to the number of users
• The number of entitlements relative to the number of roles

2. Orphaned accounts

• Users that have not logged in for quite some time. Accounts that have not been used for a certain period of time are also known as dormant accounts. What that time period should be exactly can differ between organizations. Nevertheless, 90 days is often considered the limit.

  • For certain accounts, such as admin accounts, one might prefer a shorter time period compared to other accounts. Hence, this KPI can be split into several sub-KPIs.
• Users that have never logged in.
• Uncorrelated user accounts, also known as ghost accounts. These are accounts that are not linked to an active user or not linked to a user at all.
• User accounts with a status indicating inactivity. What this status is exactly depends upon the IAM system that is used in the organization. Think for example about an employment status ‘retired’ or an activity status ‘inactive’. The clue is to look at the user characteristics in the IAM system that could indicate inactivity of a user.

3. Privileged accounts

Privileged accounts, generally defined as accounts that have significantly more access rights than ordinary accounts, exist in many forms and shapes. However, when not properly managed and monitored, privileged accounts pose significant security risks. These risks could come from all sides: malicious ‘outsiders’ (such as hackers), or careless or disgruntled ‘insiders’. Whoever gains access to these privileged accounts can control organization resources, access sensitive data, or even change or disable (security) systems.

It’s important to know how many and what kind of privileged accounts exist in the organization. Note, however, that some of the below mentioned types of privileged accounts can overlap. To start off, think about the following kinds of privileged accounts:

• Administrator accounts, think about Local Admin and Domain Admin.
• Stealthy accounts. These accounts are granted administrative privileges on one or more systems but often exist below the radar as they are not labeled ‘Admin’.
• Privileged service accounts such as Domain Service accounts.
• Non-personal accounts (NPA). These accounts are not directly related to a uniquely identifiable person/employee, nor are they the result of the 'joiner – mover - leaver' HR processes in an organization. Such accounts are often quite powerful (e.g. admin or root account) but difficult to detect. On top of that, login with the account doesn’t leave an audit trace showing which person has actually used it. In other words, there is not a specific person that can be held accountable.
• Privileged data user accounts. Even though these users are not typical privileged accounts, they should be considered privileged anyway, because of the sensitive data they can access. Think about the accountant who has access to financial data of his customers, an HR employee with access to sensitive employee data or a doctor who has access to patient information.
• Privileged role-based accounts. Depending on the role model, certain roles can be considered privileged. Therefore, we should consider users assigned to one or more of these roles as privileged accounts.

4. Users with excessive access rights

The difference with privileged accounts and users with excessive access rights is that the former focuses on users who should have (many) sensitive access rights by definition while the latter focuses on users who accidentally have (too) many access rights.

​One of the most important principles in information security is the principle of least privilege (PoLP). This principle is the practice of limiting access rights for users to the bare minimum they need to perform their intended work. It is a common misconception to only think about malicious employees when considering using the least privilege principle. The thing is that employees can also accidentally leak data due to phishing, a lost laptop, etc. But whether it's on purpose or not, the less data your employees can leak, the better.

It’s a fact that the cumulated access rights and permissions of all your users together determine the attack surface size of your organization, which of course should be kept as small as possible. Unfortunately, there’s often a gap between granted access rights and used access rights. This indicates that users have too many access rights, unnecessarily enlarging your attack surface

• Outliers. These can be defined as users that have more access rights (i.e. are assigned more roles or have more privileges) than their peers. Often this is the result of employees changing departments or functions without the former - and now unnecessary - access rights were deprovisioned.
  • Another way of finding outliers is by comparing them to an ideal role-profile. Depending on the job function a certain employee has, a certain set of roles might be appropriate. This, however, is only applicable to organizations working with such role-profiles.
• Users assigned with a high number of roles or permissions. What is considered as ‘high’ depends on the role model and organizational context.

5. Separation of Duties (SoD)

Separation of duties, also known as segregation of duties, is considered as one of the most difficult and often costly identity controls to implement properly. The objective is to disseminate the tasks and associated permissions among multiple people. That way it is much more difficult to commit fraud since at least two people must work together to do so. However, the objective is no longer limited to fraud prevention, but also includes security and privacy. If properly designed and implemented correctly SoD ensures that employees don’t have conflicting responsibilities or interests. For example, you don’t want the person defining a policy to have the ability to approve its execution.

Apart from the SoD controls itself, the metrics to see how you are doing:

• ​SoD violations. Besides the total number of SoD violations, it can also be interesting to look at the number of specific SoD violations to identify those toxic combinations that seem the hardest to resist. For these violations, a tactical clean-up will probably not do the trick. A strategic redesign (see info on the right), however, might improve the situation.
• Undecided access rights combinations. These are the combinations of roles, entitlements or applications for which it’s not clear whether they are considered ‘toxic’ or not. If such a combination occurs in practice, it’s important to know whether it’s allowed or not in order to take appropriate action (if required).

6. Identity hygiene

It is important to realize that identity hygiene (i.e. proper maintenance of the repository) and information security are strongly interconnected: a well-maintained IT environment is better protected against information security risks. Applying good practice to users, roles and entitlements not only helps to prevent risks, but it’s also a lot easier and needs considerably less effort compared with a situation where you periodically have to clean up the mess. In other words: prevention is better than cure.​

Some metrics to measure how well you’re doing regarding user hygiene:

• ​Users that have no roles or entitlements assigned.
• Users that have no access to any applications.
• User accounts that have not been changed for a certain period of time. What that time period should be exactly can differ between organizations.
• User accounts with direct entitlements, not assigned through roles.
• Users accounts for testing purposes (i.e. test accounts).
• Users (and more specifically their access rights) that are not reviewed in a certain period of time. Again, what that time period should be exactly can differ between organizations and often depends on the frequency of (re)certification campaigns.
• This KPI can also be set up for specific types of accounts, such as admin accounts.
• In case the organization enforces a password expiration policy: user accounts with expired passwords.

Some metrics to measure role hygiene. Note that these KPIs can be split into sub-KPIs for specific types of roles such as IT or business roles:

• ​Roles that do not consist of other roles or entitlements, also known as empty roles.
• Roles that are not assigned to any user, also known as unassigned roles.
• Roles that are (not) reviewed in a certain period of time. Again, the exact time period depends on the frequency of (re)certification of roles in the organization.
• Roles with an additional approver.

Some metrics to measure entitlement hygiene:

• ​Entitlements that are (not) assigned via a role.
• Entitlements that are not assigned to any user.
• Entitlements with an additional approver.

There are many KPIs that help to measure this. Think about all the different data attributes in the IAM system that could be left blank. However, it’s important to focus effort on those attributes that are crucial for other KPIs or to take action to improve identified issues. Remember that more in-depth information and action-oriented insights are required to actually improve identified issues. Without the right information, it’s almost impossible to decide whether a certain user account or role can be disabled/revoked or not.

Some metrics that are essential for the majority of organizations:

• Users without a manager, department, or email.
• Roles without a (proper and clear) description or owner.
• Entitlements without a (proper and clear) description and owner.
• Applications without a (proper and clear) description and owner.