Segregation of duties (SoD) policies allow organizations to define toxic combinations of entitlements, which no one user should possess. The most common business driver for these policies is fraud prevention -- i.e., ensuring that fraud cannot be committed without collusion by at least two people.

An effective SoD policy mechanism has several components:

  • Policy definitions:

    Define sets of two or more entitlements that should not be held by a single user.

  • Approved exceptions:

    Allow users to be assigned entitlements that violate an SoD rule, but with suitable business approval.

  • Preventive enforcement:

    Change requests that pass through an Identity and access management (IAM) system should be subject to SoD policy tests. Changes that would trigger an SoD violation should be blocked at request time.

  • Detective enforcement:

    Users and entitlements often exist before the deployment of an IAM system or the definition of a given SoD rule. Users may be assigned entitlements using tools other than the IAM system, therefore bypassing preventive enforcement. In each case, it is important to find and remediate violations after the fact.

An effective SoD policy mechanism should detect violations even if the policy is stated in terms of roles but the violation is in terms of lower-level entitlements -- or vice-versa.

Consider the following variations, where R1 is a role that consists of entitlements Ea and Eb and R2 is a role that consists of entitlements Ec and Ed, as shown in Figure [link].

Example of entitlements included in roles

Example of entitlements included in roles

Using this example, we can formulate a variety of SoD policies and identify multiple ways to violate each policy, as follows:

SoD policy

Initial

Requested

Why this is a violation
No Eb + Ec.

Eb

Ec

User has Eb directly, would get Ec.

Eb

Mirror image of the previous situation.

R1

User would get Eb from R1.

Ec

Mirror image of the previous situation.

R2

User has Eb from R1, would get Ec from R2.

R1

Mirror image of the previous situation.

R2

User has Eb directly, would get Ec from R2.

Eb

Mirror image of the previous situation.
No R1 + R2.

R1

R2

Direct violation.

Ec, Ed

User would effectively get R2.

...

Many more permutations...

A separate source of complexity is nested groups. i.e., entitlements on most systems are just groups, to which users are assigned and which are assigned access rights. Simple groups contain only accounts, but some systems, such as AD and RAC/F, support nested groups, where the members of a group can include other groups.

Both nested roles and nested groups can -- separately or jointly -- lead to cases where an SoD policy mechanism in an IAM system fails to detect policy violations.

Hitachi ID Identity Manager includes the most advanced segregation of duties (SoD) policy subsystem on the market. It actually works, whereas SoD policy checks in competitor IAM products can be bypassed in cases where there are nested roles and/or nested groups.

The Hitachi ID Identity Manager SoD policy subsystem supports:

  • Policy definition:
    • An SoD rule is defined as a toxic sets of entitlements.
    • Entitlements that participate in the SoD rule may themselves be roles, login IDs on specified target systems or membership in specific security groups.
    • Users who have at least N of the M SoD entitlements are considered to be in violation.

    This is a very general model. It supports rules such as "No user shall belong to more than 2 of these 30 groups."

  • Approved exceptions:
    • Users may be allowed to violate SoD rules, so long as an authorized person has approved the violation.
    • Access certification is used to periodically renew approved SoD exceptions.

    This is a practical model. It allows organizations to knowingly violate rules where there is a strong business reason to do so and where suitable compensating controls are in place.

  • Proactive enforcement:
    • SoD policy is an integral part of workflow in Hitachi ID Identity Manager.
    • Change requests that pass through Hitachi ID Identity Manager workflow must either:
      1. Satisfy all SoD rules (i.e., violate none); or
      2. Include a request for an approved exception to every violated rule.
    • Requesters -- via the Hitachi ID Identity Manager UI, API or automation system -- simply cannot ask for violations without also asking for an approved exception.

    SoD should be proactive rather than after-the-fact, wherever possible. This is supported by Hitachi ID Identity Manager.

  • Reporting on out-of-band and pre-existing violations:
    • It is still possible to have users with entitlements that violate SoD:
      • Pre-existing conditions, where a user violated the SoD rule before Hitachi ID Identity Manager was implemented or the rule was defined.
      • Out of band changes, made using administrative tools and login IDs outside of Hitachi ID Identity Manager.
    • In these cases, there is no general way for Hitachi ID Identity Manager to know which of the offending entitlements is inappropriate, so it cannot automatically remediate the violating users.
    • Instead, Hitachi ID Identity Manager includes reports to identify violating users and help security staff make appropriate remediating changes.

    SoD reporting is the defense of last resort.

  • Deep inspection:

    Roles can be nested into other roles. Groups can include among their members other groups. The result of these two hierarchies is that an SoD policy may be defined at one level of a hierarchy of roles or groups, but a violation may take place at another level of the hierarchy. The Hitachi ID Identity Manager SoD policy mechanism decomposes roles and locates parent groups in order to reliably detect policy violations. Competitor IAM products fail to find such such violations.

Return to Identity Management Concepts