Learn about Scope-Based Access Control (SBAC) and how to assign users to specific scoping areas in your organization.
Prerequisite
Configuring user scopes in Cortex XDR Access Management requires View/Edit RBAC permissions for Access Management (under Configurations). Account Admin and Instance Administrator roles are granted this permission by default. For more information, see Predefined user roles in Set up users, groups, and roles.
By default, Enable Scope Based Access Control is disabled in Settings → Configurations → General → Server Settings, and granular scoping is not enforced. Before enabling SBAC, we recommend that you first ensure that the users, user groups, and API Keys defined in Cortex XDR are granted the required access by assigning the relevant scopes.
Review the following topics:
Cortex XDR enables you to use Scope-Based Access Control (SBAC) in combination with Role-Based Access Control (RBAC) to define precise access controls according to your organization's security policies. While RBAC defines what a role can access and the actions that can be performed, SBAC determines the specific data and content displayed when accessing these areas and performing those actions.
Users with Access Management permission apply scopes to limit the data and content that users can be granted access to in Cortex XDR, which are divided into different scoping areas. The scoping areas include Assets, Cases and Issues, and Endpoints, which can be applied as relevant to the enforcement area or entity. For example, an Investigator role might have access to asset information based on the RBAC permissions, but the SBAC granular scoping configuration could limit that investigator's view and control to only assets within a particular scoping area. This hybrid approach ensures scalability and granular control, significantly strengthening system security by ensuring only authorized users are granted access to the relevant data that the user requires for their designated role.
Granular scoping for all scoping areas is configured in users, user groups, or API Keys according to the designated user role. Users are granted granular scoping access based on the user role assigned to them either in a user group or directly.
Before you begin setting Scope-Based Access Control (SBAC) granular scoping, consider the following information:
SBAC is disabled by default, which means that users have access to all content and data in the areas they have access to according to the RBAC permissions defined in their role.
To best address Cases that span across all scopes, we recommend that there always be designated users with full access to all cases, issues, assets, and findings.
Policies and playbook execution can affect items outside the user’s scope, even though scoped users can’t view them. As a result, we recommend that users who write policies be granted access to all relevant policy assets, so they can review the effects of the policies.
Some areas and features in Cortex XDR do not comply with SBAC. In these cases, use RBAC permissions to restrict access. For more information, see Functional areas that respect and don't respect SBAC.
Respecting SBAC has some performance overhead when opening the Cases, Issues, Findings, and Assets tables, which can take more time.
In Reports, SBAC applies when a report is manually generated, not when it is accessed in any other way. Scheduled reports do not run in any user context and are not subject to SBAC.
For users who upgraded from a previous version of Cortex XDR to the current version, see the What's New in Cortex XDR 5.x Guide for specific changes that you should know about.
Scoping areas
User Groups, Users, and API Keys can be scoped according to the following scoping areas:
Assets: Provides access to the assets associated with asset groups, and enables you to access their related cases, issues, and findings. When using asset groups, you can limit access based only on this list of attributes: Asset Class, Category, Provider, Region, Organization, Account Name, Realm, Business Application Names, Kubernetes Cluster, Kubernetes Namespace, Code Repository, and Asset Tags.
Note
Use the existing Realm attribute whenever you need to scope based on the Account ID.
When you create or edit an Asset Group, the changes are applied immediately to new assets and to existing assets that have been updated. Yet, it can take a few hours for the changes to appear on existing assets that have not been updated. For more information, see Asset groups.
Cases and Issues: Provides access to domains to view their related cases and issues.
Endpoints: Applies scoping on an endpoint as an entity and provides access to Endpoint Groups and Endpoint Tags to view their related agent management and enterprise policies.
Note
This configuration can impact the visibility of the related Security domain in the Cases and Issues scope area, but with not affect asset visibility.
Scoping Behaviors
When applicable, all conditions must be met to apply the scope configuration. For example, an issue with an affected asset is accessible only if the asset is in scope and the issue's domain is in scope. Similarly, a Case with multiple issues, where some have affected assets and others have affected endpoints, will be inaccessible if the Endpoint condition is set to 'No Endpoints,' even if the affected assets satisfy the Assets condition.
If only a subset of affected assets, endpoints, or issue domains are within a user's scope, the user can still view the full list of all items within a Case they have access to. While items outside of their scope remain visible in the list, the user cannot access further details or open the specific cards for those out-of-scope assets, endpoints, or issues.
Cases and Issues of deleted assets do not have affected assets and so are not affected by asset-led SBAC or Endpoints.
The behavior of cases and issues with affected endpoints depends on the Endpoint Scoping mode.
XQL queries that use the
cases,issues,findings, andasset_inventorydatasets respect only the Assets scoping area configurations.
It is important to review both the functional areas and features in Cortex XDR that are respected and not fully respected so you can decide what actions to take in your tenant.
Scope-Based Access Control (SBAC) applies to the following functional areas in Cortex XDR:
Important
Some areas and features in Cortex XDR do not respect SBAC. In these cases, use RBAC permissions to restrict access.
Functional Area | Description | Related scoping area |
|---|---|---|
Cases, Issues, Findings, and Assets tables | View and manage cases, issues, findings, and assets, and take actions in these tables. |
|
Dashboard and Reports | Scoping takes place only on the following:
NoteXQL-based dashboard widgets may require a few hours to initially reflect changes to the list or definitions of asset groups used for scoping. To view the most current data immediately, refresh the dashboard or its XQL widgets. |
|
Public APIs | Public APIs that access Cases, Issues, Findings, and Assets information respect Scope-Based Access Control (SBAC). |
|
Cortex Query Language (XQL) | When using XQL with
| Assets |
Endpoint Administration table | View endpoints and take actions on endpoints. | Endpoints |
Policy Management | Create and edit Prevention policies and profiles, Extension policies and profiles, and global and device Exceptions that are within the scope of the user. | Endpoints |
Action Center | View and take actions only on endpoints that are within the scope of the user. | Endpoints |
Identity Security | View and manage identity assets, permissions, and issues that are within the scope of the user. For more information, see Manage RBAC and SBAC in Cortex Cloud Identity Security.Manage RBAC and SBAC in Cortex Cloud Identity Security |
|
Cloud Workload Policies | View Cloud Workload Policies when user access is scoped to any of the available options: All assets, No assets, or Select asset groups. When no SBAC restriction is applied, the user’s access is determined solely by their RBAC permissions. For more information, see Cloud Workload Policies and Rules. | Assets |
Graph Search | Safely explore your environment in Graph Search with precise permission management. Assign users to User Groups and Asset Groups, ensuring they only see authorized graph nodes and relationships. | Assets |
Ensure that you review the points below that explain the main functional areas with limitations with respecting SBAC, so you can decide how to handle this in your tenant. A suggested action is provided when applicable.
Access to datasets: Access to the
alertsandincidentsdatasets do not support SBAC. As a result, consider limiting users from accessing these datasets by excluding access to the datasets mentioned above using Dataset Views, and only enabling access tocasesandissuesdatasets that respect SBAC.Automation Rules: Automation rules are executed using the full system scope. Users authorized to edit or run automation rules can configure the system to run scripts or playbooks that can interact with data across the entire system. It is recommended to allow users with full access to all assets to create and edit automation rules.
Command Centers: Aggregate numbers in Command Centers can also sum up data that is not in the user scope. When pivoting from Command Centers to the Cases, Issues, Findings, and Assets tables, these tables do respect SBAC. We recommend limiting the users who access Command Centers, and these users should be granted a broader scope. For all other users, disable access in RBAC settings (Dashboards & Reports → Command Center Dashboards).
Host Inventory
We recommend disabling access in RBAC settings (Investigation & Response → Search → Host Insights).
Timeline widget
As a workaround, you can disable access through RBAC permissions by disabling Dashboards (Dashboards & Reports → Dashboards).
Notification Center
Agent Installation widget: This widget is not available for scoped users.
Drop-downs of cases and issues domains: Drop-downs of these domains display all domains.
Asset Group visibility in filters: Similar to domains, all Asset Groups are available for selection in filters across Cortex XDR, regardless of which specific Asset Groups are used for scoping a user. While SBAC limits the data (assets) a user can view, it does not restrict the visibility of the names of the Asset Groups themselves in filter drop-down menus.
KSPM dashboard: Users can access all information on the dashboard when their user access is scoped to view All assets or assigned to the Instance Administrator role. Otherwise, users with granular scoping set to No assets or Select asset groups will have limited access to the dashboard. For more information on the KSPM dashboard, see Predefined dashboards.
Cloud Workload Policies: Users with SBAC granular scoping (in addition to the RBAC permissions required for Cloud Workload Policies) can only view Cloud Workload Policies when their access is scoped to any of the available options: All assets, No assets, or Select asset groups. When no SBAC restriction is applied, the user’s access is determined solely by their RBAC permissions. As a result, if you want users to be able to edit and modify Cloud Workload Policies, use the RBAC permissions. For more information on Cloud Workload Policies, see Cloud Workload Policies and Rules.
Granular scoping is configured in users, user groups, or API keys, and applied to the user roles assigned. Users are then granted granular scoping access according to the user roles assigned to them in a user group or directly. The instructions below explain how to configure granular scoping according to Palo Alto Networks best practices.
Granular scoping is disabled and not enforced in Cortex XDR by default. Before enabling SBAC, we recommend that an administrator or a user with Access Management permissions first ensure that the users, user groups, and API Keys defined in Cortex XDR are granted the required access by assigning the relevant scopes. This user can then assign a scoping area to a Cortex XDR user (non-administrator), so the non-administrator user can manage only the specific scoping areas that are predefined within that scope.
Any changes made to the granular scoping of a user, user group, or API key are recorded on the Management Audit Logs page (Settings → Management Audit Logs). These events are categorized with the Type set to Permissions and the Subtype set to Scope Edit.
Note
Make sure to assign the required default granular scoping for users. This depends on the structure and divisions within your organization and the particular purpose of each organizational unit to which scoped users belong.
Ensure that you have the necessary administrator-level permissions.
Verify that the users, user groups, and API keys defined in Cortex XDR are assigned the relevant scopes.
To verify the granular scoping of a user, select Settings → Configurations → Access Management → Users, right-click the user name, and select Edit User Permissions.
To verify the granular scoping of a user group, select Settings → Configurations → Access Management → User Groups, right-click the user group, and select Edit Group.
To verify the granular scoping of an API key, select Settings → Configurations → Integrations → API Keys, right-click the API key, and select Edit.
In the Scope tab, expand the scoping areas to review the current granular scoping definitions by clicking the chevron icon (>) beside the scoping area title, and make any changes required. The following table explains the options available to configure:
Important
Before configuring, ensure that you review the Understand scoping section.
Scoping Area
Granular Scoping Configurations
Assets
Set the Scope by selecting one of the following:
No assets: No asset is accessible.
All assets: Defines access to all assets.
Select asset groups: Defines access to the specific assets associated with the Asset Groups selected, and to view all their related cases, issues, and findings for these specific assets and Asset Groups. Under Select asset groups, define the specific asset groups that you want to grant access. Only Asset Groups relevant for scoping are listed, which are asset groups that are using only the asset attributes listed in Manage user scope (under Understand scoping → Scoping Areas → Assets).
The scoping of assets also affects the scoping of cases, issues, and findings.
Note
Visibility of Security domain Issues that refer to assets with agents is controlled by the Endpoints scoping configuration.
Cases and Issues
Set the Scope by selecting one of the following:
No cases and issues: Defines access to no cases and issues.
All cases and issues: Defines access to all cases and issues. Users can view cases or issues referencing assets within their scope. Use the Assets section to define which assets are in scope.
Select domains: Defines access to the domains selected to view their related cases and issues. Under Select domains, define the specific domains that you want to grant access.
Users can only view cases or issues referencing assets and endpoints within their scope. Use the Assets section to define which assets are in scope.
When selecting All cases and issues or Select domains, you can separately configure access to issues and cases that lack an asset reference or where the referenced asset is not in All Assets and All Endpoints inventories. To provide access, select the Allow access to cases and issues that are not referencing known assets or endpoints checkbox. Once selected, you can specifically control which users have access to issues and cases that lack Affected Assets (as seen in the issue’s panel) and Assets (as seen in the case's panel), or where the listed assets are not part of the Asset or Endpoint inventories. When the assets listed are not part of the inventories, the asset string is typically non-clickable. In some cases, such as for identity-related issues, assets may open a dedicated User Risk View, which differs from the standard inventories panels. In the Issues and Cases tables, such items can be identified by empty values in the following columns: Asset IDs, Target Agent Identifier, and Source Agent Identifier.
Endpoints
Set the Scope by selecting one of the following:
No endpoints: Defines access to no endpoints with no ability to view their related agent management and enterprise policies.
All endpoints: Defines access to all endpoints with the ability to view their related agent management and enterprise policies. This configuration can impact the visibility of related Security domain Cases and Issues, but will not affect asset visibility.
Select specific (at least one required): Defines specific access to all endpoint groups by selecting Endpoint Groups or all endpoint tags by selecting Endpoint Tags to view their related agent management and enterprise policies. This configuration can impact the visibility of related Security domain Cases and Issues, but will not affect asset visibility.
Click Save.
Repeat steps 2 to 4 until you have configured all users, user groups, and API keys with the correct granular scoping access.
Enable granular scoping in Cortex XDR.
Select Settings → Configurations → General → Server Settings, and select the Enable Scope Based Access Control toggle.
(Optional) You can select the Endpoint Scoping Mode, which is defined per tenant:
Permissive: Enables users with at least one scope tag to access the relevant entity with that same tag.
Restrictive: Users must have all the scoped tags that are tagged within the relevant entity of the system.
Click Save.
When you are finished, all the users in Cortex XDR are now able to use Cortex XDR only within the granular scoping granted according to their assigned user roles.