Example Separation of Duties Queries

Note: SoD queries should be based on your actual environment, configuration, and roles. These are examples and not necessarily indicative of actual access.

Veza provides a way to write SoD queries that encompass multiple platforms, e.g., rules involving both NetSuite and Coupa roles. Queries for SoD controls can be:

• Single Application: Queries within a single application. For example, a user with the “approver” role cannot also be a “submitter” on Zendesk.

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

See the following examples for queries involving different types of applications:

Oracle Fusion Cloud

In this conflict involving Oracle Fusion roles, an individual can enter a fictitious payment and reconcile the cash account, resulting in cash position manipulation:

• Source Entity Type: Oracle Fusion Cloud User

  • Related to Oracle Fusion Cloud Role: "Accounts Payable Payment Supervisor" OR "Accounts Payable Manager"

  • (AND) Has relation to Oracle Fusion Cloud Role: "Cash Manager"

Separation of duties risks in Oracle Fusion.

Workday

In this conflict, a user could modify compensation data and reconcile payroll records, potentially concealing unauthorized changes:

• Source Entity Type: Workday Account

  • Related to Workday Domain Security Policy “Access Compensation Basis” OR “Add Compensation Plans”

  • (AND) Has relation to Workday Domain Security Policy "Manage: Global Payroll Reconciliation"

Separation of duties risks in Workday.

Okta, Salesforce, and AWS

This query detects identities with access to Salesforce who can also delete critical S3 storage infrastructure:

• Source Entity Type: Okta User

  • Related to (Any) S3 Bucket with s3:DeleteBucket permission

  • (AND) Has relation to (Any) Salesforce User

Multi-platform risk for Okta, Salesforce, and AWS.

GitHub

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

• Source Entity Type: GitHub User

  • Related to GitHub Team: "developers" OR "qa"

  • (AND) Related to GitHub Team: "admins"

Separation of Duties for GitHub.

Okta, Snowflake, and ServiceNow

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:

• Source Entity Type: Okta User

  • First Condition (either):

    • Has relation to Okta App: Salesforce.com OR

    • Has relation to Okta App: ServiceNow UD

  • AND Second Condition (either):

    • Has relation to Snowflake Schema: ACCESS (Any Permissions) OR

    • Has relation to Snowflake Table: AUDITLOG_RESULTS (Metadata Write)

Multi-dimensional separation of duties.