Role-based Identity Management Best Practices

This is a white paper that I put together a few years ago for a large financial organization that was struggling with how to approach RBAC or role-based identity management without having the new AI and machine learning capabilities with some of the new IGA solutions such as SailPoint IdentityAI.

Introduction

Role-Based Identity Management and Role-Based Access Control (RBAC) has long been the nirvana of Identity & Access Management programs since the concept of distributed systems was introduced. The idea of aligning access needs to the business functions that users fulfill and streamline provisioning of that access has proved to be a constant challenge in terms of both IT operational efficiency as well as Compliance, Risk and Security needs. This paper aims to address the challenges for effectively managing role-based access and identify best practices to help organizations achieve better IT efficiency, reduce risk and increase security for their users, data and applications.

Role-based Identity Management Overview

What are Roles and Why Do We Need Them?

Users that have been granted access to an enterprise environment require certain access to be productive which may vary from person to person, department to department and between user types (Employee, Contractor, Vendor, etc.). The larger the enterprise the greater and more varied the access requirements. Organizations that rely on assigning users access to applications on an ad-hoc basis require a large amount of the organization's resources for submitting, approving access requests, manually provisioning the access when automation is not available as well as reviewing and re-certifying the access is still appropriate on a regular basis. The goal of implementing role-based identity management is to streamline these processes.

In terms of Identity and Access Management (IAM), a role is simply a grouping of applications (accounts) and access (groups, entitlements, permissions, etc.) that can be requested or automatically assigned to the user based on information about the user such as their department, title, location or other demographic information that is typically synchronized from an authoritative source such as an Human Resources Information System (HRIS) or third-party user management system. The idea behind role-based identity management is to abstract the technical access that the user needs to perform a job function or business process, in essence translating between the technical details of the permissions the user needs within an application, system or platform to perform a specific job function.

Role-based Identity Management Complexity

While roles streamline the process of managing users’ access, properly implementing and managing them requires special consideration to ensure that roles do not cause larger problems. Roles like users have a lifecycle that has to be considered to properly manage. Organizations grow and change over time, for example through mergers and acquisitions, that bring in new users, departments and applications. Companies expand into new regions and markets creating new offerings, products and services that bring in new applications or expand existing systems in order to manage. Additionally, applications and systems are upgraded, expanded and replaced over time. All of these factors require roles to be regularly reviewed and monitored in order to ensure that they have the right access and that they are not introducing issues such as hiding improper access or access combinations that would violate a separation-of-duty (SoD) policy. 

Role Implementation Strategies

Role Design vs Role Discovery

The two main practices for implementing roles are to either perform top-down design or bottom-up discovery. Designing roles from the top-down requires working with the various business areas in your organization to determine how to group users and what access each group needs in order to perform their job. In addition to working with each business area, application owners as well as security, risk and compliance departments should be included in this process to ensure that concerns such as SoD and other security policies are considered when designing and implementing roles. This approach requires a significant investment in time and resources.

Role mining tools provide an alternative to top-down role design by providing analytics which can identify common access patterns among a group of users and how to optimally group that access. Role mining tools typically produce a heat map that identify access patterns and allows the user running the session to alter the factors that determine the optimal set of roles to be created. In addition, some role mining tools also allow the administrator to perform role modeling to determine the impact of adding additional applications and entitlement into candidate roles.

 

Role Mining Session

Role mining streamlines the process of performing the analysis needed to design roles but may miss important factors that would be flushed out by a top-down design-based approach. For example, role mining solutions are typically integrated into an identity management/governance solution that integrates HR and application data to produce a single “pane of glass” of the current state of users and what each user has access to. Role mining tools do not give visibility into the specific business functions that a department or business area is responsible for and the nuances within a department that may require similar users to have different access.

In addition, role mining solutions are only as good as the data that is fed in to perform the analysis. Users tend to acquire and retain access as they move about the organization. In addition, many companies implement the practice of cloning existing user’s access (“like Mike” provisioning) when on-boarding new users, resulting in users joining the organization having access to applications and data that they do not need. Unless organizations are enforcing least privilege when onboarding new users as well as implementing effective access reviews across all applications, performing role-mining may result in “bloated” roles which contain more access than the recipient of role needs for the job function(s) they are performing.

Role mining tools have many of the same concerns as described for role modeling above. For example, without integrated separation-of-duty detection and enforcement role mining tools may include toxic combinations of access which would violate the organization’s SoD policies, increasing the risk of fraud or a breach.

Most role mining solutions are only effective at analyzing small populations of users. This requires the administrator running the tool to configure how to segment users, for example by HR department and title, which may not be optimal. For this and the reasons above, an optimal role design process must incorporate both bottom-up role discovery and top-down role design in order to be effective, which requires coordination and planning across the organization in order to ensure success. 

Role Ownership

Before settling on a role alignment strategy, it is important to understand how roles will be managed after the initial creation. This is important because roles, like users, have a lifecycle that has to be maintained over time. For example, once a role is initially implemented, it may require tuning to increase its effectiveness and reduce the additional access requests. In addition, as mentioned above, roles should be reviewed on a regular basis. This requires a role owner to be identified who will be responsible for ensuring that the applications and access included in the role are correct and that access that is no longer needed is removed.

Many organizations implement a central role management group which is responsible for ensuring that roles are properly maintained over time. This should augment role ownership but not replace it as a centralized role management team may not have visibility into each business area to understand how roles should be composed. Ideally role owners should be designated within the business area that the roles serve in order to be effective.

Aligning Roles to Users

Single Role vs Role Hierarchy

When designing a role implementation strategy, one important consideration is whether users can have multiple roles, or a single role assigned which provisions the majority of the users’ access.

The advantage to the single role-to-user approach is that it ensures users do not receive toxic combinations of access which violate a separation-of-duty policy, assuming the role itself doesn’t contain SoD violations. For this reason, many financial institutions have implemented this strategy. The disadvantage to this approach is that it results in a sub-optimal role design as it requires a role to be implemented for situations such as a user which fulfills multiple job functions in a department, or requires additional access to be requested and provisioned outside of their primary job/role. Also, this strategy requires a considerable amount of role maintenance, for example to apply common access across a large number of roles. For example, if an organization adopting this strategy roles out a new company wide training application, each role would need to be updated with the access.

An optimal role strategy should involve implementing a hierarchy of roles which start with course-grained access which applies to a large population of users and goes down to fine-grained access applied to a small population of users. Implementing this requires that the organization has SoD policies defined and has the ability to detect and enforce SoD violations, especially through automated role assignments.

Title-Based Role Assignment

A popular strategy to automatically assigning roles is to create a single role per title. This assumes that titles are governed effectively and have meaningful values in the organization’s HR Information System. If titles are treated as free form text this strategy cannot be effective. In addition, if titles are not granular to a distinct population of users assigning roles will only allow a small amount of the access that is actually needed for the users to be effective.

Organizational-based Role Assignment

One strategy to accomplish effective role is to use the company’s organizational structure and create a role at each level. The following example users a fictitious company, Acme, Inc. and lists example roles at each level:

• Acme, Inc. (company) – Active Employee
• Marketing (business unit) – Marketing User
• Sales (department) – Sales User
• Central Texas (team) – Central Texas Sales User

In this example, the roles at each level provision additional access needed for the users within that part of the organization. The “Active Employee” role provisions birthright access for all employees within the organization such as creating the users Active Directory account and Exchange online mailbox, assign the user to the “All Employees” distribution list and provision access to the company’s intranet or SharePoint site. The “Marketing User” may provision the user access to the organizations Marketing SharePoint site while the “Sales User” role may provision access to the organization’s Customer Relationship Management system and the “Central Texas Sales User” assigns the user to the Central Texas Sales teams sales queue within the CRM system. Role owners would be identified in each business area that would be responsible for maintaining their roles.

This strategy can be combined with the title-based role assignment strategy to create a very powerful role management strategy. Roles would be created for each title in a department to target sub-groups within each department.

Access Request vs Automatic Assignment

As mentioned above, role-based provisioning solutions allow roles to either be requested or automatically assigned. Ideally, all roles would be automatically assigned to users based on user data from an authoritative source. Getting to 100% coverage based on HR data alone is rarely if ever feasible. This is because the data inside an HRIS or other user management system isn’t meant to capture all of the details for the business functions the user will fulfill for the organization. For example, a user in an IT department may have the title “Database Administrator”. While this indicates that the user will have DBA rights, it doesn’t capture important details for which applications or databases the user will be working on, the project they may be assigned to, etc. For this reason, it is important to provide the capability for users, their manager or other responsible party (e.g. Project Manager) to have the capability to request access to the specific applications or systems that the user needs to perform their job.

Summary

Role-based identity management is a foundational capability of highly successful IAM programs but requires special planning and consideration to be effective as well as to maintain and increase that effectiveness over time. Sirius employees highly skilled and seasoned IAM consultants and practitioners that can help ensure that your IAM program is successful from a business, regulatory and security perspective. Let us assist you in building out a roadmap for how to properly incorporate the concepts presented in this white paper for your organization.