RBAC Introduction
Role-based access control (RBAC) is becoming the norm for managing entitlements within enterprise systems and applications and plays a significant role in establishing a model for enforcing security within organizations. It simplifies entitlement management by using roles, as opposed to users, as authorization subjects. A holistic approach to role definition can help alleviate certification-related regulatory compliance challenges, and should be considered an integral part of any Identity and Access Management initiative.
Traditionally, legacy systems and applications managed user permissions by means of groups. Under this model, permissions are assigned to groups and users inherit permissions by being a member of a group. The ability to assign permissions to a group and determine who can inherit the permission is considered discretionary access control, since these decisions are made by the application and system owners. However, authority to assign members to a group is deemed non-discretionary and usually is performed by the security organization.
These concepts have evolved with the adaptation of RBAC in Identity and Access Management (IAM) solutions. Assignment of permissions to a role and determining membership of roles is supposed to be non-discretionary. User accounts inherit a set of entitlements as they are enrolled into the organization as part of the onboarding process.
In the past, managing entitlements has been considered a technical responsibility, since they are related to applications and are managed without much business input. With the emergence of various regulatory requirements such as the US Sarbanes-Oxley Act, US Health Insurance Portability and Accountability Act (HIPAA), Gramm-Leach-Biley Act (GLBA) and EU Privacy Protection Directive 2002/58/EC, it is increasingly important to streamline the entitlement management process with business oversight, as it now has become a security governance and compliance issue.
Traditionally, legacy systems and applications managed user permissions by means of groups. Under this model, permissions are assigned to groups and users inherit permissions by being a member of a group. The ability to assign permissions to a group and determine who can inherit the permission is considered discretionary access control, since these decisions are made by the application and system owners. However, authority to assign members to a group is deemed non-discretionary and usually is performed by the security organization.
These concepts have evolved with the adaptation of RBAC in Identity and Access Management (IAM) solutions. Assignment of permissions to a role and determining membership of roles is supposed to be non-discretionary. User accounts inherit a set of entitlements as they are enrolled into the organization as part of the onboarding process.
In the past, managing entitlements has been considered a technical responsibility, since they are related to applications and are managed without much business input. With the emergence of various regulatory requirements such as the US Sarbanes-Oxley Act, US Health Insurance Portability and Accountability Act (HIPAA), Gramm-Leach-Biley Act (GLBA) and EU Privacy Protection Directive 2002/58/EC, it is increasingly important to streamline the entitlement management process with business oversight, as it now has become a security governance and compliance issue.
RBAC Implementations
It is becoming increasingly important to devise a common set of roles that can be reused, over and over again, as opposed to defining roles every time an IAM component is deployed. One of the challenges often faced is that organizations often implement IAM systems based on a role-based paradigm without much consideration for roles. If defined incorrectly, roles are ineffective and fail to meet the organization’s requirements. In order to minimize the deployment effort, role definition is often not considered part of the initial project, leading to project scope creep and unmet expectations and requirements.
Roles can be defined at an abstract level from a business perspective, or context-specific to an application or system from a technology perspective. At an abstract level, roles can be a simple label that defines the job function with a set of responsibilities and authority that goes with it. For example, a bank teller’s job function can be a role defined as teller with the responsibility to perform financial transactions with certain limits (authority). At an abstract level, there is no enforcement capability. The role teller in an application has specific entitlements that enable a user to execute transactions with certain limits. How this is configured within the application and how it is enforced is specific to the individual application’s capability.
Whether an organization looks at defining roles either abstract or specific to a context, the requirements to define roles are important and role definition is a critical step in deploying any RBAC system.
Roles can be defined at an abstract level from a business perspective, or context-specific to an application or system from a technology perspective. At an abstract level, roles can be a simple label that defines the job function with a set of responsibilities and authority that goes with it. For example, a bank teller’s job function can be a role defined as teller with the responsibility to perform financial transactions with certain limits (authority). At an abstract level, there is no enforcement capability. The role teller in an application has specific entitlements that enable a user to execute transactions with certain limits. How this is configured within the application and how it is enforced is specific to the individual application’s capability.
Whether an organization looks at defining roles either abstract or specific to a context, the requirements to define roles are important and role definition is a critical step in deploying any RBAC system.
Role Engineering Approaches
Role definition and management requires alignment between business and IT. It requires a strong commitment and cooperation among the business units, as a role engineering initiative could transcend the enterprise.
Top-Down
This approach is primarily business-driven, and roles are defined based on the responsibilities of a given job function. For roles to be effective, there should be a strong alignment between business and IT objectives. Roles are defined by reviewing organizational business and job functions and mapping the permissions for each job function. This approach provides business oversight and alignment of roles with business functions and reusability.
Following are the key steps for a top-down role engineering approach:
Bottom-Up This approach is based on performing role-mining/discovery by exploring existing user permissions in current applications and systems. Once user permissions are explored, the next step is to perform role normalization and rationalization. In this approach, roles are defined to meet specific application or system access requirements. One of the challenges of this approach is that it requires viable commercial tools to perform role mining. An alternate approach is to select a set of representative users and extract the entitlements that best describe the job function. If the user population is significant, it would be ideal to sample a certain percentage of the population to validate the accuracy of the results. One of the outcomes of this approach is that users often accumulate entitlements based on their previous job functions performed over a period of time; it can become too daunting to extract the entitlements without the business involvement. This is a key aspect of role rationalization to be considered as part of a bottom-up approach.
Hybrid This approach combines the previous two approaches and is considered the industry best practice. It leverages normalized roles derived from role mining and aligns them to job functions, with the involvement of the business.
Role engineering, in a top-down and bottom-up hybrid approach, is a key cornerstone in the process of defining roles that meet the organizational requirements. Once the roles are defined and inventory has been published, it has to be maintained by both the business and IT, as this helps to keep the information current and available for any future IAM initiatives.
Top-Down
This approach is primarily business-driven, and roles are defined based on the responsibilities of a given job function. For roles to be effective, there should be a strong alignment between business and IT objectives. Roles are defined by reviewing organizational business and job functions and mapping the permissions for each job function. This approach provides business oversight and alignment of roles with business functions and reusability.
Following are the key steps for a top-down role engineering approach:
- For a successful role engineering project, it is pivotal to define the scope and boundaries for the project. If the organization has a large user population, it would be ideal to conduct a pilot to validate the approach and the outcome. The boundaries could be specific business units or applications that are being considered for role definition.
- It is important to identify enterprise access policies to determine entitlements for a given job function. The objective of this exercise is to define entitlements based on the least privilege access principle.
- The next step is to group users in a given business unit based on privileges corresponding to their job function. This would provide some basis for determining appropriate criteria to identify and define the user population.
- One of the critical aspects of role definition is not to have mutually exclusive roles assigned to the same person. For example, a person who creates a purchase order should not be the one who approves it. These types of constraints are defined as part of segregation-of-duties policies. It is important to capture these constraints so that rules can be established to evaluate what types of roles can be assigned to a user for a given job function.
- Role hierarchies help simplify role definitions by aggregating roles. Role hierarchies usually follow the pattern of organizational hierarchies, where users in the higher organizational structure are able to perform the job functions of their direct and indirect reports. For example, a bank branch manager can perform the job function of a bank teller. Creating role hierarchies simplifies the number of roles assigned to a user.
Bottom-Up This approach is based on performing role-mining/discovery by exploring existing user permissions in current applications and systems. Once user permissions are explored, the next step is to perform role normalization and rationalization. In this approach, roles are defined to meet specific application or system access requirements. One of the challenges of this approach is that it requires viable commercial tools to perform role mining. An alternate approach is to select a set of representative users and extract the entitlements that best describe the job function. If the user population is significant, it would be ideal to sample a certain percentage of the population to validate the accuracy of the results. One of the outcomes of this approach is that users often accumulate entitlements based on their previous job functions performed over a period of time; it can become too daunting to extract the entitlements without the business involvement. This is a key aspect of role rationalization to be considered as part of a bottom-up approach.
Hybrid This approach combines the previous two approaches and is considered the industry best practice. It leverages normalized roles derived from role mining and aligns them to job functions, with the involvement of the business.
Role engineering, in a top-down and bottom-up hybrid approach, is a key cornerstone in the process of defining roles that meet the organizational requirements. Once the roles are defined and inventory has been published, it has to be maintained by both the business and IT, as this helps to keep the information current and available for any future IAM initiatives.
Conclusion
As organizations embark on various RBAC-oriented IAM initiatives, it is becoming evident that defining high-level roles with basic entitlements will not deliver expected business benefits. It is imperative for a successful role definition to have management support, sufficient funding for the role engineering effort, business unit participation, and resources committed to the project. The importance of roles should not become an afterthought, but should be considered an integral part of any IAM initiative. Organizations also need to address requirements for roles from a compliance standpoint. Entitlement certification is becoming a critical aspect of various regulatory compliance initiatives. Having a holistic approach to role definition helps alleviate certification-related regulatory compliance challenges.
It is important for organizations to get the expected business benefits with careful consideration for how roles are going to be defined and managed on an ongoing basis. Defining roles is difficult under any circumstances, but the process could be overbearing without established limits. It is important to define boundaries for user population, applications and platforms, and the number of business units to be covered by the project.
It is important for organizations to get the expected business benefits with careful consideration for how roles are going to be defined and managed on an ongoing basis. Defining roles is difficult under any circumstances, but the process could be overbearing without established limits. It is important to define boundaries for user population, applications and platforms, and the number of business units to be covered by the project.