Hygiene in identity and access management

As all complex systems need to maintain a certain level of sustainability, transparency and cleanliness, we at IAM care about these buzzwords quite a lot. Furthermore, we try to bring them to practice as well. Why is this theme so important to us? What do you mean by system hygiene? I’ll try to explain in this article. I’ve written about IAM, IDM and IGA in the last article in case you’d need to refresh memory on what field of security I’m talking about.

Let’s look at some examples of how poor IAM hygiene can become one of our worst nightmares and how can we mitigate the problems which arise.

Invalid or out-of-date data amongst all managed systems

When onboarding of a new user goes on, there is typically some department responsible for it or users are provided with a self-service portal to fill basic information (like name, surname, organizational unit, mobile number for verification, etc.). This can be considered semi-automated, because there is always some kind of approval flow present. However, if the user or a responsible person makes a mistake during this initial stage, it mirrors to all systems where IDM is considered source of truth.

Invalid data is reflected in all connected systems.

Orphan accounts

Another common problem in IAM industry. The term is used for accounts of former employees which are still active. Mostly, this problem is a combination of one or more of these examples:

• More sources of user onboarding
• Not strong governance policy in place deciding when an account is inactive
• No automation of system, utility and validity checks
• No clear responsible person (typically user’s manager or part of security department)
• Indistinguishable management of internal, external or other subtypes of accounts
• Too many ways for offboarding (causes overchoice)
• Unfinished IDM project quality control requirements

Strong governance policies and precise quality control provide solid basics for quality IAM.

Permission creep problem

Just like Gollum from Lord of the Rings movies and books is creepy over its precious, there are similar beings in IAM world, too. Permission creep describes a user, who accumulated too many privileges over time way beyond his/hers working needs and holds onto them. This state often happens when a longer-term employee switches positions or responsibilities within a company and is granted new privileges. An example of abuse would be an employee with excess access who is tempted for inappropriate use. Secondly, if an attacker gains this kind of account, he also gains these privileges.

2019 Survey by Centrify revealed 74% breaches involved access to a privileged account.

Overwhelming maintenance

Almost everyone has experienced repetition of work tasks. Personally, I try to use the rule of “3 repetitions over a week” must be automated next time (similarity to Baseball Strikeout purely coincidental). Of course, some tasks cannot be automated due to a lack of time (and knowledge) or the time spent simply isn’t worth it. In IAM, when speaking about overwhelming maintenance, we mostly think about non-automated repetitive tasks. These can consist of following:

• Bulk changing attributes of an object
• Bulk role (or privilege) provisioning/deprovisioning
• Computation of object property depending on other properties
• Checking objects validity, overall state and up-to-date data
• Watching for changes in connected systems
• Too many password reset requests
• Various reports about the state of the system or handled objects

What are the best practices for overcoming these issues?

Of course, we can technically tackle all of these issues with more or less known techniques. I’ll try to describe them one by one.

Mappings

Core of every modern IDM solution. Active mappings along with templating allow us to almost instantly reflect property changes in particular objects. We can even stack these, causing a chain reaction of changes. Example of the easiest mapping could be: Fullname = GivenName + FamilyName, where GivenName is the name given by parents and FamilyName is the name you inherit. Why FamilyName and not LastName? Well, because of places all over the world where surnames are inherited across generations.

In real systems, however, mappings can get quite complex. Often, we also use scripts inside mappings for further processing. We should be able to select the ordering in which mappings are evaluated. Let’s describe a little more complex situation: we have a newly onboarded user Jean, and we’re setting up his privileges and additional properties based on what was fulfilled in registration. The first mapping we have selected to be processed is to map user’s property fullName. Second is employeeType property. We have internal and external employeeType types, which are evaluated from emailAddress and contractType registration properties. Then we can map to general organizational structure, which is divided between InternalOrg and ExternalOrg. Mapping to division organizational structure is based on organizationalUnit. Other mappings seem pretty self-explanatory.

We can see how have mappings modified user properties and assignments (entitlements). If we evaluate mappings everytime object changes, we can be sure we have the right set of privileges at any given time.

Pros: can fully resolve the inconsistent data problem

Cons: can become quite complex when stacking

Object lifecycle

Can be used to determine in which validity state the object is. It depends on implementation, but most widely used are simple Turing machines with following states:

• Draft (definition of new object in progress)
• Active (classic active object)
• Inactive (disabled object)
• Archived (disabled object stripped from most attributes, only used for audit reasons)

An example would be: Imagine a newcomer in a company being onboarded on 15h of February. Until that time, his assigned user account is only a Draft. When the time comes, he’ll be in Active state gaining privileges and working. When he leaves the company, he gets into Inactive or Archived state and after some time he can be deleted (some systems do not delete this object for audit reasons or for simply not assigning the same UID to another new user). Of course, he can be rehired again, and then he would gain Active state.

Pros: tackles the Orphan Accounts problem, automates the maintenance of lifecycle

Cons: adds complexity into system

Roles

A Role is traditionally most used and powerful object type in whole IAM. It can represent set of authorizations, mappings, templates resulting in changes in object lifecycles, even other roles (so called meta roles) and much more. With the right skill set, we can achieve just about anything. Examples of role usage are:

• Assignment role - ensures user (or other object) membership in the role and in the resulting entitlement in a connected system
• Mapping role - override default mapping rules
• Lifecycle role - override object lifecycle based on properties or evaluating functions
• Meta role - include other roles with their own rules, form hierarchy
• Birthright role - is normally a combination of mentioned above causing newly onboarded user automatic assignment of basic entitlements
• System role - holds set of authorizations needed by system users

In summary, these types of roles can be combined in any matter, revealing the true power of this concept. Beware not to get too numerous with roles. There are many types of access controls, one of them is RBAC (Role Based Access Control), which can cause Role explosion problem. The most famous examples of access controls (AC) could include:

• ABAC - attribute based AC
• PBAC - policy based AC
• GBAC - graph based AC
• OrBAC - organizational based AC
• RSBAC - rule set based AC

From the types of access controls I have mentioned, the most influental one in the last years is definitely PBAC. I’ll write more on these in the next article.

Pros: vital part of any IDM system, wide variety of usage, can be part of automation

Cons: can cause Role explosion and maintenance issues when used inappropriately

Policies

Policies are basically set of rules that define what to do if a certain situation comes up. They can implement the governance, compliance and privacy side of IAM. Most used policy concepts are Segregation of Duties (SoD) and Principe of least privilege (PoLP). There are a lot more policies used in real IAM deployments like password policy (for reset, update and generation), approval policies, organizational-based policies, role-based policies, etc.

Segregation of Duties

When this policy is applied, it prevents an individual from gaining too much access. As the name suggests, this mechanism prevents assigning (often defined Roles) privileges out of scope of work duty.

Of course, it’s much more difficult in real life. Typically, SoD matrix is tens or even hundreds of lines wide in both dimensions. SoD is a concept widely used across organizational departments, mainly Risk & Compliance to identify risk levels. Many examples can be found on the internet. This one for Judiciary is excellent in particular.

In IDM we use it for situations, where it is unacceptable to have conflicting Roles assigned at once. In the next example, imagine 4 roles for an application access. In this extended Boolean SoD Matrix, X means not applicable, 1 means allowed and 0 means duty conflict. We see that we can have R1 and R2 assigned at the same time, but not R1 and R3 or R3 and R4. In fact, R4 is in conflict with all other Roles. A rescue from this policy situation is forcing pruning conflicting roles when assigning one in conflict.

Pros: can be used to mitigate Permission creep problem, also reduces maintenance

Cons: becomes too complex in large environments

Principle of least privilege

This policy states that objects we manage trough IDM only access information and resources necessary. Imagine a set of pre-defined Roles of Developer, Technical lead and Project Manager. Naturally, Developer doesn’t need the same level of access as Project Manager or Technical Lead and vice versa. To reflect these policies, we can define an access matrix.

In the following example, we can see defining access level to a resource in a project. Number 1 means access allowed while 0 means access denied. Coming from the nature of their contract with the company and work duties, all roles can read. Only Technical Lead can execute write/delete changes (forcing usage of peer review), even if they are proposed by the Developer or Project Manager.

Pros: helps with unauthorized access problems

Cons: no cons

Access Certification

Mechanism used for periodically reviewing user’s accesses by a responsible person. It’s also often a vital part of better IDM software.

For example, we have chosen each user’s line manager as a responsible person. When the time comes (typically 3, 6 or 12 months) for an access certification review, he has to go through all of his subordinates selected accesses. Accesses to be reviewed should be selected with care, because when you present a reviewer to look at 1000 lines of access, he won’t do it properly. That situation can escalate quickly to overseeing the Permission Creep problem. Just imagine having 30 users with 20 Roles assigned each, which is, to be fair, normal. Now that counts up to 20x30=600 items to review. Even if you give the reviewer 2 weeks to get this work done, it’s just seems like an unnecessary burden. If you select only 2 roles that are risky and need a periodic review, it will reflect in only 60 items. Then it’s possible to be done over a coffee break.

Pros: can eliminate Permission Creep problem completely

Cons: is often underestimated due to possible high time consumption by responsible people who do not properly understand access risks

Automation

Automation is one of our greatest allies when it comes to managing identities. It’s applied all over the place. Its main pillar are automated tasks. Let’s look at some big players amongst them.

Reconciliation

Reconciliation is the task of the tasks for any IDM system. It can eliminate suspicious records in connected resources (doesn’t matter if it’s LDAP, AD, DB, CSV, UNIX, REST, etc.), sync and verify data integrity. It’s main function is to validate if all identities privileges match with what they have in the target resources.

Pros: can be used for synchronization between connected resources

Cons: can have high computing resource consumption when we manage hundreds of thousands of identities

Recomputation

Recomputation is not an industry standard, but in my opinion, it should be. It’s an automated task that forces to recompute all applied mappings, templates, policies and rules on a selected subset of objects. We use it with reconciliation to ensure strong data integrity amongst all connected systems.

Pros: when used with reconciliation, ensures high data integrity

Cons: the same as reconciliation

Utility, System and Validity tasks

These subtasks are used for sustaining a high general hygiene in the system. Utility and system tasks like cleaning of old audit records, cleaning up no longer used object properties, etc.

Validity tasks for triggering policy enforcement for sets of privileges or when object lifecycle changes, or even trigger the change in object lifecycle.

Pros: keep the system clean

Cons: can consume computing resources fast

LiveSync

This special type of task is mainly used for onboarding of new identities into IDM. It behaves just like a monitoring system for resources data. If something changes in the resources, we’re able to detect it within 5 seconds.

Pros: changes in resources are mirrored almost instantly, usually very lightweight

Cons: none

Scripts

It often happens that system doesn’t provide all the needed hygiene tasks bundled with the software or engine we use for IAM. That’s the time for manual scripting! When the scripts become part of your daily routine, it’s time to convert them into automated tasks.

Summary

Today, I wrote about how to keep our IAM solution clean and shiny. As we are trying to manage identities and often other objects as well, it is naturally an ever-changing environment. We looked at some issues we struggle with every day and how it is possible to overcome them. I showed pros and cons of almost every of these proposed solutions. In reality, they all work together and form a complex ecosystem.