Segregation of Duties (SoD)

Implement SoD controls by defining toxic combinations of access.

Overview

Segregation of Duties (SoD) violations occur when users can perform a combination of potentially dangerous actions. For example, a user who can modify employee bank accounts AND process payroll can redirect employee wages, potentially enabling theft or fraud. SoD violations are sometimes referred to as “toxic combinations” due to the significant security risk if an identity is compromised.

Other possible violations include:

• Finance and Accounting: Approve vendor payments AND create new vendors in the system, or initiate AND approve payments.

• IT Admin: Add user accounts and manage access permissions, AND review and delete system logs.

• Sales and Revenue: Create, approve, and modify customer contracts AND record new sales transactions.

Segregation of duties violations can occur across business processes, roles, and systems. Effective SoD controls will divide privileged actions across users and teams, mitigating the risks of fraud and error by implementing automated checks and balances.

Veza Capabilities for Segregation of Duties

• Integrations: 250+ supported systems, including any identity provider, custom app, or other data source added to Veza.

• Out-of-the-box queries: Built-in queries defining SoD rules for popular integrations, with more planned.

• Multi-platform segregation of duties: Veza allows users to write SoD policies that encompass multiple platforms, e.g., NetSuite and Coupa. Queries for SoD controls can be:

  • Uni-dimensional: Controls for a single application. For example, a user with the “approver” role cannot also be a “submitter” on Zendesk, Coupa, or another critical ERP application in the SOX scope.

  • Multi-dimensional: Controls spanning applications. For example, an “approver” in Coupa cannot also be a “submitter” in Zendesk.

• Ability to investigate violations: After identifying a user in violation of a SoD policy, platform owners can get more information about the user, such as designation, manager, department, and potential access to other apps. Veza provides powerful tools to understand issues without leaving the platform or relying on custom tools.

• Insight into conflicting access: Remediating an SoD violation can require identifying the precise roles or permissions in conflict, potentially from hundreds of roles and permissions assigned to the user. Veza’s authorization model shows access at the granular permissions level to enable efficient action on the exact permission causing the violation.

Implementing SoD controls with Veza

Veza provides both out-of-the-box queries for detecting SoD violations and a flexible interface for defining your own. These queries support:

• Using Veza’s search tools to investigate risky users, with visibility into the organization, department, last login, access to other apps, and historical access of users in violation.

• Easy-to-build and customizable dashboards for tracking SoD violations and resolutions, monitoring progress, and reporting to stakeholders.

• Continuous monitoring and alerting, with workflows for ServiceNow, Jira, or any target system using built-in orchestration actions and webhooks.

To use Veza for SoD controls, we recommend reviewing the built-in saved queries for the integrations added to Veza, then using our SoD tool to add more policies into Veza depending on need.

Defining SoD Violations

Use the Segregation of Duties page to define a violation, then click Run to view the current results or Open in Query Builder for more details. Edit and Save the violation to assign it a risk level, create a rule, or add it to reports.

The Segregation of Duties (SoD) query builder.

To define an SoD violation:

1. Go to Access Intelligence > Segregation of Duties.

2. From the dropdown menu at the top, select the user type the SoD violation applies to, for example, Snowflake Local User.

3. Use the query builder interface to specify the combinations of permissions that constitute a violation.

   For each condition, select a destination entity type, and optionally a specific entity of that type. Then, specify the permissions that will trigger a violation:

   • Add conditions by clicking the + icon next to the condition row.

   • Choose the entity name, permission type, and specific permissions (e.g., “Data Delete”, “ALTER”).

   • Expand the dropdown to search for a specific entity name, or leave the field blank to specify all entities of the chosen type.

   • Group different levels of access using logical operators AND or OR to define toxic combinations.

4. Review the query logic: The query output section below the conditions describes the logic for identifying the SoD violation. Refer to this description to verify that the query correctly represents the rule’s intent.

5. Click Run to preview the potential violations based on current graph data. Review the results shown in the records table to ensure the rule captures the correct scenarios, and adjust if necessary.

6. Customize the display output for more information about the results. Expand the Columns menu to show or hide attributes such as Identity Type or Risk Score.

7. Click Edit and Save to finalize your changes. While saving the query, you can:

   • Give it a name, description, label, and risk level, and set the visibility.

   • Add rules by defining conditions, and actions to trigger alerts and orchestration actions at different levels of severity.

   • Add the query to reports, and choose the report sections the query will appear in.

   • Schedule export of the results to an integrated Snowflake database.

Example SoD Violations

Here is a simple SoD violation, requiring that Personal Accounts in a GitHub organization can’t be assigned to either the developers or qa team, and also be admins:

Segregation of Duties for GitHub.

Here is a more complex query involving Okta User assignments to applications, and their access to data in Snowflake. In it, users assigned to Salesforce and ServiceNow can’t also have permissions on the ACCESS schema in Snowflake, or any write permission on the AUDITLOG_RESULTS table:

Multi-dimensional Segregation of Duties for several applications.

Viewing and Editing SoD Violations

Veza offers out-of-the-box SoD queries, available as a starting point as soon as you integrate the target systems. These queries are provided for individual platforms like Active Directory and Okta.

To manage and edit Segregation of Duties queries:

1. On the main Veza navigation, go to Access Visibility > Saved Queries.

2. On the Query View tab, search for the SoD query. To find built-in queries, filter by the Segregation of Duty label.

3. Expand the action menu (⠇) to the right of each row to choose an action:

   

   Saved query actions for an SoD query.

   • View query details: See configured rules, alerts, reports, and an overview of the results.

   • Open in Analysis: Open the query to edit conditions on the Segregation of Duties (SoD) page.

   • Open in Query Builder: Open in QB to add filters, for example, to filter out system users that are expected and cannot be remediated.

   • View Trend Chart: Save a visualization of the changes over a selected time.

   • Open in Graph: Show the user in graph search, including the full range of authorization relationships governing their access.

   • Clone Query: Make a copy of the SoD violation for further editing.

   • Delete Query: Delete the query.

   • Manage Rules: Configure rules to trigger alerts and run orchestration actions.

   • Schedule Export (Early Access): Export the current results from Veza to an external database.

   • Set Risk Level: Set whether query results are considered low, medium, high, or critical risks.

Viewing SoD Query Results

By default, opening an SoD violation in Query Builder will list all users in the results:

By default, SoD queries return a list of source entities.

You can alter the query to return a row for each relationship. When Show [Destination Entities] is enabled, the results include the permissions and resources triggering the SoD violation:

After enabling destinations, the results are source-destination pairs.

When summary entities are enabled, you can get additional visibility into hierarchical groups, roles, or other access controls that enable the access described in a row. See Intermediate Entities for more details.

Enabling summary entities to show intermediate roles.

Access Reviews for SoD Violations

Review access for users that are in the results of an SoD query by creating a configuration using a saved query:

1. Go to Access Reviews > Configurations. Click New Configuration.

2. Give the configuration a name.

3. In the Review Scope section, choose Saved Queries.

4. Type to search for the saved query and select it.

5. Add optional Email Notifications and Reminders and Orchestration Actions.

6. Click Create Configuration to save the review.

Reviews will include a row for each user and destination pair that matches an SoD condition. Reject the row that should be removed, and approve the appropriate role. The rejected row can be “Marked as Fixed” after remediation:

Reviewing access for an SoD query.

Remediating SoD Risks

Veza can automatically open ServiceNow or Jira tickets based on the conditions you specify. In addition to natively-supported targets for orchestration actions, you can integrate with most modern API-based systems via webhooks. Rules for SoD violations can trigger different actions at different levels of severity.

See Alert Rules for more information about enabling conditional actions based on the severity of the violation.