Control access to 1P cases and alerts

Supported in:

Google secops

Note: This feature is covered by Pre-GA Offerings Terms of the Google Security Operations Service Specific Terms. Pre-GA features might have limited support, and changes to pre-GA features might not be compatible with other pre-GA versions. For more information, see the Google SecOps Technical Support Service guidelines and the Google SecOps Service Specific Terms.

This guide is for Google SecOps administrators and security analysts who want to control access to first-party (1P) cases and alerts using Data Role-Based Access Control (RBAC). It explains how to configure data access scopes in the SIEM side of the platform and map them to SOAR environments so that users can view only alerts and cases derived from data that they are authorized to access. By following this method, you can enforce data governance policies and enhance security. Successful completion allows organizations to restrict data visibility based on roles and responsibilities, improving compliance and reducing data exposure risk.

Key terminology

The following terms are used throughout this guide to describe Data RBAC concepts and components.

• First-party (1P) alerts: Detections generated by the Google SecOps SIEM detection engine, such as rules, threat intelligence matches, or security analytics. When these SIEM detections are ingested into the SOAR component using the Google SecOps connector, they form 1P alerts and are grouped into 1P cases.
• Third-party (3P) alerts: Alerts ingested directly into the SOAR component from external security tools (for example, third-party firewalls or endpoint detection agents) using separate SOAR integrations. These alerts bypass the SIEM detection engine and are not subject to SIEM data access scopes.

For 1P alerts, Google SecOps propagates the associated data scopes of underlying events to the SOAR component. This propagation lets analysts view alerts and the associated cases only if they have access to the data scopes of underlying events. For example, a finance user could be given access to the finance data ingested into Google SecOps but not the customer contact data. The finance user can see only the alerts and cases associated with the finance data, and cannot see any alerts or cases associated with the customer contact data.

Before you begin

Before configuring data RBAC for 1P cases and alerts, make sure the following requirements are met:

• Your Google SecOps instance must be unified (SIEM and SOAR enabled).
• Multi-instance SIEM behavior: If you have multiple SIEM instances connected to a single SOAR instance, scope propagation and enforcement only apply to the Primary SIEM instance. Scopes from secondary SIEM instances are ignored on the SOAR side, and those alerts are visible to any user with access to their assigned environment in SOAR.
• Chronicle Connector: The Chronicle connector that connects the SIEM component to the SOAR component uses the modern Chronicle API. Make sure the connector is upgraded from legacy Backstory API to Chronicle API before enabling this feature. For more details, see Upgrade to the Chronicle API.

Enable Data RBAC for 1P alerts and cases

Google SecOps administrators (Chronicle API Admin role within Google Cloud IAM) can enable Data RBAC for 1P alerts and cases in their instance. There are two scenarios:

Scenario A: SIEM data access is already enforced

If Data Access controls are already active in the SIEM component, follow these steps to extend enforcement to 1P alerts and cases in the SOAR component:

1. Sign in to Google SecOps.
2. Verify that your scopes are correctly configured in SIEM Settings > Data Access.
3. Assign data scopes to users in the Google Cloud console using Google Cloud IAM.
4. In Google SecOps, go to SIEM Settings > Data Access and click Enable Data Access in SOAR.
5. Map your SIEM scopes to SOAR environments as described in Map scopes to environments.

Data Access is now enforced for 1P alerts and cases in the SOAR component. This applies to all new alerts and cases, as well as existing ones created after SIEM Data Access was initially enforced.

Scenario B: SIEM data access is NOT yet enforced

If you have not yet enabled Data Access controls in SIEM, enforcement will be enabled for SIEM and SOAR simultaneously.

1. Sign in to Google SecOps.
2. Verify that your scopes are correctly configured in SIEM Settings > Data Access.
3. Assign data scopes to users in the Google Cloud console using Google Cloud IAM.
4. In Google SecOps, go to SIEM Settings > Data Access and click Enforce Data Access.
5. Map your SIEM scopes to SOAR environments as described in Map scopes to environments.

Data Access is now enforced in the SIEM component and for new 1P alerts and cases in the SOAR component.

Map scopes to environments

To link SIEM data scopes with SOAR, map your SIEM Data Access scopes to SOAR environments.

1. Go to SOAR Settings > Environments to access the environment configuration page.
2. Select an existing environment to modify or click Add Environment.
3. Associate scopes by linking SIEM scope(s) to this environment.
   • Locate the Data access scopes field and select the required SIEM scope(s).
   • Mapping rules:
     • A scope can only be mapped to one environment.
     • Multiple scopes can be mapped to a single environment.
4. Click Save to apply the scope-to-environment mapping.

Environment fallback mapping

When scope-to-environment mapping is configured, SIEM alerts with a mapped scope are automatically assigned to the associated SOAR environment. This overrides the environment settings in the Chronicle connector.

If a SIEM alert is unscoped (global) or its scope is not mapped to an environment, it is routed to the fallback environment. The fallback environment is defined by the Environment or Environment Field Name setting in the Chronicle connector.

Note: Changes to scope-to-environment mappings or initial enablement can take up to 30 seconds to propagate.

Understand access evaluation

This section describes how Google SecOps evaluates user access to cases and alerts based on assigned scopes and environments. To view a 1P case or alert, a user must satisfy both environment and scope permissions.

Scope propagation logic

• Alert scope: An ingested alert carries the data access scope assigned to it by Google SecOps SIEM detection rules.
• Case scope: A case automatically inherits the union of all scopes from its associated alerts. For example, if a case groups Alert 1 (Scope A) and Alert 2 (Scope B), the case inherits both Scope A and Scope B.

Access rules

To access a resource (case or alert), a user must have:

1. Access to the SOAR environment assigned to the resource.
2. Access to all data access scopes assigned to the resource.

Evaluation scenarios

The following table shows how user access is evaluated under different scenarios:

Case alerts	Case scopes	User-assigned scopes	User access level	Access granted to case and associated alerts?	Rationale
Alert 1 (Scope 1)	Scope 1	Scope 1	Scoped user	Yes	User has access to the single scope assigned to the case.
Alert 1 (Scope 1) and Alert 2 (Scope 2)	Scope 1 and Scope 2	Scope 1	Scoped user	No	User is missing Scope 2; they must have access to all scopes assigned to the case.
Alert 1 (Scope 1) and Alert 2 (Scope 2)	Scope 1 and Scope 2	Scope 1 and Scope 2	Scoped user	Yes	User has access to all scopes assigned to the case.
Alert 1 (Scope 1) and Alert 2 (Scope 2)	Scope 1 and Scope 2	Global	Global user	Yes	Global users bypass scope filtering and can see all cases.
Alert 1 (Global scope)	Global	Global	Global user	Yes	Global users bypass scope filtering and can see all cases cases.
Alert 1 (Scope 1) and Alert 2 (Global scope)	Global	Scope 1	Scoped user	No	Global-scoped cases are restricted to global users.
Alert 1 (Scope 1) and Alert 2 (Global scope)	Global	Global	Global user	Yes	Global users bypass scope filtering and can see all cases.
Alert 1 (Global scope)	Global	Scope 1	Scoped user	No	Global-scoped cases are restricted to global users.

Case grouping and entity scoping rules

• Grouping bounded by environment: Alerts can only be grouped into a single case if their mapped scopes route them to the same environment.
• Scope accumulation: When alerts with different scopes map to the same environment and group into a case, the case inherits all of those scopes.
• Impact of unscoped alerts: If an unscoped alert groups with a scoped alert in the fallback environment, the case inherits the global scope, making it visible only to global users.
• Unique entities scoping: A unique entity inherits the scopes of all alerts in which it appears.
• Involved entities scoping: Involved entities inherit only their parent alert's scope.

Modify scope-to-environment mappings

When you change or remove a scope mapping, the impact depends on whether the alerts and cases are new or existing.

• Move a scope: Changing a scope's mapping from Environment A to Environment B:
  • New alerts and cases: Routed to Environment B.
  • Existing alerts and cases: Remain in Environment A. Users can access them if they have permissions for both Environment A and the assigned scope.
• Remove a scope mapping: Unmapping a scope from an environment:
  • New alerts and cases: Routed to the fallback environment. Visible only to global users and users with access to the fallback environment.
  • Existing alerts and cases: Remain in their original environment but become visible only to global users because the scope is no longer mapped.

Handle manual and overflow cases

This section describes how to manage cases that are created manually or that result from alert overflow.

Create manual cases

1. In the Cases tab, click Create Manual Case.
2. Select the target Environment.
3. Select a Data access scope. The list displays scopes that are both mapped to the environment and assigned to your user account.
   • If no overlapping scopes exist, the list is empty and you cannot submit the case.
   • Global users can select any scope mapped to the environment.
4. Enter the case details and click Submit. The case and its manual alert inherit the selected scope.

Overflow cases

Overflow cases group alerts across multiple scopes without following the shared entity model. They are assigned the global scope and are visible only to global users.

Find scopes in the Cases page

You can view the data access scopes assigned to a case in several locations within the Google SecOps interface.

Case header

Assigned scopes appear as read-only labels next to the Environment field. Hold the pointer over the area to see the full list.

List cases table

You can also view the scopes directly from your List cases table:

• A Data access scopes column is available in the List cases table.
• This column displays the scopes assigned to the case (comma-separated if multiple).
• You can filter your queue by typing scope name(s) into the column's text filter.

Handle scope deletions

This section explains what happens to existing cases and alerts when a data access scope is deleted in the SIEM side of the platform.

If an administrator deletes a data access scope in SIEM Settings > Data Access:

1. The scope is automatically unmapped from any SOAR environment.
2. Access Enforcement: Since the scope is deleted from the SIEM component and Cloud IAM, only global users (or users who still hold the cached token claim) will be able to access these historical cases and alerts.

Troubleshooting

This section outlines performance expectations and provides self-service fixes for common deployment issues.

Latency and limits

Changes to scope-to-environment mappings or initial enablement can take up to 30 seconds to propagate.

Validation and testing

To validate your configuration, test access to cases and alerts using user accounts with different scope and environment permissions. Confirm that users can only see the data for which they are authorized.

Need more help? Get answers from Community members and Google SecOps professionals.