- Examples of SoD
- SoD in IdentityIQ
- IdentityIQ SoD Policies – the Basics
- Policy Type
- General Information for the Policy
- Policy Rules
- Compensating Controls and Corrective Advice in Policies
- Detective and Preventive Policies
- What Violation Owners See
- Common Best Practices for Building SoD Policies
- One Policy or Many?
- Names and Descriptions
- Preventive Controls
- Testing Policies and Policy Rules
- Provide Useful Guidance
- Monitoring Violations
- For More Information
Separation of duties, sometimes also referred to as segregation of duties, is a common business control with two primary objectives:
- Preventing fraud, conflict of interest, wrongful acts, and errors
- Detecting any failure of controls that might include or lead to security breaches, information theft, or circumvention of security protocols
Separation of duties is commonly abbreviated as SoD.
Effective SoD relies on ensuring that no single individual is responsible for an entire transaction. Instead, responsibilities and access for a specific business process are divided across multiple users or teams. A good SoD program should also ensure that individuals are not responsible for reporting on or monitoring themselves, or their superiors.
In addition to being good business practice, SoD is an important element of many common audit, legal and privacy regulation standards, such as HIPAA, SOX, GDPR, PCI, and SHIELD.
Examples of SoD
Accounts receivable. One employee records cash payments from customers, and another employee creates credit memos for the customers. This reduces the risk that an employee will divert a cash payment from a customer and cover the theft with a matching credit to that customer's account.
Inventory management. One employee orders goods, and another employee logs in the received goods in the inventory or accounting system. This prevents the employee who orders goods from diverting them for his own use.
Information security. One person or team is responsible for designing and implementing security, and a different person or team is responsible for conducting security audits or monitoring and reporting on security. This protects against the accidental or deliberate implementation of flawed or ineffective security practices.
IT/Engineering process. A software engineer cannot move code into production without oversight, quality assurance, or access rights authentication from other engineers. This ensures that a single person cannot introduce fraudulent or malicious code into essential systems.
Sales. A salesperson who is responsible for creating sales orders cannot process billing for customers. This protects against the salesperson inappropriately creating or changing a sales document and generating a corresponding billing document for it.
SoD in IdentityIQ
IdentityIQ lets you create SoD policies for roles, entitlements, and effective entitlements (effective entitlements are the de facto access a user has by virtue of having some other entitlement – such as a role in SAP that provides effective access to various transaction codes).
SoD policies detect and alert you when a user’s current access is in violation of your organization’s policies, and can also preventively alert you when requesting, approving, or certifying access will result in a policy violation. When violations occur, and when they are remediated (for example, by revoking access), IdentityIQ keeps a record of your SoD activities for reporting and auditing purposes.
IdentityIQ SoD Policies – the Basics
SoD policies are created and maintained via the Setup > Policies menu. SoD policies in IdentityIQ can include a variety of identity data to define what is not permitted:
Identity attributes: A property specific to the user - for example, is the user a manager? Is the user a contractor? Is the user in located a specific geographic area, or part of a particular department?
Account attributes: A property specific to the account – for example, is the account disabled? Who is the owner of the account?
Entitlements: The specific permissions the user’s account allows - for example, can the user modify or delete records in the financial application, or merely view them? Can the user approve a vendor, pay a vendor, change salaries, record inventory counts, et cetera?
Roles: Roles define sets of entitlements, typically based on job function. If your implementation uses roles you might for example have one role for accounts payable and another for accounts receivable, which should not be shared by the same users.
IdentityIQ capabilities: These control the actions a user can take within IdentityIQ – for example, approving an access request or editing a policy definition.
Policy Type
When building SoD policies in IdentityIQ, the first thing you’ll choose is what type of access the policy will govern. IdentityIQ has specific SoD policy types for Roles, for Entitlements, and for Effective Entitlements.
General Information for the Policy
Once you have chosen your SoD policy type, you set up some general information and settings for the overall policy – things like the policy name, a description, who is responsible for addressing violations, and whether there are any custom business processes the policies should follow. (Business processes can add complex custom logic and behavior to your policies; to learn more about using business processes in policies, see the Policies technical white paper)
Policy Rules
Finally, every policy needs policy rules that define the logic of the policy – that is, the business rule that the policy enforces. Every policy needs at least one policy rule to define what the policy does, and in SoD policies, you can also group multiple policy rules together under a single policy. For example, you might group all the SoD rules related to a single application or a single department together in one policy.
Compensating Controls and Corrective Advice in Policies
At the rule level, you can include text describing Compensating Controls and Correction Advice to help policy violation owners resolve violations correctly, according to your organization's business rules. This text is informational only; it can help explain what the violation owner should know or do, but does not supply any automated logic that IdentityIQ will enforce.
Compensating Controls give a description of exceptions or compensating factors that apply to this rule. For example, certain policies or rules might not apply to users at the executive level in your organization.
Correction Advice is information that can be used by a policy violation owner to make the correct decision on the violation.
Detective and Preventive Policies
In IdentityIQ, SoD policies can be both detective and preventive.
Policies are detective when they find and flag any access that already exists and is in violation of your business rules. In IdentityIQ, the Refresh Identities task checks all identities against policies, and marks the ones that are in violation of your active policies. IdentityIQ policies always provide detective controls.
Policies can also be preventive, helping you spot and avoid the granting of problematic access before it occurs. Users can be alerted to violations at the time access is requested, and when it is approved. Making policies preventive is an optional, and is configured using a business process for provisioning. The out-of-the-box business process that manages this behavior is LCM Provisioning, but you can implement your own business processes as needed, using LCM Provisioning as a model.
To learn more about how to enable preventive behavior in policies using a business process, see the Policies technical white paper.
What Violation Owners See
The users responsible for reviewing and mitigating policy violations can see the violations awaiting their attention under the My Work > Policy Violations menu. There is also a Policy Violations quicklink tile that can be enabled on the IdentityIQ home page. The Quicklink menu at the left of the home page also lists policy violations under My Tasks; the Quicklink menu is customizable, so keep in mind that in your own implementation, the Quicklink menu may be organized differently. Policy violations also appear in the access reviews that make up certifications.
Knowing what information appears where in the UI for reviewing and remediating policy violations can help you plan what to include in your policy and policy rule definitions.
When users review policy violations, they see summary information in list view, and can click the three-line menu > Details to open a pop-up with more information.
In the summary list view, the Name of the overall policy, and the Summary and Description for the specific policy rule involved in this violation are displayed:
The Details button in this view opens a popup that shows the Name and Description of the overall policy, as well as the Summary (in the Rule Description field), Compensating Control, and Correction Advice from the policy rule.
Common Best Practices for Building SoD Policies
One Policy or Many?
A single policy can contain multiple policy rules. As you develop your policies, think about what belongs under one policy umbrella, versus what should be distinct. For example, you might create one policy for “Finance Department Role Conflicts” that could include many individual rules defining which roles cannot be shared within the Finance department. If your policies don't fit logically into categories, individual policies for each SoD rules might be the right approach.
Names and Descriptions
Always provide user-friendly and intuitive names and descriptions for each policy and policy rule. The description of the policy (though not of the policy rules) can also be localized if you need multilingual translations. A good rule of thumb is that the policy name should indicate the purpose of the policy, and the policy rule name should indicate what the rule actually does.
Preventive Controls
Whether or not to alert requestors and/or approvers that granting certain access will result in a SoD policy violation is something you can configure in the lifecycle management business process for provisioning. There may be some cases when you do not want to let users know which access combinations can provide an opportunity for fraud or for circumvention of security controls. For more information about using business processes in your policies, see the Policies technical white paper.
Testing Policies and Policy Rules
Fully testing policies before making them live is an essential step. There are Run Simulation options at both the policy level, and the policy rule level – use these to test the behavior and outcomes of your policies. When you run simulations, the simulation tests the policy or policy rule against every identity in your system; however, it doesn’t mark any identities as being in violation, create work items for remediating violations, or provide a list of identities in violation. It only gives you a count of the identities that are in violation of the policy or policy rule.
You can also set a policy’s state as Active or Inactive, giving you the opportunity to work iteratively on a policy, or temporarily suspend it while making updates, without impacting your daily operations. It’s a good idea to leave policies inactive until you have assessed them and are certain they are functioning as intended. Individual policy rules within a policy can also be enabled or disabled as needed, without impacting other policy rules that may be part of the policy.
Important: running a simulation on a policy or policy rule automatically disables it; be sure that both the policy and policy rules have been reactivated when your testing is done.
Provide Useful Guidance
Every policy should include clear language about the policy’s purpose, and how to manage violations. Policy rules include fields for giving important information and guidance to users. Be sure to provide meaningful and complete information with each rule, so that users have a clear understanding of the purpose of the rule and how to manage violations:
Monitoring Violations
These are the standard IdentityIQ reports that are available to policy administrators. They provide data on SoD (and other) policy violations, and the actions that have been taken to resolve them. Your implementation team can also extend these reports, so you may see additional reports in your own environment.
For more info on the contents of these reports and how to run them, see the Reporting chapter in the IdentityIQ Users Guide.
For More Information
User Guides:
- IdentityIQ Policies Guide
- IdentityIQ User Guide: Reports chapter
Technical White Paper: Policies technical white paper
Training: Identity University Policies class: IdentityIQ Business Administration: Policy v8.0 - ELEARNING
