Introducing XTI, a comprehensive threat intelligence offering that embeds adversary insights directly into SOC workflows through enriched case investigations and AI-driven behavioral analysis.
A central hub for understanding your organization's data security posture at a glance. It brings together data discovery, classification, posture, detection, and access governance into a single interactive view, helping you quickly see where your sensitive data lives, how it is protected, and what needs your attention next.
# Cortex XSIAM Documentation
Find Cortex XSIAM product guides, references, and release information.
## How can we help?
Find product documentation, compatibility details, and the latest release information.
{% hint style="info" %}
Use the tiles below to browse each documentation area.
{% endhint %}
***
### Cortex XSIAM
Explore Cortex XSIAM platform documentation and technical references.
:bullhorn:Release Notes
Review the latest Cortex XSIAM features and known issues.
# Cortex XDR Documentation
Find Cortex XDR product guides, references, and release information.
## How can we help?
Find product documentation, compatibility details, and the latest release information.
{% hint style="info" %}
Use the tiles below to browse each documentation area.
{% endhint %}
***
### Cortex XDR 5.x
Explore Cortex XDR 5.x guides, APIs, and release notes.
:book-open:Cortex XDR 5.x Documentation
Learn daily tasks, configuration, and product workflows.
# Cortex Cloud Documentation
Find Cortex Cloud product documentation, references, and release information.
## How can we help?
Find product guides, technical references, and the latest release information.
{% hint style="info" %}
Use the tiles below to browse each documentation area.
{% endhint %}
***
### Cortex Cloud
Choose a documentation area or reference for your task.
#### Cortex Cloud Runtime Security
# Cortex XDR Agent
Cortex XDR Agent guides, releases, compatibility, and reference information.
## How can we help?
Find Cortex XDR Agent documentation, compatibility details, and the latest release information.
{% hint style="info" %}
Use the tiles below to browse each Cortex XDR Agent documentation area.
{% endhint %}
***
### Cortex XDR Agent
Explore installation, configuration, and troubleshooting guidance for Cortex XDR agents.
:bullhorn:Agent Release Notes
Review the newest features and known issues for Cortex XDR Agent.
# Cortex AgentiX
Cortex AgentiX documentation, release notes, and API references.
## How can we help?
Find Cortex AgentiX documentation, administration guidance, and current release information.
{% hint style="info" %}
Use the tiles below to browse each documentation area.
{% endhint %}
### Cortex AgentiX
Explore product guides, technical references, and release information.
:bullhorn:Release Notes
Review the newest Cortex AgentiX features and known issues.
# What's New
Latest Cortex AgentiX release notes.
## What's New
Review the latest Cortex AgentiX release notes.
# Cortex Gateway Admin Guide
Manage permissions, RBAC, and user groups across Cortex products.
## Cortex Gateway Admin Guide
Learn how to view and manage permissions, role-based access control (RBAC), and user-group settings across all Cortex products.
# Release Notes
Latest Cortex AgentiX features and known issues.
## Release Notes
Review the newest features and known issues for Cortex AgentiX.
# Cortex AgentiX Documentation
Product guides for Cortex AgentiX.
## Cortex AgentiX Documentation
Learn how to use Cortex AgentiX from getting started through daily tasks.
Explore configuration, security orchestration, playbooks, incident management, monitoring, and more.
# API Reference Guide
Cortex AgentiX API reference.
## API Reference Guide
View all Cortex AgentiX APIs.
# Cortex Data Security
## How can we help?
Find product guides, references, and resources.
{% hint style="info" %}
Use the tiles below to browse each documentation area.
{% endhint %}
# Cortex XSOAR Documentation
Explore Cortex XSOAR guides, releases, and product resources.
How can we help?
Find Cortex XSOAR documentation, deployment guides, and the latest release information.
{% hint style="info" %}
Use the tiles below to browse Cortex XSOAR documentation areas.
{% endhint %}
***
### Cortex XSOAR 8 SaaS
Use these areas to deploy, manage, and maintain Cortex XSOAR 8.
:book:Cortex XSOAR 8 Documentation
Configure systems, orchestration, incidents, and playbooks for Cortex XSOAR 8 SaaS
:share-nodes:FS-ISAC STIX/TAXII Guide for Cortex XSOAR
Assist FS-ISAC member firms in connecting and configuring Cortex XSOAR through a STIX/TAXII feed integration with the FS-ISAC Threat Intelligence Exchange Repository (IntelX Repo)
# Cortex Xpanse Expander
Find Cortex Xpanse Expander guides, APIs, and release information.
## How can we help?
Find product documentation, API references, and the latest release information.
{% hint style="info" %}
Use the tiles below to browse Cortex Xpanse Expander documentation.
{% endhint %}
:shield:Cortex Xpanse Expander
Product documentation for setup, configuration, investigation, and remediation.
# Navigate the Cortex XSIAM docs
Start here for a visual overview of the main Cortex XSIAM documentation areas.
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.
{% hint style="info" %}
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.
{% endhint %}
### Learn the product
# Get started with Cortex XSIAM
Learn about Cortex XSIAM and the key integrated capabilities.
#### 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
Explore the Cortex XSIAM architecture, including SIEM, XDR, SOAR, cloud security, XDL data ingestion, and Broker VM.
### 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 |
Cortex XDR agents forward all data directly to Cortex XDL. This data is accessible for query and investigation within Cortex XSIAM.
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.
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.
|
| Network & SASE |
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.
If you plan to stream data from a Strata Logging Service instance, it must reside in the same region as your Cortex XSIAM tenant.
|
| 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 |
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).
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.
The Cortex XSIAM tenant and the CIE must be deployed in the same region.
|
| 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.
# Agentic AI in Cortex XSIAM
Use the Cortex Agentic Assistant in Cortex XSIAM to investigate cases, perform threat hunting, and create scripts. Embed and run LLM prompts in playbooks. View AI case summaries.
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**.
{% hint style="info" %}
### 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-xsiam/learn-about-cortex-xsiam/agentic-ai-in-cortex-xsiam/compare-agentic-assistant-with-cortex-assistant).
{% endhint %}
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.
{% hint style="info" %}
### 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.
{% endhint %}
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](/cortex-xsiam/detect-investigate-and-respond-to-threats/monitor-dashboards-and-reports/dashboard-reference/command-center-reference/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)
{% hint style="info" %}
### Note
In multi-tenant/MSSP environments, agentic AI features are not available on the main tenant.
{% endhint %}
### Frontier Models
**EU and US Regions**
Tenants in the EU and US regions can use the following frontier AI models:
| Name | Model |
| -------- | ----------------- |
| Flash | Gemini 3.5 Flash |
| Thinking | Claude Sonnet 4.6 |
| Pro | Claude Opus 4.8 |
Claude Sonnet 5 is available upon request in the US and EU regions.
{% hint style="info" %}
**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.
{% endhint %}
**SG, JP, IN, and UK regions**
Tenants in the SG, JP, IN, and UK regions have Gemini 3.5 Flash.
# Agentic Assistant use cases
Recommended prompts to automate your SOC using the Cortex Agentic Assistant in Cortex XSIAM.
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](https://unit42.paloaltonetworks.com/threat-brief-ivanti-cve-2025-0282-cve-2025-0283/) 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](/cortex-xsiam/detect-investigate-and-respond-to-threats/agentic-assistant-chat/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.
{% stepper %}
{% step %}
### 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?".
{% endstep %}
{% step %}
### Agent selection
The bot responds with a dropdown menu of available public agents, and you select the appropriate agent to handle the request.
{% endstep %}
{% step %}
### 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.
{% hint style="info" %}
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.
{% endhint %}
{% endstep %}
{% step %}
### 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.
{% endstep %}
{% endstepper %}
# Compare Agentic Assistant with Cortex Assistant
Feature comparison between Cortex Agentic Assistant and Cortex Assistant in Cortex XSIAM.
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.
| Features | Agentic Assistant | Cortex Assistant |
| --------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| How it operates | Uses a Large Language Model (LLM) to analyze intent and dynamically generate a plan, a unique sequence of actions executed step-by-step to resolve a specific request. | Uses natural language processing to convert user questions into XQL queries and suggest a list of static, predefined responses (for example, "Run Playbook," "Scan Host"). |
| Scope of operation | Complex, ad-hoc scenarios. Agents function as virtual personas (for example, Threat Intel, IT) that can autonomously determine the necessary steps to achieve a broad objective. | Routine tasks such as single-entity investigations (host, hash, user) and navigation shortcuts. |
| Customization | Anyone with the relevant permissions can build custom agents with specific instructions, personas, and restricted sets of actions. Scripts and commands can be registered as new actions for agents to utilize. | Functionality is limited to out-of-the-box capabilities provided by the platform. You cannot modify Cortex Assistant's behavior. |
| Execution logic | Agents validate their own plans, clarify ambiguous prompts, and execute multiple steps in sequence or parallel based on the context of the investigation. | Relies on traditional rule-based automation. Actions are discrete and require manual selection from a recommended list. |
| Infrastructure | Leverages dedicated Google Cloud Platform (GCP) infrastructure for GenAI processing. | Processes queries within the standard tenant infrastructure. |
| Availability | Disabled by default. It requires enablement by an Administrator via Settings → **Configurations** → **General** → **Server Settings** → **Agentic Assistant** and is currently restricted to tenants in specific regions. For more information, see [Cortex Agentic Assistant](/cortex-xsiam/learn-about-cortex-xsiam/agentic-ai-in-cortex-xsiam). | Available by default to all tenants not using Cortex Agentic Assistant. |
| Access Control (RBAC) |
Administrators use a dedicated CORTEX AGENTIC ASSISTANT permission category to configure specific permissions for:
Interacting with agents using the chat interface.
Managing agents/actions: Viewing, creating, or editing custom agents and registering new actions in the Agentic Assistant Hub.
| Permissions are determined by standard Cortex XSIAM user roles (for example, View/Edit access to specific modules). |
| Auditing | All agent activities are logged in a specific dataset (**`agentix_agents_actions`**) queryable via XQL. You can also view the specific plan generated by the AI within the chat interface to understand the logic behind an answer. | Actions taken are logged as standard system activities. |
# Agentic Assistant security
Learn about how the Agentic Assistant is built using responsible AI principles in Cortex XSIAM.
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 license tiers and product licenses
Compare Cortex XSIAM license tiers and product licenses: NG-SIEM, Enterprise, Premium, included capabilities, and add-ons.
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.
{% hint style="info" %}
You can upgrade your license by purchasing add-ons or moving to a different XSIAM license.
{% endhint %}
### 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:
Feature
Description
AI and Big Data
Integrates data analytics, AI/ML, and automation into a unified platform.
Comprehensive Data Collection
Offers extensive cloud data collection with out-of-the-box analytics, detection, and cloud asset discovery.
Advanced Analytics
Provides capabilities for threat hunting, analysis, response, and automation.
User and Entity Behavior Analytics (UEBA)
Uses machine learning to profile users and entities, alerting on anomalous behavior that could indicate a compromised account or insider threat
### 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:
| Feature | Description |
| ------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Cortex XDR agent | Entitles you to one Cortex XDR agent per endpoint, which provides tailored endpoint data and third-party logs collection to optimize detection and investigation visibility. |
| Extended Detection and Response (XDR) | Incorporates extended data collection and ingestion of endpoint logs and alerts, firewalls, and third-party audit and flow logs through Host Insights and Extended Threat Hunting Data. |
### 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:
Feature
Details
Cloud Posture Security
Delivers comprehensive visibility and continuous monitoring of cloud environments to ensure configurations meet security best practices, compliance standards, and vulnerability management. This bundle includes the following advanced modules:
Cloud Security Posture Management (CSPM): Continuously scans your cloud environment (AWS, Azure, GCP) to detect misconfigurations, compliance violations, and drift from secure baselines.
Cloud Infrastructure Entitlement Management (CIEM): Enforces least-privilege access to cloud infrastructure. It protects and manages access to resources by analyzing identity misconfigurations, reducing excessive permissions, and providing real-time monitoring of identity anomalies.
AI Security Posture Management (AI-SPM): Secures AI-powered applications and models against misuse and vulnerabilities.
Data Security Posture Management (DSPM): Discovers, classifies, and secures sensitive data across your cloud environment.
Agentless Workload Scanning: Scans cloud workloads for vulnerabilities, malware, and exposed secrets without requiring an agent installation.
Application Security Posture Management (ASPM): Provides a consolidated view of application risks and vulnerabilities across your environment, enabling you to understand and manage your overall security posture.
Full code security scanning requires a separate add-on.
CI/CD: Focuses on securing your continuous integration and continuous delivery pipelines, ensuring the integrity and security of your automated build and deployment processes
Cloud Runtime Security
Prevents attackers from exploiting risks present in your cloud environment. Provides real-time protection, detection, and response for cloud workloads, crucial for applications, containers, serverless functions, and APIs. Includes
Cloud Workload Rules: Cloud Workload Rules define the criteria for identifying security violations. This criteria can be applied to assets in your cloud environment and to findings generated by Cortex XSIAM.
Cloud Workload Policies: Cloud Workload Policies help you prevent and manage security violations in your cloud runtime instances.
Web and API Security: Cortex Web and API Security (WAAS) capabilities offer comprehensive protection of APIs across integrated API gateways and web-based applications and APIs running on Linux-based workloads.
Cortex XSIAM Premium users can install an XDR agent on endpoints and on any host or cloud workload, including Kubernetes hosts, based on the user's per-unit subscription parameters and workload demands. The XDR agent offers cloud-based endpoint protection and detection support, along with tailored endpoint and third-party log data collection.
For more information about the license relationship between the XDR agent on endpoints and the XDR agent on host or cloud workloads, and how the licenses are allocated, see License allocation.
Extended Threat Intelligence (XTI)
Provides operationalized Threat Intelligence (TI) seamlessly integrated across the Cortex platform.
Threat Intel Management
Investigates indicators and files, applies indicator rules, generates reports, and integrates feed integrations.
Attack Surface Management
Provides internet-facing assets and ASM enrichment, external services, external IP ranges, attack surface rules and alerts, ASM widgets, and report capabilities.
{% hint style="info" %}
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.
{% endhint %}
### 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:
Feature
Description
Cortex XSIAM NG SIEM
Cortex XSIAM Enterprise
Cortex XSIAM Premium
Core Analytics
Detects anomalies and threats using machine learning and behavioral models.
Included in license
Included in license
Included in license
Automation
Orchestrates and automates security workflows with prebuilt and customizable playbooks.
Included in license
Included in license
Included in license
Data Ingestion
Analytics tier: Collects and normalizes data, creating a unified foundation for analytics, investigation, and detection. GB/day-based, with a minimum of 100 GB/day.
Cortex Data Lake tier: Provides cost-efficient ingestion and storage of security data at scale for use cases such as threat hunting, forensic investigations, and compliance audits. This tier is available as an optional add-on with a minimum of 50 GB/day, provided the mandatory 100 GB/day Analytics tier license is already met. For more information, see Configure Cortex Data Lake tier.
Included in license
Included in license
Included in license
Enterprise Runtime Security (XDR)
Comprehensive endpoint and server protection by combining AI-driven analytics, endpoint controls, next-generation antivirus, and automated investigation to detect and respond to threats across various environments.
Add-on
Included in license
Included in license
Cloud Posture Security
Agentless comprehensive visibility across your cloud environment. Includes:
Up to 400 workloads, dependent on the license plan
For Cortex XSIAM Enterprise and NG SIEM, if purchasing Cloud Posture Security only, a minimum number of workloads is required. If you purchase Cloud Runtime Security or Cortex XSIAM Premium, this add-on is included with the subscription.
Add-on
Add-on
Included with Cloud Runtime Security
Cloud Runtime Security
Full cloud protection, detection, and response. In addition to Cloud Posture Security:
For Cortex XSIAM Premium: Minimum 200 workloads (priced per workload).
Cloud Detection and Response (CDR)
Cloud Workload Protection (CWP)
Web Application and API Security (WAAS)
For all Cortex XSIAM licenses, a minimum number of workloads is required.
Add-on
Add-on
Included in license
Application Security
Comprehensive protection for your software development lifecycle (SDLC) from code-to-cloud, offering visibility, detection, contextual analysis, prioritization, prevention, and remediation.
To access the Application Security module, you must have a Cloud Posture Security, Cloud Runtime Security, or Cortex XSIAM Premium license. These licenses include Application Security Posture Management (ASPM) and CI/CD Security.
Add-on component: Code Security
Code Security requires a separate Application Security add-on as well as a Cloud Posture Security, Cloud Runtime Security, or Cortex XSIAM Premium license.
Add-on
Add-on
Add-on
Extended Threat Intelligence (XTI)
Provides operationalized Threat Intelligence (TI) seamlessly integrated across the Cortex platform
Add-on
Add-on
Included in license
Threat Intelligence Management
Investigates indicators and files, uses indicator rules, reports, and feed integrations.
Add-on
Add-on
Included in license
Attack Surface Management
Provides internet-facing assets and ASM enrichment, external services, external IP ranges, attack surface rules and alerts, ASM widgets, and report capabilities.
Add-on
Add-on
Included in license
Identity Threat Detection & Response
Enables asset role configuration, advanced analytics alert layout, Risk Management dashboard, User/Host Risk view, designated analytics for compromised accounts, and insider threat coverage. This solution helps organizations proactively secure identities, accelerate threat response, and reduce the complexity of security operations.
Add-on
Add-on
Add-on
Forensics
Detect attacker activity by reviewing key artifacts such as event logs, registry keys, browser history, etc. Forensics simplifies investigations so you can trace every move an adversary made and swiftly contain threats from one place without needing to pivot between security tools.
Add-on
Add-on
Add-on
Host Insights
Host Insights combines Vulnerability Management, Host Inventory, and a powerful Search and Destroy feature to help you identify and contain threats. It offers a holistic approach to endpoint visibility and attack containment, helping reduce your exposure to threats so you can avoid future breaches.
Add-on
Included in license
Included in license
Extended Threat Hunting
Investigates everyday activities in real time and analyzes patterns to discover new threats, aiming to proactively minimize risk for an organization.
Add-on
Included in license
Included in license
Data Retention
Retention per dataset ensures extended access to data, strengthening threat investigation, compliance, and long-term visibility.
Add-on
Add-on
Add-on
Extended Compute Units
Additional computing resources beyond the annual allocation. You can purchase more units or enable dynamic allocation for flexible access. This ensures uninterrupted service, supports scaling during peak workloads, and optimizes resource management to maintain performance during high-demand periods.
Add-on
Add-on
Add-on
Endpoint Event Forwarding
Enables exporting the raw telemetry collected by XDR Agents and event data from cloud endpoints to external systems (if relevant).
Add-on
Add-on
Add-on
GB Event Forwarding
Enables exporting parsed logs to an external SIEM for storage, so you can keep data in your own storage in addition to the Cortex XSIAMdata layer, for compliance requirements and machine learning purposes.
Add-on
Add-on
Add-on
Advanced Email Security
Investigate and respond to threats within modern, distributed email infrastructures. The module is a scalable, API-based solution that passively analyzes cloud-hosted email environments to detect threats. It ingests data from messages, attachments, and user identities to identify early-stage threats and high-risk behaviors without requiring any changes to mail flow.
Add-on
Add-on
Add-on
Exposure Management
Gain comprehensive visibility, actionable prioritization, and automation-first remediation to help security teams proactively assess and respond to organizational exposures.
Add-on
Add-on
Add-on
DLP (Data Loss Prevention)
The Cortex Data Loss Prevention (DLP) module provides a unified and flexible solution to prevent sensitive data exfiltration. It continuously enforces policies on endpoints (even offline) across web, local, and USB channels, protecting both on-premise and cloud environments.
Add-on
Add-on
Add-on
#### Tiers and key capabilities
# Data retention
Learn more about the default retention periods for all Cortex XSIAM licenses and the available retention add-ons.
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](/cortex-xsiam/configure-cortex-xsiam/data-management/dataset-management).
### **Default retention periods**
The following table summarizes the default retention periods for Cortex XSIAM:
| Data Type | Default Retention Period |
| ------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Ingested data | 31 days |
| Cases and Issues data |
186 days
Case data is retained according to the Last Updated date.
Issue data is retained according to the Observation Time. Data collected within these dates is kept and displayed for 186 days. To ensure the accuracy of issues, Cortex XSIAM provides a grace period of up to 31 days for issues displayed in the Issues View, Issues table, and Cases View.
|
| Agentic AI chats and artifacts | 186 days |
| Forensic data |
365 days
Requires the Forensics add-on.
|
| Audit logs | 365 days |
| Query data | 186 days |
### **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:
| Feature | Description |
| --------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Additional Cases and Issues Retention |
An additional 31-day hot storage of Case and Issue data apart from the default 186 days.
Available for purchase per month for each endpoint. This retention add-on also extends agentic AI chats and artifacts retention by 31 days.
|
| Period-Based Retention - Hot Storage (All datasets) |
Fully searchable storage for investigation and threat hunting of ingested data, and Cases and Issues data.
Requires purchasing a minimum of one month of the additional retention.
|
| Additional Hot Storage (Selected datasets) |
Flexible hot storage-based retention to help accommodate varying storage requirements for different retention periods and datasets. Fully searchable storage for investigation and threat hunting of ingested data.
Available for purchase with storage for a minimum of 1,000 GB.
|
| Period-Based Retention - Cold Storage |
Lower-cost storage of ingested data for long-term compliance needs with limited search options.
Requires purchasing a minimum of six months of additional retention.
|
# Data storage lifecycle
Understand the Cortex XSIAM data storage lifecycle, including hot and cold storage, retention extensions, and Event Forwarding exports.
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](/cortex-xsiam/configure-cortex-xsiam/data-management/manage-compute-units).
For information on the CU add-on license, see [Understand the Cortex XSIAM license plan](/cortex-xsiam/learn-about-cortex-xsiam/cortex-xsiam-product-licenses).
* **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](/cortex-xsiam/configure-cortex-xsiam/data-management/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.
{% hint style="info" %}
You can view details about your Cortex XSIAM licenses by selecting **Settings** → **Cortex XSIAM License**.
{% endhint %}
# License allocation
Learn more about how Cortex XSIAM regulates licenses.
### **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.
{% hint style="info" %}
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.
{% endhint %}
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):
| Asset Type | License Return | Agent Removal from Cortex XSIAM Tenant | Agent Removal from Cortex XSIAM Database |
| ---------------------------------------------------------- | -------------------------------------------------------------------------------- | -------------------------------------- | ---------------------------------------- |
| Standard endpoints, mobile devices, server/cloud workloads | After 30 days | After 180 days | After 180 days |
| (Non-Persistent) VDI and Temporary Session |
VDI: Immediately after log-off
Other: After 90 minutes
| After 6 hours | After 7 days |
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.
{% hint style="info" %}
It can take up to an hour for Cortex XSIAM to display revived assets.
{% endhint %}
# License expiration
Learn more about the Cortex XSIAM license expiration and validation period.
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.
# Upgrade your tenant
If you have purchased new entitlements, Cortex XSIAM automatically upgrades your tenant to provide product upgrades and new license entitlements.
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.
# In-product support ticket creation
Open a support ticket directly in Cortex XSIAM and record your console to capture your issues and have the ticket handled efficiently.
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.
{% hint style="info" %}
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.
{% endhint %}
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.
{% stepper %}
{% step %}
From Cortex XSIAM, select **Help** → **Initiate Support Request**.
{% endstep %}
{% step %}
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.
{% hint style="info" %}
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.
{% endhint %}
{% endstep %}
{% step %}
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.
{% hint style="info" %}
Selecting an endpoint from the endpoint table and retrieving TSF requires full **Retrieve Endpoint Data** permissions under **Endpoint Administration**.
{% endhint %}
{% endstep %}
{% step %}
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**.
{% endstep %}
{% step %}
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**.
{% hint style="info" %}
Console recordings cannot exceed 10 minutes. The current recording time is displayed at the top of the window.
{% endhint %}
{% endstep %}
{% step %}
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.
{% endstep %}
{% endstepper %}
# Supported web browsers
View the web browsers and minimum browser versions supported for Cortex XSIAM.
Cortex XSIAM supports the following web browsers:
| Browser | Version |
| -------------- | -------------- |
| Chrome | 95.x and later |
| Firefox | 93.x and later |
| Safari | 13.x and later |
| Microsoft Edge | Latest version |
| Prisma Browser | Latest version |
# Use the Cortex XSIAM interface
Learn Cortex XSIAM interface navigation, filtering, saved views, result exports, system tools, and product areas.
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.
{% hint style="info" %}
* Each SAML login session is valid for 8 hours.
* Some menu items only appear if you have the relevant license.
{% endhint %}
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.
{% hint style="info" %}
* 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.
{% endhint %}
**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.
{% hint style="info" %}
* 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.
{% endhint %}
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**
| Component | Description |
| ----------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Dashboard | Select a dashboard/command center to view your tenant's activities, enabling you to effectively monitor your cases and overall activity in your environment |
| Reports | View all the reports that Cortex XSIAM have run. |
| Dashboard Manager | Manage dashboards, including adding dashboards with customized widgets to surface the statistics that matter to you most. |
| Report Templates | Build reports using pre-defined templates or customize a report. Reports can be generated on demand or scheduled. |
| Widget library | Search, view, edit, and create widgets based on predefined widgets and user-created custom widgets. |
**Cases & Issues**
| Component | Description |
| ------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Cases | Investigate cases, manually create new cases, manage case severity and status, assign cases, and merge cases. |
| Issues | Investigate and manage individual issues. Run a playbook in the **Work Plan** for an individual issue or run the same playbook on multiple issues from the **Issues** table. Run commands in the **War Room**. Navigate to the **Findings** table. |
| Case Configuration | Add case scoring rules, view starred issues, and add featured hosts, users, and IP addresses. |
**Investigation & Response**
**Search**
| Component | Description |
| ----------------- | ----------------------------------------------------------------------------------------------------------------------- |
| Query Builder | Build complex queries to investigate, identify connections, and expose the root cause of issues from your data sources. |
| Query Center | View and manage the results of all simple and complex queries created from the Query Builder. |
| Scheduled Queries | View and manage all scheduled and recurring queries created from the Query Builder. |
**Automation**
| Component | Description |
| ---------------- | ------------------------------------------------------------------------------------------------------------------------------- |
| Playbooks | Manage playbooks, including viewing, creating, and editing. |
| Scripts | Manage scripts. Use **Script Helper** to find relevant commands and scripts for your use case. |
| Jobs | Create and manage jobs to run a specific playbook, triggered either by time or a delta in a feed. |
| Playground | Safely develop and test scripts, commands, and more, in a non-production environment not connected to a specific issue or case. |
| Automation Rules | Automatically respond to events by defining trigger conditions and desired actions to perform once the condition is met. |
**Response**
| Component | Description |
| ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Action Center | Provides a central location from which you can track the progress of all investigation, response, and maintenance actions performed on your endpoints. |
| Live Terminal | Initiate a remote connection to an endpoint, enabling you to remotely manage, investigate, and perform response actions on the endpoint. |
| EDL | Add malicious domains and IP addresses to an external dynamic list enforceable on your Palo Alto Networks firewall. |
**Forensics**
| Component | Description |
| --------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| N/a | Streamline your case response, data collection, threat hunting, and analysis of your endpoint data to find the source and scope of an attack. Requires the Forensics add-on. |
**Notebooks**
| Component | Description |
| --------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| N/a | Use Jupyter tools to build machine learning models to visualize clusters, identify anomalies, and then feed your findings back into the Cortex XSIAM environment to generate security insights. You need a daily minimum of 1000 compute units. |
**Threat Management**
**Detection Rules**
| Component | Description |
| --------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| IOC | Identify specific hashes, IP addresses, domains, file names, and paths that indicate a threat. |
| BIOC | Identify a specific network, process, file, or registry activity that indicates a threat. |
| Correlations | Analyze correlations of multiple events from multiple sources. |
| Indicator Rules | Create rules based on filters that are applied as either SHA256 and MD5 prevention rules in specific Agent Prevention Profiles or as file, IP address, and domain detection rules. |
**Threat Intelligence**
| Component | Description |
| ------------------- | ----------------------------------------------------------------------------------------------------------------- |
| Threat Intelligence | Requires Cortex XSIAM Premium or any other XSIAM license with the TIM add-on |
| Indicators | Indicators database. Search, review, and interact with indicators including IPs, domains, URLs, hashes, and more. |
**Posture Management**
Requires Cortex XSIAM Premium or any other XSIAM license with the Cloud Runtime Security add-on.
| Component | Description |
| ------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Vulnerability Management | View vulnerability issues, vulnerable assets, vulnerabilities, and vulnerability intelligence. |
| Compliance | Determine asset vulnerabilities and risk by checking whether assets adhere to industry standards or your organization's best practices for compliance. You can select compliance standards from the compliance catalog. |
| Rules & Policies | Create and edit rules and policies for cloud workload, cloud security, and vulnerability management. |
**Inventory**
**Assets**
| Component | Description |
| --------------------- | ------------------------------------------------------------------------------------------------------------------- |
| All Assets | Provides a central location from which you can view and investigate information relating to assets in your network. |
| Groups | Create and view groups of assets with shared attributes. |
| Network configuration | Define your internal IP address ranges and domain names to identify and track your network assets. |
**Endpoints**
| Component | Description |
| -------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| All Endpoints | View and manage endpoints that have registered with your Cortex XSIAM instance. |
| Groups | Create endpoint groups to which you can perform actions and assign the policy. |
| Installations | Create packages of the Cortex XSIAM agent software for deployment to your endpoints. |
| Host Insights | Access comprehensive insights into your system's components, including applications, services, users, and vulnerability assessments, to maintain visibility and security across your environment. |
| Policy Management | Configure your endpoint security profiles and assign them to your endpoints. |
| Host Firewall | Control communications on your endpoints by applying sets of rules that allow or block internal and external traffic. |
| Device Control Violations | Monitor all instances where end users attempted to connect restricted USB-connected devices and Cortex XSIAM blocked them on the endpoint. |
| Disk Encryption Visibility | View and manage endpoints that were encrypted using BitLocker. |
| File Integrity Monitoring | A security control designed to detect unauthorized or anomalous modifications to files and folders in the file system. Any change, such as, a new file being created or an existing file being modified, will trigger an event that is sent to the Cortex XSIAM tenant. |
**Modules**
| Component | Description |
| -------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| AI Security |
Comprehensive overview of the AI assets within an organization. Designed to ensure AI security by offering tools to review and prioritize AI risks effectively.
This feature is included with a Cloud Runtime Security, Cloud Posture Security, or Cortex XSIAM Premium license.
|
| Application Security |
Secures your applications by identifying and prioritizing them as a single, logical entity encompassing assets across the entire software development lifecycle (SDLC).
This feature is included with a Cloud Runtime Security, Cloud Posture Security, or Cortex XSIAM Premium license.
|
| Dats Security |
Agentless multi-cloud data security platform that discovers, classifies, protects, and governs sensitive data.
This feature is included with a Cloud Runtime Security, Cloud Posture Security, or Cortex XSIAM Premium license.
|
| Identity Security |
Runs a proprietary algorithm to calculate effective permissions and entitlements of the identities across your cloud service providers.
This feature is included with a Cloud Runtime Security, Cloud Posture Security, or Cortex XSIAM Premium license.
|
| Kubernetes Security |
Automatically discovers assets, enforces policies, and scans for vulnerabilities, malware, secrets, and misconfigurations across the environment.
This feature is included with a Cloud Runtime Security, Cloud Posture Security, or Cortex XSIAM Premium license.
|
| Attack Surface | ASM helps you discover and manage your public attack surface, providing visibility into all of your digital assets, including on-prem and cloud. Identify and remediate vulnerabilities, enforce compliance policies, and reduce the risk of cyberattacks. Included in Cortex XSIAM Premium or any other XSIAM license with the Attack Surface Management add-on. |
| Email Security | Provides a scalable detection, investigation, and response layer over cloud-hosted email environments. It connects directly to supported email platforms via secure API integrations to ingest rich message-level and identity-related telemetry. Requires the Email Security add-on. |
| Exposure Management | A collection of features, capabilities, integrations, and content designed to help defenders holistically assess, consolidate, prioritize, and proactively respond to exposures in their organization. Requires the Exposure Management add-on. |
**Agentic Assistant Hub**
{% hint style="info" %}
This menu item appears if you have enabled the Cortex Agentic Assistant.
{% endhint %}
Manage agentic agents and actions in the Agentic Assistant Hub.
# Manage API keys
Learn to create and manage Cortex XSIAM API keys, roles, expiration, scopes, and credential permissions.
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](/cortex-xsiam/onboard-cortex-xsiam/deployment-steps/set-up-users-and-roles/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.
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.
| Action | Description |
| ---------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| View Examples | Copies the Python 3 example, so you can edit it to set up your own API calls. |
| Copy text to clipboard / Copy entire row | Copies the value of an API setting, such as the ID, to the clipboard by right-clicking the setting and selecting **Copy text to clipboard**. You can copy all the settings of an API key by right-clicking and selecting **Copy entire row**. |
| Filter API keys | Filters the API keys by selecting one of the filter options, such as **Show rows 30 days prior to...**. You can then adjust the filter options to filter the API keys according to all the available fields. |
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.
# How to onboard Cortex XSIAM
Learn about the deployment preparation and procedures for onboarding and configuring Cortex XSIAM.
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.
# Plan and prepare
Plan your Cortex XSIAM deployment, including storage, region, licensing, XDR agents, data sources, and user roles.
This stage includes how to plan and prepare the Cortex XSIAM environment.
{% hint style="info" %}
### 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](/cortex-xsiam/configure-cortex-xsiam/cortex-xsiam-data-sources/cloud-service-provider-csp-onboarding).
{% endhint %}
Before you get started with Cortex XSIAM, consider the following:
| Action | Details | See More |
| ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Determine the required Log storage | ✅ Determine the amount of log storage you need for your Cortex XSIAM deployment. Discuss with your partner or sales representative to determine whether to purchase additional storage within the Cortex XSIAM tenant. | [Data storage lifecycle](/cortex-xsiam/learn-about-cortex-xsiam/cortex-xsiam-product-licenses/data-storage-lifecycle) |
| Determine the deployment region | ✅ Determine the region you want to host Cortex XSIAM and any associated services, such as the Directory Sync Service. If you plan to stream data from a Strata Logging Service instance, it must be in the same region as Cortex XSIAM. | [Cortex XSIAM supported regions](/cortex-xsiam/onboard-cortex-xsiam/deployment-steps/activate-cortex-xsiam#UUID-61479dc6-978f-bf5d-da88-4f934ff79ef1) |
| Review your license and add-ons | ✅ Review your Cortex XSIAM license and consider the addons for your use case, such as Advanced Email Security and Exposure management for complete security protection. | [Cortex XSIAM product licenses](/cortex-xsiam/learn-about-cortex-xsiam/cortex-xsiam-product-licenses) |
| Plan the XDR Agent deployment |
✅ The XDR Agent is installed on endpoints for protection and extended detection and response (XDR). The data is collected into the Cortex XSIAM tenant.
The XDR agent is included with the Cortex XSIAM Premium and Enterprise licenses and any other XSIAM license with the Enterprise Runtime Security (XDR) add-on.
For Cortex XSIAM Premium or XSIAM licences with the Cloud Runtime Security add-on, the agent is also used to stop attacks running on workloads, including VMs, containers, Kubernetes, and serverless functions.
Consider the following:
✅ Determine the necessary bandwidth required to support the number of agents you plan to deploy.
✅ Verify endpoint operating systems and identify third-party security products to ensure they are compatible with Cortex XSIAM.
✅ Create a proof of concept (POC) that simulates your corporate production environment. After the successful completion of the initial POC, we recommend a phased rollout, which enables you to test the agent and its policies on a small scale before deploying them widely.
✅ Consider the data sources you want to initially ingest, such as Palo Alto Networks firewall/cloud logs, as they provide the most immediate security context and data for Cortex XSIAM's analytics.
In Cortex XSIAM, content is organized into content packs, which are either downloaded from the Data Sources catalog or from Marketplace. Start planning what content you require.
✅ Review the steps you need to take in your day-to-day SOC operations, and the required third-party tools/applications.
| [What are Cortex XSIAM data sources?](/cortex-xsiam/configure-cortex-xsiam/cortex-xsiam-data-sources/what-are-cortex-xsiam-data-sources) |
| Consider roles and permissions | ✅ Review and plan roles using Role-Based Access Control (RBAC) for your security operations team. Consider user groups and start with the default roles. | [Set up users and roles](/cortex-xsiam/onboard-cortex-xsiam/deployment-steps/set-up-users-and-roles) |
# Plan your agent deployment
Plan phased Cortex XDR agent deployment, from pilot testing to organization-wide Cortex XSIAM rollout.
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.
| Step | Duration | Plan |
| --------------------------------------------------------------------------------------- | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 1. Calculate the bandwidth required to support the number of agents you plan to deploy. | As needed | For every 100,000 agents, allocate 120 Mbps of bandwidth. The bandwidth requirement scales linearly. For example, to support 300,000 agents, plan to allocate 360 Mbps of bandwidth (three times the amount required for 100,000 agents). |
| 2. Set up Cortex XSIAM access services | 1 week |
If you have not done so already, set up the following:
Firewall configuration: Enable access to Cortex XSIAM communication servers, storage buckets, and resources.
Required certificates to establish secure communication
Enable access for Windows CRL checks (Windows only)
Enable peer-to-peer content updates
Validate compatibility with third-party security products
|
| 3. Install the Cortex XDR agent on a pilot group of endpoints | 1 week |
Install the Cortex XDR agent on a small number of endpoints (3 to 10).
Test the expected behavior of the Cortex XDR agents (collection and policy) and confirm that there is no change in the user experience.
|
| 4. Expand the Cortex XSIAM deployment. | 2 weeks | Gradually expand agent distribution to larger groups that have similar attributes (hardware, software, and users). At the end of two weeks, you can have Cortex XSIAM deployed on up to 100 endpoints. |
| 5. Complete the Cortex XSIAM installation. | 2 or more weeks | Broadly distribute the Cortex XDR agent throughout the organization until all endpoints are protected. |
| 6. Define corporate policy and protected processes. | Up to 1 week | Add protection rules for third-party or in-house applications and then test them. |
| 7. Refine corporate policy and protected processes. | Up to 1 week | Deploy security policy rules to a small number of endpoints that use the applications frequently. Fine-tune the policy as needed. |
| 8. Finalize corporate policy and protected processes. | A few minutes | Deploy protection rules globally. |
# Deployment steps
Review the plan and prepare considerations, and then follow the steps in the onboarding checklist to successfully deploy and onboard Cortex XSIAM.
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.
# Cortex XSIAM onboarding checklist
Cortex XSIAM onboarding checklist for activation, data source configuration, XDR agent deployment, and analytics setup.
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.
{% hint style="warning" %}
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/configure-cortex-xsiam/cortex-xsiam-data-sources/cloud-service-provider-csp-onboarding).
{% endhint %}
### Cortex XSIAM deployment checklist
This deployment phase sets up Cortex XSIAM infrastructure, data pipelines, endpoint protection, and security analytics.
| Step | Details | See More |
| ------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| 1. Activation and initial setup |
✅ In the Cortex Gateway, activate Cortex XSIAM and confirm license status.
✅ Enable access to required PANW resources and set up encryption keys (BYOK), if required.
✅ Assign initial administrator and analyst-type user roles (Responder/Investigator), create user groups, and assign roles to those groups (recommended) to a limited number of users initially. You can update this later.
✅ Set up access through the Customer Support Portal or SAML single sign-on.
Use the Data Sources Onboarding wizard to configure the following:
✅ Priority content:
Configure network security data, such as Palo Alto Networks Next-Generation Firewalls, and network devices.
Configure identity and user data. Install the Cloud Identity Engine (optional and highly recommended), which provides the necessary Active Directory or Microsoft Entra ID/Okta context (user names, group membership, computer names) to map a raw event (for example, an IP address) to a user or asset.
✅ Highly recommended content:
Connect cloud audit logs for the most critical providers, such as AWS CloudTrail, Azure Activity Logs, and Google Cloud Audit Logs, directly to Cortex XSIAM.
Configure/enable a key Threat Intelligence feed, such as the Unit 42 Intelligence feed, to enrich incoming issues. This ensures that as soon as a log/alert hits the Data Lake, it has the latest malicious context.
✅ Install the XDR agent by creating XDR Agent installation packages for a small, diverse pilot group of endpoints and deploy the agent to a pilot group (phased rollout). Start with small, low-risk endpoints and extend, as required. Gradually expand agent distribution to larger groups that have similar attributes (hardware, software, and users). At the end of two weeks, you can have Cortex XSIAM deployed on up to 100 endpoints.
✅ After testing expected agent behavior and performance, review and select default endpoint security profiles (Exploit, Malware, Restrictions, Agent Settings, Exceptions) to begin protecting your endpoints from threats immediately. Once endpoints are deployed and start collecting data, you can make any necessary adjustments to these rules and policies.
✅ Verify endpoint data collection (logs, alerts, events) is flowing from deployed agents to the XSIAM Data Lake. After deploying the agents to the pilot group, set up data collection to analyze the data.
This provides granular event data (process execution, file activity, registry changes, network connections) necessary for EDR/XDR detection and Behavioral Indicators of Compromise (BIOCs).
✅ Enable Cortex XSIAM Analytics engine (if not already enabled).
The analytics engine accesses your logs as they are streamed to Cortex XSIAM, including firewall data, and analyzes them as soon as they arrive.
You need EDR or network logs from at least 30 endpoints over a minimum of 2 weeks, or Cloud audit logs over a minimum of 2 weeks.
✅ Enable Identity Analytics, which focuses on user behavior that is critical since attackers primarily target credentials. It has two main functions:
User/Entity Behavior Analytics (UEBA): Profiles users, hosts, and groups based on identity data and flags anomalies like a user logging in from a new country (Impossible Traveler), accessing an unusual database, or transferring a massive file volume outside of their norm.
Investigation context: When an issue fires, Identity Analytics ensures that the relevant user profile details, recent activities, and group membership are automatically aggregated and displayed with a user-based Analytics type issue and Analytics BIOC rule
The Cloud Identity Engine must be set up.
✅ Enable the Identity Threat Detection and Response (ITDR) add-on (optional), which enhances the analytics baseline capabilities to include the Directory Infrastructure. This enables the detection of advanced attacks targeting Domain Controllers and other identity components.
In addition, the ITDR module integrates proactive capabilities by using attack surface management to identify and expose identity-related security flaws and vulnerabilities before they can be exploited.
|
Your Cortex XSIAM is now operational and is collecting data.
# Activate Cortex XSIAM
Activate Cortex XSIAM tenants in Cortex Gateway, including prerequisites, encryption, and access configuration.
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.
{% hint style="warning" %}
### 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](https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClNVCA0).
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](https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA14u000000sZ8mCAE).
* 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 |
You must have the Account Admin role.
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.
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.
|
{% endhint %}
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](/cortex-xsiam/onboard-cortex-xsiam/deployment-steps/activate-cortex-xsiam/cortex-xsiam-supported-regions). |
| Tenant Subdomain |
DNS record associated with your tenant. Enter a name that will be used to access the tenant directly using the full URL:
https\://\xdr.\.paloaltonetworks.com
|
| Encryption Method |
(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.
Default encryption (recommended)
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.
BYOK (Bring your own keys)
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.
|
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](/cortex-xdr-3.x/cortex-xdr-3.x-documentation/onboard-and-configure-cortex-xdr/deployment-steps/step-1-activate-cortex-xdr/enable-access-to-required-panw-resources).
# Bring your own keys
Set up, import, rotate, and disable Cortex BYOK encryption keys for Cortex XSIAM tenant data.
### 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.
{% hint style="info" %}
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.
{% endhint %}
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**.
{% hint style="info" %}
**PREREQUISITE:**
To disable your encryption keys and deactivate a tenant, you must have an Account Admin role.
{% endhint %}
{% hint style="warning" %}
**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.
{% endhint %}
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 \
-in \
-out \
-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](https://docs.cloud.google.com/kms/docs/configuring-openssl-for-manual-key-wrapping).
2. Generate a temporary random AES key:
```
openssl rand 32 >
```
3. Wrap the temporary AES key with the wrapping public key:
```
openssl pkeyutl \
-encrypt \
-pubin \
-inkey \
-in \
-out \
-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:
```
"" enc \
-id-aes256-wrap-pad \
-iv A65959A6 \
-K $( hexdump -v -e '/1 "%02x"' < " " ) \
-in "" >> " "
```
3. Upload the wrapped key and click **Complete Activation**.
# Cortex XSIAM supported regions and data residency
View Cortex XSIAM supported hosting regions and data residency locations in Americas, EMEA, and JPAC.
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
| Country | Description |
| ------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| US (United States) | All Cortex XSIAM logs and ingested data remain hosted within the boundaries of the United States. |
| Brazil (BR) | All Cortex XSIAM logs and ingested data remain hosted within the boundaries of Brazil. |
| Canada (CA) |
All Cortex XSIAM logs and ingested data remain hosted within the boundaries of Canada. However, if you have a WildFire Canada cloud subscription, consider the following:
You cannot send file submissions for bare-metal analysis.
You will not be protected against macOS-borne zero-day threats. However, you will receive protection against other macOS malware in regular WildFire updates.
|
### Cortex XSIAM regions in EMEA
| Country | Description |
| ------------------- | -------------------------------------------------------------------------------------------------- |
| Finland (FI) | All Cortex XSIAM logs and ingested data remain hosted within the boundaries of Finland. |
| France (FA) | All Cortex XSIAM logs and ingested data remain hosted within the boundaries of France. |
| Germany (DE) | All Cortex XSIAM logs and ingested data remain hosted within the boundaries of Germany. |
| Israel (IL) | All Cortex XSIAM logs and ingested data remain hosted within the boundaries of Israel. |
| Italy (IT) | All Cortex XSIAM logs and ingested data remain hosted within the boundaries of Italy. |
| Netherlands | All Cortex XSIAM logs and ingested data remain hosted within the boundaries of Netherlands. |
| Poland (PL) | All Cortex XSIAM logs and ingested data remain hosted within the boundaries of Poland. |
| Qatar (QT) | All Cortex XSIAM logs and ingested data remain hosted within the boundaries of Qatar. |
| Saudi Arabia (SA) | All Cortex XSIAM logs and ingested data remain hosted within the boundaries of Saudi Arabia. |
| South Africa (ZA) | All Cortex XSIAM logs and ingested data remain hosted within the boundaries of South Africa. |
| Spain (ES) | All Cortex XSIAM logs and ingested data remain hosted within the boundaries of Spain. |
| Switzerland (CH) | All Cortex XSIAM logs and ingested data remain hosted within the boundaries of Switzerland. |
| UK (United Kingdom) | All Cortex XSIAM logs and ingested data remain hosted within the boundaries of the United Kingdom. |
### Cortex XSIAM regions in JPAC
| Country | Description |
| ---------------- | ------------------------------------------------------------------------------------------- |
| Australia (AU) | All Cortex XSIAM logs and ingested data remain hosted within the boundaries of Australia. |
| Delhi (DL) | All Cortex XSIAM logs and ingested data remain hosted within the boundaries of Delhi. |
| India (IN) | All Cortex XSIAM logs and ingested data remain hosted within the boundaries of India. |
| Indonesia (ID) | All Cortex XSIAM logs and ingested data remain hosted within the boundaries of Indonesia. |
| Japan (JP) | All Cortex XSIAM logs and ingested data remain hosted within the boundaries of Japan. |
| Singapore (SG) | All Cortex XSIAM logs and ingested data remain hosted within the boundaries of Singapore. |
| South Korea (KR) | All Cortex XSIAM logs and ingested data remain hosted within the boundaries of South Korea. |
| Taiwan (TW) | All Cortex XSIAM logs and ingested data remain hosted within the boundaries of Taiwan. |
# Enable access to required PANW resources
Configure firewall access to Cortex XSIAM resources using required FQDNs, IP addresses, ports, and App-IDs.
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:
* Regional ranges:
* 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**.
{% hint style="info" %}
***``*** refers to the selected subdomain of your Cortex XSIAM tenant, and ***``*** is the region in which your tenant is deployed. For more information, see [Cortex XSIAM supported regions](/cortex-xsiam/onboard-cortex-xsiam/deployment-steps/activate-cortex-xsiam/cortex-xsiam-supported-regions).
{% endhint %}
The following tables list required FQDNs, IP addresses, ports, and App-ID coverage for your deployment.
FQDN
IP Addresses and Port
App-ID Coverage
<tenant-name>.xdr.<region>.paloaltonetworks.com
Used to send data from external services and systems to the Cortex tenant.
IP address by region:
US (United States): 35.244.250.18:443
EU (Europe): 35.227.237.180:443
CA (Canada): 34.120.31.199:443
UK (United Kingdom): 34.120.87.77:443
JP (Japan): 35.241.28.254:443
SG (Singapore): 34.117.211.129:443
AU (Australia): 34.120.229.65:443
DE (Germany): 34.98.68.183:443
IN (India): 35.186.207.80:443
DL (Delhi): 34.8.67.192:443
CH (Switzerland): 34.111.6.153:443
PL (Poland): 34.117.240.208:443
TW (Taiwan): 34.160.28.41:443
QT (Qatar): 35.190.0.180:443
FA (France): 34.111.134.57:443
IL (Israel): 34.111.129.144:443
SA (Saudi Arabia): 35.244.157.127:443
ID (Indonesia): 34.111.58.152:443
ES (Spain): 34.111.188.248:443
IT (Italy): 34.8.224.70:443
KR (South Korea): 34.54.5.247:443
ZA (South Africa): 34.149.165.12:443
BR (Brazil): 34.96.83.202:443
FI (Finland): 34.160.63.63:443
cortex-xdr
distributions.traps.paloaltonetworks.com
Used for the first request in registration flow where the agent passes the distribution id and obtains the ch-<tenant-name>.traps.paloaltonetworks.com of its tenant.
Used for API requests and responses and to connect to an engine.
IP address by region:
US (United States): 35.222.81.194:443
EU (Europe): 34.90.67.58:443
CA (Canada): 35.203.82.121:443
UK (United Kingdom): 34.89.56.78:443
JP (Japan): 34.84.125.129:443
SG (Singapore): 34.87.83.144:443
AU (Australia): 35.189.18.208:443
DE (Germany): 34.107.57.23:443
IN (India): 35.200.158.164:443
DL (Delhi): 34.131.165.103:443
CH (Switzerland): 34.65.248.119:443
PL (Poland): 34.116.216.55:443
TW (Taiwan): 35.234.8.249:443
QT (Qatar): 34.18.46.240:443
FA (France): 34.155.222.152:443
IL (Israel): 34.165.156.139:443
SA (Saudi Arabia): 34.166.58.79:443
ID (Indonesia): 34.128.115.238:443
ES (Spain): 34.175.30.176:443
IT (Italy): 34.154.195.120:443
KR (South Korea): 34.64.54.175:443
ZA (South Africa): 34.35.64.191:443
BR (Brazil): 34.39.136.78:443
FI (Finland): 35.228.73.215:443
—
cc-<tenant-name>.traps.paloaltonetworks.com
Used for get-verdict requests.
For agents on endpoints, you must allow the IP address for the closest region to ensure connectivity. Endpoints use latency-based routing. An agent that belongs to a US tenant, for example, but that is physically located in Singapore, routes to Singapore to get the verdict.
These IPs are used for communication between Cortex XSIAM and your resources. Use them when sending data out from your tenant.
FI (Finland):
34.88.97.182
34.88.189.1
US (United States)
34.132.108.184
34.69.63.16
EU (Europe)
34.147.107.51
34.91.26.125
CA (Canada)
35.203.108.13
35.203.101.162
UK (United Kingdom)
35.242.180.163
34.105.173.229
JP (Japan)
35.200.3.131
34.146.181.233
SG (Singapore)
35.240.243.57
34.126.183.208
AU (Australia)
34.151.83.236
34.116.67.90
DE (Germany)
35.234.118.195
34.89.183.45
IN (India)
35.200.175.78
34.93.9.198
CH (Switzerland)
34.65.108.153
34.65.155.169
PL (Poland)
34.118.48.171
34.116.202.235
TW (Taiwan)
34.80.133.68
35.234.18.10
QT (Qatar)
34.18.34.118
34.18.39.155
FA (France)
34.155.5.117
34.155.41.247
IL (Israel)
34.165.33.165
34.165.27.131
SA (Saudi Arabia)
34.166.61.81
34.166.58.213
ID (Indonesia)
34.128.126.138
34.128.82.158
ES (Spain)
34.175.46.46
34.175.80.182
IT (Italy)
34.154.23.156
34.154.186.12
KR (South Korea)
34.64.93.168
34.64.237.45
ZA (South Africa):
34.35.42.196
34.35.79.219
cortex-xdr
Egress IP addresses Used for traffic from the Cortex tenant to external services and systems. Add the relevant IP addresses from this list to your allow lists for your external services and systems.
IP addresses by region
FI (Finland)
35.228.175.228
35.228.44.44
US (United States)
35.225.156.101
34.69.88.119
EU (Europe)
34.147.67.188
34.90.16.31
CA (Canada)
35.203.57.162
35.203.90.79
UK (United Kingdom)
34.142.3.42
34.142.44.136
JP (Japan)
34.146.60.215
34.84.93.160
SG (Singapore)
35.240.144.192
35.240.255.15
AU (Australia)
35.244.73.76
35.201.22.63
DE (Germany)
34.107.83.197
34.159.53.97
IN (India)
35.244.5.205
34.93.118.113
DL (Delhi)
34.131.207.151
34.126.212.40
CH (Switzerland)
34.65.222.25
34.65.233.60
PL (Poland)
34.118.92.214
34.116.223.119
TW (Taiwan)
104.199.223.229
34.81.38.132
QT (Qatar)
34.18.39.0
34.18.32.96
FA (France)
34.155.197.131
34.155.5.100
IL (Israel)
34.165.46.47
34.165.17.246
SA (Saudi Arabia)
34.166.58.243
34.166.54.238
ID (Indonesia)
34.101.125.66
34.101.218.184
ES (Spain)
34.175.255.99
34.175.230.35
IT (Italy)
34.154.173.134
34.154.229.60
KR (South Korea)
34.64.189.205
34.64.45.118
ZA (South Africa)
34.35.70.193
34.35.80.189
BR (Brazil)
35.199.96.109
34.39.161.254
—
Collect third-party data from your SaaS and Cloud resources
# Cortex XSIAM regional egress resources
Configure Cortex XSIAM firewall egress access with regional FQDNs, IP addresses, ports, and App-IDs.
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
Service Definition
FQDN
APP-ID
Egress tenant
Connects to the Cortex XSIAM tenant.
<tenant-name>.xdr.<region>.paloaltonetworks.com
cortex-xdr
Live Terminal
Used in live terminal flow for real-time shell sessions
https://lrc-<region>.paloaltonetworks.com
wss://lrc-<region>.paloaltonetworks.com
cortex-xdr
Endpoint Detection and Response (EDR)
Used for EDR data upload. Includes telemetry logs, process executions, and security events that the Cortex XDR agent captures and sends to the cloud for analysis
dc-<tenant-name>.traps.paloaltonetworks.com
traps-management-service
Heartbeat
Used for all other requests between the XDR agent and the tenant, including heartbeat, uploads, action results, and scan reports.
ch-<tenant-name>.traps.paloaltonetworks.com
traps-management-service
API Access
Used for API requests and responses and to connect to an engine.
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 engine outbound IP addresses
Configure firewall allowlists for Cortex XSIAM engine outbound IP addresses by deployment region.
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
| Region | IP Addresses |
| ------------------ | ---------------------------- |
| United States (US) | 35.225.156.101, 34.69.88.119 |
| Canada (CA) | 35.203.57.162, 35.203.90.79 |
### Cortex XSIAM engine IP addresses in EMEA
| Region | IP Addresses |
| ------------------------------------- | ----------------------------- |
| France (FA) | 34.155.197.131, 34.155.5.100 |
| Germany (DE) | 34.107.83.197, 34.159.53.97 |
| Israel (IL) | 34.165.46.47, 34.165.17.246 |
| Italy (IT) | 34.154.173.134, 34.154.229.60 |
|
Netherlands/
Europe (EU)
| 34.147.67.188, 34.90.16.31 |
| Poland (PL) | 34.118.92.214, 34.116.223.119 |
| Qatar (QT) | 34.18.39.0, 34.18.32.96 |
| Saudi Arabia (SA) | 34.166.58.243, 34.166.54.238 |
| South Africa (ZA) | 34.35.70.193, 34.35.80.189 |
| Spain (ES) | 34.175.255.99, 34.175.230.35 |
| Switzerland (CH) | 34.65.222.25, 34.65.233.60 |
| United Kingdom (UK) | 34.142.3.42, 34.142.44.136 |
| Finland (FI) | 35.228.175.228, 35.228.44.44 |
### Cortex XSIAM engine IP addresses in JPAC
| Region | IP Addresses |
| ---------------- | ----------------------------- |
| Australia (AU) | 35.244.73.76, 35.201.22.63 |
| India (IN) | 35.244.5.205, 34.93.118.113 |
| Indonesia (ID) | 34.101.125.66, 34.101.218.184 |
| Japan (JP) | 34.146.60.215, 34.84.93.160 |
| Singapore (SG) | 35.240.144.192, 35.240.255.15 |
| South Korea (KR) | 34.64.189.205, 34.64.45.118 |
| Taiwan (TW) | 104.199.223.229, 34.81.38.132 |
# Cortex XSIAM inbound source IP addresses
Configure firewall allowlists for Cortex XSIAM inbound source IP addresses by deployment region.
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
| Region | Infrastructure IP Addresses (allow inbound) | Data Collection IP Addresses (allow inbound) |
| ------------------ | ------------------------------------------- | -------------------------------------------- |
| United States (US) | 34.132.108.184, 34.69.63.16 | 34.66.69.154, 35.202.21.123 |
| Canada (CA) | 35.203.108.13, 35.203.101.162 | 34.95.33.72, 34.95.62.136 |
### Cortex XSIAM inbound IP addresses in EMEA
| Region | Infrastructure IP Addresses (allow inbound) | Data Collection IP Addresses (allow inbound) |
| ------------------------------------- | ------------------------------------------- | -------------------------------------------- |
| France (FA) | 34.155.5.117, 34.155.41.247 | 34.163.125.167, 34.163.155.105 |
| Germany (DE) | 35.234.118.195, 34.89.183.45 | 34.89.197.46, 34.107.3.224 |
| Israel (IL) | 34.165.33.165, 34.165.27.131 | 34.165.131.171, 34.165.120.206 |
| Italy (IT) | 34.154.23.156, 34.154.186.12 | 34.154.208.247, 34.154.243.11 |
|
Netherlands/
Europe (EU)
| 34.147.107.51, 34.91.26.125 | 34.90.70.107, 35.204.129.196 |
| Poland (PL) | 34.118.48.171, 34.116.202.235 | 34.118.71.237, 34.118.124.130 |
| Qatar (QT) | 34.18.34.118, 34.18.39.155 | 34.18.44.71, 34.18.30.132 |
| Saudi Arabia (SA) | 34.166.61.81, 34.166.58.213 | 34.166.59.20, 34.166.53.242 |
| South Africa (ZA) | 34.35.42.196, 34.35.79.219 | 34.35.69.156, 34.35.60.86 |
| Spain (ES) | 34.175.46.46, 34.175.80.182 | 34.175.27.251, 34.175.198.50 |
| Switzerland (CH) | 34.65.108.153, 34.65.155.169 | 34.65.225.124, 34.65.89.6 |
| United Kingdom (UK) | 35.242.180.163, 34.105.173.229 | 34.105.227.146, 34.105.137.22 |
| Finland (F) | 34.88.97.182, 34.88.189.1 | 35.228.192.167, 34.88.193.126 |
### Cortex XSIAM inbound IP addresses in JPAC
| Region | Infrastructure IP Addresses (allow inbound) | Data Collection IP Addresses (allow inbound) |
| ---------------- | ------------------------------------------- | -------------------------------------------- |
| Australia (AU) | 34.151.83.236, 34.116.67.90 | 35.197.181.108, 35.197.175.44 |
| India (IN) | 35.200.175.78, 34.93.9.198 | 34.93.3.196, 34.93.175.218 |
| Indonesia (ID) | 34.128.126.138, 34.128.82.158 | 34.101.158.32, 34.101.79.159 |
| Japan (JP) | 35.200.3.131, 34.146.181.233 | 34.85.68.167, 34.84.99.239 |
| Singapore (SG) | 35.240.243.57, 34.126.183.208 | 35.247.148.38, 35.247.173.40 |
| South Korea (KR) | 34.64.93.168, 34.64.237.45 | 34.64.107.163, 34.64.84.25 |
| Taiwan (TW) | 34.80.133.68, 35.234.18.10 | 35.201.142.86, 35.189.176.163 |
# FedRAMP and US federal Cortex XSIAM required resources
Configure required Cortex XSIAM network resources for FedRAMP and US federal government deployments.
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.
| Source | Compliance Level | IP Addresses |
| ------------------------ | ------------------------------------ | ------------------------------------ |
| Egress | FedRAMP Moderate | 34.122.220.113, 35.223.83.172 |
| FedRAMP High | 34.136.155.252, 34.133.46.50 | |
| Outbound IPs for Engines | FedRAMP Moderate | 34.123.127.174:443, 34.71.135.18:443 |
| FedRAMP High | 34.123.153.175:443, 35.223.253.2:443 | |
### Core Cortex XSIAM communication resources
These resources handle agent registration, heartbeats, data uploads, and API connections. All ports are 443 unless specified otherwise.
| Resource/Function | FQDN | IP Address & Port | App-ID |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------- | ----------------- | -------------------------- |
| Initial registrationUsed for the first request in registration flow where the agent passes the distribution ID and obtains the **`ch-`*****``*****`.traps.paloaltonetworks.com`** of its tenant | `distributions-prod-fed.traps.paloaltonetworks.com` | 104.198.132.24 | `traps-management-service` |
| Agent heartbeat and data uploadUsed for all other requests between the agent and its tenant server, including heartbeat, uploads, action results, and scan reports. | `ch-.traps.paloaltonetworks.com` | 130.211.195.231 | `traps-management-service` |
| EDR data uploadUsed for EDR data upload. | `dc-.traps.paloaltonetworks.com` | 130.211.195.231 | `traps-management-service` |
| API gatewayUsed for API requests and responses. | `api-.xdr.federal.paloaltonetworks.com` | 130.211.195.231 | N/a |
| Verdict requestsUsed for get-verdict requests. | `cc-.traps.paloaltonetworks.com` | 35.222.50.74 | `traps-management-service` |
| Live terminalUsed in live terminal flow. | `wss://lrc-fed.paloaltonetworks.com` | 35.188.188.91 | `cortex-xdr` |
| App proxy | `app-proxy.federal.paloaltonetworks.com` | 35.186.217.42 | N/a |
### Cortex XSIAM content updates and GCP storage
These resources are hosted on Google Cloud Platform. All ports are 443 unless otherwise specified.
| Resource/function | FQDN | IP Addresses | |
| ---------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------- | ---------------- | ------------ |
|
| FQDN | IP Addresses | App-ID |
| InstallersUsed to download installers for upgrade actions from the server. | `panw-xdr-installers-prod-fr.storage.googleapis.com` | IP ranges in GCP | `cortex-xdr` |
| Legacy payloadsUsed to download the executable for the live terminal for Cortex XDR agents earlier than version 7.1.0. | `panw-xdr-payloads-prod-fr.storage.googleapis.com` | IP ranges in GCP | `cortex-xdr` |
| Content updatesUsed to download content updates. | `global-content-profiles-policy-prod-fr.storage.googleapis.com` | IP ranges in GCP | `cortex-xdr` |
| Scanning verdictsUsed to download extended verdict request results in scanning. | `panw-xdr-evr-prod-fr.storage.googleapis.com` | IP ranges in GCP | `cortex-xdr` |
### Cortex XSIAM Broker VM resources
Required only for deployments utilizing Broker VM features. All ports are 443, unless otherwise stated.
| Resource/Function | FQDN | IP Addresses | App-ID |
| --------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------- | -------------- | :------------------------: |
| Broker connection | `br-.xdr.federal.paloaltonetworks.com` | 34.71.185.11 | N/a |
|
Registration
Used for the first request in the registration flow, for Broker VMs to obtain their specific connection URLs.
Used by the Broker VM to ensure accurate timestamping for forwarded logs.
| N/a | UDP port 123 | N/a |
### Cortex XSIAM authentication and SSO
Required for administrator login and Single Sign-On. All ports are 443 unless specified
| Resource | FQDN | IP Addresses and Port | App-ID |
| ---------------- | ------------------------------- | --------------------- | :----: |
| Identity service | `identity.paloaltonetworks.com` | 34.107.215.35 | N/a |
| Login service | `login.paloaltonetworks.com` | 34.107.190.184 | N/a |
### Cortex XSIAM ingress for third-party data collection
Allow traffic from these IPs to your network when collecting data from SaaS and Cloud resources.
| IP Addresses | App-ID |
| ---------------------------------------------------- | ------------ |
|
34.68.217.16
34.69.175.202
| `cortex-xdr` |
### 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/onboard-cortex-xsiam/post-deployment/data-and-log-forwarding/forward-logs-and-data-from-cortex-xsiam-to-external-services/configure-external-applications-for-forwarding/integrate-a-syslog-receiver).
# Set up users, groups, and roles
Learn how to set up users and roles in Cortex XSIAM.
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-xsiam/onboard-cortex-xsiam/post-deployment/manage-user-roles-and-access-management#UUID-071cdbb6-6c6a-6afe-3a67-1fa79991a0a8).
Cortex Gateway and the tenant have different options and requirements.
| Location | Details |
| ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Cortex Gateway |
A centralized portal for managing roles, user groups, and users for all tenants. Any roles and user groups created in Cortex Gateway are available for all tenants.
In Cortex Gateway, on the Permissions page, you can manage users that have been added to your Customer Support Portal account or view users that have been created in the tenant using SSO (you cannot edit SSO users in Cortex Gateway). All users must have at least one role or belong to at least one user group to be saved in the Cortex Gateway. You can exclude different tenants or different Cortex products. For more information, see Cortex Gateway Administrator Guide.
Note
To make users visible in the Users list within the Cortex tenant, an administrator must first assign them the Cortex User role in the Customer Support Portal (CSP). For more information, see Manage user roles.
Only users with the Account Admin role can manage roles, tenants, and user groups in Cortex Gateway.
|
| Cortex XSIAM tenant |
(Recommended) All permissions and roles are specific to the tenant and exist only at the tenant level. Advanced settings, such as SBAC and Dataset access management, can be defined at the tenant level.
Managing users, roles, scopes, user groups, and authentication settings in Cortex XSIAM requires View/Edit RBAC permissions for Access Management (under Configurations). Account Admin and Instance Administrator roles are granted this permission by default.
|
### **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](/cortex-xsiam/reference-and-developer-docs/role-based-access-control/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.
{% hint style="info" %}
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.
{% endhint %}
Super user and administrative roles
| Role | Description | Recommended use |
| ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Account Admin |
A super user role that is assigned directly to the user in Cortex Gateway or a tenant and has full access to all Cortex products in your account, including all tenants added in the future. In Cortex Gateway, the Account Admin can assign roles to Cortex instances and activate product-specific Cortex tenants. This user has the same view/edit permissions in the tenant as the Instance Administrator.
The user who activated the Cortex product is assigned the Account Admin role. You cannot create additional Account Admin roles in the Cortex XSIAM tenant. If you do not want the user to have Account Admin permission, you must remove the Account Admin role in Cortex Gateway.
| Assign to the primary platform administrator, typically the security operations director, or designated platform owner. This role should be limited to a very small number of trusted users. |
| Instance Administrator | View and edit permissions for all components and access all pages in the Cortex XSIAM tenant. The Instance Administrator can also make other users an Instance Administrator for the tenant. If the tenant has predefined or custom roles, the Instance Administrator can assign those roles with scopes to other users. |
Assign to instance-level administrators who need full control over a specific tenant, but should not automatically gain access to other instances in the account.
Common scenarios include multi-tenant deployments, MSSP environments, and delegated admins (for example, a team lead gets full admin on their team's instance without access to other teams' instances).
|
| Deployment Admin |
Manage and control endpoints, installations, and configure Broker VMs.
The Deployment Admin is a focused infrastructure role for teams responsible for rolling out and maintaining Cortex XDR Agents. It provides full control over agent installations, endpoint groups, and broker configuration, but excludes security operations capabilities like issue triage, case response, and detection rule management.
| Assign to IT operations staff who need to deploy agents across the organization, manage agent groups and installations, configure broker VMs, and set up integrations. |
| IT Admin |
Manage and control endpoints and installations, configure Broker VMs, view endpoint profiles and policies, and view issues.
The IT Admin extends the Deployment Admin with cases and issue visibility, host insights, and general configuration access.
| Assign to IT administrators who need security awareness but without security authority. They need to see issues and policies (troubleshooting, understanding endpoint behavior), but cannot configure or respond to cases. |
| Privileged IT Admin |
Manage and control endpoints and installations, configure Broker VMs, create profiles and policies, view issues, and initiate Live Terminal.
This permission is significantly more extensive than the standard IT Admin. It includes response actions, script execution, detection rule editing, cloud security policies, compliance management, and Live Terminal access. This role is closer to a Security Admin than a typical IT Admin.
| Assign to senior IT administrators or IT security leads who need full endpoint management capabilities plus the ability to respond to cases, edit detection rules, manage policies/profiles, and access cloud security features. |
| Scoped Agent Admin |
Can only access product areas that support endpoint Scoped-Based Access Control (SBAC) - Agent Administration, Action Center, Response, Dashboards, and Reports.
Scoped Agent Admin is designed for SBAC. All permissions are limited to the endpoint scope assigned to the user. The role focuses on response actions and agent management within that scope, with no access to investigation, detections, settings, or cloud security features.
| Assign to regional IT admins, site-specific endpoint managers, or MSSP analysts who should only manage and respond to endpoints within a specific scope (for example, a geographic region, business unit, or customer). SBAC ensures they cannot see or act on endpoints outside their assigned scope. |
Security and investigation roles
| Role | Description | Recommended use |
| ------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Investigator | The base investigation role. Provides case/issue triage (edit) with investigation tools (such as query center and Query Library (edit), but no response actions and no detection rule management, host insights, or configuration access. | Assign to SOC Tier-1 analysts who triage incoming issues, update case status, and escalate to senior analysts. They can investigate using queries and view forensics data, but cannot isolate endpoints, run scripts, or modify detection rules. |
| Privileged Investigator |
Extends Investigator role with rules visibility, threat intel, and action center. Can view and triage issues, cases, and rules, and view profiles and policies, with Analytics management. No response actions, detection rule editing, endpoint, or configuration access.
While a standard Investigator focuses on viewing and triaging issues, the Privileged Investigator is granted deeper View/Edit access to the investigation logic itself.
| Assign to senior SOC analysts or threat hunters who need to understand detection rules, edit threat intel indicators, manage playbooks/scripts, and have visibility into endpoint policies, but who do not need to perform response actions like isolating endpoints or running Live Terminal. |
| Responder | Adds response actions to the Investigator base. Can view and triage issues, and access all response capabilities (isolate, terminate, quarantine), but no Live Terminal, rule editing, or configuration access. | Assign to SOC Tier-2 analysts who need to take immediate containment actions (isolate, terminate, quarantine) when responding to confirmed threats, plus the ability to edit detection rules and manage threat intel. |
| Privileged Responder |
Can view and triage cases and issues, and combines full response (including Live Terminal), rule editing, endpoint policy management, and playbook/script editing. No access management, alert notifications, broker management, or data sources management.
A Privileged Responder is primarily about advanced remediation and administrative control.
| Assign to SOC Tier-3 analysts or senior case responders who handle complex cases end-to-end, from deep investigation through containment, remediation, and rule tuning. They need Live Terminal for hands-on endpoint investigation, script execution for custom response actions, and the ability to update detection rules based on findings. |
| Investigation Admin | View and triage issues and cases, configure rules, view endpoint profiles and policies, and manage analytics. A senior investigation role focused on rule configuration, full investigation, response actions (action center, device control, host firewall), but no Live Terminal and no agent management. | Assign to detection engineers, SOC leads, or threat intelligence managers who focus on tuning detection rules, managing playbooks, and overseeing investigation workflows, but who delegate hands-on response actions to Responder roles. This role is about building and maintaining the detection and investigation infrastructure rather than performing case response. |
| Security Admin |
Can triage and investigate issues and cases, respond (excluding Live Terminal), and edit profiles and policies. A comprehensive security role with response actions (excluding Live Terminal), rule editing, policy/profile editing, agent management, and configuration access.
A Security Admin maintains integrations, log flow, and system health.
| Assign to security engineers or SOC managers who need to manage the security posture end-to-end, configuring detection/prevention rules, managing endpoint policies and profiles, setting up data sources and integrations, and responding to incidents with basic containment actions. |
| Privileged Security Admin | Triage and investigate issues and cases, and respond to and edit profiles and policies. The most powerful security role. Everything Security Admin has, plus Live Terminal, file operations, script execution, playbook editing, device control editing, host firewall editing, audit, alert notifications, broker management, etc. | Assign to senior security administrators or CISO-designated security leads who need unrestricted security operations capabilities. They handle the most critical incidents requiring Live Terminal access, manage the full detection and response stack, configure broker infrastructure, and oversee audit trails. The only capabilities reserved above this role are user/role management (Access Management) and application hub management, which require Account/Instance Administrator. |
| Viewer | Provides broad read-only access across almost all areas, such as dashboards, policies, endpoints, configurations, and audit, but has no edit permissions, including edit, respond, or configure. | Assign to stakeholders, managers, auditors, or compliance officers who need visibility into the security posture and operations but should never modify anything. Also useful for new SOC team members during onboarding who need to observe before being granted active permissions. |
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.
| Role | Description | Recommended use |
| --------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Developer |
Read-only Cloud Application Security role designed for developers who need to see scan results and security findings but not modify security policies or rules.
Users can view AppSec detection rules, policies, issues, and all scan types (periodic, CI/CD, PR scans), as well as cloud security dashboards and policies. They also have view access to dashboards, reports, issues, asset management, compliance, and edit access for the CLI tool.
| Developers need to see the security issues found in their code, scan results, detection rule details, and policy violations, so they can fix them. This gives developers the visibility to remediate issues while keeping security governance in the hands of the AppSec Admin. |
| AppSec Admin |
Full permissions for all Cloud Application Security-related activities. Create and modify detection rules within the Code/Build domain, track progress, and adjust enforcement as needed. Additionally, triage and investigate findings, issues, and cases spanning from code to cloud. The role also includes complete visibility into all cloud assets.
However, there are no response actions, no agent management, and no general configuration.
| Assign to an application security team lead or AppSec engineer who manages the entire AppSec program. They configure what gets scanned, define detection rules for code vulnerabilities, set enforcement policies, triage AppSec findings, and manage the integration pipeline between code repositories and the security platform. |
| DevSecOps |
Provides complete visibility on all Cloud Application Security assets, findings, issues, and scans, plus edit permissions on Scan management pages.
It sits between the Developer (view-only) and AppSec Admin (full edit) roles. DevSecOps users can view all AppSec data like the Developer, but additionally can track, investigate code scans, and rescan failed scans. They cannot modify detection rules, enforcement policies, or issue status.
|
Assign to DevSecOps engineers within development teams who need to actively manage the scanning pipeline, monitor scan progress, investigate scan failures, and trigger rescans, while leaving policy and rule management to the AppSec Admin.
This role bridges development and security by giving DevSecOps practitioners hands-on scan management without the ability to weaken security policies.
|
| Compliance Administrator |
View/Edit access to Compliance Catalog Assessment Profiles and Compliance Reports. Broad view access across the tenant, including cases/issues, forensics, host insights, detection rules, endpoints, configurations, and audit.
No edit permissions on anything except compliance features. For more information about compliance permissions, see Compliance - Cloud permissions.
| Assign to compliance officers or audit managers who need to manage the organization's compliance posture. Having read-only visibility into the broader security operations helps to understand context. |
| AI Security Viewer |
Provides read-only access to the AI Security module plus broad view access to related security areas.
The role can view AI security findings, issues, and the AI security inventory. It also has view access to dashboards, cloud security dashboards, reports (with edit), issues, query center, compliance (view), cloud security rules/policies, CWP policies, asset management, and asset groups.
|
Assign to stakeholders, analysts, or team members who need to monitor AI security posture. See what AI models, applications, and data pipelines exist in the organization and what security issues have been identified, without the ability to modify AI security configurations.
Useful for AI/ML team leads who want visibility into how their AI assets are being secured, or for SOC analysts who need to see AI-related findings during investigations.
|
| AI Security Administrator |
View/Edit access to the AI Security module plus extensive capabilities, including issue triage, full response actions, playbook/script editing, compliance management, cloud security rule/policy editing, CWP policy editing, asset management, and data sources management.
It is a powerful role that combines AI security management with broad security operations capabilities.
|
Assign to the AI security program owner or AI Security engineer who manages the organization's AI security posture end-to-end. They configure AI security policies, manage AI asset inventory, respond to AI-related security incidents, and ensure compliance of AI systems.
The extensive response and investigation capabilities allow them to handle AI security cases directly, from detection through containment and remediation, without needing a separate security operations role.
|
| Data Security Viewer |
Read-only access to the Cloud Data Security for monitoring the organization's cloud data security posture. It can view data security findings, data objects, data patterns, and classification results.
It also has view access to dashboards (including cloud security dashboards), reports (edit), issues, query center, compliance, cloud security rules/policies, CWP policies, asset management, and DLP-related features, such as data-in-motion rules and endpoint applications.
| Assign to Data privacy officers, DLP analysts, compliance team members, or data governance stakeholders who need to monitor the organization's data security posture, without the ability to modify any Data Security configurations, data classification policies, or DLP settings. |
| Data Security Administrator | View/Edit access to the Data Security module plus extensive capabilities including issue triage, full response actions, playbook/script editing, compliance management, cloud security rule/policy editing, CWP policy editing, DLP management, and asset management editing. | Assign to the data security program owner or the Data Security engineer who manages the organization's data security posture. They configure data classification policies, manage data security findings, respond to data-related security cases, and ensure compliance with data handling practices. |
| Identity Security Runtime Viewer |
Read-only access to the baseline Identity Analytics and Identity Runtime Detection Rules. Users with this role can view identity-based analytics alerts, user and host risk scores, behavioral analytics profiles, and raw directory data queries. They cannot modify detection rules, analytics configurations, or any system settings.
Note
Relevant for Behavioral Analytics & Identity Threat Detection and Response (ITDR).
| SOC Tier-1 analysts, Tier-1 responders, or auditors who need to investigate identity-related analytics alerts and review user/host risk profiles without the ability to change detection rules or system configurations. This role provides sufficient access for issue triage, initial investigation, and escalation workflows. |
| Identity Security Runtime Administrator |
Full administrative (View/Edit) access to the baseline Identity Analytics and Identity Runtime Detection Rules. Users can view, create, modify, and manage identity-based analytics detection rules, configure the Identity Analytics module, and take response actions on identity-related findings. They have full control over the runtime identity analytics pipeline.
Note
Relevant for Behavioral Analytics & Identity Threat Detection and Response (ITDR).
| Senior SOC analysts (Tier-2/3), detection engineers, or security architects responsible for deploying, tuning, and maintaining identity-based analytics detection rules. This role is appropriate for team members who build and optimize the identity analytics detection pipeline, manage automated response playbooks, and need to take direct action on identity-related findings. |
| Identity Security Viewer |
Read-only access to the full Identity Security module, including both the baseline Identity Analytics capabilities and the advanced Identity Threat Detection and Response (ITDR) features.
Users can view the Identity Security dashboards (Identity Overview, Risk Overview), browse the complete identity asset inventory across cloud, SaaS, and on-premises environments, review identity posture and threat issues, view detection rules, and monitor conditional access policies and audit logs. They cannot modify any configurations, rules, or policies.
Note
Relevant for Identity Posture & Cloud Infrastructure Entitlements (CIEM).
These features require the ITDR add-on, a Cloud Posture Security, Cloud Runtime Security, or Cortex XSIAM Premium license.
| Risk analysts, compliance officers, or SOC analysts (Tier-1/2) who need deep, comprehensive visibility into the organization's overall identity risk posture, spanning cloud entitlements, behavioral analytics, user/host risk profiles, and high-value asset exposure. This role is ideal for personnel who need to investigate identity-related findings across all data sources, generate reports for stakeholders, and monitor the effectiveness of identity security controls without the ability to modify them. |
| Identity Security Administrator |
Full administrative (View/Edit) access to the complete Identity Security module, including both the baseline Identity Analytics capabilities and all advanced Identity Threat Detection and Response (ITDR) features.
Users have unrestricted control over the entire identity security posture. They can manage identity asset inventories, create and tune posture and threat detection rules, configure conditional access policies, manage data source connections, configure asset role classifications for risk scoring, and execute the full range of response actions.
Note
Relevant for Identity Posture & Cloud Infrastructure Entitlements (CIEM).
These features require the ITDR add-on, a Cloud Posture Security, Cloud Runtime Security, or Cortex XSIAM Premium license.
|
Identity security engineers, IAM administrators, or risk managers who are actively responsible for the organization's identity security posture. This role is appropriate for personnel who configure behavioral analytics, build and tune detection rules across both posture and threat domains, manage conditional access policies, configure identity data source integrations, tune asset role classifications for risk scoring, and oversee the overall identity risk management program.
This is the most privileged identity security role and should be assigned sparingly, following the principle of least privilege.
|
| Exposure Management Administrator |
Full access to security controls and effectiveness rules features within the Exposure Management module. It limits view access to most features, with View/Edit access specifically for Vulnerability Management and Exposure Management.
This role is focused on managing the organization's attack surface exposure and vulnerability remediation priorities.
| Assign to vulnerability management engineers, exposure management analysts, or attack surface management leads who need to configure and manage security controls, effectiveness rules, vulnerability management data, and exposure management settings. |
Service account roles
Predefined roles designed for non-human, machine-to-machine authentication within the tenant.
| Role | Description | Recommended Use |
| ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
| Generic Collector |
Generic Collector is a machine-only service account role with the minimum permissions required by the 3rd-party scanners. Its sole purpose is to authenticate API calls from external AppSec scanners (for example, Snyk, SonarQube, Checkmarx) that send their findings to the collector endpoint
It is not intended for users. It follows the principle of least privilege; the API key can only ingest scan data.
| Admins can see what role is assigned to collector API keys and understand the permission scope. |
| App Service Account |
A service account role for Application instances (Jupyter notebooks, Observability apps). It provides a broad set of permissions that apps typically need to interact with the tenant programmatically to view and triage issues, cases, and rules, and support public APIs.
Note
This role automatically assigns API keys generated for App instances. When an Application instance is created, the system automatically generates an API key with this role, allowing the app instance to interact with the tenant, reading issues, creating cases, querying data, and updating threat intel.
| Admins can see what role is assigned to auto-generated API keys and understand their permission scope. This role is not intended for users. |
| CLI Role | A service account role with the specific permissions required for the Command Line Interface (CLI) tool to perform security operations. For more information, see [Cortex CLI usage](/cortex-xsiam/reference-and-developer-docs/about-cortex-cli/cortex-cli-usage). | Assign to API keys used by the CLI tool for automated security operations and scripting. |
| CLI Read Only Role | A read-only service account role for the CLI tool. It provides visibility into security data without allowing modifications. For more information, see [Cortex CLI usage](/cortex-xsiam/reference-and-developer-docs/about-cortex-cli/cortex-cli-usage). | Assign to API keys used by the CLI tool for data extraction, reporting, or monitoring where modifications are not required. |
# Manage Cortex XSIAM user groups
Manage Cortex XSIAM user groups for RBAC, SBAC scoping, SAML mapping, and Active Directory synchronization.
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.
{% hint style="info" %}
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).
{% endhint %}
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](/cortex-xsiam/onboard-cortex-xsiam/post-deployment/manage-user-roles-and-access-management/manage-user-scope#understand-scoping). Before configuring SBAC, ensure that you review **Understand scoping** in the [Manage user scope](/cortex-xsiam/onboard-cortex-xsiam/post-deployment/manage-user-roles-and-access-management/manage-user-scope#understand-scoping) 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](/cortex-xsiam/onboard-cortex-xsiam/deployment-steps/set-up-users-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](/cortex-xsiam/onboard-cortex-xsiam/deployment-steps/set-up-authentication/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](/cortex-xsiam/onboard-cortex-xsiam/deployment-steps/set-up-authentication/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](/cortex-xsiam/onboard-cortex-xsiam/deployment-steps/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.
{% hint style="warning" %}
### 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](broken://pages/biuuG1IS5OSUz5bKfSom#UUID-ad5006d0-cb45-2631-bed2-129d796c6a74) for complete instructions on handling directory lifecycle cleanups and managing stale accounts.
{% endhint %}
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 |
Select the group role associated with this user group. You can only have a single role designated per group.
In Cortex Gateway, you can only select either Instance Administrator or a custom role created in the Gateway.
Note
For non-administrator users, the Instance Administrator role is unavailable from the dropdown menu.
|
| Users |
Select the users you want to belong to this user group.
Note
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.
If you have not yet created any users, skip this field and add them later. See Set up authentication .
|
| Nested Groups |
Lists any nested groups associated with this user group. If you have an existing group, you can add a nested group.
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.
For example:
Group A has Tier-1 Analyst permissions
Group B has Tier-2 Analyst permissions
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).
In Cortex Gateway, you can only add user groups that are created in Cortex Gateway.
|
| SAML Group Mapping |
(Relevant when creating a user group in the Cortex tenant only.)
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.
You can add multiple groups by pressing enter after each name to build a list.
Note
Capitalization is vital. String evaluation enforces absolute case mapping rules. The name must match your IdP's string configuration exactly.
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.
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.
|
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 |
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.
|
{% hint style="warning" %}
### 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](/cortex-xsiam/onboard-cortex-xsiam/post-deployment/manage-user-roles-and-access-management/manage-user-scope#understand-scoping).
{% endhint %}
4. Click **Create** to create the user group.
Import an Active Directory group into Cortex XSIAM
{% hint style="info" %}
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.
{% endhint %}
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 |
Type to search the CIE in real time, and choose a group or Organizational Unit (OU) to import from Active Directory.
Only CSP and SSO users already existing in Cortex will be imported.
|
| 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 |
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.
You can add multiple groups by pressing enter after each name to build a list.
Note
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.
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.
|
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 user roles and groups
Assign Cortex XSIAM roles and groups, configure RBAC permissions, and apply SBAC granular access.
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.
{% hint style="info" %}
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.
{% endhint %}
## 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**.
{% stepper %}
{% step %}
Select **Settings** → **Configurations** → **Access Management** → **Users**.
{% endstep %}
{% step %}
Right-click the relevant user and select **Edit User Permissions**.
{% hint style="info" %}
To apply the same settings to multiple users, select them, and then right-click and select **Edit Users Permissions**.
{% endhint %}
{% endstep %}
{% step %}
Ensure the **Role** tab is selected.
{% endstep %}
{% step %}
Under **Role**, select the default or custom role.
{% endstep %}
{% step %}
(Optional) Under **User Groups**, add the user to a group.
{% endstep %}
{% step %}
(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.
{% hint style="warning" %}
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](/cortex-xsiam/onboard-cortex-xsiam/post-deployment/manage-user-roles-and-access-management#UUID-751d26ed-9390-dddd-d4f6-bb1f20db3a1d).
{% endhint %}
{% endstep %}
{% step %}
(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:
{% hint style="warning" %}
Before configuring, ensure you review **Understand scoping** in the [Manage user scope](/cortex-xsiam/onboard-cortex-xsiam/post-deployment/manage-user-roles-and-access-management#UUID-071cdbb6-6c6a-6afe-3a67-1fa79991a0a8) section.
{% endhint %}
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](/cortex-xsiam/onboard-cortex-xsiam/post-deployment/manage-user-roles-and-access-management/manage-user-scope#UUID-071cdbb6-6c6a-6afe-3a67-1fa79991a0a8_section-idm235041053079477) (under **Understand scoping** → **Scoping Areas** → **Assets**).
The scoping of assets also affects the scoping of cases, issues, and findings.
{% hint style="info" %}
Visibility of Security domain Issues that refer to assets with agents is controlled by the **Endpoints** scoping configuration.
{% endhint %}
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](/cortex-xsiam/configure-cortex-xsiam/cortex-xsiam-data-sources/administration-and-troubleshooting/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”`.
{% hint style="warning" %}
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](/cortex-xsiam/onboard-cortex-xsiam/post-deployment/manage-user-roles-and-access-management/manage-user-scope).
{% endhint %}
{% endstep %}
{% step %}
Save the user group.
{% endstep %}
{% endstepper %}
**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](/cortex-xsiam/onboard-cortex-xsiam/post-deployment/manage-user-roles-and-access-management#UUID-a112c99e-112f-ab8a-e5ed-e31445dee8fe).
# Set up authentication
Authenticate Cortex XSIAM users using SAML 2.0 or Customer Support Portal (CSP).
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](/cortex-xsiam/onboard-cortex-xsiam/deployment-steps/set-up-users-and-roles/assign-user-roles-and-groups).
{% hint style="info" %}
You should have at least one user in the Customer Support Portal for backup, in case of any authentication issues with your IdP provider.
{% endhint %}
# Authenticate users through the Customer Support Portal
Authenticate Cortex XSIAM users through Customer Support Portal and assign Gateway or tenant access roles.
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.
{% hint style="info" %}
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.
{% endhint %}
How to authenticate users through the Customer Support Portal
{% stepper %}
{% step %}
### Add the user to your Customer Support Portal.
Sign in to the [Customer Support Portal](https://support.paloaltonetworks.com/) 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](https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClNPCA0).
* **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](https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClNXCA0).
{% endstep %}
{% step %}
### Wait for the user to accept
The user accepts the invitation. They can then sign in to Cortex Gateway.
{% endstep %}
{% step %}
### 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.
{% endstep %}
{% endstepper %}
# Authenticate users using SSO
Configure Cortex XSIAM SAML 2.0 single sign-on with identity providers, group mapping, and user provisioning.
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.
{% hint style="info" %}
* 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.
{% endhint %}
### 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
| Parameter | Description |
| --------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| IdP SSO or Metadata URL |
Select the option that meets your organization's requirements.
Indicates your SSO URL, which is a fixed, read-only value based on your tenant's URL using the format https\://\.crtx.paloaltonetworks.com/idp/saml. For example,
You need this value when configuring your IdP.
|
| IdP SSO URL | Specify your organization’s SSO URL, which is copied from your organization’s IdP. |
| Metadata URL | |
| Audience URI (SP Entity ID) |
Indicates your Service Provider Entity ID, also known as the ACS URL. It is a fixed, read-only value using the format, https\://\.paloaltonetworks.com. For example .
You need this value when configuring your organization’s IdP.
|
| Default Role | (Optional) Select the default role that you want any user to automatically receive when they are granted access to Cortex XSIAM through SSO. This is an inherited role and is not the same as a direct role assigned to the user. |
| IdP Issuer ID | Specify your organization’s IdP Issuer ID, which is copied from your organization’s IdP. |
| X.509 Certificate | Specify your X.509 digital certificate, which is copied from your organization’s IdP. |
| Domain | Relevant only for multiple SSOs. For one SSO, this is a fixed, read-only value. Associate this IdP with a specific email domain (user@\). When logging in, users are redirected to the IdP associated with their email domain or to the default IdP if no association exists. |
IdP attribute mapping
These IdP attribute mappings are dependent on your organization’s IdP.
| Parameter | Description |
| ---------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Email | Specify the email mapping according to your organization’s IdP. |
| Group Membership |
Specify the group membership mapping according to your organization’s IdP.
Note
Cortex XSIAM requires the IdP to send the group membership as part of the SAML token. Some IdPs send values in a format that include a comma, which is not compatible with Cortex XSIAM. In that case, you must configure your IdP to send a single value without a comma for each group membership. For example, if your IdP sends the Group DN (a comma-separated list), by default, you must configure IdP to send the Group CN (Common Name) instead.
|
| First Name | Specify the first name mapping according to your organization’s IdP. |
| Last Name | Specify the last name mapping according to your organization’s IdP. |
Advanced settings
The following advanced settings are optional to configure and some are specific for a particular IdP.
| Parameter | Description |
| ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Relay State | (Optional) Specify the URL for a specific page that you want users to be directed to after they’ve been authenticated by your organization’s IdP and log in to Cortex XSIAM. |
| IdP Single logout URL | (Optional) Specify your IdP single logout URL provided by your organization’s IdP to ensure that when a user initiates a logout from Cortex XSIAM, the identity provider logs the user out of all applications in the current identity provider login session. |
| SP Logout URL | (Optional) Indicates the Service Provider logout URL that you need to provide when configuring a single logout from your organization’s IdP to ensure that when a user initiates a logout from Cortex XSIAM, the identity provider logs the user out of all applications in the current identity provider login session. This field is read-only and uses the following format `https://.crtx.paloaltonetworks.com/idp/logout`, such as `https://tenant1.crtx.paloaltonetworks.com/idp/logout`. |
| Service Provider Public Certificate | (Optional) Specify your organization’s IdP service provider public certificate. |
| Service Provider Private Key (Pem Format) | (Optional) Specify your organization’s IdP service provider private key in Pem Format. |
| Remove SAML RequestedAuthnContext |
(Optional) Requires users to log in to Cortex XSIAM using additional authentication methods, such as biometric authentication.
Selecting this removes the error generated when the authentication method used for previous authentication is different from the one currently being requested. See here for more details about the RequestedAuthnContext authentication mismatch error.
|
| Force Authentication | (Optional) Requires users to reauthenticate to access the Cortex XSIAM tenant if requested by the idP, even if they already authenticated to access other applications. |
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.
# Set up Okta as the Identity Provider Using SAML 2.0
Configure Okta SAML 2.0 single sign-on and group mapping for Cortex XSIAM users.
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](https://help.okta.com/oie/en-us/content/topics/apps/apps_apps.htm).
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](https://help.okta.com/asa/en-us/content/topics/adv_server_access/docs/setup/create-a-group.htm) 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**.
# Set up Microsoft Entra ID as the Identity Provider Using SAML 2.0
Configure Microsoft Entra ID SAML 2.0 single sign-on, security group claims, and user group mapping for Cortex XSIAM.
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](https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/add-application-portal-setup-sso).
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](https://www.youtube.com/watch?v=nwF3hY3wgc0).
Task 1. Configure Microsoft Entra ID Security Groups
Within Microsoft Entra ID, assign users to [security groups](https://learn.microsoft.com/en-us/azure/active-directory/fundamentals/how-to-manage-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](#UUID-1192642a-c44e-58e5-4af1-b3654ab2e41a_N1698222696896) 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**.
# Configure content
Configure Cortex XSIAM data sources with standard collectors, Broker VM applets, XDR Collectors, CSP onboarding, and content packs.
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
| Data Source Type | Primary Use | Configuration Method | Cortex XSIAM Features | Recommendation |
| --------------------------------------------------- | -------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Standard data source (also called data collectors) | Ingesting raw logs and events. | Configured in the **Data Sources & Integrations** page using the Data Source Onboarder. | Limited to data ingestion, parsing, and normalization. | Choose this if you only need raw data ingestion. |
| Cloud Service Provider (CSP) onboarding data source | Ingest cloud assets | Configured in the **Data Sources & Integrations** page using the cloud service provider (CSP) onboarding wizard. | Designed to facilitate the seamless setup of CSP data into Cortex XSIAM. Requires minimal user input; simply define the scope of your CSP accounts and specify the scan mode. For full control of the CSP setup, you can use the advanced settings. Based on the onboarding settings, Cortex XSIAM generates an authentication template to establish trust to the CSP and grant permissions to Cortex XSIAM. | |
| Content pack integration | Ingesting data and enabling rich security functionality. |
Configured via a content pack downloaded from Marketplace by either:
Using the Data Source Onboarder on the Data Sources & Integrations page (if available)
Installing the content pack from Settings → Configurations → Marketplace, and then configuring the integration instance on the Data Sources & Integrations page.
| **Includes**: Data ingestion, parsing, normalization, plus built-in commands and automations, such as playbooks, scripts, correlation rules, and data model rules. |
Choose this option for any of the following reasons:
You need to define automations.
You need to collect data that is not covered by a standard collector.
You need to install rules or automations relevant to integrations or data sources.
|
To add a new data source, see [Add a new data source or instance](/cortex-xsiam/configure-cortex-xsiam/cortex-xsiam-data-sources/administration-and-troubleshooting/manage-instances/add-a-new-data-source-or-instance).
To add a content pack from Marketplace, see [Install content packs](/cortex-xsiam/onboard-cortex-xsiam/post-deployment/cortex-marketplace/install-content-packs).
# Set up Cloud Identity Engine
Learn how to set up Cloud Identity Engine to use with Cortex XSIAM.
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.
# Install Cortex XDR agents
Install Cortex XDR agents with agent installation packages to monitor endpoints and collect Cortex XSIAM endpoint data.
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.
# Create an agent installation package
Create Cortex XDR agent installation packages for endpoints, Kubernetes, container, and serverless workloads in Cortex XSIAM.
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](/compatibility-matrix) 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](/7.x/7.1-eol/changes-to-default-behavior).
* (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:
{% hint style="info" %}
Requires the Cortex Cloud Runtime Security or Cortex XSIAM Premium license. Every 10 container-embedded agents will consume a single Cortex Runtime Security license.
{% endhint %}
**Prerequisites**
| Supported Environments |
The following managed container services are supported:
AWS ECS Fargate; containers using x86\_64 and AArch64 architecture
|
| Limitations | Alpine Linux and other musl-based distributions are not supported for container-embedded deployments. |
**Create the container-embedded agent Dockerfile via API:**
See the API reference guide: [Create Distributions](broken://spaces/1ZrobAtcwfCDWAJAWeuj/pages/77559efbcb35263dc41a77532056f7ec55374506#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.
{% hint style="info" %}
NOTE:
The profile will be applied if the security policy cannot be retrieved in real-time.
{% endhint %}
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.
# Deploy installation packages
Deploy Cortex XDR agent installation packages to Windows, macOS, Linux, Kubernetes, and Android endpoints using manual or software distribution methods in Cortex XSIAM.
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](/cortex-xdr-agent/8.1-eol)
* [Agent iOS Guide](/cortex-xdr-agent-ios-guide)
* [Agent Android Guide](/cortex-xdr-agent-android-guide)
# Endpoint data collection
Review endpoint metadata, EDR events, Windows event logs, and performance metrics collected by Cortex XDR agents for Cortex XSIAM.
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:
| Field | Description |
| ---------------------- | -------------------------------------------------------------------- |
| Absolute timestamp | Kernel system time |
| Relative timestamp | Uptime since the computer started |
| Thread ID | ID of the originating thread |
| Process ID | ID of the originating process |
| Process creation time | Part of the process unique ID per boot session (PID + creation time) |
| Sequence ID | Unique integer per boot session |
| Primary user SID | Unique identifier of the user |
| Impersonating user SID | Unique identifier of the impersonating user, if applicable |
EDR data collected for Windows endpoints
| Category | Events | Attributes |
| ------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Mount a device (volume and hardware) |
Mount
Unmount
|
Storage device name
Storage device class GUID
Storage device class name
Storage device bus type
Storage device volume GUID
Storage device mount point
Storage device drive type
Storage device vendor ID
Storage device product ID
Storage device serial number
Storage device virtual volume image
|
| Executable metadata | Process start |
File size
File access time
|
| Files |
Create
Write
Delete
Rename
Move
Modification
Symbolic links
Read
|
Full path of the modified file before and after modification
SHA256 and MD5 hash for the file after modification
SetInformationFile for timestamps
File set security (DACL) information
Resolve hostnames on local network
Symbolic-link/hard-link and reparse point creation
File device type (regular file or Named Pipe)
|
| Image (DLL) | Load |
Full path
Base address
Target process-id/thread-id
Image size
Signature
SHA256 and MD5 hash for the DLL
File size
File access time
|
| Process |
Create
Terminate
|
Process ID (PID) of the parent process
PID of the process
Full path
Command line arguments
Integrity level to determine if the process is running with elevated privileges
Hash (SHA256 and MD5)
Signature or signing certificate details
|
| Thread | Injection |
Thread ID of the parent thread
Thread ID of the new or terminating thread
Process that initiated the thread if from another process
|
| Network |
Accept
Connect
Create
Listen
Close
Bind
|
Source IP address and port
Destination IP address and port
Failed connection
Protocol (TCP/UDP)
Resolve hostnames on local network
|
| Network protocols |
DNS request and UDP response
HTTP connect
HTTP disconnect
HTTP proxy parsing
|
Origin country
Remote IP address and port
Local IP address and port
Destination IP address and port if proxy connection
Network connection ID
IPv6 connection status (true/false)
External hostname
|
| Network statistics |
On-close statistics
Periodic statistics
|
Upload volume on TCP link
Download volume on TCP link
Traps sends statistics both when a connection is closed, and at periodic intervals while the connection remains open.
|
| Registry |
Registry value:
Deletion
Set
Registry key:
Creation
Deletion
Rename
Addition
Modification (set information)
Restore
Save
Registry key is collected as a real key name, and not as a symbolic link.
Instead of HKEY\_LOCAL\_MACHINE\System\CurrentControlSet, which is a symbolic link, KEY\_LOCAL\_MACHINE\System\ControlSet001 will be collected.
Instead of HKEY\_CURRENT\_USER, HKEY\_USERS\<SID> will be collected, where SID is a SID of the current user.
|
Registry path of the modified value or key
Name of the modified value or key
Data of the modified value
|
| Session |
Log on
Log off
Connect
Disconnect
|
Interactive log-on (log-on at a computer console using credentials such as a username and password)
Session ID
Session State (equivalent to the event type)
Local (physically on the computer) or remote (connected using a terminal services session)
|
| Host status |
Boot
Suspend
Resume
|
Host name
OS Version
Domain
Previous and current state
|
| Agent status | Agent start | |
| User presence | User Detection | Detection when a user is present or idle per active user session on the computer. |
| RPC calls |
RpcCall
RpcPreCall
|
action\_rpc\_interface\_uuid
action\_rpc\_interface\_version\_major
action\_rpc\_interface\_version\_minor
action\_rpc\_func\_opnum
action\_rpc\_func\_str\_call\_fields (optional)
action\_rpc\_func\_int\_call\_fields (optional)
action\_rpc\_interface\_name
action\_rpc\_func\_name
|
| System calls | Syscall types change frequently, and can be observed in each event's data. |
action\_syscall\_string\_params
action\_syscall\_int\_params
action\_syscall\_target\_instance\_id
action\_syscall\_target\_image\_path
action\_syscall\_target\_image\_name
action\_syscall\_target\_os\_pid
action\_syscall\_target\_thread\_id
address\_mapping
|
| Event log | See the table below for the list of Windows Event Logs that can be sent to the server. | |
| .Net events |
.NET DLL Loaded
.NET DLL Loaded From Buffer
Amsi Bypass Attempt
Suspicious .NET To Win32 Calls
.NET To Native Shellcode Execution Attempt
Malicious C# Compilation and Execution Attempt
Powershell Script Execution
Obfuscated Powershell Execution Attempt
Deserialization Exploit Attempt
Webshell Execution Attempt
Suspicious ASPX execution
Exchange Vulnerability Attempt
SharePoint JWT Vulnerability Attempt
|
DotNetCommon\_DotnetCallstack
DotNetCommon\_CLRVersion
DotNetCommon\_ContentVersion
DotNetCommon\_EdrAssemblyVersion
DotNetCommon\_AppDomainId
Other attributes may be added, depending on the event type and context.
|
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](/cortex-xsiam/reference-and-developer-docs/reference/microsoft-windows-security-auditing-setup).
| Path | Provider | Event IDs and Description |
| ------------------------------------------------------------------ | --------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Application | EMET | |
| Application | Windows Error Reporting | Only for Windows Error Reporting (WER) events when an application stops unexpectedly |
| Application | Microsoft-Windows-User Profiles Service |
1511: A user logged on with a temporary profile because Windows could not find the user's local profile.
1518: A profile could not be created using a temporary profile
|
| Application | Application Error | **1000**: Application unexpected stop/hang events, similar to WER/1001. These events include the full path to the EXE file, or to the module with the fault. |
| Application | Application Hang | **1002**: Application unexpected stop/hang events, similar to WER/1001. These events include the full path to the EXE file, or to the module with the fault. |
| Microsoft-Windows-LDAP-client | | **30**: Windows Event Collector (WEC) recommended event |
| Microsoft-Windows-CAPI2/Operational | |
Windows CAPI2 logging events:
11: Build Chain
70: A Private Key was accessed
90: X509 object
|
| Microsoft-Windows-DNS-Client/Operational | | **3008**: A DNS query was completed without local machine name resolution events, and without empty name resolution events. |
| Microsoft-Windows-DriverFrameworks-UserMode/Operational | | **2004**: Detection of User-Mode drivers loading, for potential BadUSB detection |
| Microsoft-Windows-PowerShell/Operational | |
4103: Block an activity
4104: Remote command
4105: Start command
4106: Stop command
|
| Microsoft-Windows-PrintService | Microsoft-Windows-PrintService | |
| Microsoft-Windows-TaskScheduler/Operational | Microsoft-Windows-TaskScheduler | **106, 129, 141, 142, 200, 201** |
| Microsoft-Windows-TerminalServices-RDPClient/Operational | | **1024**: A terminal service (TS) attempted to connect to a remote server |
| Microsoft-Windows-Windows Defender/Operational | |
1006: Microsoft Defender Antivirus detected suspicious behavior
1009: Microsoft Defender Antivirus restored an item from quarantine
4886: Certificate Services received a certificate request
4887: Certificate Services approved a certificate request
4899: A Certificate Services template was updated
4900: Certificate Services template security was updated
5140: A network share object was accessed
|
| Security | Microsoft-Windows-Security-Auditing | **4713**: Kerberos policy was changed on a domain controller |
| Security | Microsoft-Windows-Security-Auditing | **4662**: An operation was performed on an Active Directory object |
EDR data collected for Mac endpoints
| Category | Events | Attributes |
| --------- | --------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Files |
Create
Write
Delete
Rename
Move
Open
|
Full path of the modified file before and after modification
SHA256 and MD5 hash for the file after modification
|
| Process |
Start
Stop
|
Process ID (PID) of the parent process
PID of the process
Full path
Command line arguments
Integrity level to determine if the process is running with elevated privileges
Hash (SHA256 and MD5)
Signature or signing certificate details
|
| Network |
Accept
Connect
Connect Failure
Disconnect
Listen
Statistics
|
Source IP address and port
Destination IP address and port
Failed connection
Protocol (TCP/UDP)
Aggregated send/receive statistics for the connection
|
| Event log |
Authentication
|
Provider Name
Data fields
Message
|
EDR data collected for Linux endpoints
| Category | Events | Attributes |
| --------- | -------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Files |
Create
Open
Write
Delete
|
Full path of the file
Hash of the file
For specific files only and only if the file was written.
|
| Files |
Copy
Move (rename)
|
Full paths of both the original and the modified files
|
| Files |
Change owner (chown)
Change mode (chmod)
|
Full path of the file
Newly set owner/attributes
|
| Network |
Listen
Accept
Connect
Connect failure
Disconnect
|
Source IP address and port for explicit binds
Destination IP address and port
Failed TCP connections
Protocol (TCP/UDP)
|
| Process |
Start
|
PID of the child process
PID of the parent process
Full image path of the process
Command line of the process
Hash of the image (SHA256 & MD5)
|
| Process |
Stop
|
PID of the stopped process
|
| Event log |
Authentication
|
Provider Name
Data fields
Message
|
IT performance metrics
| Field | Description |
| ------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Time |
Generated time
Timestamp
|
| Agent information |
Agent ID
Agent hostname
Agent OS type
Agent host boot time
Agent session start time
Agent request time
|
| Event information |
Event ID
Event type
Event subtype
Event version
Event timestamp
|
| Actor information | Actor process instance ID |
| OS actor information |
OS actor process instance ID
OS actor process OS PID
OS actor process OS name
|
| Sample information |
Sample start
Sample end
|
| CPU usage information |
CPU max
CPU average
CPU 90th percentile
|
| Memory usage information |
Memory max
Memory average
Memory 90th percentile
|
| Vendor | Vendor name |
| Product | Product name |
| ZIP | ZIP ID |
| Server information | Server request time |
# Configure global agent settings
Configure global Cortex XDR agent settings for uninstall passwords, content bandwidth, upgrades, advanced analysis, and endpoint cleanup for Cortex XSIAM.
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](/cortex-xsiam/protect-your-endpoints/endpoint-security/endpoint-protection/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.
# Define endpoint groups
Create and manage static or dynamic Cortex XDR Agent endpoint groups to target security policies and actions by endpoint attributes for Cortex XSIAM.
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.
# Manage endpoint profiles
Manage Cortex XSIAM endpoint security profiles and policy mappings to apply reusable threat protection settings across endpoint groups.
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.
# Guidelines for keeping Cortex XDR agents and content updated
Plan phased Cortex XDR agent upgrades and content updates with rollout schedules, staging content, and bandwidth controls in Cortex XSIAM.
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
{% hint style="info" %}
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](https://app.gitbook.com/s/AEIjuYE3RXcIfmuQnBbm/deployment-steps/install-cortex-xdr-agents/define-endpoint-groups).
{% endhint %}
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:
| Item | Options | Description |
| ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Automatic Upgrade Scope |
Latest agent release (Default)
One release before the latest one
Only maintenance releases
Only maintenance releases in a specific version
|
For One release before the latest one, Cortex XSIAM upgrades the agent to the previous release before the latest, including maintenance releases. Major releases are numbered X.X, such as release 8.0, or 8.2. Maintenance releases are numbered X.X.X, such as release 8.2.2.
For Only maintenance releases in a specific version, select the required release version.
|
| Upgrade Rollout |
Immediate (Default)
Delayed
|
The Cortex XDR agent automatically fetches any new agent release, maintenance and new features.
For Delayed, set the delay period (number of days) to wait after the version release before upgrading endpoints. Choose a value between 7 and 45.
|
| Scheduling |
Hours
Days of the week
| Schedule the upgrade task for specific time and days of the week. |
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 |
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.
Set the number of parallel agent upgrades, where the maximum is 500 agents.
|
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.
| [](https://docs-cortex.paloaltonetworks.com/viewer/attachment/5CAbsl8idaK8R43ZLhoTOw/QljK8yvhXwcveIjxv3NO7g-5CAbsl8idaK8R43ZLhoTOw) |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
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.
| Item | Options | More details |
| ------------------- | ---------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Content Auto-Update |
Enabled (Default)
Disabled
|
When Content Auto-Update is enabled, the Cortex XDR agent retrieves the most updated content and deploys it on the endpoint.
If you disable content updates, the agent stops retrieving them from the Cortex XSIAM tenant, and keeps working with the current content on the endpoint.
|
| Staging Content |
Enabled
Disabled (Default)
| Enable users to deploy agent staging content on selected test environments. Staging content is released before production content, allowing for early evaluation of the latest content update. |
| Content Rollout |
Immediate (Default)
Delayed
Specific
|
The Cortex XDR agent can retrieve content updates immediately as they are available, after a pre-configured delay period of up to 30 days, or you can select a specific version.
When you delay content updates, the Cortex XDR agent will retrieve the content according to the configured delay. For example, if you configure a delay period of two days, the agent will not use any content released in the last 48 hours.
|
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 |
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.
Cortex XSIAM supports between 20 - 10000 Mbps.
It is recommended to allocate a minimum of 20 Mbps, or you can enter a value.
|
| 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. |
# Cortex XSIAM - Analytics
Learn how to enable Cortex XSIAM - Analytics, which allows Cortex XSIAM to analyze data from a variety of sensors and develop a baseline to raise analytics alerts.
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.
{% hint style="warning" %}
### 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.
{% endhint %}
# Configure Cortex XSIAM network parameters
Configure Cortex XSIAM internal IP address ranges and domain suffixes for network asset identification, tracking, and analysis.
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 |
1. Click Add New Range → Create New, and then enter the IP address name and IP address range or CIDR values.
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.
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.
2. Click Save.
|
| Upload IP address ranges from a CSV file |
1. Select Inventory+Assets → Network Configuration → IP Address Ranges.
2. Click Add New Range → Upload from File.
3. Locate the CSV file you want to upload, and then click Add.
|
### **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**.
# Enable the Analytics Engine and Identity Analytics
Enable Cortex XSIAM Analytics Engine and Identity Analytics to baseline activity and detect anomalous endpoint and user behavior.
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.
{% hint style="warning" %}
### 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](/cortex-xsiam/onboard-cortex-xsiam/deployment-steps/set-up-cloud-identity-engine).
{% endhint %}
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.
# FedRAMP overview
Learn how FedRAMP standardizes cloud security assessment, authorization, and continuous monitoring for U.S. government agencies.
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 FedRAMP compliance for federal agencies
Learn how FedRAMP-authorized Cortex XSIAM supports U.S. federal agencies with isolated tenants, U.S. data residency, and government cloud infrastructure.
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 )](/application-security/software-supply-chain-security/risk-and-remediation/software-composition-analysis-sca-scanners).
# Onboard and configure government cloud environments
Onboard government cloud environments to Cortex XSIAM with the CSP wizard, Government tenant settings, and compliant scan modes.
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.
# FedRAMP limitations and supported government cloud regions
Review Cortex XSIAM FedRAMP feature limitations and supported AWS GovCloud and Azure Government regions for federal deployments.
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.
| Provider | Supported regions |
| ---------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| AWS GovCloud |
AWS GovCloud (US-East) - us-gov-east-1
AWS GovCloud (US-West) - us-gov-west-1
|
| Azure Government |
US Gov Arizona - usgovarizona
US Gov Texas - usgovtexas
US Gov Virginia - usgovvirginia
|
# Post-deployment
Complete Cortex XSIAM post-deployment tasks, including health checks, automations, and reviews of security cases and issues.
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:
* [Cortex XSIAM post-deployment checklist](/cortex-xsiam/onboard-cortex-xsiam/post-deployment/post-deployment-checklist)
* [Perform health checks](/cortex-xsiam/onboard-cortex-xsiam/post-deployment/perform-health-checks)
* [Cortex Marketplace](/cortex-xsiam/onboard-cortex-xsiam/post-deployment/cortex-marketplace)
* [Manage user roles and access management](/cortex-xsiam/onboard-cortex-xsiam/post-deployment/manage-user-roles-and-access-management)
* [Dashboards and reports](/cortex-xsiam/onboard-cortex-xsiam/post-deployment/dashboards-and-reports)
* [Configure server settings](/cortex-xsiam/onboard-cortex-xsiam/post-deployment/configure-server-settings)
* [Configure security settings](/cortex-xsiam/onboard-cortex-xsiam/post-deployment/configure-security-settings)
* [Data and log forwarding](/cortex-xsiam/onboard-cortex-xsiam/post-deployment/data-and-log-forwarding)
# Cortex XSIAM post-deployment checklist
Use this Cortex XSIAM post-deployment checklist for health checks, automations, case triage, XDR agent rollout, and integrations.
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.
{% hint style="info" %}
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](/cortex-xsiam/configure-cortex-xsiam/cortex-xsiam-data-sources/cloud-service-provider-csp-onboarding).
{% endhint %}
### 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.
| Action | Details | See More |
| ----------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Perform health checks | ✅ Validate logs, detectors, and update prevention policies. It is recommended to perform health checks, including updating prevention policies, monitoring operational status, and validating detectors for any issues or cases. | [Perform health checks](/cortex-xsiam/onboard-cortex-xsiam/post-deployment/perform-health-checks) |
| Configure automations | ✅ Review the different types of automations (playbooks and scripts) and apply automation rules to your use case. | [Create an automation rule](/cortex-xsiam/configure-cortex-xsiam/automations/create-an-automation-rule) |
| Review cases and issues |
✅ Monitor the Cases page for new, generated cases (grouped issues) and begin basic triage exercises with the analyst team. Look for cases or issues that were generated.
✅ Check that your automation rules are working as expected and reflect the cases for your use case. Check whether your playbooks are responding to alerts and incidents as expected.
✅ Validate your workflow. Start with Widfire testing to confirm the security controls and sandbox integration are functional and working as expected. For example, acquire a safe, benign sample unknown to Wildfire, attempt to execute it, and confirm that the XDR agent’s malware prevention file intercepts the execution. Confirm that a case/issue was generated and the file verdict is populated.
✅ Review and test the default Behavioral Indicators of Compromise (BIOC). Review severity levels and exceptions on pre-built BIOCs to minimize false positives, especially for legitimate administrative tools and scripts.
✅ Review and test the default Indicator of Compromise (IOC) rules. Ensure all known bad indicators from historical incidents or key threat intelligence feeds are loaded, enabled, and prioritized.
|
### 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.
| Action | Details | See More |
| ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Set up relevant integrations |
✅ Install essential content packs (for example, common security use cases or SOAR playbook) and configure relevant integrations, from the Data Sources catalog.
If your use case is not in the Data Sources catalog, you can install content from Marketplace. For example, if you require content packs such as Phishing and Malware, you need to download the pack from Marketplace and configure the integration. The Data Sources catalog includes the most used data sources to help you onboard.
| [What are Cortex XSIAM data sources?](/cortex-xsiam/configure-cortex-xsiam/cortex-xsiam-data-sources/what-are-cortex-xsiam-data-sources) |
| Update users and roles | ✅ Review and configure users, roles, and user groups as required. Each role extends specific privileges to users. The way you configure administrative access depends on your organization's security requirements. Use roles to assign specific access privileges to administrative user accounts. | [Manage user roles and access management](/cortex-xsiam/onboard-cortex-xsiam/post-deployment/manage-user-roles-and-access-management) |
| Dashboards | ✅ Review and configure dashboards and ensure you can visualize activity from your active log sources (for example, VPN logins, Firewall blocks). | [Overview of dashboards and reports](/cortex-xsiam/detect-investigate-and-respond-to-threats/monitor-dashboards-and-reports/overview-of-dashboards-and-reports) |
| Server and security settings |
✅ Customize and configure Cortex XSIAM for a more personalized user experience:
Server settings, such as the timezone, the timestamp format, password protection, and custom logos for communication task emails.
Security settings, such as allowed domains, allowed sessions, and user expiration.
|
| Log forwarding | ✅ Set up sending logs to an external service, such as a Slack channel or an email distribution list. | [Forward logs and data from Cortex XSIAM to external services](/cortex-xsiam/onboard-cortex-xsiam/post-deployment/data-and-log-forwarding#UUID-8cf9dc23-530e-9c23-89bc-9ebfccd6b949) |
Expand the XDR Agent deployment
This stage involves customizing policies and gradually rolling out the XDR Agent to all users.
| Action | Details | See More |
| ------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Customize endpoint security profiles and policies |
✅ Review your policy rules and the security profiles assigned to these rules and make any necessary adjustments. After the pilot group has been running for about a week, analyze the cases and issues that were generated. You may find issues with benign activity, such as in-house applications or custom scripts. Do the following:
Create exceptions to prevent false positives
Start building your primary prevention policies to suit your use case as necessary
| [Set up endpoint profiles and exception rules](/cortex-xsiam/protect-your-endpoints/endpoint-security/install-and-manage-endpoints#UUID-8e42879c-93b8-fb0c-baff-1fe6544db66d) |
| Expand the agent deployment | ✅ Expand the Agent deployment to larger groups for initial data collection. | |
| Define endpoint groups |
✅ (Optional, can be performed post-deployment) Define an endpoint group to apply policy rules and manage specific endpoints.
Instead of managing security policies and configurations for each device, you can manage them for the entire group. For example, create a High-Security Prevention Profile and apply it to an entire group, Critical Financial Servers.
Note
If you set up Cloud Identity Engine, you can also leverage your Active Directory user, group, and computer details in endpoint groups.
| [Define endpoint groups](/cortex-xsiam/protect-your-endpoints/endpoint-security/install-and-manage-endpoints/define-endpoint-groups) |
| Complete the XDR agent deployment | ✅ Gradually distribute the Cortex XDR agent throughout the organization until all endpoints are protected. You can do this at any time during post-deployment. | |
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.
| Action | Details | |
| ---------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Set up XDR Collectors for specific Windows/Linux logs (optional) |
✅ Set up XDR Collectors (XDRCs), which are installed directly on a Windows or Linux machine to collect log files from that machine's local file system. They are crucial for ingesting detailed Windows and Linux event logs from systems where the full Cortex XDR Agent may not be deployed, or to collect specific log types, complementing agent data.
✅ After installing XDRCs, create/configure a profile and apply it to a policy. The XDRC then starts collecting and forwarding the logs to Cortex XSIAM.
| [XDR Collectors](/cortex-xsiam/configure-cortex-xsiam/cortex-xsiam-data-sources/generic-on-premise-data-collectors/xdr-collectors/manage-xdr-collectors) |
| Set up and configure Broker VM (optional but highly recommended) |
✅ Set up the Broker VM, which functions as a secure on-prem gateway for Cortex XSIAM. It centralizes on-prem data collection by running applets to ingest logs from on-prem security devices and services that can’t send data directly to the cloud. It also allows secure agent proxy and communication located in restricted or air-gapped networks to communicate securely with the Cortex XSIAM tenant.
Note
You can also use the Broker VM for high availability.
| [Set up and configure Broker VM](/cortex-xsiam/configure-cortex-xsiam/data-management/broker-vm/set-up-and-configure-broker-vm) |
| Set up and deploy an engine (optional) |
✅ Deploy an engine if you have specific automation and feed integrations, scripts, or playbooks that execute actions or fetch data directly from resources within your internal network (for example, querying an on-prem Active Directory, isolating a machine via a local tool).
An engine is a proxy server application that is installed on a remote machine, enabling communication between the remote machine and the Cortex XSIAM tenant. You can run playbooks, scripts, commands, and integrations on the remote machine, and the results are returned to the tenant.
| [What is an engine?](/cortex-xsiam/configure-cortex-xsiam/engines/what-is-an-engine) |
After completing the post-deployment steps, you can now start configuring Cortex XSIAM.
# Perform health checks
Perform Cortex XSIAM health checks for prevention policies, Cortex XDR agents, WildFire testing, alerts, cases, and log ingestion.
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, see[Set up endpoint protection](/cortex-xsiam/protect-your-endpoints/endpoint-security/install-and-manage-endpoints/set-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](/cortex-xsiam/onboard-cortex-xsiam/post-deployment/perform-health-checks/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](https://docs.paloaltonetworks.com/wildfire/u-v/wildfire-api/get-wildfire-information-through-the-wildfire-api/get-a-malware-test-file-wildfire-api).
* **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/learn-about-cortex-xsiam/cortex-xsiam-product-licenses/data-storage-lifecycle).
# Monitor agent operational status in Cortex XSIAM
Monitor Cortex XDR agent operational status in Cortex XSIAM, including protected, partially protected, unprotected, and resource-impact states.
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.
| Status | Description |
| ------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Protected** | (Windows, Mac, and Linux) Indicates all protection modules are running as configured on the endpoint. |
| **Partially protected** |
Windows
XDR data collection is not running, or not set
Behavioral threat protection is not running
Malware protection is not running
Exploit protection is not running
Mac
Operating system adaptive mode\*
XDR Data Collection is not running, or not set
Behavioral threat protection is not running
Malware protection is not running
Exploit protection is not running
Linux
Kernel module not loaded\*\*
Kernel module compatible but not loaded\*\*
Kernel version not compatible\*\*
XDR Data Collection is not running, or not set
Behavioral threat protection is not running
Anti-malware flow is asynchronous
Malware protection is not running
Exploit protection is not running
Any of the listed items could lead to a partially protected state. Refer to the Cortex XSIAM management console for specific reasons for the state.
|
| **Unprotected** |
Windows, Mac, and Linux:
Behavioral threat protection and Malware protection are not running
Exploit protection and malware protection are not running
The content is unavailable.
|
| **Local Resource Impact** |
Windows, Mac, Linux
Machine CPU impact on the agent operation
Machine memory impact on the agent operation
In addition to the status, either one of the following sub-statuses appear:
Low local available memory
No local available memory
|
{% hint style="warning" %}
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
{% endhint %}
# Cortex Marketplace
Discover Cortex Marketplace content packs for integrations, playbooks, automations, correlation rules, dashboards, and security use cases.
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:
| Content | Description |
| -------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Actions | Actions wrap diverse capabilities (such as playbooks, scripts, and commands) to make them accessible and executable by an agent. |
| Classifiers | Classification determines the type of issue/indicator that is created for events ingested from a specific integration. You create a classifier and define that classifier in an integration. Mappers map the fields from your third-party integration to the fields in your issue/indicator layouts. |
| Correlation Rules | Analyzes the correlation of multiple events from multiple sources by using the Cortex XSIAM XQL-based engine for creating these correlation (scheduled) rules. Issues can then be triggered based on these rules with a defined time frame and schedule. |
| Dashboards | Dashboards consist of visualized data powered by fully customizable widgets, which enable you to analyze data from inside or outside Cortex XSIAM, in different formats such as line charts, tables, text, etc. |
| Data Model Rules |
Data Model rules enable you to normalize logs for out-of-the-box analytics and data enrichment. This allows you to do the following:
Map 3rd-party data to a consolidated schema with predefined data types.
Enjoy auto-complete and mapping suggestions.
Map multiple datasets to one Data Model.
Some content packs contain out-of-the-box default Data Model Rules.
|
| Indicator types and fields | Indicators are categorized by indicator type, which determines the indicator layout and fields that are displayed and which scripts are run on indicators of that type. |
| Integrations |
You can define the following integrations:
(SOAR) Automation: Add your 3rd-party security and alert management vendors, which can then trigger events from these integrations that become issues in Cortex XSIAM. Once the issues are created, you can run playbooks on these issues to enrich them with information from other products in your system, which helps you complete the picture.
Collection (SIEM): Add integrations that collect raw events, such as logs. These integrations are separate from automation integrations so that you can add a collection integration that requires read permissions without having to add automation (read and write permissions).
|
| Issue types and fields |
All issues that are ingested into Cortex XSIAM are assigned an issue type when they are classified. After you classify the issue, you can then map the relevant fields to the issue.
Issue types contain fields that are relevant to the issue type.
|
| Layouts and layout rules |
Enables you to add rules, which define the layout of issues and notifications,
When installed, the layout rules are enabled and added as Default Rules. When deleted, all related layout rules (including all Rule sections) are removed from the Default Rules tab.
|
| Parsing rules |
Enables you to add rules, which remove non-required data for analytics, hunting, or regulation, reduce data storage costs, pre-process all incoming data, etc.
When installed, the parsing rules are enabled and added as Default Rules. When deleted, all related parsing rules (including all Rule sections) are removed from the Default Rules tab.
|
| Playbooks | You can automate many security processes, including handling investigations and managing tickets and security responses that were previously handled manually. When an issue is ingested, the playbook runs and an issue is created. |
| Reports | Reports contain statistical data in the form of widgets (from a dashboard), which enable you to analyze data from inside or outside Cortex XSIAM, in different formats such as line charts, tables, text from information, etc. |
| Scripts | Perform specific actions and are comprised of commands, which are used in playbook tasks and when running commands in the issue War Room. |
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](https://cortex.marketplace.pan.dev/marketplace/).
# Content packs
Explore pre-installed and recommended Cortex Marketplace content packs for integrations, playbooks, scripts, widgets, and security workflows.
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](https://cortex.marketplace.pan.dev/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](https://cortex.marketplace.pan.dev/marketplace/details/CommonScripts/), [Common Widgets](https://cortex.marketplace.pan.dev/marketplace/details/CommonWidgets/), [Common Playbooks](https://cortex.marketplace.pan.dev/marketplace/details/CommonPlaybooks/), [Common Types](https://cortex.marketplace.pan.dev/marketplace/details/CommonTypes/), [Common Reports](https://cortex.marketplace.pan.dev/marketplace/details/CommonReports/), [Common Dashboards](https://cortex.marketplace.pan.dev/marketplace/details/CommonDashboards/)
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](https://cortex.marketplace.pan.dev/marketplace/details/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](https://cortex.marketplace.pan.dev/marketplace/details/Phishing/)
Create and respond to phishing issues based on user reports.
* [Cortex XDR by Palo Alto Networks](https://cortex.marketplace.pan.dev/marketplace/details/CortexXDR/)
Automate Cortex XDR incident response. Includes custom Cortex XDR incident views and layouts to aid analyst investigations.
* [Atlassian Jira](https://cortex.marketplace.pan.dev/marketplace/details/Jira/)
Manage Jira tickets directly from Cortex XSIAM, enrich them with Cortex XSIAM data, and mirror information between Jira tickets and Cortex issues.
* [ServiceNow](https://cortex.marketplace.pan.dev/marketplace/details/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](https://cortex.marketplace.pan.dev/marketplace/details/PANOS/)
Manage Palo Alto Networks Firewall and Panorama from Cortex XSIAM.
* A collaboration integration, such as [Microsoft Teams](https://cortex.marketplace.pan.dev/marketplace/details/MicrosoftTeams/) or [Slack](https://cortex.marketplace.pan.dev/marketplace/details/Slack/), to send messages and notifications to your team.
{% hint style="info" %}
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](https://cortex.marketplace.pan.dev/marketplace/details/MicrosoftExchangeOnline/).
{% endhint %}
# Install content packs
Install Cortex Marketplace content packs, review dependencies, and configure integrations and data sources in Cortex XSIAM.
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.
{% hint style="info" %}
Currently, not all content packs are supported in the **Data Sources & Integrations** page. For example, content packs with several integrations are not yet supported.
{% endhint %}
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.
{% hint style="info" %}
Content packs are also automatically installed when you adopt playbooks and configure tasks.
{% endhint %}
# Manage user roles and access management
Learn how to manage access for users, user roles, user groups, and Single Sign-On (SSO) for users on a specific Cortex XSIAM tenant.
{% hint style="warning" %}
### 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](/cortex-xsiam/onboard-cortex-xsiam/deployment-steps/set-up-users-and-roles).
{% endhint %}
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.
{% hint style="info" %}
To remove users added to your CSP account, you must do so in the CSP, not in Cortex Gateway.
{% endhint %}
**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.
{% hint style="info" %}
For more information on assigning user roles when generating an API key, see [Manage API keys](/cortex-xsiam/learn-about-cortex-xsiam/manage-api-keys).
{% endhint %}
**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](#UUID-751d26ed-9390-dddd-d4f6-bb1f20db3a1d).
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](/cortex-xsiam/onboard-cortex-xsiam/post-deployment/manage-user-roles-and-access-management/manage-user-roles). For more information on row-level scoping, see [Manage user scope](/cortex-xsiam/onboard-cortex-xsiam/post-deployment/manage-user-roles-and-access-management/manage-user-scope).
{% hint style="info" %}
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.
{% endhint %}
**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.
{% hint style="info" %}
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](#UUID-751d26ed-9390-dddd-d4f6-bb1f20db3a1d).
{% endhint %}
**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.
# Manage user roles
Create and manage Cortex XSIAM user roles with RBAC permissions, XQL dataset access controls, and scoped access settings.
{% hint style="warning" %}
### 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](/cortex-xsiam/onboard-cortex-xsiam/deployment-steps/set-up-users-and-roles).
{% endhint %}
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**.
# Manage user access
Manage Cortex XSIAM user access with roles, user groups, RBAC permissions, SBAC scopes, and XQL dataset row controls.
{% hint style="warning" %}
### 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](/cortex-xsiam/onboard-cortex-xsiam/deployment-steps/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](/cortex-agentix-docs/cortex-gateway-admin-guide).
{% endhint %}
### 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](/cortex-xsiam/onboard-cortex-xsiam/post-deployment/manage-user-roles-and-access-management/manage-user-scope).
{% hint style="info" %}
### 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.
{% endhint %}
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.
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.
|
| 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.
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.
Important
For optimal performance, we recommend using a single field in the filter definition and simple comparison operators.
FIXME\_ACCORDION\_PLACEHOLDER
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.
\*\*Example 13. \*\*null
3. Scroll down the list of datasets to the dataset you want to apply a filter on, and click the Edit Scope icon.
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.
Important For optimal performance, we recommend using a single field in the filter definition and simple comparison operators.
FIXME\_ACCORDION\_PLACEHOLDER
5. (Optional) Set the Time frame for the query. The default is Last 1 day.
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.
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
|
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, .
* 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**.
# User access reference information
Reference Cortex XSIAM Users page fields for user types, direct roles, groups, group roles, and granular access scopes.
The following is a list of common fields on the **Users** page:
| Field | Description |
| ---------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Show User Subset | Displays all users except for hidden users. |
| User Type | Indicates whether a user was defined in Cortex XSIAM using the Customer Support Portal, SSO (single sign-on) using your organization’s IdP, or both Customer Support Portal/SSO. |
| Direct XDR Role | Name of the role specifically assigned to a user. When a user does not have any Cortex XSIAM access permissions assigned specifically to them, the field displays **No-Role**. |
| Groups |
Lists the groups to which a user belongs. Any group that was imported from Active Directory displays AD beside the group name.
If a user group has scoping permissions, the users in the group are granted permissions according to the user group settings, even if the user does not have configured scope settings.
|
| Group Roles | Lists the group roles based on the groups to which a user belongs. Hovering over the group role displays the group associated with this role. |
| Scope | Lists a summary of the granular scoping configured for the user. |
| Groups Scope | Lists a summary of the granular scoping configured in the user groups that the user belongs to |
# Manage user scope
Configure Cortex XSIAM Scope-Based Access Control (SBAC) for users, groups, and API keys across assets, cases, endpoints, and dataset rows.
{% hint style="warning" %}
### 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](/cortex-xsiam/onboard-cortex-xsiam/deployment-steps/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.
{% endhint %}
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](#functional-areas-that-respect-and-dont-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](/cortex-xsiam/onboard-cortex-xsiam/post-deployment/manage-user-roles-and-access-management/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](#scenarios-related-to-datasets-rows-scoping).
{% hint style="info" %}
**Note**
Access to the `asset_groups` dataset is managed through **Dataset Access Management** permissions within the user role.
{% endhint %}
**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:
{% hint style="info" %}
### Important
Some areas and features in Cortex XSIAM do not respect SBAC. In these cases, use RBAC permissions to restrict access.
{% endhint %}
| Functional Area | Description | Related scoping area |
| ------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- |
| Cases, Issues, Findings, and Assets tables | View and manage cases, issues, findings, and assets, and take actions in these tables. |
Assets
Cases and Issues
Endpoints
|
| Dashboard and Reports |
Scoping takes place only on the following:
XQL-related widgets based on XQL queries that use the cases, issues, findings, and asset\_inventory datasets, and respect only the Assets scoping area configurations.
Agent-related widgets.
Note
XQL-based dashboard widgets may require a few hours to initially reflect changes to the list or definitions of asset groups used for scoping. To view the most current data immediately, refresh the dashboard or its XQL widgets.
|
Assets
Cases and Issues
Endpoints
|
| Public APIs | Public APIs that access Cases, Issues, Findings, and Assets information respect Scope-Based Access Control (SBAC). |
Assets
Cases and Issues
|
| Cortex Query Language (XQL) |
When using XQL with cases, issues, findings, and asset\_inventory datasets, keep in the mind the following:
XQL respects asset-led SBAC and the Cases and Issues scoping configuration.
These scoping controls are enforced across all XQL-based features, including XQL queries and dashboard widgets.
Note
XQL queries for cases and issues do not respect the Endpoints scoping area configurations.
| **Assets** |
| Endpoint Administration table | View endpoints and take actions on endpoints. | **Endpoints** |
| Policy Management | Create and edit Prevention policies and profiles, Extension policies and profiles, and global and device Exceptions that are within the scope of the user. | **Endpoints** |
| Action Center | View and take actions only on endpoints that are within the scope of the user. | **Endpoints** |
| Identity Security | View and manage identity assets, permissions, and issues that are within the scope of the user. |
Assets
Cases and Issues
|
| Cloud Workload Policies | View Cloud Workload Policies when user access is scoped to any of the available options: **All assets**, **No assets**, or **Select asset groups**. When no SBAC restriction is applied, the user’s access is determined solely by their RBAC permissions. For more information, see Cloud Workload Policies and Rules. | **Assets** |
| Graph Search | Safely explore your environment in Graph Search with precise permission management. Assign users to User Groups and Asset Groups, ensuring they only see authorized graph nodes and relationships. | **Assets** |
| Access to datasets | 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. | **Datasets Rows** |
**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](/cortex-xsiam/onboard-cortex-xsiam/post-deployment/manage-user-roles-and-access-management/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](/cortex-xsiam/onboard-cortex-xsiam/post-deployment/manage-user-roles-and-access-management/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](#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](#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**.
{% hint style="info" %}
### 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.
{% endhint %}
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](/cortex-xsiam/configure-cortex-xsiam/cortex-xsiam-data-sources/administration-and-troubleshooting/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](/cortex-xsiam/onboard-cortex-xsiam/post-deployment/manage-user-roles-and-access-management/manage-user-scope#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”`.
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.
# Manage access to objects
Manage Cortex XSIAM per-object access for dashboards, reports, playbooks, scripts, and saved XQL queries using owner, editor, and viewer roles.
Cortex XSIAM enforces least-privileged access by allowing you to manage access for individual instances of custom (user-defined) objects. Access management for these items is handled through a common experience for per-object access, which allows you to treat these tools as distinct objects with their own access settings.
### What are Objects?
Objects are the tools used to visualize, analyze, and interact with information within Cortex XSIAM. By managing access at the object level, you can isolate sensitive information between teams (such as SOC vs. Internal Threat) or departments (such as CloudOps vs. SecOps).
In Cortex XSIAM, objects are functional components or configurations. There are two primary categories of objects:
**Custom objects**
User-defined objects created, imported, or duplicated by users. These are the primary focus of per-object access management.
Supported custom objects include:
* Dashboards and widgets
* Report Templates
* Playbooks and Scripts
* Saved Cortex Query Language (XQL) queries (located in the Query Library)
**System objects**
Out-of-the-box objects provided by Palo Alto Networks. These are **Public** by default and are read-only; they cannot be edited or deleted, and their ownership cannot be changed. Yet, they can often be duplicated to create a custom version. System objects are available to any user who has the corresponding component (such as **Dashboards & Reports** → **Dashboards** or **Investigation & Response** → **Automations** → **Playbooks**) enabled in their role.
### Access examples
Granular per-object access supports various organizational security requirements:
1. **Use only by SOC team**: A "flat" structure where all analysts can see all objects. This is the default setting for the tenant. By default, newly created custom objects, such as a specific investigation dashboard or a complex XQL saved query, are **Restricted** and visible only to the creator; the owner can then make them **Public** to allow the entire team to view or edit them based on their role permissions.
2. **Both SOC team and Internal threat**: Specific objects, such as sensitive dashboards and saved queries, are created by a member of the Internal Threat team and made accessible only to the Internal Threat user group. Members of the Internal Threat team create these objects and share them only with their peers or their specific user group. Members of the SOC team do not have access to these objects, as they are not visible or accessible to any users who have not been explicitly granted access.
3. **Both SOC team and Cloud team**: Provides department isolation. Each team only accesses its own custom objects, such as playbooks and scripts; the SOC team cannot see Cloud team objects, and vice versa.
### Key concepts
Before configuring access, it is important to understand the different states and roles that define an object's security access.
**General access states**
The **General access** setting determines the baseline visibility for an object:
* **Restricted** (default): To ensure least privileged access, all newly created custom objects are **Restricted** by default. The object is visible only to the **Owner** and those specifically shared with.
* **Public**: The object is visible to all users who have that component enabled in their role permissions. Users with the additional **Edit Public \[Object]** role permissions can also modify these custom objects.
**Per-object roles**
* **Owner**: The person who created the object. Every object has an assigned Owner responsible for managing its lifecycle and access. Owners have full control, including the ability to edit content, delete the object, and, depending on tenant-level settings, share the object with other principals (users, user groups, or API keys) as an Editor or Viewer. For more information, on tenant-level settings, see [Step 1: Configure tenant-level access settings](#step-1-configure-tenant-level-access-settings).
Note
Only the Owner or an Administrator can delete a custom object.
* **Editor**: Can view and modify the object. They can also manage access for others if permitted by tenant settings.
* **Viewer**: Can see the definition of the object and its results, such as see the underlying logic of a script or view a dashboard, but cannot make any changes to the configuration or access settings.
* **Administrative access**: Account and Instance Administrators have inherent visibility into all objects (including **Restricted** ones) regardless of whether they have been explicitly shared with them. They can also **Change Owner** for any object.
Important
While Per-object access controls the visibility of the object (such as a dashboard or saved query), the underlying data remains governed by Scope-Based Access Control (SBAC). A user must have the appropriate SBAC permissions to view the data available through an object.
**API enforcement**
Public APIs for functional objects strictly enforce these object-level permissions. To interact with a **Restricted** object via the API (such as using GET, INSERT, or DELETE methods), the API Key must be explicitly added to that specific object’s access list with the required **Viewer** or **Editor** role.
### Sharing icons
The following icons indicate the sharing status and origin of an object in management tables:
* : A **Restricted** object you created that is not shared with anyone else.
* : An object you created that is currently shared with other users, groups, or API keys.
* : An object created by another user that has been shared with you.
* : A Palo Alto Networks object provided out-of-the-box. These are **Public**, read-only, cannot be deleted, and ownership cannot be transferred.
### How to change an object owner
To ensure continuity when personnel changes occur or to hand off management of an object, the ownership of an object can be changed.
* **Administrative privilege**: Only Account Admins and Instance Administrators can change the owner of an object. Other users who are Owners and Editors cannot perform this action.
* **Change Owner**: Using the **Change Owner** action in the management table of the specific object, administrators can select a new user to take over full control. Once changed, the new user assumes all Owner-level rights, including the ability to edit, delete, and share with other principals (users, user groups, and API keys).
### How to configure access to objects?
Configuring access follows a top-down workflow:
1. [Tenant-level settings](#step-1-configure-tenant-level-access-settings): Establish the "rules of engagement" for the entire instance.
2. [Role permissions](#step-2-set-role-permissions): Enable specific components and define additional capabilities for those roles.
3. [Per-object access](#step-3-configuring-per-object-access): Manage visibility and access levels for specific dashboards and queries and queries.
4. [Scope-Based Access Control (SBAC)](/cortex-xsiam/onboard-cortex-xsiam/post-deployment/manage-user-roles-and-access-management/manage-user-scope): Ensure the user has the required permissions to view the underlying data available through the object.
#### Step 1: Configure tenant-level access settings
Administrators first establish the "rules of engagement" for all objects. These settings are located under **Settings** → **Configurations** → **Access Management** → **Objects**:
* **Owners can Share objects they created**: Allows the creator (Owner) of an object to share it with users, user groups, or API keys. When enabled, the **Share** option is available in object menus. When disabled, this is replaced with the **Manage Access** option.
* **Editors can also Share objects with others**: Allows users with Editor access to further share the object with additional principals (users, user groups, and API keys).
* **Owners and editors can change the general access** (default): Allows the object owner and any user with Editor access to modify the object's **General access** settings (**Restricted** or **Public**) using the drop-down menu in the object's sharing settings. When disabled, only an administrator can change this state.
#### Step 2: Set role permissions
Once tenant-level policies are established, configure individual roles to allow users to interact with specific components. Role permissions for objects have transitioned from the legacy "None/View/View-Edit" model to a granular "Disabled/Enabled" model. To configure these:
1. Select **Settings** → **Configurations** → **Access Management** → **Roles**.
2. Right-click the relevant user role, and select **Edit Role**.
3. Under **Components**, expand each list, set the applicable component (such as **Dashboards & Reports** → **Dashboards**) to one of the following:
* **Disabled**: The component is hidden from the user's navigation menu. The user cannot access any objects associated with this component, even if they were previously shared with them.
* **Enabled**: The component is visible in the user's navigation menu. The user can view **Public** objects and any **Restricted** objects shared with them.
4. Define additional capabilities.
If enabled, refine capabilities using the following checkboxes:
* **Create \[Object]**: Allows the user to create new instances; the user is automatically designated as the **Owner** of the newly created object, which grants the inherent right to edit, delete, and manage sharing for that specific object.
* **Edit Public \[Object]**: Allows the user to modify custom objects that have been set to **Public** General access, even if they are not the owner.
5. Save the changes.
Once a component is enabled using role permissions, sharing is managed at the individual object level. Owners and authorized editors can share with other principals (users, user groups, or API keys) directly on the object.
#### Step 3. Configuring per-object access
For more information on managing visibility and access levels for specific custom objects, see the following topics:
* [Manage access to dashboards](/cortex-xsiam/onboard-cortex-xsiam/post-deployment/manage-user-roles-and-access-management/manage-access-to-objects/manage-access-to-custom-dashboards)
* [Manage access to report templates](/cortex-xsiam/onboard-cortex-xsiam/post-deployment/manage-user-roles-and-access-management/manage-access-to-objects/manage-access-to-report-templates)
* [Manage access to playbooks and scripts](/cortex-xsiam/onboard-cortex-xsiam/post-deployment/manage-user-roles-and-access-management/manage-access-to-objects/manage-access-to-playbooks-and-scripts)
* [Manage access to saved queries](/cortex-xsiam/onboard-cortex-xsiam/post-deployment/manage-user-roles-and-access-management/manage-access-to-objects/manage-access-to-saved-queries)
#### Step 4. Configure SBAC permissions
For more information on managing user scope so users have the permissions necessary to view the data available through the object, see [Manage user scope](/cortex-xsiam/onboard-cortex-xsiam/post-deployment/manage-user-roles-and-access-management/manage-user-scope).
# Manage access to custom dashboards
Manage Cortex XSIAM custom dashboard access with role permissions, object sharing, owners, editors, viewers, and SBAC data scopes.
Review the following:
* [Manage access to objects](/cortex-xsiam/onboard-cortex-xsiam/post-deployment/manage-user-roles-and-access-management/manage-access-to-objects)
The **Dashboard Manager** serves as the central repository for your visualizations. By using object-level access, you can ensure that custom (user-defined) dashboards, such as those used for sensitive executive reporting or specialized department views, are only accessible to authorized users and user groups. The permissions assigned to your role, combined with the ownership of specific objects, directly determine the content available to you; you can only access dashboards where you are the Owner, dashboards that have been explicitly shared with you (or your user group), or dashboards marked as **Public**.
{% hint style="warning" %}
### Prerequisite
* **Configure tenant-level settings**: An administrator must first establish the sharing framework under **Settings** → **Configurations** → **Access Management** → **Objects**.
The configuration of these settings defines the authorized sharing workflows for for all custom objects, including dashboards:
* **Enable "Owners can Share objects they created"**: Grants owners the ability to share dashboards with specific users and user groups. In the **Dashboard Manager**, this enables the **Share** option.
* **Disable "Owners can Share objects they created"**: Restricts owners to managing only **General access** (**Public** vs. **Restricted**). In the **Dashboard Manager**, this replaces the **Share** option with the **Manage Access** option.
For more information on configuring tenant-level settings, see [Manage access to objects](#UUID-ff05f1c8-e516-ea74-9dff-ea8b26692754).
* **Define Scope-Based Access Control (SBAC)**: While object-level sharing grants access to the dashboard's layout and configuration, users must also have the appropriate SBAC permissions to view the actual data populated within the widgets. If a user has access to a shared dashboard but lacks the required data scope for the underlying datasets, the dashboard will load, but the widgets may appear empty or display an error. For more information on defining SBAC, see [Manage user scope](#UUID-071cdbb6-6c6a-6afe-3a67-1fa79991a0a8).
{% endhint %}
Understanding dashboard behavior
Because dashboards are composed of multiple visualization elements, it is important to understand how access is applied:
* **Dashboard vs. Widget access**: Access to a dashboard is managed through the **Dashboard Manager**. When you share a dashboard, you can also manage access for any **Custom Widgets** contained within it.
* **System Widgets**: Standard system widgets provided by Cortex XSIAM remain **Public** and accessible to all users by default; their access cannot be restricted.
Understanding widget behavior
Because dashboards are composed of multiple widgets, it is important to understand how access is applied to these individual components:
* **Widgets are not objects**: Unlike dashboards, individual widgets are not treated as independent objects. They do not have their own "Share" dialog and cannot be shared independently. Within the Widget Library, a widget is set to either **Restricted** (visible only to the creator) or **Public** (visible to all with Widget Library access).
* **Inherited access**: Any user who has been granted access to a custom dashboard (as a **Viewer** or **Editor**) can see all the widgets contained within that dashboard, including those marked as **Restricted**. This means you may see a widget on a shared dashboard that you cannot see in the Widget Library even if you have access to it.
* **Dashboard Editors**: Can edit the dashboard layout, but the widget is only available in their Widget Library for editing when the widget is **Public**.
* **Dashboard Viewers**: Can't make any changes to dashboards or widgets that are **Restricted**.
Change owner of a dashboard
To ensure continuity when personnel changes occur or to hand off management of a resource, only administrators can change the ownership of a custom dashboard.
{% hint style="info" %}
### Note
Only Account Admins and Instance Administrators have the authority to change the owner of an object.
{% endhint %}
1. Select **Dashboards & Reports** → **Dashboard Manager**.
2. Right-click the custom dashboard in the table and select **Change owner**.
3. Select the new owner from the list of users, and click **Change**.
How to configure access to custom dashboards
**Step 1: Set role-level permissions**
Role permissions define the functional capabilities for dashboards and the Widget Library, and determine what actions a user can take.
1. Select **Settings** → **Configurations** → **Access Management** → **Roles**.
2. Right-click the relevant user role, and select **Edit Role**.
3. Under **Components**, expand **Dashboards & Reports**, and locate **Dashboards**.
4. Configure access state:
* **Disabled**: Users cannot navigate to **Dashboards & Reports** → **Dashboard Manager** or **Dashboards & Reports** → **Widget Library**. Dashboards cannot be shared with this role. If the user previously owned or had access to shared dashboards, they are no longer available.
* **Enabled**: Allows dashboards to be accessed and managed according to defined sub-permissions. Grants access to the Widget Library as explained below in Manage the Widget Library.
5. If **Enabled**, assign specific capabilities to control the UI:
* **Create Dashboards**: Enables the **New Dashboard** button on the **Dashboard Manager** page, allowing the user to create new custom dashboard objects. The user who performs this action becomes the **Owner** of the object and is granted the inherent right to edit, delete, and manage sharing for that specific object..
* **Edit Public Dashboards**: Allows the user to modify custom dashboards set to **Public**, even if they are not the owner.
6. Click **Save**.
**Step 2: Manage the widget library**
The Widget Library is the central repository for predefined and custom widgets and is intended for browsing and selecting widgets to add to a dashboard. Access to and visibility within the Widget Library is determined by role-level permissions and your specific access level to the dashboards where those widgets reside:
* **Access to the Widget Library**: To access the Widget Library, your role must have the **Create Dashboards** or **Edit Public Dashboards** capability. Users who only have "View" permissions for dashboards cannot access the Widget Library.
* **Widget Library visibility**: Visibility within the Widget library depends on ownership and inherited dashboard and widget permissions:
* **Public and personal widgets**: You can always see widgets you created (**Restricted**) and widgets marked as **Public**.
* **Inherited access via dashboards**: If a **Restricted** widget was created by another user but is part of a dashboard shared with you, you won't see it in the Widget Library and it can't be edited (unless you are an administrator).
Note
If you're designated as an Editor, you can always duplicate the widget and make your changes on the copy.
**Step 3: Manage sharing for a custom dashboard**
Once a custom dashboard exists in the Dashboard Manager, the Owner (or an authorized Editor) defines who can see or edit it.
1. Select **Dashboards & Reports** → **Dashboard Manager**.
2. Locate the custom dashboard that you want to share in the table.
3. Right-click the custom dashboard and select the available access option. The menu option you see depends on your tenant-level settings:
* **Share**: Use this if your admin enabled sharing. It allows you to grant access to specific users/groups and change the **General access** (**Public**/**Restricted**).
* **Manage Access**: Use this if sharing is disabled. It is a restricted view that only allows you to toggle the **General access** between **Public** and **Restricted**. You cannot grant access to specific individuals.
4. (If sharing is enabled) Search for the **User** or **User Group**, and assign the access level: **Viewer** (read-only) or **Editor** (can modify and share).
5. Set the **General access** state:
* **Restricted**: Private to the Owner and the others granted access.
* **Public**: Visible to all users with the **Dashboard** component enabled in their role.
6. Click **Save**.
Sharing icons in the Dashboard Manager
The following icons help you identify the security access of your custom dashboards:
* : A **Restricted** custom dashboard you created that is not shared with anyone else.
* : A custom dashboard you created that is currently shared with other users or user groups.
* : A custom dashboard created by another user that has been shared with you.
* : A standard system dashboard provided by Palo Alto Networks. These are always **Public** and cannot be deleted or edited, and their ownership cannot be transferred. Yet, you can **Duplicate** a system dashboard to create a custom version that you can then modify and share.
# Manage access to report templates
Manage Cortex XSIAM report template access with role permissions, ownership, sharing, public visibility, and SBAC data scopes.
Review the following:
* [Manage access to objects](/cortex-xsiam/onboard-cortex-xsiam/post-deployment/manage-user-roles-and-access-management/manage-access-to-objects)
The **Report Templates** page serves as the central repository where you can view, create, and modify report templates for your reports. By using object-level access, you can ensure that custom (user-defined) report templates, such as those used for specialized department metrics or sensitive internal audits, are only accessible to authorized users and user groups. Your access is determined by your role permissions combined with report template ownership; you can only interact with report templates where you are the Owner, report templates explicitly shared with you (or your user group), or report templates marked as **Public**.
{% hint style="warning" %}
### Prerequisite
* **Configure tenant-level settings**: An administrator must first establish the sharing framework under **Settings** → **Configurations** → **Access Management** → **Objects**.
The configuration of these settings defines the authorized sharing workflows for all custom objects, including report templates:
* **Enable "Owners can Share objects they created"**: Grants owners the ability to share report templates with specific users, user groups, and API keys. This enables the **Share** option in the right-click menu for any report template listed on the **Report Templates** page.
* **Disable "Owners can Share objects they created"**: Restricts owners to managing only **General access** (**Public** vs. **Restricted**). In this case, the **Share** option is removed from the report template menu on the **Report Templates** page and is replaced with the **Manage Access** option.
* **Define Scope-Based Access Control (SBAC)**: While per-object access controls the visibility of the report template itself, the underlying data in generated reports remains governed by SBAC. The scope of a generated report is based on the scope of the user who last saved the report template. Ensure the report template creator or last editor has the appropriate data permissions to provide intended results for all report recipients. For more information on defining SBAC, see [Manage user scope](/cortex-xsiam/onboard-cortex-xsiam/post-deployment/manage-user-roles-and-access-management/manage-user-scope).
{% endhint %}
Understanding report behavior
Because report templates are used to generate static report instances, it is important to understand how access is applied:
* **Generated reports is the same as report template access**: A user can access specific report instances generated from a report template to which they have at least **Viewer** access. Access to report instances is the same as the access to the report template used to generate them; if a user is granted access to a report template, they gain access also to all reports previously generated from it. Conversely, if access to the report template is removed, the user immediately loses access to those reports.
* **Data scoping**: Data in reports is generated based on the scope of the user who last saved the template. If an Owner leaves the organization, an Administrator must Change Owner to ensure reports continue to generate data correctly based on an active user's scope.
* **Inherited widget access**: Reports can include both **Public** and **Restricted** widgets. When a widget is added to a report template, the resulting generated report will display the data from that widget to all authorized report recipients, even if they cannot see that specific widget in their own Widget Library.
Change owner of a report template
To ensure continuity when personnel changes occur or to hand off management of a resource, administrators can change the ownership of custom report template objects.
{% hint style="info" %}
### Note
Only Account Admins and Instance Administrators have the authority to change the owner of an object.
{% endhint %}
When changing ownership, keep the following in mind:
* **Principals**: Ownership can only be transferred to an individual **User**. You cannot assign a User Group or an API Key as the Owner of a report template.
* **Schedules**: When ownership is transferred, any existing report schedules associated with the report template are automatically removed. The administrator performing the transfer will see a confirmation message, and the new Owner will receive a notification in the Notification Center. The new Owner must manually redefine the schedule to resume automated report generation.
1. Select **Dashboards & Reports** → **Report Templates**.
2. Right-click the custom report template in the table and select **Change owner**.
3. Select the new owner from the list of users, and click **Change**.
How to configure access to report templates
**Step 1: Set role-level permissions**
Role permissions define the functional capabilities for report templates and determine what actions a user can take.
1. Select **Settings** → **Configurations** → **Access Management** → **Roles**.
2. Right-click the relevant user role, and select **Edit Role**.
3. Under **Components**, expand **Dashboards & Reports**, and locate **Reports**.
4. Configure access state:
* **Disabled**: Users cannot navigate to the **Report Templates** or **Reports** pages. Report templates cannot be shared with this role.
* **Enabled**: Allows report templates to be accessed and managed according to defined sub-permissions.
5. If **Enabled**, assign specific capabilities:
* **Create Reports**: Enables the **New Template** button, allowing the user to create new custom report templates. The user who creates the report template is designated as the **Owner**.
* **Edit Public Reports**: Allows the user to modify custom report templates set to **Public**, even if they are not the **Owner**.
6. Click **Save**.
**Step 2: Manage sharing for a report template**
Once a custom report template exists, the Owner (or an authorized Editor) defines its visibility.
1. Select **Dashboards & Reports** → **Report Templates**.
2. Locate the custom report template you want to share in the table.
3. Right-click the custom report template and select the available access option. The menu option you see depends on your tenant-level settings:
* **Share**: Use this if your admin enabled sharing. It allows you to grant access to specific users/groups and change the **General access** (**Public**/**Restricted**).
* **Manage Access**: Use this if sharing is disabled. It is a restricted view that only allows you to toggle the **General access** between **Public** and **Restricted**. You cannot grant access to specific individuals.
4. (If sharing is enabled) Search for the **User**, **User Group**, or **API Key** and assign the access level: **Viewer** (read-only) or **Editor** (can modify and share).
5. Set the **General access** state:
* **Restricted** (default): Private to the Owner and specifically invited principals.
* **Public**: Visible to all users who have the **Reports** component enabled in their role.
6. Click **Save**.
Sharing icons for report templates
The following icons help you identify the security access of report templates in the table on the **Report Templates** page:
* : A **Restricted** report template you created that is not shared with anyone else.
* : A report template you created that is currently shared with other users, user groups, or API keys.
* : A report template created by another user that has been shared with you.
* : A standard system report template provided by Palo Alto Networks. These are always **Public**, read-only, and cannot be deleted or edited, and their ownership cannot be transferred. Yet, you can **Duplicate** a system report template to create a custom version that you can then modify and share.
Import and export report templates
You can move report templates between different Cortex XSIAM tenants using the import and export functionality. Access and ownership are handled as follows during this process:
* **Export**: To export a report template, you must have at least **Viewer** access to that report template. The exported file contains the configuration of the report template but does not include the original access list or ownership data.
* **Import**: When you import a report template into a tenant:
* **New report template**: If the report template does not already exist in the tenant, you are automatically designated as the **Owner**.
* **Default access**: The report template is created with **Restricted** General access by default, regardless of its setting in the original tenant.
* **Existing report template**: If the report template already exists in the system, the imported template will be updated (overwriting the template definition), but the current **Owner** and access configuration remain unchanged.
# Manage access to playbooks and scripts
Manage Cortex XSIAM playbook and script access with role permissions, ownership, sharing, public visibility, and automation controls.
Review the following:
* [Manage access to objects](/cortex-xsiam/onboard-cortex-xsiam/post-deployment/manage-user-roles-and-access-management/manage-access-to-objects)
The **Playbooks** and **Scripts** pages serve as the central repositories where you can view, create, and modify automation logic for your environment. By using object-level access, you can ensure that custom (user-defined) playbooks and scripts, such as those used for sensitive remediation or specialized third-party integrations, are only accessible to authorized users and user groups. Your access is determined by your role permissions combined with object ownership; you can only interact with playbooks and scripts where you are the Owner, those explicitly shared with you (or your user group), or those marked as **Public**.
{% hint style="warning" %}
### Prerequisite
* **Configure tenant-level settings**: An administrator must first establish the sharing framework under **Settings** → **Configurations** → **Access Management** → **Objects**.
The configuration of these settings defines the authorized sharing workflows for all custom objects, including report templates:
* **Enable "Owners can Share objects they created"**: Grants owners the ability to share playbooks and scripts with specific users, user groups, and API keys. This enables the **Share** option in the right-click menu for any playbook listed on the on the **Playbooks** page or any script listed on the **Scripts** page.
* **Disable "Owners can Share objects they created"**: Restricts owners to managing only **General access** (**Public** vs. **Restricted**). In this case, the **Share** option is removed from the playbook menu on the **Playbooks** page or from the script menu on the **Scripts** page, and replaced with the **Manage Access** option.
For more information on configuring tenant-level settings, see [Manage access to objects](#UUID-ff05f1c8-e516-ea74-9dff-ea8b26692754).
* **Define Scope-Based Access Control (SBAC)**: While per-object access controls the visibility of the playbook or script itself, the actions performed during execution depend on the trigger method:
* **Manual execution**: Actions are governed by the permissions and scope of the user who explicitly runs the playbook or script, as well as the defined scope of the involved integrations.
* **Automated execution**: Actions performed by automation rules or jobs are executed as "system" and are governed by the defined scope and permissions of the involved integrations, regardless of the configured access of the user who created or modified the rule or job. As such, they should be carefully crafted such that they will affect only the intended data.
For more information on defining SBAC, see [Manage user scope](/cortex-xsiam/onboard-cortex-xsiam/post-deployment/manage-user-roles-and-access-management/manage-user-scope).
{% endhint %}
Automation objects
Automation objects in Cortex XSIAM are categorized by their origin, which dictates how access is managed:
* **Custom objects**: Any playbook or script created by a user, whether through a new build, duplicating an existing object, or importing a file, is a custom object. Ownership and granular "access" described in this section apply only to these custom objects.
* **Out-of-the-box (OOTB) objects**: These are playbooks and scripts are either included by default in Cortex XSIAM, installed via Marketplace, or added using the `cortex-sdk`. OOTB playbooks and scripts are **Public** and Read-Only to all users with appropriate role permissions. In the context of the broader object management framework, OOTB objects are referred to as system objects.
Understanding access to playbooks and scripts
As playbooks and scripts are utilized across various platform interfaces, it is important to understand how access permissions are applied:
* **Playbook Editor**: You can only open and modify the logic of playbooks or scripts where you are the **Owner** or have been granted **Editor** access. For all other shared playbooks, you have a read-only view.
* **Task Library visibility**: The Task Library displays tasks that call playbooks or scripts you have access to. If you do not have at least **Viewer** access to a playbook or script, the tasks that reference them will not appear in your library.
* **Access to sub-playbooks**: Sharing a parent playbook does not grant access to the sub-playbooks or scripts used within it. While the automation logic remains intact and will execute successfully regardless of a user's permissions, collaborators must be granted explicit access to the individual sub-playbooks or scripts to view or edit their underlying definitions.
* **Detaching Marketplace content**: When a user detaches a system playbook or script, it becomes a custom object. The user become its **Owner**, and the object is **Restricted**.
* **Selecting and running automations**: Across all the places in Cortex XSIAM where you can select a playbook or script, the list of available automations is filtered. You can only select playbooks or scripts to which you have the required per-object access.
Note
Any playbook can still be triggered and executed via the CLI, even if the user does not have explicit access to it, using the following methods:
Invoking the playbook in the Automation Playground utilizing the ! command.
Utilizing the setPlaybook command within the War Room by manually entering the exact playbook name as a string.
* **Automation rules management**: All automation rules are visible to users with the appropriate role permissions. Yet, managing these rules (creating or editing them) is restricted: you can only select or configure a rule to use a playbook if you have at least **Viewer** access to that specific playbook.
* **Job scheduling**: When a user creates a job, they can select any playbook to which they have at least **Viewer** access. Yet, once a job is executed, the playbook runs as "system" governed by the defined scope and permissions of the involved integrations, regardless of the configured scope or object-level access of the user who created or modified the job.
* **Export bundles (JSON/ZIP)**: To export a custom content bundle, the user role must have **Integrations** (under **Configurations** → **Data Collection**) set to **View**. Additionally, **Scripts** and **Playbooks** (under **Investigation & Response** → **Automations**) set to **Enabled**. A user can only export the playbooks and scripts to which they have access.
* **Import bundles (JSON/ZIP)**: To import a bundle, the user role must have **Integrations** (under **Configurations** → **Data Collection**) set to **View/Edit**. Additionally, **Scripts** and **Playbooks** (under **Investigation & Response** → **Automations**) set to **Enabled** (with the **Edit Public** sub-permission selected for both).
* **Importing new objects**: When a playbook or script is imported that does not already exist in the environment, the user performing the import is designated as the new **Owner**, and the playbook or script state defaults to **Restricted**.
* **Importing existing objects**: If the playbook or script already exists in the environment, only content the user is authorized to access will be updated. The import preserves existing ownership. Only the playbooks and scripts the user has access to are imported.
* **Credential dependencies in Automation**: The ability to execute a playbook or script is independent of the ability to access the secrets it uses. If a playbook or script relies on the user's context to fetch a credential, such as for authenticating against a third-party tool like Jira or Active Directory, the execution will fail if the user's role has the **Credentials** permission set to **None**. In this state, users are prohibited from passing secrets to scripts or external vaults.
Change owner of a playbook or script
To ensure continuity when personnel changes occur, administrators can change the ownership of custom playbooks and scripts, or assign an **Owner** if the playbook or script doesn't have one.
1. Select **Investigation & Response** → **Automation** → **Playbooks** or **Investigation & Response** → **Automation** → **Scripts**.
2. Right-click the custom playbook or script in the table and select **Change owner**.
3. Select the new owner from the list of users, and click **Change**.
Remote Repositories (Push/Pull)
When utilizing remote repositories for content management, access to synchronization actions is governed by a combination of role-level capabilities and object-level visibility:
* **Push**: Initiating a push synchronizes all custom content (user-defined playbooks and scripts) in the tenant to the remote repository, regardless of the object-level access permissions of the user who initiated the action.
* **Pull**: When pulling content from a remote repository, Cortex XSIAM handles ownership differently depending on whether the content is new or already exists in the environment:
* **Existing playbooks and scripts**: If an object already exists in the target environment, the content is updated, but the current ownership and access configuration remain unchanged.
* **New content owner**: For playbooks and scripts that do not yet exist in the environment, the assignment of the **Owner** depends on the settings in the **Remote Repository Settings**.
* **Keep the original owner**: Select this when the user managing access is the same in both tenants. This user is designated as the **Owner** in the production tenant. Recommended option when the same users exist in both the pushing tenant and the pulling one.
* **Owner is the user pulling content into the production tenant (default)**: Select this when users pulling content should also manage their access. The user who manually triggers the pull action is designated as the **Owner**.
* **Assign new content to this user**: Select this when a specific user is responsible for managing access to new content. An administrator specifies a specific user as the **Owner** of all playbooks and scripts included in the pull.
Note
In a production (pull) tenant, be aware of the following:
Users cannot be granted Editor permissions.
Any existing Editor permissions (set before the tenant was configured for remote repository synchronization) are effectively treated as Viewer access.
Automation execution and response
The ability to view the execution of a playbook is independent to the access of playbooks and scripts being called during execution. All playbook tasks, including those of sub-playbooks and scripts to which the user does not have access, will be visible to the user in both the War Room and the Issue Work Plan.
How to configure access to playbooks and scripts
**Task 1. Set role-level permissions**
Role permissions define the functional capabilities for automations and determine what actions a user can take.
1. Select **Settings** → **Configurations** → **Access Management** → **Roles**.
2. Right-click the relevant user role, and select **Edit Role**.
3. Under **Components**, expand **Investigation & Response**, and under **Automations**, locate **Playbooks** or **Scripts**.
4. Configure the access state:
* **Disabled**: Users cannot navigate to the **Playbooks** or **Scripts** pages. Playbooks or scripts cannot be shared with this role.
* **Enabled**: Allows automations to be accessed and managed according to defined sub-permissions.
Note
Playbooks can only be Enabled when Scripts are Enabled first.
5. If **Enabled**, assign specific capabilities:
* For playbooks:
* **Create Playbooks**: Enables all methods for adding playbooks to Cortex XSIAM. This includes the **Build New Playbook** button, as well as the ability to **Duplicate** or **Detach** playbooks. The user who performs these actions is automatically designated as the **Owner**.
* **Edit Public Playbooks**: Allows the user to modify custom playbooks set to **Public**, even if they are not the Owner. Additionally, this permission is required to **Detach** a system playbook and is necessary for users to set or to modify the settings, such as input and output parameters, for tasks that point to system playbooks.
* For scripts:
* **Create Scripts**: Enables all methods for adding scripts to Cortex XSIAM. This includes the **New Script** button, as well as the ability to **Duplicate** or **Detach** scripts. The user who performs these actions is automatically designated as the **Owner**.
* **Edit Public Scripts**: Allows the user to modify custom scripts set to **Public**, even if they are not the Owner.
Note
To detach a playbook or script, a user must have both the Create and the Edit Public sub-permissions assigned to their role.
Reattaching an existing automation to a Marketplace content pack can be performed by the playbook or script Owner or an Administrator.
6. Click **Save**.
**Task 2. Manage sharing for a playbook or script**
Once a custom playbook or script exists, the Owner (or an authorized Editor) defines its visibility.
1. Select **Investigation & Response** → **Automation** → **Playbooks** or **Investigation & Response** → **Automation** → **Scripts**.
2. Locate the custom playbook or script you want to share in the table.
3. Right-click the custom playbook or script and select the available access option. The menu option you see depends on your tenant-level settings:
* **Share**: Use this if your admin enabled sharing. It allows you to grant access to specific users/groups and change the **General access** (**Public**/**Restricted**).
* **Manage Access**: Use this if sharing is disabled. It is a restricted view that only allows you to toggle the **General access** between **Public** and **Restricted**. You cannot grant access to specific individuals.
4. (If sharing is enabled) Search for the **User**, **User Group**, or **API Key** and assign the access level: **Viewer** (read-only) or **Editor** (can modify and share).
5. Set the **General access** state:
* **Restricted** (default): Private to the Owner and specifically invited principals.
* **Public**: Visible to all users who have the **Playbooks** or **Scripts** component enabled in their role.
6. Click **Save**.
# Manage access to saved queries
Manage Cortex XSIAM saved XQL query access with role permissions, ownership, sharing, public visibility, and Query Library controls.
Review the following:
* [Manage access to objects](/cortex-xsiam/onboard-cortex-xsiam/post-deployment/manage-user-roles-and-access-management/manage-access-to-objects)
The Query Library serves as the central repository for your team's investigation logic. By using object-level access, you can ensure that specific Cortex Query Language (XQL) queries, such as those used for sensitive internal investigations or executive reporting, are only accessible to authorized users, user groups, and API keys.
{% hint style="warning" %}
### Prerequisite
**Configure tenant-level settings**: An administrator must first establish the sharing framework under **Settings** → **Configurations** → **Access Management** → **Objects**.
The configuration of these settings defines the authorized sharing workflows for saved queries in the Query Library, including the options that appear to users when clicking the three dot, vertical ellipsis (⋮) for a query in the Query Library:
* **Enable "Owners can Share objects they created"**: Grants owners the ability to share saved queries with specific users, user groups, and API keys to the query's access list. In the Query Library, this enables the **Share** option.
* **Disable "Owners can Share objects they created"**: Restricts owners to managing only **General access** (**Public** vs. **Restricted**). In the Query Library, this replaces the **Share** option with the **Manage Access** option.
For more information on these tenant-level configurations, see [Manage access to objects](#UUID-ff05f1c8-e516-ea74-9dff-ea8b26692754).
{% endhint %}
How access impacts the Query Builder
The permissions assigned to your role, combined with the ownership of specific objects, directly change the tools available to you while working in the Query Builder:
* **Restricted versus Public visibility**: Your Query Library view is personalized. You will only see queries where you are the Owner, queries that have been explicitly shared with you (or your user group or API key), or queries marked as **Public**.
* **Context-sensitive functionality**: The permissions assigned to your role, combined with the ownership of specific objects, directly change the tools available to you while working in the Query Builder and the Query Library. UI elements like the **Save as** menu or the **Share** action only appear if you have the required functional capabilities.
How to configure access to saved queries
Setting up access involves a two-part process: enabling the user interface (UI) elements in the role settings, and then defining the audience for individual saved query objects.
**Step 1: Define role capabilities**
Role-level permissions act as the "master switch" for Query Builder functionality and determine what actions a user can take.
1. Select **Settings** → **Configurations** → **Access Management** → **Roles**.
2. Right-click the relevant user role, and select **Edit Role**.
3. Under **Components**, expand **Investigation & Response**.
4. Ensure **Query Library** is set to **Enabled**.
5. Define functional capabilities to control the UI:
* **Create Queries**: Selecting this enables the **Save as** drop-down menu in the Query Builder. This allows users to select **Save as** → **Query to Library** or **Save as** → **Widget to Library**. The user who performs this action becomes the Owner of the object and is granted the inherent right to edit, delete, and manage sharing for that specific object..
* **Edit Public Queries**: This allows a user to modify queries marked as **Public** by others.
Note
If the role of a user is set to Edit Public Queries but not Create Queries, they can update existing public queries, but the Save as drop-down menu will be hidden, preventing them from creating new Query Library entries.
Keep in mind the following:
* If a custom query does not have an assigned **Owner**, an Administrator can use the **Change Owner** action to assign one.
**Step 2: Manage sharing for a specific query**
Once a query exists in the Query Library, the Owner (or an authorized Editor) can define who has permission to view (and run) or edit it.
1. Select **Investigation & Response** → **Search** → **Query Builder** → **XQL**.
2. Under the **Query Library** tab, locate the query that you want to share in the table.
3. Click the three dot, vertical ellipsis (⋮) and select the available action:
* **Share**: This option appears when **Owners can Share objects they created** is enabled in tenant-level settings. It allows you to manage both **General access** and specific principals (users, user groups, and API keys).
* **Manage Access**: This option appears when **Owners can Share objects they created** is disabled. It only allows you to change the **General access** state.
4. (If sharing is enabled) To share with specific entities (for **Restricted** queries):
* Search for the User, User Group, or API Key.
* Assign the access level: **Viewer** (can run/view) or **Editor** (can modify and, if permitted by tenant-level settings, share).
5. Set the **General access** drop-down menu (if authorized by tenant-level settings):
* **Restricted**: The query is private. It is only visible to the Owner and the specific principals added to the list.
* **Public**: The query is visible to every user who has the Query Library enabled in their role.
Note
When the tenant-level setting Owners and editors can change the general access is unselected, the drop-down is disabled and only an administrator can configure this option.
6. Click **Save**.
Sharing icons in the Query Library
The following icons in the Query Library table help you identify the security access of your queries:
* : A **Restricted** query you created that is not shared with anyone else.
* : A query you created that is currently shared with other users, user groups, or API keys.
* : A query created by another user that has been shared with you.
* : A standard system query provided by Palo Alto Networks. These are always **Public** and can't be deleted, or have their ownership transferred.
# Dashboards and reports
Use Cortex XSIAM dashboards, widgets, reports, and report templates to visualize security data and monitor system activity.
Dashboards consist of visualized data powered by fully customizable widgets, which enable you to analyze data from inside or outside Cortex XSIAM, in different formats such as graphs, pie charts, or text. Cortex XSIAM displays the predefined dashboards when you log in. You can also create custom dashboards that are based on the predefined dashboards, or built to your specifications, and you can save any of your dashboards as reports.
Cortex XSIAM also provides Command Center dashboards that display interactive overviews of your system activity, with drilldowns to additional dashboards and associated pages.
From the **Dashboard & Reports** menu, you can view and manage your dashboards and reports from the dashboard and incidents table, and view alert exclusions.
* **Dashboard:** Provides dashboards that you can use to view high-level statistics about your agents and incidents.
* **Reports:** View all the reports that Cortex XSIAM administrators have run.
* **Customize:** Create and manage a new dashboard and reports.
* **Dashboards Manager:** Add new dashboards with customized widgets to surface the statistics that matter to you most.
* **Reports Templates:** Build reports using pre-defined templates, or customize a report. Reports can be generated on-demand scheduled.
* **Widget Library:** Search, view, edit, and create widgets based on predefined widgets and user-created custom widgets.
# Configure server settings
Configure Cortex XSIAM server settings for localization, branding, AI, access control, data ingestion, security, and support access.
You can configure server settings such as keyboard shortcuts, timezone, timestamp format, and custom logos for communications task emails to create a more personalized user experience in Cortex XSIAM. Go to **Settings** → **Configurations** → **General** → **Server Settings**.
{% hint style="info" %}
### Note
Keyboard shortcuts, timezone, and timestamp format are not set universally and only apply to the user who sets them.
{% endhint %}
| Server Setting | Description |
| ----------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Keyboard Shortcuts | Enables you to change the default shortcut settings. The shortcut value must be a keyboard letter, A through Z, and cannot be the same for both shortcuts. |
| Timezone | Select a specific timezone. The timezone affects the timestamps displayed in Cortex XSIAM, auditing logs and when exporting files. |
| Timestamp Format |
The format in which to display Cortex XSIAM data. The format affects the timestamps displayed in Cortex XSIAM, auditing logs and when exporting files.
This setting is configured per user and not per tenant.
|
| Email Contacts | A list of email addresses Cortex XSIAM can be used as a distribution list. The defined email addresses are used to send product maintenance, updates, and new version notifications. These addresses are in addition to the email addresses registered with your Customer Support Portal account. |
| Custom Logo |
By default, the Cortex XSIAM logo displays on communication task emails. You can replace the default logo with a custom logo to match your organization's branding.
Supported file formats are PNG, JPEG, SVG, and GIF.
The minimum recommended image dimensions are 50px height and 50px width. The recommended maximum file size is 100 KB.
|
| AI Configuration |
Enable or disable the Cortex Agentic Assistant (Agents & LLM Experience).
Enable or disable AI case summarization capabilities.
Note:
The Cortex Agentic Assistant and AI case summarization are currently available for users in limited regions. For more information, see Agentic AI in Cortex XSIAM.
For multi-tenant/MSSP environments, the Cortex Agentic Assistant and AI case summarization are not available in the main tenant.
|
| Password Protection (for downloaded files) |
Enable password protection when downloading retrieved files from an endpoint. This prevents users from opening potentially malicious files.
Administrator permissions required.
Note: If the Password Protection (for downloaded files) setting under Settings → Configuration → General → Server Settings is enabled, enter the password 'suspicious' to download the file.
|
| Google Maps Key | Enter the Google Maps API key to display the physical location of an entity on a Google map. |
| Scope-Based Access Control (SBAC) |
Enforces granular scoping on users with a scoping configuration. A user can inherit scoping configurations from a user group, or have the scoping configuration applied directly on top of the role assigned from either a user group or a generated API Key.
By default, Enable Scope Based Access Control is disabled 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.
(Optional) If enabled, 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.
|
| Ingestion Evaluation Mode | Estimates your data sizing requirements for licensing purposes. When enabled, the system accepts, processes, and parses all your data to calculate ingestion metrics and populate the Ingestion and NGFW Ingestion Dashboards. |
| Data Ingestion Monitoring (Beta) |
Data ingestion health monitors the availability and overall health of data collection. When enabled, Cortex XSIAM creates the following types of alerts:
Ingestion health alerts: Based on the data ingestion metrics and indicate disruptions in data collection
Collection health alerts: Based on error statuses in collection integrations and indicate that a collector is not connected
If you disable data ingestion monitoring, Cortex XSIAM continues to collect metrics, but alerts are not created.
Related information
Use data ingestion health metrics in Cortex Query Language queries and to create correlation rules with your data ingestion logic. For more information, see Monitor data ingestion health.
View all health alerts on the Health Alerts page. For more information, see About health issues.
|
| XQL Configuration |
Enables setting case sensitivity across Cortex XSIAM.
By default, this setting is set to false and field values are evaluated as case insensitive.
This setting overwrites any other default configuration except for BIOCs, which will remain case-insensitive no matter what this configuration is set to.
|
| Define the cases target MTTR per issue severity |
Determines within how many days and hours you want issues resolved according to the issue severity Critical, High, Medium, and Low.
The defined MTTR is used to display the Resolved Issue MTTR dashboard widgets.
|
| Impersonation Role |
The type of role permissions granted to the Palo Alto Networks Support team when opening support tickets. We recommend that role permissions be granted only for a specific time frame, and full administrative permissions be granted only when specifically requested by the Support team.
Role permissions include:
Read-only: Default setting; grants read-only access to your tenant.
Support-related actions: Grants permissions to tech support file collection, dump file collection, investigation query, correlation rule, BIOC and IOC rule editing, alert starring, exclusion, and exception editing
Full role permissions: No limitations are applied; grants full permissions to all actions and content on your tenant
Permission Reset Timeframe: Determines how long role permissions are valid.
|
| Custom Content |
Export all custom content: Exports custom content, such as playbooks and scripts as a content bundle, which you can import to another Cortex XSIAM tenant.
Upload custom content: Imports custom content created from another Cortex XSIAM tenant.
|
| Case display modes | Allow users the access the Cases page in legacy mode. |
| Caching |
Improve performance on the Cases and Issues pages by enabling a temporary data cache.
Note: In MSSP environments, this option is not available on the parent tenant.
|
| Issues | Create timer fields that display in the issues table and issue layouts. For more information, see Configure issue timer fields. |
| Indicators |
Note: Requires the TIM add-on.
By default, system-wide automatic indicator extraction and enrichment is disabled. However, if you migrated from Cortex XSIAM 2.x to Cortex XSIAM 3.x, system-wide automatic indicator extraction and enrichment is enabled.
If you have the TIM add-on, you can enable or disable system-wide automatic indicator extraction and enrichment from issues.
|
| Unified Case View |
Note: Requires an MSSP License and RBAC permissions to Cases & Issues and Investigation & Response → Automation. This setting is available for the parent tenant only.
Enable the Unified Case View to see a consolidated view of all cases across your distributed environment and perform actions on child tenants.
If this setting is disabled, the Cases page displays a single tenant at a time with a drop down list to move between tenants in read-only mode.
For more information, see Unified case view.
|
# Configure security settings
Configure Cortex XSIAM security settings for session expiration, login domains, approved IP ranges, inactive users, cookies, and report emails.
You can configure security settings such as how long users can be logged in Cortex XSIAM, and from which domains and IP ranges users can log in.
Go to **Settings** → **Configurations** → **General** → **Security Settings**.
| Settings | Options | Description |
| ----------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Session Expiration | User Login Expiration | The number of hours (between 1 and 24) after which the user's login session expires. You can also choose to automatically log users out after a specified period of inactivity. |
| Dashboard Expiration |
Whether the Dashboard page expires at the same time as the user login session or after seven days. This is useful when you view a dashboard on a separate screen.
For example, if you select seven days for dashboards and eight hours for login expiration, and you are currently viewing the Dashboard page, the dashboard expiration takes priority (seven days). This ensures that the Dashboard page continues to display the widgets for an extended period.
| |
| Allowed Sessions | Approved Domains | The domains from which you want to allow user access (login) to Cortex XSIAM. You can add or remove domains as necessary. |
| Approved IP Ranges | The IP ranges from which you want to allow user access (login) to Cortex XSIAM. You can also choose to limit API access from specific IP addresses. | |
| User Expiration | Deactivate Inactive User | Deactivate an inactive user, and also set the user deactivation trigger period. By default, user expiration is disabled. When enabled, enter the number of days after which inactive users should be deactivated. |
| Same-Site Cookie Policy |
Strict
Lax
|
Configure your Cortex tenant's SameSite cookie security policy by selecting between two settings to control how users log in from external links:
Strict (Recommended): Requires users to reauthenticate when clicking a link from another site, even if they are already signed in.
Lax: Offers a more seamless experience by allowing users to access the tenant directly from external links without needing to log in again. Yet, we advise against this setting for security reasons.
|
| Allowed Domains | Domain Name | The domain names that can be used in your distribution lists for reports. For example, when generating a report, ensure the reports are not sent to email addresses outside your organization. |
# Data and log forwarding
Configure Cortex XSIAM notifications and forward logs, alerts, cases, and issues to email, Slack, syslog, and third-party services.
To stay informed about important alerts and events, you can configure your notifications and specify the type of data and logs you want to forward. You can forward logs and data to an email account, a Slack channel, or a syslog receiver. In addition, cases and issues can be forwarded to third-party systems including Splunk, Amazon SQS, Amazon S3, and Webhook.
# Forward logs and data from Cortex XSIAM to external services
Forward Cortex XSIAM logs, cases, and issues to email, Slack, syslog, Splunk, Amazon SQS, Amazon S3, or webhooks.
You can forward logs, cases, and issues from Cortex XSIAM to an external service. By forwarding logs and data, you can manage alerts and investigations in external systems and meet data retention requirements. Available services include the following:
* **Slack channel and/or syslog receiver:** Configure the external application with Cortex XSIAM. After the application is configured, configure notification forwarding, specifying the data/log type you want to forward.
* **Email distribution list:** Configure notification forwarding, specifying the data/log type you want to forward.
* **Splunk, Amazon SQS, Amazon S3, and Webhook:** Only cases and issues can be forwarded to these services. The external application must be configured in Cortex XSIAM and egress configured in the Cortex Gateway before forwarding to these services.
The following table shows the log types supported for each notification type:
| Data/log type | Email | Slack | Syslog | Splunk, Amazon SQS, Amazon S3, Webhook |
| ------------------------------------------------------------ | ----- | ----- | ------ | -------------------------------------- |
| Issues | ✓ | ✓ | ✓ | ✓ |
| Cases | ✓ | ✓ | — | ✓ |
|
Agent Audit Logs
Note: Requires an XDR Agent
| ✓ | — | ✓ | — |
| Management Audit Logs | ✓ | — | ✓ | — |
| Health Issues (Deprecated) | ✓ | ✓ | ✓ | — |
# Configure external applications for forwarding
Configure external applications in Cortex XSIAM to forward cases, issues, and logs to email, Slack, syslog, Amazon S3, Amazon SQS, Splunk, and webhooks.
Cases, issues, and logs can be forwarded to third-party external services. The external service must be configured in Cortex XSIAM before you set up notification forwarding.
Only cases and issues can be forwarded to Slack, Amazon S3, Amazon SQS, Splunk, and Webhook. Before forwarding cases or issues to Splunk, Amazon S3, Amazon SQS, or Webhook, you need to configure egress in the Cortex Gateway.
You do not need to configure egress for email, Slack, or syslog forwarding. No prior configuration is required to send data or logs to an email distribution list.
{% hint style="info" %}
### Note
You can configure external applications using either of these methods:
* Pre-configuration: Navigate to **Settings → Configurations → Integrations → External Applications** and follow the setup guide for your specific service:
* [Forward notifications to Amazon SQS](/cortex-xsiam/onboard-cortex-xsiam/post-deployment/data-and-log-forwarding/forward-logs-and-data-from-cortex-xsiam-to-external-services/configure-external-applications-for-forwarding/forward-notifications-to-amazon-sqs)
* [Forward notifications to Amazon S3](/cortex-xsiam/onboard-cortex-xsiam/post-deployment/data-and-log-forwarding/forward-logs-and-data-from-cortex-xsiam-to-external-services/configure-external-applications-for-forwarding/forward-notifications-to-amazon-s3)
* [Forward notifications to Splunk](/cortex-xsiam/onboard-cortex-xsiam/post-deployment/data-and-log-forwarding/forward-logs-and-data-from-cortex-xsiam-to-external-services/configure-external-applications-for-forwarding/forward-notifications-to-splunk)
* [Forward notifications to webhook](/cortex-xsiam/onboard-cortex-xsiam/post-deployment/data-and-log-forwarding/forward-logs-and-data-from-cortex-xsiam-to-external-services/configure-external-applications-for-forwarding/forward-notifications-to-webhook)
* [Integrate a syslog receiver](/cortex-xsiam/onboard-cortex-xsiam/post-deployment/data-and-log-forwarding/forward-logs-and-data-from-cortex-xsiam-to-external-services/configure-external-applications-for-forwarding/integrate-a-syslog-receiver)
* [Integrate Slack for outbound notifications](/cortex-xsiam/onboard-cortex-xsiam/post-deployment/data-and-log-forwarding/forward-logs-and-data-from-cortex-xsiam-to-external-services/configure-external-applications-for-forwarding/integrate-slack-for-outbound-notifications)
* In-workflow configuration: Navigate to **Settings → Configurations → General → Notifications → Add Forwarding Notifications**. Define the configuration and notification scope, then click **Add Application** and complete the setup steps for your chosen service.
{% endhint %}
# Forward notifications to Amazon SQS
Configure Cortex XSIAM notification forwarding to Amazon SQS with Cortex Gateway egress, an AWS SQS queue, IAM role or access keys, and queue permissions.
### Create the SQS queue
Log in to your AWS Management Console and create a new **Standard SQS queue**.
{% hint style="info" %}
NOTE: Use the default AWS SQS message queue depth (256KB) or higher when creating or editing a standard SQS queue.
{% endhint %}
### Configure egress in Cortex Gateway
Before forwarding cases or issues to Amazon SQS, you need to configure egress. Only a user with Account Admin or Instance Admin permissions can configure egress.
To configure egress, to enter the queue name. For example, if the full URL is , enter only `queue-name`.
1. In the Cortex Gateway, go to **Permission Management** → **Egress Configurations** → **Path**.
2. Select the account name and tenant.
3. In the Flow field, select **External storage: AWS SQS**.
4. Enter the exact \. For example, `my-example-queue`. Note that the path does not include HTTP or HTTPS.
5. Add the configuration.
### Generate the authorized party ID
1. In Cortex XSIAM, go to **Settings** → **Configurations** → **Integrations** → **External Applications** → **Add Application** and select **Amazon SQS**.
2. Enter the queue URL from Amazon SQS. Use the URL format rather than the ARN for this specific field.
3. Click **Verify**. If egress has not been configured in the Cortex Gateway, verification will fail and a message will display that the endpoint does not match any approved routes.
4. After verification is successful, an authorized party ID is generated. Copy this ID for your AWS configuration.
5. Leave this page open to complete the application configuration.
### Configure the IAM role and permissions in AWS
Cortex XSIAM needs permission to assume a role in your account.
You can authenticate using either an IAM role or IAM access keys.
* **IAM role**:
* In AWS, go to **IAM** → **Roles** → **Create role**, select Custom trust policy, and enter the Trusted Entity JSON, replacing the sub condition with your Authorized party ID. The following is an example:
```programlisting
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "accounts.google.com"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"accounts.google.com:sub": ""
}
}
}
]
}
```
* Create and attach a policy granting permissions to access your queue ARN. The policy must allow `sqs:ListQueues` and `sqs:SendMessage`. Verify your resource matches your exact queue ARN. For example:
```programlisting
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowLogsToSQS",
"Effect": "Allow",
"Action": [
"sqs:GetQueueAttributes",
"sqs:ListQueues",
"sqs:SendMessage"
],
"Resource": [
"arn:aws:sqs:::"
]
}
]
}
```
* **IAM access keys**: Verify the user associated with the access key and secret key has related permissions to accept the data.
### Complete external application configuration in Cortex XSIAM
1. Go back to Cortex XSIAM and enter the instance name and an optional description.
2. Select either **IAM Role** or **IAM Access Keys**.
* For IAM role, paste the role ARN (Amazon Resource Name) from the role you created.
* For IAM access keys, enter the access key and secret key.
3. Click **Test** to verify Cortex XSIAM can write a test object, then click **Connect**.
### Configure notification forwarding
Follow the instructions for [Configure notification forwarding](/cortex-xsiam/onboard-cortex-xsiam/post-deployment/data-and-log-forwarding/forward-logs-and-data-from-cortex-xsiam-to-external-services/configure-notification-forwarding).
# Forward notifications to Amazon S3
Configure Cortex XSIAM notification forwarding to Amazon S3 with Cortex Gateway egress, AWS IAM roles, bucket permissions, and file rollup.
### Create the S3 Bucket
1. Log in to your AWS Management Console.
2. Navigate to S3 and click **Create bucket**.
3. Enter a unique bucket name and select the AWS Region. Note the region, as you will need it later.
4. Verify **Block all public access** is turned on for security.
### Configure egress in Cortex Gateway
Before forwarding cases or issues to Amazon S3, you need to configure egress. Only a user with Account Admin or Instance Admin permissions can configure egress.
To configure egress, you must enter the bucket name. For example, if the full path is `s3://parent-bucket-name/child-bucket/`, enter `parent-bucket-name`.
1. In the Cortex Gateway, go to **Permission Management** → **Egress Configurations** → **Path**.
2. Select the account name and tenant.
3. In the Flow field, select **External Storage: AWS S3**.
4. Enter the exact ``. For example, `my-example-bucket`. Do not include subfolders.
5. Add the configuration.
### Generate the authorized party ID
1. In Cortex XSIAM, go to **Settings** → **Configurations** → **Integrations** → **External Applications** → **Add Application** and select **Amazon S3**.
2. Enter the S3 URI.
3. Click **Verify**. If egress has not been configured in the Cortex Gateway, verification will fail, and a message will display that the endpoint does not match any approved routes.
4. After verification is successful, an authorized party ID is generated. Copy this ID for your AWS configuration.
5. Leave this page open to complete the application configuration after configuring the IAM role and permissions in AWS.
Configure the IAM Role and permissions in AWS
Cortex XSIAM needs permission to assume a role in your account.
1. In AWS, go to **IAM** → **Roles** → **Create role**, select Custom trust policy, and enter the Trusted Entity JSON, replacing the sub condition with your Authorized party ID. The following is an example:
```programlisting
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "accounts.google.com"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"accounts.google.com:sub": ""
}
}
}
]
}
```
2. Create and attach a policy granting permissions.
The policy must allow s3:PutObject and s3:ListBuckets. Verify the resource matches your exact bucket name, formatted as arn:aws:s3:::your-bucket-name/*. The following is an example:
### Complete external application configuration in Cortex XSIAM
1. Go back to Cortex XSIAM and enter the instance name and an optional description.
2. Select **IAM Role** as the connection method and paste the Role ARN (Amazon Resource Name) from the role you created.
3. Enter the AWS region. The region you select must exactly match the bucket's region in AWS.
4. Select the file rollup time to collect data (cases or issues) before sending. The default is one hour. This is the maximum duration the system collects data before writing to a new file in Amazon S3.
Note
The first message is always sent immediately, and the selected rollup time applies to all subsequent data
5. Click **Test** to verify Cortex XSIAM can write a test object, then click **Connect**.
### Configure notification forwarding
Follow the instructions for [Configure notification forwarding](/cortex-xsiam/onboard-cortex-xsiam/post-deployment/data-and-log-forwarding/forward-logs-and-data-from-cortex-xsiam-to-external-services/configure-notification-forwarding).
# Forward notifications to Splunk
Configure Cortex XSIAM notification forwarding to Splunk with firewall access, Cortex Gateway egress, HTTPS Event Collector, and authentication tokens.
### Configure access in your firewall
Add the IP addresses for your tenant region to your firewall. For more information, refer to the list of ingress IPs in [Enable access to required PANW resources](/cortex-xsiam/onboard-cortex-xsiam/deployment-steps/activate-cortex-xsiam/enable-access-to-required-panw-resources).
### Configure egress in Cortex Gateway
Before forwarding cases or issues to Splunk, you need to configure egress. Only a user with Account Admin or Instance Admin permissions can configure egress.
To configure egress, enter the FQDN (fully qualified domain name), without including the port or the path. For example, if the full URL is `https://splunk..mycompany.com:8088/services/collector`, you would enter `splunk.mycompany.com`.
1. In the Cortex Gateway, go to **Permission Management** → **Egress Configurations** → **Path**.
2. Select the account name and tenant.
3. In the Flow field, select **Splunk**.
4. Enter the FQDN (full qualified domain name) of the Splunk instance. For example, `splunk.mycompany.com`. Note that the path does not include HTTP or HTTPS.
5. Add the configuration.
### Complete external application configuration in Cortex XSIAM
1. Go to **Settings** → **Configurations** → **Integrations** → **External Applications** → **Add Application** and select **Splunk**.
2. Enter the Splunk HTTP event collector URL. The URL can include a port, but the connection must be HTTPS.
3. Click **Verify**. If egress has not been configured in the Cortex Gateway, verification will fail.
4. After verification is successful, enter the instance name and optional description.
5. Enter the authentication token for secure access to your Splunk instance.
6. Click **Test** to verify the connection, then click **Connect**.
### Configure notification forwarding
Follow the instructions for [Configure notification forwarding](/cortex-xsiam/onboard-cortex-xsiam/post-deployment/data-and-log-forwarding/forward-logs-and-data-from-cortex-xsiam-to-external-services/configure-notification-forwarding).
# Forward notifications to webhook
Configure Cortex XSIAM case and issue notifications to HTTPS webhooks with firewall access, Gateway egress, authentication, and JSON payload support.
You can forward issues and cases to a webhook.
{% hint style="info" %}
Cortex sends webhook notifications using its own predefined payload format. If your webhook endpoint requires the payload to be structured in a specific way — for example, the format expected by Google Chat or another third-party service — the notification will not be delivered successfully. Only endpoints that accept arbitrary JSON payloads are supported.
{% endhint %}
### Configure access in your firewall
Add the IP addresses for your tenant region to your firewall. For more information, refer to the list of ingress IPs in [Enable access to required PANW resources](/cortex-xsiam/onboard-cortex-xsiam/deployment-steps/activate-cortex-xsiam/enable-access-to-required-panw-resources).
### Configure egress in Cortex Gateway
Before forwarding cases or issues to Splunk, you need to configure egress. Only a user with Account Admin or Instance Admin permissions can configure egress.
To configure egress, enter the FQDN (fully qualified domain name), without including the port or the path. For example, if the full URL is `https://webhook..mycompany.com/target_resource`, you would enter `webhook.mycompany.com`.
1. In the Cortex Gateway, go to **Permission Management** → **Egress Configurations** → **Path**.
2. Select the account name and tenant.
3. In the Flow field, select **Webhook**.
4. Enter the FQDN (fully qualified domain name) of the webhook endpoint. For example, `webhook.mycompany.com`. Note that the path does not include HTTP or HTTPS.
5. Add the configuration.
### Complete external application configuration in Cortex XSIAM
1. Go to **Settings** → **Configurations** → **Integrations** → **External Applications** → **Add Application** and select **Webhook**.
2. Enter the webhook URL. The URL can include a port, but the connection must be HTTPS.
3. Click **Verify**. If egress has not been configured in the Cortex Gateway, verification will fail.
4. After verification is successful, enter the instance name and optional description.
5. Show advanced settings to add HTTPS headers if required.
6. Enter the authentication token for secure access to your Splunk instance.
7. Click **Test** to verify the connection, then click **Connect**.
### Configure notification forwarding
Follow the instructions for [Configure notification forwarding](/cortex-xsiam/onboard-cortex-xsiam/post-deployment/data-and-log-forwarding/forward-logs-and-data-from-cortex-xsiam-to-external-services/configure-notification-forwarding).
# Integrate a syslog receiver
Integrate a syslog receiver for Cortex XSIAM notifications with regional firewall access, TCP or UDP transport, TLS certificates, and troubleshooting.
A syslog receiver can be a physical or virtual server, a SaaS solution, or any service that accepts syslog messages.
To send Cortex XSIAM notifications to your syslog receiver, you first need to define the settings for the syslog receiver. After this is complete, you can configure notification forwarding.
### Enable access
Before you begin, enable access to the following Cortex XSIAM IP addresses for your region in your firewall.
{% tabs %}
{% tab title="Americas" %}
| Region | Log Forwarding address |
| ----------------------------- | ------------------------------ |
| United States - Americas (US) | 35.232.87.9, 35.224.66.220 |
| United States - Government | 104.198.222.185, 35.239.59.210 |
| Brazil (BR) | 35.247.234.13, 34.39.178.116 |
| Canada (CA) | 35.203.54.204, 35.203.52.255 |
| {% endtab %} | |
{% tab title="EMEA (Europe, Middle East, Africa)" %}
| Region | Log Forwarding IP Addresses |
| ------------------------- | ------------------------------ |
| Finland (FI) | 34.88.235.28, 34.88.248.229 |
| France (FA) | 34.163.100.253, 34.155.72.149 |
| Germany (DE) | 35.234.95.96, 35.246.192.146 |
| Israel (IL) | 34.165.194.4, 34.165.101.105 |
| Italy (IT) | 34.154.0.173, 34.154.71.94 |
| Netherlands - Europe (EU) | 34.90.202.186, 34.90.105.250 |
| Poland (PL) | 34.118.45.145, 34.118.126.170 |
| Qatar (QT) | 34.18.48.182, 34.18.43.40 |
| Saudi Arabia (SA) | 34.166.50.215, 34.166.55.72 |
| South Africa (ZA) | 34.35.70.253, 34.35.10.167 |
| Spain (ES) | 34.175.83.90, 34.175.230.150 |
| Switzerland (CH) | 34.65.228.95, 34.65.74.83 |
| United Kingdom (UK) | 34.105.227.105, 34.105.149.197 |
| {% endtab %} | |
{% tab title="JPAC (Asia-Pacific)" %}
| Region | Log Forwarding IP Addresses |
| ---------------- | ----------------------------- |
| Australia (AU) | 35.189.38.167, 34.87.219.39 |
| Delhi (DL) | 34.126.223.198, 34.131.110.15 |
| India (IN) | 34.93.247.41, 34.93.183.131 |
| Indonesia (ID) | 34.101.248.99, 34.101.176.232 |
| Japan (JP) | 34.84.88.183, 35.243.76.189 |
| Singapore (SG) | 35.240.192.37, 34.87.125.227 |
| South Korea (KR) | 34.64.198.58, 34.47.86.20 |
| Taiwan (TW) | 35.234.2.208, 35.185.171.91 |
| {% endtab %} | |
| {% endtabs %} | |
### **How to send issues or logs to a syslog receiver**
1. Go to **Settings** → **Configurations** → **Integrations** → **External Applications** → **Add Application** and select **Syslog**.
2. Define the following parameters:
| Parameter | Description |
| ----------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Name | Unique name for the server profile. |
| Destination | IP address or fully qualified domain name (FQDN) of the syslog receiver. |
| Port | Port number to send syslog messages. |
| Facility | Select one of the syslog standard values. The value maps to how your syslog server uses the facility field to manage messages. For details on the facility field, see [RFC 5424](https://tools.ietf.org/html/rfc5424). |
| Protocol |
Method of communication with the syslog receiver:
TCP: No validation is made on the connection with the syslog receiver. However, if an error occurred with the domain used to make the connection, the Test connection will fail.
UDP: No error checking, error correction, or acknowledgment. No validation is done for the connection or when sending data.
TCP + SSL: Cortex XSIAM validates the syslog receiver certificate and uses the certificate signature and public key to encrypt the data sent over the connection.
|
| Certificate |
The communication between Cortex XSIAM and the syslog destination can use TLS. In this case, upon connection, Cortex XSIAM validates that the syslog receiver has a certificate signed by either a trusted root CA or a self-signed certificate. You may need to merge the Root and Intermediate certificate if you receive a certificate error when using a public certificate.
If your syslog receiver uses a self-signed CA, upload your self-signed syslog receiver CA. If you only use a trusted root CA leave the certificate field empty.
Up to TLS 1.3 is supported.
Verify the self-signed CA includes your public key.
You can ignore certificate errors. For security reasons, this is not recommended. If you choose this option, data and logs will be forwarded even if the certificate contains errors.
|
3. Test the parameters to ensure a valid connection, and click **Connect** when ready.
You can define up to five syslog receivers. Upon success, the table displays the syslog servers and their status.
After you integrate with your syslog receiver, configure your forwarding settings. For more information, see [Configure notification forwarding](/cortex-xsiam/onboard-cortex-xsiam/post-deployment/data-and-log-forwarding/forward-logs-and-data-from-cortex-xsiam-to-external-services/configure-notification-forwarding).
Syslog receiver test message errors
When configuring a syslog message, Cortex XSIAM sends a test message. If a test message cannot be sent, Cortex XSIAM displays an error message to help you troubleshoot.
The following table includes descriptions and suggested solutions for the error messages:
| Error Message | Description | Suggested Solution |
| ------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Host Resolving Failed | The IP address or hostname you provided doesn't exist, or can't be resolved. | Ensure you have the correct IP address or the hostname. |
| Configured Local Address | The IP address or hostname you provided is internal and can't be used. | Ensure you have the correct IP address or the hostname. |
| Wrong Certificate Format | The certificate you uploaded is in an unexpected format and can't be used. The certificate must be an ASCII string or a bytes-like object. |
Re-create the certificate in the correct format, for example:
|
| Connection Timed Out | Cortex XSIAM didn’t connect to the syslog receiver in the expected time. This could be because your firewall blocked the connection or because the configuration of the syslog server caused it to drop the connection. | Check the firewall logs and the connection using Wireshark. |
| Connection Refused | The syslog receiver refused the connection. This could be because your firewall blocked the connection or because the configuration of the syslog server caused it to drop the connection. | Check the firewall logs and the connection using Wireshark. |
| Connection Reset | The connection was reset by the syslog receiver. This could be because your firewall blocked the connection or because the configuration of the syslog receiver caused it to drop the connection. | Check the firewall logs and the connection using Wireshark. |
| Certificate Verification Failed |
The uploaded certificate couldn’t be verified for one of the following reasons.
The certificate doesn't correspond to the certificate on the syslog receiver and cannot be validated.
The certificate doesn’t have the correct hostname.
You are using a certificate chain and didn’t merge the certificates into one certificate.
|
Incorrect certificate: to check that the certificate you are uploading corresponds to the server syslog certificate, use the following openssl command.
If the certificate is correct, the result is syslog\_certificate: OK.
Incorrect hostname: make sure that the hostname/ip in the certificate matches the syslog server.
Certificate chain: If you are using a list of certificates, merge the chain into one certificate. You can concatenate the certificates using the following cat command in Linux or macOS.
If the certificate is correct, the result is syslog\_certificate: OK.
|
| Connection Terminated Abruptly | The firewall or the syslog receiver dropped the connection unexpectedly. This could be because the firewall on the customer side limits the number of connections, the configuration on the syslog receiver drops the connection, or the network is unstable. | Check the firewall logs and the connection using Wireshark. |
| Host Unreachable | The network configuration is faulty, and the connection can't reach the syslog receiver. | Check the network configuration to make sure everything is configured correctly, like a firewall or a load balancer which may be accidentally directing the connection to a dead server. |
| SSL Error | Unknown SSL error. | To investigate the issue, contact support. |
| Connection Unavailable | General error. | To investigate the issue, contact support. |
# Integrate Slack for outbound notifications
Integrate Cortex XSIAM with Slack to forward issue and report notifications to dedicated workspace channels.
Integrate Cortex XSIAM with your Slack workspace to manage and highlight your issues and reports. Creating a Cortex XSIAM Slack channel ensures that defined issues are exposed on laptop and mobile devices using the Slack interface. Unlike email notifications, Slack channels provide dedicated spaces where you can contact specific members regarding your issues.
How to integrate Slack with Cortex XSIAM
1. Go to **Settings** → **Configurations** → **Integrations** → **External Applications** → **Add Application** and click **Slack**.
2. Click **Ok** to go to an external Slack page to install Cortex XSIAM on your Slack workspace.
Note
You are directed to the Slack browser to install Cortex XSIAM. You can only use this link to install Cortex XSIAM on Slack. Attempting to install from Slack Marketplace will redirect you to Cortex XSIAM documentation.
3. Click **Submit**.
Upon successful installation, Cortex XSIAM displays the workspace to which you connected.
**What to do next**
After you integrate with your Slack workspace, configure your forwarding settings. For more information, see [Configure notification forwarding](/cortex-xsiam/onboard-cortex-xsiam/post-deployment/data-and-log-forwarding/forward-logs-and-data-from-cortex-xsiam-to-external-services/configure-notification-forwarding). To send notifications about failed reports to Slack, see Run or schedule reports.
# Configure notification forwarding
Configure Cortex XSIAM forwarding notifications for issues, cases, and audit logs with scoped filters, formats, grouping, and external destinations.
After you integrate with an external service such as Slack, a syslog server, Amazon S3, Amazon SQS, Webhook, or Splunk, create a forwarding configuration that specifies the data or log type you want to forward. You can configure notifications for issues, cases, and logs. To send reports to email or Slack, see Run or schedule reports.
{% hint style="warning" %}
### Prerequisite
Before you can select an external service for notification forwarding, you must integrate the external service with Cortex XSIAM. For more information, see [Configure external applications for forwarding](/cortex-xsiam/onboard-cortex-xsiam/post-deployment/data-and-log-forwarding/forward-logs-and-data-from-cortex-xsiam-to-external-services/configure-external-applications-for-forwarding). No prior configuration is required to send data to an email distribution list.
{% endhint %}
How to configure notifications
1. Select Settings → **Configurations** → **General** → **Notifications** → **Add Forwarding Configuration**.
2. Enter a name for the configuration.
3. Select the data or log type you want to forward:
* **Issues:** Send notifications for specific issue types.
Note
Forwarding destinations: Only issues and cases can be forwarded to Slack, Splunk, Amazon SQS, Amazon S3, or Webhook.
Notification forwarding by domain: To configure notification forwarding for issues by domain, select Issues and filter the Issues table by Issue Domain.
Alert vs. issue format: By default, new configurations use the issue format, but you can select the alert format if needed when forwarding to email, Slack, or a syslog server. You cannot forward issues in the alert format to Splunk, Amazon SQS, Amazon S3, or Webhook.
Existing legacy configurations are not automatically updated and continue to send notifications in the alert format. To use the issue format, edit the existing configuration.
* **Agent Audit Logs:** Send notifications for audit logs reported by your Cortex XDR agents.
* **Management Audit Logs:** Send notifications for audit logs about events related to your Cortex XSIAM tenant.
* **Cases:** Send notifications for specific cases.
4. (Optional) Enter a description of the forwarding configuration.
5. Click **Next**, and under **Scope**, filter which issues, cases, or logs you want included in a notification.
For example, for a filter set to `Severity = Medium, Category = Configuration`, Cortex XSIAM sends the issues or events matching this filter as a notification.
6. Click **Next**.
7. Select email or the external service you want to forward to.
Email (Issues, cases, logs)
1. Enable the email option and click **Email** to expand the form.
2. Enter the email address for your **Distribution List**.
3. For issue forwarding, you can define the **Grouping Timeframe**, which is the time frame, in minutes, to specify how often Cortex XSIAM sends notifications. Every 20 issues aggregated within this time frame are sent together in one notification, sorted according to severity. To send a notification when one issue is generated, set the time frame to **`0`**. The grouping time frame for case and management audit log is 10 minutes and cannot be modified.
4. (Optional) Define your email configuration:
1. In the **Distribution List**, add the email addresses to which you want to send email notifications.
2. Choose whether you want Cortex XSIAM to provide an auto-generated subject.
3. Choose the format you want to send the email. If you choose **Alert**, you can choose the **Standard** or **Legacy** format. For more information about the legacy format, see [Log format for IOC and BIOC issues](/cortex-xsiam/onboard-cortex-xsiam/post-deployment/data-and-log-forwarding/data-and-log-notification-formats/log-format-for-ioc-and-bioc-issues).
5. Choose whether you want Cortex XSIAM to provide an auto-generated subject or enter your own subject.
6. By default, data is sent in the issue format. You can also choose **Alert** format, **Standard** or **Legacy**. For more information about the legacy format, see [Log format for IOC and BIOC issues](/cortex-xsiam/onboard-cortex-xsiam/post-deployment/data-and-log-forwarding/data-and-log-notification-formats/log-format-for-ioc-and-bioc-issues).
{% hint style="info" %}
The **Grouping Timeframe** defines the time frame, in minutes, of how often Cortex XSIAM sends notifications. Every 20 issues or 20 events aggregated within this time frame are sent together in one notification, sorted according to severity. To send a notification when one issue or event is generated, set the time frame to **`0`**.
{% endhint %}
Syslog server (Issues, logs)
1. Enable the Syslog option and click **Syslog** to expand the form.
2. Select a syslog receiver. Cortex XSIAM displays the list of receivers integrated with your Cortex XSIAM tenant.
3. Choose the format you want to send the syslog. If you choose **Alert**, you can choose the **Standard** or **Legacy** format. For more information about the legacy format, see [Log format for IOC and BIOC issues](/cortex-xsiam/onboard-cortex-xsiam/post-deployment/data-and-log-forwarding/data-and-log-notification-formats/log-format-for-ioc-and-bioc-issues).
Slack (Issues, cases)
1. Enable the Slack option and click **Slack** to expand the form.
2. Enter the Slack channel name and select from the list of available channels. Slack channels are managed independently of Cortex XSIAM in your Slack workspace. After integrating your Slack account with your Cortex XSIAM tenant, Cortex XSIAM displays a list of specific Slack channels associated with the integrated Slack workspace.
3. Choose the format you want to send the syslog. If you choose **Alert**, you can choose the **Standard** or **Legacy** format. For more information about the legacy format, see [Log format for IOC and BIOC issues](/cortex-xsiam/onboard-cortex-xsiam/post-deployment/data-and-log-forwarding/data-and-log-notification-formats/log-format-for-ioc-and-bioc-issues).
Amazon S3, Amazon SQS, Splunk, or Webhook (Issues, cases)
1. Enable the Amazon S3, Amazon SQS, Splunk, or Webhook option and click to expand the form.
2. Select the instance name.
8. Click **Next**.
9. Review the forwarding configuration and click **Create**.
# Set up email notifications for tenant updates
Set up Cortex XSIAM email notifications for tenant upgrades, hotfixes, downtime warnings, and Management Audit Log events.
Your Cortex tenant generates Management Audit Logs throughout the tenant update lifecycle. This includes version upgrades and hotfixes, covering both the pending (before) and completed (after) phases of a scheduled update.
Using log forwarding, you can automatically receive an email whenever one of these events occurs, ensuring your team is notified the moment a change is scheduled or completed on your tenant.
{% hint style="warning" %}
**Prerequisites**
Ensure you have the following:
* Admin privileges on the tenant.
* The email distribution list that will receive the notifications.
* Your tenant name (for example., acme-corp.us) to include in the email subject for easy identification.
{% endhint %}
### How audit events are structured
Every forwarding rule is built by matching key fields from the Management Audit Log:
| Field | What it tells you | Values to filter on |
| ----------- | ------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------- |
| Type | The domain that produced the event. | Tenant Management |
| Subtype | The exact phase of the lifecycle. | Upgrade Pending, Upgrade Completed, Hotfix Pending, Hotfix Completed |
| Description | Human-readable summary of the event. | Contains the word downtime when downtime is involved. This enables you to build targeted rules that run only when downtime is expected. |
### How to set up email notifications for tenant updates
1. Go to **Settings** → **Configurations** → **General** → **Notifications** → **+ Add Forwarding Configuration**.
1. In the **Define** step, set the forwarding configuration details.
2. Enter a name for the configuration.
3. For **Log Type**, select **Management Audit Logs**.
4. (Optional) Enter a description of the forwarding configuration.
5. Click **Next**.
2. In the **Scope** step, filter which issues, cases, or logs you want included in a notification and then click **Next**.\
For example, for a filter set to Severity = Medium, Category = Configuration, Cortex XSIAM sends the issues or events matching this filter as a notification.
3. In the **Forward Destination** step, define the destination details.
1. Select the **Notification Timezone**.
2. Under the **Add Application** dropdown, enable one or more integrations.
3. Enable **Email**.
4. Enter the recipients in the **Email distribution list** field.
5. Set the **Grouping timeframe** to **1 minute**.\
A one minute timeframe ensures pre-upgrade and pre-hotfix warnings arrive in time to be actionable without unnecessary delays.
6. Clear the **Use Auto Generated Subject** checkbox.\
Writing a custom subject that includes your tenant name and the event type (for example, \ tenant - Pre-upgrade warning) enables recipients to instantly identify the affected tenant.
7. Enter your custom subject and add the **Filter / Conditions** for your specific use case from the use case configurations table below.
4. Click **Create**.
### Use case configurations
The following table provides subject lines and filter conditions for your notification needs. For all rules below, the **Entity** condition must be set to **Tenant Management**.
| Use case | When the email is sent | Email recipients | Custom email subject | Additional filter conditions |
| ----------------------------- | ---------------------------------------------------- | ------------------------------------------------------------------------------------ | ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| All upgrade and hotfix events | Any upgrade/hotfix event occurs. | Compliance and audit teams needing a complete record. This is the simplest approach. | \ tenant - Upgrade/Hotfix audit log | (None) |
| Pre-upgrade warning | An upgrade is about to begin (\~10-min warning). | Operations teams needing to prepare. | \ tenant - Pre-upgrade warning | Subtype contains Upgrade Pending |
| Post-upgrade completion | An upgrade has successfully completed. | Anyone tracking version changes. | \ tenant - Upgrade completed | Subtype contains Upgrade Completed |
| Pre-hotfix warning | A hotfix is about to be deployed (\~10-min warning). | Operations teams needing to prepare. | \ tenant - Pre-hotfix warning | Subtype contains Hotfix Pending |
| Post-hotfix completion | A hotfix has been successfully deployed. | Anyone tracking deployments. | \ tenant - Hotfix completed | Subtype contains Hotfix Completed |
| Any event with downtime | An upgrade or hotfix requires downtime. | On-call and SRE teams tracking service interruptions. | \ tenant - Upgrade/Hotfix with downtime |
Description contains downtime
Example configurations:
description contains downtime
type = Tenant Management
subtype contains upgrade
OR
description contains downtime
type = Tenant Manage
|
### Manage and test your rules
* View all rules: Go to **Settings** → **Configurations** → **General** → **Notifications**. Each forwarding configuration is listed with its log type, destination, and status.
* Edit or pause notifications: Open any rule to change recipients, adjust filters, or toggle it on/off.
* Verify the notification is sent: The next time an upgrade or hotfix occurs, confirm the expected email arrives. You can also check the event in **Settings** → **Management Audit Logs**.
* Audit log retention: All audit events are retained for 365 days, enabling you to review historical events in the **Management Audit Logs** table even if you miss an email.
### Frequently asked questions
Should I create one general rule or several specific ones?
If you need a complete record, the use case for all upgrade and hotfix events is the simplest approach. Create individual pre-event and post-event rules only if you need to route specific phases to different teams (for example, warnings to on-call engineers or completions to compliance).
Can I forward these logs to other destinations?
Yes. You can route Management Audit Logs to a Syslog receiver by changing the destination to Syslog during setup. The filter configurations remain exactly the same.
Why does the time in the email differ from the tenant UI?
The tenant UI displays times based on your tenant **timezone** server setting. Forwarded emails use UTC to provide an unambiguous timestamp for all recipients.
---
[Next Page](/llms-full.txt/1)