Segregation Of Duties (SOD)

Cymmetri provides a framework for managing risk arising for application access to organization users. Broadly, the risk is quantified on the basis of Qualitative and Quantitative measures

Qualitative Risk

This is a risk that is identified from the knowledge of the system. This means that even in absence of the Enterprise Role model or mapping of activities or tasks or processes to the users, a certain risk value may still be assigned to the users, purely based on the application roles based on the COSO framework (i.e. admin / maker / checker / read only) and applications assigned to them.

The qualitative risk calculation will be based on -

The number of applications assigned to a particular user, the risk associated with the application, and
The risk associated with the COSO type of the application role.

Quantitative Risk

This is a risk that is identified from the specific classification of application roles based on High, Medium and Low risk. The risk classification is thus based on users having roles assigned to them.

SOD Features

As a part of Cymmetri’s Identity Governance & Administration capabilities, Segregation of Duty (SoD) is offered as a product feature.

Also called Separation of Duty, the SoD in principle is the demarcation of access grant with respect to business functions pertaining to a job / task.

The current functions by the SoD in the product provide-

Ability to configure the following under Entities:

Business Tasks
Business Roles
Business Process

Ability to configure the following under Policies:

SoD Policies
SoD Rules

To establish the activities performed by the organisation, the Cymmetri Admin will configure the Business Process. Under each Process, there will be one or several tasks to accomplish the business activities. For example, a task could be “Transaction Entry up to 50,000” or “Transaction Approval above 1,00,000” or “Manage Masters”

For each of the tasks, there will be Business Roles such as “Approve Transactions” or “Book Transactions” or “Manage System Configuration”

Example in tabular form:

Business Process

Business Role

Business Task

Purchase

Book Purchase Transactions

Transaction Entry up to 50,000

Transaction Entry between 50,001 - 99,999

Transaction Entry above 1,00,000

Purchase Approval

Approve Purchases Transactions

Approve up to 50,000

Approve between 50,001 - 99,999

Approve above 1,00,000

Maintain System

Configure System

Add & Modify Master records

Delete or Disable Master records

Manage Users

Add & Update Users

Delete or Disable Users

Assign or Remove Role to Users

Based on the above entity information, we can define Policies for defining the separation of duties

SoD Policy

SoD Rule (roles that cannot co-exist)

Maker cannot be checker

Book Purchase Transactions

Approve Purchases Transactions

Admin cannot have other roles

Configure System

Book Purchase Transactions

Admin cannot have other roles

Configure System

Approve Purchases Transactions

Linkage of Business Role with Application Role

When the SoD Admin is configuring the Business Role, they must link the record to an Application Role configured in Cymmetri. Thus the SoD Business Role and Application (IT) Role are interlinked providing Cymmetri with the mechanism for mapping business role to application role.

Apart from the above configurable elements, it is important to note that Applications configured in Cymmetri also allow defining the application risk categorization along with role type categorization. These elements together provide Cymmetri to define a Qualitative and Quantitative Risk score to every user based on the applications assigned and the role entitlement available with the user.

The benefit this provides in Cymmetri is that when a requester has asked for a role which may have potential conflicts, the approver is made aware of the same. Along with the conflicting roles (toxic combinations), it also allows approver to see the risk score associated with providing approval.

Violation example