Breaking Down the Identity and Access Management Capability Maturity Model, Part Two

Maturity models can be used to evaluate the effectiveness of current capabilities and set a prioritization level when an organization is ready to advance its capabilities. When applying a maturity model to Identity and Access Management (IAM), however, it’s important to examine the key tenets of an overall IAM strategy. Focusing on one area at a time allows you to identify your organization’s current status on the maturity and capability scale through a framework of smaller, digestible segments.

In part one of this series, we reviewed Levels 0-4 in each of the first four tenets of the Identity and Access Management Capability Maturity Model: Federation, Multi-Factor Authentication (MFA), Single Sign-On (SSO), and Delegated Administration. Next, we’ll discuss the remaining three tenets along with our recommended steps for how your organization can get started with increasing maturity in each.

While there is no exact order the IAM tenets need to be implemented, our recommendation is to start with Identity Lifecycle Management (ILM) because it’s a central foundational layer of IAM. Before introducing or maturing other tenets of IAM, it’s essential that identities are provisioned into your organization’s systems and resources.

With that, let’s kick off part two of this blog series with the maturity levels of ILM. 

Identity Lifecycle Management (ILM)

Debatably the most important tenet of your entire IAM strategy, ILM directly ties into all the applications or services your end users access. ILM includes the creation, update, and removal of all identities, as well as their roles and attributes, across all the applications and services used throughout the organization. As we move through the ILM Maturity Model, the goal is to automate these actions. 

• Level 0 - At Level 0, account provisioning is completely manual and completed on an ad-hoc or reactive basis. As each user account is handled independently and manually, account details are prone to human error. In addition, onboarding and the amount of time it takes to get a new employee online and productive, is often an issue.
  
  
• Level 1 - Organizations have scripts that technical employees have written over the years to at least partially automate some aspects of ILM. Scripts are typically created to solve ad-hoc requests, but are sparsely maintained and do not take a holistic approach to other systems in the organization. For example, when a new hire is onboarded, scripts can be set up to create their accounts and provide access to the various resources and applications needed for their particular role and department. Data can be taken from an HR system, typically via flat file, to automatically create and possibly update Active Directory (AD). Other departments in the organization have done similar things with other applications, but they most likely used different methods and have different levels of completeness.
  
  
• Level 2 - In Level 2 we see onboarding, the first action to implement an ILM program, typically through vendor-provided tools to manage accounts. Often referred to as provisioning, onboarding sets up new accesses. This is usually the starting point because provisioning is normally in response to users requesting access to systems to which they don’t have access. However, at this stage, there are no capabilities to easily remove the identity if a user leaves or is terminated from the organization or to make updates, such as transfers or other changes, including re-hires and re-names.
  
  
• Level 3 - This level adds an identity logic engine that centralizes all ILM functions and holistically manages the entire lifecycle processes— which is made up of numerous events— not just the onboarding aspect of an identity. For example, an identity can easily be removed if a user leaves or is terminated from the organization. In addition, the engine can make updates to identities, such as transfers or other changes, including re-hires and re-names. Furthermore, at Level 3 the audit process is simplified because it’s easy to demonstrate which users have access to which applications and resources.
  
  
• Level 4 - Level 4 adds API-driven ILM, which refers to the target or downstream system pulling the identity information, rather than the organization having to design ways to push this data to the new system. Providing a standard restful API is becoming the de-facto means for allowing integration or data synchronization between systems. While Level 4 is somewhat a future concept, there are many standards published today that indicate the industry is headed towards an API-driven direction in order to reduce the complexity of a complete ILM implementation.

Our Recommended Steps: Phase out homegrown scripts and find a vendor that supports identity events, like role and attribute changes. It’s also important the vendor can integrate with legacy applications that many organizations still have in their environments today.

Access Management

The concept of access management is ensuring proper access is granted to valid users and prohibited to invalid users by identifying, tracking, and regulating users' access to a system or application. While ILM creates and manages different users, roles, groups, and policies, access management ensures these roles are assigned proper access to resources based on these policies.

• Level 0 - At Level 0, there is fragmented access to the organization’s applications or systems, which generally means that access is granted on a manual basis. A designated person at the organization will explicitly grant or deny access to a particular resource for a particular identity.
  
  
• Level 1 - This level has two prerequisites from ILM and the next tenet we will review, governance. First, it assumes there’s an identity logic engine in place supporting full lifecycle management across the ecosystem, or Level 3 of the ILM Maturity Model previously discussed. The second prerequisite is a basic level of governance in place with an inventory of entitlements defined. Access granted to an application is known as an entitlement, and for each system you can access, there is an individual entitlement associated with it. That being said, the primary focus of Level 1 is birthright access, determined by Attribute-Based Access Controls (ABAC) and Role-Based Access Controls (RBAC). These controls identify attributes of identity to make determinations on what access the user should get. For example, these attributes can help answer questions such as: Is the identity located in a particular office? Does the identity have a particular job title or job assignment? Does the identity have a membership in a particular role? Can we apply that role as part of the access for a particular resource?
  
  
• Level 2 - In order to be at Level 2 in the Access Management Maturity Model, an organization must have a mechanism in place to handle exceptional access requests. For example, self-service capabilities can be used to make requests for exception handling and to associate identities with entitlements. At this level we can also put limits on the duration of that access with capabilities to extend or certify continued access.
  
  
• Level 3 - In Level 3, we move beyond standard access and focus on privileged access management (PAM). PAM is a subset of access management that provides additional protection for privileged accounts, or the primary accounts that are at an administrative or system level. Typically, PAM is handled by a process known as password vaulting, which is where the service account passwords continuously change until a user is granted access to use them. Another key differentiator of Level 3 is that organizations have static and dynamic role assignments to entitlements. Finally, organizations at Level 3 start to centralize access policies using an authorization engine to validate rules. The authorization engine is a collection of policies that use data provided by an IAM service, such as attributes, role memberships, entitlements, and other data that doesn’t exist within a system natively.
  
  
• Level 4 - In Level 4, the ultimate goal is to fully adopt the principle of least privileged access everywhere. That means providing users only the access they need for the minimum time they need it, and then removing that access or privilege. So, every action— request, grant, revoke— is auditable. An organization also starts to utilize Security Information and Event Management (SIEM) tools to perform event correlation to find anomalies and pass them back to the IAM system for action, such as revoking access if an anomaly is found. Finally, Level 4 builds in Artificial Intelligence (AI) to recognize those patterns and help make access management decisions. 

Our Recommended Steps: Create mappings that map entitlements to accounts or privileges in systems. Start to consider how you can build data ingestion jobs for each of these systems as well as reconciliation jobs to compare entitlements with ingested data.

Governance

Governance improves the organization’s transparency and manageability through greater visibility and control over all the identities and their accesses. Governance focuses on giving organizations the ability to view, certify, and report on identities and their entitlements to determine that IAM practices are aligned with the goals of the business policies and rules that are in place.

• Level 0 - In the previous section on access management, we discussed entitlements. At Level 0 of the Governance Maturity Model, the organization does not have an entitlement repository or central certification in place. This means business owners lack visibility and control over who has access to their business applications. Organizations at Level 0 are handling processes through email, phone calls, or helpdesk tickets at best, but business owners are not in the loop.
  
  
• Level 1 - This is where organizations implement an entitlement repository, which is capable of presenting a user’s access throughout the organization. At Level 1, organizations review granted entitlements on at least an annual basis. Furthermore, organizations in Level 1 run campaign-based entitlement certifications that establish periodic validation for how long access should be granted, as well as when access needs to be removed for exceptional handling. Reporting is a key capability here; the organization should be able to pull a report from the entitlement repository to see all of the access a particular user has throughout the organization’s systems. This also includes the paper trail that details who approved the user, if any comments were added, and if the user has been recertified.
  
  
• Level 2 - Organizations in Level 2 of the Governance Maturity Model reconcile the entitlement repository against data imported from systems. This ensures the entitlement repository matches what’s actually been provisioned by programmatically examining the accesses in the applications themselves. For example, if the organization can reconcile and enable AD user account entitlement to an active user account in AD, then they have passed. On the other hand, if an entitlement is granted and the user does not exist or is inactive, then it’s a fail. An even worse fail is if there’s no entitlement, yet there’s an active AD account, also known as an orphaned AD account. Organizations in Level 2 also add the ability to perform time-based certifications, also known as continuous or rolling access certifications. This type of certification is based on the time period when the entitlement was actually granted and is more granular than campaign-based certifications because certifications can be staggered. Time-based certifications are also advantageous for companies because applications don’t all have to be reviewed during the same timeframe.
  
  
• Level 3 - At this stage, the organization can reconcile between the application and the entitlement repository in real time. This is highly recommended for high risk resources where access is provided to sensitive information, for example, reconciling AD against memberships changed in the domain administrator group. However, organizations should not move away from scheduled full reconciliations, such as to reconcile AD group information to the entitlement repository. For real-time reconciliation, the governance system needs to be able to monitor the resources for change, as they change. Then, the governance system can automatically reconcile that change to the entitlement repository. When drift is detected, the system can automatically take action and even remediate, if possible. Another characteristic of Level 3 is organizations have mapped entitlements to specific privileges. By mapping entitlements, the IGA tool is provided context to help make a decision on whether access should be granted. This process saves time by limiting human intervention to only when there’s a flag in the system.
  
  
• Level 4 - Level 4 adds analytics and AI into the mix to help ease the burden of the overwhelming amount of approval and certification requests. With good historical data and proper training, AI can use patterns and trends to determine, within an acceptable probability, that an entitlement request or recertification can be automatically approved or denied. The goal is for the AI model to become so well-trained that it can handle the majority of access decisions and only anomalies are left for human intervention when a threshold is not met.

Our Recommended Steps: Create mappings for entitlements with an interface that provides real-time query rules. In addition, implement continuous model training to lay the groundwork for AI. It may take several months or a year to get a solid model in place, but once completed, the upkeep can be automated.

Reveal Your Organization’s IAM Maturity with the Identity & Access Management Maturity Assessment

Now that we completed our overview of the Identity and Access Management Capability Maturity Model, the next step is to evaluate where your organization stands in each tenet.

As a reminder, it may not always be necessary to be at Level 4 for each tenet. Rather, it’s an organizational decision as to the appropriate level to achieve for your needs.

So, where do you begin to put this into practice?

Check out our IAM Maturity Model Assessment Tool to easily self-assess your level of maturity in each of the seven IAM tenets. This tool enables you to quickly evaluate areas of focus and determine a plan to approach in each IAM tenet. As you improve each of those tenets, you’re improving your overall maturity index.

Upon completion, you will receive an overall IAM maturity score, a maturity score within each of the seven tenets, actionable steps and insights for increasing your maturity levels, along with additional resources.

Access the Identity & Access Management Maturity Assessment Tool here.