Role Engineering or Role Mining



Every organization use some model to manage their resources or assets and RBAC is the most famous & most adopted model for the same. RBAC i.e. Role Based Access Control simplifies the management of access to resources and assets. In RBAC model, all the permissions/access are tied to various roles. Controlling the access through roles reduces the administrative burden of security practitioners. Here are the few key benefits of RBAC model:

Key Benefits:

  • ·       Reduces no of access requests & approvals
  • ·       Improve end user experience
  • ·       Enhance security
  • ·       Very helpful in implementing Birth Right Access
  • ·       Improve Productivity
  • ·       Simplifies the User Access Re-validation (Certification)
  • ·       Build the foundation to implement Separation of Duties


Sometimes it becomes difficult to implement RBAC in large organizations as every organization has their own set of resources, permissions, job functions, policies and controls. Identifying the right roles for an organization is a big & an important task and this task of identifying roles is known as Role Engineering. Role Engineering is also known as Role Mining or Role Discovery. Role Engineering is a process to discover relationships between access permissions and users or job functions which can be grouped together to form a role.
.
There are three types of approaches which we use for Role Engineering:
.
  • Top-Down Approach: Roles are defined based on organization business
  • Bottom-Up Approach: Roles are defined to meet specific application or system access
  • Hybrid Approach: Roles are defined using above two approaches

Earlier Role Engineering was a manual process. Data Owners used to export the access data in an excel sheet to analyze and define the roles but nowadays most of the organizations have implemented IDM products like Oracle Identity Analytics, SailPoint IdentityIQ, CA IDM etc. Because organizations are using these IDM products, so these products will have the up-to-date access data which is a must have to perform this Role Mining process. These IDM products come with OOTB Role Mining capabilities, but custom algorithms can be implemented based on organization needs. Here’s the process which is used by these products for defining the roles in any organization:

  • ·       Setting the Role Engineering attributes
  • ·       Creating and Running Role Engineering Process
  • ·       Analyze the Role Engineering Results
  • ·       Configure and Save the Role Definitions
  • ·       Set the metadata for the roles

In the above steps, setting the role engineering attributes is the key steps because that is going to set the base or build the logic for the entire Role Mining process. If we want to perform Role Mining for an application, first we need the access data for that application. Second, we need to define some parameters like Job Title, Job Function, Department, User Type, Manager, Job Level etc. to find/discover the relationship. Once we execute step 1 and 2, IDM products will execute the Role Mining task and share the results.

Role Engineering is not just a one-time task or job, rather it’s an ongoing activity which helps organizations in enabling better control on their resources and assets. It was also proven that defining just high-level roles with basic access/permissions does not deliver expected business benefits. Role Engineering with any approach (Top-Down, Bottom-Up or Hybrid) is a key cornerstone.


Risk Scoring in IAM



Risk Management is a crucial part of each organization. This is the process to identify and evaluate the risk to avoid or minimize their impact. We also do Risk Management in IAM by assigning the correct Risk Scores to each and every asset, data, resources, applications, permissions, roles & identities. 

Why do we assign Risk Score?

Assigning the risk score helps in identifying the security value of the entity or information. This also helps in assigning the accurate security measures to protect the information or entity. For example, if an entitlement provides the privilege or admin access in any system then we can assign the High Risk score to that entitlement and this score can be used to trigger additional level of approval at the time of granting access, or at the time of User Access Revalidation.
Every organization use thousands or millions of entitlements and every user get access to hundreds of entitlements to perform his/her job functions, so it’s difficult to run the User Access Revalidation process for each and every user and for each entitlement in the organization. If we assign the Risk Score with the entitlements, we can run the User Access Revalidation process only for those users who are having access to entitlements with High Risk scores.
Risk score can be assigned to Roles as well. In an RBAC model, roles are tied with entitlements and risk scores of entitlements are utilized to calculate the risk of roles. In a similar way, risk score can be assigned to Identities or Users in an IAM system based on the roles & entitlement they have.

Should we assign the same risk score to all Privilege Entitlements or Roles?

No, we should not assign the same risk score to all privilege entitlements or permissions and there’s a reason behind for not doing this. Consider an example, there are three entitlements i.e. Entitlement 1, Entitlement 2 & Entitlement 3. 


Read
Write/Modify
Delete
Privilege Access
Entitlement 1
Yes
No
No
No
Entitlement 2
Yes
Yes
No
Yes
Entitlement 3
Yes
Yes
Yes
Yes

Based on the above table, Entitlement 2 & Entitlement 3 are Privilege access but give different level of access to users in the system. If we assign same risk score to Entitlement 2 & Entitlement 3, this means that impact of Entitlement 2 and Entitlement 3 are same which is completely incorrect. Entitlement 3 gives “Delete” access which has more impact than a “Write” operation.

Assigning the Risk Score is a very crucial and complex task which takes a lot of time and multiple rounds of analysis & review. 

SailPoint Context From Outside

Here's the code snippet to get the context, this can be used to do a quick API test for development.





Disclaimer

All content provided on this blog is for informational purposes only. The owner of this blog makes no representations as to the accuracy or completeness of any information on this site or found by following any link on this site. The owner will not be liable for any errors or omissions in this information nor for the availability of this information. The owner will not be liable for any losses, injuries, or damages from the display or use of this informatio