Documentation — August 19, 2026
15 files changed, 318 insertions, 129 deletions — view the commit on the mirror.
IoT Security collector deprecated for a new Device Security one; authentication mapping rewritten
- The IoT Security data collector is marked deprecated and a new Device Security collector replaces it, keeping both existing datasets.
- Authentication mapping was rewritten around a 15-field mandatory set, and
xdm.auth.servicegained a third value,Universal. - Allow and block lists now accept script and Java file types on Windows, Mac and Linux.
- Quarantine gained per-OS folder paths, a 180-day retention and a configurable pending-action expiry.
- The rest is restructuring — the architecture, XTI and role-scoping pages were reorganized without changing what they say; the XSIAM book is now 2,283 pages.
Highlights
-
Device Security replaces the IoT Security collector
The new collector authenticates with a Strata Cloud Manager service account (TSG ID, client ID and secret) where the legacy one used an IoT portal access key, and the legacy page now warns it will be discontinued.
-
xdm.auth.service gains a third value, Universal
Alongside IDP and SP it now covers sources that are not a known identity provider — local accounts, TACACS+, RADIUS and device SSH — and the page forbids putting a protocol name in the field.
-
An unmapped mandatory authentication field drops the event
The mapping page now states that all 15 mandatory fields must be mapped or the event is dropped from authentication stories and identity analytics, and that identity analytics requires the ITDR licence.
-
Allow and block lists accept more file types
Windows adds VBS, VBE, JSE, Java (JAR/WAR), JS, JSP and JSPX, Mac and Linux add JS, JSP and JSPX, and War, Asp and Aspx are supported when On-write File Examination is enabled.
-
Quarantine retention and expiry are now documented
Records stay in the Quarantine List for 180 days, and a quarantine command sent to an offline endpoint expires after 4 days by default, configurable between 1 and 30.
-
The Broker VM allowlist table was rewritten, but nothing was allowlisted
The tenant placeholder changed from br-__.xdr.<region> to br-<XDR tenant>.xdr.<region>; no FQDN or port was added or removed.
Changes
15 files listed, 13 written up and shaded below.
-
▸ ▾ README modified +1 −1
READMEGenerated by the mirror — not a documentation page, so no diff is kept. The counts above still say how much moved.
-
▸ ▾ Navigation manifest (xsiam) modified +9 −3
.meta/xsiamThe book's page tree and ordering — not a documentation page, so no diff is kept. The counts above still say how much moved.
-
▸ ▾ Deploy the Terraform authentication template in OCI modified +1 −1 Corrects the closing step, which said the template is uploaded to GCP, to OCI.
xsiam/configure-cortex-xsiam/cortex-xsiam-data-sources/cloud-service-provider-csp-onboarding/oracle-cloud-infrastructure-cloud-onboarding/deploy-the-terraform-authentication-template-in-ociRead it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗
Before After@@ -56,9 +56,9 @@ Before you begin, ensure you have:3. Select the name of the Identity Domain created by the Terraform script you downloaded from Cortex XSIAM.3. Select the name of the Identity Domain created by the Terraform script you downloaded from Cortex XSIAM.4. On the domain details page, go to the region section and click the Actions menu (three dots) for the target region you need to collect resources from.4. On the domain details page, go to the region section and click the Actions menu (three dots) for the target region you need to collect resources from.5. Select Enable replication and confirm.5. Select Enable replication and confirm.Replication may take up to 60 minutes depending on the complexity of your identity setup.Replication may take up to 60 minutes depending on the complexity of your identity setup.Once the status changes from Enabling to Enabled, the domain is ready to handle identities in that specific region.Once the status changes from Enabling to Enabled, the domain is ready to handle identities in that specific region.When the template is successfully uploaded to GCP, the initial discovery scan is started. When the scan is complete, you can view your cloud assets in Asset Inventory.When the template is successfully uploaded to OCI, the initial discovery scan is started. When the scan is complete, you can view your cloud assets in Asset Inventory.Show markdown source
@@ -56,9 +56,9 @@ Before you begin, ensure you have: 3. Select the name of the **Identity Domain** created by the Terraform script you downloaded from Cortex XSIAM. 4. On the domain details page, go to the region section and click the **Actions** menu (three dots) for the target region you need to collect resources from. 5. Select **Enable replication** and confirm. Replication may take up to 60 minutes depending on the complexity of your identity setup. Once the status changes from **Enabling** to **Enabled**, the domain is ready to handle identities in that specific region. -When the template is successfully uploaded to GCP, the initial discovery scan is started. When the scan is complete, you can view your cloud assets in **Asset Inventory**. +When the template is successfully uploaded to OCI, the initial discovery scan is started. When the scan is complete, you can view your cloud assets in **Asset Inventory**. -
▸ ▾ IoT Security modified +1 −1 The data source overview now links to both collector pages instead of only the IoT Security one.
xsiam/configure-cortex-xsiam/cortex-xsiam-data-sources/palo-alto-networks-integrations/iot-securityRead it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗
Before After@@ -1,10 +1,10 @@# IoT Security# IoT SecurityYou can configure collecting IoT Security logs and data using an integration configured in Data Sources, content pack integration (onboarded prior to July 26, 2026), or connector (onboarded after July 26, 2026):You can configure collecting IoT Security logs and data using an integration configured in Data Sources, content pack integration (onboarded prior to July 26, 2026), or connector (onboarded after July 26, 2026):Collection Method│DescriptionCollection Method│Description| ---------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ || ---------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |Data Source overview│The Palo Alto Networks IoT Security solution discovers unmanaged devices, detects behavioral anomalies, recommends policy based on risk, and automates enforcement without the need for additional sensors or infrastructure. The Cortex XSIAM IoT Security integration enables you to ingest alerts and device information from your IoT Security instance.Data Source overview│The Palo Alto Networks IoT Security solution discovers unmanaged devices, detects behavioral anomalies, recommends policy based on risk, and automates enforcement without the need for additional sensors or infrastructure. The Cortex XSIAM IoT Security integration enables you to ingest alerts and device information from your IoT Security instance.Link to Data Source instructions│Ingest alerts and assets from IoT SecurityLink to Data Source instructions│Links to content pack/integration details (onboarded prior to July 26, 2026)│The IoT by Palo Alto Networks content pack enables Cortex XSIAM to integrate with the Palo Alto Networks IoT Security Portal for retrieving device details, listing and managing alerts and vulnerabilities, and integrating with ticketing systems like ServiceNow for streamlined incident response. It contains the PANW IoT ServiceNow Tickets Check playbook, the PANW IoT Incident Handling with ServiceNow playbook, the PANW IoT Alert Handling with ServiceNow playbook, the
iot-security-get-raciautomation script, the iot-security-alert-post-processing automation script, theiot-security-check-servicenowautomation script, and the iot-security-vuln-post-processing automation script, along with the IoT Alert and IoT Vulnerability issue types and custom issue fields.- Palo Alto Networks IoT: Use this integration to wrap around the IoT Security Portal APIs for operations such as getting a device detail by ID, listing devices, listing alerts and vulnerabilities, and resolving alerts and vulnerabilities. The integration provides the API wrapper that supports actions for retrieving device information and managing IoT alerts and vulnerabilities.
Links to content pack/integration details (onboarded prior to July 26, 2026)│The IoT by Palo Alto Networks content pack enables Cortex XSIAM to integrate with the Palo Alto Networks IoT Security Portal for retrieving device details, listing and managing alerts and vulnerabilities, and integrating with ticketing systems like ServiceNow for streamlined incident response. It contains the PANW IoT ServiceNow Tickets Check playbook, the PANW IoT Incident Handling with ServiceNow playbook, the PANW IoT Alert Handling with ServiceNow playbook, the
iot-security-get-raciautomation script, the iot-security-alert-post-processing automation script, theiot-security-check-servicenowautomation script, and the iot-security-vuln-post-processing automation script, along with the IoT Alert and IoT Vulnerability issue types and custom issue fields.- Palo Alto Networks IoT: Use this integration to wrap around the IoT Security Portal APIs for operations such as getting a device detail by ID, listing devices, listing alerts and vulnerabilities, and resolving alerts and vulnerabilities. The integration provides the API wrapper that supports actions for retrieving device information and managing IoT alerts and vulnerabilities.
Link to connector (onboarded after July 26, 2026)│IoT SecurityLink to connector (onboarded after July 26, 2026)│IoT SecurityShow markdown source
@@ -1,10 +1,10 @@ # IoT Security You can configure collecting IoT Security logs and data using an integration configured in Data Sources, content pack integration (onboarded prior to July 26, 2026), or connector (onboarded after July 26, 2026): | Collection Method | Description | | ---------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Data Source overview | The Palo Alto Networks IoT Security solution discovers unmanaged devices, detects behavioral anomalies, recommends policy based on risk, and automates enforcement without the need for additional sensors or infrastructure. The Cortex XSIAM IoT Security integration enables you to ingest alerts and device information from your IoT Security instance. | -| Link to Data Source instructions | [Ingest alerts and assets from IoT Security](iot-security/ingest-alerts-and-assets-from-iot-security) | +| Link to Data Source instructions | <ul><li><a href="iot-security/ingest-alerts-and-assets-from-iot-security">Ingest alerts and assets from IoT Security (Deprecated)</a></li><li><a href="iot-security/ingest-alerts-and-assets-from-device-security">Ingest alerts and assets from Device Security</a></li></ul> | | Links to content pack/integration details (onboarded prior to July 26, 2026) | <p>The <a href="https://cortex.marketplace.pan.dev/marketplace/details/PaloAltoNetworks_IoT/">IoT by Palo Alto Networks</a> content pack enables Cortex XSIAM to integrate with the Palo Alto Networks IoT Security Portal for retrieving device details, listing and managing alerts and vulnerabilities, and integrating with ticketing systems like ServiceNow for streamlined incident response. It contains the <strong>PANW IoT ServiceNow Tickets Check</strong> playbook, the <strong>PANW IoT Incident Handling with ServiceNow</strong> playbook, the <strong>PANW IoT Alert Handling with ServiceNow</strong> playbook, the <strong><code>iot-security-get-raci</code></strong> automation script, the <strong>iot-security-alert-post-processing</strong> automation script, the <strong><code>iot-security-check-servicenow</code></strong> automation script, and the <strong>iot-security-vuln-post-processing</strong> automation script, along with the IoT Alert and IoT Vulnerability issue types and custom issue fields.</p><ul><li><a href="https://xsoar.pan.dev/docs/reference/integrations/palo-alto-networks-io-t">Palo Alto Networks IoT</a>: Use this integration to wrap around the IoT Security Portal APIs for operations such as getting a device detail by ID, listing devices, listing alerts and vulnerabilities, and resolving alerts and vulnerabilities. The integration provides the API wrapper that supports actions for retrieving device information and managing IoT alerts and vulnerabilities.</li></ul> | | Link to connector (onboarded after July 26, 2026) | [IoT Security](iot-security/iot-security) |
-
▸ ▾ Ingest alerts and assets from Device Security added +60 −0 New page. Configures the Device Security collector with a Strata Cloud Manager service account, ingesting alerts every 15 minutes and device activity every 30 seconds.
xsiam/configure-cortex-xsiam/cortex-xsiam-data-sources/palo-alto-networks-integrations/iot-security/ingest-alerts-and-assets-from-device-securityRead it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗
Before After@@ -0,0 +1,60 @@# Ingest alerts and assets from Device SecurityThe Palo Alto Networks Device Security solution discovers unmanaged devices, detects behavioral anomalies, recommends policy based on risk, and automates enforcement without the need for additional sensors or infrastructure.The Cortex XSIAM Device Security integration enables you to ingest alerts and device information from your Device Security instance.### Data collection behavior• Issues and alerts: Cortex XSIAM displays Device Security alerts in the Cortex XSIAM Issues table and groups them into cases. These issues are updated every 15 minutes. Device security alerts that were resolved before the integration was established are not added to the table.• Assets and device activities: Device activities detected by Device Security are populated in the Cortex XSIAM Assets table. These activities are updated every 30 seconds.• Datasets: Cortex XSIAM automatically creates two distinct datasets which you can use to initiate XQL Search queries and create Correlation Rules:•panw_iot_security_alerts_raw(for alerts/issues)•panw_iot_security_devices_raw(for assets/device activities)hint infoNoteData mapping and schemas for both datasets remain completely identical to the IoT Security (Deprecated) collector, ensuring your existing XQL queries and Correlation Rules continue to function seamlessly.endhint### PrerequisitesBefore you configure the Device Security data collector, generate a Strata Cloud Manager (SCM) service account Client ID and a Client Secret for the integration.1. Log in to the Strata Cloud Manager instance you use for Device Security using a role that has write access.2. Select Settings > Identity & Access > Access Management.3. Click Add Identity to open the Add New Identity configuration wizard.4. Configure the Identity Information. When finished, click Next.• Identity Type: Service Account• Service Account Name: Name for the service account5. Copy the Client ID and Client Secret from the Client Credentials screen and save them in a secure location. When finished, click Next.6. Assign roles to your service account.• Apps & Services: All Apps & Services• Role: Superuser7. Click Submit to create the new service account, and then verify that your service account appears in the Access Management table.For more information about the PAN IoT Security Public API, see Get Started with the IoT Security Public API.### Configure the Device Security collector1. Select Settings > Data Sources & Integrations.2. On the Data Sources & Integrations page, click + Add New, search for the Device Security data collector, then hover over it and click Add.3. Specify the following parameters.• TSG ID: The unique Tenant Service Group ID for your Strata Cloud Manager instance. You can find this ID at the top of your SCM Identity & Access page next to your tenant name.\<div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><p><strong>Note</strong><br>The <strong>TSG ID</strong> is unique and case-sensitive. You cannot edit it after saving the integration instance.</p></div>• Client Id and Client Secret for the SCM service account previously generated during the prerequisite steps.• Integration Scope: Select at least one of the two values, Alerts and Devices, depending on the information you want to ingest.4. Click Test to validate access, and then click Enable.\When events start to come in, a green checkmark appears underneath the Device Security data collector configuration with the data and time that the data was last synced.### Managing the CollectorYou can continue to manage your existing configuration by selecting the integration in your settings to:• Edit the collector settings.• Disable data collection temporarily.• Delete the collector instance entirely.Show markdown source
@@ -0,0 +1,60 @@ +# Ingest alerts and assets from Device Security + +The Palo Alto Networks Device Security solution discovers unmanaged devices, detects behavioral anomalies, recommends policy based on risk, and automates enforcement without the need for additional sensors or infrastructure. + +The Cortex XSIAM Device Security integration enables you to ingest alerts and device information from your Device Security instance. + +### Data collection behavior + +* **Issues and alerts**: Cortex XSIAM displays Device Security alerts in the Cortex XSIAM Issues table and groups them into cases. These issues are updated every **15 minutes**. Device security alerts that were resolved before the integration was established are not added to the table. +* **Assets and device activities**: Device activities detected by Device Security are populated in the Cortex XSIAM Assets table. These activities are updated every **30 seconds**. +* **Datasets**: Cortex XSIAM automatically creates two distinct datasets which you can use to initiate XQL Search queries and create Correlation Rules: + * `panw_iot_security_alerts_raw` (for alerts/issues) + * `panw_iot_security_devices_raw` (for assets/device activities) + +{% hint style="info" %} +**Note** + +Data mapping and schemas for both datasets remain completely identical to the **IoT Security (Deprecated)** collector, ensuring your existing XQL queries and Correlation Rules continue to function seamlessly. +{% endhint %} + +### Prerequisites + +Before you configure the Device Security data collector, generate a Strata Cloud Manager (SCM) service account Client ID and a Client Secret for the integration. + +1. Log in to the Strata Cloud Manager instance you use for Device Security using a role that has write access. +2. Select **Settings** > **Identity & Access** > **Access Management**. +3. Click **Add Identity** to open the **Add New Identity** configuration wizard. +4. Configure the Identity Information. When finished, click **Next**. + * Identity Type: **Service Account** + * Service Account Name: Name for the service account +5. Copy the **Client ID** and **Client Secret** from the **Client Credentials** screen and save them in a secure location. When finished, click **Next**. +6. Assign roles to your service account. + * Apps & Services: **All Apps & Services** + * Role: **Superuser** +7. Click **Submit** to create the new service account, and then verify that your service account appears in the Access Management table. + +For more information about the PAN IoT Security Public API, see [Get Started with the IoT Security Public API](https://pan.dev/iot/api/iot-public-api-new/). + +### Configure the Device Security collector + +1. Select **Settings** > **Data Sources & Integrations**. +2. On the **Data Sources & Integrations** page, click **+ Add New**, search for the **Device Security** data collector, then hover over it and click **Add**. +3. Specify the following parameters. + + * **TSG ID**: The unique Tenant Service Group ID for your Strata Cloud Manager instance. You can find this ID at the top of your **SCM Identity & Access** page next to your tenant name.\\ + + <div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><p><strong>Note</strong><br>The <strong>TSG ID</strong> is unique and case-sensitive. You cannot edit it after saving the integration instance.</p></div> + + * **Client Id** and **Client Secret** for the SCM service account previously generated during the prerequisite steps. + * **Integration Scope**: Select at least one of the two values, **Alerts** and **Devices**, depending on the information you want to ingest. +4. Click **Test** to validate access, and then click **Enable**.\ + When events start to come in, a green checkmark appears underneath the **Device Security** data collector configuration with the data and time that the data was last synced. + +### Managing the Collector + +You can continue to manage your existing configuration by selecting the integration in your settings to: + +* **Edit** the collector settings. +* **Disable** data collection temporarily. +* **Delete** the collector instance entirely. -
▸ ▾ Ingest alerts and assets from IoT Security (Deprecated) modified +38 −21 Retitled with a Deprecated suffix and warns legacy collectors will be discontinued; asset updates are documented at 5 minutes against the new collector's 30 seconds.
xsiam/configure-cortex-xsiam/cortex-xsiam-data-sources/palo-alto-networks-integrations/iot-security/ingest-alerts-and-assets-from-iot-securityRead it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗
Before After@@ -1,38 +1,55 @@# Ingest alerts and assets from IoT Security# Ingest alerts and assets from IoT Security (Deprecated)The Palo Alto Networks IoT Security solution discovers unmanaged devices, detects behavioral anomalies, recommends policy based on risk, and automates enforcement without the need for additional sensors or infrastructure. The Cortex XSIAM IoT Security integration enables you to ingest alerts and device information from your IoT Security instance.hint warningImportantTo receive data, configure the settings in Cortex XSIAM for the IoT Security data collector in Settings → Data Sources & Integrations.Legacy IoT Security data collectors will be discontinued in the near future. We recommend migrating to the new Device Security data collector to ensure uninterrupted data collection. For more information, see Ingest alerts and assets from Device Security.endhintAs soon as data collection begins, Cortex XSIAM displays the IoT Security alerts in the Cortex XSIAM Issues table and groups them into cases. The IoT Security issues are updated every 15 minutes. IoT security alerts which were resolved before the integration aren’t added to the Cortex XSIAM table. Cortex XSIAM adds device activities detected by IoT Security into the Cortex XSIAM Assets table. Device activities are updated every five minutes.The Palo Alto Networks IoT Security (Deprecated) solution discovers unmanaged devices, detects behavioral anomalies, recommends policy based on risk, and automates enforcement without the need for additional sensors or infrastructure. The Cortex XSIAM IoT Security (Deprecated) integration enables you to ingest alerts and device information from your IoT Security (Deprecated) instance.Cortex XSIAM automatically creates a new dataset for device activities (panw_iot_security_devices_raw) and a new dataset for issues (panw_iot_security_alerts_raw), which you can use to initiate XQL Search queries and create Correlation Rules.### Data Collection BehaviorBefore you configure the IoT Security Collector, generate an access key and a key ID for the integration.• Issues and alerts: Cortex XSIAM displays IoT Security (Deprecated) alerts in the Cortex XSIAM Issues table and groups them into cases. These issues are updated every 15 minutes. IoT security alerts that were resolved before the integration was established are not added to the table.• Assets and device activities: Device activities detected by IoT Security (Deprecated) are populated in the Cortex XSIAM Assets table. These activities are updated every 5 minutes.• Datasets: Cortex XSIAM automatically creates two distinct datasets which you can use to initiate XQL Search queries and create Correlation Rules:•panw_iot_security_alerts_raw(for alerts/issues)•panw_iot_security_devices_raw(for assets/device activities)### PrerequisitesBefore you configure the IoT Security (Deprecated) data collector, generate an access key and a key ID for the integration.1. Log in to the PAN IoT Security portal and click your user name.1. Log in to the PAN IoT Security portal and click your user name.2. Select Preferences.2. Select Preferences.3. In the User Role & Access section, Create an API Access Key.3. In the User Role & Access section, Create an API Access Key.4. Download and save the access key and key ID in a secure location.4. Download and save the access key and key ID in a secure location.For more information about the PAN IoT Secuity API, see Get Started with the IoT Security API.For more information about the PAN IoT Security API, see Get Started with the IoT Security API (Deprecated).Configure the IoT Security alerts and assets collection in Cortex XSIAM.### Configure the IoT Security Collector (Deprecated)1. Navigate to Settings → Data Sources & Integrations.1. Navigate to Settings > Data Sources & Integrations.2. On the Data Sources & Integrations page, click + Add New, search for IoT Security Collector, then hover over it and click Add.2. On the Data Sources & Integrations page, click + Add New, search for IoT Security (Deprecated), then hover over it and click Add.3. Specify the following parameters.3. Specify the following parameters.• Customer ID: Tenant domain part of the FQDN used for your IoT Security account. For example, inyourcorp.iot.paloaltonetworks.com, the customer ID isyourcorp. The customer ID is unique and case sensitive. After you save the integration instance, you can't edit the Customer ID.• Access Key and Key ID previously generated for the integration.• Integration Scope: Select at least one of the two values, Alerts and Devices depending on which information you want to ingest.4. Click Test to validate access, and then click Enable.When events start to come in, a green check mark appears underneath the **IoT Security Collector** configuration with the data and time that the data was last synced.• Customer ID: Tenant domain part of the FQDN used for your IoT Security account. For example, inyourcorp.iot.paloaltonetworks.com, the customer ID isyourcorp. The customer ID is unique and case sensitive. After you save the integration instance, you can't edit the Customer ID.5. (Optional) Manage your IOT Security Collector.• Access Key and Key ID previously generated for the integration.• Integration Scope: Select at least one of the two values, Alerts and Devices depending on which information you want to ingest.4. Click Test to validate access, and then click Enable.\When events start to come in, a green checkmark appears underneath the IoT Security (Deprecated) data collector configuration with the data and time that the data was last synced.### Managing the CollectorYou can continue to manage your existing configuration by selecting the integration in your settings to:• Edit the collector settings.• Disable data collection temporarily.• Delete the collector instance entirely.After you enable the IOT Security Collector, you can make additional changes as needed. To modify a configuration, select any of the following options.hint infoNote• Edit the IOT Security Collector settings.If you disable or delete this legacy collector, you will need to follow the migration path to deploy the Device Security data collector to maintain continuous asset and alert monitoring.• Disable the IOT Security Collector.endhint• Delete the IOT Security Collector.6. After Cortex XSIAM begins receiving data from IOT Security, you can use the XQL Search to search for logs in the new datasets,panw_iot_security_devices_rawfor device activities, andpanw_iot_security_alerts_rawfor issues.Show markdown source
@@ -1,38 +1,55 @@ -# Ingest alerts and assets from IoT Security +# Ingest alerts and assets from IoT Security (Deprecated) -The Palo Alto Networks IoT Security solution discovers unmanaged devices, detects behavioral anomalies, recommends policy based on risk, and automates enforcement without the need for additional sensors or infrastructure. The Cortex XSIAM IoT Security integration enables you to ingest alerts and device information from your IoT Security instance. +{% hint style="warning" %} +**Important** -To receive data, configure the settings in Cortex XSIAM for the IoT Security data collector in **Settings** → **Data Sources & Integrations**. +Legacy IoT Security data collectors will be discontinued in the near future. We recommend migrating to the new Device Security data collector to ensure uninterrupted data collection. For more information, see [Ingest alerts and assets from Device Security](ingest-alerts-and-assets-from-device-security). +{% endhint %} -As soon as data collection begins, Cortex XSIAM displays the IoT Security alerts in the Cortex XSIAM Issues table and groups them into cases. The IoT Security issues are updated every 15 minutes. IoT security alerts which were resolved before the integration aren’t added to the Cortex XSIAM table. Cortex XSIAM adds device activities detected by IoT Security into the Cortex XSIAM Assets table. Device activities are updated every five minutes. +The Palo Alto Networks IoT Security (Deprecated) solution discovers unmanaged devices, detects behavioral anomalies, recommends policy based on risk, and automates enforcement without the need for additional sensors or infrastructure. The Cortex XSIAM IoT Security (Deprecated) integration enables you to ingest alerts and device information from your IoT Security (Deprecated) instance. -Cortex XSIAM automatically creates a new dataset for device activities (`panw_iot_security_devices_raw`) and a new dataset for issues (`panw_iot_security_alerts_raw`), which you can use to initiate XQL Search queries and create Correlation Rules. +### Data Collection Behavior  -Before you configure the **IoT Security Collector**, generate an access key and a key ID for the integration. +* **Issues and alerts**: Cortex XSIAM displays IoT Security (Deprecated) alerts in the Cortex XSIAM Issues table and groups them into cases. These issues are updated every **15 minutes**. IoT security alerts that were resolved before the integration was established are not added to the table. +* **Assets and device activities**: Device activities detected by IoT Security (Deprecated) are populated in the Cortex XSIAM Assets table. These activities are updated every **5 minutes**. +* **Datasets**: Cortex XSIAM automatically creates two distinct datasets which you can use to initiate XQL Search queries and create Correlation Rules: + * `panw_iot_security_alerts_raw` (for alerts/issues) + * `panw_iot_security_devices_raw` (for assets/device activities) + +### Prerequisites  + +Before you configure the IoT Security (Deprecated) data collector, generate an access key and a key ID for the integration. 1. Log in to the **PAN IoT Security** portal and click your user name. 2. Select **Preferences**. 3. In the **User Role & Access** section, **Create** an API Access Key. 4. Download and save the access key and key ID in a secure location. -For more information about the PAN IoT Secuity API, see [Get Started with the IoT Security API](https://docs.paloaltonetworks.com/iot/iot-security-api-reference/iot-security-api-overview/get-started-with-the-iot-security-api). +For more information about the PAN IoT Security API, see [Get Started with the IoT Security API](https://docs.paloaltonetworks.com/iot/iot-security-api-reference/iot-security-api-overview/get-started-with-the-iot-security-api) (Deprecated). -Configure the IoT Security alerts and assets collection in Cortex XSIAM. +### Configure the IoT Security Collector (Deprecated)  -1. Navigate to **Settings** → **Data Sources & Integrations**. -2. On the **Data Sources & Integrations** page, click **+ Add New**, search for **IoT Security Collector**, then hover over it and click **Add**. +1. Navigate to **Settings** > **Data Sources & Integrations**. +2. On the **Data Sources & Integrations** page, click **+ Add New**, search for **IoT Security** **(Deprecated)**, then hover over it and click **Add**. 3. Specify the following parameters. - * **Customer ID**: Tenant domain part of the FQDN used for your **IoT Security** account. For example, in `yourcorp.iot.paloaltonetworks.com`, the customer ID is `yourcorp`. The customer ID is unique and case sensitive. After you save the integration instance, you can't edit the Customer ID. - * **Access Key** and **Key ID** previously generated for the integration. - * **Integration Scope**: Select at least one of the two values, **Alerts** and **Devices** depending on which information you want to ingest. -4. Click **Test** to validate access, and then click **Enable**. - When events start to come in, a green check mark appears underneath the **IoT Security Collector** configuration with the data and time that the data was last synced. -5. (Optional) Manage your IOT Security Collector. +* **Customer ID**: Tenant domain part of the FQDN used for your **IoT Security** account. For example, in `yourcorp.iot.paloaltonetworks.com`, the customer ID is `yourcorp`. The customer ID is unique and case sensitive. After you save the integration instance, you can't edit the Customer ID. +* **Access Key** and **Key ID** previously generated for the integration. +* **Integration Scope**: Select at least one of the two values, **Alerts** and **Devices** depending on which information you want to ingest. + +4. Click **Test** to validate access, and then click **Enable**.\ + When events start to come in, a green checkmark appears underneath the **IoT Security (Deprecated)** data collector configuration with the data and time that the data was last synced. + +### Managing the Collector  + +You can continue to manage your existing configuration by selecting the integration in your settings to:  + +* **Edit** the collector settings. +* **Disable** data collection temporarily. +* **Delete** the collector instance entirely. - After you enable the IOT Security Collector, you can make additional changes as needed. To modify a configuration, select any of the following options. +{% hint style="info" %} +**Note** - * **Edit** the IOT Security Collector settings. - * **Disable** the IOT Security Collector. - * **Delete** the IOT Security Collector. -6. After Cortex XSIAM begins receiving data from IOT Security, you can use the XQL Search to search for logs in the new datasets, `panw_iot_security_devices_raw` for device activities, and `panw_iot_security_alerts_raw` for issues. +If you disable or delete this legacy collector, you will need to follow the migration path to deploy the **Device Security** data collector to maintain continuous asset and alert monitoring.  +{% endhint %} -
▸ ▾ Set up and configure Broker VM modified +8 −8 The allowlist table rewrites the tenant placeholder in the Broker Service FQDNs; no FQDN or port was added or removed.
xsiam/configure-cortex-xsiam/data-management/broker-vm/set-up-and-configure-broker-vmRead it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗
Before After@@ -55,24 +55,24 @@ Before downloading, ensure that your virtual machine (VM) is compatible with oneEnable communication between the Broker Service, and other Palo Alto Networks services and applications.Enable communication between the Broker Service, and other Palo Alto Networks services and applications.hint warninghint warning#### Important#### ImportantThe internal network for the Broker VM must be unique and reserved. Other devices should not use the same IP as the Broker VM internal network as it can lead to communication issues with the Broker VM.The internal network for the Broker VM must be unique and reserved. Other devices should not use the same IP as the Broker VM internal network as it can lead to communication issues with the Broker VM.endhintendhintFQDN, Protocol, and Port│DescriptionFQDN, Protocol, and Port│Description| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- || ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |(Default)time.google.compool.ntp.org
UDP port 123
│Broker's NTP server used for broker registration and communication encryption. The Broker VM provides default servers you can use, or you can define an NTP server of your choice.(Default)time.google.compool.ntp.org
UDP port 123
│Broker's NTP server used for broker registration and communication encryption. The Broker VM provides default servers you can use, or you can define an NTP server of your choice.br-__.xdr.<region>.paloaltonetworks.comHTTPS over TCP port 443│Broker Service server depending on the region of your deployment, such asusoreu.br-<XDR tenant>.xdr.<region>.paloaltonetworks.comHTTPS over TCP port 443
│Broker Service server depending on the region of your deployment, such asusoreu.distributions.traps.paloaltonetworks.comHTTPS over TCP port 443│Information needed to communicate with your Cortex XSIAM tenant. Used by tenants deployed in all regions.distributions.traps.paloaltonetworks.comHTTPS over TCP port 443│Information needed to communicate with your Cortex XSIAM tenant. Used by tenants deployed in all regions.br-__.xdr.federal.paloaltonetworks.comHTTPS over TCP port 443│Broker Service server for Federal (US Government) deployment.br-<xdr-tenant>.xdr.federal.paloaltonetworks.comHTTPS over TCP port 443│Broker Service server for Federal (US Government) deployment.distributions-prod-fed.traps.paloaltonetworks.comHTTPS over TCP port 443│Used by tenants with Federal (US Government) deploymentdistributions-prod-fed.traps.paloaltonetworks.comHTTPS over TCP port 443
│Used by tenants with Federal (US Government) deploymentFrom Broker VM version 19.x.x and later, you can navigate to the following URL to open the Broker VM web console:https://<broker_vm_ip_address>.:4443HTTPS over TCP port 4443│Broker VM web consoleFrom Broker VM version 19.x.x and later, you can navigate to the following URL to open the Broker VM web console:https://<broker_vm_ip_address>.:4443HTTPS over TCP port 4443│Broker VM web consolehint infohint info#### Note#### NoteWhen DHCP is not enabled in your network and there isn't an IP address for your Broker VM, configure the Broker VM with a static IP using the serial console menu.When DHCP is not enabled in your network and there isn't an IP address for your Broker VM, configure the Broker VM with a static IP using the serial console menu.endhintendhint#### Enable access to Cortex XSIAM#### Enable access to Cortex XSIAMShow markdown source
@@ -55,24 +55,24 @@ Before downloading, ensure that your virtual machine (VM) is compatible with one Enable communication between the Broker Service, and other Palo Alto Networks services and applications. {% hint style="warning" %} #### Important The internal network for the Broker VM must be unique and reserved. Other devices should not use the same IP as the Broker VM internal network as it can lead to communication issues with the Broker VM. {% endhint %} -| FQDN, Protocol, and Port | Description | -| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| <p>(Default)</p><ul><li><strong><code>time.google.com</code></strong></li><li><strong><code>pool.ntp.org</code></strong></li></ul><p>UDP port 123</p> | Broker's NTP server used for broker registration and communication encryption. The Broker VM provides default servers you can use, or you can define an NTP server of your choice. | -| **`br-__.xdr.<region>.paloaltonetworks.com`** HTTPS over TCP port 443 | Broker Service server depending on the region of your deployment, such as **`us`** or **`eu`**. | -| **`distributions.traps.paloaltonetworks.com`** HTTPS over TCP port 443 | Information needed to communicate with your Cortex XSIAM tenant. Used by tenants deployed in all regions. | -| **`br-__.xdr.federal.paloaltonetworks.com`** HTTPS over TCP port 443 | Broker Service server for Federal (US Government) deployment. | -| **`distributions-prod-fed.traps.paloaltonetworks.com`** HTTPS over TCP port 443 | Used by tenants with Federal (US Government) deployment | -| From Broker VM version 19.x.x and later, you can navigate to the following URL to open the Broker VM web console: **`https://<broker_vm_ip_address>.:4443`** HTTPS over TCP port 4443 | Broker VM web console | +| FQDN, Protocol, and Port | Description | +| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| <p>(Default)</p><ul><li><strong><code>time.google.com</code></strong></li><li><strong><code>pool.ntp.org</code></strong></li></ul><p>UDP port 123</p> | Broker's NTP server used for broker registration and communication encryption. The Broker VM provides default servers you can use, or you can define an NTP server of your choice. | +| <p><strong><code>br-</code></strong><em><strong><code><XDR tenant></code></strong></em><strong><code>.xdr.<region>.paloaltonetworks.com</code></strong> </p><p>HTTPS over TCP port 443</p> | Broker Service server depending on the region of your deployment, such as **`us`** or **`eu`**. | +| **`distributions.traps.paloaltonetworks.com`** HTTPS over TCP port 443 | Information needed to communicate with your Cortex XSIAM tenant. Used by tenants deployed in all regions. | +| **`br-`**_**`<xdr-tenant>`**_**`.xdr.federal.paloaltonetworks.com`**HTTPS over TCP port 443 | Broker Service server for Federal (US Government) deployment. | +| <p><strong><code>distributions-prod-fed.traps.paloaltonetworks.com</code></strong> </p><p>HTTPS over TCP port 443</p> | Used by tenants with Federal (US Government) deployment | +| From Broker VM version 19.x.x and later, you can navigate to the following URL to open the Broker VM web console: **`https://<broker_vm_ip_address>.:4443`** HTTPS over TCP port 4443 | Broker VM web console | {% hint style="info" %} #### Note When DHCP is not enabled in your network and there isn't an IP address for your Broker VM, configure the Broker VM with a static IP using the serial console menu. {% endhint %} #### Enable access to Cortex XSIAM -
▸ ▾ How to map authentication events for analytics modified +85 −35 Retitled How to map authentication events for analytics and expanded with MAP/DERIVE/PAD field treatment, principal classification, AAA topologies and a logout convention.
xsiam/configure-cortex-xsiam/data-management/data-model-rules/how-to-map-authentication-story-eventsRead it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗
Before After@@ -1,82 +1,132 @@# How to map authentication story events?# How to map authentication events for analyticshint infoLicenseTo enable Identity Threat Detection and Response (ITDR) analytics, you must have the ITDR license and ingest identity logs. Full identity analytics capabilities are optimized for data collected via Cortex XDR agents and specific cloud/SaaS integrations.endhintCortex XSIAM enables analytics to run on all mapped authentication data, which automatically creates authentication stories for Cortex Data Model (XDM) identity data. To build these stories, you must map authentication events to the XDM schema using specific mandatory fields and principles. For a complete list of these fields, see XDM fields for mapping authentication events.hint warninghint warning### Prerequisite### PrerequisiteData Model Rules requires View/Edit RBAC permissions for Data Management (under Configurations → Data Management), which are the same permissions required for Dataset Management, Parsing Rules, and Event Forwarding.• You must have View/Edit RBAC permissions for Data Management (under Configurations > Data Management).• Familiarize yourself with the Cortex Data model (XDM) schema for field definitions and naming conventions, see XSIAM Data Model Schema.endhintendhintCortex XSIAM enables analytics to run on all mapped authentication data, which automatically creates authentication stories for Cortex Data Model (XDM) identity data. As a result, you need to map authentication events to the Cortex XSIAM XDM schema to build the authentication story. For a complete list of these fields, see XDM fields for mapping authentication events.hint infohint info### Scope Clarification### Scope ClarificationThis Feature focuses on authentication events related to SSO (Single Sign-On) and SaaS (Software-as-a-Service) application authentications. It does not cover internal authentication mechanisms such as Kerberos, NTLM, or traditional domain logon events generated by on-premise infrastructure.This Feature focuses on authentication events related to SSO (Single Sign-On) and SaaS (Software-as-a-Service) application authentications. It does not cover internal authentication mechanisms such as Kerberos, NTLM, or traditional domain logon events generated by on-premise infrastructure.endhintendhinthint warning### PrerequisiteFamiliarize yourself with the Cortex Data model (XDM) schema for field definitions and naming conventions, see XSIAM Data Model Schema.endhintMapping principlesMapping principlesWhen mapping your authentication data, follow these guidelines:When mapping your authentication data, follow these guidelines:• Prioritize conclusive events: Focus on mapping events that clearly represent the final stage or result of an authentication process.• Prioritize conclusive events: Focus on mapping events that represent the final result of an authentication process.• Exclude ambiguous or non-final steps from outcome decisions: Intermediate or informational events should not be treated as indicators of success or failure.• Exclude ambiguous steps: Intermediate or informational events should not be treated as indicators of success or failure.• Preserve context across the full authentication flow: Include intermediate events to provide visibility into the process, while making it clear they are not final outcomes.• Preserve context across the full authentication flow: Include intermediate events to provide visibility into the process, while making it clear they are not final outcomes.• Normalize raw error and outcome data: You must define explicit mapping logic between the raw event fields that contain outcome or error messages, such asget_reasonanddebugdata_errorcode, and the target XDM fields. This logic should normalize provider-specific strings or codes into a canonical format to support reliable detection and analytics across diverse sources.• Normalize raw error and outcome data: Define explicit mapping logic between the raw event fields that contain outcome or error messages, such asget_reasonanddebugdata_errorcode, and the target XDM fields. This logic should normalize provider-specific strings or codes into a canonical format to support reliable detection and analytics across diverse sources.• Preserve attack evidence: Do not sanitize identity fields at model time. Hostile values, such as template-injection probes, must be preserved verbatim as they are critical evidence for detection.</details></details>Why follow the mapping principles?Why follow the mapping principles?• Prevents misclassification of failed sessions as successful.• Prevents misclassification of failed sessions as successful.• Avoids distorted behavioral baselines that can mask real attacks.• Avoids distorted behavioral baselines that can mask real attacks.• Preserves full visibility of authentication flows without misleading analytics.• Preserves full visibility of authentication flows without misleading analytics.</details></details>Third-party mapping examplesThird-party mapping examples</details></details>Mandatory XDM fields to map for authentication eventsMandatory XDM fields to map for authentication eventsThere are mandatory fields that you need map to the Cortex Data Model (XDM) schema to build authentication stories based on the mapped authentication data. For more detailed information on these fields, see XDM fields for mapping authentication events.You must map all 15 of the following fields. If a mandatory field is unmapped or incorrect, the event will be dropped from authentication stories and identity analytics. For more detailed information on these fields, see XDM fields for mapping authentication events.The following fields are mandatory to map:hint warningImportant•xdm.source.portTo maximize the variety of issues that are retrieved based on the XDM authentication stories, we recommend that the following additional fields are populated:xdm.logon.type,xdm.source.user_agent, andxdm.source.host.device_category. Should you decide to change the default XDM mappings, ensure that both the mandatory and recommended fields are populated and do not contain any empty values.•xdm.target.ipv4endhint•xdm.target.port•xdm.network.ip_protocol•xdm.source.ipv4•xdm.event.type•xdm.event.tags•xdm.event.operation•xdm.event.original_event_type•xdm.auth.service•xdm.event.outcome•xdm.source.user.upnhint infoXDM Target Field Data Type Purpose and Guidance xdm.auth.serviceString System Role. Decided PER EVENT TYPE: IDP(validates),SP(initiates), orUniversal(local/AAA). Do not use protocol names here.xdm.event.operationString Describes the action (such as AUTH_LOGIN,AUTH_MFA). Never blind-default if unclear.xdm.event.original_event_typeString The raw vendor event name exactly as logged. xdm.event.outcomeEnum Set only to SUCCESSorFAILED. Do not set on intermediate steps.xdm.event.tagsArray Must include XDM_CONST.EVENT_TAG_AUTHENTICATIONxdm.event.typeString Must contain authentication.xdm.network.ip_protocolEnum The transport protocol (e.g., TCP). Fallback toIP_PROTOCOL_IPif unknown.xdm.source.ipv4String The client IP observed by the authenticator. Never static or empty. xdm.source.portInteger Map real value; otherwise 0.xdm.source.user.upnString Identity Key. Must be UPN-shaped ( user@domain). Use a shape-guard to append@localhostif the source provides only a bare username.xdm.source.user.identity_typeEnum The nature of the principal (such as USER,MACHINE,BUILTIN).xdm.source.user.user_typeEnum The account class (such as REGULAR,SERVICE_ACCOUNT).xdm.target.ipv4String The IP of the device being accessed. If absent, use "".xdm.target.portInteger Map real value; otherwise 0.xdm.target.resource.nameString The name or address of the service being accessed. Set this in addition to specific host/app fields. Never pad this; if absent, resolve to null. ### ImportantTo maximize the variety of issues that are retrieved based on the XDM authentication stories, we recommend that the following additional fields are populated:xdm.target.resource.name,xdm.logon.type,xdm.source.user_agent, andxdm.source.host.device_category. Should you decide to change the default XDM mappings, ensure that both the mandatory and recommended fields are populated and do not contain any empty values.</details>endhintDetailed implementation guidance### The three branches logicWhen an authentication field is missing from your source log, apply these treatments in order:1. MAP: If the source carries the value directly.2. DERIVE: If the value can be constructed from another field (e.g., synthesizing a UPN).3. PAD: Use semantically empty placeholders only if derivation is impossible.• Valid Pads:to_integer(0)for ports,""for target IP,IP_PROTOCOL_IPfor protocol.• Invalid Pads: Never padxdm.target.resource.nameorxdm.source.ipv4.### Principal Classification (Identity vs. User Type)To support identity analytics, you must map both fields using specific constants:•identity_type: Classifies the nature of the principal (such asIDENTITY_TYPE_MACHINEfor names ending in$,IDENTITY_TYPE_BUILTINforSYSTEM).•user_type: Defines the operational class (such asUSER_TYPE_REGULARfor human logins,USER_TYPE_SERVICE_ACCOUNTforsvc_prefixes).### Mandatory Field Crosswalk for Network/AAA DevicesVendor Field Hint│XDM Target Field│Implementation Note| ----------------------- | -------------------------- | ----------------------------------------------------------------- |user,username│xdm.source.user.upn│Synthesize UPN:concat(tmp_user, "@localhost")priv_lvl,privilege│xdm.auth.privilege_level│Band 15+ toADMIN, 1+ toUSER, 0 toGUEST.dvc_ip,nas-ip│xdm.target.ipv4│The IP of the accessed device.src_ip,rem_addr│xdm.source.ipv4│The IP of the authenticating client workstation.service│xdm.auth.auth_method│Protocol. (e.g.,RADIUS). Do not map toxdm.auth.service.task_id,session-id│xdm.network.session_id│Crucial for correlating session lifecycle events.</details>Important topologies### Device-local authenticationWhen a device logs a login to itself (such as SSH into a router):• Observer: The device that wrote the log is thexdm.observer.*.• Target: If the login was into that device, the device is ALSO the target:xdm.target.host.hostnameandxdm.target.ipv4.• Source: The remote workstation initiating the connection is the source:xdm.source.ipv4,xdm.source.port, andxdm.source.user.*.### AAA Gateway topologyNetwork-device AAA logs (TACACS+, RADIUS) involve three parties:• Principal: The human or service account (xdm.source.user.upn).• Source: The user's workstation (xdm.source.ipv4).• Target: The network device being accessed (xdm.target.ipv4andxdm.target.resource.name).• Observer: The AAA server validating the credential (xdm.observer.name).### Logout conventionA logout record should takexdm.event.outcome = OUTCOME_SUCCESSbut leavexdm.event.operationunset. This ensures logout events do not incorrectly inflate login metrics.</details></details>Show markdown source
@@ -1,82 +1,132 @@ -# How to map authentication story events? +# How to map authentication events for analytics + +{% hint style="info" %} +**License** + +To enable Identity Threat Detection and Response (ITDR) analytics, you must have the ITDR license and ingest identity logs. Full identity analytics capabilities are optimized for data collected via Cortex XDR agents and specific cloud/SaaS integrations. +{% endhint %} + +Cortex XSIAM enables analytics to run on all mapped authentication data, which automatically creates authentication stories for Cortex Data Model (XDM) identity data. To build these stories, you must map authentication events to the XDM schema using specific mandatory fields and principles. For a complete list of these fields, see [XDM fields for mapping authentication events](../../../reference-and-developer-docs/reference/xdm-fields-for-mapping-authentication-events). {% hint style="warning" %} ### Prerequisite -Data Model Rules requires **View/Edit** RBAC permissions for **Data Management** (under **Configurations** → **Data Management**), which are the same permissions required for Dataset Management, Parsing Rules, and Event Forwarding. +* You must have **View/Edit** RBAC permissions for **Data Management** (under **Configurations > Data Management**). +* Familiarize yourself with the Cortex Data model (XDM) schema for field definitions and naming conventions, see [XSIAM Data Model Schema](https://app.gitbook.com/s/HVBaxKOW1b6qcIQ6iMBh/). {% endhint %} -Cortex XSIAM enables analytics to run on all mapped authentication data, which automatically creates authentication stories for Cortex Data Model (XDM) identity data. As a result, you need to map authentication events to the Cortex XSIAM XDM schema to build the authentication story. For a complete list of these fields, see [XDM fields for mapping authentication events](../../../reference-and-developer-docs/reference/xdm-fields-for-mapping-authentication-events). - {% hint style="info" %} ### Scope Clarification This Feature focuses on authentication events related to SSO (Single Sign-On) and SaaS (Software-as-a-Service) application authentications. It does not cover internal authentication mechanisms such as Kerberos, NTLM, or traditional domain logon events generated by on-premise infrastructure. {% endhint %} -{% hint style="warning" %} -### Prerequisite - -Familiarize yourself with the Cortex Data model (XDM) schema for field definitions and naming conventions, see [XSIAM Data Model Schema](https://app.gitbook.com/s/HVBaxKOW1b6qcIQ6iMBh/). -{% endhint %} - <details> -<summary>Mapping principles</summary> +<summary><strong>Mapping principles</strong></summary> When mapping your authentication data, follow these guidelines: -* **Prioritize conclusive events**: Focus on mapping events that clearly represent the final stage or result of an authentication process. -* **Exclude ambiguous or non-final steps from outcome decisions**: Intermediate or informational events should not be treated as indicators of success or failure. +* **Prioritize conclusive events**: Focus on mapping events that represent the final result of an authentication process. +* **Exclude ambiguous steps**: Intermediate or informational events should not be treated as indicators of success or failure. * **Preserve context across the full authentication flow**: Include intermediate events to provide visibility into the process, while making it clear they are not final outcomes. -* **Normalize raw error and outcome data**: You must define explicit mapping logic between the raw event fields that contain outcome or error messages, such as `get_reason` and `debugdata_errorcode`, and the target XDM fields. This logic should normalize provider-specific strings or codes into a canonical format to support reliable detection and analytics across diverse sources. +* **Normalize raw error and outcome data**: Define explicit mapping logic between the raw event fields that contain outcome or error messages, such as `get_reason` and `debugdata_errorcode`, and the target XDM fields. This logic should normalize provider-specific strings or codes into a canonical format to support reliable detection and analytics across diverse sources. +* **Preserve attack evidence**: Do not sanitize identity fields at model time. Hostile values, such as template-injection probes, must be preserved verbatim as they are critical evidence for detection. </details> <details> -<summary>Why follow the mapping principles?</summary> +<summary><strong>Why follow the mapping principles?</strong></summary> * Prevents misclassification of failed sessions as successful. * Avoids distorted behavioral baselines that can mask real attacks. * Preserves full visibility of authentication flows without misleading analytics. </details> <details> -<summary>Third-party mapping examples</summary> +<summary><strong>Third-party mapping examples</strong></summary> * [DUO- SSO - Data Model Mapping](https://github.com/demisto/content/blob/master/Packs/DuoAdminApi/ModelingRules/DuoModelingRule_2_0/DuoModelingRule_2_0.xif#L26) * [Okta - SSO - Data Model Mapping](https://github.com/demisto/content/blob/master/Packs/Okta/ModelingRules/OktaModelingRules_2_0/OktaModelingRules_2_0.xif) </details> <details> -<summary>Mandatory XDM fields to map for authentication events</summary> +<summary><strong>Mandatory XDM fields to map for authentication events</strong></summary> -There are mandatory fields that you need map to the Cortex Data Model (XDM) schema to build authentication stories based on the mapped authentication data. For more detailed information on these fields, see [XDM fields for mapping authentication events](../../../reference-and-developer-docs/reference/xdm-fields-for-mapping-authentication-events). +You must map all 15 of the following fields. If a mandatory field is unmapped or incorrect, the event will be dropped from authentication stories and identity analytics. For more detailed information on these fields, see [XDM fields for mapping authentication events](../../../reference-and-developer-docs/reference/xdm-fields-for-mapping-authentication-events). -The following fields are mandatory to map: +{% hint style="warning" %} +**Important** -* `xdm.source.port` -* `xdm.target.ipv4` -* `xdm.target.port` -* `xdm.network.ip_protocol` -* `xdm.source.ipv4` -* `xdm.event.type` -* `xdm.event.tags` -* `xdm.event.operation` -* `xdm.event.original_event_type` -* `xdm.auth.service` -* `xdm.event.outcome` -* `xdm.source.user.upn` +To maximize the variety of issues that are retrieved based on the XDM authentication stories, we recommend that the following additional fields are populated: `xdm.logon.type`, `xdm.source.user_agent`, and `xdm.source.host.device_category`. Should you decide to change the default XDM mappings, ensure that both the mandatory and recommended fields are populated and do not contain any empty values. +{% endhint %} -{% hint style="info" %} -### Important +<table><thead><tr><th width="171">XDM Target Field</th><th>Data Type</th><th>Purpose and Guidance</th></tr></thead><tbody><tr><td><code>xdm.auth.service</code></td><td>String</td><td><strong>System Role.</strong> Decided PER EVENT TYPE: <code>IDP</code> (validates), <code>SP</code> (initiates), or <code>Universal</code> (local/AAA). Do not use protocol names here.</td></tr><tr><td><code>xdm.event.operation</code></td><td>String</td><td>Describes the action (such as <code>AUTH_LOGIN</code>, <code>AUTH_MFA</code>). Never blind-default if unclear.</td></tr><tr><td><code>xdm.event.original_event_type</code></td><td>String</td><td>The raw vendor event name exactly as logged.</td></tr><tr><td><code>xdm.event.outcome</code></td><td>Enum</td><td>Set only to <code>SUCCESS</code> or <code>FAILED</code>. Do not set on intermediate steps.</td></tr><tr><td><code>xdm.event.tags</code></td><td>Array</td><td>Must include <code>XDM_CONST.EVENT_TAG_AUTHENTICATION</code></td></tr><tr><td><code>xdm.event.type</code></td><td>String</td><td>Must contain <code>authentication</code>.</td></tr><tr><td><code>xdm.network.ip_protocol</code></td><td>Enum</td><td>The transport protocol (e.g., <code>TCP</code>). Fallback to <code>IP_PROTOCOL_IP</code> if unknown.</td></tr><tr><td><code>xdm.source.ipv4</code></td><td>String</td><td>The client IP observed by the authenticator. Never static or empty.</td></tr><tr><td><code>xdm.source.port</code></td><td>Integer</td><td>Map real value; otherwise <code>0</code>.</td></tr><tr><td><code>xdm.source.user.upn</code></td><td>String</td><td><strong>Identity Key.</strong> Must be UPN-shaped (<code>user@domain</code>). Use a shape-guard to append <code>@localhost</code> if the source provides only a bare username.</td></tr><tr><td><code>xdm.source.user.identity_type</code></td><td>Enum</td><td>The nature of the principal (such as <code>USER</code>, <code>MACHINE</code>, <code>BUILTIN</code>).</td></tr><tr><td><code>xdm.source.user.user_type</code></td><td>Enum</td><td>The account class (such as <code>REGULAR</code>, <code>SERVICE_ACCOUNT</code>).</td></tr><tr><td><code>xdm.target.ipv4</code></td><td>String</td><td>The IP of the device being accessed. If absent, use <code>""</code>.</td></tr><tr><td><code>xdm.target.port</code></td><td>Integer</td><td>Map real value; otherwise <code>0</code>.</td></tr><tr><td><code>xdm.target.resource.name</code></td><td>String</td><td>The name or address of the service being accessed. Set this in addition to specific host/app fields. Never pad this; if absent, resolve to null.</td></tr></tbody></table> -To maximize the variety of issues that are retrieved based on the XDM authentication stories, we recommend that the following additional fields are populated: `xdm.target.resource.name`, `xdm.logon.type`, `xdm.source.user_agent`, and `xdm.source.host.device_category`. Should you decide to change the default XDM mappings, ensure that both the mandatory and recommended fields are populated and do not contain any empty values. -{% endhint %} +</details> + +<details> + +<summary><strong>Detailed implementation guidance</strong></summary> + +### The three branches logic + +When an authentication field is missing from your source log, apply these treatments in order: + +1. **MAP**: If the source carries the value directly. +2. **DERIVE**: If the value can be constructed from another field (e.g., synthesizing a UPN). +3. **PAD**: Use semantically empty placeholders only if derivation is impossible. + * **Valid Pads**: `to_integer(0)` for ports, `""` for target IP, `IP_PROTOCOL_IP` for protocol. + * **Invalid Pads**: Never pad `xdm.target.resource.name` or `xdm.source.ipv4`. + +### Principal Classification (Identity vs. User Type) + +To support identity analytics, you must map both fields using specific constants: + +* `identity_type`: Classifies the **nature** of the principal (such as `IDENTITY_TYPE_MACHINE` for names ending in `$`, `IDENTITY_TYPE_BUILTIN` for `SYSTEM`). +* `user_type`: Defines the operational **class** (such as `USER_TYPE_REGULAR` for human logins, `USER_TYPE_SERVICE_ACCOUNT` for `svc_` prefixes). + +### Mandatory Field Crosswalk for Network/AAA Devices + +| **Vendor Field Hint** | **XDM Target Field** | **Implementation Note** | +| ----------------------- | -------------------------- | ----------------------------------------------------------------- | +| `user`, `username` | `xdm.source.user.upn` | Synthesize UPN: `concat(tmp_user, "@localhost")` | +| `priv_lvl`, `privilege` | `xdm.auth.privilege_level` | Band 15+ to `ADMIN`, 1+ to `USER`, 0 to `GUEST`. | +| `dvc_ip`, `nas-ip` | `xdm.target.ipv4` | The IP of the accessed device. | +| `src_ip`, `rem_addr` | `xdm.source.ipv4` | The IP of the authenticating client workstation. | +| `service` | `xdm.auth.auth_method` | **Protocol.** (e.g., `RADIUS`). Do not map to `xdm.auth.service`. | +| `task_id`, `session-id` | `xdm.network.session_id` | Crucial for correlating session lifecycle events. | + +</details> + +<details> + +<summary><strong>Important topologies</strong></summary> + +### **Device-local authentication** + +When a device logs a login to **itself** (such as SSH into a router): + +* **Observer**: The device that wrote the log is the `xdm.observer.*`. +* **Target**: If the login was into that device, the device is **ALSO** the target: `xdm.target.host.hostname` and `xdm.target.ipv4`. +* **Source**: The remote workstation initiating the connection is the source: `xdm.source.ipv4`, `xdm.source.port`, and `xdm.source.user.*`. + +### AAA Gateway topology + +Network-device AAA logs (TACACS+, RADIUS) involve three parties: + +* **Principal**: The human or service account (`xdm.source.user.upn`). +* **Source**: The user's workstation (`xdm.source.ipv4`). +* **Target**: The network device being accessed (`xdm.target.ipv4` and `xdm.target.resource.name`). +* **Observer**: The AAA server validating the credential (`xdm.observer.name`). + +### **Logout convention** + +A logout record should take `xdm.event.outcome = OUTCOME_SUCCESS` but leave `xdm.event.operation` **unset**. This ensures logout events do not incorrectly inflate login metrics. </details> -
▸ ▾ parse_cef modified +26 −0 Adds an Output results section showing the parsed JSON object the rule writes to the dataset.
xsiam/configure-cortex-xsiam/data-management/parsing-rules/parsing-rules-file-structure-and-syntax/ingest/parse_cefRead it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗
Before After@@ -23,8 +23,34 @@ alter raw ="<14>Oct 2 10:06:18 PAN-PROD-APPSVC-EU-W4-FW01 CEF:0|Palo Alto Netwo``````### Explanation of the rule components:### Explanation of the rule components:* `INGEST` section: Defines the `vendor`, `product`, and the `target_dataset` where the parsed logs will be stored.* `INGEST` section: Defines the `vendor`, `product`, and the `target_dataset` where the parsed logs will be stored.* `alter raw`: In this rule context, this defines the source string to be parsed (simulating the `_raw_log` input).* `alter raw`: In this rule context, this defines the source string to be parsed (simulating the `_raw_log` input).* `parse_cef(raw)`: Processes the CEF string into a structured object containing key-value pairs.* `parse_cef(raw)`: Processes the CEF string into a structured object containing key-value pairs.* Semicolon (`;`): Required at the end of the rule to ensure proper compilation.* Semicolon (`;`): Required at the end of the rule to ensure proper compilation.## Output resultsThe following JSON represents the structured object stored in the parsed field of the `test_parse_cef_raw` dataset after the rule is applied:<br>```"parsed": {"ad.subtype": "forward","ad.vd": "root","app": "ssl","cefDeviceEventClassId": "end","cefDeviceProduct": "PAN-OS","cefDeviceVendor": "Palo Alto Networks","cefDeviceVersion": "8.1.15-h3","cefName": "TRAFFIC","cefSeverity": "1","cefVersion": "CEF:0","double": "1.15","in": "8697","mac": "B3-F5-10-ED-C4-EE","pattern:test": "test","proto": "6","rt": 1664730378000,"src": "35.204.254.72"}```Show markdown source
@@ -23,8 +23,34 @@ alter raw ="<14>Oct 2 10:06:18 PAN-PROD-APPSVC-EU-W4-FW01 CEF:0|Palo Alto Netwo ``` ### Explanation of the rule components: * `INGEST` section: Defines the `vendor`, `product`, and the `target_dataset` where the parsed logs will be stored. * `alter raw`: In this rule context, this defines the source string to be parsed (simulating the `_raw_log` input). * `parse_cef(raw)`: Processes the CEF string into a structured object containing key-value pairs. * Semicolon (`;`): Required at the end of the rule to ensure proper compilation. + +## Output results + +The following JSON represents the structured object stored in the parsed field of the `test_parse_cef_raw` dataset after the rule is applied:<br> + +``` +"parsed": { +"ad.subtype": "forward", +"ad.vd": "root", +"app": "ssl", +"cefDeviceEventClassId": "end", +"cefDeviceProduct": "PAN-OS", +"cefDeviceVendor": "Palo Alto Networks", +"cefDeviceVersion": "8.1.15-h3", +"cefName": "TRAFFIC", +"cefSeverity": "1", +"cefVersion": "CEF:0", +"double": "1.15", +"in": "8697", +"mac": "B3-F5-10-ED-C4-EE", +"pattern:test": "test", +"proto": "6", +"rt": 1664730378000, +"src": "35.204.254.72" +} +``` -
▸ ▾ Manage file execution modified +10 −4 Adds script and Java file types to the allow and block lists on all three operating systems, plus War, Asp and Aspx when On-write File Examination is enabled.
xsiam/detect-investigate-and-respond-to-threats/investigation-and-response/investigate-files/manage-file-executionRead it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗
Before After@@ -1,23 +1,29 @@# Manage file execution# Manage file executionYou can manage file execution on your endpoints by adding file hashes to your allow and block lists. If you trust a certain file and know it to be benign, you can add the file hash to the allow list. This allows the file to be executed on all your endpoints regardless of the WildFire or local analysis verdict. Similarly, if you want to always block a file from running on your endpoints, you can add the associated hash to the block list.You can manage file execution on your endpoints by adding file hashes to your allow and block lists. If you trust a certain file and know it to be benign, you can add the file hash to the allow list. This allows the file to be executed on all your endpoints regardless of the WildFire or local analysis verdict. Similarly, if you want to always block a file from running on your endpoints, you can add the associated hash to the block list.Adding files to the allow and block lists takes precedence over any other policy rules that are applied to these files. In the Action Center, you can monitor the allow and block list actions performed in your network, and add or remove files from these lists.Adding files to the allow and block lists takes precedence over any other policy rules that are applied to these files. In the Action Center, you can monitor the allow and block list actions performed in your network, and add or remove files from these lists.Supported file types are:Supported file types are:Operating system Supported file types Windows - PE, PE64
- doc, docx, xls, xlsx (only if they contain macro files)
- PS1
Mac macho, DMG Linux ELF Operating system│Supported file types| ---------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- |Windows│- PE, PE64
- doc, docx, xls, xlsx (only if they contain macro files)
- PS1
- VBS, VBE, JSE, Java (JAR/WAR), JS, JSP, JSPX
Mac│- macho, DMG
- JS, JSP, JSPX
Linux│- ELFS
- JE, JSP, JSPX
#### How to add a file to the allow or block list or allow listIf On-write File Examination is enabled, the following file type hashes are also supported in the allow and block list: War, Asp, Aspx.1. Go to Investigation & Response → Response → Action Center → New Action.### How to add a file to the allow or block list or allow list1. Go to Investigation & Response → Response → Action Center → New Action.2. Select Add to Block List or Add to Allow List.2. Select Add to Block List or Add to Allow List.3. Enter the SHA-256 hash of the file and click 🖼 blue-arrow.png.3. Enter the SHA-256 hash of the file and click 🖼 blue-arrow.png.You can add up to 100 file hashes at one time. If you add a comment, it is added to all the hashes you added in this action.You can add up to 100 file hashes at one time. If you add a comment, it is added to all the hashes you added in this action.4. Click Next.4. Click Next.5. Review the summary and click Done.5. Review the summary and click Done.In the next heartbeat, the agent retrieves the updated lists from Cortex XSIAM.In the next heartbeat, the agent retrieves the updated lists from Cortex XDR.6. You are automatically redirected to the Block List or Allow List that corresponds to the action in the Action Center.6. You are automatically redirected to the Block List or Allow List that corresponds to the action in the Action Center.7. To manage the file hashes on the Block List or the Allow List, right-click a file to see the available actions.7. To manage the file hashes on the Block List or the Allow List, right-click a file to see the available actions.Show markdown source
@@ -1,23 +1,29 @@ # Manage file execution You can manage file execution on your endpoints by adding file hashes to your allow and block lists. If you trust a certain file and know it to be benign, you can add the file hash to the allow list. This allows the file to be executed on all your endpoints regardless of the WildFire or local analysis verdict. Similarly, if you want to always block a file from running on your endpoints, you can add the associated hash to the block list. Adding files to the allow and block lists takes precedence over any other policy rules that are applied to these files. In the **Action Center**, you can monitor the allow and block list actions performed in your network, and add or remove files from these lists. Supported file types are: -<table><thead><tr><th width="198">Operating system</th><th>Supported file types</th></tr></thead><tbody><tr><td>Windows</td><td><ul><li>PE, PE64</li><li>doc, docx, xls, xlsx (only if they contain macro files)</li><li>PS1</li></ul></td></tr><tr><td>Mac</td><td>macho, DMG</td></tr><tr><td>Linux</td><td>ELF</td></tr></tbody></table> +| Operating system | Supported file types | +| ---------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Windows | <ul><li>PE, PE64</li><li>doc, docx, xls, xlsx (only if they contain macro files)</li><li>PS1</li><li>VBS, VBE, JSE, Java (JAR/WAR), JS, JSP, JSPX</li></ul> | +| Mac | <ul><li>macho, DMG</li><li>JS, JSP, JSPX</li></ul> | +| Linux | <ul><li>ELFS</li><li>JE, JSP, JSPX</li></ul> | -#### **How to add a file to the allow or block list or allow list** +If **On-write File Examination** is enabled, the following file type hashes are also supported in the allow and block list: War, Asp, Aspx. -1. Go to **Investigation & Response → Response → Action Center →** **New Action**. +### How to add a file to the allow or block list or allow list + +1. Go to Investigation & Response → Response → Action Center → **New Action**. 2. Select **Add to Block List** or **Add to Allow List**. 3. Enter the SHA-256 hash of the file and click . You can add up to 100 file hashes at one time. If you add a comment, it is added to all the hashes you added in this action. 4. Click **Next**. 5. Review the summary and click **Done**. - In the next heartbeat, the agent retrieves the updated lists from Cortex XSIAM. + In the next heartbeat, the agent retrieves the updated lists from Cortex XDR. 6. You are automatically redirected to the **Block List** or **Allow List** that corresponds to the action in the **Action Center**. 7. To manage the file hashes on the **Block List** or the **Allow List**, right-click a file to see the available actions. -
▸ ▾ Manage quarantined files modified +31 −19 Broadens quarantine beyond Windows with per-OS folder paths and adds retention and expiry timeframes; an editorial note about adding the macOS path is left published in that line.
xsiam/detect-investigate-and-respond-to-threats/investigation-and-response/investigate-files/manage-quarantined-filesRead it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗
Before After@@ -1,41 +1,53 @@# Manage quarantined files# Manage quarantined filesWhen the agent detects malware on a Windows endpoint, you can take additional precautions to quarantine the file. When the agent quarantines malware, it moves the file from the location on a local or removable drive to a local quarantine folder (%PROGRAMDATA%\Cyvera\Quarantine) where it isolates the file. This prevents the file from attempting to run again from the same path or causing any harm to your endpoints.When the agent detects malware on an endpoint, you can take additional precautions to quarantine the file. When the agent quarantines malware, it moves the file from the location on a local or removable drive to a local quarantine folder where it encrypts and isolates the file as a locked file. This prevents the file from attempting to run again from the same path or causing any harm to your endpoints. The file remains stored locally in this repository until explicitly restored or deleted, or until storage rotation occurs.To evaluate whether an executable file is considered malicious, the agent calculates a verdict using information from the following sources in order of priority:To evaluate whether an executable file is considered malicious, the agent calculates a verdict using information from the following sources in order of priority:• Hash exception policy1. Hash exception policy• WildFire threat intelligence2. WildFire threat intelligence• Local analysis3. Local analysis### Local quarantine folder location by OS• Windows:%ProgramData%\PaloAltoNetworks\Traps\quarantine\(or...\Cortex XDR\quarantine\, depending on agent version)• macOS:/Library/Application Support/PaloAltoNetworks/Traps/quarantine/(or.../Cortex XDR/quarantine/) [Comment: Added macOS path from Text 2]• Linux:/opt/traps/quarantine/(or/var/log/traps/quarantine/)### How to quarantine a file### How to quarantine a fileYou can quarantine a file in the following ways:You can quarantine a file in the following ways:• Enable the agent to automatically quarantine malicious executables by configuring quarantine settings in a Malware prevention profile. For more information, see Set up malware prevention profiles.• Enable the agent to automatically quarantine malicious executables by configuring quarantine settings in a Malware prevention profile. For more information, see Set up malware prevention profiles.• Right-click a specific file from the causality view and select Quarantine.• Right-click a specific file from the causality view and select Quarantine.### Retention and Expiration Timeframes• Quarantine List Retention: Quarantined file records remain in the Quarantine List for a default retention period of 180 days (6 months).• Pending Action Expiration: When a Quarantine command is issued to an offline or unreachable endpoint, the command stays in Pending status for 4 days by default before expiring. This setting is configurable between 1 and 30 days.To update the Pending Action Expiration setting, go to Settings → Configurations → Action Center Expiration (or Settings → Configurations → Security & Server Settings, depending on tenant version), locate Quarantine under the Response category, modify the Expiration (Days) field, and click Save.### View and manage quarantined files### View and manage quarantined fileshint infohint infoRequires the Cortex XSIAM Premium, Enterprise, or any other XSIAM license with the Enterprise Runtime Security or the Cloud Runtime Security add-on.Requires the Cortex XSIAM Premium, Enterprise, or any other XSIAM license with the Enterprise Runtime Security or the Cloud Runtime Security add-on.endhintendhint1. To view the quarantined files in your network, go to Investigation & Response → Response → Action Center → File Quarantine.1. To view the quarantined files in your network, go to Investigation & Response → Response → Action Center → File Quarantine.Toggle between the **Detailed** and **Aggregated By SHA256** tabs to see information on your quarantined files.Toggle between the **Detailed** and **Aggregated By SHA256** tabs to see information on your quarantined files.2. Review details about quarantined files.2. Review details about quarantined files.• In the Detailed view, filter and review the Endpoint Name, Domain, File Path, Quarantine Source, and Quarantine Date of all the quarantined files. You can take the following actions:In the **Detailed** view, filter and review the **Endpoint Name**, **Domain**, **File Path**, **Quarantine Source**, and **Quarantine Date** of all the quarantined files. You can take the following actions:• Reinstate a quarantined file: Right-click one or more rows and select Restore all files by SHA256.• Reinstate a quarantined file: Right-click one or more rows and select Restore all files by SHA256.<div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><h3>Note</h3><p>This will restore all files with the same hash on all of your endpoints.</p></div><div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><h3>Note</h3><p>This will restore all files with the same hash on all of your endpoints.</p></div>• Review the quarantined file inspection results on VirusTotal: Right-click the Hash field and select Open in VirusTotal.• Review the quarantined file inspection results on VirusTotal: Right-click the Hash field and select Open in VirusTotal.• Drill down on the hash value: Right-click the Hash field and select Open Hash View. You can see each of the process executions, file operations, cases, actions, and threat intelligence reports relating to the hash value.• Drill down on the hash value: Right-click the Hash field and select Open Hash View. You can see each of the process executions, file operations, cases, actions, and threat intelligence reports relating to the hash value.• Search for where the hash value appears in Cortex XSIAM: Right-click the Hash field and select Open in Quick Launcher.• Search for where the hash value appears in Cortex XSIAM: Right-click the Hash field and select Open in Quick Launcher.• Export to file: Click the icon on the top right corner to download a detailed list of the quarantined hashes in a TSV format.• Export to file: Click the icon on the top right corner to download a detailed list of the quarantined hashes in a TSV format.• In the Aggregated by SHA256 view, filter and review the Hash, File Name, File Path, and Scope of all the quarantined files. You can take the following actions:3. In the Aggregated by SHA256 view, filter and review the Hash, File Name, File Path, and Scope of all the quarantined files. You can take the following actions:• Open the Quarantine Details page: Right-click a row and select Additional Data to open the page detailing the Endpoint Name, Domain, File Path, Quarantine Source, and Quarantine Date of a specific file hash.• Open the Quarantine Details page: Right-click a row and select Additional Data to open the page detailing the Endpoint Name, Domain, File Path, Quarantine Source, and Quarantine Date of a specific file hash.• Reinstate a file hash: Right-click and select Restore.• Reinstate a file hash: Right-click and select Restore.• Permanently delete quarantined files on the endpoint: Right-click and select Delete all files by SHA256.• Permanently delete quarantined files on the endpoint: Right-click and select Delete all files by SHA256.Show markdown source
@@ -1,41 +1,53 @@ # Manage quarantined files -When the agent detects malware on a Windows endpoint, you can take additional precautions to quarantine the file. When the agent quarantines malware, it moves the file from the location on a local or removable drive to a local quarantine folder (`%PROGRAMDATA%\Cyvera\Quarantine`) where it isolates the file. This prevents the file from attempting to run again from the same path or causing any harm to your endpoints. +When the agent detects malware on an endpoint, you can take additional precautions to quarantine the file. When the agent quarantines malware, it moves the file from the location on a local or removable drive to a local quarantine folder where it encrypts and isolates the file as a locked file. This prevents the file from attempting to run again from the same path or causing any harm to your endpoints. The file remains stored locally in this repository until explicitly restored or deleted, or until storage rotation occurs. To evaluate whether an executable file is considered malicious, the agent calculates a verdict using information from the following sources in order of priority: -* Hash exception policy -* WildFire threat intelligence -* Local analysis +1. Hash exception policy +2. WildFire threat intelligence +3. Local analysis + +### Local quarantine folder location by OS + +* Windows: `%ProgramData%\PaloAltoNetworks\Traps\quarantine\` (or `...\Cortex XDR\quarantine\`, depending on agent version) +* macOS: `/Library/Application Support/PaloAltoNetworks/Traps/quarantine/` (or `.../Cortex XDR/quarantine/`) \[Comment: Added macOS path from Text 2] +* Linux: `/opt/traps/quarantine/` (or `/var/log/traps/quarantine/`) ### How to quarantine a file You can quarantine a file in the following ways: * Enable the agent to automatically quarantine malicious executables by configuring quarantine settings in a Malware prevention profile. For more information, see [Set up malware prevention profiles](https://app.gitbook.com/s/mxWuY3s7AUvWfzCV9p1A/endpoint-security/install-and-manage-endpoints/set-up-endpoint-protection/set-up-endpoint-profiles-and-exception-rules/set-up-malware-prevention-profiles). * Right-click a specific file from the causality view and select **Quarantine**. +### Retention and Expiration Timeframes + +* **Quarantine List Retention:** Quarantined file records remain in the Quarantine List for a default retention period of 180 days (6 months). +* **Pending Action Expiration:** When a Quarantine command is issued to an offline or unreachable endpoint, the command stays in Pending status for 4 days by default before expiring. This setting is configurable between 1 and 30 days. + +To update the Pending Action Expiration setting, go to **Settings → Configurations → Action Center Expiration** (or **Settings → Configurations → Security & Server Settings**, depending on tenant version), locate **Quarantine** under the **Response** category, modify the Expiration (Days) field, and click **Save**. + ### View and manage quarantined files {% hint style="info" %} Requires the Cortex XSIAM Premium, Enterprise, or any other XSIAM license with the Enterprise Runtime Security or the Cloud Runtime Security add-on. {% endhint %} 1. To view the quarantined files in your network, go to **Investigation & Response → Response → Action Center →** **File Quarantine**. Toggle between the **Detailed** and **Aggregated By SHA256** tabs to see information on your quarantined files. -2. Review details about quarantined files. - - In the **Detailed** view, filter and review the **Endpoint Name**, **Domain**, **File Path**, **Quarantine Source**, and **Quarantine Date** of all the quarantined files. You can take the following actions: - - * **Reinstate a quarantined file:** Right-click one or more rows and select **Restore all files by SHA256**. - - <div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><h3>Note</h3><p>This will restore all files with the same hash on all of your endpoints.</p></div> - * **Review the quarantined file inspection results on VirusTotal:** Right-click the **Hash** field and select **Open in VirusTotal**. - * **Drill down on the hash value:** Right-click the **Hash** field and select **Open Hash View**. You can see each of the process executions, file operations, cases, actions, and threat intelligence reports relating to the hash value. - * **Search for where the hash value appears in Cortex XSIAM:** Right-click the **Hash** field and select **Open in Quick Launcher**. - * **Export to file:** Click the icon on the top right corner to download a detailed list of the quarantined hashes in a TSV format. -3. In the **Aggregated by SHA256** view, filter and review the **Hash**, **File Name**, **File Path**, and **Scope** of all the quarantined files. You can take the following actions: - * **Open the Quarantine Details page:** Right-click a row and select **Additional Data** to open the page detailing the **Endpoint Name**, **Domain**, **File Path**, **Quarantine Source**, and **Quarantine Date** of a specific file hash. - * **Reinstate a file hash:** Right-click and select **Restore**. - * **Permanently delete quarantined files on the endpoint:** Right-click and select **Delete all files by SHA256**. +2. Review details about quarantined files. + * In the **Detailed** view, filter and review the **Endpoint Name**, **Domain**, **File Path**, **Quarantine Source**, and **Quarantine Date** of all the quarantined files. You can take the following actions: + * **Reinstate a quarantined file:** Right-click one or more rows and select **Restore all files by SHA256**. + + <div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><h3>Note</h3><p>This will restore all files with the same hash on all of your endpoints.</p></div> + + * **Review the quarantined file inspection results on VirusTotal:** Right-click the **Hash** field and select **Open in VirusTotal**. + * **Drill down on the hash value:** Right-click the **Hash** field and select **Open Hash View**. You can see each of the process executions, file operations, cases, actions, and threat intelligence reports relating to the hash value. + * **Search for where the hash value appears in Cortex XSIAM:** Right-click the **Hash** field and select **Open in Quick Launcher**. + * **Export to file:** Click the icon on the top right corner to download a detailed list of the quarantined hashes in a TSV format. + * In the **Aggregated by SHA256** view, filter and review the **Hash**, **File Name**, **File Path**, and **Scope** of all the quarantined files. You can take the following actions: + * **Open the Quarantine Details page:** Right-click a row and select **Additional Data** to open the page detailing the **Endpoint Name**, **Domain**, **File Path**, **Quarantine Source**, and **Quarantine Date** of a specific file hash. + * **Reinstate a file hash:** Right-click and select **Restore**. + * **Permanently delete quarantined files on the endpoint:** Right-click and select **Delete all files by SHA256**. -
▸ ▾ Extended Threat Intelligence modified +0 −2 Drops a redundant Extended Threat Intelligence overview heading.
xsiam/detect-investigate-and-respond-to-threats/threat-management/extended-threat-intelligenceRead it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗
Before After@@ -1,18 +1,16 @@------description: >-description: >-Research threats, investigate indicators, and apply intelligence across CortexResearch threats, investigate indicators, and apply intelligence across CortexXSIAM workflows.XSIAM workflows.------# Extended Threat Intelligence# Extended Threat Intelligence## Extended Threat Intelligence overviewExtended Threat Intelligence (XTI) offers operationalized Threat Intelligence (TI) seamlessly integrated across the Cortex platform.Extended Threat Intelligence (XTI) offers operationalized Threat Intelligence (TI) seamlessly integrated across the Cortex platform.
XTI offers the following core capabilities:XTI offers the following core capabilities:• Threat Intel Library: Powered by Unit 42 threat intel data, the Threat Intel Library provides a unified catalog of curated threat objects (threat actors, malware families, vulnerabilities, and reports), helping you understand the broader threat landscape.• Threat Intel Library: Powered by Unit 42 threat intel data, the Threat Intel Library provides a unified catalog of curated threat objects (threat actors, malware families, vulnerabilities, and reports), helping you understand the broader threat landscape.• XTI Indicators: XTI indicators include first-party indicators, as well as observables extracted from detections and customer-managed indicators.• XTI Indicators: XTI indicators include first-party indicators, as well as observables extracted from detections and customer-managed indicators.Show markdown source
@@ -1,18 +1,16 @@ --- description: >- Research threats, investigate indicators, and apply intelligence across Cortex XSIAM workflows. --- # Extended Threat Intelligence -## Extended Threat Intelligence overview - Extended Threat Intelligence (XTI) offers operationalized Threat Intelligence (TI) seamlessly integrated across the Cortex platform. <figure><img src="https://2786854933-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FAEIjuYE3RXcIfmuQnBbm%2Fuploads%2FfgqohfZlHMei5r9mobRS%2Funknown.png?alt=media&token=d63be7a9-dc9a-4afe-b999-2ec139433e8e" alt="This screenshot from Cortex UI shows the XTI Threat Intel Library page listing threat actors." height="411" width="624"><figcaption></figcaption></figure> XTI offers the following core capabilities: * **Threat Intel Library:** Powered by Unit 42 threat intel data, the Threat Intel Library provides a unified catalog of curated threat objects (threat actors, malware families, vulnerabilities, and reports), helping you understand the broader threat landscape. * **XTI Indicators:** XTI indicators include first-party indicators, as well as observables extracted from detections and customer-managed indicators.
-
▸ ▾ Cortex XSIAM architecture modified +40 −19 Reorganized under headings for core capabilities, XDL, the Agentic Assistant and Broker VM, and the ecosystem diagram was replaced.
xsiam/learn-about-cortex-xsiam/get-started-cortex-xsiam/cortex-xsiam-architectureRead it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗
Before After@@ -1,40 +1,61 @@------description: Learn more about the Cortex XSIAM architecture.description: >-Explore the Cortex XSIAM architecture, including SIEM, XDR, SOAR, cloudsecurity, XDL data ingestion, and Broker VM.------# Cortex XSIAM architecture# Cortex XSIAM architectureThe following diagram shows the high-level architecture for key Cortex XSIAM components:### Cortex XSIAM architecture overview🖼 imageCortex 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.• Cortex XSIAM includes the following core capabilities:🖼 Cortex XSIAM architecture showing core security capabilities and Cortex Extended Data Lake• SIEM• EDR/XDR### Core Cortex XSIAM capabilities• CDR (Cloud Detection and Response), including Cloud Posture and Cloud Runtime Security• NDR (Network Detection and Response)• Cortex XSIAM includes:• SOAR• SIEM (security information and event management)• Cortex Extended Data Lake (XDL) provides unified data normalization, AI, and automation. It centralizes all telemetry, ensuring a single, intelligent source of truth, including the following:• 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│DescriptionFeature│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.
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.
Note
If you plan to stream data from a Strata Logging Service instance, it must reside in the same region as your Cortex XSIAM tenant.
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.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.
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.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 collectionOpen 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• You can extend Cortex XSIAM by adding advanced capabilities, such as ITDR (Identity Threat Detection and Response) for domain controller protection, Threat Intelligence Platform (TIP), Attack Surface Management (ASM), Email Advanced Security, and Exposure Management.• Cortex Agentic Assistant is the autonomous "brain" of Cortex XSIAM. It utilizes AI agents that plan, reason, and investigate complex threats, such as cloud identity theft or container breaches.Cortex XSIAM ecosystem### Extended Cortex XSIAM capabilitiesYou 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 AssistantCortex Agentic Assistant uses AI agents to plan, reason, and investigate complex threats. Examples include cloud identity theft and container breaches.### Cortex XSIAM ecosystemThis diagram illustrates how XSIAM serves as a central command center, connecting diverse data sources and proactive security functions. It represents the full system architecture.This diagram shows Cortex XSIAM as a central security operations platform. It connects diverse data sources and proactive security functions.

Cortex XSIAM ecosystem architecture.
Product Architecture and the Broker VM### Broker VM architecture and data collectionBroker VM acts as a secure on-prem gateway. It centralizes data collection from security devices that cannot send data directly to the cloud, providing a secure proxy for agents and collectors in restricted or air-gapped networks. It runs specialized applets to handle different data types. Data is collected and ingested into Cortex XDL.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.
Show markdown source
@@ -1,40 +1,61 @@ --- -description: Learn more about the Cortex XSIAM architecture. +description: >- + Explore the Cortex XSIAM architecture, including SIEM, XDR, SOAR, cloud + security, XDL data ingestion, and Broker VM. --- # Cortex XSIAM architecture -The following diagram shows the high-level architecture for key Cortex XSIAM components: +### 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. -* Cortex XSIAM includes the following core capabilities: - * SIEM - * EDR/XDR - * CDR (Cloud Detection and Response), including Cloud Posture and Cloud Runtime Security - * NDR (Network Detection and Response) - * SOAR -* Cortex Extended Data Lake (XDL) provides unified data normalization, AI, and automation. It centralizes all telemetry, ensuring a single, intelligent source of truth, including the following: + + +### Core Cortex XSIAM capabilities + +* Cortex XSIAM includes: + * **SIEM** (security information and event management) + * **EDR/XDR** (endpoint and extended detection and response) + * **CDR** (cloud detection and response), including Cloud Posture and Cloud Runtime Security + * **NDR** (network detection and response) + * **SOAR** (security orchestration, automation, and response) + +### Cortex Extended Data Lake (XDL) + +* Cortex Extended Data Lake (XDL) provides unified data normalization, AI, and automation. It centralizes security telemetry as a single, intelligent source of truth, including: | Feature | Description | | ----------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Endpoint | <p>Cortex XDR agents forward all data directly to Cortex XDL. This data is accessible for query and investigation within Cortex XSIAM.</p><p>When a Cortex XDR agent detects an unknown sample (an attempt to run a macro, DLL, or executable file), Cortex XSIAM can automatically forward the sample for WildFire analysis. WildFire Cloud Service identifies previously unknown malware and generates signatures that Palo Alto Networks firewalls and Cortex XSIAM can use to detect and block that malware.</p><p>Based on the properties, behaviors, and activities the sample displays when analyzed and executed in the WildFire sandbox, WildFire determines whether the sample is benign, grayware, phishing, or malicious. WildFire then generates signatures to recognize the newly discovered malware and makes the latest signatures globally available every five minutes.</p> | - | Network & SASE | <p>Centralizes logs from Palo Alto Networks sources. It utilizes the Strata Logging Service to ingest and normalize network logs from Next-Generation Firewalls (NGFW) and Prisma Access.</p><div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><p><strong>Note</strong></p><p>If you plan to stream data from a Strata Logging Service instance, it must reside in the same region as your Cortex XSIAM tenant.</p></div> | + | Network & SASE | <p>Centralizes logs from Palo Alto Networks sources. It utilizes the Strata Logging Service to ingest and normalize network logs from Next-Generation Firewalls (NGFW) and Prisma Access.</p><div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><p>If you plan to stream data from a Strata Logging Service instance, it must reside in the same region as your Cortex XSIAM tenant.</p></div> | | Cloud, Apps & CI/CD | Provides comprehensive visibility across your cloud infrastructure, version control systems (VCS), and delivery pipelines to detect risks, such as exposed secrets, Software Composition Analysis (SCA) vulnerabilities, and IaC misconfigurations. | | Identity | <p>Consumes data from identity sources that connect to the Cloud Identity Engine, which provides the necessary Active Directory or Okta context for User/Entity Behavior Analytics (UEBA).</p><p>The Cloud Identity Engine (CIE) enables Palo Alto Networks cloud-based applications to use computer, user, and group attributes from your organization’s directories for security policies and endpoint management. This cloud-based service synchronizes attribute data from various sources, including On-prem directories like Active Directory and cloud-based directories such as Microsoft Entra ID, Okta, and Google Cloud Identity.</p><p>The Cortex XSIAM tenant and the CIE must be deployed in the same region.</p> | | Vulnerabilities and exposures | ASM performs DNS lookups and scans hosts to identify security flaws before they can be exploited. The intelligence gathered from these lookups and scans is transformed into actionable data, such as vulnerabilities and exposures. | | Open ecosystem (any source) | Facilitates the ingestion of third-party security and management vendor telemetry, custom logs, and external alerts from any environment. These sources are integrated into Cortex XDL using an HTTP Log Collector or through the Broker VM, which runs specialized applets for Syslog, Database, CSV, Kafka, and FTP collection | -* You can extend Cortex XSIAM by adding advanced capabilities, such as ITDR (Identity Threat Detection and Response) for domain controller protection, Threat Intelligence Platform (TIP), Attack Surface Management (ASM), Email Advanced Security, and Exposure Management. -* Cortex Agentic Assistant is the autonomous "brain" of Cortex XSIAM. It utilizes AI agents that plan, reason, and investigate complex threats, such as cloud identity theft or container breaches. -**Cortex XSIAM ecosystem** +### 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 illustrates how XSIAM serves as a central command center, connecting diverse data sources and proactive security functions. It represents the full system architecture. +This diagram shows Cortex XSIAM as a central security operations platform. It connects diverse data sources and proactive security functions. -<figure><img src="https://2786854933-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FAEIjuYE3RXcIfmuQnBbm%2Fuploads%2F4mN4E9ti2HEb5C5sKS4z%2Farch-xsaim.png?alt=media&token=901a79e4-b0c3-4b57-9ec6-3bafb3a0a40e" alt=""><figcaption></figcaption></figure> +<figure><img src="https://2786854933-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FAEIjuYE3RXcIfmuQnBbm%2Fuploads%2FQbAfFWWNgsBueFKYXxbU%2Fimage.png?alt=media&token=f3c44fd2-b0f1-4840-a860-8239e9e57350" alt="Cortex XSIAM ecosystem connecting security data sources, XDL, and proactive security functions"><figcaption><p>Cortex XSIAM ecosystem architecture.</p></figcaption></figure> -**Product Architecture and the Broker VM** +### Broker VM architecture and data collection -Broker VM acts as a secure on-prem gateway. It centralizes data collection from security devices that cannot send data directly to the cloud, providing a secure proxy for agents and collectors in restricted or air-gapped networks. It runs specialized applets to handle different data types. Data is collected and ingested into Cortex XDL. +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. -<figure><img src="https://2786854933-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FAEIjuYE3RXcIfmuQnBbm%2Fuploads%2Fs2fhystfiBuytnXX7Gj3%2Fbroker-vm.png?alt=media&token=0113b5f8-5763-4262-b894-577d1aa66dea" alt=""><figcaption></figcaption></figure> +<figure><img src="https://2786854933-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FAEIjuYE3RXcIfmuQnBbm%2Fuploads%2Fs2fhystfiBuytnXX7Gj3%2Fbroker-vm.png?alt=media&token=0113b5f8-5763-4262-b894-577d1aa66dea" alt="Cortex XSIAM Broker VM architecture for secure on-premises data collection"><figcaption><p>Broker VM data collection architecture.</p></figcaption></figure> -
▸ ▾ Assign user roles and groups modified +2 −10 The granular scoping table, previously broken across malformed markdown rows, is rebuilt as an HTML table.
xsiam/onboard-cortex-xsiam/deployment-steps/set-up-users-and-roles/assign-user-roles-and-groupsRead it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗
Before After@@ -26,25 +26,17 @@ Cortex XSIAM provides predefined built-in user roles that provide specific acces2. Under Components, expand each list to view the permissionsSetting 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.2. Under Components, expand each list to view the permissionsSetting 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.7. (Optional) You can configure and manage granular scoping:7. (Optional) You can configure and manage granular scoping:1. Click the Scope tab.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: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:<div data-gb-custom-block data-tag="hint" data-style="warning" class="hint hint-warning"><p>Before configuring, ensure that you review <strong>Understand scoping</strong> in the <a href="../../../post-deployment/manage-user-roles-and-access-management#UUID-071cdbb6-6c6a-6afe-3a67-1fa79991a0a8">Manage user scope</a> section.</p></div><div data-gb-custom-block data-tag="hint" data-style="warning" class="hint hint-warning"><p>Before configuring, ensure that you review <strong>Understand scoping</strong> in the <a href="../../../post-deployment/manage-user-roles-and-access-management#UUID-071cdbb6-6c6a-6afe-3a67-1fa79991a0a8">Manage user scope</a> section.</p></div>Scoping Area│Granular Scoping Configurations<table><thead><tr><th>Scoping Area</th><th>Granular Scoping Configurations</th></tr></thead><tbody><tr><td>Assets</td><td><p>Set the <strong>Scope</strong> by selecting one of the following:</p><ul><li><strong>No assets</strong>: No asset is accessible.</li><li><strong>All assets</strong>: Defines access to all assets.</li><li><strong>Select asset groups</strong>: 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 <strong>Select asset groups</strong>, 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 <a href="../../../post-deployment/manage-user-roles-and-access-management/manage-user-scope#UUID-071cdbb6-6c6a-6afe-3a67-1fa79991a0a8_section-idm235041053079477">Manage user scope</a> (under <strong>Understand scoping</strong> → <strong>Scoping Areas</strong> → <strong>Assets</strong>).</li></ul><p>The scoping of assets also affects the scoping of cases, issues, and findings.</p><div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><p><strong>Note</strong></p><p>Visibility of Security domain Issues that refer to assets with agents is controlled by the <strong>Endpoints</strong> scoping configuration.</p></div></td></tr><tr><td>Cases and Issues</td><td><p>Set the <strong>Scope</strong> by selecting one of the following:</p><ul><li><strong>No cases and issues</strong>: Defines access to no cases and issues.</li><li><strong>All cases and issues</strong>: Defines access to all cases and issues. Users can view cases or issues referencing assets within their scope. Use the <strong>Assets</strong> section to define which assets are in scope.</li><li><p><strong>Select domains</strong>: Defines access to the domains selected to view their related cases and issues. Under <strong>Select domains</strong>, define the specific domains that you want to grant access.</p><p>Users can only view cases or issues referencing assets and endpoints within their scope. Use the <strong>Assets</strong> section to define which assets are in scope.</p></li></ul><p>When selecting <strong>All cases and issues</strong> or <strong>Select domains</strong>, you can separately configure access to issues and cases that lack an asset reference or where the referenced asset is not in <strong>All Assets</strong> and <strong>All Endpoints</strong> inventories. To provide access, select the <strong>Allow access to cases and issues that are not referencing known assets or endpoints</strong> checkbox. Once selected, you can specifically control which users have access to issues and cases that lack <strong>Affected Assets</strong> (as seen in the issue’s panel) and <strong>Assets</strong> (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 <strong>User Risk View</strong>, which differs from the standard inventories panels. In the <strong>Issues</strong> and <strong>Cases</strong> tables, such items can be identified by empty values in the following columns: Asset IDs, Target Agent Identifier, and Source Agent Identifier.</p></td></tr><tr><td>Endpoints</td><td><p>Set the <strong>Scope</strong> by selecting one of the following:</p><ul><li><strong>No endpoints</strong>: Defines access to no endpoints with no ability to view their related agent management and enterprise policies.</li><li><strong>All endpoints</strong>: 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 <strong>Security</strong> domain <strong>Cases and Issues</strong>, but will not affect asset visibility.</li><li><strong>Select specific (at least one required)</strong>: Defines specific access to all endpoint groups by selecting <strong>Endpoint Groups</strong> or all endpoint tags by selecting <strong>Endpoint Tags</strong> to view their related agent management and enterprise policies. This configuration can impact the visibility of related <strong>Security</strong> domain <strong>Cases and Issues</strong>, but will not affect asset visibility.</li></ul></td></tr><tr><td>Datasets Rows</td><td><p>Configure a <code>filter</code> to define the specific subset of rows a user is allowed to access in each raw dataset. A raw dataset is every dataset where Palo Alto Networks data is ingested out-of-the-box or third-party data is ingested using a configured dedicated collector, also called a data source. This filter configuration does not impact the visibility of cases and issues.</p><p>Follow these steps to configure a <code>filter</code>.</p><ol><li><p>For datasets where no <code>filter</code> is defined, determine how to set the When no filter is defined option as either:</p><ul><li>No rows are accessible (default): Without a configured <code>filter</code>, no rows are accessible. Users can query the datasets in Cortex Query Language (XQL) as they have access, but the results will be empty.</li><li>All rows are accessible: Without a configured <code>filter</code>, all rows are accessible. Users can query the datasets in Cortex Query Language (XQL) as they have access, and view all results.</li></ul><p>When defining a filter for row-level scoping on raw datasets, queries based on the Cortex Data Model (XDM) are not supported. XDM queries return specific rows only when All rows are accessible is selected and no filter is defined in the Datasets Rows scoping area. Otherwise, no rows are returned.</p></li><li><p>Define any filters for the applicable datasets listed in the table:</p><ol><li>Scroll down the list of datasets to the dataset you want to apply a <code>filter</code> on, and click the Edit Scope icon.</li><li><p>In the Define what rows are accessible window, continue to write the query for the <code>filter</code> in the query box (where the syntax is a limited subset of XQL) to limit the data rows for the selected dataset according to the access permissions you want the user to have. The beginning of the query is already defined before the query box, and there is no need to include this in your query.</p><p>For optimal performance, we recommend using a single field in the <code>filter</code> definition and simple comparison operators.</p><p>Supported syntax</p><p><strong>Fields</strong></p><p>You can define the rest of the <code>filter</code> in the query box, where only the following system fields are supported: <code>_broker_device_id</code>, <code>_broker_device_ip</code>, <code>_broker_device_name</code>, <code>_collector_id</code>, <code>_collector_ip</code>, <code>_collector_name</code>, <code>_collector_type</code>, <code>_device_id</code>, <code>_final_reporting_device_ip</code>, <code>_final_reporting_device_name</code>, <code>_log_type</code>, <code>_product</code>, <code>_scope</code>, <code>_reporting_device_ip</code>, <code>_reporting_device_name</code>, and <code>_vendor</code>.</p><p>For more information on these fields, see the table that describes all the fields in the <code>metrics_source</code> dataset and <code>metrics_view</code> preset in <a href="../../../configure-cortex-xsiam/cortex-xsiam-data-sources/administration-and-troubleshooting/overview-of-data-ingestion-metrics">Overview of data ingestion metrics</a>. For more information on the <code>_scope</code> field (relevant when <code>_scope</code> is defined in the Parsing Rule), see [Scenario 3: Supported fields don't provide the necessary segmentation] in Scenarios related to Datasets Rows scoping.</p><p><strong>Comparison operators</strong></p><p>The following comparison operators are supported:</p><ul><li>Exact matches (<code>=</code>, <code>!=</code>)</li><li>Comparing numerical values (<code>></code>, <code><</code>, <code>>=</code>, <code><=</code>)</li><li>Checking membership in lists (<code>in</code>)</li><li>Querying arrays (<code>array_contains</code>)</li><li>Partial matches (<code>contains</code>, <code>starts_with</code>): Using this operator has additional performance overhead, and we recommend avoiding its use.</li></ul><p>If you only want a user to be able to access rows in the <code>pan_dds_raw</code> dataset, when the <code>_collector_name</code> is <code>bu2_collector</code> , you'd have to define the <code>filter</code> in the query box as:</p><pre><code>_collector_name = “bu2_collector”| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |</code></pre></li></ol></li></ol></td></tr><tr><td></td><td></td></tr><tr><td></td><td></td></tr><tr><td><p><br></p><ul><li>(Optional) Set the Time frame for the query. The default is Last 1 day.</li><li>(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.</li><li><p>When you are finished, click Done.</p><p>The Scope field for the dataset that you added the filter on is updated with the query.</p><p>In the above example, the Scope field displays <code>_collector_name = “bu2_collector”</code>.</p></li></ul></td><td></td></tr></tbody></table>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.
| Datasets Rows | <p>Configure a <code>filter</code> to define the specific subset of rows a user is allowed to access in each raw dataset. A raw dataset is every dataset where Palo Alto Networks data is ingested out-of-the-box or third-party data is ingested using a configured dedicated collector, also called a data source. This filter configuration does not impact the visibility of cases and issues.</p><p>Follow these steps to configure a <code>filter</code>.</p><ol><li><p>For datasets where no <code>filter</code> is defined, determine how to set the When no filter is defined option as either:</p><ul><li>No rows are accessible (default): Without a configured <code>filter</code>, no rows are accessible. Users can query the datasets in Cortex Query Language (XQL) as they have access, but the results will be empty.</li><li>All rows are accessible: Without a configured <code>filter</code>, all rows are accessible. Users can query the datasets in Cortex Query Language (XQL) as they have access, and view all results.</li></ul><p>When defining a filter for row-level scoping on raw datasets, queries based on the Cortex Data Model (XDM) are not supported. XDM queries return specific rows only when All rows are accessible is selected and no filter is defined in the Datasets Rows scoping area. Otherwise, no rows are returned.</p></li><li><p>Define any filters for the applicable datasets listed in the table:</p><ol><li>Scroll down the list of datasets to the dataset you want to apply a <code>filter</code> on, and click the Edit Scope icon.</li><li><p>In the Define what rows are accessible window, continue to write the query for the <code>filter</code> in the query box (where the syntax is a limited subset of XQL) to limit the data rows for the selected dataset according to the access permissions you want the user to have. The beginning of the query is already defined before the query box, and there is no need to include this in your query.</p><p>For optimal performance, we recommend using a single field in the <code>filter</code> definition and simple comparison operators.</p><p>Supported syntax</p><p><strong>Fields</strong></p><p>You can define the rest of the <code>filter</code> in the query box, where only the following system fields are supported: <code>_broker_device_id</code>, <code>_broker_device_ip</code>, <code>_broker_device_name</code>, <code>_collector_id</code>, <code>_collector_ip</code>, <code>_collector_name</code>, <code>_collector_type</code>, <code>_device_id</code>, <code>_final_reporting_device_ip</code>, <code>_final_reporting_device_name</code>, <code>_log_type</code>, <code>_product</code>, <code>_scope</code>, <code>_reporting_device_ip</code>, <code>_reporting_device_name</code>, and <code>_vendor</code>.</p><p>For more information on these fields, see the table that describes all the fields in the <code>metrics_source</code> dataset and <code>metrics_view</code> preset in <a href="../../../configure-cortex-xsiam/cortex-xsiam-data-sources/administration-and-troubleshooting/overview-of-data-ingestion-metrics">Overview of data ingestion metrics</a>. For more information on the <code>_scope</code> field (relevant when <code>_scope</code> is defined in the Parsing Rule), see [Scenario 3: Supported fields don't provide the necessary segmentation] in Scenarios related to Datasets Rows scoping.</p><p><strong>Comparison operators</strong></p><p>The following comparison operators are supported:</p><ul><li>Exact matches (<code>=</code>, <code>!=</code>)</li><li>Comparing numerical values (<code>></code>, <code><</code>, <code>>=</code>, <code><=</code>)</li><li>Checking membership in lists (<code>in</code>)</li><li>Querying arrays (<code>array_contains</code>)</li><li>Partial matches (<code>contains</code>, <code>starts_with</code>): Using this operator has additional performance overhead, and we recommend avoiding its use.</li></ul><p>If you only want a user to be able to access rows in the <code>pan_dds_raw</code> dataset, when the <code>_collector_name</code> is <code>bu2_collector</code> , you'd have to define the <code>filter</code> in the query box as:</p><pre><code>_collector_name = “bu2_collector”</code></pre></li></ol></li></ol> || | || | |- (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.
In the above example, the Scope field displays
_collector_name = “bu2_collector”.
<div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><h3>Important</h3><p>By default, <strong>Enable Scope Based Access Control</strong> is disabled in Settings → Configurations → General → <strong>Server Settings</strong>, and granular scoping is not enforced. Before enabling SBAC, we recommend that an administrator or a user with <strong>Access Management</strong> 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 <a href="../../post-deployment/manage-user-roles-and-access-management/manage-user-scope">Manage user scope</a>.</p></div><div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><h3>Important</h3><p>By default, <strong>Enable Scope Based Access Control</strong> is disabled in Settings → Configurations → General → <strong>Server Settings</strong>, and granular scoping is not enforced. Before enabling SBAC, we recommend that an administrator or a user with <strong>Access Management</strong> 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 <a href="../../post-deployment/manage-user-roles-and-access-management/manage-user-scope">Manage user scope</a>.</p></div>8. Click Save.8. Click Save.Perform additional tasksPerform additional tasksFor 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.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.Show markdown source
@@ -26,25 +26,17 @@ Cortex XSIAM provides predefined built-in user roles that provide specific acces 2. Under **Components**, expand each list to view the permissionsSetting 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](../../../post-deployment/manage-user-roles-and-access-management#UUID-751d26ed-9390-dddd-d4f6-bb1f20db3a1d). 7. (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 table explains the options available to configure: <div data-gb-custom-block data-tag="hint" data-style="warning" class="hint hint-warning"><p>Before configuring, ensure that you review <strong>Understand scoping</strong> in the <a href="../../../post-deployment/manage-user-roles-and-access-management#UUID-071cdbb6-6c6a-6afe-3a67-1fa79991a0a8">Manage user scope</a> section.</p></div> - | Scoping Area | Granular Scoping Configurations | - | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | - | Assets | <p>Set the <strong>Scope</strong> by selecting one of the following:</p><ul><li><strong>No assets</strong>: No asset is accessible.</li><li><strong>All assets</strong>: Defines access to all assets.</li><li><strong>Select asset groups</strong>: 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 <strong>Select asset groups</strong>, 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 <a href="../../../post-deployment/manage-user-roles-and-access-management/manage-user-scope#UUID-071cdbb6-6c6a-6afe-3a67-1fa79991a0a8_section-idm235041053079477">Manage user scope</a> (under <strong>Understand scoping</strong> → <strong>Scoping Areas</strong> → <strong>Assets</strong>).</li></ul><p>The scoping of assets also affects the scoping of cases, issues, and findings.</p><div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><p><strong>Note</strong></p><p>Visibility of Security domain Issues that refer to assets with agents is controlled by the <strong>Endpoints</strong> scoping configuration.</p></div> | - | Cases and Issues | <p>Set the <strong>Scope</strong> by selecting one of the following:</p><ul><li><strong>No cases and issues</strong>: Defines access to no cases and issues.</li><li><strong>All cases and issues</strong>: Defines access to all cases and issues. Users can view cases or issues referencing assets within their scope. Use the <strong>Assets</strong> section to define which assets are in scope.</li><li><p><strong>Select domains</strong>: Defines access to the domains selected to view their related cases and issues. Under <strong>Select domains</strong>, define the specific domains that you want to grant access.</p><p>Users can only view cases or issues referencing assets and endpoints within their scope. Use the <strong>Assets</strong> section to define which assets are in scope.</p></li></ul><p>When selecting <strong>All cases and issues</strong> or <strong>Select domains</strong>, you can separately configure access to issues and cases that lack an asset reference or where the referenced asset is not in <strong>All Assets</strong> and <strong>All Endpoints</strong> inventories. To provide access, select the <strong>Allow access to cases and issues that are not referencing known assets or endpoints</strong> checkbox. Once selected, you can specifically control which users have access to issues and cases that lack <strong>Affected Assets</strong> (as seen in the issue’s panel) and <strong>Assets</strong> (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 <strong>User Risk View</strong>, which differs from the standard inventories panels. In the <strong>Issues</strong> and <strong>Cases</strong> tables, such items can be identified by empty values in the following columns: Asset IDs, Target Agent Identifier, and Source Agent Identifier.</p> | - | Endpoints | <p>Set the <strong>Scope</strong> by selecting one of the following:</p><ul><li><strong>No endpoints</strong>: Defines access to no endpoints with no ability to view their related agent management and enterprise policies.</li><li><strong>All endpoints</strong>: 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 <strong>Security</strong> domain <strong>Cases and Issues</strong>, but will not affect asset visibility.</li><li><strong>Select specific (at least one required)</strong>: Defines specific access to all endpoint groups by selecting <strong>Endpoint Groups</strong> or all endpoint tags by selecting <strong>Endpoint Tags</strong> to view their related agent management and enterprise policies. This configuration can impact the visibility of related <strong>Security</strong> domain <strong>Cases and Issues</strong>, but will not affect asset visibility.</li></ul> | - | Datasets Rows | <p>Configure a <code>filter</code> to define the specific subset of rows a user is allowed to access in each raw dataset. A raw dataset is every dataset where Palo Alto Networks data is ingested out-of-the-box or third-party data is ingested using a configured dedicated collector, also called a data source. This filter configuration does not impact the visibility of cases and issues.</p><p>Follow these steps to configure a <code>filter</code>.</p><ol><li><p>For datasets where no <code>filter</code> is defined, determine how to set the When no filter is defined option as either:</p><ul><li>No rows are accessible (default): Without a configured <code>filter</code>, no rows are accessible. Users can query the datasets in Cortex Query Language (XQL) as they have access, but the results will be empty.</li><li>All rows are accessible: Without a configured <code>filter</code>, all rows are accessible. Users can query the datasets in Cortex Query Language (XQL) as they have access, and view all results.</li></ul><p>When defining a filter for row-level scoping on raw datasets, queries based on the Cortex Data Model (XDM) are not supported. XDM queries return specific rows only when All rows are accessible is selected and no filter is defined in the Datasets Rows scoping area. Otherwise, no rows are returned.</p></li><li><p>Define any filters for the applicable datasets listed in the table:</p><ol><li>Scroll down the list of datasets to the dataset you want to apply a <code>filter</code> on, and click the Edit Scope icon.</li><li><p>In the Define what rows are accessible window, continue to write the query for the <code>filter</code> in the query box (where the syntax is a limited subset of XQL) to limit the data rows for the selected dataset according to the access permissions you want the user to have. The beginning of the query is already defined before the query box, and there is no need to include this in your query.</p><p>For optimal performance, we recommend using a single field in the <code>filter</code> definition and simple comparison operators.</p><p>Supported syntax</p><p><strong>Fields</strong></p><p>You can define the rest of the <code>filter</code> in the query box, where only the following system fields are supported: <code>_broker_device_id</code>, <code>_broker_device_ip</code>, <code>_broker_device_name</code>, <code>_collector_id</code>, <code>_collector_ip</code>, <code>_collector_name</code>, <code>_collector_type</code>, <code>_device_id</code>, <code>_final_reporting_device_ip</code>, <code>_final_reporting_device_name</code>, <code>_log_type</code>, <code>_product</code>, <code>_scope</code>, <code>_reporting_device_ip</code>, <code>_reporting_device_name</code>, and <code>_vendor</code>.</p><p>For more information on these fields, see the table that describes all the fields in the <code>metrics_source</code> dataset and <code>metrics_view</code> preset in <a href="../../../configure-cortex-xsiam/cortex-xsiam-data-sources/administration-and-troubleshooting/overview-of-data-ingestion-metrics">Overview of data ingestion metrics</a>. For more information on the <code>_scope</code> field (relevant when <code>_scope</code> is defined in the Parsing Rule), see [Scenario 3: Supported fields don't provide the necessary segmentation] in Scenarios related to Datasets Rows scoping.</p><p><strong>Comparison operators</strong></p><p>The following comparison operators are supported:</p><ul><li>Exact matches (<code>=</code>, <code>!=</code>)</li><li>Comparing numerical values (<code>></code>, <code><</code>, <code>>=</code>, <code><=</code>)</li><li>Checking membership in lists (<code>in</code>)</li><li>Querying arrays (<code>array_contains</code>)</li><li>Partial matches (<code>contains</code>, <code>starts_with</code>): Using this operator has additional performance overhead, and we recommend avoiding its use.</li></ul><p>If you only want a user to be able to access rows in the <code>pan_dds_raw</code> dataset, when the <code>_collector_name</code> is <code>bu2_collector</code> , you'd have to define the <code>filter</code> in the query box as:</p><pre><code>_collector_name = “bu2_collector” - </code></pre></li></ol></li></ol> | - | | | - | | | - | <p><br></p><ul><li>(Optional) Set the Time frame for the query. The default is Last 1 day.</li><li>(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.</li><li><p>When you are finished, click Done.</p><p>The Scope field for the dataset that you added the filter on is updated with the query.</p><p>In the above example, the Scope field displays <code>_collector_name = “bu2_collector”</code>.</p></li></ul> | | + <table><thead><tr><th>Scoping Area</th><th>Granular Scoping Configurations</th></tr></thead><tbody><tr><td>Assets</td><td><p>Set the <strong>Scope</strong> by selecting one of the following:</p><ul><li><strong>No assets</strong>: No asset is accessible.</li><li><strong>All assets</strong>: Defines access to all assets.</li><li><strong>Select asset groups</strong>: 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 <strong>Select asset groups</strong>, 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 <a href="../../../post-deployment/manage-user-roles-and-access-management/manage-user-scope#UUID-071cdbb6-6c6a-6afe-3a67-1fa79991a0a8_section-idm235041053079477">Manage user scope</a> (under <strong>Understand scoping</strong> → <strong>Scoping Areas</strong> → <strong>Assets</strong>).</li></ul><p>The scoping of assets also affects the scoping of cases, issues, and findings.</p><div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><p><strong>Note</strong></p><p>Visibility of Security domain Issues that refer to assets with agents is controlled by the <strong>Endpoints</strong> scoping configuration.</p></div></td></tr><tr><td>Cases and Issues</td><td><p>Set the <strong>Scope</strong> by selecting one of the following:</p><ul><li><strong>No cases and issues</strong>: Defines access to no cases and issues.</li><li><strong>All cases and issues</strong>: Defines access to all cases and issues. Users can view cases or issues referencing assets within their scope. Use the <strong>Assets</strong> section to define which assets are in scope.</li><li><p><strong>Select domains</strong>: Defines access to the domains selected to view their related cases and issues. Under <strong>Select domains</strong>, define the specific domains that you want to grant access.</p><p>Users can only view cases or issues referencing assets and endpoints within their scope. Use the <strong>Assets</strong> section to define which assets are in scope.</p></li></ul><p>When selecting <strong>All cases and issues</strong> or <strong>Select domains</strong>, you can separately configure access to issues and cases that lack an asset reference or where the referenced asset is not in <strong>All Assets</strong> and <strong>All Endpoints</strong> inventories. To provide access, select the <strong>Allow access to cases and issues that are not referencing known assets or endpoints</strong> checkbox. Once selected, you can specifically control which users have access to issues and cases that lack <strong>Affected Assets</strong> (as seen in the issue’s panel) and <strong>Assets</strong> (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 <strong>User Risk View</strong>, which differs from the standard inventories panels. In the <strong>Issues</strong> and <strong>Cases</strong> tables, such items can be identified by empty values in the following columns: Asset IDs, Target Agent Identifier, and Source Agent Identifier.</p></td></tr><tr><td>Endpoints</td><td><p>Set the <strong>Scope</strong> by selecting one of the following:</p><ul><li><strong>No endpoints</strong>: Defines access to no endpoints with no ability to view their related agent management and enterprise policies.</li><li><strong>All endpoints</strong>: 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 <strong>Security</strong> domain <strong>Cases and Issues</strong>, but will not affect asset visibility.</li><li><strong>Select specific (at least one required)</strong>: Defines specific access to all endpoint groups by selecting <strong>Endpoint Groups</strong> or all endpoint tags by selecting <strong>Endpoint Tags</strong> to view their related agent management and enterprise policies. This configuration can impact the visibility of related <strong>Security</strong> domain <strong>Cases and Issues</strong>, but will not affect asset visibility.</li></ul></td></tr><tr><td>Datasets Rows</td><td><p>Configure a <code>filter</code> to define the specific subset of rows a user is allowed to access in each raw dataset. A raw dataset is every dataset where Palo Alto Networks data is ingested out-of-the-box or third-party data is ingested using a configured dedicated collector, also called a data source. This filter configuration does not impact the visibility of cases and issues.</p><p>Follow these steps to configure a <code>filter</code>.</p><ol><li><p>For datasets where no <code>filter</code> is defined, determine how to set the When no filter is defined option as either:</p><ul><li>No rows are accessible (default): Without a configured <code>filter</code>, no rows are accessible. Users can query the datasets in Cortex Query Language (XQL) as they have access, but the results will be empty.</li><li>All rows are accessible: Without a configured <code>filter</code>, all rows are accessible. Users can query the datasets in Cortex Query Language (XQL) as they have access, and view all results.</li></ul><p>When defining a filter for row-level scoping on raw datasets, queries based on the Cortex Data Model (XDM) are not supported. XDM queries return specific rows only when All rows are accessible is selected and no filter is defined in the Datasets Rows scoping area. Otherwise, no rows are returned.</p></li><li><p>Define any filters for the applicable datasets listed in the table:</p><ol><li>Scroll down the list of datasets to the dataset you want to apply a <code>filter</code> on, and click the Edit Scope icon.</li><li><p>In the Define what rows are accessible window, continue to write the query for the <code>filter</code> in the query box (where the syntax is a limited subset of XQL) to limit the data rows for the selected dataset according to the access permissions you want the user to have. The beginning of the query is already defined before the query box, and there is no need to include this in your query.</p><p>For optimal performance, we recommend using a single field in the <code>filter</code> definition and simple comparison operators.</p><p>Supported syntax</p><p><strong>Fields</strong></p><p>You can define the rest of the <code>filter</code> in the query box, where only the following system fields are supported: <code>_broker_device_id</code>, <code>_broker_device_ip</code>, <code>_broker_device_name</code>, <code>_collector_id</code>, <code>_collector_ip</code>, <code>_collector_name</code>, <code>_collector_type</code>, <code>_device_id</code>, <code>_final_reporting_device_ip</code>, <code>_final_reporting_device_name</code>, <code>_log_type</code>, <code>_product</code>, <code>_scope</code>, <code>_reporting_device_ip</code>, <code>_reporting_device_name</code>, and <code>_vendor</code>.</p><p>For more information on these fields, see the table that describes all the fields in the <code>metrics_source</code> dataset and <code>metrics_view</code> preset in <a href="../../../configure-cortex-xsiam/cortex-xsiam-data-sources/administration-and-troubleshooting/overview-of-data-ingestion-metrics">Overview of data ingestion metrics</a>. For more information on the <code>_scope</code> field (relevant when <code>_scope</code> is defined in the Parsing Rule), see [Scenario 3: Supported fields don't provide the necessary segmentation] in Scenarios related to Datasets Rows scoping.</p><p><strong>Comparison operators</strong></p><p>The following comparison operators are supported:</p><ul><li>Exact matches (<code>=</code>, <code>!=</code>)</li><li>Comparing numerical values (<code>></code>, <code><</code>, <code>>=</code>, <code><=</code>)</li><li>Checking membership in lists (<code>in</code>)</li><li>Querying arrays (<code>array_contains</code>)</li><li>Partial matches (<code>contains</code>, <code>starts_with</code>): Using this operator has additional performance overhead, and we recommend avoiding its use.</li></ul><p>If you only want a user to be able to access rows in the <code>pan_dds_raw</code> dataset, when the <code>_collector_name</code> is <code>bu2_collector</code> , you'd have to define the <code>filter</code> in the query box as:</p><pre><code>_collector_name = “bu2_collector” + </code></pre></li></ol></li></ol></td></tr><tr><td></td><td></td></tr><tr><td></td><td></td></tr><tr><td><p><br></p><ul><li>(Optional) Set the Time frame for the query. The default is Last 1 day.</li><li>(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.</li><li><p>When you are finished, click Done.</p><p>The Scope field for the dataset that you added the filter on is updated with the query.</p><p>In the above example, the Scope field displays <code>_collector_name = “bu2_collector”</code>.</p></li></ul></td><td></td></tr></tbody></table> <div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><h3>Important</h3><p>By default, <strong>Enable Scope Based Access Control</strong> is disabled in Settings → Configurations → General → <strong>Server Settings</strong>, and granular scoping is not enforced. Before enabling SBAC, we recommend that an administrator or a user with <strong>Access Management</strong> 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 <a href="../../post-deployment/manage-user-roles-and-access-management/manage-user-scope">Manage user scope</a>.</p></div> 8. Click Save. **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](../../../post-deployment/manage-user-roles-and-access-management#UUID-a112c99e-112f-ab8a-e5ed-e31445dee8fe). -
▸ ▾ XDM fields for mapping authentication events modified +6 −5 xdm.auth.service adds a Universal value for non-IdP sources and forbids naming a protocol such as Kerberos, SSH or Login in the field.
xsiam/reference-and-developer-docs/reference/xdm-fields-for-mapping-authentication-eventsRead it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗
Before After@@ -3,17 +3,17 @@ description: >-Learn more about the Cortex Data Model (XDM) fields to map for authenticationLearn more about the Cortex Data Model (XDM) fields to map for authenticationevents.events.------# XDM fields for mapping authentication events# XDM fields for mapping authentication eventsThis section provides a comprehensive guide to mapping authentication events from various customer log sources to the XDM (Cortex Data Model) schema. Each relevant XDM field is detailed, including whether the field is mandatory or optional, the corresponding Authentication Story field , data type, and purpose, ensuring consistent data normalization essential for robust security analysis and threat detection.This section provides a comprehensive guide to mapping authentication events from various customer log sources to the XDM (Cortex Data Model) schema. Each relevant XDM field is detailed, including whether the field is mandatory or optional, the corresponding Authentication Story field , data type, and purpose, ensuring consistent data normalization essential for robust security analysis and threat detection.The mandatory fields to map are listed below with an asterisk (*) beside them as these fields must be mapped to automatically create authentication stories for XDM identity data.The fields that are mandatory to map are listed below with an asterisk (*) beside them as these fields must be mapped to automatically create authentication stories for XDM identity data.hint infohint info### Note### NoteFor more information on the entire Cortex Data model (XDM) schema, see Cortex XSIAM Data Model Schema.For more information on the entire Cortex Data model (XDM) schema, see Cortex XSIAM Data Model Schema.endhintendhint## Mandatory fields## Mandatory fields@@ -184,34 +184,35 @@ xdm.event.operation =###- xdm.auth.service*
###- xdm.auth.service*
Authentication Story Field:auth_serviceAuthentication Story Field:auth_serviceType: stringType: stringRequirement: MandatoryRequirement: MandatoryDescription: This field defines the role the system played in the authentication flow, such as identity provider or relying party, and should reflect event-specific context.Description: This field defines the role the system played in the authentication flow for this specific record.Supported values:Supported values:•״SP״(Service Provider): The system initiating the authentication request.• IDP: Use when the system validates the credential (such as Okta, Entra ID, Domain Controller).•״IDP״(Identity Provider): The system that validates the user authentication.• SP: Use when the system initiates the request and relies on another to validate (such as a relying-party app consuming SSO).• Universal: Use when the source is NOT a known IdP provider (such as local accounts, TACACS+, RADIUS, device SSH).Data Model Rule example for Okta:Data Model Rule example for Okta:```programlisting```programlistingif(eventType = "user.authentication.auth_via_AD_agent", "IDP",if(eventType = "user.authentication.auth_via_AD_agent", "IDP",eventType = "user.authentication.auth_via_radius", "IDP", ..., eventType = "user.authentication.sso", "SP", null)eventType = "user.authentication.auth_via_radius", "IDP", ..., eventType = "user.authentication.sso", "SP", null)``````hint infohint info### Note### NoteMapping should be done per event type. The same system could be an IDP in one event and an SP in another.Mapping should be done per event type. The same system could be an IDP in one event and an SP in another. NEVER use a service or protocol name like "Kerberos", "SSH", or "Login" in this field. Mapping should be done per event type. The same system could be an IDP in one event and an SP in another.endhintendhint###- xdm.event.outcome*
###- xdm.event.outcome*
Authentication Story Field:auth_outcomeAuthentication Story Field:auth_outcomeType: string (ENUM)Type: string (ENUM)Show markdown source
@@ -3,17 +3,17 @@ description: >- Learn more about the Cortex Data Model (XDM) fields to map for authentication events. --- # XDM fields for mapping authentication events This section provides a comprehensive guide to mapping authentication events from various customer log sources to the XDM (Cortex Data Model) schema. Each relevant XDM field is detailed, including whether the field is mandatory or optional, the corresponding **Authentication Story** field , data type, and purpose, ensuring consistent data normalization essential for robust security analysis and threat detection. -The mandatory fields to map are listed below with an asterisk (\*) beside them as these fields must be mapped to automatically create authentication stories for XDM identity data. +The fields that are mandatory to map are listed below with an asterisk (\*) beside them as these fields must be mapped to automatically create authentication stories for XDM identity data. {% hint style="info" %} ### Note For more information on the entire Cortex Data model (XDM) schema, see [Cortex XSIAM Data Model Schema](https://app.gitbook.com/s/HVBaxKOW1b6qcIQ6iMBh/). {% endhint %} ## Mandatory fields @@ -184,34 +184,35 @@ xdm.event.operation = ### 10. xdm.auth.service\* **Authentication Story Field**: `auth_service` **Type**: string **Requirement**: Mandatory -**Description**: This field defines the role the system played in the authentication flow, such as identity provider or relying party, and should reflect event-specific context. +**Description**: This field defines the **role** the system played in the authentication flow for this specific record. **Supported values**: -* `״SP״` (Service Provider): The system initiating the authentication request. -* `״IDP״` (Identity Provider): The system that validates the user authentication. +* **IDP**: Use when the system validates the credential (such as Okta, Entra ID, Domain Controller). +* **SP**: Use when the system initiates the request and relies on another to validate (such as a relying-party app consuming SSO). +* **Universal**: Use when the source is NOT a known IdP provider (such as local accounts, TACACS+, RADIUS, device SSH). **Data Model Rule example for Okta**: ```programlisting if(eventType = "user.authentication.auth_via_AD_agent", "IDP", eventType = "user.authentication.auth_via_radius", "IDP", ..., eventType = "user.authentication.sso", "SP", null) ``` {% hint style="info" %} ### Note -Mapping should be done per event type. The same system could be an IDP in one event and an SP in another. +Mapping should be done per event type. The same system could be an IDP in one event and an SP in another. NEVER use a service or protocol name like "Kerberos", "SSH", or "Login" in this field. Mapping should be done per event type. The same system could be an IDP in one event and an SP in another. {% endhint %} ### 11. xdm.event.outcome\* **Authentication Story Field**: `auth_outcome` **Type**: string (ENUM)