Segregation of Duties (SOD)

Owned by Christine Gross
Last updated: Apr 23, 2024 by Matt McIrvin
9 min read

Segregation of Duties (SOD) policies are essential in a governance, compliance, and security solutions to detect, prevent and resolve conflicting combinations of access. Segregation of Duties policies are typically part of an organization's overall compliance process to ensure that controls are being followed and visibility of any SOD Findings are highlighted and reviewed.

SOD Use Case Example

As a simple use case, conflicting combination of access allows a user to perform something (e.g., a transaction) that can result in (potentially financial) damage to their organization. This could be as simple as a user that is allowed to create a vendor in the vendor management system and also generate and submit an invoice for the vendor to get paid (this could be within the same application or across different applications or systems). These “toxic” combinations of access can occur from when users move and transfer within an organization, where old access from their old role is not timely removed (or removed at all). Additionally, this can occur where too much access is granted (over privileged) intentionally or unintentionally.

Learn more about these specific topics:

Creating and uploading Segregation of Duties (SOD) Policies

Use the following steps to upload conflicting access information to create SOD policies. 

Structure of the SOD upload CSV file

The following columns are required in the SOD conflicting access upload CSV matrix:

  • Policy – This is the name of the policy that will be created within Zilla. All rows with the same Policy will be grouped together to create a single SOD policy.  

  • FunctionA – A logical business function / operation that groups together access on one side of the policy that will be used to evaluate the conflicting access against Function B. A policy can have only two functions (logical groupings of access) A & B.

  • ApplicationA – Access which Zilla knows about that exists within a specific Application, this is the name of the Application that Zilla is bringing in permissions for. Only one Application can be listed on a line, if multiple Applications are part of the Function A for the policy, another line is required for each additional Application.

  • PermissionA – Permissions from Application A are listed in this field. Multiple permissions for Application A can be grouped together in this field (enclosing in quotes and comma separation) or listed as individual lines.

  • FunctionB – This is the other logical business function / operation that groups together access on the ‘other’ side of the policy that will be used to evaluate the conflicting function / access against Function A.

  • ApplicationB - Access which Zilla knows about that exists within a specific Application, this is the name of the Application that Zilla is bringing in permissions for. Only one Application can be listed on a line, if multiple Applications are part of the Function B for the policy, another line is required for each additional Application.

  • PermissionB – Permissions from Application B are listed in this field. Multiple permissions for Application B can be grouped together in this field (enclosing in quotes and comma separation) or listed as individual lines.

  • Description - Add a policy description that you want to automatically upload into Zilla, this field is optional. Policy descriptions can still be updated in Zilla, but if they exist in the upload file, they will be over-written. If there is no policy description in the upload file and one has been updated in Zilla, the one in Zilla will be preserved. Descriptions, especially with commas or other selected delimiters, should be enclosed in quotes for upload.

Notes:

  • If an application’s name is changed in Zilla, it will no longer match the policy or an existing upload file (that has the original name). Any application name change needs to be updated in the SOD upload file to update the SOD policies.

  • Only applications that Zilla is collecting information for are considered valid in the SOD upload. Applications that have been Archived are considered invalid and must be removed from the upload file as the resulting policy will fail to import.

Wildcard Support (*)

Support for wildcards (*) in the Segregation of Duties rules will match any value as long as it exists. Wildcards are only supported for the entire permission and / or resource (partial wildcards, such as “create*”, “*cash*”, “admin*” are not currently supported. Wildcard options are added to the PermissionA or PermissionB columns for the respective Applications in the SOD CSV file.

For example:

  • “*” - This will match any permission in the corresponding application that does not have a resource associated. Note: this will not match any permission that has a resource associated.

  • “*: *” - This will match any permission that has any resource associated. Note: this will not match a permission without a resource.

  • “permissionName: *” - This will match “permissionName” with any resources. Note: this will not match a permission without a resource, if the policy needs to consider both a permission with and without a resource, two entries are needed: “permissionName, permissionName: *”.

  • “*: resourceName“ - This will match any permission with the resource “resourceName”.

Note: the space after the “:” must be included after the colon and before the wildcard or the specified resourceName.

The findings generated will record and display the actual permission and resource that triggered the violation.

Example Segregation of Duties conflicting access matrix

 

Policy Upload Behavior

  • When a policy is first created and is new to Zilla, it is created in a Disabled state to allow the configurator to edit additional meta-data and notification actions before enabling.

  • If an Enabled policy structure is updated, for example a permission is added or removed in a subsequent file upload, any existing Findings will be updated to reflect the changes if conflicting access is found.

  • If there are any open Findings for a policy, and the policy is removed from the upload file, those Findings are no longer available.

Uploading the Segregation of Duties conflicting access matrix

  1. As an Administrator of your Zilla instance, go to Settings > Segregation of Duties and click on the Upload Button to select the file to upload.

  2. Select the SOD CSV file to upload and click on Next.

  3. The uploaded file will be analyzed at the Review step before importing to detect and display any errors and warnings found in the import file.

    2. Click on Next to proceed to the Confirm & Import step.

  4. Review the information for the policies that will be created, updated and/or removed before importing to make sure the changes are expected.

    2. Click on Submit to create, update and/or remove existing policies.

  5. The Segregation of Duties tab is updated with the policy and conflicting access information.

Segregation of Duties Policies

In this section you will learn how to:

  • Edit Segregation of Duties Policy General Information

  • Enable / Disable and Configure Automated Actions

Policies that are first imported will default to a Disabled state and High severity. Access and edit SOD policies in Zilla by clicking on Policies in the left navigation and then clicking the Segregation of Duties policy card. Click on the edit icon to edit the policy.

Edit Segregation of Duties Policies General Information

The following general information can be updated for Segregation of Duties Policies:

  • Description - description that is uploaded from the SOD matrix will appear and persist here (even if later updated in the UI). If there is no description included in the upload file, once can be filled in and will be persisted.

  • Severity - default severity is set to High and can be changed

  • Tags - tags can be added for additional policy reference

Note: The Policy Category “Segregation of Duties” cannot be changed to another category.

Enable / Disable and Configure Automated Actions

You can enable or disable the policy from generating Findings. 

  • Enabled - When you enable a policy, Findings will be detected upon the next policy evaluation. Actions are only available when the policy is Enabled.

  • Disabled - When you disable a policy, any Findings that exist will be suppressed from view and cannot have actions taken. If a previous Finding is in a non-closed state, the policy will still evaluate the condition and close the Finding if it is resolved in the source system, but new Findings will not be detected. Actions will not trigger when a policy is Disabled. If the policy is subsequently re-enabled and if the conflicting access is still found, the Finding will be reopened.  

You can automate actions for a specific policy, so that once a Finding is detected, those actions will automatically be taken.  

  • Send Email - Choose this option to automatically send an email of the Findings discovered to the Application Business Owner, Technical Owner or other users to follow-up accordingly.

  • Create Ticket - Choose this option to automatically create a ticket in your ticketing system (as configured in your Zilla tenant Settings). You can choose to create a single ticket for each Finding as well as group all the Findings into one ticket for each application. Note: This option is only available if you have configured an email address for your ticketing system.

  • Custom Actions – Such as Slack, MSTeams, Email Distribution List, and WebHooks will be available if configured for your Zilla tenant. See Custom Actions for more information.

Segregation of Duties Findings & Taking Action

When SOD policies are evaluated against the data that Zilla knows about, if a conflicting access condition is found, a Finding is generated. Findings can be reviewed, and manual actions can be taken to take the necessary steps to correct the underlying issue in the source applications. Upon the next synchronization, Zilla will evaluate the policies and determine if the Finding has been resolved, and if so, will mark it as Closed. Otherwise, the Finding will remain in its current state.

You can quickly view the associated Findings by Policy when clicking on the “Findings” menu item in the left-hand navigation, then clicking on the policy that you wish to view more detailed information about the individual Findings.

To view even more detail of the SOD Finding, including which permissions are in conflict, click on the Finding Status (where you can also take immediate action if the Finding is not closed).

Segregation of Duties Findings in an Access Review

When an Access Review campaign is created and applications are added, if there are open SOD Findings, they are included in the Access Review data. They appear as flagged items to provide the person reviewing the access additional context that an SOD Finding is present. This is to help the reviewer understand more information about the Policy, User and Permissions that are in conflict that generated the Finding.  

A reviewer can hover over the flag number (as multiple findings can exist against the permission) to view the policy that the SOD Finding was generated from. By clicking the flag number, the reviewer can view more detailed information about the Finding, such as: Policy Information, User Details and Conflicting Access that caused the Finding.

Comments can also be enforced when Maintaining a permission that has an SOD Finding, this is configurable in the Access Review Campaign Settings.

 

Having trouble? Please contact support@zillasecurity.com