Risk-based Access Approval with IBMs IGA Products

View Only

Risk-based Access Approval with IBMs IGA Products

By David Edwards posted Wed July 03, 2019 09:55 PM

Like

Identity Governance and Administration (IGA) solutions are all about reducing the risk to businesses that users and their access represent. But they also need to maintain an ease-of-use so that users don’t find ways to circumvent IGA controls and introduce more risk.

With IGA tools, like IBM Security Identity Governance and Intelligence (IGI) and IBM Security Identity Manager (ISIM), we have various controls to reduce risk, such as role-based access, approval workflows on request-based access, risk policy (such as Separation of Duties policy), risk mitigation and recertification. If applied correctly, these can effectively manage and reduce the user-based risk.

But what if we could use risk to simplify the user experience? One way we could do this is to use risk determination to decide whether we need to apply approval workflow. If a request represents low risk, why waste time in approval? The following article looks at how this could be applied in IBMs IGA solutions – IGI and ISIM.

Identifying Risk

There are many measures of risk that can be relevant to an IGA solution, such as risk policies, user risk scores, application risk scores and access entitlement risk scores. Let’s have a look at these.

Risk Policy

Risk policy, like Separation of Duties (SoD), Sensitive Access (SA) or Privileged Access, are a way to define risk. These policies will define access entitlements that carry a level of risk and possibly a level of risk. Both IGI and ISIM have the concept of SoD, and IGI adds a risk rating (high, medium, low). IGI also has SA policies, where specific entitlements carry a level of risk.

IBM Security Secret Server (https://www.ibm.com/au-en/marketplace/secret-server) defines privileged “secrets” to allow privileged access. When integrated with IGI (via the supplied adapter) these secrets can be managed in risk policies, like SoD and SA policies.

We leverage this in IGI in the out-of-the-box approval workflows – if a risk violation is detected by an access entitlement request, we can escalate to a risk owner for review. Using Rules in IGI we can programmatically access risk policies. This is also theoretically possible in ISIM using API calls in Operation nodes in workflow.

User Risk

We can consider user risk; do we have users that are “riskier” than others; does their access represent greater risk to the business; if so, how do we know and use this risk; can we bypass approval if the user is below a certain threshold of risk?

IGI maintains a level of risk based on the highest level of all risk violations for that user, resulting in a high/medium/low rating. This can be accessed programmatically in Rules.

We can also leverage analytics tools to determine user risk. IBM QRadar SIEM User Behavior Analytics (UBA) can determine a degree of risk associated with a user, but currently there is no simple way to get that risk back into IGI or ISIM.

QRadar UBA — QRadar User Behavior Analytics (UBA)

IBM Cloud Identity Analyze (CIA, part of the Cloud Identity family, but currently in beta) uses a combination of rules and intelligence to associate risk with users and their access. This risk information is returned to IGI and stored in the IGI DB that can be accessed programmatically from within a Rule. A similar capability is expected to be added to ISIM in the future, but today one could access the user risk scores in CIA and assign them to an attribute on the PERSON object.

Thus, it’s possible to programmatically access user risk information, either native to IGI or from an external analytics engine (UBA or CIA) plumbed into IGI. A similar mechanism could be built to get external risk into ISIM.

Application Risk

In any business some applications represent greater risk to the business than others. The core customer application carries far greater risk than an intranet information website or learning management tool. Can we associate a risk with an application and use that to decide whether to bypass approval?

Neither IGI nor ISIM have the concept of application risk. Whilst IGI does have SoD/SA policies and these relate to access entitlements belonging to applications, we don’t consolidate or show a score anywhere. You could arbitrarily assign a risk rating to applications and store it on the Application in IGI (or APPLICATION object in ISIM) and access it programmatically.

External analytics tools, like UBA and CIA, can also determine risk for applications. With CIA we can return this risk information to the IGI DB and access it programmatically, similar to user risk.

Access Entitlement Risk

We have talked about risk associated with users and risk associated with applications. What about risk associated with specific access entitlements? Any application will have access entitlements that are considered riskier than others, such as privileged accesses.

Neither IGI nor ISIM have the concept of access entitlement risk – there is no attribute stored on the entitlement (e.g. group, role), nor is there a mechanism to determine risk and apply it to an attribute on the entitlement. Risk ratings could be arbitrarily defined and manually assigned to an entitlement and stored on an attribute, then programmatically accessed.

Within IGI we could also use a SA policy to associate risk with an entitlement. If a specific entitlement is considered risky and needs to be managed as a risk, you can create a SA policy for that entitlement and associate a level of risk.

If IBM Security Secret Server is integrated with IGI (or ISIM), we could take that association and apply a risk to the associated entitlement. For example, we might have a Rule that processes new entitlements coming from Secret Server and if it’s a secret then set a “low” risk rating, if it’s a folder then set a “medium” risk rating, if it’s a folder under specific branches of a folder tree then set a “high” risk rating. This is done as the Secret Server access entitlement is added to IGI.

External analytics tools, like UBA and CIA, can also determine risk for access entitlements. With CIA we can return this risk information to the IGI DB and access it programmatically, similar to user and application risk.

Making Use of the Risk Information to Modify Approval Flows

The previous section showed how we can collect risk information in our IGA tools (IGI and ISIM). This may be risk policy (SoD, SA), user risk, application risk and access entitlement risk. With this information stored in the local repositories (or accessible programmatically) we can now look at how we use this information.

Using Risk in ISIM Approval Flows

As can be seen above, IGI is the strongest when it comes to risk management – it’s one of the main reasons for the product. However, ISIM can access and leverage risk information programmatically and use it to determine approval flow. How? By using Operation nodes in a workflow and an associated Java program.

Operation nodes allow execution of a Java program. It would be the first step in an approval workflow, which would determine the risk and make a decision, then the resulting flow would branch to the approval steps or to the end. The Java program would need to gather the risk information (SoD, user, application, access entitlement) and decide whether to proceed to approval or to skip.

Using Risk in IGI Approval Flows

Implementing a mechanism to skip over approvals in a workflow process involves having a Rule associated as a Post-action on the GEN step. This Rule would go collect the relevant risk information (SoD/SA, user, application, access entitlement) and decide whether to proceed to approval or not. If there is no need for approval (i.e. risk is low) then the Rule can automatically approve the next approval step in the request and let the flow proceed.

IGI Workflow Rules — Adding Rules to IGI Workflow

There are examples of this type of Rules processing on the IGI Rules git (https://github.com/IBM-Security/igi-rules). See the Rules guide (pdf) and also examples in the Sample Rules / Other Rules / Workflow folder for examples.

IBM Security Verify