Separation of Duties Overview

Given the sensitive nature of many organizational IT resources and the potential for fraud exposing those resources to unwarranted users can cause, EmpowerID provides a Separation of Duties (SoD) engine that allows organizations to craft policies that mitigate the opportunities for fraud by restricting the actions and access authorized to any one person at a given time. In general, SoD policies are defined by an organization to create internal control and identify potential areas where conflicts of interest can create opportunities for unchecked errors or outright abuse. These often occur when combinations of privileges grant a user undesired access in a way that is termed a “toxic combination.”

A common example of such a toxic combination would be authorizing the same person or the same group of people to both cash and maintain the records of receivable checks. A SoD policy properly applied here would disallow any one person or group of people from performing both duties while also distributing a system of checks and balances to mitigate the potential for collusion. And since most of today’s financial transactions occur through the transference of electronic information, this scenario could readily play out through allowing toxic combinations of permissions or roles, such as occurred recently when one individual was authorized to both submit and approve trades, creating financial losses in the billions. As a powerful hub of all authorization information, EmpowerID is in a unique position to provide a full-featured SoD platform that allows for the creation of extremely flexible rules to prevent such disasters before they occur.

In large organizations, the sheer amount of resources needing to be managed and the sensitive nature of many of those resources make the reality of toxic combinations an ongoing threat. The feasibility of analyzing all the data connected to those resources with any type of acceptable frequency or even gathering all the data necessary for a proper analysis is an impossible task without an Identity Management system that collects that data into a single central repository. EmpowerID is a natural source for generating SoD rules to evaluate toxic combinations because in an enterprise, it is the system that has the most informative and authoritative data about the objects in your protected systems. EmpowerID’s inventory process gathers all the information in each protected system and application to provide a comprehensive snapshot of information about each object in those systems, including the access permissions and assignments people have to those resources, allowing you to immediately capture who has access to what and how that access came about.

EmpowerID SoD Policies are policies that allow you to implement rules that raise alerts when combinations of resource assignments violate your organization’s security protocols. These rules are always based on inappropriate access to resources occurring from an intersection of assignments and must include two sets of expressions to be implemented, such as a person having an assignment to a Management Role that authorizes actions and grants access to resources that should preclude that person from having a Management Role with access to other resources at the same time. When violations to a SoD policy are detected, they are routed for review to the appropriate authorized personnel whether those personnel are managers, role owners or data owners. The review process allows the reviewer to respond to the violation, determining whether the violation is permissible or if corrective action needs to be taken. Internal processes can use this data to remediate and rectify exceptions or to certify the exceptions as permitted. EmpowerID maintains an audit trail of these violations as well as the decisions made concerning them. Combining SoD policies with EmpowerID’s robust reporting capabilities allows organizations to create a more thorough and effective resource management strategy.

EmpowerID SoD policies come in the following types:

  • Group Membership Policy - The Group Membership Policy type allows you to combine two collections or sets of Groups for which an intersection of membership by any one person defines a SoD violation, regardless of how that membership was obtained. These types of policies can be crafted to preclude people from having accounts in both sets of groups at the same time. An example of this could be a SoD policy that denies any person who is a member of a customer group from being a member of a domain admin group at the same time.
  • Management Role Policy - The Management Role Policy type allows you to combine two Management Role Assignments to define a SoD violation whenever an intersection of those two Management Roles occurs for a single person. These types of policies can be crafted to preclude people from being assigned to both Management Roles at the same time. An example of this could be a SoD policy that precludes a person with a Management Role assignment that allows them to author security policies from being assigned to a Management Role that gives them audit privileges for those policies.
  • Access Level Policy - The Access Level Policy type allows you to combine two collections or sets of Access Levels to define a SoD violation whenever an intersection of any one of those Access Levels in one set occurs with a Access Level in the other set for a single person. Access Levels in EmpowerID represent actions that a person may perform in workflows or roles and permissions they may be assigned in other managed systems. Access Level policies can be crafted to preclude people from being assigned to any two sets of Access Levels at the same time. An example of this could be a SoD policy that denies an individual person from holding the modify Access Level for shared folders in Switzerland and the modify Access Level for shared folders in the United States at the same time.
  • Set Group Policy - The Set Group Policy type allows you to combine two collections of objects or query-based sets to define a SoD violation whenever an intersection of those two collections occurs for a single person. Set Groups are comprised of Sets, which are Ldap or code-based queries. These Sets are re-evaluated by the EmpowerID engine on a scheduled basis and can group collections of people or resources based upon queries written against the EmpowerID Identity Warehouse or even external systems in a customer’s environment. The use of SetGroups for SoD policies provides a rich and flexible mechanism by which organizations can selectively collect the objects they want to incorporate within a given policy. For example, you could use one SetGroup to collect all people who have not enrolled for password self-service and create another SetGroup to collect all people assigned to a specific role within your organization, then create a SoD rule that raises an alert whenever those queries run and collect people who fall into both of those collections at the same time.

Each SoD Policy can be scheduled to daily, weekly, monthly, quarterly, or at any moment, depending on the demands of your security policy. When a policy is run manually or at its scheduled time, any violations to that policy create SoD Violations task items for each policy. This allows authorized staff in an organization to review the violations and determine whether they warrant an immediate rectification or can be allowed at the moment.

These SoD Violations appear to delegated users on the SoD Violations tab of the My Workspace application in the EmpowerID Management Console. Clicking on the SoD Violations tab in My Workspace allows users to interact with each SoD Violation task item as either an Auditor or a Reviewer, depending on the delegations granted to those users. Users granted an Auditor role can view SoD Violations and the status of those violations, while users granted the Reviewer role can view SoD Violations as well as respond to any currently unreviewed items, changing the status and adding comments as necessary. SoD Violations have the following statuses:

  • Unreviewed - The SoD Violation has not yet been reviewed.
  • Acknowledged - The SoD Violation has been noted, but no corrective action has been taken by the reviewer.
  • Corrected - The exception to a SoD Policy has been corrected.
  • Permitted - The exception to a SoD Policy has been accepted.
  • Policy Changed - The SoD Policy has been changed to allow any exceptions to a previous version of the policy.


SoD Policy Security


As RBAC-protected resources, each SoD Policy requires users be granted Access Level assignments with the necessary operations allowed for both the policy itself and the Person that is the subject of the violation before they can take part in the review process. SoD Policies have the following security elements:

EmpowerID Protected Controls

  • EmpowerID Separation of Duties Policy - This is the EmpowerID Protected Control that secures access to the SoD Violations tab in My Workspace. For users to see the SoD Violations tab, they must be granted the Viewer Access Level for the control.
  • Resource Manager: Separation of Duties Policy Groups - This is the EmpowerID Protected Control object that secures access to the EmpowerID Separation of Duties node in the Resource Type drop-down of Resource Manager. For users to see this node in Resource Manager, they must be granted the Viewer Access Level for the control. Note that granting this Access Level does not give the assignee of the Access Level the ability to see any Separation of Duties objects in Resource Manager. In addition to this Access Level assignment, you must grant the Viewer Access Level for each Separation of Duties policy you want to be viewable as an object in Resource Manager.

Access Levels

  • Reviewer Access Level - The Reviewer Access Level has the Review operation allowed and grants assignees "Reviewer" status for a specific policy by allowing them to view SoD policies and violations as well as providing them with the ability to change the status of a policy and enter comments in as needed. This Access Level must be granted for both the policy and the people that are the violators of that policy.

Operations

  • Review - This operation allows users to perform status changes to an SoD violation task item. This operation must be allowed on both the SoD policy as well as the violators of the policy.
  • Provision - This operation allows users delegated a Access Level with the operation allowed the ability to create new EmpowerID SoD policies.
  • Edit - This operation allows users delegated a Access Level with the operation allowed the ability to edit EmpowerID SoD Policies.
  • Delete - This operation allows users delegated a Access Level with the operation allowed the ability to delete EmpowerID SoD Policies.

Workflows

  • ProvisionSeparationOfDutiesPolicy - This workflow gives delegated users the ability to create new SoD policies. To run the workflow, users must be assigned the Initiator Access Level. To provision a new SoD policy without requiring approval, users must also be assigned a Access Level with the Provision operation allowed.
  • EditSeparationOfDutiesPolicyNoUI - This workflow gives delegated users the ability to edit a SoD policy. To run the workflow, users must be assigned the Initiator Access Level for the workflow. To edit a SoD policy without requiring approval, users must also be assigned a Access Level with the Edit operation allowed.
  • CompileSeparationOfDutiesPolicy - This workflow gives the delegated users the ability to manually run a SoD policy. To run the workflow, users must be assigned the Initiator Access Level for the workflow.

As with all Access Level assignments, EmpowerID gives you the power to tailor those assignments, limiting or broadening their scope as desired. For example, if you have audit team members scattered across multiple locations, you can give them access to only those policies and policy objects related to their respective locations. In addition, EmpowerID provides a full audit trail for any SoD Violations that occur, providing a detailed account of the violation and how it was handled by the audit team.