Overview

Evaluating Toxic Entitlement Combinations in Okta SOD Rules

This guide outlines a methodical approach to evaluating data related to toxic entitlement combinations within Okta's Segregation of Duties (SoD) rules. It clarifies when SoD rules should employ one-to-one, one-to-many, or many-to-many comparisons, given the functional specifics of Okta's SoD rule engine.

Understanding SoD Rules in Okta

Okta's SoD framework is designed to prevent conflicts of interest and reduce the risk of fraud by ensuring that no single user has all the entitlements necessary to complete a critical transaction or process. This involves defining "toxic" combinations of entitlements that, when held by a single user, create a security risk.

Types of Entitlement Comparisons

The effectiveness of an SoD rule heavily depends on the comparison model used to identify toxic combinations. 

NOTE:  SoD rules on the string-based entitlements will never trigger a toxic combination because the user is never allowed to have more than one entitlement value at a time.  This is enforced by the application. 

One-to-One Comparison

A one-to-one comparison is the most straightforward. It involves identifying a specific pair of entitlements that, if held by the same user, constitute a violation.

When to Use

• Simple Conflicts: When two distinct entitlements are inherently contradictory and should never be granted to the same individual.

• Clear Responsibility Separation: For roles where specific responsibilities are strictly separated, and access to both functions would allow a bypass of controls.

Example

• List1 / Entitlement A: "Create Purchase Order"

• List 2 / Entitlement B: "Approve Purchase Order"

If a user has both Entitlement A and Entitlement B, a one-to-one conflict exists.

One-to-Many Comparison

A one-to-many comparison involves one specific entitlement that, if combined with any of a defined set of other entitlements, creates a violation.

When to Use

• Core Entitlement with Multiple Risks: When a single critical entitlement, when combined with various other entitlements, could lead to different types of security breaches.

• Role-Based Access Control (RBAC) Scenarios: Where a specific role (represented by a core entitlement) should not have access to certain sensitive functions.

Example

• List 1 / Core Entitlement A: "Administer User Accounts"

• List 2 / Entitlement Set B: {"Modify Financial Data", "Approve System Changes", "Access Sensitive Customer Information"}

If a user has "Administer User Accounts" and any entitlement from "Entitlement Set B," a one-to-many conflict exists.

Many-to-Many Comparison

A many-to-many comparison identifies a violation when a user possesses any entitlement from one defined set and any entitlement from another defined set. This is the most complex comparison type.

When to Use

• Complex Role Overlaps: In environments with granular entitlements and intricate role structures, where multiple combinations can pose a risk.

• Cross-Functional Risks: When combinations of access from different functional areas can lead to a toxic entitlement.

Example

• List 1 / Entitlement Set A: {"Process Payments", "Generate Financial Reports"}

• List 2 / Entitlement Set B: {"Approve Payment Batches", "Modify Vendor Information"}

If a user has any entitlement from "Entitlement Set A" and any entitlement from "Entitlement Set B," a many-to-many conflict exists.

Data Evaluation Steps

The following table outlines the steps for evaluating toxic entitlement combinations.

Guidance for Okta's SoD Rules

Okta's SoD rule engine allows for flexible definitions that can accommodate all three comparison types. Here's how to approach each:

• One-to-One: Directly define the two specific entitlements that conflict within a single rule.

• One-to-Many: Define the single "core" entitlement and then list all the entitlements in the "many" set as conflicting. Okta's rules often allow for specifying "any of the following" for the second part of a rule.

• Many-to-Many: This requires careful construction. You might need multiple rules or utilize Okta's rule grouping capabilities to achieve this. For instance, you could define a rule that says "if a user has any entitlement from Set A AND any entitlement from Set B, then flag."

Best Practices

• Involve Stakeholders: Collaborate with business process owners, compliance teams, and security experts to accurately identify toxic combinations.

• Start Simple: Begin with critical one-to-one conflicts and gradually introduce more complex one-to-many and many-to-many rules as your understanding of the data and Okta's capabilities grows.

• Document Everything: Maintain detailed documentation of your SoD rules, the rationale behind them, and the identified toxic combinations.

• Leverage Okta's Features: Familiarize yourself with Okta's specific features for defining SoD rules, including conditions, groups, and remediation actions.

• Regular Audits: Conduct regular audits of user entitlements against your SoD rules to ensure ongoing compliance and identify any new or overlooked conflicts.

• Evaluate:  Building aggregated rules based upon entitlement groupings where possible. Follow the 3 C’s.  Consider, Calculate and Compute.

Related References

• Corporate blog: Scaling identity lifecycle with Okta Identity Governance

• Guide on using Okta Identity Governance API’s

• Corporate blog: Okta Identity Governance: A Unified IAM and Governance Solution

• Improve Your Security Posture with Okta Identity Governance (OIG)

• Understanding Okta Resource Name (ORN)