Cortex XSIAM Documentation

Cortex XSIAM unifies detection, investigation, response, endpoint security, and cloud security in one platform.

Use this page to jump into the right docs area fast.

Use the table of contents when you know the exact page.

Use this page when you need a quick overview of the main Cortex XSIAM areas.

Learn the product

Onboard Cortex XSIAM

Configure Cortex XSIAM

Protect your environment

Detect, investigate, and respond

Cloud Security

Reference and developer docs

What is Cortex XSIAM?

Cortex XSIAM (Extended Security Intelligence and Automation Management) is an AI-driven platform designed to power the autonomous Security Operations Center (SOC). It transforms security operations by consolidating best-in-class SOC capabilities, including SIEM, XDR, SOAR, ASM, and Threat Intelligence, along with native Cloud Security (subject to license) into a single, unified platform.

By harnessing the power of Agentic AI and a centralized data foundation, Cortex XSIAM simplifies operations, stops threats at scale across both enterprise and cloud environments, and accelerates incident remediation through autonomous decision-making.

Key features

Simplify security operations with a converged platform:

• Unified Cloud and Enterprise Security

  Cortex XSIAM combines SOC capabilities, such as XDR, SOAR, ASM, and SIEM, with Cloud Posture (CSPM) and Cloud Runtime Security into a unified platform, eliminating the need to switch between cloud and security consoles.

• Broad integration

  Enables easy onboarding of diverse data sources from endpoints and firewalls to cloud workloads without extensive engineering efforts.

• Deep data stitching

  Ensures continuous collection, stitching, and normalization of raw data (including cloud telemetry), going beyond simple alerts to deliver enriched, cross-domain insights.

Stop threats at scale with AI-driven outcomes:

• Unified visibility

  Leverage out-of-the-box AI models to connect events across endpoints, identities, networks, and cloud infrastructure, delivering a holistic view of cases.

• Intelligent prioritization

  Employs issue grouping and AI-driven scoring to prioritize cases based on overall risk, correlating cloud misconfigurations (posture) with active runtime threats.

• Focus on critical threats

  Transforms low-confidence events into high-confidence cases, allowing security teams to focus efficiently on confirmed threats.

Accelerate remediation with an Agentic AI workforce:

• Cortex Agentic Assistant

  Moves beyond static playbooks by deploying autonomous AI agents that can plan, reason, and investigate complex threats, such as cloud identity theft or container breaches, without human intervention.

• Autonomous Resolution

  Automates manual tasks and complex decision-making processes, reducing Mean Time to Resolution (MTTR) by independently verifying and fixing issues.

• Pre-built Content

  Offers hundreds of pre-built content packs from Cortex Marketplace to streamline operations immediately.

• Continuous Learning

  The platform learns from analyst actions and autonomous agent outcomes, continuously refining its detection and response logic.

Security challenges addressed by Cortex XSIAM

• Data overload

  Reduces noise from high volumes of security events by using AI to filter and prioritize actionable cases.

• Fragmented security visibility

  Eliminates blind spots by unifying endpoint, network, identity, and cloud (Code-to-Cloud) data into one comprehensive detection engine.

• Slow case response

  Accelerates investigations with agentic abilities, which autonomously performs root cause analysis and executes remediation plans.

• Manual alert management

  Shifts the workload from human analysts to AI agents that handle the enrichment and resolution of routine and complex issues alike.

• Evolving threat landscape

  Keeps defenses up-to-date with real-time threat intelligence and continuous ML model optimization.

• Operational inefficiencies: Delivers an out-of-the-box solution with built-in optimizations, eliminating the need for extensive customer-led tuning.

• Analyst burnout

  Alleviates alert fatigue by offloading repetitive investigation and response tasks to the AI workforce, allowing analysts to focus on strategic defense.

Cortex XSIAM architecture overview

Cortex XSIAM unifies endpoint, network, cloud, identity, and third-party security data. Its architecture combines AI-driven detection, investigation, and response with centralized data ingestion, normalization, and automation.

Core Cortex XSIAM capabilities

• Cortex XSIAM includes:
  • SIEM (security information and event management)
  • EDR/XDR (endpoint and extended detection and response)
  • CDR (cloud detection and response), including Cloud Posture and Cloud Runtime Security
  • NDR (network detection and response)
  • SOAR (security orchestration, automation, and response)

Cortex Extended Data Lake (XDL)

• Cortex Extended Data Lake (XDL) provides unified data normalization, AI, and automation. It centralizes security telemetry as a single, intelligent source of truth, including:

  Feature	Description
  Endpoint	<p>Cortex XDR agents forward all data directly to Cortex XDL. This data is accessible for query and investigation within Cortex XSIAM.</p><p>When a Cortex XDR agent detects an unknown sample (an attempt to run a macro, DLL, or executable file), Cortex XSIAM can automatically forward the sample for WildFire analysis. WildFire Cloud Service identifies previously unknown malware and generates signatures that Palo Alto Networks firewalls and Cortex XSIAM can use to detect and block that malware.</p><p>Based on the properties, behaviors, and activities the sample displays when analyzed and executed in the WildFire sandbox, WildFire determines whether the sample is benign, grayware, phishing, or malicious. WildFire then generates signatures to recognize the newly discovered malware and makes the latest signatures globally available every five minutes.</p>
  Network & SASE	<p>Centralizes logs from Palo Alto Networks sources. It utilizes the Strata Logging Service to ingest and normalize network logs from Next-Generation Firewalls (NGFW) and Prisma Access.</p><div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><p>If you plan to stream data from a Strata Logging Service instance, it must reside in the same region as your Cortex XSIAM tenant.</p></div>
  Cloud, Apps & CI/CD	Provides comprehensive visibility across your cloud infrastructure, version control systems (VCS), and delivery pipelines to detect risks, such as exposed secrets, Software Composition Analysis (SCA) vulnerabilities, and IaC misconfigurations.
  Identity	<p>Consumes data from identity sources that connect to the Cloud Identity Engine, which provides the necessary Active Directory or Okta context for User/Entity Behavior Analytics (UEBA).</p><p>The Cloud Identity Engine (CIE) enables Palo Alto Networks cloud-based applications to use computer, user, and group attributes from your organization’s directories for security policies and endpoint management. This cloud-based service synchronizes attribute data from various sources, including On-prem directories like Active Directory and cloud-based directories such as Microsoft Entra ID, Okta, and Google Cloud Identity.</p><p>The Cortex XSIAM tenant and the CIE must be deployed in the same region.</p>
  Vulnerabilities and exposures	ASM performs DNS lookups and scans hosts to identify security flaws before they can be exploited. The intelligence gathered from these lookups and scans is transformed into actionable data, such as vulnerabilities and exposures.
  Open ecosystem (any source)	Facilitates the ingestion of third-party security and management vendor telemetry, custom logs, and external alerts from any environment. These sources are integrated into Cortex XDL using an HTTP Log Collector or through the Broker VM, which runs specialized applets for Syslog, Database, CSV, Kafka, and FTP collection

Extended Cortex XSIAM capabilities

You can extend Cortex XSIAM with capabilities such as:

• ITDR (Identity Threat Detection and Response) for domain controller protection
• Threat Intelligence Platform (TIP)
• Attack Surface Management (ASM)
• Email Advanced Security
• Exposure Management

Cortex Agentic Assistant

Cortex Agentic Assistant uses AI agents to plan, reason, and investigate complex threats. Examples include cloud identity theft and container breaches.

Cortex XSIAM ecosystem

This diagram shows Cortex XSIAM as a central security operations platform. It connects diverse data sources and proactive security functions.

Cortex XSIAM ecosystem architecture.

Broker VM architecture and data collection

Broker VM is a secure on-premises gateway for Cortex XSIAM data ingestion. It centralizes collection from security devices that cannot send data directly to the cloud. It also provides a secure proxy for agents and collectors in restricted or air-gapped networks. Specialized applets collect different data types and ingest them into Cortex XDL.

Broker VM data collection architecture.

Cortex XSIAM integrates advanced artificial intelligence to streamline security operations. Through the Cortex Agentic Assistant, the platform provides a unified interface for interacting with both system-provided and custom AI agents capable of creating and executing multi-step plans. These agents leverage specific capabilities to perform actions across your infrastructure, facilitating deep case investigations and proactive threat hunting while allowing for the creation of tailored automation.

Key AI Capabilities

• Agentic Assistant Hub: A centralized hub for managing agents and actions. System agents can be enabled and disabled, and you can create custom agents tailored to your organizational needs, including the ability to execute custom scripts.
• Automation Engineer Agent: Provides a natural language interface to draft, refine, and deploy automation scripts.
• MCP Integration: Supports the configuration of integrations that communicate with external MCP servers, enabling agents to access third-party tools and data sources via a standardized protocol.
• Embedded AI Prompts: Facilitates the inclusion of generative AI tasks within playbooks. These prompts function as standalone workflow steps to analyze data or generate content without requiring a dedicated agent.
• AI-Generated Case Summaries: Automatically generate technical overviews of security incidents. These summaries consolidate complex telemetry and impact data into high-level reports to accelerate initial triage and stakeholder reporting.

Cortex Agentic Assistant

Cortex Agentic Assistant uses AI agents to investigate threats and execute multi-step security tasks in Cortex XSIAM. It utilizes AI agents that plan, reason, and investigate complex threats, such as cloud identity theft or container breaches. Cortex Agentic Assistant enables security operations teams to use natural language prompts to interact with AI agents. The agents have access to case context and can create plans and perform actions such as running commands, playbooks, and scripts, as well as visualizing data or investigations.

You can also interact directly from Slack with the Agentic Assistant. This enables you to trigger agents, investigate, and perform remote executions within your collaboration workflow without needing to log into Cortex XSIAM.

To enable the Cortex Agentic Assistant, go to Settings → Configurations → General → Server Settings → Agentic Assistant.

Note

By default, you have access to the Cortex Assistant, which includes a natural language interface for entity investigation and provides a list of recommended responses such as running a playbook, performing a scan, or collecting support files.

If you enable the Cortex Agentic Assistant, it replaces the Cortex Assistant interface entirely.

For more information, see Compare Agentic Assistant with Cortex Assistant.

Cortex Agentic Assistant is based on an ecosystem of agents and actions.

The Cortex Agentic Assistant includes mission-focused system agents and the ability to create custom agents. An analyst focused on threat hunting, for example, might communicate primarily with the system Threat Intel agent. In contrast, analysts focused on general investigations might build custom agents that include all the actions required to perform their daily tasks.

Each agent is assigned actions it can execute. System actions can be based on playbooks, scripts, commands, or AI prompts. You can also register custom actions, which are based on scripts, commands, or AI prompts.

Access to the Cortex Agentic Assistant and the ability to manage agents and actions is restricted by role-based access controls. Actions marked as sensitive require manual approval, and all actions an agent executes are logged.

Tip

The system Help Center agent delivers fast, context-aware assistance to answer your questions. You can ask natural language questions, such as "How do I create a dashboard?" or "Where can I review my data retention policies?" and the agent retrieves concise, relevant information from the documentation. If a question remains unresolved, the agent assists you in creating a support case.

Within the XSIAM Command Center dashboard, you can click Cortex Agentic Assistant to view how your organization utilizes the Agentic Assistant, including information on agent plans, user prompts, as well as open cases. For more information, see XSIAM Command Center.

Supported regions

The Cortex Agentic Assistant is currently available for tenants in the following regions:

• Australia (AU)
• Canada (CA)
• France (FA)
• Germany (DE)
• India (IN)
• Japan (JP)
• Netherlands (EU)
• Singapore (SG)
• South Korea (KR)
• United Kingdom (UK)
• United States (US)

Note

In multi-tenant/MSSP environments, agentic AI features are not available on the main tenant.

Frontier Models

EU and US Regions

Tenants in the EU and US regions can use the following frontier AI models:

Claude Sonnet 5 is available upon request in the US and EU regions.

NOTE

Only tenants in the EU and US regions have the model selector. Using the model selector, you can choose between different frontier models per chat, AI prompt, and AI prompt task.

SG, JP, IN, and UK regions

Tenants in the SG, JP, IN, and UK regions have Gemini 3.5 Flash.

Discover how Cortex XSIAM can streamline your security operations by exploring some key use cases.

Chat prompt examples

Using chat prompt conversation starters in the Agentic Assistant simplifies and speeds up your interactions by providing pre-defined, common queries that guide you to relevant actions and information.

For example, a SOC analyst may see the following conversation starters under the chat prompt:

• What are the top issues I should prioritize today?
• Show me all issues with an overdue SLA
• Which automations are waiting for my input?
• Clean up all expired indicators.

Additional examples of possible relevant prompts are:

• Read this Unit42 blog and get all the CVEs. For every critical CVE found, check if my assets are vulnerable and isolate them.
• List recent security issues with high severity and an affected hostname that includes 'server'.
• Summarize the latest security issues from the past 24 hours
• How do I make a loop inside a playbook?
• What is the riskiest unresolved issue affecting our critical infrastructure?
• Show recent SSO-related issues
• Investigate this phishing issue and determine the source of the email and block any malicious indicators.
• Create a pie chart of the top 10 targeted assets over the last 7 days.
• Show critical assets by region in a bar chart.
• Create an line chart to show the trend of critical security issues over the past month.

Slack interaction with the Agentic Assistant example

Slack chats with the Agentic Assistant bridge the gap between where your team collaborates and where security operations happen by enabling you to interact with agents directly within your daily communication workflow without needing to log in to Cortex XSIAM. For more information on interacting with an agent from Slack, see Chat with an Agentic Assistant agent.

The following is an example scenario describing how you can monitor shift priorities, track SLAs, and review pending automations in Cortex XSIAM directly from Slack.

Initiation

Check the daily queue by opening your team's Slack channel and tagging @Your bot name with the prompt, "What are the top issues I should prioritize today and show me all issues with an overdue SLA?".

Agent selection

The bot responds with a dropdown menu of available public agents, and you select the appropriate agent to handle the request.

Status update

The agent processes the request and replies in the thread, providing a summarized list of the highest-priority issues and any automations currently waiting for user input.

If a team member in the channel sees the summary and attempts to ask the agent, "Give me more details on the first SLA issue," the team member receives an access denied message because the active session is only available to you, the initiator.

Handoff

The session can remain open for up to two weeks, after which it automatically closes. To end a session, type @Your bot name so the rest of the team can engage.

Another team member can then tag @Your bot name to initiate a new session. Because the system pulls the last five messages in the thread, the agent understands the history of the conversation. The team member can simply prompt, "Assign the first overdue issue from that summary to me," and the agent will know which issue is being referenced.

Cortex XSIAM offers two distinct forms of AI-driven assistance. Agentic Assistant is an advanced, optional capability that utilizes generative AI to autonomously plan and execute complex workflows. Cortex Assistant is a basic interface for streamlined navigation and entity investigation using natural language.

The following details the differences between Agentic Assistant and Cortex Assistant.

The Agentic Assistant is built on responsible AI principles to ensure its use is safe, fair, and trustworthy. We design our AI to be transparent about its actions, accountable for its decisions, and fair in its operations, avoiding biases.

The following describes how the Agentic Assistant protects sensitive data and gives you control and understanding over its automated actions.

Access control and permissions

User roles and RBAC options

Instance and Account admins control user access to Cortex Agentic Assistant. Cortex XSIAM uses role-based access control (RBAC) to govern chat access and permissions to view, create, edit, delete, enable, and disable agents and actions in the Agentic Assistant Hub.

Action Execution Scope

Agents can only use actions assigned to them, and execution is limited to the user's existing permissions in your Cortex XSIAM tenant. If a required integration is not active, its commands and any actions that wrap them will not work.

To perform actions in Slack, your Slack email must match your Cortex XSIAM user email. This ensures the system can strictly follow your assigned permissions (RBAC). If you do not have the required permissions to interact with agents, the system will block the action.

Data security and control

How sensitive data is protected

Data is hosted and encrypted by default on a dedicated Google Cloud Platform (GCP) project, and is isolated and protected by your specific IAM permissions. Google's multi-tenant architecture enforces strict data separation between customers.

User approval for sensitive actions

Actions marked as sensitive require explicit user approval before execution and are never run automatically. This gives you final control over critical or data-modifying steps.

Data user policy

Your prompts and outputs are processed only to generate the immediate response. They are not collected for model training or shared with third parties.

Data residency

All prompts and responses stay inside that region’s compute boundary, aligning with modern data-residency practices.

Transparency

You can see how the agent reaches its answer. Click the down arrow next to the Plan, to view how the user input was interpreted, the planned steps, and the actions used. You can view JSON artifacts created during plan execution, when data was retrieved, or when an object was created.

All actions an agent takes are saved in an audit dataset. You can see which agent ran which action, and which user invoked it.

In addition, all chat logs and actions initiated via Slack are stored in the Cortex XSIAM database and labelled with a specific Slack prefix or metadata tag.

Cortex XSIAM product licenses are available in NG-SIEM, Enterprise, and Premium subscription tiers. Compare each Cortex XSIAM license tier, its included capabilities, and available security add-ons to select the subscription for your security use case.

You can upgrade your license by purchasing add-ons or moving to a different XSIAM license.

Compare Cortex XSIAM license tiers

• NG-SIEM provides analytics, data collection, detection, and security automation.
• Enterprise adds Cortex XDR agent coverage and extended endpoint visibility.
• Premium adds cloud posture security, cloud runtime security, and threat intelligence capabilities.

Cortex XSIAM NG-SIEM license

Cortex XSIAM NG-SIEM is an analytics subscription tier that includes data collection and full automation, suitable for users who want to enhance their security without immediately replacing their existing SIEM and endpoint solutions.

Key features include:

Cortex XSIAM Enterprise license

Cortex XSIAM Enterprise includes all the features of Cortex XSIAM NG-SIEM and builds upon them by adding advanced endpoint visibility and data collection:

Key additions include:

Cortex XSIAM Premium license

Cortex XSIAM Premium is the most comprehensive tier, providing the highest level of security by combining all Enterprise features together with the following capabilities:

Existing users with a Cortex XSIAM Enterprise Plus license retain all Cortex XSIAM Enterprise features, including cloud agent features. You can deploy agents for runtime detection on cloud sources, such as Kubernetes nodes, OpenShift clusters, or cloud VMs, whether in the cloud or on-premises. If you want the full cloud posture security bundle (Cloud Posture Security or Cloud Runtime Security), you need to upgrade to Cortex XSIAM Premium.

Some add-ons, such as Advanced Email Security and Exposure Management, are available with Cortex XSIAM Premium, Enterprise, and NG-SIEM licenses.

License capabilities and add-ons

Cortex offers a modular set of license packages that work interchangeably, allowing them to serve as add-ons to subsequent products seamlessly. The table below shows the breakdown of each type of license package:

Tiers and key capabilities

After purchasing your license retention add-ons, you can view details about your Cortex XSIAM licenses and retention add-ons by selecting Settings → Cortex XSIAM License. For more information on your storage license details, see Dataset Management.

Default retention periods

The following table summarizes the default retention periods for Cortex XSIAM:

Retention add-ons

Retention add-ons are provided for ingested data and Cases and Issues data. Minimum requirements are dependent on the license type. You can purchase one or more of the following add-ons:

Cortex XSIAM data storage is managed in the Cortex XSIAM Data Layer. You receive data storage based on the amount associated with your licenses, determined by factors such as daily ingestion needs and the number of users. All licenses provide default retention periods, which can be extended for hot and cold storage.

To determine your requirements, you must understand the differences between the available storage options. The following image shows examples of these differences:

Data Ingestion Pipeline

Data enters via a data stream called the Data Ingestion Pipeline, where manipulation, such as normalization, enrichment, and analytics, occurs. Once ready, it is transferred to the following locations based on your licenses:

Hot storage

With a regular license, data is automatically sent to hot storage for the default retention period (typically one month).

• Extensions: You can add retention in monthly increments via Period-Based Retention (all data) or Additional Hot Storage (specific datasets).
• Retroactive application: If you purchase additional hot storage, the new retention time can be applied retroactively to any data still available in your hot datasets that hasn't been rolled out yet.
• Image example: In the image above, the regular Cortex XSIAM license and additional storage licenses ensure that all the data is accessible from hot storage for two months. After this, data begins purging except for Dataset 2 (accessible for one additional month) and Dataset 3 (accessible for two additional months) before being gradually purged.

Cold storage

A regular license provides no default cold storage.

• Independence: There is no connection between hot and cold storage; you cannot move missing data from hot to cold storage later. Data must be sent to cold storage from the pipeline starting from the purchase date.

  Tip

  If you want your cold storage data to align with the hot storage data, you must ensure you purchase your cold storage license at the same time as your regular Cortex XSIAM license.

• Accessibility: Cold storage data is collected upon ingestion but is only accessible after the hot storage retention period has expired. The cold storage retention period only begins once the hot storage period ends.
• Retroactive application: If you purchase additional cold storage, the extra retention time may be applied retroactively to any data still residing in your cold datasets that hasn't been rolled out yet, provided the existing data is covered under the renewal/purchase.

• Requirements: Requires a minimum of six months of retention and Compute Units (CU) to run cold storage queries. For more information on CU, see Manage compute units.

  For information on the CU add-on license, see Understand the Cortex XSIAM license plan.

• Image example: Cold storage is aligned with hot storage. The pipeline sends data to both for the first two months, but it is not accessible in cold storage during the hot storage retention period. After two months, the data becomes accessible in cold storage for six months (except for Datasets 2 and 3, which are still in their extended hot storage periods). Once those datasets finish their hot retention, they also become accessible in cold storage for six months before purging.

Export

A regular license does not provide default export capabilities.

• Event Forwarding: Only after purchasing this add-on is data sent to an intermediate storage location from the pipeline.
• Retention: This data is accessible for seven days before being gradually purged.

• Image example: Export data is aligned with hot and cold storage. The pipeline sends data to intermediate storage for Event Forwarding, which is accessible for seven days before purging.

  For more information on Event Forwarding, see Manage Event Forwarding.

Recommendations

To optimize your data strategy and prevent data loss, consider the following best practices:

• Synchronize license purchases: For your cold storage data to align perfectly with your hot storage data, you must purchase your cold storage license at the same time as your regular Cortex XSIAM license. This ensures the Data Ingestion Pipeline begins feeding both streams simultaneously from day one.
• Manage retention proactively: To ensure no data is lost and that extensions can be retroactively applied to your hot and cold datasets, always make changes to your data retention licenses while the current license is still active. If a license expires or the data retention period passes, the data is purged and cannot be recovered or extended retroactively.

You can view details about your Cortex XSIAM licenses by selecting Settings → Cortex XSIAM License.

Enforcement of licenses

Cortex XSIAM Enterprise and Premium licenses include Cortex XDR agents with Host Insights (HI) and Extended Threat Hunting (XTH) capabilities. When you buy additional agents, these capabilities are automatically extended to new agents. For Cortex XSIAM NG SIEM, this license does not include agents or HI/XTH capabilities by default. If you buy agents for this tier, you must also buy the HI and XTH add-ons for them.

In Cortex XSIAM, the Cortex XDR agent protects all your enterprise assets, from user devices to cloud servers. For licensing purposes, these assets are categorized as follows:

• Endpoints

  An endpoint is any physical or virtual device, such as a PC, laptop, or server, protected by an installed Cortex XDR agent. Licensing is calculated on a 1:1 basis, meaning one active device consumes one license.

• Workloads

  A workload represents a compute resource, such as a VM, container, or serverless function in a public cloud. These resources can be secured by agent-based protection (Cortex XDR agent) or agentless methods. Both Cloud Runtime Security and Cloud Posture Security are included in Cortex XSIAM Premium. License consumption is determined by the protection you deploy.

When all XDR endpoint and workload licenses are consumed, Cortex XSIAM maintains basic endpoint protection on affected assets. Advanced pro-level detection and response capabilities are not applied. If you exceed workloads or endpoints, XSIAM does not “borrow” from unused endpoints or workloads.

When you exceed the permitted number of Cortex XDR endpoints and workloads, Cortex XSIAM displays a notification in the notification area. Cortex XSIAM permits a small grace period over the permitted number, but begins enforcing the number of agents after 14 days. If additional Cortex XDR agents are required, increase your Cortex XDR endpoint/workload license capacity.

For Cortex XSIAM Enterprise Plus licenses, if an endpoint requires a Cortex XDR per Endpoint license, and you’ve exceeded the number of available Cortex XDR per Endpoint licenses, one of your surplus Cloud per Host licenses is automatically consumed as a Cortex XDR per Endpoint license for the endpoint. After utilizing all available XDR per Endpoint and Cloud per Host licenses, Cortex XSIAM maintains basic endpoint protection on affected assets. Advanced pro-level detection and response capabilities are not applied.

When the number of Cloud Posture Workloads exceeds the limit for Cortex XSIAM Premium or any Cortex XSIAM license with the Cloud Posture Security and Cloud Runtime Security add-ons, the excess posture workloads will use available credits from the Cloud Runtime Workloads quota until it is fully used. Spillover occurs only from posture to runtime workloads and does not occur in the reverse direction. Any excess workload usage is displayed as a notification in the notification area.

License revocation

Cortex XSIAM manages licensing for all assets, including user devices, servers, and cloud workloads, which are protected by the Cortex XDR Agent. Each time you install a new Cortex XDR Agent, it registers with Cortex XSIAM to obtain a license from the appropriate pool (either for user endpoints or workloads). For non-persistent VDI (virtual machines that are reset or destroyed after use), the agent registers as soon as a user logs in to the asset.

Cortex XSIAM issues licenses until you exhaust the number of licenses available, and enforces a cleanup policy that automatically returns unused licenses to the available pool. The time at which a license returns to the license pool depends on the type of endpoint (or workload):

After a license is revoked, if the agent connects to Cortex XSIAM, reconnection will succeed as long as the agent has not been deleted from the database; otherwise, the agent is registered as a new asset.

If an agent from a deleted asset tries to connect to Cortex XSIAM within the 180-day period (for standard endpoints and workloads), it can resume its connection and maintain its original agent ID. After 180 days, the agent ID and all associated data are permanently deleted from the database. To reconnect an agent after this period, you must use Cytool to reconnect or reinstall the agent on the asset, which will then be assigned a new agent ID and start fresh.

It can take up to an hour for Cortex XSIAM to display revived assets.

Cortex XSIAM licenses are valid for the period of time associated with the license purchase. After your license expires, you have access to your tenant for an additional grace period of 48 hours. After the 48-hour grace period, you no longer have access and it is disabled until you renew the license.

For the first 31 days of your expired license, Cortex XSIAM continues to protect your endpoints and/or network and retains data in the Cortex Data Layer according to your data retention policy and licensing. After 31 days, the tenant is decommissioned and agent prevention capabilities cease.

When you purchase new entitlements, Cortex XSIAM automatically applies them to your tenant through a seamless upgrade process. If any downtime is required, you’ll receive advance notice and can choose a convenient time to proceed with the upgrade.

A banner notifies you that an upgrade is scheduled. To see details of the upgrade schedule, click view upgrade details. You can continue with the update schedule, or take one of the following actions:

• To upgrade immediately, click Upgrade now.
• To schedule an upgrade, select a start date and time from the calendar.

Keep in mind the following during the upgrade process:

• The gateway may experience up to two hours of downtime during the installation.
• The upgrade will occur automatically on the scheduled time and date unless you change it. The product will also display a banner 24-hours before the upgrade occurs.
• The development tenant associated with the upgraded production tenant will also be upgraded.
• Pairing Prisma Cloud Compute with Cortex XSIAM is not supported in XSIAM 3.X versions.

To simplify the process of creating a support ticket, you can open a support ticket directly in Cortex XSIAM. Opening the ticket in Cortex XSIAM allows all of the relevant context to be included, such as the option to record the console and upload relevant logs. When relevant, Cortex XSIAM will create and send the agent tech support file (TSF) for the endpoint you select. All relevant data about your tenant is logged and included in the support ticket, including license details. Using the Submit Support Ticket wizard makes it easier for you to include all of the necessary details and log files while first submitting your support ticket, thereby enabling the support team to solve it more quickly and easily.

If you have the Cortex Agentic Assistant enabled, when you click Help, you have two options: Documentation Portal and Initiate Support Request. If you select Initiate Support Request, the Help Center agent opens to assist with finding relevant documentation, troubleshooting, and creating a support ticket. After your first prompt to the Help Center agent, you can click Submit support ticket above the chat. If you click Submit Support Ticket, you are brought directly to the Submit Support Ticket wizard.

If you do not have the Cortex Agentic Assistant enabled, when you click Help, you have two options: Documentation Portal and Initiate Support Request. If you select Initiate Support Request, you are brought directly to the Submit Support Ticket wizard.

To use the embedded support ticket feature, you must have a user account in the Customer Support Portal, and your Cortex XSIAM user must be granted the Help permission in Cortex Gateway.

From Cortex XSIAM, select Help → Initiate Support Request.

In the Submit Support Ticket wizard, enter the requested ticket information. Be precise when indicating the impact of the issue. When an issue is critical, you will be asked to input the most critical information so that support can understand the issue and start addressing it immediately.

When opening a support ticket through the Customer Support Portal, you need to manually select Cortex XSIAM as the product. While there may be discrepancies between the categories in this wizard and the Customer Support Portal process, that's because this wizard is designed specifically to focus on options relevant to Cortex XSIAM.

When the issue you are opening a support ticket for is related to the agent, you can select the relevant endpoint. If you select the endpoint, Cortex XSIAM will create and send the TSF for the agent you selected, when possible.

Selecting an endpoint from the endpoint table and retrieving TSF requires full Retrieve Endpoint Data permissions under Endpoint Administration.

To provide more context for your support ticket, you can record the Cortex XSIAM console directly from the support ticket wizard. If you choose to record the console, you can also opt to have the HAR file generated and sent to further assist support in solving the ticket. To record the console, select Record Console. To submit your support ticket without recording the console, select Skip.

If you choose to record the console, your browser may prompt you for permission for Cortex XSIAM to see the contents of the tab. To allow recording, select Allow. You can now recreate the issue in your Cortex XSIAM environment, and all of your actions are recorded. The console recording and HAR file generation only take place within the context of the browser tab that Cortex XSIAM is running in. When you are ready to stop recording, select Stop Sharing.

If you wish to recreate the recording, you must first delete the existing console recording by clicking the x symbol next to the Console Recording. Then select Record Console.

Console recordings cannot exceed 10 minutes. The current recording time is displayed at the top of the window.

To submit the support ticket, click Submit Support Ticket.

While the ticket attachments are uploading, do not refresh or navigate away from Cortex XSIAM until you get a notification in the Notification Center that uploading is complete. In the meantime, you can close this wizard and continue working in Cortex XSIAM.

Once the support ticket is created successfully, the support ticket number is displayed, and you will receive an email notification from Palo Alto Networks Support. You can manage the support ticket and monitor its progress in the Customer Support Portal.

Cortex XSIAM supports the following web browsers:

The Cortex XSIAM interface provides a centralized security operations workspace. Use it to view and manage security data across your environment.

Use the navigation menu on the left to move between product areas in the tenant. For a quick overview of each area, see the Navigation cheat sheet below.

From the interface, you can:

• Navigate between product areas.
• Chat with an Agentic Assistant agent
• Filter table results to find relevant information.
• Create saved views with commonly used filter configurations.
• Export table data.

• Access in-product help and documentation.

• Each SAML login session is valid for 8 hours.
• Some menu items only appear if you have the relevant license.

Filter Cortex XSIAM page results

To reduce the number of results, you can filter by any heading and value. When you apply a filter, Cortex XSIAM displays the filter criteria above the results table. You can also filter individual columns for specific values using the icon to the right of the column heading.

Some fields also support additional operators such as =, !=, Contains, not Contains, *, !*.Filters are persistent. When you navigate away from the page and return, any filter you added remains active.

To build a filter using one or more fields:

1. From a Cortex XSIAM page, select filter ().

   Cortex XSIAM adds the filter criteria above the top of the table.

2. For each field you would like to filter by:
   1. Select or search the field.

   2. Select the operator that matches the criteria.

      Use = to include results that match the value you specify, or != to exclude results that match the value.

   3. Enter a value to complete the filter criteria.

      CMD fields have a 128-character limit. Shorten longer query strings to 127 characters and add an asterisk (*).

      Alternatively, you can select Include empty values to create a filter that excludes or includes results when the field has empty values.

3. To add additional filters, click +AND, within the filter brackets to display results that must match all specified criteria, or +OR to display results that match any of the criteria.
4. To see the results, click out of the filter area.

Save Cortex XSIAM views and filters

Cortex XSIAM allows you to save filter configurations so you can quickly return to commonly used data selections. Depending on the page you are working on, you can save either views or filters:

• Saved views store table configurations, including filters, so you can quickly switch between commonly used table perspectives.
• Saved filters store only the filter criteria, allowing you to quickly apply the same filtering logic again.

These options help you quickly focus on the data most relevant to your workflow.

Saved views

Saved views store filter configurations for table data, allowing you to quickly return to frequently used filters. You can filter table data by fields such as domain, context, or work queue, configure the columns you want to see, and save the configuration as a reusable view.

Saved views are available on most table-based pages, such as the Cases and Issues pages. The default view is All (for example, All Cases).

Select the arrow next to the view name to see all available views. If you modify filters in an existing view, you can update the view or save the configuration as a new view.

Save a view

1. Apply one or more filters.
2. Select Save.
3. Enter a name for the view.
4. Choose whether to share the view.

Manage views

• Use the three-dot Actions menu next to the view name to take the following actions:
  • Set the view as the default.
  • Share or unshare the view.
  • Update the view after modifying filters.
  • Delete the view.
• Deleting a shared view removes it for all users.
• You can delete your own saved views.
• To delete views created by other users, you must have the Account administrator or Instance administrator role.

Saved filters

Some pages allow you to save filters instead of views, such as the IOC and BIOC pages.

Saved filters store filter criteria, allowing you to quickly apply the same filters again. Saved filters help standardize filtering and allow users to quickly apply commonly used search conditions.

Apply a saved filter

1. Open the three-dot Actions menu in the table filter row.
2. Select Saved filters and choose a filter to apply.
3. Click Apply.

Create a filter

1. Remove all filters from the table.
2. Click Add filter and define the filter values.
3. Click Save and define a filter name.

Share or delete a saved filter

1. Open the three-dot Actions menu in the table filter row.
2. Select Saved filters.
3. Click the Actions menu next to a filter name and select the relevant action.

• Deleting a shared filter removes it for all users.
• You can delete your own saved filters.
• To delete filters created by other users, you must have the Account administrator or Instance administrator role.

Export Cortex XSIAM results

You can export the page results for most pages in Cortex XSIAM to a tab-separated values (TSV) file.

1. (Optional) Filter page results to reduce the number of results for export.

2. Select export to file ().

   Cortex XSIAM exports any results matching your applied filters in TSV format. The TSV format requires a tab separator; automatic detection does not work in the case of multi-event exports.

Cortex XSIAM system tools and services

The following controls appear in the navigation bar and provide access to system tools, help resources, and tenant settings.

Cortex Agentic Assistant

Click in the top-right corner to open the assistant.

The Cortex Agentic Assistant is the autonomous AI capability of Cortex XSIAM. It uses AI agents that plan, reason, and investigate complex threats, such as cloud identity theft or container breaches.

Notifications

The Notifications panel displays system alerts and updates generated by Cortex XSIAM.

Tenant Navigator

Use Tenant Navigator to view and switch between tenants you have access to. Tenants are organized by CSP account. You can also navigate directly to the Cortex Gateway.

Settings

From the Settings menu, you can:

• View license information
• Manage audit logs
• Manage exceptions configuration
• Configure data sources and system settings

Managed Services

The Managed Threat Hunting service provides 24/7 monitoring by Palo Alto Networks threat researchers and Unit 42 experts.

Help

Cortex XSIAM provides in-product help directly within the interface.

Click to open the Help. There are two options:

• Documentation Portal
• Initiate Support Request

If you have the Cortex Agentic Assistant enabled, when you select Initiate Support Request, the Help Center agent opens to assist with finding relevant documentation, troubleshooting, and creating a support ticket. After your first prompt to the Help Center agent, you can click Submit Support Ticket above the chat. If you click Submit Support Ticket, you are brought directly to the Submit Support Ticket wizard.

If you do not have Cortex Agentic Assistant enabled, selecting Initiate Support Request brings you directly to the Submit Support Ticket wizard.

User menu

Click your username to access user and tenant options.

From the user menu, you can:

• View tenant information
• See What's New
• Switch between light and dark mode
• Log out

Cortex XSIAM navigation cheat sheet

Dashboards & Reports

Cases & Issues

Investigation & Response

Search

Automation

Response

Forensics

Notebooks

Threat Management

Detection Rules

Threat Intelligence

Posture Management

Requires Cortex XSIAM Premium or any other XSIAM license with the Cloud Runtime Security add-on.

Inventory

Assets

Endpoints

Modules

Agentic Assistant Hub

This menu item appears if you have enabled the Cortex Agentic Assistant.

Manage agentic agents and actions in the Agentic Assistant Hub.

API keys are used to manage and secure API interactions. An API key is essentially a unique string of alphanumeric characters that acts as a credential, allowing a specific user or application to access and interact with a particular API. When you request data or perform an action through an API call, you must include this API key in the header. Cortex XSIAM then verifies the key's authenticity and, if valid, grants the requested access.

How to create an API key

1. Select Settings → Configurations → Integrations → API Keys → New Key.
2. In the Role tab, perform the following:
   1. Under Security Level, select the type of API Key you want to generate: Advanced or Standard. The Advanced API key hashes the key using a nonce, a random string, and a timestamp to prevent replay attacks. cURL does not support this, but it is suitable for scripts.

   2. Under Role, select the desired level of access for this key. You can select from predefined roles or custom roles. Roles are available according to what was defined in either the Cortex Gateway or Cortex XSIAM Access Management. You can view the configuration of the role selected by expanding the sections under Components. For more information, see Assign user roles and groups.

      Ensure the selected role has the appropriate Credentials permission. If you select a role where Credentials is set to None, such as the predefined CLI Role, any API calls made using this key that attempt to fetch, list, create, or modify stored credentials will return a 403 Forbidden error.

   3. (Optional) Under Comment, provide a comment that describes the purpose of the API key.
   4. (Optional) If you want to define a time limit on the API key authentication, select Enable Expiration Date, and select the expiration date and time. You can track the expiration date of each API key in the API Keys page. In addition, Cortex XSIAM displays an API Key Expiration notification in the Notification Center one week and one day before the defined expiration date.

3. (Optional) To configure and manage granular scoping for Scope-Based Access Control (SBAC), click the Scope tab, and under Scope Definition, expand the scoping areas that you want to grant the user role access to for this API by clicking the chevron icon (>) beside the scoping area title. The following table explains the options available to configure:

   Before configuring, ensure you review Understand scoping in the Manage user scope 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. 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.
   Datasets Rows	Configure a filter to define the specific subset of rows a user is allowed to access in each raw dataset. A raw dataset is every dataset where Palo Alto Networks data is ingested out-of-the-box or third-party data is ingested using a configured dedicated collector, also called a data source. This filter configuration does not impact the visibility of cases and issues. Follow these steps to configure a filter: 1. For datasets where no filter is defined, determine how to set the When no filter is defined option as either: No rows are accessible (default): Without a configured filter, no rows are accessible. Users can query the datasets in Cortex Query Language (XQL) as they have access, but the results will be empty. All rows are accessible: Without a configured filter, all rows are accessible. Users can query the datasets in Cortex Query Language (XQL) as they have access, and view all results. When defining a filter for row-level scoping on raw datasets, queries based on the Cortex Data Model (XDM) are not supported. XDM queries return specific rows only when All rows are accessible is selected, and no filter is defined in the Datasets Rows scoping area. Otherwise, no rows are returned. 2. Define any filters for the applicable datasets listed in the table: Scroll down the list of datasets to the dataset you want to apply a filter on, and click the Edit Scope icon. In the Define what rows are accessible window, continue to write the query for the filter in the query box (where the syntax is a limited subset of XQL) to limit the data rows for the selected dataset according to the access permissions you want the user to have. The beginning of the query is already defined before the query box, and there is no need to include this in your query. Important For optimal performance, we recommend using a single field in the filter definition and simple comparison operators. Supported syntax: Fields You can define the rest of the filter in the query box, where only the following system fields are supported: _broker_device_id, _broker_device_ip, _broker_device_name, _collector_id, _collector_ip, _collector_name, _collector_type, _device_id, _final_reporting_device_ip, _final_reporting_device_name, _log_type, _product, _scope, _reporting_device_ip, _reporting_device_name, and _vendor. For more information on these fields, see the table that describes all the fields in the metrics_source dataset and metrics_view preset in Overview of data ingestion metrics. For more information on the _scope field (relevant when _scope is defined in the Parsing Rule), see Scenario 3: Supported fields don't provide the necessary segmentation. Comparison operators The following comparison operators are supported: Exact matches (=, !=) Comparing numerical values (>, <, >=, <=) Checking membership in lists (in) Querying arrays (array_contains) Partial matches (contains, starts_with): Using this operator has additional performance overhead, and we recommend avoiding its use. Example If you only want a user to be able to access rows in the pan_dds_raw dataset, when the _collector_name is bu2_collector , you'd have to define the filter in the query box as: _collector_name = “bu2_collector” (Optional) Set the Time frame for the query. The default is Last 1 day. (Optional) You can preview the query results displayed based on your defined query by clicking Preview. You can edit your query until you're satisfied with the output. By default, the query results are limited to 1000 records. When you are finished, click Done. The Scope field for the dataset that you added the filter on is updated with the query. Example In the above example, the Scope field displays _collector_name = “bu2_collector”.

   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 an administrator or a user with Access Management permissions first ensure that the users, user groups, and API Keys defined in Cortex XSIAM are granted the required access by assigning the relevant scopes. For more information, see Manage user scope.

4. Click Generate to generate the API key.

5. Copy the generated API key and click Done.

   You will not be able to view the API key again after you complete this step. Ensure that you copy the API key before closing the notification.

Actions available on API Keys

Below are some of the main pivot (right-click) options for actions available on each API key listed in the API Keys table. Only tasks that need further explanation are explained below.

API enforcement for credentials

If an API key is assigned a role with Credentials set to None:

• Data access: GET or List calls to credential endpoints will fail.
• Modification: POST, PUT, or DELETE calls to create or update credentials will fail.
• Automation: Any scripts or external integrations using this API key to retrieve secrets from the credential store will return an unauthorized error.

Onboarding aims to get you up and running as quickly as possible, driven by the need for rapid time-to-value (TTV), immediate risk reduction, and quick validation. Focus on the most essential components (such as core data sources and integrations), and install the XDR agent (subject to license) as the central sensor for visibility and prevention. This establishes the Cortex Extended Data Lake (XDL) as the central data repository, ensuring it is the single, intelligent source of truth powering all subsequent XQL queries, detection analytics, and automated case triage.

This stage includes how to plan and prepare the Cortex XSIAM environment.

Note

This topic does not include any specific Cloud Security requirements. If you have a Cortex XSIAM Premium license or another XSIAM license with Cloud Posture Security/Runtime addons, you should also plan and prepare Cloud Posture Security and Runtime during or after completing this stage. For more information about Cloud Security onboarding, see Cloud service provider onboarding.

Before you get started with Cortex XSIAM, consider the following:

You typically deploy Cortex XDR agent software to endpoints across a network after an initial proof of concept (POC), which simulates your corporate production environment. During the POC or deployment stage, you analyze security events to determine which are triggered by malicious activity and which are due to legitimate processes behaving in a risky or incorrect manner. You also simulate the number and types of endpoints, the user profiles, and the types of applications that run on the endpoints in your organization, and, according to these factors, you define, test, and adjust the security policy for your organization.

The goal of this multi-step process is to provide maximum protection to the organization without interfering with legitimate workflows.

After the successful completion of the initial POC, we recommend a multi-step implementation in the corporate production environment for the following reasons:

• The POC doesn't always reflect all the variables that exist in your production environment.
• There is a rare chance that the XDR agent will affect business applications, which can reveal vulnerabilities in the software as a prevented attack.
• During the POC, it is much easier to isolate issues that appear and provide a solution before full implementation in a large environment where issues could affect a large number of users.

A multi-step deployment approach ensures a smooth implementation and deployment of the Cortex XSIAM

Cortex XSIAM solution throughout your network. Use the following steps for better support and control over the added protection.

While Cortex XSIAM is a unified platform, a successful deployment is rarely done all at once. Start with the essential, high-impact activities to get the core platform functional, endpoint protection up and running, and critical data sources feeding into the system quickly. Once you have completed these steps, set up the less critical but important features.

Use this Cortex XSIAM onboarding checklist to plan, deploy, and configure your security operations environment. Complete activation, data source configuration, Cortex XDR agent deployment, and analytics setup.

This checklist does not include any specific Cloud Security requirements. If you have a Cortex XSIAM Premium license or another XSIAM license with Cloud Posture Security/Runtime, you should also onboard Cloud Posture Security and Runtime during or after completing this stage. For more information about Cloud Security onboarding, see Cloud service provider (CSP) onboarding.

Cortex XSIAM deployment checklist

This deployment phase sets up Cortex XSIAM infrastructure, data pipelines, endpoint protection, and security analytics.

Your Cortex XSIAM is now operational and is collecting data.

To activate a tenant, you need to log in to Cortex Gateway, a centralized portal for activating and managing tenants, users, roles, and user groups. After activating the tenant, you can then access the tenant. You must repeat this task for each tenant if you have multiple tenants. The activation process involves accessing Cortex Gateway, activating the tenant, and then accessing the tenant's resources.

Prerequisite

• The Cortex XSIAM activation email.

• A Customer Support Portal (CSP) account.

  You need to set up your CSP account. For more information, see How to Create Your CSP User Account.

  When you create a CSP account, you can set up two-factor authentication (2FA) to log into the CSP by using an Email, Okta Verify, or Google Authenticator (non-FedRAMP accounts). For more information, see How to Enable a Third Party IdP.

• You have one of the following roles assigned:

  Role	Description
  CSP role	The Super User role is assigned to your CSP account. The user who creates the CSP account is granted the Super User role.
  Cortex role	<p>You must have the Account Admin role.</p><p>If you are the first user to access Cortex Gateway with the CSP Super User role, you are automatically granted Account Admin permissions for the Cortex Gateway. You can also add Account Admin users as required.</p><p>In the Cortex Gateway, you can activate new tenants, access existing tenants, and create and manage role-based access control (RBAC) for all of your tenants.</p>

How to activate Cortex XSIAM

1. Log in to Cortex Gateway.

   You can also access the link from the activation email.

2. Enter your username and password or multi-factor authentication (if set up) by using your Customer Support Portal account credentials to sign in.

   After you sign in, you can view the following:

   • If you are a CSP Account Admin, you can see tenants allocated to your CSP account and ready for activation. After activation, you cannot move your tenant to a different CSP account.
   • Tenant details such as license type, number of endpoints, and purchase date.
   • Tenants that were activated and are now available. If you have more than one Customer Support Portal account, the tenants are displayed according to the Customer Support Portal account name.

3. In the Available for Activation section, use the serial number to locate the tenant that needs activation, and then click Activate.

   When you activate, a production tenant is activated first. After activation, you can set up a development tenant (subject to your license).

4. On the Tenant Activation page, define the following:

   Parameter	Description
   Tenant Name	Enter the name of the tenant. Use a unique name across your company account up to 59 characters long.
   Region	Geographic location where your tenant will be hosted. For more information about supported regions, see Cortex XSIAM supported regions.
   Tenant Subdomain	<p>DNS record associated with your tenant. Enter a name that will be used to access the tenant directly using the full URL:</p><p>https://<subdomain>xdr.<region>.paloaltonetworks.com</p>
   Encryption Method	<p>(Optional) If you want to bring your own keys for encrypting your data, under Advanced, select BYOK and follow the instructions of the wizard as detailed in Encryption Method.</p><ul><li><p>Default encryption (recommended)</p><p>All data stored by Cortex XSIAM is encrypted at rest using a dedicated key management system. Cortex XSIAM provides strict key access controls and auditing, and encrypts user data at rest according to AES-256 encryption standards. We recommend using this default system.</p></li><li><p>BYOK (Bring your own keys)</p><p>BYOK (Bring Your Own Keys) enables you to generate your own encryption keys and securely import and manage them via Cortex Gateway to retain greater control over your tenant data and encryption. This requires further setup.</p></li></ul>

5. Review and agree to the terms and conditions of the Privacy policy, Terms of Use, and EULA , and then Activate your tenant.

   Activation can take about an hour and does not require you to remain on the activation page. Cortex XSIAM sends a notification to your email when the process is complete.

6. After activation, from the Cortex Gateway, in the Available Tenants, when hovering over the activated tenant, do the following:
   • Ensure that you can successfully access the tenant by clicking the Cortex XSIAM tenant name (when the tenant is active).

   • In the dialog box, view the tenant status, region, serial number, and license details.

     If you want to change your tenant's name, the subdomain, or activate a development tenant (subject to license), on the right-hand side, click the ellipsis.

     You can only change the subdomain once, and it cannot be undone.

     After deleting the subdomain, you can reuse it after 7 days.

7. Enable and verify access to Cortex XSIAM communication servers, storage buckets, and various resources in your firewall configuration. For more information, see Enable access to required PANW resources.

What is Cortex BYOK?

Cortex self-managed BYOK (bring your own keys) offers a comprehensive data encryption solution, empowering enterprises to assert complete authority over their encryption key management, while ensuring platform reliability, availability, and responsiveness. It enables you to securely import and manage your own encryption keys via Cortex Gateway. This provides you with enhanced control over your tenant data encryption and accessibility, eliminates reliance on default CSP encryption or third-party key management, and enables you to comply with stringent regulatory requirements.

Unlike self-hosted solutions, Cortex BYOK minimizes exposure to external risks, such as downtime, breaches, or operational disruptions, by reducing dependency on external environments, ensuring availability and responsiveness of your Cortex products.

By default, Google Cloud encrypts customer data at rest using envelope encryption, where randomly generated Data Encryption Keys (DEKs) encrypt the data, and Google-managed Key Encryption Keys (KEKs) wrap the DEKs, all protected within Google's multi-layered key hierarchy. Cortex BYOK enhances this model by allowing customers to generate and supply their own KEK, which is securely imported into PANW's tenant-specific Key Management Service (KMS) environment on Google Cloud. The customer-provided KEK is used to encrypt the DEKs that protect tenant data, giving customers control over key management through the Cortex Gateway. While PANW securely manages encryption operations within its cloud environment, customers retain authority over the KEK, achieving greater control and auditability.

Cortex BYOK architecture

Cortex BYOK leverages a dedicated Key Management Service (KMS) deployed per tenant within PANW's GCP-based infrastructure. Each tenant has its own isolated KMS instance, ensuring complete separation of key material.

In multitenant environments, each tenant has its own isolated KMS instance and keys, and each one is managed independently.

Two separate keys are used for encrypting tenant data: one for the Data lake BigQuery and another for other services.

Security measures

Cortex BYOK ensures key material is wrapped for protection in transit, and access to the wrapping key is limited solely to the scope of the import job.

The key material is unwrapped solely within the tenant’s KMS using the import job's private key and is inserted as a new version of the target key on the target key ring through an atomic operation. This ensures that no key material is left exposed or in an untrusted state, keeping it secure and preventing potential vulnerabilities, while maintaining its integrity and consistency.

Cortex also provides detailed audit logs within the tenant on all key management operations.

Email notifications are sent for any key management operations, allowing tenant administrators to monitor and review all activities and detect and mitigate any unauthorized access attempts.

BYOK key management operations

BYOK supports the following key management operations. Cortex XSIAM provides detailed audit logs and email notifications on all key management operations.

Set up new tenant with BYOK

Generate your own encryption keys and import them via Cortex Gateway to retain greater control over your tenant data and encryption. This control enables you to implement customized security measures tailored to your organization’s needs and compliance requirements for encrypting your tenant data at rest.

Cortex BYOK uses two keys for encrypting your tenant data at rest: one for the Data lake BigQuery and another for all other tenant services. You can generate a single key for both or create two separate keys.

• If you're doing the activation for the first time, in the Cortex Gateway, follow the Tenant Activation wizard. In Tenant Activation → Define Tenant Settings, under Advanced, select BYOK (Bring Your Own Keys) and click Create Tenant and Set Up Keys.

  The tenant is now initialized, which may take a few minutes. You can set up your keys now, or return at a later stage and click Set Up Encryption Keys next to the tenant in the gateway to continue the process.

• If you've already started the activation process and paused, locate your tenant in the Available Tenants list in the Cortex gateway, click Set Up Encryption Keys next to your tenant and set up your keys.

Rotate encryption keys

To rotate your encryption keys, in the Cortex gateway, open the More options menu next to the tenant, select Rotate Encryption Key, and follow the Bring your own keys (BYOK) setup.

To resume the process, in the main gateway, open the more options menu next to the tenant, select Continue Rotation, and follow the Bring your own keys (BYOK) setup.

As long as the rotation hasn't been completed, you can cancel the rotation process from the three-dot menu next to the tenant.

The new keys you import will serve as primary encryption keys for newly generated data.

For BYOK key rotation, you can select your preferred key import method, replacing the previously fixed default RSA_OAEP_3072_SHA256.

The new recommended default is RSA_OAEP_3072_SHA256_AES_256. To use the previous default method, select it manually.

Disable encryption keys

To disable your encryption keys, in the main gateway, open the three dot menu next to the tenant, select Disable All Keys & Deactivate Tenant.

PREREQUISITE:

To disable your encryption keys and deactivate a tenant, you must have an Account Admin role.

CAUTION:

Disabling all encryption keys and deactivating the tenant renders the tenant inaccessible and non-operational.

Disabling the keys affects communication with the agents, may prevent the agents from receiving updates to policies, configurations, and crucial information, and may result in loss of data.

To secure your tenant data and to prevent unauthorized access, re-enabling the keys and re-activating the tenant are strictly controlled and require manual intervention by the Cortex XSIAM Customer Success team.

To import a new encryption key, whether for initial tenant setup or key rotation, use the Bring your own keys (BYOK) setup.

Bring your own keys (BYOK) setup

Cortex BYOK uses two keys for encrypting your data at rest. One key is for the Data lake and the other is for all the other services within the tenant. You can generate a single key for both or create two separate keys for each service.

You can select your preferred key wrapping algorithm to meet regulatory or compliance requirements.

After completing the process, the imported keys become the primary keys used for encrypting any newly generated data stored within the tenant.

Import new keys for encrypting your tenant data at rest:

1. The Generate Key screen helps you generate an encryption key.

   Generate a key that meets these requirements using your preferred method or use the provided OpenSSL command:

   When your encryption key is ready, select I have a 32-byte symmetric encryption key ready and click Next.

2. In the Wrap & Upload screen, repeat the following procedure for both Data lake wrapping key and Services wrapping key.

   1. Select your import method and download the wrapping key. You can only select your import method the first time you download your key.

      Available import methods are:

      • RSA_OAEP_3072_SHA256_AES_256 (default)
      • RSA_OAEP_4096_SHA256_AES_256
      • RSA_OAEP_3072_SHA256
      • RSA_OAEP_4096_SHA256

      The wrapping key is valid for up to three days. After three days, you need to download a new wrapping key.

   2. Use an OpenSSL editor to wrap your encryption key using the following procedure:

      • For RSA_OAEP_3072_SHA256 and RSA_OAEP_4096_SHA256:

        Wrap the target key using the wrapping public key:
        

        openssl pkeyutl \  
        -encrypt \  
        -pubin \  
        -inkey <full path to the public wrapping key file that ends with .pem> \  
        -in <full path to your target encryption key> \  
        -out  <full path where you want to save the wrapped target key that is ready for import> \  
        -pkeyopt rsa_padding_mode:oaep \  
        -pkeyopt rsa_oaep_md:sha256 \  
        -pkeyopt rsa_mgf1_md:sha256
        

      • For RSA_OAEP_3072_SHA256_AES_256 and RSA_OAEP_4096_SHA256_AES_256:

        1. Patch and recompile OpenSSL. For more details, see Configuring Open SSL for manual key wrapping.

        2. Generate a temporary random AES key:
           

           openssl rand 32 > <full path where you want to save the temporary AES key>
           

        3. Wrap the temporary AES key with the wrapping public key:
           

           openssl pkeyutl \  
           -encrypt \  
           -pubin \  
           -inkey  <full path to the public wrapping key file that ends with .pem>  \  
           -in <full path to your temporary AES key> \ 
           -out <full path where you want to save the wrapped key> \  
           -pkeyopt rsa_padding_mode:oaep \  
           -pkeyopt rsa_oaep_md:sha256 \  
           -pkeyopt rsa_mgf1_md:sha256
           

        4. Wrap the target key with the temporary AES key and append it to the wrapped key:
           

           "<full path to your patched and recompiled (OpenSSL) openssl.sh script>" enc \  
           -id-aes256-wrap-pad \  
           -iv A65959A6 \  
           -K $( hexdump -v -e '/1 "%02x"' < "<full path to your temporary AES key> " ) \  
           -in "<full path to your target encryption key>" >> " <full path to the wrapped key that is now ready for import>"
           

   3. Upload the wrapped key and click Complete Activation.

View the supported Cortex XSIAM hosting regions for tenant deployment and data residency. The following tables list regions for Cortex XSIAM and associated Cortex services.

Cortex XSIAM regions in the Americas

Cortex XSIAM regions in EMEA

Cortex XSIAM regions in JPAC

After you receive your account details, enable and verify access to Cortex XSIAM communication servers, storage buckets, and other resources in your firewall configuration.

Some required IP addresses are registered in the United States. GeoIP databases might not identify their actual usage location. Customer data remains in your deployment region. Data transmission stays restricted to that region.

Before configuring your firewall, review these guidelines:

• Palo Alto Networks App-IDs (firewall policy): If you are using a Palo Alto Networks Firewall, you can simplify your configuration by using App-IDs. If you add the specific App-IDs (for example, cortex-xdr, traps-management-service) to your firewall security policy, you do not need to allow specific IP addresses listed below manually
• App-ID limitations: A dash (—) indicates there is no App-ID coverage for a specific resource. For these rows, you must configure your firewall to allow access based on the IP address and port.
• Rule direction: Enable access from the Cortex XDR Agent to the tenant (outbound); this traffic does not need to be bidirectional.
• Google Cloud Platform (GCP): For resources listing IP ranges in the GCP, go to the official JSON feeds for the specific IP addresses required for your deployment:
  • Global subnets: https://www.gstatic.com/ipranges/goog.json
  • Regional ranges: https://www.gstatic.com/ipranges/cloud.json
• SSL decryption: If you use SSL decryption and experience difficulty connecting the Cortex XDR agent to the server, we recommend that you add the FQDNs required for access to your SSL Decryption Exclusion list in Device → Certificate Management → SSL Decryption Exclusion.

<tenant-name> refers to the selected subdomain of your Cortex XSIAM tenant, and <region> is the region in which your tenant is deployed. For more information, see Cortex XSIAM supported regions.

The following tables list required FQDNs, IP addresses, ports, and App-ID coverage for your deployment.

Use these Cortex XSIAM regional egress resources to configure firewall allowlists for your deployment region. They support agent-to-tenant communication for API access, heartbeats, Live Terminal, and EDR data uploads.

The following table describes the service definition, FQDNs, and App-ID coverage for your deployment. Unless specified, all ports are 443 (TCP). Select your region and allow outbound traffic to the corresponding FQDNs and IPs.

Cortex XSIAM egress service definitions

The following tables list the required resources by region. Unless specified, all ports are 443 (TCP).

Cortex XSIAM egress IP addresses in the Americas

Cortex XSIAM egress IP addresses in EMEA

Cortex XSIAM egress IP addresses in JPAC

Use these Cortex XSIAM engine outbound IP addresses to configure firewall allowlists by deployment region. Automation playbooks and scripts use these IPs to access on-premises resources, such as Active Directory or internal GitLab.

APP-ID: None

Cortex XSIAM engine IP addresses in the Americas

Cortex XSIAM engine IP addresses in EMEA

Cortex XSIAM engine IP addresses in JPAC

Use these Cortex XSIAM inbound source IP addresses to configure firewall allowlists by deployment region. They support inbound communication with Broker VM and syslog resources, plus data collection from SaaS and cloud environments.

Configure your firewall (and relevant receivers) to allow inbound traffic from these Source IPs.

Cortex XSIAM inbound service definitions

• Infrastructure: Communication to your on-premise resources (for example, Broker VM, Syslog)
• Data collection: Traffic from Cortex XSIAM to your network to collect data.
• App-ID: cortex-xdr

Cortex XSIAM inbound IP addresses in the Americas

Cortex XSIAM inbound IP addresses in EMEA

Cortex XSIAM inbound IP addresses in JPAC

Configure firewall access for FedRAMP and US federal government Cortex XSIAM deployments. The following tables list required FQDNs, IP addresses, ports, and App-ID coverage.

Cortex XSIAM egress and engine resources

All ports are 443 unless otherwise specified.

Core Cortex XSIAM communication resources

These resources handle agent registration, heartbeats, data uploads, and API connections. All ports are 443 unless specified otherwise.

Cortex XSIAM content updates and GCP storage

These resources are hosted on Google Cloud Platform. All ports are 443 unless otherwise specified.

Cortex XSIAM Broker VM resources

Required only for deployments utilizing Broker VM features. All ports are 443, unless otherwise stated.

Cortex XSIAM authentication and SSO

Required for administrator login and Single Sign-On. All ports are 443 unless specified

Cortex XSIAM ingress for third-party data collection

Allow traffic from these IPs to your network when collecting data from SaaS and Cloud resources.

Cortex XSIAM log forwarding to a syslog receiver

If you want to send logs to a syslog receiver, you need to enable access to Cortex XSIAM IP addresses for your region in your firewall. For more information, see Integrate a syslog receiver.

Cortex XSIAM uses both Role-Based Access Control (RBAC) and Scope-Based Access Control (SBAC) to manage roles with specific permissions for controlling user access.

RBAC helps manage access to Cortex XSIAM components and Cortex Query Language (XQL) datasets, so that users, based on their roles, are granted minimal access required to accomplish their tasks.

SBAC refines the RBAC permissions by granting access only to the relevant data that the user requires for their designated role. Users with Access Management permission can apply scopes to limit the data and content that users can be granted access to in Cortex XSIAM, which are divided into different scoping areas. The scoping areas include Assets, Cases and Issues, Endpoints, and Datasets Rows, which can be applied as relevant to the enforcement area, entity, or dataset. For more information on user scopes, see Manage user scope.

Cortex Gateway and the tenant have different options and requirements.

Predefined user roles

Cortex XSIAM utilizes Role-Based Access Control (RBAC) to manage user permissions across all tenants and services. This framework ensures a secure separation of duties by granting users only the specific access required for their functional or regional responsibilities. Key features include:

• Predefined Roles: Cortex XSIAM provides default roles with set permissions. While these cannot be edited directly, they can be copied and customized to meet your organization's specific security requirements. To view the predefined permissions for each default role, go to Settings → Configurations → Access Management → Roles.

  For more information about user role-based access permissions, see Role permissions by component

• Centralized Management: Roles can be configured globally within the Cortex Gateway or at the individual tenant level.
• Visibility logic: Users may not see a specific feature if the feature is not supported by the license type or if they do not have access based on their assigned role or scope.

To quickly see exactly which pages and actions a role allows, click on the role name, which opens a read-only view of all checked permissions.

Super user and administrative roles

Security and investigation roles

Specialized domain roles

For all Cloud features, Cortex XSIAM requires a Cloud Posture Security, Cloud Runtime Security, or Cortex XSIAM Premium license. For Application Security scans, you also need the Application Security add-on.

Service account roles

Predefined roles designed for non-human, machine-to-machine authentication within the tenant.

Manage Cortex XSIAM user groups to assign roles, permissions, and access controls. Users receive access through direct role assignments or membership in one or more user groups.

A user group can only be assigned to a single role, but users can be added to multiple groups if they require multiple roles. You can also nest groups to achieve the same effect.

Users who have multiple roles through either method will receive the highest level of access based on the combination of their roles. The same principle for users with multiple roles is followed for both the Role-Based Access Control (RBAC) access permissions and the Scope-Based Access Control (SBAC) granular scoping, so that users receive the highest level of access by combining their roles.

Example

Joe has an Analyst role and is a member of the Tier-1 Analyst user group, which is assigned the Triage role. Joe has the permissions of the Analyst role and the Triage role. Joe is assigned 2 roles and has the highest permission based on the combination of both roles.

• John is a member of two user groups - Tier-1 Analyst and Tier-2 Analyst. One group is configured to use the Triage role and the other group is configured to use the Incident Response role. John is assigned both roles and has the highest permissions based on the combination of all roles.
• Jack is a member of the Tier-2 user group, which has an Incident response role. This user group is included in a Tier-3 user group (Threat Hunter role), added as a nested group. Jack is assigned both roles and has the highest permissions based on the combination of all roles.

On the User Groups page, you can create a new user group for several different system users or groups.

You can see information including the details of all user groups, the roles, nested groups, IdP groups (SAML), and when the group was created/updated.

You can also right-click in the table to edit, save as a new group, remove (delete) a group, and copy text to the clipboard.

Non-administrator users with Access Management permissions cannot create or modify user groups to include the Instance Administrator role. Additionally, the Edit and Delete options are hidden for any user group that holds the Instance Administrator role, whether assigned directly or indirectly (through parent group assignments).

You can create user groups in the tenant or Cortex Gateway.

User groups created in Cortex Gateway do not support SAML group mapping and are shared across all your tenants. We recommend managing user groups directly in the Cortex tenant, because only tenant-based groups support scoping and SAML group mapping.

Managing groups directly in the tenant allows you to maintain different user groups for different environments, such as dev/prod. It also allows you to apply granular scoping to a user group by granting access only to the relevant data that the group members require.

To use scope-based access control (SBAC), you must enable it in the Server Settings page. For more information, see Manage user scope. Before configuring SBAC, ensure that you review Understand scoping in the Manage user scope section.

Cortex XSIAM identity and group provisioning strategies

To govern user-to-group lifecycle relationships within individual tenant workloads, administrators must utilize one of three core provisioning strategies to ingest or evaluate directory identities:

Strategy A: Native local custom groups (default method)

This default method allows you to associate users with groups created and managed within Cortex XDR.

• Methodology: System administrators manually build structural custom groups directly in the tenant console or the Cortex Gateway, explicitly assigning individual accounts into the member list.
• Prerequisites for allocation: The user identity must first exist in the Customer Support Portal (CSP) or have finished a first Single Sign-On (SSO) authentication sequence. For CSP users, the account must also be assigned the specific Cortex User role within the support portal configuration. If this role is not assigned, the user will be unable to log in through the CSP and will only be able to log in through SSO (if configured). For more information, see Set up users, groups, and roles.

Strategy B: SAML dynamic group mapping (IdP is the source of truth)

This approach establishes your corporate Identity Provider (IdP) as the absolute source of truth, allowing group assignments defined in your enterprise directory to be seamlessly reused inside Cortex XDR.

• Methodology: Administrators create user group shells inside Cortex XDR and associate them with the user groups defined in the IdP. This allows you to reuse your existing organizational hierarchy, access permissions, and team structures directly into the security operations console without introducing operational fragmentation or duplicative group-association overhead.
• Note on role requirements: Users who authenticate only through Single Sign-On (SSO) do not require the Cortex User role in the CSP. Their access and permissions are managed via the SAML group mappings and the default role configured in your SSO settings.
• Configuration steps:
  • For Okta environments: For step-by-step instructions, see Set up Okta as the Identity Provider Using SAML 2.0. Pay close attention to configuring the group attribute statement to pass the user's groups in the SAML assertion token.
  • For Microsoft Entra ID (Active Directory) environments: For step-by-step instructions, see Set up Microsoft Entra ID as the Identity Provider Using SAML 2.0. You must configure Entra ID to emit user group claims in the token.
• Critical capitalization requirement: String evaluation across authentication mappings, attribute configurations, and group designations enforces absolute case mapping rules. Strict attention to exact character capitalization must be maintained across all configurations. If the group name string in the IdP does not match the string in Cortex XDR with identical uppercase and lowercase letters, the mapping will fail, and users will not inherit their permissions.
• Active session mechanics: This flow operates dynamically during user login and does not alter or update the permanent group mappings listed within the Cortex XDR console. The session flow works as follows:
  1. The user logs in via SSO.
  2. Based on the SAML assertions coming from the Identity Provider (IdP), the list of IdP groups associated with that user is extracted.
  3. These extracted groups are used to associate the user with the local Cortex Groups based on the SAML Group Mapping field configured within the Cortex group settings.
  4. These mapped groups are associated with the user for the length of the current authenticated session.
  5. Consequently, these groups do not appear in the persistent list of Cortex groups associated with this user inside the Cortex XDR console.

Strategy C: Cloud Identity Engine (CIE) directory sync

This process utilizes the CIE directory to manage and arrange organizational group mappings in advance.

• Methodology: The Cloud Identity Engine (CIE) uses the System for Cross-domain Identity Management (SCIM) protocol to automatically synchronize groups from your Identity Provider (IdP) directly into CIE. Then, Cortex XDR synchronizes the CIE groups that were selected using Import AD Group into its local list of groups.
• Configuration steps: To configure and connect the underlying identity engine pipeline to your enterprise directory infrastructure before mapping groups locally, see the step-by-step onboarding instructions in Set up Cloud Identity Engine.
• Synchronization processing delay: Because the directory sync between CIE and the Cortex tenant runs on a periodic background schedule, a delay of a few hours may occur after the list of groups changes in your IdP, or when a mapping between groups and users changes in CIE.

Important

The Cloud Identity Engine (CIE) is used exclusively for directory group management; it is not utilized for individual user account management, provisioning, or authentication workflows. Consequently, disabling, suspending, or removing user objects directly within CIE does not automatically disable, restrict, or delete those corresponding users inside Cortex XDR. If you use Single Sign-On (SSO) for Cortex XDR authentication, see the User De-provisioning and Restrictions section in Authenticate users using SSO for complete instructions on handling directory lifecycle cleanups and managing stale accounts.

Create a Cortex XSIAM user group

1. Go to Settings → Configurations → Access Management → User Groups.

2. To create a new user group for several different system users or groups, click New Group, and add the following parameters:
   

   Parameter	Description
   Name	Name of the user group.
   Description	Description of the user group.
   Group for product	(Cortex Gateway only) If you have multiple products, select the relevant Cortex product.
   Role	<p>Select the group role associated with this user group. You can only have a single role designated per group.</p><p>In Cortex Gateway, you can only select either Instance Administrator or a custom role created in the Gateway.</p><div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><p>Note</p><p>For non-administrator users, the Instance Administrator role is unavailable from the dropdown menu.</p></div>
   Users	<p>Select the users you want to belong to this user group.</p><div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><p>Note</p><p>If users have been created in the CSP, but you want them to access the tenant through SSO only, skip this field and add only SAML group mapping after SSO is set up, otherwise, users can access the tenant through both the CSP and SSO.</p><p>If you have not yet created any users, skip this field and add them later. See Set up authentication .</p></div>
   Nested Groups	<p>Lists any nested groups associated with this user group. If you have an existing group, you can add a nested group.</p><p>User groups can include multiple users and nested groups, which inherit the permissions of parent user groups. The user group will have the highest level of permission.</p><p>For example:</p><ul><li>Group A has Tier-1 Analyst permissions</li><li>Group B has Tier-2 Analyst permissions</li></ul><p>If you add Group A as a nested group in Group B, Group A inherits Group B's permissions (Tier-1 and Tier-2 permissions).</p><p>In Cortex Gateway, you can only add user groups that are created in Cortex Gateway.</p>
   SAML Group Mapping	<p>(Relevant when creating a user group in the Cortex tenant only.)</p><p>Maps the SAML group membership to this user group. For example, you have defined a Cortex Admins group. You need to name this group exactly how it appears in Okta.</p><p>You can add multiple groups by pressing enter after each name to build a list.</p><div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><p>Note</p><ul><li>Capitalization is vital. String evaluation enforces absolute case mapping rules. The name must match your IdP's string configuration exactly.</li><li>When using Microsoft Entra ID for SSO, the SAML group mapping needs to be provided using the group object ID (GUID) and not the group name.</li><li>Relevant strategy: For functional context and the session mechanics of this configuration, see Strategy B: SAML dynamic group mapping (IdP is the source of truth).</li></ul></div><p>If you have not set up SSO in your tenant, skip this field and add it later. After you have added it, follow the procedure relevant to your IdP. For example, see Set up authentication.</p>

3. (Optional) When creating the user group in the tenant, configure granular scoping for the user group.

   If creating the user group in the Cortex Gateway, you can skip this step, as scoping is only supported in the tenant.

   1. Click the Scope tab.
   2. Expand the scoping areas that you want to grant the user role access to in the tenant by clicking the chevron icon (>) beside the scoping area title, and make any changes required. The following table explains the options available to configure:

   Scoping Area	Granular Scoping Configurations
   Assets	<p>Set the Scope by selecting one of the following:</p><ul><li>No assets: No asset is accessible.</li><li>All assets: Defines access to all assets.</li><li>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).</li></ul><p>The scoping of assets also affects the scoping of cases, issues, and findings.</p><div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><p>Note</p><p>Visibility of Security domain Issues that refer to assets with agents is controlled by the Endpoints scoping configuration.</p></div>
   Cases and Issues	<p>Set the Scope by selecting one of the following:</p><ul><li>No cases and issues: Defines access to no cases and issues.</li><li>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.</li><li><p>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.</p><p>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.</p></li></ul><p>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.</p>
   Endpoints	<p>Set the Scope by selecting one of the following:</p><ul><li>No endpoints: Defines access to no endpoints with no ability to view their related agent management and enterprise policies.</li><li>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.</li><li>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.</li></ul>

Important

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 an administrator or a user with Access Management permissions first ensures that the users, user groups, and API Keys defined in Cortex XSIAM are granted the required access by assigning the relevant scopes. For more information, see Manage user scope.

1. Click Create to create the user group.

Import an Active Directory group into Cortex XSIAM

To automatically synchronize group membership with your organization's Active Directory, you can import an AD group. When someone joins or leaves a team in AD, their Cortex permissions update automatically.

The Import AD Group feature is only enabled when the Cloud Identity Engine (CIE) is connected and configured.

1. Select Settings → Configurations → Access Management → User Groups.
2. Click Import AD Group.

3. In the Role tab, define the following parameters:
   

   Parameter	Description
   Import AD Group	<p>Type to search the CIE in real time, and choose a group or Organizational Unit (OU) to import from Active Directory.</p><div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><p>Only CSP and SSO users already existing in Cortex will be imported.</p></div>
   Description	Description of the imported user group.
   Role	Select the group role associated with this user group. You can only have a single role designated per group.
   SAML Group Mapping	<p>Maps the SAML group membership to this user group. For example, you have defined a Cortex Admins group. You need to name this group exactly how it appears in Okta.</p><p>You can add multiple groups by pressing enter after each name to build a list.</p><div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><p>Note</p><p>When using Microsoft Entra ID for SSO, the SAML group mapping needs to be provided using the group object ID (GUID) and not the group name.</p></div><p>If you have not set up SSO in your tenant, skip this field and add it later. After you have added it, follow the procedure relevant to your IdP.</p>

4. Click the Scope tab to configure granular scoping for the imported group. You can limit the data and content that users can access by configuring the Assets, Cases and Issues, Endpoints, and Datasets Rows options the same as detailed in the custom user group instructions.
5. Click Import.

6. Cortex creates a new User Group of type AD Group and immediately fetches the current members in the background. An update appears in Notifications when the import is complete. Following the import, Cortex XSIAM automatically runs periodic background syncs with the CIE to ensure the group's membership stays up to date.

   If an imported group is later deleted from your Active Directory, Cortex XSIAM automatically deletes the corresponding user group at the next sync cycle.

Assign roles directly to users or create user groups and assign roles to those groups. We recommend creating user groups (with a user role), and assigning users to those user groups rather than creating direct roles for each user.

If an existing user in the Cortex Gateway no longer has a role or a user group assigned, the user is revoked. Any roles, user groups, or egress configurations created by that user are shown as created by Revoked user instead of the user’s email address.

Assign a user/user group to a role

Cortex XSIAM provides predefined built-in user roles that provide specific access rights that cannot be modified. You can also create custom, editable user roles. If a user does not have any Cortex XSIAM access permissions that are assigned specifically to them, the field displays No-Role.

Select Settings → Configurations → Access Management → Users.

Right-click the relevant user and select Edit User Permissions.

To apply the same settings to multiple users, select them, and then right-click and select Edit Users Permissions.

Ensure the Role tab is selected.

Under Role, select the default or custom role.

(Optional) Under User Groups, add the user to a group.

(Optional) Under Show Accumulated Permissions:

1. Do one of the following:
   • Select all to view the combined permissions for every role and user group assigned to the user.
   • Select a specific role assigned to the user to view the available permissions for that role.
2. Under Components, expand each list to view the permissions.

Setting Cortex Query Language (XQL) dataset access permissions for a user role can only be performed from Cortex XSIAM Access Management. For more information, see Manage user roles.

(Optional) You can configure and manage granular scoping:

1. Click the Scope tab.
2. Under Scope Definition, expand the scoping areas that you want to grant the user role access to in the tenant by clicking the chevron icon (>) beside the scoping area title, and make any changes required. The following sections explain the options available to configure:

Before configuring, ensure you review Understand scoping in the Manage user scope section.

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.

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.

Datasets Rows

Configure a filter to define the specific subset of rows a user is allowed to access in each raw dataset. A raw dataset is every dataset where Palo Alto Networks data is ingested out-of-the-box or third-party data is ingested using a configured dedicated collector, also called a data source. This filter configuration does not impact the visibility of cases and issues.

Follow these steps to configure a filter.

1. For datasets where no filter is defined, determine how to set the When no filter is defined option as either:

   • No rows are accessible (default): Without a configured filter, no rows are accessible. Users can query the datasets in Cortex Query Language (XQL) as they have access, but the results will be empty.
   • All rows are accessible: Without a configured filter, all rows are accessible. Users can query the datasets in Cortex Query Language (XQL) as they have access, and view all results.

   When defining a filter for row-level scoping on raw datasets, queries based on the Cortex Data Model (XDM) are not supported. XDM queries return specific rows only when All rows are accessible is selected and no filter is defined in the Datasets Rows scoping area. Otherwise, no rows are returned.

2. Define any filters for the applicable datasets listed in the table:

   1. Scroll down the list of datasets to the dataset you want to apply a filter on, and click the Edit Scope icon.

   2. In the Define what rows are accessible window, continue to write the query for the filter in the query box (where the syntax is a limited subset of XQL) to limit the data rows for the selected dataset according to the access permissions you want the user to have. The beginning of the query is already defined before the query box, and there is no need to include this in your query.

      For optimal performance, we recommend using a single field in the filter definition and simple comparison operators.

      Supported syntax

      Fields

      You can define the rest of the filter in the query box, where only the following system fields are supported: _broker_device_id, _broker_device_ip, _broker_device_name, _collector_id, _collector_ip, _collector_name, _collector_type, _device_id, _final_reporting_device_ip, _final_reporting_device_name, _log_type, _product, _scope, _reporting_device_ip, _reporting_device_name, and _vendor.

      For more information on these fields, see the table that describes all the fields in the metrics_source dataset and metrics_view preset in Overview of data ingestion metrics. For more information on the _scope field (relevant when _scope is defined in the Parsing Rule), see [Scenario 3: Supported fields don't provide the necessary segmentation] in Scenarios related to Datasets Rows scoping.

      Comparison operators

      The following comparison operators are supported:

      • Exact matches (=, !=)
      • Comparing numerical values (>, <, >=, <=)
      • Checking membership in lists (in)
      • Querying arrays (array_contains)
      • Partial matches (contains, starts_with): Using this operator has additional performance overhead, and we recommend avoiding its use.

      If you only want a user to be able to access rows in the pan_dds_raw dataset, when the _collector_name is bu2_collector , you'd have to define the filter in the query box as:

      _collector_name = “bu2_collector”
      

   3. (Optional) Set the Time frame for the query. The default is Last 1 day.
   4. (Optional) You can preview the query results displayed based on your defined query by clicking Preview. You can edit your query until you're satisfied with the output. By default, the query results are limited to 1000 records.

   5. When you are finished, click Done.

      The Scope field for the dataset that you added the filter on is updated with the query.

      In the above example, the Scope field displays _collector_name = “bu2_collector”.

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 an administrator or a user with Access Management permissions first ensures that the users, user groups, and API Keys defined in Cortex XSIAM are granted the required access by assigning the relevant scopes. For more information, see Manage user scope.

Save the user group.

Perform additional tasks

For more information about additional tasks such as creating a custom role, modifying a user's role, or removing a user's role, see Manage user access.

You can create users in the Customer Support Portal or by using SAML Single Sign-On (SSO) in the tenant. Users authenticate by doing the following:

• Authenticate through the Customer Support Portal

  When users log into Cortex Gateway or the tenant (provided they are assigned a role) they are prompted to sign into the Customer Support Portal using their username and password or 2FA (if set up). This is the default method of authentication.

  Use the Customer Support Portal (CSP) if you want to locally manage your users, or if you want them to be able to open support tickets. Conversely, use SAML Single Sign-On (SSO) if you want your organization's external Identity Provider (IdP) to manage user authentication according to your corporate standards.

• Authenticate using SAML single sign-on in the Cortex XSIAM tenant

  Users can be authenticated using your IdP provider such as Okta, Ping, or Microsoft Entra ID. You can use any IdP that supports SAML 2.0. After you configure the SSO integration you need to map group SAML group membership to user groups in Cortex XSIAM. Use SAML Single Sign-On (SSO) configurations when you require Cortex XSIAM users to authenticate according to your organization's precise corporate compliance and access standards as implemented inside your enterprise Identity Provider (IdP). This is critical for enforcing corporate Multi-Factor Authentication (MFA) mandates, complex identity validation, handling automatic de-provisioning (for example, when a user leaves the company), or specific conditional network access policies before granting portal admission.

SSO authentication provides several administrative advantages:

• Removes the administrative burden of requiring separate accounts to be configured through the Customer Support Portal.
• Enforces multi-factor authentication (MFA) and any conditional access policies on the user login at the IdP before granting a user access to Cortex XSIAM.
• Maps SAML group memberships to user groups and roles, allowing you to manage role-based access control.

Customer Support Portal authentication, by contrast, is useful if you have users who need the same permissions across multiple tenants. If you use SSO for multiple tenants, you must set up the SSO configuration separately for each tenant, both in the IdP and in Cortex XSIAM.

To restrict a user to SSO login only, ensure they are not assigned the Cortex User role in the Cortex Gateway. For more information, see Manage users in Cortex Gateway in the Cortex Gateway Administrator Guide. While the CSP login option remains available, the user will be unable to successfully authenticate and must use the SSO login method instead.

For more information, see Assign user roles and groups.

You should have at least one user in the Customer Support Portal for backup, in case of any authentication issues with your IdP provider.

When you add users to your Customer Support Portal account, users are sent an invitation to join. After they accept, users can access Cortex Gateway and tenants, but they cannot view any tenants in the Gateway and cannot view any data in the tenant unless they are assigned a direct role or user group role. Only Account Admins can make any changes in Cortex Gateway.

Keep in mind the following:

• You must be assigned the Super User role in the Customer Support Portal to add users in the Customer Support Portal.
• The first Super User who logs into Cortex Gateway is automatically assigned the Account Admin role and has access to the tenant. The user who activates the Cortex XSIAM tenant will also be assigned the Account Admin role (if there is no current Account Admin role) or Instance Admin (if there is an existing Account Admin role) and will have access to the tenant. Any additional users including Super Users need to be assigned access to the tenant.
• To log in to Cortex XSIAM through the Customer Support Portal (CSP), users must be assigned the Cortex User role in CSP. If this role is not assigned, the user will be unable to log in via the CSP and must use the Single Sign-On (SSO) login method instead.

When users log into Cortex Gateway or the tenant they are prompted to sign into the Customer Support Portal using their username and password. This is the default method of authentication.

After users are added to the Customer Support Portal and they accept the invitation, you can manage them in Cortex Gateway or the Cortex XSIAM tenant.

How to authenticate users through the Customer Support Portal

Add the user to your Customer Support Portal.

Sign in to the Customer Support Portal and do one of the following:

• Create a user
  1. Select Members → Create New User.

  2. Add the member details and click Submit.

     The user must accept the email invitation within seven days.

     For invitation help, see How a Super User Creates a New Customer Support Portal User Account.

• Send an account registration link
  1. Select Account Management → Account Details → User Access.
  2. In Account Registration, click Create.

  3. Copy and send the link to the user.

     The user submits their registration details through the link. The Super User receives a creation notification.

     For link management, see How to Use the Account Registration Link.

Wait for the user to accept

The user accepts the invitation. They can then sign in to Cortex Gateway.

Assign tenant access

In Cortex Gateway or the Cortex XSIAM tenant, assign a role directly. Alternatively, add the user to a user group with a role.

Cortex XSIAM enables you to authenticate system users securely across enterprise-wide applications and websites with one set of credentials using single sign-on (SSO) with SAML 2.0. System users can authenticate using your organization's Identity Provider (IdP), such as Okta or PingOne. You can integrate with any IdP that is supported by SAML 2.0.

Use SAML SSO when you want your platform users to be authenticated according to your organization's precise security standards as implemented within your enterprise IdP. This is critical for enforcing corporate Multi-Factor Authentication (MFA) mandates, identity verification policies, handling automatic de-provisioning (for example, when a user leaves the company), or specific conditional network access rules before granting portal access.

Configuring SSO with SAML 2.0 is dependent on your organization’s IdP. Some of the parameter values need to be supplied from your organization’s IdP and some need to be added to your organization’s IdP. You must have sufficient knowledge about IdPs, how to access your organization’s IdP, which values to add to Cortex XSIAM, and which values to add to your IdP fields.

• To set up SSO authentication in the tenant, you must be assigned an Instance Administrator or Account Admin role.
• SAML 2.0 users must log in to Cortex XSIAM using the FQDN (full URL) of the tenant. To allow login directly from the IdP to the tenant, you must set the relay state on the IdP to the FQDN of the tenant.
• If you have multiple tenants, you must set up the SSO configuration separately for each tenant, both in the IdP and in Cortex XSIAM.
• If you are using AWS SSO, the Application ACS URL refers to the Single Sign-On URL and the Application SAML Audience refers to the Audience URL (SP Entity ID). Both values can be copied from the Authentication Settings in Cortex XSIAM.
• Unlike users who authenticate through the Customer Support Portal (CSP), users who log in via SSO do not require the Cortex User role to be assigned in the CSP. Their access and permissions are governed by the SAML Group Mapping configured in Cortex XSIAM.

Identity provisioning and de-provisioning lifecycle

Just-In-Time (JIT) account creation

When an enterprise user authenticates through your configured Identity Provider (IdP) for the very first time, an explicit user account entry is dynamically generated inside the platform via Just-In-Time (JIT) provisioning. Once provisioned, this newly formed user identity appears within the primary Users Table console.

Following initial JIT creation, administrators can open the account entry to assign targeted Access Management controls, defining precise Roles and granular data Scopes. You can choose to select an optional global Default Role parameter within the general SSO configuration menu to automatically apply baseline permissions to newly provisioned users.

To maintain a secure posture, it is critical that this Default Role is configured with the least-privileged permissions possible (such as read-only or a basic viewer role) to ensure users without explicit role or group assignments inherit minimal access by default.

Security minimization best practice

If a Default Role is utilized for JIT automation, it is strongly recommended to restrict this role to the most minimal, low-privilege read-only permissions possible. This ensures that if a platform administrator forgets to manually apply an explicit target role or scope assignment to a newly synced user, that account remains structurally isolated from sensitive security controls or data views.

Once account objects successfully register via JIT login, administrators can manually pair those known identities directly with local Custom Cortex User Groups within the console.

Deprovisioning and account disabling actions

• Identity Provider (IdP) account suspensions: If a user account is deleted, suspended, or disabled directly within your organization's external Identity Provider (IdP), that target user is blocked from executing any further single sign-on validation attempts into Cortex XSIAM if you set SSO as the authentication method, taking effect upon their next login sequence. For continuity tracking purposes, the historical record for that user will continue to populate inside the internal console Users table until an inactivity threshold triggers a backend purge. For more information, see the [Inactivity removal cycles] policy explained directly below.
• Inactivity removal cycles: For accounts bound to both single sign-on (SSO) pipelines and native Customer Support Portal (CSP) infrastructure, identity profiles and group mappings are automatically purged and removed from the platform console following a specified period of prolonged system inactivity. This inactivity threshold is explicitly configured by navigating to Settings → Configurations → General → Security Settings and selecting Enabled from the Deactivate Inactive User drop-down menu. Selecting this option exposes the Deactivation period field, which is set to 30 days by default, allowing administrators to specify the exact number of inactive days required to trigger user deactivation.
• Cloud Identity Engine (CIE) separation boundary: Disabling, removing, or changing user records directly inside the Cloud Identity Engine interface does not disable, modify, or block corresponding user accounts inside Cortex XSIAM. User lifecycle connectivity is governed purely by active IdP authentication responses or CSP invitation status.

If you are configuring Okta or Microsoft Entra ID, follow the procedure in Okta or Microsoft Entra ID. You can also adapt these instructions for use with any similar SAML 2.0 IdP.

1. In Cortex XSIAM, go to Settings → Configurations → Access Management → Authentication Settings.

2. In the Login Options tab, toggle SSO Disabled to on.

   You can see the SSO settings, so you can configure them according to your organization’s IdP.

3. If you want to add another SSO connection to enable managing user groups with different roles and different IdPs, click Add SSO Connection.

   Different SSO parameters for an SSO are displayed to configure according to your organization’s additional IdP.

   • The first SSO cannot be deleted; it can only be deactivated by toggling SSO Enabled to off.

   • The Domain parameter is predefined for the first SSO.

     If you add additional SSO providers, you must provide the email Domain in the SSO Integration settings for all providers except the first. Cortex XSIAM uses this domain to determine to which identity provider to send the user for authentication.

   • When mapping IdP user groups to Cortex XSIAM user groups, you must include the group attribute for each IdP you want to use. For example, if you are using Microsoft Entra ID and Okta, your Cortex XSIAM user group SAML Group Mapping field must include the IdP groups for each provider. Each group name is separated by a comma.
4. Set the following parameters using your organization’s IdP, where the field parameters are explained in the tables below.
   • General parameters
   • IdP Attribute Mapping
   • Advanced Settings (optional)

5. Save your changes.

   Whenever an SSO user logs in to Cortex XSIAM, the following login options are available.

   • Sign-in with SSO

     If you have enabled more than one SSO provider, an optional email field appears. If the user does not enter an email address or if the email address does not match an existing domain, the user is automatically directed to the default IdP provider (the first in the list of SSO providers in the Authentication Settings). If the user enters an email address and it matches a domain listed in the Domain field in the SSO Integration settings for one of your IdPs, Sign-In with SSO sends the user to the IdP associated with that email domain.

   Programmatic constraint:

   There is no public API endpoint available to provision or de-provision users programmatically within Cortex XSIAM. All target accounts must be initialized or explicitly managed using the native interactive Single Sign-On (SSO) or Customer Support Portal (CSP) interface workflows defined in this guide. To review the list of supported programmatic actions and ingestion endpoints, see the Cortex XSIAM API Reference guide.

General parameters

IdP attribute mapping

These IdP attribute mappings are dependent on your organization’s IdP.

Advanced settings

The following advanced settings are optional to configure and some are specific for a particular IdP.

Troubleshoot SSO issues

The following list describes the common errors and issues when using SAML 2.0 authentication.

• Errors in your IdP could mean the Service Provider Entity ID and/or Service Identifier are not properly configured in the IdP or in the Cortex XSIAM settings.
• SAML attributes from the IdP are not properly mapped in Cortex XSIAM. The attributes are case sensitive and must exactly match in your IdP and in the Cortex XSIAM IdP Attributes Mapping.
• Group memberships from the IdP have not been properly mapped to Cortex XSIAM user groups. Verify the values your identity provider is sending, to properly map the groups in Cortex XSIAM.
• The identity provider is not configured to sign both the SAML response and the assertion on the login token. Your IdP must be configured to sign both to ensure a secure login.
• If you require further troubleshooting, we recommend using your browser's built-in developer tools or additional browser plugins to capture the login request and SAML token.

This topic provides specific instructions for using Okta to authenticate your Cortex XSIAM users. As Okta is a third-party software, specific procedures, and screenshots may change without notice. We encourage you to also review the Okta documentation for app integrations.

To configure SAML SSO in Cortex XSIAM, you must be a user who can access the Cortex XSIAM tenant and have either the Account Admin or Instance Administrator role assigned.

Task 1. Configure Okta Groups

Within Okta, assign users to groups that match the user groups they will belong to in Cortex XSIAM. Users can be assigned to multiple Okta groups and receive permissions associated with multiple user groups in Cortex XSIAM. Use an identifying word or phrase, such as Cortex XSIAM, within the group names. For example, Cortex XSIAM Analysts. This allows you to send only relevant group information to Cortex XSIAM, based on a filter you will set in the group attribute statement.

Create a list of the Okta groups and their corresponding Cortex XSIAM user groups (or the Cortex XSIAM user groups you intend to create) and save this list for later use when configuring user groups in Cortex XSIAM.

Task 2. Copy Single SSO and Audience URI Values from Cortex XSIAM

1. In Cortex XSIAM, go to Settings → Configurations → Access Management → Authentication Settings.
2. In the Login Options tab, toggle SSO Disabled to on.
3. Expand the SSO Integration settings.

4. Copy and save the values for Single Sign-On URL and Audience URI (SP Entity ID).

   Both values are needed to configure your IdP settings.

   You cannot save the enabled SSO Integration at this time, as it requires values from your IdP.

Task 3. Configure Cortex XSIAM Application in Okta

1. In Okta, create a Cortex XSIAM application and Edit the SAML Settings.
2. Paste the Single sign-on URL and the Audience URI (SP Entity ID) that you copied from the Cortex XSIAM SSO settings. The Audience URI should also be pasted in the Default RelayState field, which allows users to log in to Cortex XSIAM directly from the Okta dashboard.
3. Click Show Advanced Settings, verify that Okta is configured to sign both the response and the assertion signature for the SAML token, and then click Hide Advanced Settings.

4. Cortex XSIAM requires the IdP to send four attributes in the SAML token for the authenticating user.

   • Email address
   • Group membership
   • First Name
   • Last Name

   Configure Okta to send group memberships of the users using the memberOf attribute. Use the word or phrase you selected when configuring Okta groups (such as Cortex XSIAM) to create a filter for the relevant groups.

5. Copy the exact names of the attribute statements from Okta and save them, as they are required to configure the Cortex XSIAM SSO integration. In the example above, the names are FirstName, LastName, Email, and memberOf. The attribute names are case-sensitive.

Task 4. Copy IdP SSO URL, Identity Provider Issuer, and X.509 Certificate Values

1. In Okta, from your Cortex XSIAM application page, click View SAML setup instructions. If you do not see this button, verify you are on the Sign On tab of the application.
2. Copy and save the values for Identity Provider Single Sign-On URL, Identity Provider Insurer, and the X.509 Certificate. These values are needed to configure your Cortex XSIAM SSO Integration.

Task 5. Configure the Cortex XSIAM SSO Integration

1. In Cortex XSIAM go to Settings → Configurations → Access Management → Authentication Settings.
2. In the Login Options tab, toggle SSO Disabled to on.
3. Expand the SSO Integration settings.

4. Use the following table to complete the SSO Integration settings, based on the values you saved from Okta.

   Okta	Cortex XSIAM Field
   Identity Provider Single Sign-On URL	IdP SSO URL
   Identity Provider Issuer	IdP Issuer ID
   X.509 Certificate	X.509 Certificate

5. In the IdP Attributes Mapping section, enter the attribute names from Okta. The names are case-sensitive and must match exactly.
6. Save your settings.

Task 6. Map SAML Group Memberships to Cortex XSIAM User Groups

1. Select Settings → Configurations → Access Management → User Groups.
2. Right-click a user group and select Edit Group.
3. In the SAML Group Mapping field add the Okta group(s) that should be associated with this user group. Multiple groups should be separated with a comma. The Okta group name must match the exact value sent in the token.
4. Save your settings.
5. Repeat for each user group.

Task 7. Test SSO Login

1. Go to the Cortex XSIAM tenant URL and Sign-In with SSO.

   Note

   When using SAML 2.0, users are required to authenticate by logging in directly at the tenant URL. They cannot log in via Cortex Gateway.

2. After authentication to Okta, you are redirected again to the Cortex XSIAM tenant.

3. When logged in, validate that you have been assigned the proper roles.

   To view your role and any role assigned to a user group you are a member of, click your name in the bottom left-hand corner, and click About.

This topic provides specific instructions for using Microsoft Entra ID (formerly Azure AD) to authenticate your Cortex XSIAM users. As Microsoft Entra ID is a third-party software, specific procedures, and screenshots may change without notice. We encourage you to also review the Microsoft Entra ID documentation.

To configure SAML SSO in Cortex XSIAM, you must be a user who can access the Cortex XSIAM tenant and have either the Account Admin or Instance Administrator role assigned.

The following video is a step-by-step guide configuring SSO for Microsoft Entra ID: Microsoft Entra ID SSO.

Task 1. Configure Microsoft Entra ID Security Groups

Within Microsoft Entra ID, assign users to security groups that match the user groups they will belong to in Cortex XSIAM. Users can be assigned to multiple Microsoft Entra ID groups and receive permissions associated with multiple user groups in Cortex XSIAM. Use an identifying word or phrase, such as Cortex XSIAM, within the group names. For example, Cortex XSIAM Analysts. This allows you to send only relevant group information to Cortex XSIAM, based on a filter you will set in the group attribute statement.

Task 2. Copy Single SSO and Audience URI Values from Cortex XSIAM

1. In Cortex XSIAM go to Settings → Configurations → Access Management → Authentication Settings.

2. In the Login Options tab, toggle SSO Disabled to on.

   By default, SSO is disabled in Cortex XSIAM.

3. Expand the SSO Integration settings.

4. Copy and save the values for Single Sign-On URL and Audience URI (SP Entity ID).

   Both values are needed to configure your IdP settings.

   Important

   When copying the Single Sign-On URL value, remove idp/saml and leave the trailing /.

   For example, if the Single Sign-On URL is https://clientname.panproduct.region.paloaltonetworks.com/idp/saml, just copy https://clientname.panproduct.region.paloaltonetworks.com/.

5. You cannot save the enabled SSO Integration at this time, as it requires values from your IdP.

Task 3. Configure Cortex XSIAM Application in Microsoft Entra ID

1. From within Microsoft Entra ID, create a Cortex XSIAM application and Edit the Basic SAML Configuration.

   

2. Paste the Single sign-on URL and the Audience URI (SP Entity ID) that you copied from the Cortex XSIAM SSO settings. The Single sign-on URL from Cortex XSIAM should be pasted in the Reply URL and the Sign on URL fields. The Audience URI (SP Entity ID) value from Cortex XSIAM should be pasted in the Identifier (Entity ID) and Relay State fields. This allows users to log in to Cortex XSIAM directly from Microsoft Entra ID.

   

3. In the SAML Certificates section, click Edit and verify that Microsoft Entra ID is configured to sign both the response and the assertion.

   

4. To have Microsoft Entra ID send group membership for the user in the SAML token, you must + Add a group claim in the Attributes & Claims section. Send the Security groups, using the source attribute Group ID. Use the word or phrase you selected when configuring Microsoft Entra ID security groups (such as Cortex XSIAM) to create a filter. Customize the name of the group claim as memberOf.

   

5. In addition to group membership, verify that there are also claims for:

   • Email address
   • First Name
   • Last Name

Task 4. Copy Login URL, Microsoft Entra ID Identifier, and Attribute Claims

1. In Microsoft Entra ID, from the Single sign-on page, in the Set up Cortex XSIAM Production section, copy the values for the Login URL and Microsoft Entra ID Identifier. You need these values to configure the SSO Integration in Cortex XSIAM.

   

2. Edit Attributes & Claims and copy the values in the Claim name column. The claim name is case sensitive. You need these values to configure the SSO Integration in Cortex XSIAM.

   Note

   The default attributes shown on the main single sign-on page in Microsoft Entra ID are not the values you need. You must click Edit next to Attributes and Claims to view and copy the actual values.

   

Task 5. Download the Certificate

From the SAML Certificates section in Microsoft Entra ID, Download the Certificate (Base64). You need the contents of this file to configure the Cortex XSIAM SSO Integration.

Task 6. Copy the Source IDs for Microsoft Entra ID Security Groups

The claim for the membership attribute that is sent to Cortex XSIAM uses the Object Id of the group. The Object Id is different from the Microsoft Entra ID security group name. You can find the Object Id for each of your Microsoft Entra ID security groups by navigating to Users and groups in Microsoft Entra ID, clicking on the group name, and viewing the Object id. Create a list of the group names and corresponding Object Ids for every Microsoft Entra ID security group you want to map to a Cortex XSIAM user group.

Task 7. Configure the Cortex XSIAM SSO Integration

1. In Cortex XSIAM go to Settings → Configurations → Access Management → Authentication Settings.

2. In the Login Options tab, toggle SSO Disabled to on.

   By default, SSO is disabled in Cortex XSIAM.

3. Expand the SSO Integration settings.

4. Use the following table to complete the SSO Integration settings, based on the values you saved from Microsoft Entra ID.

   Microsoft Entra ID	Cortex XSIAM Field
   Login URL	IdP SSO URL
   Microsoft Entra ID Identifier	IdP Issuer ID
   Contents of the downloaded certificate file.	X.509 Certificate

5. In the IdP Attributes Mapping section, enter the attribute claim names from Microsoft Entra ID. The names are case sensitive and must match exactly.

   Note

   The attribute claim name must exactly match the value sent by your IdP. In some cases, this may be the full attribute name/namespace, depending on the configuration of our IdP

   

6. (Optional) Under Advanced Settings, select the checkboxes for ADFS and Compress encode URL (ADFS). In some circumstances, these fields may be required by your Microsoft Entra ID configuration.
7. Save your settings.

Task 8. Map SAML Group Memberships to Cortex XSIAM User Groups

1. Select Settings → Configurations → Access Management → User Groups.
2. Right-click a user group and select Edit Group.
3. In the SAML Group Mapping field add the Microsoft Entra ID group(s) Object Ids that should be associated with this user group. Multiple Object Ids should be separated with a comma. The Microsoft Entra ID group Object Id must match the exact value sent in the token.
4. Save your settings.
5. Repeat for each user group.

Task 9. Test SSO Login

1. Go to the Cortex XSIAM tenant URL and Sign-In with SSO.

   Note

   When using SAML 2.0, users are required to authenticate by logging in directly at the tenant URL. They cannot log in via Cortex Gateway.

2. After authentication to Microsoft Entra ID, you are redirected again to the Cortex XSIAM tenant.

3. When logged in, validate that you have been assigned the proper roles.

   To view your role and any role assigned to a user group you are a member of, click your name in the bottom left-hand corner, and click About.

Cortex XSIAM enables you to collect data across a vast and varied enterprise landscape. This necessitates distinct data source types designed for different environments and needs:

• Standard data collectors (API/Built-in): These are built-in functionalities primarily focused on ingesting raw logs and security events for core security analysis, parsing, and normalization. They often involve direct API connections, such as Okta and CrowdStrike, or file collection tools, such as Amazon S3.
• Broker VM data collector applets: These are modular applications installed on a local Broker VM virtual appliance, designed for on-premise data collection needs like the Syslog Collector or Database Collector.
• XDR Collectors (XDRC): These are lightweight agents dedicated to on-premise log collection on Windows and Linux host machines, typically gathering logs and events using tools such as Filebeat or Winlogbeat.
• Cloud Service Provider (CSP) Onboarding: These are specialized wizards for integrating cloud environments, including AWS, Azure, GCP, and OCI, enabling streamlined setup for asset discovery, posture/runtime security, and log collection.
• Marketplace content packs: These packages offer specialized security functionality by bundling both a collection integration (for data ingestion) and automation components, such as playbooks and correlation rules. Note that not all data collectors have a corresponding Marketplace content pack.

Cortex XSIAM enables you to ingest data from a wide range of third-party vendors and security services. For many popular vendors, we offer a choice between distinct types of data sources to fit your needs:

• Standard data sources (also called data collectors)
• Cloud Service Provider (CSP) onboarding data sources
• Content pack integrations

To add a new data source, see Add a new data source or instance.

To add a content pack from Marketplace, see Install content packs.

The Cloud Identity Engine provides both user identification and user authentication for a centralized cloud-based solution in on-premise, cloud-based, or hybrid network environments. The Cloud Identity Engine allows you to write security policy based on users and groups, not IP addresses, and helps secure your assets by enforcing behavior-based security actions. It also provides the flexibility to adapt to changing security needs and users by making it simpler to configure an identity source or provider in a single unified source of user identity, allowing scalability as needs change. By continually syncing the information from your directories, whether they are on-premise, cloud-based, or hybrid, ensures that your user information is accurate and up to date and policy enforcement continues based on the mappings even if the cloud identity provider is temporarily unavailable.

To provide user, group, and computer information for policy or event context, Palo Alto Networks cloud-based applications and services need access to your directory information. The Cloud Identity Engine, a secure cloud-based infrastructure, provides Palo Alto Networks apps and services with read-only access to your directory information for user visibility and policy enforcement. The components of the Cloud Identity Engine deployment vary based on whether the Cloud Identity Engine is accessing an on-premises directory (such as Active Directory) or a cloud-based directory (such as Microsoft Entra ID).

The authentication component of the Cloud Identity Engine allows you to configure a profile for a SAML 2.0-based identity provider (IdP) that authenticates users by redirecting their access requests through the IdP before granting access. You can also configure a client certificate for user authentication. When you configure an Authentication policy and the Authentication Portal on the Palo Alto Networks firewall, users must log in with their credentials before they can access the resource.

Guidelines for using Cloud Identity Engine with Cortex XSIAM

Keep in mind the following guidelines:

• Cloud Identity Engine is an optional service.
• Cloud Identity Engine must be activated in the same region as Cortex XSIAM.
• You can use Active Directory information in policy configuration and endpoint management.
• Cortex XSIAM supports on-premises Active Directory and Microsoft Entra.
• You can use XQL Query to query the data using the pan_dss_raw dataset.

Activate Cloud Identity Engine

Activating a Cloud Identity Engine instance on your Cortex XSIAM account will allow you to pair your Cortex XSIAM tenant with the Active Directory information collected by the Cloud Identity Engine instance.

Configure Cortex XSIAM with Cloud Identity Engine

After you complete the activation steps, wait about ten minutes and do the following:

1. Log in to Cortex XSIAM.
2. Select Settings → Configuration → Integrations → Cloud Identity Engine.
3. In the Add Cloud Identity Engine dialog box, select the instance name and click Save.

Risk sharing between Cortex XSIAM and the Cloud Identity Engine

Integrate Cortex XSIAM with the Cloud Identity Engine (CIE) to enable dynamic user grouping and access control based on real-time risk assessments. This integration leverages historical events and alerts from Cortex XSIAM to continuously evaluate user and host risk, synchronizing the insights with CIE to support adaptive policy enforcement. When an Okta tenant with an Identity Threat Protection (ITP) license is available, CIE can be connected to Okta to create and apply adaptive policies directly within the Okta environment, based on Cortex Risky users sharing, ensuring responsive and risk-based identity management.

Before you activate the integration, you must complete the onboarding in the Cloud Identity Engine.

1. Configure Cortex XSIAM with Cloud Identity Engine.
2. In the Cloud Identity Engine, onboard the relevant directories, Active Directory, Entra ID, or Okta.

3. In Cortex XSIAM, go to Settings → Configuration → Integrations → Cloud Identity Engine and select Activate risk signal sharing to CIE.

   Note

   The Activate risk signal sharing to CIE checkbox is available only after the second step is completed.

The Cortex XDR agent monitors endpoint activity and collects endpoint data that Cortex XSIAM uses to generate issues. Before you can begin collecting endpoint data, you must create an agent installation package and then install the Cortex XDR agent.

To install the Cortex XDR agent on the endpoint for the first time, create an agent installation package. Review Where can I install the Cortex XDR agent for supported versions and operating systems.

To install the Cortex XDR agent software, you must use a valid installation package that exists in your Cortex XSIAM management console. If you delete an installation package, new agents installed from this package are not able to register with Cortex XSIAM; however, existing agents may re-register using the Agent ID generated by the installation package.

1. From Cortex XSIAM, select Inventory → Endpoints → Agent Installations.
2. Click Create to create a new installer.

3. Enter a unique name and an optional description to identify the installation package.

   The package name can contain letters, numbers, hyphens, underscores, commas, and spaces, and should not exceed 100 characters.

4. Select the Package Type:
   • Standalone Installer: Use for fresh installations and to upgrade agents on a registered endpoint that is connected to Cortex XSIAM.
   • Upgrade from ESM: Use this package to upgrade Traps agents which connect to the on-premises Traps Endpoint Security Manager to Cortex XSIAM. For more information, see Migrate from Traps Endpoint Security Manager.
   • (Linux only) Kubernetes Installer: Use for fresh installations and upgrades of Cortex XDR agents running on Kubernetes clusters.
   • CaaS: Create the Cortex XDR container-embedded agent Dockerfile.
   • Helm Installer: Use this package for fresh installations and upgrades of Cortex XDR agents running on Kubernetes clusters.
   • Serverless Installer: Create an installation package for a serverless function to deploy to your runtime platform.

Guidelines for Kubernetes installer

• Settings for the Kubernetes installer cannot be changed after you create the installation package.

• For Version, select the desired Cortex XDR agent version.

  If the option Always deploy the latest agent version is displayed, do not select it.

• For the Agent Daemonset Namespace, it is recommended to use the default cortex-xdr namespace.
• For a more granular deployment, enter any labels or selectors in the Node Selector. The Cortex XDR agent will be deployed only on these nodes.
• To configure the Cortex XDR agent to communicate through a proxy, enter either the IP address and port number or the FQDN and port number. When you enter the FQDN, you can use both lowercase and uppercase letters. Avoid using special characters or spaces. Use commas to separate multiple addresses.

Guidelines for CaaS container-embedded installer

How to create an agent package for CaaS Workloads:

Before you deploy the container-embedded agent, verify the following:

Requires the Cortex Cloud Runtime Security or Cortex XSIAM Premium license. Every 10 container-embedded agents will consume a single Cortex Runtime Security license.

Prerequisites

Create the container-embedded agent Dockerfile via API:

See the API reference guide: Create Distributions

Create the container-embedded agent Dockerfile via user interface:

1. Go to Inventory → Endpoints → Installations, click Create.
2. Select CaaS Deployment as the Package Type and Container Embedded as the Deployment Type.
   1. Select the installer details to define the configuration settings for version and proxy (optional).
   2. Upload your Dockerfile. Cortex XSIAM validates your Dockerfile against the technical prerequisites.
3. A new Agent Installation instance will be created. Right-click it and download the newly generated Dockerfile.

Embed the Agent container-embedded agent Dockerfile into your container image:

1. Select the newly generated Dockerfile.
2. Re-build your container image using the newly generated Dockerfile.
3. During the build process, the agent binary will be fetched from the Cortex repository and baked into the image.
4. Once the build process is successfully finished, you are ready to use the new container image in your CaaS environments, based on the prerequisites above.

Guidelines for serverless installer

How to create an agent package for a serverless function:

1. Go to Inventory+Endpoints+Installations and click Create.
2. Add a name and description, and add any endpoint tags that will be added to the agent as part of the installation process.
3. For Package Type, select Serverless Function.
4. Configure the following settings for Serverless Function:
   1. For Version, select the required Cortex agent version.
   2. For Cloud Provider, AWS is configured for this release.
   3. For Runtime, select one of the environments:
      • node.js
      • python
   4. For Deployment Type, select the type:
      • Embedded
      • AWS Layers
   5. If node.js and the deployment type AWS Layers are selected, select one of the Modules:
      • ECMAScript
      • CommonJS
   6. For Embed Default Profile From, select from the profile rules configured for serverless functions.

NOTE:

The profile will be applied if the security policy cannot be retrieved in real-time.

The package is created and ready to be deployed.

How to deploy the package to your runtime environment:

1. From Cortex XSIAM, go to Inventory+Endpoints+Installations and from the Agent Installations page, right click and select View Installation Instructions.
2. Depending on the runtime environment, the instructions are slightly different.
   • Agent installation package for embedded python:
     1. Download the serverless agent bundle.
     2. Log in to your AWS Management Console.
     3. Navigate to the AWS Lambda service, and unzip the serverless agent bundle in the main folder.
     4. Add the serverless agent to the function by importing the Cortex library and wrapping the function’s handler.\
        The Cortex serverless library must be imported after other libraries to activate the hooks that enable auditing.
   • Agent installation package for embedded node.js:
     1. Download the serverless agent bundle.
     2. Log in to your AWS Management Console.
     3. Navigate to the AWS Lambda service, and unzip the serverless agent bundle in the main folder.
     4. Add the serverless agent to the function by importing the Cortex library and wrapping the function’s handler.
   • Agent installation package for node.js using AWS Layers in ECMAScript (JavaScript) runtime/Agent installation package for node.js in AWS Lambda using AWS Layers with CommonJS module format:
     1. Download the serverless agent bundle.
     2. Log in to your AWS Management Console.
     3. Navigate to the AWS Lambda service, and upload the layer and add it to the function’s configuration.
     4. Save the current Lamba handler setting in the ORIGINAL_HANDLER environment variable.
     5. Change the Lambda handler setting to cortex.handler.
   • Agent installation package for python using AWS Layers in python runtime/Agent installation package for python in AWS Lambda using AWS Layers with python module format:
     1. Download the serverless agent bundle.
     2. Log in to your AWS Management Console.
     3. Create a new AWS layer with the downloaded bundle, copy the new layer ARN value, and add the new layer using the copied ARN.
     4. Save the current Lamba handler setting in the ORIGINAL_HANDLER environment variable.
     5. Change the Lambda handler setting to cortex.handler.
3. Select the platform and relevant settings, and then click Create.\
   Cortex XSIAM prepares your installation package and displays it on the Agent Installations page.

4. Download your installation package.\
   When the status of the package shows Completed, right-click the package, and click Download.

5. Select the platform and relevant settings, and then click Create.

   Cortex XSIAM prepares your installation package and displays it on the Agent Installations page.

6. Download your installation package.

   When the status of the package shows Completed, right-click the package, and click Download.

After you create and download an installation package, you can then install it directly on an endpoint or you can use a software deployment tool, such as JAMF or GPO, to distribute the software to multiple endpoints.

• For Windows endpoints, select the architecture type. You can download the installer msi file only or a distribution package that includes both the installer msi file and the latest content zip. The distribution package is recommended to reduce the network load and time typically required for the initial roll-out or major upgrades of the Cortex XDR agent. To understand the benefits, workflow, and requirements to support this type of deployment, refer to the Cortex XDR Agent Administrator Guide.
• For macOS endpoints, download the ZIP installation folder and upload it to the endpoint. To deploy the Cortex XDR agent using JAMF, upload the ZIP folder to JAMF. Alternatively, to install the agent manually on the endpoint, unzip the ZIP folder and double-click the pkg file.
• For Linux endpoints, you can download .rpm or .deb installers (according to the endpoint Linux distribution), and deploy the installers on the endpoints using the Linux package manager. Alternatively, you can download a Shell installer and deploy it manually on the endpoint.
• For Kubernetes clusters on Linux endpoints, download the YAML file. We strongly recommend that you do not edit this file.
• For Android endpoints, Cortex XDR creates a tenant-specific download link that you can distribute to Android endpoints. When a newer agent version is available, Cortex XDR identifies older package versions as [Outdated].

Related information

• Cortex XDR Agent Administrator Guide
• Agent iOS Guide
• Agent Android Guide

When the Cortex XDR agent generates an issue on endpoint activity, a minimum set of metadata about the endpoint is sent to the server.

When you enable behavioral threat protection or EDR data collection in your endpoint security policy, the Cortex XDR agent can also continuously monitor endpoint activity for malicious event chains identified by Palo Alto Networks. The endpoint data that the Cortex XDR agent collects when you enable these capabilities varies by platform type.

Metadata collected for Cortex XDR agent issues

When the Cortex XDR agent generates an issue on endpoint activity, the following metadata is sent to the server:

EDR data collected for Windows endpoints

Windows event logs collected for Windows endpoints

Cortex XDR agents can send the following Windows Event Logs to the tenant.

Cortex XSIAM saves the Windows event logs both in xdr_data and in the microsoft_windows_raw dataset.

For more information on how to set up Windows event logs collection, see Microsoft Windows security auditing setup.

EDR data collected for Mac endpoints

EDR data collected for Linux endpoints

IT performance metrics

In addition to the customizable Agent Settings Profiles for each Operating System and different endpoint targets, you can configure global Agent Configurations that apply to all the endpoints in your network.

1. From Cortex XSIAM, select Settings → Configurations → General → Agent Configurations.

2. Set global uninstall password.

   The uninstall password is required to remove a Cortex XDR agent and to grant access to the agent security component on the endpoint. You can use the default uninstall Password1 defined in Cortex XSIAM or set a new one and Save. This global uninstall password applies to all the endpoints (excluding mobile) in your network. If you change the password later on, the new default password applies to all new and existing profiles to which it applied before. If you want to use a different password to uninstall specific agents, you can override the default global uninstall password by setting a different password for those agents in the Agent Settings profile. The selected password must satisfy the requirements enforced by Password Strength indicator.

   A new password must satisfy the following Password Strength indicator requirements:

   • It must be 8 to 32 characters.
   • It must contain at least one upper-case, at least one lower-case letter, at least one number, and at least one of the following characters: !@#%.
3. Manage the content updates bandwidth and frequency in your network.
   • Enable bandwidth control: Palo Alto Networks enables you to control your Cortex XDR agent network consumption by adjusting the bandwidth it is allocated. Based on the number of agents you want to update with content and upgrade packages, active or future agents, the Cortex XSIAM calculator configures the recommended amount of Mbps (Megabits per second) required for a connected agent to retrieve a content update over a 24 hour period or a week. Cortex XSIAM supports between 20 - 10000 Mbps, you can enter one of the recommended values or enter one of your own. For optimized performance and reduced bandwidth consumption, we recommend that you install and update new agents with the latest version, and include the content package built in using SCCM.
   • Enable minor content version updates: The Cortex XSIAM research team releases more frequent content updates in-between major content versions to ensure your network is constantly protected against the latest and newest threats in the wild. Enabled by default, the Cortex XDR agent receives minor content updates, starting with the next content releases. To learn more about the minor content numbering format, refer to the About content updates topic.

4. Configure content bandwidth allocated for all endpoints.

   To control the amount of bandwidth allocated in your network to Cortex XSIAM content updates, assign a Content bandwidth management value between 20-10,000 Mbps. To help you with this calculation, Cortex XSIAM recommends the optimal value of Mbps based on the number of active agents in your network, and including overhead considerations for large content updates. Cortex XSIAM verifies that agents attempting to download the content update are within the allocated bandwidth before beginning the distribution. If the bandwidth has reached its cap, the download will be refused and the agents will attempt again at a later time. After you set the bandwidth, Save the configuration.

5. Configure the Cortex XDR agent number of parallel upgrades.

   If Agent auto upgrades are enabled for your Cortex XDR agents, you can control the automatic upgrade process in your network. To better control the rollout of a new Cortex XDR agent release in your organization, during the first week only a single batch of agents is upgraded. After that, auto-upgrades continue to be deployed across your network with number of parallel upgrades as configured.

   • Amount of Parallel Upgrades: Set the number of parallel agent upgrades, where the maximum is 2000 agents. When you configure this, keep in mind your organization's bandwidth usage and resource consumption.

6. Configure automated Advanced Analysis of Cortex XDR Agent alerts raised by exploit protection modules.

   Advanced Analysis is an additional verification method you can use to validate the verdict issued by the Cortex XDR agent. In addition, Advanced Analysis also helps Palo Alto Networks researchers tune exploit protection modules for accuracy.

   To initiate additional analysis you must retrieve data about the alert from the endpoint. You can do this manually on an alert-by-alert basis or you can enable Cortex XSIAM to automatically retrieve the files.

   After Cortex XSIAM receives the data, it automatically analyzes the memory contents and renders a verdict. When the analysis is complete, Cortex XSIAM displays the results in the Advanced Analysis field of the Additional data view for the data retrieval action on the Action Center. If the Advanced Analysis verdict is benign, you can avoid subsequent blocked files for users that encounter the same behavior by enabling Cortex XSIAM to automatically create and distribute exceptions based on the Advanced Analysis results.

   1. Configure the desired options:
      • Enable Cortex XSIAM to automatically upload defined alert data files for advanced analysis. Advanced Analysis increases the Cortex XSIAM exploit protection module accuracy.
      • Automatically apply Advanced Analysis exceptions to your Global Exceptions list. This will apply all Advanced Analysis exceptions suggested by Cortex XSIAM, regardless of the alert data file source.
   2. Save the Advanced Analysis configuration.

7. Configure the Cortex XDR Agent license revocation and deletion period.

   This configuration applies to standard endpoints only and does not impact the license status of agents for VDIs or Temporary Sessions.

   1. Configure the desired options:
      • Connection Lost (Days): Configure the number of days after which the license should be returned when an agent loses the connection to Cortex XSIAM. Default is 30 days; Range is 2 to 60 days. Day one is counted as the first 24 hours with no connection.
      • Agent Deletion (Days): Configure the number of days after which the agent and related data is removed from the Cortex XSIAM management console and database. Default is 180 days; Range is 3 to 360 days and must exceed the Connection Lost value. Day one is the first 24 hours of lost connection.
   2. Click Save to save the Agent Status configuration.

8. Enable WildFire analysis scoring for files with Benign verdicts.

   The WildFire analysis score for files with a Benign verdict is used to indicate the level of confidence WildFire has in the Benign verdict. For example, a file by a trusted signer or a file that was tested manually gets a high confidence Benign score, whereas a file that did not display any suspicious behavior at the time of testing gets a lower confidence Benign score. To add an additional verification method to such files, enable this setting. After this, when Cortex XSIAM receives a Benign Low Confidence verdict, the agent enforces the Malware Security profile settings you currently have in place (Run local analysis to determine the file verdict, Allow, or Block).

   \
   Disabling this capability takes immediate effect on new hashes, fresh agent installations, and existing security policies. It could take up to a week to take effect on existing agents in your environment pending agent caching.

9. Enable Informative BTP Alerts.

   Behavioral threat protection (BTP) alerts have been given unique and informative names and descriptions, to provide immediate clarity into the events without having to drill down into each alert. Enable to display of the informative BTP rule alert names and descriptions. After you update the settings, new alerts include the changes while already existing alerts remain unaffected.

   \
   If you have any Cortex XSIAM filters, starring policies, exclusion policies, scoring rules, log forwarding queries, or automation rules configured for XSOAR/3rd party SIEM, we advise you to update those to support the changes before activating the feature. For example, change the query to include the previous description that is still available in the new description, instead of searching for an exact match.

10. Configure settings for periodic cleanup of duplicate entities in the endpoint administration table.

    When enabled, Periodic duplicate cleanup removes all duplicate entries of an endpoint from the endpoint table based on the defined parameters, leaving only the last occurrence of the endpoint reporting to the server. This enables you to streamline and improve the management of your endpoints. For example, when an endpoint reconnects after a hardware change, it may be re-registered, leading to confusion in the endpoint administration table regarding the real status of the endpoint. The cleanup leaves only the latest record of the endpoint in the table.

    • Define whether to clean up according to Host Name, Host IP Address, MAC Address, or any combination of them. If not selected, the default is Host Name. When you select more than one parameter, duplicate entries are removed only if they include all the selected parameters.
    • Configure the frequency of the cleanup: every 6 hours, 12 hours, 1 day, or 7 days. You can also select to perform an immediate One-time cleanup.

    Data for a deleted endpoint is retained for 90 days since the endpoint’s last connection to the system. If a deleted endpoint reconnects, Cortex XSIAM recovers its existing data.

You can define an endpoint group and then apply policy rules and manage specific endpoints. If you set up Cloud Identity Engine, you can also leverage your Active Directory user, group, and computer details to define endpoint groups.

Do one of the following:

• Create a dynamic group by enabling Cortex XSIAM to populate your endpoint group dynamically using endpoint characteristics, such as an endpoint tag, partial hostname or alias, full or partial domain or workgroup name, IP address, range or subnets, installation type (VDI, temporary session or standard endpoint), agent version, endpoint type (workstation, server, mobile), user or operating system version.
• Create a static group by selecting a list of specific endpoints.

Configuration based on user granular policy is optimized for VDI and session-persistent environments; it is not recommended for decentralized or traditional endpoint architectures.

After you define an endpoint group, you can then use it to target policy and actions to specific recipients. The Endpoint Groups page displays all endpoint groups along with the number of endpoints and policy rules linked to the endpoint group.

How to define an endpoint group

1. Select Inventory → Endpoints → Groups → +Add Group.
2. Select one of the following:
   • Create New to create an endpoint group from scratch
   • Upload From File using plain text files with a new line separator, to populate a static endpoint group from a file containing IP addresses, hostnames, or aliases.
3. Enter a Group Name and optional description to identify the endpoint group. The name you assign to the group will be visible when you assign endpoint security profiles to endpoints.

4. Determine the endpoint properties for creating an endpoint group:

   • Dynamic: Use the filters to define the criteria you want to use to dynamically populate an endpoint group. Dynamic groups support multiple criteria selections and can use AND or OR operators. For endpoint names and aliases, and domains and workgroups, you can use * to match any string of characters. As you apply filters, Cortex XSIAM displays any registered endpoint matches to help you validate your filter criteria.

   • Static: Select specific registered endpoints that you want to include in the endpoint group. Use the filters, as needed, to reduce the number of results.

     When you create a static endpoint group from a file, the IP address, hostname, or alias of the endpoint must match an existing agent that has registered with Cortex XSIAM. You can select up to 250 endpoints.

   Disconnecting Cloud Identity Engine in your Cortex XSIAM deployment can affect existing endpoint groups and policy rules based on Active Directory properties.

5. Create the endpoint group.

   After you save your endpoint group, it is ready for use to assign security profiles to endpoints and in other places where you can use endpoint groups.

At any time, you can return to the Groups page to view and manage your endpoint groups. To manage a group, right-click the group and select the desired action:

• Edit: View the endpoints that match the group definition, and optionally refine the membership criteria using filters.
• Delete: Remove the endpoint group.
• Save as new: Duplicate the endpoint group and save it as a new group.
• Export group: Export the list of endpoints that match the endpoint group criteria to a tab separated values (TSV) file.
• View endpoints: Pivot from an endpoint group to a filtered list of endpoints on the All Endpoints page where you can quickly view and initiate actions on the endpoints within the group.

Cortex XSIAM provides default security profiles that you can use out of the box to immediately begin protecting your endpoints from threats. These profiles are applied to endpoints by mapping them to policies and then mapping the policies to endpoints.

While security rules enable you to block or allow files to run on your endpoints, security profiles help you customize and reuse settings across different groups of endpoints. When the Cortex XDR agent detects behavior that matches a rule defined in your security policy, it applies the security profile that is attached to the rule for further inspection.

This topic covers a recommended strategy and best practices for managing agent and content updates to help reduce the risk of downtime in a production environment, while helping ensure timely delivery of security content and capabilities.

Keeping Cortex XDR agents up-to-date is essential for protecting against evolving threats and vulnerabilities. Regular updates ensure the latest security features for malware and exploit prevention, and compatibility with the latest software environments, which helps reduce the risk of attacks. This can also help organizations meet regulatory standards while maintaining strong overall protection.

Content updates, such as new threat intelligence or detection logic, are critical for defending against newly discovered cyber threats and malware and are designed to ensure that systems remain protected against the latest attacks. Content updates, released on a weekly basis, address compatibility issues as well, helping to achieve smooth operations alongside the Cortex XDR agent. Without regular content updates, security solutions may fail to detect new or evolving threats, leaving systems vulnerable to attacks.

The Cortex XDR agent can retrieve content updates immediately as they become available, or after a pre-configured delay period of up to 30 days. In addition, to expedite testing and evaluation, the staging content provides a preview of the content update a week before its published GA.

When planning Cortex XDR agent upgrades and content updates, consult with the appropriate stakeholders and teams and follow the change management strategy in your organization.

Cortex XSIAM can be configured to manage the deployment of agent and content updates by adjusting the following settings:

Agent upgrade settings

Agent settings per endpoint:

• Agent Auto-Upgrade is disabled by default. Before enabling agent auto-upgrade for Cortex XDR agents, make sure to consult with all relevant stakeholders in your organization. Enabling this option allows you to define the scope of the automatic updates, such as upgrading to the latest agent release, one release prior, only maintenance releases, or maintenance releases within a specific version.
• Upgrade Rollout includes two options: Immediate, where the Cortex XDR agent automatically receives new releases, including maintenance updates and features, and Delayed, which lets you set a delay of 7 to 45 days after a version is released before upgrading endpoints.
• Agent Upgrade Scheduler allows the upgrade task to be scheduled for specific days of the week and a specific time range.

Global agent settings: Configure the number of parallel upgrades to apply to all endpoints in your organization.

Content update settings

Content updates per endpoint:

• Content Auto-Update is enabled by default and automatically retrieves the latest content before deploying it on the endpoint. If you disable content updates, the agent will stop fetching updates from the Cortex XSIAM tenant and will continue to operate with the existing content on the endpoint.
• Content Rollout: The Cortex XDR agent can retrieve content updates immediately as they become available, after a pre-configured delay period of up to 30 days. Utilize the staging content for early evaluation on test environments before the content is released to production.

Global content updates: Configure the content update cadence and bandwidth allocation within your organization. To enforce immediate protection against the latest threats, enable minor content updates. Otherwise, the content updates in your network occur only on major releases.

Guidelines for planning Cortex XDR agent upgrades

Use a phased rollout plan by creating batches for deploying updates. The specifics may vary based on your organization and its structure. Start with a control group, then deploy to 10% of your organization. Subsequently, allocate the remaining upgrades in batches that best suit your organization until achieving a full 100% rollout.

Example

The following is an example of a rollout plan for deploying a Cortex XDR agent upgrade:

Phase 1: Control group rollout: Start by selecting a control group of endpoints as early adopters. This group should consist of a diverse range of operating systems, devices, applications, and servers, with a focus on low-risk endpoints. After a defined testing period, such as one week, assess for any issues. If no problems are found, move to the next phase.

Phase 2: 10% rollout: Expand the rollout to 10% of the organization’s endpoints. This group should maintain the same variety as the control group but include low- to medium-risk endpoints. Monitor performance during the set period. If the rollout is successful with no issues, proceed to the next phase.

Phase 3: 40% rollout: After confirming the success of the 10% rollout, extend the deployment to 40% of the organization. Continue including a variety of endpoints while gradually incorporating some medium-risk endpoints. Ensure thorough testing during this phase before moving forward.

Phase 4: 80% rollout: Extend the deployment to 80% of the organization's endpoints. This batch should include a wide variety of endpoints, incorporating both medium and high-risk systems. After a careful monitoring period and confirmation that everything is stable, move to the final phase.

Phase 5: Full rollout: Complete the rollout by updating the remaining 20% of the organization’s endpoints. By this point, the majority of systems should have been thoroughly tested, reducing the risk of issues in the final stage. Once complete, 100% of the organization will be updated.

Guidelines for planning content updates

Content updates consist of detection rules and operational logic, and are typically released on a weekly basis. Staging content provides a preview of the content update a week before the published GA.

Use a phased rollout plan by creating batches for deploying updates. Start with a control group, then deploy to 10% of your organization. Subsequently, allocate the remaining upgrades in batches that best suit your organization until achieving a full 100% rollout.

For early evaluation, select a small test group or a lab environment for enabling the staging content preview.

Example

The following is an example of a rollout plan over a period of one week for deploying content updates:

Phase 1: Control group rollout: Keep the default configuration set to deploy content updates immediately.

Phase 2: 10% rollout: Content is automatically deployed on day 2 following a delay period defined in the profile.

Phase 3: 60% rollout: Content is automatically deployed on day 3 following a delay period defined in the profile.

Phase 4: Full rollout: Increase the deployment to include medium and high-risk systems, until the entire organization is updated.

How to configure agent and content update settings

The following information will help you select and configure the update settings.

Cortex XDR agent upgrades

Configure one or more of the following settings to keep your Cortex XDR agents up-to-date.

Distribute agent upgrades to selected endpoints

1. Create an agent installation package for each operating system version for which you want to upgrade the Cortex XDR agent.

   Note the installation package names.

2. Select Inventory → Endpoints → All Endpoints.

   If needed, filter the list of endpoints. To reduce the number of results, use the endpoint name search and filters at the top of the page.

3. Select the endpoints you want to upgrade.

   You can also select endpoints running different operating systems to upgrade the agents at the same time.

4. Right-click your selection and select Endpoint Control → Upgrade Agent Version.

   For each platform, select the name of the installation package you want to push to the selected endpoints.

   You can install the Cortex XDR agent on Linux endpoints using a package manager. If you do not want to use the package manager, clear the option Upgrade to installation by package manager.

   When you upgrade an agent on a Linux endpoint that is not using a package manager, Cortex XSIAM upgrades the installation process by default according to the endpoint Linux distribution.

   The Cortex XDR agent keeps the name of the original installation package after every upgrade.

5. Upgrade.

   Cortex XSIAM distributes the installation package to the selected endpoints at the next heartbeat communication with the agent. To monitor the status of the upgrades, go to Investigation and Response → Response → Action Center.

   From the Action Center you can also view additional information about the upgrade (right-click the action and select Additional data) or cancel the upgrade (right-click the action and select Cancel Agent Upgrade).

   • Custom dashboards that include upgrade status widgets, and the All Endpoints page display upgrade status.
   • During the upgrade process, the endpoint operating system might request a reboot. However, you do not have to perform the reboot for the Cortex XDR agent upgrade process to complete it successfully.
   • After you upgrade on an endpoint with Cortex XSIAM Device Control rules, you need to reboot the endpoint for the rules to take effect.

Agent settings per endpoint

These profiles can be configured on one or more endpoints, static/dynamic groups, tags, IP ranges, endpoint names, or other parameters that allow the creation of logical endpoint groups. See how to define endpoint group.

1. Go to Inventory → Endpoints → Policy Management → Profiles, and then edit an existing profile, add a new profile, or import from a file.

2. If you're adding a new profile, select the operating system and Agent Settings. Then click Next.

   If you want to edit an existing profile, hover over Agent Settings for the operating system and click View Profile.

3. Select Agent Upgrade. By default, this option is disabled.

   Before enabling Auto-Update for Cortex XDR agents, make sure to consult with all relevant stakeholders in your organization.

The following table describes the available Agent Auto-Upgrade options:

Global agent settings

Configure the Cortex XDR agent upgrade scheduler and the number of parallel upgrades to apply to all endpoints in your organization.

1. Go to Settings → Configurations → Agent Configurations, and scroll to Agent upgrade.

2. Configure the Cortex XDR agent upgrade scheduler and the number of parallel upgrades.

   Item	Description
   Amount of parallel upgrades	<p>During the first week of a new Cortex XDR agent release rollout, only a single batch of agents is upgraded. After that, auto-upgrades continue to be deployed across your network with the number of parallel upgrades as configured.</p><p>Set the number of parallel agent upgrades, where the maximum is 500 agents.</p>

Content updates

When a new content update is available, Cortex XSIAM notifies the Cortex XDR agent. The Cortex XDR agent then randomly chooses a time within a six-hour window during which it will retrieve the content update from Cortex XSIAM. By staggering the distribution of content updates, Cortex XSIAM reduces the bandwidth load and prevents bandwidth saturation due to the high volume and size of the content updates across many endpoints. You can view the distribution of endpoints by content update version from the dashboard.

You can configure whether to update content per endpoint or use the global settings.

| |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |

Content update settings per endpoint

Configure content update options for agents within the organization to ensure it is always protected with the latest security measures.

These profiles can be configured on one or more endpoints, static/dynamic groups, tags, IP ranges, endpoint names, or other parameters that allow the creation of logical endpoint groups.

The following table describes the available Content Configuration options:

1. Go to Inventory → Endpoints → Policy Management → Profiles, and then edit an existing profile, add a new profile, or import from a file.

2. If you're adding a new profile, select the operating system and Agent Settings. Then click Next.

   If you want to edit an existing profile, hover over Agent Settings for the operating system and click View Profile.

3. Select Content Configuration. By default, this option is Enabled.

Global content update settings

1. Go to Settings → Configurations → Agent Configurations, and scroll to Content Management.

2. Configure the content update cadence and bandwidth allocation within your organization.

   Item	Description
   Enable bandwidth control	Based on the number of agents you want to update with content and upgrade packages, active or future agents, the Cortex XSIAM calculator configures the recommended amount of Mbps (Megabits per second) required for a connected agent to retrieve a content update over a 24 hour period or a week. Cortex XSIAM supports between 20 - 10000 Mbps, you can enter one of the recommended values or enter one of your own. For optimized performance and reduced bandwidth consumption, it is recommended that you install and update new agents with Cortex XDR agents 7.3 and later include the content package built in using SCCM.
   XDR Calculator for Recommended Bandwidth	<p>Based on the number of agents you want to update with content and upgrade packages, active or future agents, the Cortex XSIAM calculator configures the recommended amount of Mbps (Megabits per second) required for a connected agent to retrieve a content update over 24 hours or a week. This calculation is based on connected agents and includes an overhead for large content update.</p><p>Cortex XSIAM supports between 20 - 10000 Mbps.</p><p>It is recommended to allocate a minimum of 20 Mbps, or you can enter a value.</p>
   Enable minor content version updates	To enforce immediate protection against the latest threats, enable minor content updates. Otherwise, the content updates in your network occur only on major releases.

The Cortex XSIAM Analytics engine enables Cortex XSIAM to analyze data from a variety of sensors and develop a baseline to raise analytics alerts when anomalies and malicious behaviors are detected.

Prerequisite

Before Cortex XSIAM - Analytics can start to analyze your endpoint data, perform the following steps:

1. Configure Cortex XSIAM network parameters to monitor your internal networks.
2. Enable the Analytics Engine.
3. Make sure Cloud Identity Engine is set up.
4. Enable Identity Analytics.

Define your internal IP address ranges and domain names to enable Cortex XSIAM to identify, track, and analyze network assets.

Define internal IP address ranges

The IP Address Ranges page displays the address ranges that Cortex XSIAM Analytics monitors. Addresses are pre-populated with the default IPv4 and IPv6 address spaces. The names you define appear when investigating the network-related events in Cortex XSIAM.

You can add a new IP address range manually or upload IP address ranges from a CSV file.

How to define internal IP address ranges

1. Select Inventory → Assets → Network Configuration → Internal IP Address Ranges.

2. Do one of the following:

   To	Do this
   Add a new IP address manually	<p>1. Click Add New Range → Create New, and then enter the IP address name and IP address range or CIDR values.</p><p>By default, Cortex XSIAM creates Private Network ranges that specify reserved industry-approved ranges. Private Network ranges are marked with a icon and you can only edit the name.</p><div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><p>You can add a range that is fully contained in an existing range; however, you cannot add a new range that partially intersects with another range.</p></div><p>2. Click Save.</p>
   Upload IP address ranges from a CSV file	<p>1. Select Inventory+Assets → Network Configuration → IP Address Ranges.</p><p>2. Click Add New Range → Upload from File.</p><p>3. Locate the CSV file you want to upload, and then click Add.</p>

Define internal domain names

1. Select Inventory → Assets → Network Configuration → Internal Domain Suffixes.
2. Type the domain suffix you want to include as part of your internal network, for example, acme.com.
3. Select to add the suffix to the Domains List.

Cortex XSIAM - Analytics includes the following:

• Cortex XSIAM Analytics Engine: Analyzes your endpoint data to develop a baseline and raise Analytics and Analytics BIOC alerts when anomalies and malicious behaviors are detected.
• Identity Analytics: Allows the Cortex XSIAM Analytics engine to aggregate and display user profile details, activities, and alerts related to a user-based Analytics type alert and Analytics BIOC rule during an investigation.

Prerequisite

Analytics Engine

To create a baseline for enabling analytics, Cortex XSIAM requires a minimum of one of the following data sets:

• EDR or Network logs from at least 30 endpoints over a minimum of 2 weeks
• Cloud audit logs over a minimum of 5 days

Identity Analytics

• Cortex XSIAM - Analytics must be activated.
• Cloud Identity Engine must be set up. For more information, see Cloud Identity Engine.

How to enable analytics

1. Select Settings → Configurations → Cortex XSIAM - Analytics.

2. Click Enable. Creating a baseline can take up to three hours.

   Adding Windows DHCP logs can enhance the Analytics Engine. For more information, see Ingest Windows DHCP Logs with an XDR Collector Profile.

3. Activate Identity Analytics by turning on the toggle.

The Federal Risk and Authorization Management Program (FedRAMP) provides a standardized approach to security assessment, authorization, and continuous monitoring for cloud products and services used by the U.S. government. This program ensures that federal information remains secure while allowing agencies to adopt cloud solutions efficiently.

Cortex XSIAM is FedRAMP High- and Moderate-authorized for U.S. federal agencies and regulated industries. FedRAMP-authorized Cortex XSIAM tenants provide isolated government cloud environments, U.S. data residency, and secure federal network access.

FedRAMP security and infrastructure architecture

FedRAMP Cortex XSIAM environments use the following compliance safeguards:

• Isolation: Dedicated single-tenant instances that are physically and logically isolated from the commercial user base.
• Data sovereignty: All logs and ingested data remain strictly within the United States.
• Infrastructure: Usage of government-specific infrastructure, such as AWS GovCloud or Azure Government.
• Secure egress: Implementation of federal FQDNs, such as p-proxy.federal.paloaltonetworks.com, to secure all egress traffic paths.
• Scanning rights: FedRAMP instances are authorized to scan both secure government and standard commercial cloud accounts, whereas commercial instances are strictly prohibited from accessing government-authorized environments.

Software Composition Analysis (SCA) in FedRAMP

Application Security Software Composition Analysis (SCA) is available in FedRAMP and Government (Gov) tenant environments. Organizations operating under FedRAMP or public-sector compliance requirements can scan open-source dependencies for known vulnerabilities (CVEs), license miscompliance, and package operational risks using the same SCA scanner available in commercial environments.

SCA in FedRAMP/Gov tenants uses the same enablement and prerequisites as commercial tenants:

• The Application Security module is active on the tenant
• At least one VCS integration is onboarded
• The SCA scanner is enabled for the target repositories
• At least one periodic or PR scan has completed

No FedRAMP-specific configuration is required.

For more information on SCA, refer to Software Composition Analysis (SCA ).

Use the following steps to onboard and configure a government-authorized cloud environment in Cortex XSIAM. These settings support federal security requirements for Government CSP environments.

Government cloud onboarding and configuration

1. Onboarding: Use the cloud onboarding wizard to connect a Government Cloud Service Provider (CSP) environment to Cortex XSIAM.
2. Environment selection: During configuration, select the Government option in the Environment menu to ensure the tenant adheres to federal security standards.

3. Scan mode: You can select Cloud Scan or Scan with Outpost.

   If you choose an outpost scan, you must select an outpost that has the environment type defined as Government to maintain compliance and connectivity.

Cortex XSIAM FedRAMP Government deployments support specific cloud services and regions. Review these service limitations before onboarding federal cloud environments.

FedRAMP service limitations

• Unsupported features: FedRAMP Government instances do not currently support these DSPM services:
  • AWS: RDS/Aurora scanning
  • DBaaS: Snowflake, Databricks
  • Microsoft 365
  • Azure: All services (this is not supported for both DSPM and AISPM services)
• Environmental restrictions: Multi-tenant or MSSP environments are not currently supported by FedRAMP.
• Permitted capabilities: Other capabilities, such as registry scanning, serverless scanning, and agentless disk scanning, are allowed.

Supported AWS GovCloud and Azure Government regions

Supported regions are limited to AWS GovCloud regions and Microsoft Azure government regions.

Once your Cortex XSIAM is operational, start post-deployment, such as performing health checks, configuring automations, and reviewing cases and issues.

Key post-deployment topics include:

• post-deployment-checklist
• perform-health-checks
• cortex-marketplace
• manage-user-roles-and-access-management
• dashboards-and-reports
• configure-server-settings
• configure-security-settings
• data-and-log-forwarding

Use this Cortex XSIAM post-deployment checklist after onboarding. Start with health checks and case triage. Then configure integrations, expand the Cortex XDR agent rollout, and deploy on-premises components.

This checklist includes post-deployment for the Cortex XSIAM environment, but does not include any specific Cloud Security requirements. For more information about Cloud Security onboarding, see Cloud service provider (CSP) onboarding.

Initial Cortex XSIAM post-deployment actions

The following table describes the post-deployment steps for the most critical areas to get you up and running quickly.

Advanced Cortex XSIAM post-deployment actions

General

This section includes general post-deployment steps, such as server and security settings, configuring dashboards, and refining RBAC roles.

Expand the XDR Agent deployment

This stage involves customizing policies and gradually rolling out the XDR Agent to all users.

Deploy additional On-prem components

Deploy additional on-prem components for data ingestion, collection, and automation for complete protection. Although these components are optional, XDR Collectors and the Broker VM are critical for this next deployment phase. The Broker VM is often highly recommended early on because it can solve immediate connectivity and log collection challenges for on-prem identity sources.

After completing the post-deployment steps, you can now start configuring Cortex XSIAM.

As part of the onboarding process, it is recommended to perform the following health checks:

• Update prevention policies: Update policies and profiles, and ensure that all action modes are set to Block. For more information, seeset-up-endpoint-protection.
• Monitor operational status: Verify that Cortex XDR agents are protecting endpoints according to predefined security policies and profiles. For more information, see Monitor agent operational status in Cortex XSIAM.
• Test sample malware: Use a malware PE, MacOSX, or APK test file, to test end-to-end WildFire sample processing. For more information, see Get a Malware Test File.
• Validate detectors for issues and cases: Check issues and their associated sources. Validate that all the configurations on the policy level and on the agent deployment level meet the requirements to generate alerts and cases on Cortex XSIAM. For example, check the following:
  • Cortex XDR agent generates WildFire malware issues.
  • NFGW issues are listed by PAN NGFW.
• Validate log ingestion from external integrations: Verify what datasets are being created. The Dataset Management page enables you to manage your datasets and understand your overall data storage duration for different retention periods and datasets based on your Hot and Cold Storage licenses and retention add-ons to extend your storage. For more information, see Data storage lifecycle.

Cortex XSIAM provides information about the XDR agent operational status on an endpoint. It indicates whether the agent provides protection according to its predefined security policies and profiles. This information can help you identify technical issues or misconfigurations that interfere with the agent’s protection capabilities or interactions with Cortex XSIAM and other applications.

The XDR agent reports the operational status as follows:

• Protected: Indicates that the XDR agent is running as configured and did not report any exceptions to Cortex XSIAM.
• Partially protected: Indicates that the XDR agent reported one or more exceptions to Cortex XSIAM.
• Unprotected: Indicates the XDR agent is not enforcing protection on the endpoint.
• Local Resource Impact: Indicates that available endpoint resources are insufficient for the XDR agent to operate smoothly.

You can monitor the Cortex XDR agent Operational Status in Endpoints → All Endpoints.

The reported operational status varies according to exceptions reported by the XDR agent.

A status can have the following implications for the endpoint:

• *(Status): The exploit protection module is not running.
• **(Status):
  • XDR data collection is not running
  • Behavioral threat protection is not running
  • Anti-malware flow is asynchronous
  • Local privilege escalation protection is asynchronous

Content in Marketplace is organized into content packs to support specific security orchestration use cases. Content packs are created by Palo Alto Networks, technology partners, contributors, and customers.

In Marketplace, content includes the following:

Cortex XSIAM supports free content packs, which are either Cortex XSIAM or partner-supported content packs. You can restrict a user role from managing content packs in Marketplace when defining/editing user roles.

In Marketplace, you can browse all content packs (including installed content) or view only installed content packs.

You can search for content packs by entering text in the search bar and selecting the relevant content pack from the search results.

You can sort content packs by latest update, best match, recommended, number of downloads, and filter according to the following criteria:

• Use cases: Filter according to high-level use cases, such as Phishing, Malware, Ransomware, and Access.
• Integrations: Filter according to the integration included in the content pack.
• Categories: Filter according to content pack categories, such as Messaging, and Forensics & Malware Analysis
• Published: Filter according to whether published by Cortex XSIAM or by Cortex XSIAM technology partners.
• Content Pack Includes: Filter according to the content of the content pack, such as scripts, integrations, playbooks, and actions.
• Tags: Filter according to tags, such as Issues, Actions, Network, and Security.
• Types: Filter according to Collection or TIM.

When clicking a content pack you can view detailed information including content that it installs (such as scripts, playbooks, and integrations), dependencies (what content packs are required or optional) and version history (including whether you want to roll back to earlier versions).

You can view Marketplace content packs from within Cortex XSIAM (go to Settings → Configurations → Marketplace) or at Cortex Developer Docs Marketplace.

Cortex Marketplace content packs bundle integrations, scripts, playbooks, widgets, and other components for security automation workflows. Palo Alto Networks, technology partners, consulting companies, MSSPs, customers, and contributors create content packs. Content packs are free for all customers.

You can view Marketplace content packs from within Cortex XSIAM (go to Settings → Configurations → Marketplace) or at Cortex Developer Docs Marketplace.

Pre-installed Cortex Marketplace content packs

Cortex XSIAM includes pre-installed content packs for common security use cases. These content packs include, but are not limited to:

• Common Scripts, Common Widgets, Common Playbooks, Common Types, Common Reports, Common Dashboards

  These content packs provide important tools and building blocks you can use to customize your playbooks and workflows in Cortex XSIAM. The Common Scripts content pack, for example, includes scripts that convert file formats, fetch indicators from a file, export context data, send emails, and more.

• VirusTotal

  Provides integration with the popular VirusTotal service to analyze suspicious files, domains, IPs, and URLs to detect malware and other security breaches.

Recommended Cortex Marketplace content packs

In addition, we recommend reviewing if you require the following popular content packs:

• Phishing

  Create and respond to phishing issues based on user reports.

• Cortex XDR by Palo Alto Networks

  Automate Cortex XDR incident response. Includes custom Cortex XDR incident views and layouts to aid analyst investigations.

• Atlassian Jira

  Manage Jira tickets directly from Cortex XSIAM, enrich them with Cortex XSIAM data, and mirror information between Jira tickets and Cortex issues.

• ServiceNow

  Manage ServiceNow tickets directly from Cortex XSIAM, enrich them with Cortex XSIAM data, and mirror information between ServiceNow tickets and Cortex issues.

• PAN-OS by Palo Alto Networks

  Manage Palo Alto Networks Firewall and Panorama from Cortex XSIAM.

• A collaboration integration, such as Microsoft Teams or Slack, to send messages and notifications to your team.

Cortex XSIAM includes a built-in default mail sender. You also have the option of installing a different mail sender content pack, such as Microsoft Exchange Online.

You can only install one content pack at a time. Cortex XSIAM automatically adds any content that is required to install the content pack. You can also add any optional content packs that use the content pack you want to install.

If you receive an error message when you try to install a content pack, you need to fix the error before installing. If a warning message is issued, you can still download the content pack, but you should fix the problem; otherwise, the content may not work correctly.

Before you install a content pack, you should review the content pack to see what it includes and what the various dependencies are. The following is the information you can view:

• Details: General information about the content pack such as installation, content, version, author, and status.
• Content: The content to be installed, such as scripts or integrations.
• Dependencies: Details of any required content packs and optional content packs that may need to be installed with your content pack.
• Version History: View the currently installed version, earlier versions, available updates, and revert if required.

If you want to install data sources, you can do one of the following:

• Go to the Data Sources & Integrations page and add a data source. Once configured, it automatically installs the required content packs and recommends additional beneficial content such as playbooks and dashboards that are relevant for this specific data source.
• In Marketplace, select either Data Onboarder (which takes you to the integration configuration in the Data Sources & Integrations page) or install the content pack directly from Marketplace. If installing the content pack from Marketplace, you will then have to configure the integration in the Data Source & Integrations page.

Currently, not all content packs are supported in the Data Sources & Integrations page. For example, content packs with several integrations are not yet supported.

How to install a content pack in Marketplace

1. Go to Settings → Configurations → Marketplace → Browse and locate the content pack you want to install.
2. Click the required content pack and review the contents.
3. Click Install to add the content pack to the Cart.

4. (Optional) If the content pack includes optional content, select the content packs you want to add.

   The Cart displays the number of items you are installing, including any required content packs. You can log in and out, but the content packs remain in the Cart until you click either Empty cart or Install.

5. Click Install.

6. After installation, click Refresh content.

   You can now start configuring your content. If you have installed an integration, configure the integration, including setting up an integration instance.

Content packs are also automatically installed when you adopt playbooks and configure tasks.

Prerequisite

Managing users, roles, scopes, user groups, and authentication settings in Cortex XSIAM 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 and roles.

Access management enables you to control who can access the different parts of your organization's resources. It ensures only authorized users can interact with sensitive data.

Cortex XSIAM uses a combination of Role-Based Access Control (RBAC) and Scope-Based Access Control (SBAC) to ensure scalability and granular control.

What is the difference between RBAC and SBAC?

RBAC assigns permissions based on a user's organizational role, such as Investigator or Responder, establishing a clear hierarchy and set of capabilities for each role and simplifying management by linking access to job functions. RBAC does this by helping to manage access to Cortex XSIAM components and Cortex Query Language (XQL) datasets, so that users, based on their roles, are granted the minimal access required to accomplish their tasks.

SBAC refines RBAC by granting access only to the relevant data that the user requires for their designated role. Users with Access Management permission apply scopes to limit the data and content that users can be granted access to in Cortex XSIAM, which are divided into different scoping areas. The scoping areas include Assets, Cases and Issues, Endpoints, and Dataset Rows, which can be applied as relevant to the enforcement area, entity, or dataset.

For example, an Investigator role might have access to asset information based on the RBAC permissions, but SBAC granular scoping 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.

Understanding more about access management concepts

You can manage access for users and create and assign user roles and user groups for a specific tenant. When Single Sign-On (SSO) is enabled, you can manage SSO for users.

Users

You can manage access permissions and activities for users allocated to a specific Customer Support Portal account and tenant. All users must belong to a user group or have an assigned role.

To remove users added to your CSP account, you must do so in the CSP, not in Cortex Gateway.

User roles

User roles enable you to define the type of access and actions a user can perform. User roles are assigned to users, user groups, or API keys.

For more information on assigning user roles when generating an API key, see Manage API keys.

Predefined user roles

Cortex XSIAM provides predefined built-in user roles that provide specific access rights that cannot be modified. You can also create custom, editable user roles. To view the predefined permissions for each default role, go to Settings → Configurations → Access Management → Roles.

Dataset access permissions

You can also set dataset access permissions using user roles or set specific permissions using role-based access control (RBAC). Configuring administrative access depends on the security requirements of your organization. Dataset permissions control dataset access for all components, while RBAC controls access to a specific component. By default, dataset access management is disabled, and users have access to all datasets. If you enable dataset access management, you must configure access permissions for each dataset type and for each user role. When a dataset component is enabled for a particular role, the Issues and Cases pages include information about datasets. For more information on how to set dataset access permissions, see Manage user roles.

Be aware that even with scoped access to dataset rows applied, users can still indirectly access unauthorized dataset rows through dataset views and correlation rules. You can prevent this by ensuring that users don't have access to these dataset views and are unable to write correlation rules based on these datasets by enabling dataset access management for the relevant user roles, and limiting access to the applicable datasets. You may also want to consider not allowing these dataset-scoped users to write correlation rules, which we recommend as a best practice. For more information on how to set dataset access permissions, see Manage user roles. For more information on row-level scoping, see Manage user scope.

Some features are license-dependent. Accordingly, users may not see a specific feature if the feature is not supported by the license type or if they do not have access based on their assigned role or scope.

User groups and scoping areas

You can use user groups to streamline configuration activities by grouping together users whose access permission requirements are similar. Import user groups from Active Directory, or create them from scratch in Cortex XSIAM.

Users with Access Management permission can further restrict access of these user groups, specifically for the designated role and list of users configured in the user group by granting access only to the relevant data that the user requires for their designated role. This is performed by applying scopes to limit the data and content that users can be granted access to in Cortex XSIAM, which are divided into different scoping areas. The scoping areas include Assets, Cases and Issues, Endpoints, and Dataset Rows, which can be applied as relevant to the enforcement area, entity, or dataset. This enables you to adhere to your company's security policies of limiting user access by specifying, for example, which groups of assets users can access and what actions they can perform.

For features where scoping is not applicable, Role-Based Access Control (RBAC) is used and can be configured when managing user roles. For more information, see Manage user roles.

Single Sign-On

Manage your SSO integration with the Security Assertion Markup Language (SAML) 2.0 standard to securely authenticate system users across enterprise-wide applications and websites, with one set of credentials. This configuration allows system users to authenticate using your organization's Identity Provider (IdP), such as Okta or PingOne. You can integrate any IdP with Cortex XSIAM supported by SAML 2.0.

SSO with SAML 2.0 configuration activities are dependent on your organization’s IdP. Some of the field values need to be obtained from your organization’s IdP, and some values need to be added to your organization’s IdP. It is your responsibility to understand how to access your organization’s IdP to provide these fields and to add any fields from Cortex XSIAM to your IdP.

After SSO configuration is complete, when you sign in as an SSO user, the Cortex XSIAM permissions granted to you after logging in, either from the group mapping or from the default role configuration, are effective throughout the entire session for the defined maximum session length. The maximum session length is defined in your Cortex XSIAM Session Security Settings. This applies even if the default role configuration is updated or the group membership settings are changed.

Prerequisite

Managing user roles in Cortex XSIAM 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 and roles.

Review the following topics:

• Set up users and roles
• User group management
• Assign user roles and groups
• Manage user roles and access management

Manage user roles that are assigned to Cortex XSIAM users, user groups, or API keys. User roles enable you to define the type of access and actions a user can perform.

You can only set dataset access permissions from a user role in Cortex XSIAM Access Management for the tenant. When creating user roles from the Cortex Gateway, these settings are disabled. By default, dataset access management is disabled, and users have access to all datasets. If you enable dataset access management, you must configure access permissions for each dataset type and for each user role. When a dataset component is enabled for a particular role, the Issues and Cases pages include information about datasets.

Be aware that even with scoped access to dataset rows applied, users can still indirectly access unauthorized dataset rows through dataset views and correlation rules. You can prevent this by ensuring that users don't have access to these dataset views and are unable to write correlation rules based on these datasets by enabling dataset access management for the relevant user roles and limiting access to the applicable datasets. You may also want to consider not allowing these dataset-scoped users to write correlation rules, which we recommend as a best practice. For more information on row-level scoping, see Manage user scope.

Create a user role

1. Select Settings → Configurations → Access Management → Roles.
2. Click New Role.
3. Under Role Name, enter a name for the user role.
4. (Optional) Under Description, enter a description for the user role.
5. Under Components, expand each list and select the permissions for each of the components.
6. Under Datasets (Disabled), you have two options for setting the Cortex Query Language (XQL) dataset access permissions for the user role:
   • Set the user role with access to all XQL datasets by leaving the dataset access management as disabled (default).
   • Set the user role with limited access to certain XQL datasets by selecting the Enable dataset access management toggle and selecting the datasets under the different dataset category headings.
7. Click Save.

Edit a user role

1. Select Settings → Configurations → Access Management → Roles.
2. Right-click the relevant user role, and select Edit Role.
3. (Optional) Under Role Name, modify the name for the user role.
4. (Optional) Under Description, enter a description for the user role or modify the current description.
5. Under Components, expand each list and select the permissions for each of the components.
6. Under Datasets, you have two options for setting the Cortex Query Language (XQL) dataset access permissions for the user role:
   • Set the user role with access to all XQL datasets by disabling the Enable dataset access management toggle.
   • Set the user role with limited access to certain XQL datasets by selecting the Enable dataset access management toggle and selecting the datasets under the different dataset category headings.
7. Click Save.

Create new role based on an existing role

1. Select Settings → Configurations → Access Management → Roles.
2. Right-click the relevant user role, and select Save As New Role.
3. (Optional) Under Role Name, modify the name for the user role.
4. (Optional) Under Description, enter a description for the user role or modify the current description.
5. Under Components, expand each list and select the permissions for each of the components.
6. Under Datasets, you have two options for setting the Cortex Query Language (XQL) dataset access permissions for the user role:
   • Set the user role with access to all XQL datasets by disabling the Enable dataset access management toggle.
   • Set the user role with limited access to certain XQL datasets by selecting the Enable dataset access management toggle and selecting the datasets under the different dataset category headings.
7. Click Save.

Prerequisite

• Managing users, roles, scopes, user groups, authentication settings in Cortex XSIAM 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 and roles.
• To make users visible in the Users list within the Cortex tenant, an administrator must first assign them the Cortex User role on the Edit User screen in the Manage User Console of the Customer Support Portal (CSP). This role assignment in the CSP controls both the user's visibility in the tenant and their ability to authenticate via the CSP. For more information, see Cortex Gateway Administrator Guide.

Role and permission management

While the CSP controls initial visibility and access, you must update the specific permissions associated with each role within the tenant itself or via the Roles tab in the Cortex Gateway.

The following applies to user access and retention:

• SSO-only access: To allow a user to appear in the tenant while restricting them to SSO login only, assign them the Cortex User role in the CSP, but do not assign them a direct role or a default role in the Cortex Gateway or the tenant.
• Access revocation: If no role is assigned to a user (either directly or through a user group) in the Cortex Gateway or the tenant, the user cannot access the tenant. The user is subsequently revoked in the Cortex Gateway, and their information is no longer saved.

Manage users in the Cortex XSIAM tenant

Once users are visible in the tenant, perform the following tasks in Cortex XSIAM to edit permissions, import multiple users, view permissions, or manage user status.

Edit user permissions

Update a user's role and scope, add a user to a user group, and view permissions based on the role, scope, and user groups assigned to the user.

You can configure granular scoping for Scope-Based Access Control (SBAC) by granting access only to the relevant data that the user requires for their designated role. Administrators apply scopes to limit the data and content that users can be granted access to in Cortex XSIAM, which are divided into different scoping areas. The scoping areas include Assets, Cases and Issues, Endpoints, and Datasets Rows, which can be applied as relevant to the enforcement area, entity, or dataset. For more information, see Manage user scope.

Note

• You can only reduce the permissions of an Account Admin user via Cortex Gateway.
• Non-administrator users with Access Management permissions are restricted from granting, modifying, or removing the Instance Administrator role for any user, user group, or API key. Additionally, the Edit and Remove buttons are hidden for users who already hold an effective Instance Administrator role.

1. Select Settings → Configurations → Access Management → Users.

2. Right-click the relevant user, and select Edit User Permissions.

   Tip

   To apply the same settings to multiple users, select them, and then right-click and select Edit User Permissions.

3. In the Role tab, under Role, select the default or custom role.
4. (Optional) Under User Groups, add the user to a group.

5. (Optional) Under Show Accumulated Permissions:

   1. Do one of the following:
      • Select all to view the combined permissions for every role and user group assigned to the user.
      • Select a specific role assigned to the user to view the available permissions for that role.
   2. Under Components, expand each list to view the permissions to the various Cortex XSIAM components.
   3. Under Datasets, there are two possibilities for viewing a user's dataset access permissions:
      • When dataset access management is enabled and the user has access to certain Cortex Query Language (XQL) datasets, the datasets are listed.
      • When dataset access management is disabled and users have access to all XQL datasets, the text No dataset has been selected is displayed.

   Note

   User permissions for components and datasets are based on the access permissions set in the user role. For more information on editing these user role permissions, see Manage user roles.

6. (Optional) You can configure granular scoping:

   1. Click the Scope tab.

   2. Under Scope Definition, expand the scoping areas that you want to grant the user role access to in the tenant 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 Understand scoping in the Manage user scope section.

      Scoping Area	Granular Scoping Configurations
      Assets	<p>Set the Scope by selecting one of the following:</p><ul><li>No assets: No asset is accessible.</li><li>All assets: Defines access to all assets.</li><li>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).</li></ul><p>The scoping of assets also affects the scoping of cases, issues, and findings.</p><div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><p>Note</p><p>Visibility of Security domain Issues that refer to assets with agents is controlled by the Endpoints scoping configuration.</p></div>
      Cases and Issues	<p>Set the Scope by selecting one of the following:</p><ul><li>No cases and issues: Defines access to no cases and issues.</li><li>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.</li><li><p>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.</p><p>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.</p></li></ul><p>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.</p>
      Endpoints	<p>Set the Scope by selecting one of the following:</p><ul><li>No endpoints: Defines access to no endpoints with no ability to view their related agent management and enterprise policies.</li><li>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.</li><li>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.</li></ul>
      Datasets Rows	<p>Configure a filter to define the specific subset of rows a user is allowed to access in each raw dataset. A raw dataset is every dataset where Palo Alto Networks data is ingested out-of-the-box or third-party data is ingested using a configured dedicated collector, also called a data source. This filter configuration does not impact the visibility of cases and issues.</p><p>Follow these steps to configure a filter:</p><p>1. For datasets where no filter is defined, determine how to set the When no filter is defined option as either:</p><ul><li>No rows are accessible (default): Without a configured filter, no rows are accessible. Users can query the datasets in Cortex Query Language (XQL) as they have access, but the results will be empty.</li><li>All rows are accessible: Without a configured filter, all rows are accessible. Users can query the datasets in Cortex Query Language (XQL) as they have access, and view all results.</li></ul><div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><p>Note</p><p>When defining a filter for row-level scoping on raw datasets, queries based on the Cortex Data Model (XDM) are not supported. XDM queries return specific rows only when All rows are accessible is selected and no filter is defined in the Datasets Rows scoping area. Otherwise, no rows are returned.</p></div><p>2. Define any filters for the applicable datasets listed in the table:</p><p>1. Scroll down the list of datasets to the dataset you want to apply a filter on, and click the Edit Scope icon.</p><p>2. In the Define what rows are accessible window, continue to write the query for the filter in the query box (where the syntax is a limited subset of XQL) to limit the data rows for the selected dataset according to the access permissions you want the user to have. The beginning of the query is already defined before the query box, and there is no need to include this in your query.</p><div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><p>Important</p><p>For optimal performance, we recommend using a single field in the filter definition and simple comparison operators.</p></div><p>FIXME_ACCORDION_PLACEHOLDER</p><p>3. (Optional) Set the Time frame for the query. The default is Last 1 day.</p><p>4. (Optional) You can preview the query results displayed based on your defined query by clicking Preview. You can edit your query until you're satisfied with the output. By default, the query results are limited to 1000 records.</p><p>5. When you are finished, click Done.</p><p>The Scope field for the dataset that you added the filter on is updated with the query.</p><p>Example 13. **null </p><p>3. Scroll down the list of datasets to the dataset you want to apply a filter on, and click the Edit Scope icon.</p><p>4. In the Define what rows are accessible window, continue to write the query for the filter in the query box (where the syntax is a limited subset of XQL) to limit the data rows for the selected dataset according to the access permissions you want the user to have. The beginning of the query is already defined before the query box, and there is no need to include this in your query.</p><div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><p>Important For optimal performance, we recommend using a single field in the filter definition and simple comparison operators.</p></div><p>FIXME_ACCORDION_PLACEHOLDER</p><p>5. (Optional) Set the Time frame for the query. The default is Last 1 day.</p><p>6. (Optional) You can preview the query results displayed based on your defined query by clicking Preview. You can edit your query until you're satisfied with the output. By default, the query results are limited to 1000 records.</p><p>7. When you are finished, click Done.The Scope field for the dataset that you added the filter on is updated with the query.Example 13. **null </p>

   Important

   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 an administrator or a user with Access Management permissions first ensure that the users, user groups, and API Keys defined in Cortex XSIAM are granted the required access by assigning the relevant scopes. For more information, see Manage user scope.

7. Click Save.

Import multiple users

Use a CSV file to import users who belong to a Customer Support Portal account, and assign them roles that are defined in Cortex XSIAM. You can use the CSV template provided in Cortex XSIAM, or prepare a CSV file from scratch.

1. Select Settings → Configurations → Access Management → Users.
2. Click Import Multiple User Roles.
3. Do one of the following:
   • To use the CSV template, click Download example file, and replace the example values with your values.
   • Prepare a CSV file from scratch. Make sure the file includes these columns:
     • User email: Email address of the user belonging to a Customer Support Portal account, for example, john.smith1@exampleCompany.com.
     • Role name: Name of the role that you want to assign to this user, for example, Privileged Responder. The role must already exist in Cortex XSIAM.
     • Is an account role: A boolean value that defines whether the user is designated with an Account Admin role in Cortex Gateway. Set the value to TRUE; otherwise, the value is set to FALSE (default).
4. Locate the file and drag it to the dialog box.
5. Click Import.

View user permissions

View all of the permissions currently assigned to a user.

1. Select Settings → Configurations → Access Management → Users.

2. Right-click the relevant user, and select Edit User Permissions.

   Tip

   To apply the same settings to multiple users, select them, and then right-click and select Edit User Permissions.

3. In the Role tab, under Show Accumulated Permissions, do one of the following:
   • Select all to view the combined permissions for every role and user group assigned to the user.
   • Select a specific role assigned to the user to view the available permissions for that role.
4. Under Components, expand each list to view the permissions to the various Cortex XSIAM components.
5. Under Datasets, there are two possibilities for viewing a user's dataset access permissions:
   • When dataset access management is enabled and the user has access to certain Cortex Query Language (XQL) datasets, the datasets are listed.
   • When dataset access management is disabled and users have access to all XQL datasets, the text No dataset has been selected is displayed.
6. To view the granular scoping configurations granted to the user role, click the Scope tab, and under Scope Definition, expand the scoping areas to view the settings by clicking the chevron icon (>) beside the scoping area title. The scoping areas include Assets, Cases and Issues, Endpoints, and Datasets Rows.

Hide user

There might be instances where you want to hide a user from the list of users, for example, a user that has a Customer Support Portal Super User role but isn't active on your Cortex XSIAM tenant. After you hide a user, they will no longer be displayed in the list of users when Show User Subset is selected on the Users page. Non-administrator users with Access Management permissions can hide any user, including those assigned the Instance Administrator role.

1. Select Settings → Configurations → Access Management → Users.
2. Right-click the relevant user, and select Hide User.

Add user to a user group

1. Select Settings → Configurations → Access Management → Users.

2. Right-click the relevant user, and select Edit User Permissions.

   Tip

   To apply the same settings to multiple users, select them, and then right-click and select Edit User Permissions.

3. Under User Groups, add the user to a group.
4. Click Save.

Deactivate user

You cannot deactivate a user who has an Account Admin role.

1. Select Settings → Configurations → Access Management → Users.
2. Right-click the relevant user, and select Deactivate User.
3. Click Deactivate.

Remove role assigned to user

You cannot remove a user who has an Account Admin role.

1. Select Settings → Configurations → Access Management → Users.
2. Right-click the relevant user, and select Remove User Role.
3. Click Remove.

The following is a list of common fields on the Users page:

Prerequisite

• Configuring user scopes in Cortex XSIAM 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 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 XSIAM are granted the required access by assigning the relevant scopes.

Review the following topics:

• Set up users and roles
• User group management
• Assign user roles and groups
• Manage user roles and access management

What is SBAC?

Cortex XSIAM 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 XSIAM, which are divided into different scoping areas. The scoping areas include Assets, Cases and Issues, Endpoints, and Datasets Rows, which can be applied as relevant to the enforcement area, entity, or dataset. 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.

Things to consider before configuring SBAC

Before you begin setting up 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.
• Some areas and features in Cortex XSIAM 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 in the following areas:
  • When opening the Cases, Issues, Findings, and Assets tables, which can take more time.
  • When defining a filter for access row-level scoping on raw datasets, the more complex the filter is, the greater the performance overhead. For optimal performance, we recommend using a single field in the scope definition and simple comparison operators.
• In Reports, SBAC applies when a report is manually generated. Scheduled reports run in the scope of the user who created or last updated the report template. Be aware that once a report is generated, it can be shared with others; exercise caution when distributing reports, as recipients might not be authorized to view the data they contain.
• Be aware that even with scoped access to dataset rows applied, users can still indirectly access unauthorized dataset rows through dataset views and correlation rules. You can prevent this by ensuring that users don't have access to these dataset views and are unable to write correlation rules based on these datasets by enabling dataset access management for the relevant user roles and limiting access to the applicable datasets. You may also want to consider not allowing these dataset-scoped users to write correlation rules, which we recommend as a best practice. For more information on how to set dataset access permissions, see Manage user roles.

Understand scoping

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.
• 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 will not affect asset visibility.

• Datasets Rows: Enables row-level scoping on raw datasets. This granular control directly affects product areas accessing these rows, such as Cortex Query Language (XQL) dataset queries and custom dashboard widgets. The datasets listed are a subset of datasets, determined by your assigned role, where you can configure row-level access for users. To grant access to specific dataset rows, you must configure a filter to explicitly define the allowable rows. When configuring this filter, you can encounter different scenarios. For more information, see Scenarios related to Datasets Rows scoping.

Note

Access to the asset_groups dataset is managed through Dataset Access Management permissions within the user role.

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 and issues datasets respect both Assets and Cases and Issues scoping configurations.
• Scoping of Datasets Rows is performed in addition to user permissions to access the dataset.
• Row-level scoping is only supported on raw datasets. This granular scoping directly affects product areas accessing these rows, including XQL dataset queries and custom dashboard widgets.

• When a user's SBAC permissions change for a given dataset by updating the filter, queries executed before the change will retain and display their original results in the Query Center.

  Note

  Whenever a user's SBAC permissions are changed, Cortex XSIAM logs this event in the audit logs (Settings → Management Audit Logs). These monitored activity events are found on the Management Audit Logs table by filtering the Type column by Permissions and Subtype column by Scope Edit.

• While users with row-level dataset scoping can view other users' queries in the Query Center, they are prevented from viewing the corresponding query results.

Functional areas that respect and don't respect SBAC

It is important to review both the functional areas and features in Cortex XSIAM that are respected and not fully respected so you can decide what actions to take in your tenant.

Functional areas respected

Scope-Based Access Control (SBAC) applies to the following functional areas in Cortex XSIAM:

Important

Some areas and features in Cortex XSIAM do not respect SBAC. In these cases, use RBAC permissions to restrict access.

SBAC not fully respected functional areas

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 alerts and incidents datasets does 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 enable access to cases and issues datasets that respect SBAC.
  • Access to the endpoints dataset via XQL does not respect endpoint-led SBAC. In this case, use RBAC permissions to restrict access to the endpoints dataset and permit access only to users who can see information for all agents.
  • Row-level scoping is only supported on raw datasets and no other dataset types, including in XQL queries and custom dashboard widgets. For these datasets that are not in the scope, all rows are available.
  • When defining the filter for row-level scoping on raw datasets, queries based on the Cortex Data Model (XDM) aren't supported. XDM queries return specific rows only when All rows are accessible is selected when no filter is defined in the Datasets Rows scoping area. Otherwise, no rows are returned.
• Dataset Views: Be aware that even with scoped access to dataset rows applied, users can still indirectly access unauthorized dataset rows through dataset views. You can prevent this by ensuring that users don't have access to these dataset views by enabling dataset access management for the relevant user roles and limiting access to the applicable datasets. For more information on how to set dataset access permissions, see Manage user roles.
• Correlation Rules: Be aware that even with scoped access to dataset rows applied, users can still indirectly access unauthorized dataset rows through correlation rules. You can prevent this by ensuring that users are unable to write correlation rules based on these datasets by enabling dataset access management for the relevant user roles, and limiting access to the applicable datasets. You may also want to consider not allowing these dataset-scoped users to write correlation rules, which we recommend as a best practice. For more information on how to set dataset access permissions, see Manage user roles.
• 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 XSIAM, 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.

  Note

  This feature is included with a Cortex XSIAM Premium, Enterprise, and NG-SIEM licenses.

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

Scenarios related to Datasets Rows scoping

When configuring row-level scoping on raw datasets, you can encounter different scenarios. It's important to understand how best to handle these scenarios and what are the recommended best practices.

Scenario 1: Data sources with multiple instances

When integrating data from multiple sources, as a best practice, name each data source instance using a descriptive and consistent convention. This naming should clearly reflect the teams/groups that require access to the data through that specific instance, and the same naming value should be maintained across different sources when applicable. For example, use names like business_unit_x or subsidiary_y. Adopting this convention across all data sources simplifies the process of writing filters for each _raw dataset using the _collector_name field.

Scenario 2: Dataset schemas without _collector_name

When data is ingested from a source like a Broker VM or agent, the dataset schema may not include the _collector_name field. In this scenario, use the other fields that are supported to define your filter. For more information on the fields supported, see Supported syntax in Step 3 of How to configure granular scoping of the table for Datasets Rows.

Scenario 3: Supported fields don't provide the necessary segmentation

Sometimes, when trying to configure a filter to define the specific subset of rows a user is allowed to access in each raw dataset, the supported fields don't provide the necessary segmentation that you are looking for. In this case, define a _scope field in an [INGEST] section of the Parsing Rules for the applicable dataset ingesting data. The _scope field is added to the dataset columns, so that each row is imprinted during ingestion or parsing time with the _scope value. You can then use this _scope field in the filter. For more information on the fields supported, see Supported syntax in Step 3 of How to configure granular scoping of the table for Datasets Rows.

Scenario 4: Only a few datasets need to be segmented

When only a few datasets need to be segmented, as you want users to have full access to the other datasets, configure the datasets to grant access to all rows by default when no filter is defined. This is set in the Datasets Rows scoping area by configuring the When no filter is defined option to All rows are accessible. You can then define filters only for the few datasets that need scoping.

Scenario 5: Scoped users with Access Management permission

Consider this scenario for scoped users with Access Management permission:

When a user (non-administrator) with Access Management permission (User A) attempts to define row-level scoping for another user (User B), an issue can arise. User A can only see and configure SBAC filters for datasets that both User A and User B currently have access permissions (RBAC) to. Any datasets that User B can access, but User A cannot, will not appear for User A when defining access for User B.

To avoid these possible scenarios, we recommend that users with access management permissions be granted full RBAC permissions to the complete superset of datasets for the other users to whom they're meant to apply row-level scoping. This ensures that users setting row-level scoping see the complete list of datasets they are authorized to scope.

How to configure granular scoping

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 XSIAM 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 XSIAM are granted the required access by assigning the relevant scopes. This user can then assign a scoping area to a Cortex XSIAM 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.

1. Ensure that you have the necessary administrator-level permissions.
2. Verify that the users, user groups, and API keys defined in Cortex XSIAM 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.

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

   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.

   Dataset rows

   Follow these steps to configure a filter:

   Configure a filter to define the specific subset of rows a user is allowed to access in each raw dataset. A raw dataset is every dataset where Palo Alto Networks data is ingested out-of-the-box or third-party data is ingested using a configured dedicated collector, also called a data source. This filter configuration does not impact the visibility of cases and issues.
   

   1. For datasets where no filter is defined, determine how to set the When no filter is defined option as either:

      • No rows are accessible (default): Without a configured filter, no rows are accessible. Users can query the datasets in Cortex Query Language (XQL) as they have access, but the results will be empty.
      • All rows are accessible: Without a configured filter, all rows are accessible. Users can query the datasets in Cortex Query Language (XQL) as they have access, and view all results.

      Note: When defining a filter for row-level scoping on raw datasets, queries based on the Cortex Data Model (XDM) are not supported. XDM queries return specific rows only when All rows are accessible is selected and no filter is defined in the Datasets Rows scoping area. Otherwise, no rows are returned.

   2. Define any filters for the applicable datasets listed in the table:

      1. Scroll down the list of datasets to the dataset you want to apply a filter on, and click the Edit Scope icon.

      2. In the Define what rows are accessible window, continue to write the query for the filter in the query box (where the syntax is a limited subset of XQL) to limit the data rows for the selected dataset according to the access permissions you want the user to have. The beginning of the query is already defined before the query box, and there is no need to include this in your query.

         For optimal performance, we recommend using a single field in the filter definition and simple comparison operators.

         Supported syntax

         Fields

         You can define the rest of the filter in the query box, where only the following system fields are supported: _broker_device_id, _broker_device_ip, _broker_device_name, _collector_id, _collector_ip, _collector_name, _collector_type, _device_id, _final_reporting_device_ip, _final_reporting_device_name, _log_type, _product, _scope, _reporting_device_ip, _reporting_device_name, and _vendor.

         For more information on these fields, see the table that describes all the fields in the metrics_source dataset and metrics_view preset in Overview of data ingestion metrics. For more information on the _scope field (relevant when _scope is defined in the Parsing Rule), see Scenario 3: Supported fields don't provide the necessary segmentation.

         Comparison operators

         The following comparison operators are supported:

         • Exact matches (=, !=)
         • Comparing numerical values (>, <, >=, <=)
         • Checking membership in lists (in)
         • Querying arrays (array_contains)
         • Partial matches (contains, starts_with): Using this operator has additional performance overhead, and we recommend avoiding its use.

         If you only want a user to be able to access rows in the pan_dds_raw dataset, when the _collector_name is bu2_collector , you'd have to define the filter in the query box as:

         _collector_name = “bu2_collector”
         

      3. Optional) Set the Time frame for the query. The default is Last 1 day.
      4. (Optional) You can preview the query results displayed based on your defined query by clicking Preview. You can edit your query until you're satisfied with the output. By default, the query results are limited to 1000 records.

      5. When you are finished, click Done.

         The Scope field for the dataset that you added the filter on is updated with the query.

         In the above example, the Scope field displays _collector_name = “bu2_collector”.

4. Click Save.
5. Repeat steps 2 to 4 until you have configured all users, user groups, and API keys with the correct granular scoping access.

6. Enable granular scoping in Cortex XSIAM.

   1. Select Settings → Configurations → General → Server Settings, and select the Enable Scope-Based Access Control toggle.
   2. (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.
   3. Click Save.

   When you are finished, all the users in Cortex XSIAM are now able to use Cortex XSIAM only within the granular scoping granted according to their assigned user roles.