Creating SoD Detection Queries

How to use the Separation of Duties Query Builder to create new detection queries.

Overview

Use the Separation of Duties query builder to detect SoD conflicts, and save searches to create customized SoD rulesets in Veza. The SoD query interface provides a streamlined version of the Access Intelligence Query Builder, with special support for defining SoD violations with AND and OR statements.

For each query, you will need to:

• Define the type of user the rule applies to (either an identity provider identity or a local user account).

• Identify the conflicting roles or permissions across one or more target applications by specifying each destination entity type, and the roles or permissions that represent an SoD conflict.

Click Run to view the current results or Open in Query Builder for more details. Click Edit and Save to assign a risk level, and add risk explanation and remediation details. You can optionally add rules, schedule exports, or add the query to reports while saving it.

This document includes steps for Using the SoD Query Builder. See Example SoD Queries for different types of SoD risks.

Using the SoD Query Builder

Separation of Duties queries typically search for users with relationships to two or more sets of conflicting roles/permissions – but might be defined in terms of a user's effective access to data resources, local user accounts, and/or role or group assignments. The search can include any Entity Type from integrations added to Veza.

To define a conflict, use the builder to create groups of access conditions using logical AND or OR operators. Each condition describes a relationship between the source and destination entity type:

User RELATES TO
[(Access Condition 1) OR (Access Condition 2) or (Access Condition 3)]
AND
[(Access Condition 3) OR (Access Condition 4)]
AND
(Access Condition 5)

For example:

• If a user with Role A, Role B, or Role C would create conflict if they were also assigned Role D and Role E:

  • The query conditions would be (Role A OR Role B OR Role C) AND (Role D OR Role E).

• If a user is in conflict when they can delete AWS S3 Buckets and also access Salesforce:

  • The query conditions would be (Any Salesforce User) AND (Any S3 Bucket with s3:DeleteBucket permission)

You can add many groups of conditions to the query, and each condition can apply to a different destination application.

To create an SoD query:

1. Go to the Separation of Duties page.

2. Click + New SoD Query

3. From the Select User Type dropdown menu, select the user type the SoD risk applies to, for example, Azure AD User or Snowflake Local User.

4. Use the condition builder to define the relationships that constitute a violation of separation of duties.

   For each condition, select a related entity type (e.g., Oracle Fusion Role, Workday Domain Security, S3 Bucket), and optionally a specific entity of that type (e.g., a role, permission, or local user):

   • Add conditions by clicking the + And button and + Or buttons to describe the SoD violation.

   • For each condition, choose the related Entity Type (e.g., “Workday Domain Security Policy”) and expand the Select Entity Name dropdown to search for a single entity (e.g., “Process: Expense Reports”).

     When an optional name is not provided, the condition applies to any entity of the chosen type. A condition can describe a single role assignment or table, or access to ANY roles or resources of the chosen type.

   • For some entities, such as AWS S3 Buckets or database tables, you can choose a Permission Type to filter by system-level permissions, or filter by effective permissions the user has on the resource.

5. 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.

6. Click Run to preview the potential violations based on current data.

7. Customize the display output for more information about the results. You can focus on the most important attributes by using the column selection menu to hide or show columns.

8. 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 whether it is public or private.

     1. Use the query name to briefly identify the system and risk (e.g. Oracle: Cash and Accounts Payable)

     2. Add a risk level to enable the Risk Remediation and Risk Explanation fields for additional logging and notes.

   • Add optional Alert Rules by defining conditions, and actions to trigger email notifications or Veza Actions at different levels of severity.

     • You can create Alert Rules to trigger on-demand access reviews when new conflicts are detected.

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

   • To include the query in Dashboards, add it to the “Dashboard Reports” report collection.

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

   • After saving an SoD query, you can create a 1-Step Access Review directly from the query using the Actions menu. This will create a new review using the latest results.

   • To enable recurring reviews on a schedule, save a review configuration using the SoD query builder, and Create a Schedule for the configuration.