Impact of data RBAC on Google SecOps features
Data role-based access control (data RBAC) is a security model that restricts user access to data based on individual user roles within an organization. After data RBAC is configured in an environment, you start seeing filtered data in Google Security Operations features. Data RBAC controls user access according to their assigned scopes and ensures that users can access only authorized information. This page gives an overview of how data RBAC impacts each Google SecOps feature.
To understand how data RBAC works, see Overview of Data RBAC.
Search
The data that is returned in search results is based on the user's data access scopes. Users can only see results from data that matches the scopes that are assigned to them. If users have more than one assigned scope, then the search is executed across the combined data of all the authorized scopes. Data belonging to scopes that the user doesn't have access to does not appear in search results.
Rules
Rules are detection mechanisms that analyze the ingested data and help identify potential security threats. You can view and manage rules that are bound to a data scope that you have access to.
A rule can be either global (accessible by all users) or bound to a single scope. The rule operates on the data that matches the scope's definition. Data outside the scope is not considered.
Alerts generation is also limited to events that match the rule's scope. Rules that are not bound to any scope run in the global scope and are applied to all data. When data RBAC is enabled on an instance, all existing rules are automatically converted to global scope rules.
The scope that is associated with a rule determines how global and scoped users can interact with it. The access permissions are summarized in the following table:
| Action | Global user | Scoped user |
|---|---|---|
| Can view scoped rules | Yes | Yes (only if the rule's scope is within the user's assigned scopes)
For example, a user with scopes A and B can see a rule with scope A, but not a rule with scope C. |
| Can view global rules | Yes | No |
| Can create and update scoped rules | Yes | Yes (only if the rule's scope is within the user's assigned scopes)
For example, a user with scopes A and B can create a rule with scope A, but not a rule with scope C. |
| Can create and update global rules | Yes | No |
Detections
Detections are alerts that signify potential security threats. Detections are triggered by custom rules, which are created by your security team for your Google SecOps environment.
Detections are generated when incoming security data matches the criteria defined in a rule. Users can only see detections that originate from rules associated with their assigned scopes. For example, a security analyst with the finance data scope only sees detections generated by rules assigned to the finance data scope, and doesn't see detections from any other rules.
The actions that a user can take on a detection (for example, marking a detection as resolved) are also limited to the scope in which the detection occurred.
Curated detections
Detections are triggered by custom rules that are created by your security team whereas curated detections are triggered by rules provided by the Google Cloud Threat Intelligence (GCTI) team. As part of the curated detections, GCTI provides and manages a set of YARA-L rules to help you identify common security threats within your Google SecOps environment. For more information, see Use curated detections to identify threats.
Curated detections don't support data RBAC. Only users with global scope can access curated detections.
Reference lists
Reference lists are collections of values that are used for matching and filtering data in UDM Search and detection rules. Assigning scopes to a reference list (scoped list) restricts its access to specific users and resources such as rules and UDM search. A reference list that has no scope assigned is called an unscoped list.
Access permissions for users in reference lists
The scopes that are associated with a reference list determine how global and scoped users can interact with it. The access permissions are summarized in the following table:
| Action | Global user | Scoped user |
|---|---|---|
| Can create scoped list | Yes | Yes (with scopes that match their assigned scopes or are a subset of their assigned scopes)
For example, scoped user with scopes A and B can create a reference list with scope A or with scopes A and B, but not with scopes A, B, and C. |
| Can create unscoped list | Yes | No |
| Can update scoped list | Yes | Yes (with scopes that match their assigned scopes or are a subset of their assigned scopes)
For example, a user with scopes A and B can modify a reference list with scope A or with scopes A and B, but not a reference list with scopes A, B, and C. |
| Can update unscoped list | Yes | No |
| Can update scoped list to unscoped | Yes | No |
| Can view and use scoped list | Yes | Yes (if there is at least one matching scope between the user and the reference list)
For example, a user with scopes A and B can use a reference list with scopes A and B, but not a reference list with scopes C and D. |
| Can view and use unscoped list | Yes | Yes |
| Can run UDM search and dashboard queries with unscoped reference lists | Yes | Yes |
| Can run UDM search and dashboard queries with scoped reference lists | Yes | Yes (if there is at least one matching scope between the user and the reference list)
For example, a user with scope A can run UDM search queries with reference lists with scopes A, B, and C, but not with reference lists with scopes B and C. |
Access permissions for rules in reference lists
A scoped rule can use a reference list if there is at least one matching scope between the rule and the reference list. For example, a rule with scope A can use a reference list with scopes A, B, and C, but not a reference list with scopes B and C.
A rule with global scope can use any reference list.
Feeds and forwarders
Data RBAC doesn't directly affect the feed and forwarder execution. However, during their configuration, users can assign the default labels (log type, namespace, or ingestion labels) to the incoming data. Data RBAC is then applied to features using this labeled data.
Looker dashboards
Looker dashboards don't support data RBAC. Access to Looker dashboards is controlled by feature RBAC.
Applied Threat Intelligence (ATI) and IOC matches
IOCs and ATI data are pieces of information that suggest a potential security threat within your environment.
ATI curated detections are triggered by rules provided by the Advanced Threat Intelligence (ATI) team. These rules use Mandiant threat intelligence to proactively identify high-priority threats. For more information, see Applied Threat Intelligence overview.
Data RBAC doesn't restrict access to IOC matches and ATI data, however, the matches are filtered based on the user's assigned scopes. Users only see matches for IOCs and ATI data that are associated with assets that are within their scopes.
User and Entity Behavior Analytics (UEBA)
The Risk Analytics for UEBA category offers prebuilt rule sets to detect potential security threats. These rule sets use machine learning to proactively trigger detections by analyzing user and entity behavior patterns. For more information, see Overview of Risk Analytics for UEBA category.
UEBA does not support data RBAC. Only users with global scope can access the risk analytics for UEBA category.
Entity details across Google SecOps
The following fields, which describe an asset or a user, appear on multiple pages in Google SecOps, such as the Entity Context panel in UDM Search. With data RBAC, the fields are available only to the users with global scope.
- First seen
- Last seen
- Prevalence
Scoped users can view the first seen and last seen data of users and assets if the first seen and last seen is calculated from data within the user's assigned scopes.