Role Engineering: The Cornerstone of RBAC

By Srinivasan Vanamali, CISA, CISSP

Role-based access control (RBAC) is becoming the norm for managing entitlements within commercial systems and applications. RBAC plays a significant role in establishing a model for enforcing security within organizations. RBAC is also one of the critical components of an identity management (IdM) framework. It essentially simplifies entitlement management by using roles (as opposed to users) as authorization subjects. RBAC should not be treated as the panacea for all ills related to access control, but it has proven to be cost-effective for organizations—reducing entitlement management costs and complexity. It also reduces the risk of users having inappropriate access privileges and aggregating entitlements as they change job functions within the organization. As the users change their job function, they are assigned new roles and old roles are removed from their profile. This results in users’ entitlements matching their job functions.

Evolution of Entitlement Management

Traditionally, legacy systems and applications managed permissions by groups. Under this model, permissions are assigned to groups—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, as these determinations are made by the application and system owners. However, the authority to assign members to a group is deemed nondiscretionary and usually is performed by the security organization. This construct has evolved in recent times with the adaptation of RBAC in IdM solutions. Assigning permission to a role and determining membership of roles are supposed to be nondiscretionary. Users inherit sets of entitlements as their "birthright," as they are enrolled into the organization as part of the onboarding process.

Conventionally, managing entitlements has been considered technical, as entitlements are related to applications and are managed in silos 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-Bliley 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 has become a security governance and compliance issue.

RBAC 101

The fundamental concept of RBAC is that roles aggregate permissions by being members of roles. They are given entitlements—no more than what is required to perform their job function—based on the "least privilege access" principle.

The key elements of RBAC are:

  • Users—By definition, users are individuals who perform a job function within an organization. Users traditionally have been designed to perform individual functions within an organization.
  • Roles—In a business context, roles represent job functions and related responsibilities. Responsibilities represent users’ implicit or explicit authority to execute their job function. In a technology context, roles represent a collection of entitlements that a person inherits from an application perspective to perform a job function.
  • Permissions—In a technology context, permission is the authority to perform certain operations based on the assigned role.

Role Engineering

As organizations start deploying IdM solutions, 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 IdM component is deployed. One of the challenges often faced is that, if defined incorrectly, roles are ineffective and fail to meet the organization’s requirements.

Role engineering is the process of defining roles and related information, such as permissions, constraints, and role hierarchies, as they pertain to the users’ functional use of systems, applications, and business processes. It is essentially one of the critical steps in deploying RBAC-oriented IdM systems. Organizations often implement IdM systems based on a role-based paradigm without much consideration for roles. To minimize the deployment effort or to avoid project scope creep, organizations frequently do not invest enough time to define roles; rather, they tend to define high-level roles that do not reflect the organizational job functions. The process of defining roles should be based on a complete analysis of how an organization functions and should include input from a wide spectrum of users, including business line managers and human resources.

Key Steps for a Top-down Role Engineering Approach

  1. For a successful role engineering project, it is pivotal to identify enterprise access policies to determine entitlements for a given job function.
  2. Group users in a given business unit based on privileges corresponding to their job function.
  3. Avoid having mutually exclusive roles assigned to the same person.
  4. Role hierarchies help simplify role definitions by grouping similar roles together.

Conclusion

As organizations embark on various RBAC-oriented IdM initiatives, it is becoming evident that defining high-level roles with basic entitlements does not deliver expected business benefits. It is imperative for a successful role definition to require 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 as an integral part of any IdM initiative. Role engineering is a key cornerstone in the process of defining roles that meet the organizational requirements.