5/8/24, 9:18 AM PDF Export

Cortex XSIAM Administrator Guide

Confidential - Copyright © Palo Alto Networks

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 1/1003
5/8/24, 9:18 AM PDF Export

1. Overview
1.1. Architecture

1.2. Concepts

1.3. Use cases

1.4. Cortex XSIAM License

1.4.1. License Retention
1.4.2. License Allocation
1.4.3. License Expiration
1.4.4. License Monitoring

2. Get Started
2.1. Setup Overview

2.2. Plan Your Deployment

2.2.1. Cortex XSIAM supported regions

2.3. Activate

2.4. Deploy your Network Devices

2.5. Manage User Roles

2.5.1. Permission Management
2.5.2. Access Management
2.5.2.1. Manage Users
2.5.2.2. Manage Roles
2.5.2.3. Manage User Groups
2.5.2.4. Authentication Settings
2.5.2.5. Manage Single Sign-On
2.5.2.5.1. Configure Single Sign-On Using SAML 2.0
2.5.2.5.2. Set up Azure AD as the Identity Provider Using SAML 2.0
2.5.2.5.3. Set up Okta as the Identity Provider Using SAML 2.0
2.5.2.5.4. Troubleshoot SAML 2.0 Issues
2.5.2.5.5. Use Multiple SAML 2.0 Providers

2.5.3. Predefined User Roles

2.5.4. Manage User Scope

2.6. Configure a Mail Sender Integration

2.7. Set Up Cloud Identity Engine

2.8. Set up Endpoint Protection

2.8.1. Plan Your Agent Deployment
2.8.2. Setup Access Services
2.8.2.1. Resources Required to Enable Access

2.9. Set up Network Analysis

2.10. Set up your Data Sources and Alert Sensors

2.10.1. Integrate External Threat Intelligence Services
2.10.2. Set up Your Environment

2.11. Set up Outbound Integration

2.12. Use the Interface

2.12.1. Manage Tables

2.13. In-product Support Case Creation

3. Endpoint Security
3.1. Endpoint Security Concepts
3.1.1. Endpoint Protection
3.1.2. File Analysis and Protection Flow
3.1.3. Endpoint Protection Capabilities
3.1.4. Endpoint Protection Modules

3.2. Communication

3.3. Manage Agents

3.3.1. Create an Agent Installation Package
3.3.2. Set an Application Proxy for Cortex XDR Agents
3.3.3. Move Agents Between Managing Servers
3.3.4. Upgrade Cortex XDR Agents
3.3.5. Set a Cortex XDR Agent Critical Environment Version
3.3.6. Clear Agent Database
3.3.7. Delete Cortex XDR Agents
3.3.8. Uninstall the Cortex XDR Agent
3.3.9. Set an Alias for an Endpoint
3.3.10. Manage Endpoint Tags
3.3.11. Manage Agent Tokens
3.3.11.1. Retrieve Support File Password

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 2/1003
5/8/24, 9:18 AM PDF Export

3.3.12. Send Push Notifications to iOS

3.3.13. Restart Agent

3.4. Define Endpoint Groups

3.5. About Content Updates

3.6. Endpoint Security Profiles

3.6.1. Add a New Exploit Security Profile
3.6.1.1. Processes Protected by Exploit Security Policy

3.6.2. Add a New Malware Security Profile

3.6.2.1. WildFire Analysis Concepts

3.6.3. Add a New Restrictions Security Profile

3.6.4. Manage Endpoint Security Profiles

3.7. Customizable Agent Settings

3.7.1. Add a New Agent Settings Profile
3.7.2. Configure Global Agent Settings
3.7.3. Endpoint Data Collection

3.8. Apply Security Profiles to Endpoints

3.9. Exception Configuration

3.9.1. Alert Exclusions
3.9.1.1. Add an Alert Exclusion Rule

3.9.2. Add an IOC or BIOC Rule Exception

3.9.3. Add a Disable Prevention Rule
3.9.4. Add a Support Exception Rule
3.9.5. Add a Legacy Exception Rule
3.9.5.1. Add a New Exceptions Security Profile
3.9.5.2. Add a Global Endpoint Policy Exception

3.10. Hardened Endpoint Security

3.10.1. Device Control
3.10.2. Host Firewall
3.10.2.1. Host Firewall for Windows
3.10.2.2. Host Firewall for macOS

3.10.3. Disk Encryption

3.10.4. Host Inventory
3.10.5. Vulnerability Assessment

3.11. Cortex XDR Agent for Cloud

3.11.1. Pairing Prisma Cloud Compute with Cortex XSIAM

4. Investigation and Response

4.1. Rules
4.1.1. Working with BIOCs
4.1.1.1. BIOC Rule Details
4.1.1.2. Create a BIOC Rule
4.1.1.3. Manage Global BIOC Rules

4.1.2. Working with IOCs

4.1.2.1. IOC Rule Details
4.1.2.2. Create an IOC Rule

4.1.3. Working with Correlation Rules

4.1.3.1. Correlation Rule Details
4.1.3.2. Create a Correlation Rule
4.1.3.3. Monitor correlation rules

4.1.4. Attack Surface Rules

4.1.5. Manage Existing Indicators

4.2. Investigate Incidents

4.2.1. Incidents
4.2.1.1. Incident and alert domains
4.2.1.2. Create an incident domain

4.2.2. Create an Incident

4.2.3. External Integrations
4.2.4. Manage Incident Starring
4.2.5. Manage Incident Scoring
4.2.6. Featured Fields
4.2.7. Triage Incidents
4.2.8. Manage Incidents
4.2.8.1. Resolution Reasons for Incidents and Alerts
4.2.8.2. Adding Custom Incident Statuses and Resolution Reasons

4.3. Search Queries

4.3.1. XQL Search
4.3.1.1. Useful XQL User Interface Features
4.3.1.2. XQL Query Best Practices
4.3.1.3. Expected Results when Querying Fields
4.3.1.4. Create an XQL Query
4.3.1.5. View XQL Query Results
4.3.1.6. Translate to XQL
4.3.1.7. Visualize Query Results

4.3.2. About the Query Builder

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 3/1003
5/8/24, 9:18 AM PDF Export

4.3.2.1. Query Builder templates

4.3.2.1.1. Get started with Query Builder templates
4.3.2.1.2. Considerations for using Query Builder templates
4.3.2.1.3. Create a query from a template
4.3.2.1.4. Run a free text query
4.3.2.1.5. Query Builder template examples
4.3.2.2. The Legacy Query Builder
4.3.2.2.1. Create a File Query
4.3.2.2.2. Create a Process Query
4.3.2.2.3. Create a Network Query
4.3.2.2.4. Create an Image Load Query
4.3.2.2.5. Create a Registry Query
4.3.2.2.6. Create an Event Log Query
4.3.2.2.7. Create a Network Connections Query
4.3.2.2.8. Create an Authentication Query
4.3.2.2.9. Query Across All Entities

4.3.3. Edit and rerun queries

4.3.3.1. Query Center reference information

4.3.4. Manage scheduled queries

4.3.4.1. Scheduled Queries reference information

4.3.5. Manage Your Personal Query Library

4.3.6. Quick Launcher
4.3.7. Research a Known Threat

4.4. Investigate Artifacts and Assets

4.4.1. Investigate an IP Address
4.4.2. Investigate an Asset
4.4.3. Investigate a Host
4.4.4. Investigate a File and Process Hash
4.4.5. Investigate a User

4.5. Investigate Alerts

4.5.1. Alerts
4.5.2. Alert Investigation
4.5.2.1. Context Data Management
4.5.2.2. Use Context Data in a Jira Ticketing System
4.5.2.3. Update Incident Fields From an Alert
4.5.2.4. Alert Automation
4.5.2.4.1. Playbook triggers
4.5.2.4.2. Create a Playbook Trigger
4.5.2.4.3. Add a Recommended Playbook Trigger
4.5.2.5. Run Indicator Extraction in the CLI
4.5.2.6. Alert Investigation Customization
4.5.2.6.1. Alert Fields
4.5.2.6.1.1. Alert Field Types
4.5.2.6.1.2. Create Custom Alert Fields
4.5.2.6.1.2.1. Create a Grid Field
4.5.2.6.1.2.2. Timer fields in Cortex XSIAM
4.5.2.6.1.2.2.1. Configure timer fields
4.5.2.6.1.2.2.2. Configure a playbook to run timers
4.5.2.6.1.2.2.3. Automate changes to alert fields using timer scripts
4.5.2.6.1.2.2.4. Use timer field commands manually in the CLI
4.5.2.6.2. Alert Layouts
4.5.2.6.2.1. Create Custom Alert Layouts
4.5.2.6.2.1.1. Add a Custom Widget to an Alert Layout
4.5.2.6.2.2. Create Rules for Alert Layouts

4.5.3. Triage Alerts

4.5.4. Manage Alerts
4.5.5. Alert Panel View
4.5.6. Causality View
4.5.7. Network Causality View
4.5.8. Cloud Causality View
4.5.9. SaaS Causality View
4.5.10. Analytics Alert View
4.5.11. Timeline View

4.6. Investigate Endpoints

4.6.1. Action Center
4.6.1.1. Manage Endpoint Actions

4.6.2. Endpoints Table

4.6.3. Retrieve Files from an Endpoint
4.6.4. Retrieve Support Logs from an Endpoint
4.6.5. Scan an Endpoint for Malware

4.7. Investigate Files

4.7.1. Manage File Execution
4.7.2. Manage Quarantined Files
4.7.3. Review WildFire Analysis Details
4.7.4. Import File Hash Exceptions

4.8. Forensic investigations

4.8.1. Manage an investigation
4.8.1.1. Create a new investigation
4.8.1.2. Edit an investigation
4.8.1.3. Close an investigation
4.8.1.4. User permissions

4.8.2. Data collection

4.8.2.1. Hunting
4.8.2.1.1. Create a hunt
4.8.2.1.2. Hunt results
4.8.2.1.3. Hunt status

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 4/1003
5/8/24, 9:18 AM PDF Export

4.8.2.2. Triage
4.8.2.2.1. Create triage
4.8.2.2.2. Upload an offline triage package
4.8.2.2.3. Triage results
4.8.2.2.4. Triage status

4.8.3. Analysis and documentation

4.8.3.1. Review alerts
4.8.3.2. Investigation timeline
4.8.3.3. Key assets & artifacts

4.8.4. Export

4.9. Response Actions

4.9.1. Initiate a Live Terminal Session
4.9.2. Isolate an Endpoint
4.9.3. Pause Endpoint Protection
4.9.4. Remediate Changes from Malicious Activity
4.9.5. Run Scripts on an Endpoint
4.9.6. Search and Destroy Malicious Files
4.9.7. Manage External Dynamic Lists
4.9.8. Collect a Memory Image

4.10. Playbooks
4.10.1. Playbook development
4.10.2. Search for a playbook
4.10.3. Manage playbook settings
4.10.3.1. Obtain playbook metadata

4.10.4. Version control

4.10.5. Playbook tasks
4.10.5.1. Create a section header
4.10.5.2. Playbook task fields
4.10.5.3. Create a conditional task
4.10.5.4. Communication tasks
4.10.5.4.1. Create an Ask task
4.10.5.4.1.1. Ask task examples
4.10.5.4.2. Create a data collection task
4.10.5.4.2.1. Data Collection Task Examples
4.10.5.4.3. Create Communication Task Authentication
4.10.5.5. Add ad-hoc tasks to a Work Plan

4.10.6. Playbook inputs and outputs

4.10.6.1. Task cheat sheet

4.10.7. Indicator extraction

4.10.7.1. Create indicator extract rules for a playbook task

4.10.8. Extend context

4.10.8.1. Extend context in a playbook task
4.10.8.2. Extend context using the command line

4.10.9. Filters and transformers

4.10.9.1. Create filters and transformers in a playbook
4.10.9.2. Create a filter example
4.10.9.3. Filter operators
4.10.9.3.1. Built-in Filters
4.10.9.4. Transformers operators
4.10.9.5. Create custom filter and transformer operators

4.10.10. Scripts
4.10.10.1. Common scripts to use in other scripts

4.10.11. Configure a sub-playbook loop

4.10.12. Playbook polling
4.10.13. Create alert fields in a playbook
4.10.14. Debugger
4.10.14.1. Debug a playbook

4.10.15. Playgrounds
4.10.16. Best practices

4.11. Lists
4.11.1. Work With Lists
4.11.2. Work with JSON Lists
4.11.3. Create a List
4.11.4. Edit a List from a Content Pack
4.11.5. Transform a List into an Array

4.12. Jobs
4.12.1. Create a Time Triggered Job
4.12.2. Create a Job Triggered by delta in a Feed
4.12.3. Set up a Job to Process Indicators

5. Threat Intel Management

5.1. Threat Intel Concepts

5.2. Indicator Verdict

5.3. Indicator Ingestion

5.4. Indicator Rules

5.5. Indicator Customization

5.5.1. Indicator Types

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 5/1003
5/8/24, 9:18 AM PDF Export

5.5.1.1. Create an Indicator Type

5.5.1.2. Indicator Type Profile
5.5.1.3. File Indicators
5.5.1.4. Formatting Script
5.5.1.5. Enhancement Scripts
5.5.1.6. Reputation Scripts
5.5.1.7. Reputation Commands

5.5.2. Indicator Fields

5.5.2.1. Create a Custom Indicator Field
5.5.2.2. Map Custom Indicator Fields
5.5.2.3. Indicator field trigger scripts
5.5.2.4. Indicator Fields Structure

5.5.3. Indicators Classification and Mapping

5.5.3.1. Classify Attributes for Indicator Types
5.5.3.2. Map Attributes to Indicator Types

5.5.4. Exclusion List

5.6. Indicator Expiration

5.7. Indicator Management

5.7.1. Export Indicators
5.7.1.1. Manually Export Indicators
5.7.1.2. Export Indicators Integrations
5.7.1.3. Export Indicators Playbooks

5.7.2. Indicator Relationships

5.7.2.1. Create Indicator Relationships

5.8. Threat Intel Feeds

5.8.1. Feed Integrations
5.8.2. Threat Intelligence Management Playbooks

5.9. Unit 42 Intel

5.9.1. Unit 42 Intel Overview
5.9.2. Understanding Indicator Queries
5.9.3. Add Unit 42 Intel Data
5.9.4. Sample Analysis
5.9.5. Sessions and Submissions

6. Broker VM
6.1. Broker VM
6.1.1. Broker VM Overview
6.1.2. Set up Broker VM
6.1.2.1. Configure the Broker VM
6.1.2.1.1. Create a Broker VM Amazon Machine Image (AMI)
6.1.2.1.2. Create a Broker VM Azure Image
6.1.2.1.3. Create a Broker VM Image for Microsoft Hyper-V
6.1.2.1.4. Set up the Broker VM on Google Cloud Platform (GCP)
6.1.2.1.5. Create a Broker VM Image for Alibaba Cloud
6.1.2.1.6. Create a Broker VM Image for a Nutanix Hypervisor
6.1.2.1.7. Create a Broker VM Image for a KVM using Ubuntu
6.1.2.1.8. Set up Broker VM on VMware ESXi using vSphere Client
6.1.2.2. Activate the Local Agent Settings
6.1.2.3. Activate the Syslog Collector
6.1.2.4. Activate the Apache Kafka Collector
6.1.2.5. Activate the CSV Collector
6.1.2.6. Activate the Database Collector
6.1.2.7. Activate the Files and Folders Collector
6.1.2.8. Activate the FTP Collector
6.1.2.9. Activate the NetFlow Collector
6.1.2.10. Activate the Network Mapper
6.1.2.11. Activate Pathfinder
6.1.2.12. Activate the Windows Event Collector
6.1.2.12.1. Activate the Windows Event Collector on Windows Core
6.1.2.12.2. Renew WEC Certificates

6.1.3. Manage Your Broker VMs

6.1.3.1. View Broker VM Details
6.1.3.2. Edit Your Broker VM Configuration
6.1.3.3. Monitor the Broker VM using Prometheus
6.1.3.4. Collect Broker VM Logs
6.1.3.5. Reboot a Broker VM
6.1.3.6. Shut Down a Broker VM
6.1.3.7. Upgrade a Broker VM
6.1.3.8. Import Broker VM Configuration
6.1.3.9. Open a Live Terminal
6.1.3.10. Remove a Broker VM
6.1.3.11. Add Broker VM to Cluster
6.1.3.12. Switchover Primary Node in Cluster
6.1.3.13. Remove from Cluster

6.1.4. Broker VM High Availability Cluster

6.1.4.1. Configure a High Availability Cluster
6.1.4.2. Manage Broker VM Clusters
6.1.4.2.1. View Cluster Details
6.1.4.2.2. Edit a Cluster
6.1.4.2.3. Add an Applet to a Cluster
6.1.4.2.4. Add Broker VM to Cluster
6.1.4.2.5. Remove a Cluster

6.1.5. Broker VM Notifications

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 6/1003
5/8/24, 9:18 AM PDF Export

7. XDR Collectors
7.1. XDR Collector Audit Logs

7.2. XDR Collector Machine Requirements and Supported Operating Systems

7.3. Resources Required to Enable Access to XDR Collectors

7.4. Configure the XDR Collector Upgrade Scheduler

7.5. Manage XDR Collectors

7.5.1. Create an XDR Collector Installation Package
7.5.2. Install the XDR Collector Installation Package for Windows
7.5.2.1. Install the XDR Collector on Windows Using the MSI
7.5.2.2. Install the XDR Collector on Windows Using Msiexec

7.5.3. Install the XDR Collector Installation Package for Linux

7.5.4. XDR Collectors Installation Resource for Windows and Linux
7.5.5. Set an Application Proxy for XDR Collectors
7.5.6. Upgrade XDR Collectors
7.5.7. Uninstall the XDR Collector
7.5.8. Set an Alias for a Collector Machine

7.6. Define Collector Machine Groups

7.7. About Cortex XDR Collector Content Updates

7.8. XDR Collector Profiles

7.9. Add an XDR Collector Profile for Windows

7.9.1. Ingest Logs from Windows DHCP using Elasticsearch Filebeat
7.9.2. Ingest Windows DNS Debug logs using Elasticsearch Filebeat

7.10. Add an XDR Collector Profile for Linux

7.11. Apply Profiles to Collection Machine Policies

7.12. XDR Collector Datasets

8. Data Ingestion
8.1. Visibility of Logs and Alerts from External Sources

8.2. External Data Ingestion Vendor Support

8.3. Palo Alto Networks Integrations

8.3.1. Ingest Data from Next-Generation Firewall
8.3.2. Ingest Data from Prisma Access
8.3.3. Ingest Alerts from Prisma Cloud Compute
8.3.4. Ingest Alerts and Assets from Prisma Cloud
8.3.5. Ingest Detection Data from Strata Logging Service
8.3.6. Ingest Alerts and Assets from IoT Security
8.3.7. Collecting URL and File log types
8.3.7.1. Detectors connected to URL and File log types

8.4. External Data Ingestion

8.4.1. External Applications
8.4.2. Onboarding data sources
8.4.2.1. Adding a new data source or instance
8.4.2.2. Managing Instances

8.4.3. Ingest Network Connection Logs

8.4.3.1. Ingest Network Flow Logs from Amazon S3
8.4.3.1.1. Create an Assumed Role
8.4.3.1.2. Configure Data Collection from Amazon S3 Manually
8.4.3.2. Ingest Network Route 53 Logs from Amazon S3
8.4.3.3. Ingest Logs from Check Point Firewalls
8.4.3.4. Ingest Logs from Cisco ASA Firewalls and AnyConnect
8.4.3.5. Ingest Logs from Corelight Zeek
8.4.3.6. Ingest Logs from Fortinet Fortigate Firewalls
8.4.3.7. Ingest Logs and Data from a GCP Pub/Sub
8.4.3.8. Ingest Logs from Microsoft Azure Event Hub
8.4.3.9. Ingest Network Flow Logs from Microsoft Azure Network Watcher
8.4.3.10. Ingest Logs and Data from Okta
8.4.3.11. Ingest Logs from Windows DHCP using Elasticsearch Filebeat
8.4.3.12. Ingest Logs from Zscaler Internet Access
8.4.3.13. Ingest Logs from Zscaler Private Access

8.4.4. Ingest Authentication Logs and Data

8.4.4.1. Ingest Audit Logs from AWS Cloud Trail
8.4.4.2. Ingest Logs from Microsoft Azure Event Hub
8.4.4.3. Ingest Logs and Data from a GCP Pub/Sub
8.4.4.4. Ingest Logs and Data from Google Workspace
8.4.4.5. Ingest Logs from Microsoft Office 365
8.4.4.6. Ingest Logs and Data from Okta
8.4.4.7. Ingest Logs and Data from OneLogin
8.4.4.8. Ingest Authentication Logs from PingFederate
8.4.4.9. Ingest Authentication Logs and Data from PingOne

8.4.5. Ingest Operation and System Logs from Cloud Providers

8.4.5.1. Ingest Generic Logs from Amazon S3
8.4.5.2. Ingest Logs from Amazon CloudWatch

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 7/1003
5/8/24, 9:18 AM PDF Export

8.4.5.3. Ingest Logs and Data from a GCP Pub/Sub

8.4.5.4. Ingest Logs from Google Kubernetes Engine
8.4.5.5. Ingest Logs from Microsoft Azure Event Hub
8.4.5.6. Ingest Logs and Data from Okta

8.4.6. Ingest Cloud Assets

8.4.6.1. Ingest Cloud Assets from AWS
8.4.6.2. Ingest Cloud Assets from Google Cloud Platform
8.4.6.3. Ingest Cloud Assets from Microsoft Azure

8.4.7. Additional Log Ingestion Methods

8.4.7.1. Ingest Logs from a Syslog Receiver
8.4.7.2. Ingest Apache Kafka Events as Datasets
8.4.7.3. Ingest CSV Files as Datasets
8.4.7.4. Ingest Database Data as Datasets
8.4.7.5. Ingest Logs in a Network Share as Datasets
8.4.7.6. Ingest FTP Files as Datasets
8.4.7.7. Ingest NetFlow Flow Records as Datasets
8.4.7.8. Set up an HTTP Log Collector to Receive Logs
8.4.7.9. Ingest Logs from BeyondTrust Privilege Management Cloud
8.4.7.10. Ingest Logs and Data from Box
8.4.7.11. Ingest Logs and Data from Dropbox
8.4.7.12. Ingest Logs from Elasticsearch Filebeat
8.4.7.13. Ingest Logs from Forcepoint DLP
8.4.7.14. Ingest Logs from Proofpoint Targeted Attack Protection
8.4.7.15. Ingest Logs and Data from Salesforce.com
8.4.7.16. Ingest Data from ServiceNow CMDB
8.4.7.17. Ingest Report Data from Workday

8.4.8. Ingest External Alerts

9. Apps
9.1. Notebooks

10. Data Management

10.1. Dataset Management
10.1.1. Manage Datasets
10.1.2. Lookup datasets
10.1.2.1. Import a lookup dataset
10.1.2.2. Download JSON file of lookup dataset
10.1.2.3. Set time to live for lookup datasets

10.2. Parsing Rules

10.2.1. Parsing Rules Editor Views
10.2.2. Parsing Rules File Structure and Syntax
10.2.2.1. INGEST
10.2.2.2. COLLECT
10.2.2.3. CONST
10.2.2.4. RULE
10.2.2.5. EXTEND

10.2.3. Create Parsing Rules

10.2.4. Troubleshooting Parsing Rules Errors
10.2.5. Parsing Rules Raw Dataset

10.3. Data Model Rules

10.3.1. Data Model Rules Editor Views
10.3.2. Data Model Rules File Structure and Syntax
10.3.2.1. MODEL
10.3.2.2. RULE
10.3.2.3. Field Structure

10.3.3. Create Data Model Rules

10.3.4. Troubleshooting Data Model Rules
10.3.5. Using Data Enrichment
10.3.6. Data Model Rules Notifications

10.4. Manage Event Forwarding

10.4.1. Endpoints Event Forwarding - Exported Data Types

10.5. Manage Compute Units Usage

11. Analytics
11.1. Analytics Concepts

12. Asset Management

12.1. Network Configuration
12.1.1. Configure Your Network Parameters

12.2. Vulnerability Assessment

12.3. Cloud Compliance

12.4. Manage Asset Scores

12.5. Unified Asset Inventory

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 8/1003
5/8/24, 9:18 AM PDF Export

12.5.1. Using the Unified Asset Inventory page

12.6. Existing Asset Inventory

12.6.1. All Assets
12.6.2. All External Services
12.6.3. Specific Assets
12.6.4. Cloud Inventory Assets
12.6.4.1. All Cloud Assets
12.6.4.2. Specific Cloud Assets
12.6.4.3. Manage Your Cloud Inventory Assets

12.7. Asset Roles

12.7.1. Manage Asset Roles for Endpoints
12.7.2. Manage Asset Roles for Users

13. Attack Surface Management

13.1. External Assets

13.2. Asset Attribution Evidence

13.3. External Services

13.4. Externally Inferred CVEs

13.4.1. View Externally Inferred CVEs

13.5. Attack Surface Testing

13.5.1. Set up Attack Surface Testing
13.5.2. Select targets for Attack Surface Testing
13.5.3. View attack surface test results
13.5.4. Enable new attack surface tests by default
13.5.5. View attack surface tests
13.5.6. View source IP addresses for Attack Surface Testing scans

14. Monitoring
14.1. Dashboard
14.1.1. Manage Dashboards
14.1.2. Command Center dashboards
14.1.2.1. XSIAM Command Center
14.1.2.2. Cloud Command Center

14.1.3. Predefined Dashboards

14.1.4. Build a Custom Dashboard
14.1.4.1. Manage Your Widget Library
14.1.4.1.1. Dashboard Widgets
14.1.4.2. Using Dashboard Filters, Inputs, and Drilldowns
14.1.4.3. Configuring Filters, Inputs, and Drilldowns

14.1.5. Reports
14.1.5.1. Report Templates
14.1.5.2. Run or Schedule Reports

14.2. Monitor Cortex XSIAM Incidents

14.3. Monitor Gateway Management Activity

14.4. Monitor Administrative Activity

14.5. Monitor Agent Operational Status

14.6. Monitor Agent Activity

14.7. Monitor Agent Upgrade Status

14.8. Monitor Broker VM Activity

14.9. Monitoring Collector Connectivity

14.9.1. Verifying Collector Connectivity

14.10. Monitoring Data Ingestion Health

14.10.1. Overview of Data Ingestion Metrics
14.10.2. Creating Correlation Rules to Monitor Data Ingestion Health
14.10.3. Viewing ingestion and collection alerts
14.10.4. Measuring Data Freshness

14.11. Monitor Data Model Rules Activity

15. Log Forwarding

15.1. Log Forwarding Data Types

15.2. Integrate Slack for Outbound Notifications

15.3. Integrate a Syslog Receiver

15.3.1. Syslog Server Test Message Errors

15.4. Configure Notification Forwarding

15.5. Log Notification Formats

15.5.1. Management Audit Log Messages

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 9/1003
5/8/24, 9:18 AM PDF Export

15.5.2. Alert Notification Format

15.5.3. Agent Audit Log Notification Format
15.5.4. Management Audit Log Notification Format
15.5.5. Log Format for IOC and BIOC Alerts
15.5.6. Analytics Log Format
15.5.7. Log Formats

16. Managed Security

16.1. About Managed Security

16.2. Managed Security Access Requirements

16.3. Switch to a Different Tenant

16.4. Pair a Parent Tenant with Child Tenant

16.5. Manage a Child Tenant

16.5.1. Track your Tenant Management
16.5.2. Investigate Child Tenant Data
16.5.3. Create and Allocate Configurations
16.5.4. Create a Security Managed Action

16.6. About Managed Threat Hunting

16.7. Set up Managed Threat Hunting

16.8. Investigate Managed Threat Hunting Reports

17. Marketplace
17.1. Marketplace Overview

17.2. Marketplace FAQs

17.3. Search and Navigate in the Marketplace

17.4. Content Pack Lifecycle

17.5. Content Pack Installation

17.5.1. Install a Content Pack
17.5.2. Delete a Content Pack
17.5.3. Update a Content Pack
17.5.4. Revert a Content Pack

17.6. Forward Requests to Long Running Integrations

18. Engines
18.1. Engines Overview

18.2. Engine Installation

18.2.1. Install an Engine
18.2.2. Engine Offline Installation
18.2.3. Docker
18.2.3.1. Install Docker
18.2.3.2. Change the Docker Installation Folder
18.2.3.3. Update Container-Selinux
18.2.3.4. Install Docker Distribution for Red Hat on an Engine
18.2.3.5. Docker Image Security
18.2.3.6. Configure Docker Pull Rate Limit
18.2.3.7. Docker FAQs

18.2.4. Podman
18.2.4.1. Install Podman
18.2.4.2. Migrate From Docker to Podman

18.3. Configure Engines

18.3.1. Edit the Engine Configuration File
18.3.2. Common Properties When Editing an Engine Configuration
18.3.3. Docker Hardening Guide
18.3.3.1. Configure Docker Images
18.3.3.2. Check Docker Hardening Configurations
18.3.3.3. Run Docker with Non-Root Internal Users
18.3.3.4. Configure the Memory Limit Support Without Swap Limit Capabilities
18.3.3.5. Configure the Memory Limitation
18.3.3.6. Test the Memory Limit
18.3.3.7. Limit Available CPU on Your System
18.3.3.8. Configure the PIDs Limit
18.3.3.9. Configure the Open File Descriptors Limit
18.3.3.10. Docker Network Hardening

18.3.4. Configure the Engine to Use a Web Proxy

18.3.5. Configure the Engine to Call the Server Without Using a Proxy
18.3.6. Use NGINX as a Reverse Proxy to the Engine
18.3.6.1. Install NGINX on the Engine
18.3.6.2. Generate a Certificate for NGINX
18.3.6.3. Configure NGINX on an Engine

18.3.7. Configure an Engine to Use Custom Certificates

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 10/1003
5/8/24, 9:18 AM PDF Export

18.4. Manage Engines

18.5. Use an Engine in an Integration

18.6. Run a Script Using an Engine

18.7. Remove an Engine

18.8. Troubleshoot Engines

18.8.1. Troubleshoot Engine Installation
18.8.2. Troubleshoot Docker Networking Issues
18.8.3. Troubleshoot Docker Performance Issues
18.8.4. Troubleshoot Podman Installation
18.8.5. Troubleshoot Engine Upgrades
18.8.6. Troubleshoot Engine Connectivity
18.8.7. Troubleshoot Integrations Running on Engines
18.8.8. Troubleshoot Engine Import Error or Invalid Syntax Error
18.8.9. Troubleshoot Permission Denied

19. Automation and Feed Integrations

19.1. Fetch Alerts From an Integration Instance

19.2. Classification and Mapping

19.3. Classify Events Using a Classifier for Alert Types

19.4. Map Fields to Alert Types

19.5. Credentials in Cortex XSIAM

19.5.1. Configure Cortex XSIAM Credentials
19.5.2. Configure an External Credentials Vault

20. Glossary
20.1. Alert

20.2. Alert Exclusion

20.3. Analytics behavioral indicators of compromise (ABIOCs)

20.4. Attack Surface Management (ASM)

20.5. Behavioral indicators of compromise (BIOCs)

20.6. Bring Your Own Machine Learning (BYOML)

20.7. Broker Virtual Machine (Broker VM)

20.8. Broker Virtual Machine Fully Qualified Domain Name (Broker VM FQDN)

20.9. Causality Group Owner (CGO)

20.10. Causality View

20.11. Cloud Detection and Response (CDR)

20.12. Cortex Data Model (XDM)

20.13. Cortex Query Language (XQL)

20.14. Dataset

20.15. Elasticsearch Filebeat

20.16. Endpoint Detection and Response (EDR)

20.17. Endpoint Protection Platform (EPP)

20.18. Exception

20.19. Exception vs Alert Exclusion

20.20. Extended Detection and Response (XDR)

20.21. External Dynamic List (EDL)

20.22. Filebeat

20.23. Forensics

20.24. Fully Qualified Domain Name (FQDN)

20.25. Identity Threat Detection and Response (ITDR)

20.26. Incident

20.27. Indicators of compromise (IOCs)

20.28. IT Metrics Dashboard

20.29. Managed Threat Hunting (MTH)

20.30. Management, Reporting, and Compliance

20.31. Master Boot Record Protection (MBR Protection)

20.32. MITRE ATT&CK Framework Coverage Dashboard

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 11/1003
5/8/24, 9:18 AM PDF Export

20.33. Next-Generation Firewall (NGFW)

20.34. Notebooks

20.35. On-write File Protection

20.36. Playbook

20.37. Prisma

20.38. Script

20.39. Security Information and Event Management (SIEM)

20.40. Security Orchestration, Automation, and Response (SOAR)

20.41. Threat Intelligence Platform (TIP)

20.42. Unified Extensible Firmware Interface Protection (UEFI Protection)

20.43. User and Entity Behavior Analytics (UEBA)

20.44. Virtual Machine

20.45. Vulnerability Assessment (VA)

20.46. Windows Event Collector (WEC)

20.47. XSIAM Command Center

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 12/1003
5/8/24, 9:18 AM PDF Export

1 | Overview
Abstract

Learn more about Cortex XSIAM and what it provided you with.

Cortex XSIAM is an AI-powered SOC platform that revolutionizes how data, analytics, and automation are deployed to outpace threats. Extended Security
Intelligence & Automation Management (XSIAM) turns widespread infrastructure telemetry into an intelligent data foundation to fuel best-in-class artificial
intelligence and dramatically accelerate threat response.

Cortex XSIAM collects and ingests endpoint, network, cloud, and identity data, in addition to logs and alerts, to drive machine learning for natively autonomous
response actions, such as cross-correlation of alerts and data, detection of highly sophisticated threats, and automated remediation based on native threat
intelligence and attack surface data.

Specifically, Cortex XSIAM enables you to:

Rapid Detection and Response - Full visibility across external and internal assets, and Internet-facing vulnerabilities by providing multiple layers of AI-
driven analytics based on your data foundation. Cortex XSIAM detects emerging threats across the entire security infrastructure, automates the correlation
of alerts and data into incidents, and leverages a self-learning recommendation engine to determine response next steps.

Threat Hunting and Threat Intelligence - Advanced Cortex Query Language (XQL) search, visualization, and aggregation capabilities incorporated with
automated feed aggregation from multiple sources, WildFire threat intelligence incident artifacts, and Unit 42 enrichment, hunting, and investigation
analysis.

Increase SOC Efficiency - Easily onboard and automatically normalizes, correlates, and stitches cloud-based data to speed deployment and provide an
intelligent foundation for analytics, streamlining analysis with hundreds of built-in playbooks, and product integrations.

1.1 | Architecture
Abstract

Learn more about the Cortex XSIAM architecture.

Alert Alert Exclusion Analytics behavioral indicators of compromise Attack Surface Management Behavioral indicators of compromise Bring Your Own Machine
Learning Broker Virtual Machine Broker Virtual Machine Fully Qualified Domain Name Causality Chain Causality Group Owner Causality View Cloud Detection
and Response Cortex Copilot Cortex Data Model Cortex Query Language Dataset Elasticsearch Filebeat Endpoint Detection and Response Endpoint Protection
Platform Exception Exception vs Alert Exclusion Extended Detection and Response External Dynamic List Filebeat Forensics Fully Qualified Domain Name
Identity Threat Detection and Response Incident Indicators of compromise IT Metrics Dashboard Managed Threat Hunting Management, Reporting, and
Compliance Master Boot Record Protection MITRE ATT&CK Framework Coverage Dashboard Next-Generation Firewall Notebooks On-write File Protection
PlaybookPrisma ScriptSecurity Orchestration, Automation, and Response Security Information and Event Management Threat Intelligence Platform User and
Entity Behavior Analytics Unified Extensible Firmware Interface Protection Virtual Machine Vulnerability Assessment Windows Event Collector XSIAM Command
Center

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 13/1003
5/8/24, 9:18 AM PDF Export

Cortex XSIAM consumes data from the Data Layer to provide cloud-based storage within the Cortex XSIAM tenant including all sources streamed into Cortex
XSIAM — endpoints, firewalls, cloud sources, and third-party data. Cortex XSIAM can correlate and stitch together this data from logs across your different log
sensors to derive event causality and timelines.

1.2 | Concepts
Abstract

Learn more about the Cortex XSIAM main concepts.

Cortex XDR

With Endpoint Detection and Response (EDR), enterprises rely on endpoint data as a means to trigger cybersecurity incidents. As cybercriminals and their
tactics have become more sophisticated, the time to identify and contain breaches has only increased. Cortex Extended Detection and Response (XDR) goes
beyond the traditional EDR approach of using only endpoint data to identify and respond to threats by applying machine learning across all your enterprise,
network, cloud, and endpoint data. This approach enables you to quickly find and stop targeted attacks and insider abuse and remediate compromised
endpoints.

Sensors

Cortex XSIAM uses your existing Palo Alto Networks products as sensors to collect logs and telemetry data. The sensors that are available to you depend on
your Cortex XSIAM license type.

Virtual (VM-Series) or physical firewalls: Identifies known threats in your network and cloud data center environments

Prisma Access or GlobalProtect: Identifies known threats in your mobile user and remote network traffic

External vendors: You can forward logs from supported vendors and additional vendors that adhere to the required formats

Cortex XDR agents: Identifies threats on your Windows, Mac, Linux, and Android endpoints and halts any malicious behavior or files

While more sensors increase the amount of data Cortex XSIAM can analyze, you only need to deploy one type of sensor to begin detecting and stopping threats
with Cortex XSIAM.

Log Stitching

To provide a complete and comprehensive picture of the events and activity surrounding an event, Cortex XSIAM correlates together firewall network logs,
endpoint raw data, and cloud data across your detection sensors. The act of correlating logs from different sources is referred to as log stitching and helps you
identify the source and destination of security processes and connections made over the network.

Log stitching allows you to:

Run investigation queries based on stitched network and endpoint logs

Create granular BIOC and Correlation Rules over logs from Palo Alto Networks Next-Generation Firewalls and raw endpoint data

Investigate correlated network and endpoint events in the Network Causality View

Investigate cloud Cortex XSIAM alerts and Cloud Audit Logs in the Cloud Causality View

Investigate software-as-a-service (SaaS) related alerts for audit stories, such as Office 365 audit logs and normalized logs, in the SaaS Causality View

Log stitching streamlines detection and reduces response time by eliminating the need for manual analysis across different data sensors. Stitching data across
the firewalls and endpoints allows you to obtain data from different sensors in a unified view, each sensor adding another layer of visibility. For example, when a
connection is seen through the firewall and the endpoint, the endpoint can provide information on the processes involved and on the chain of execution while the
firewall can provide information on the amount of data transferred over the connection and the different app IDs involved.

Causality Analysis Engine

The Causality Analysis Engine correlates activity from all detection sensors to establish causality chains that identify the root cause of every alert. The Causality
Analysis Engine also identifies a complete forensic timeline of events that helps you to determine the scope and damage of an attack and provide an immediate
response. The Causality Analysis Engine determines the most relevant artifacts in each alert and aggregates all alerts related to an event into an incident.

Causality Chain

When a malicious file, behavior, or technique is detected, Cortex XSIAM correlates available data across your detection sensors to display the sequence of
activity that led to the alert. This sequence of events is called the causality chain. The causality chain is built from processes, events, insights, and alerts
associated with the activity. During the alert investigation, you should review the entire causality chain to fully understand why the alert occurred.

Causality Group Owner (CGO)

The Causality Group Owner (CGO) is the process in the causality chain that the Causality Analysis Engine identified as being responsible for or causing the
activities that led to the alert.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 14/1003
5/8/24, 9:18 AM PDF Export

NOTE:

There are no CGOs in the Cloud Causality View, when investigating cloud Cortex XSIAM alerts and Cloud Audit Logs, or SaaS Causality View, when
investigating SaaS-related alerts for 501 audit events, such as Office 365 audit logs and normalized logs.

Automation and Integrations

Cortex XSIAM ingests aggregated alerts and indicators of compromise (IOCs) from detection sources, such as security information, network security tools,
threat intelligence feeds, and mailboxes, and then executes automatable, process-driven playbooks to enrich and respond to these incidents. These playbooks
coordinate across technologies, security teams, and external users for centralized data visibility and action.

Content Packs

All Cortex XSIAM content is organized in packs. Packs are groups of artifacts that implement use cases in the product. Content packs are created by Palo Alto
Networks, technology partners, consulting companies, MSSPs, customers, and individual contributors. Content packs may include a variety of different
components, such as integrations, scripts, playbooks, and widgets.

Playbooks

Playbooks are self-contained, fully documented prescriptive procedures that query, analyze, and take action based on the gathered results. Playbooks enable
you to organize and document security monitoring, orchestration, and response activities. There are several out-of-the-box playbooks that cover common
investigation scenarios. You can use these playbooks as-is, or customize them according to your requirements. Playbooks are written in YAML file format using
the COPS standard.

A key feature of playbooks is the ability to structure and automate security responses, which were previously handled manually. You can reuse playbook tasks
as building blocks for new playbooks, saving you time and streamlining knowledge retention.

1.3 | Use cases

Abstract

Learn more about common use cases for Cortex XSIAM.

The following are common use cases for the different categories of Cortex XSIAM integrations. While this list is not meant to be exhaustive, it's a starting point to
understand what use cases are supported by Cortex XSIAM and third-party integrations.

Analytics and SIEM

Abstract

Learn more about analytics and SIEM top use cases.

Top use cases:

Fetch incidents with relevant filters.

Create, close and delete incidents/events/cases.

Update incidents - update status, assignees, severity, SLA, etc.

Get events related to an incident/case for enrichment/investigation purposes.

Query SIEM (consider aggregating logs).

NOTE:

These integrations usually include the Fetch Incidents option for an instance. It can also include list-incidents or get-incident as integration
commands, or important information for an event or incident.

Analytics & SIEM Integration Example: ArcSight ESM

Authentication

Abstract

Learn more about the authentication top use cases.

Top use cases:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 15/1003
5/8/24, 9:18 AM PDF Export

Use credentials from the authentication vault to configure instances in Cortex XSIAM. (Save credentials in: Settings → Configurations → Integrations →
Credentials.) The integration should include the isFetchCredentials parameter. Integrations that use credentials from the vault should have the Switch
to credentials option.

Lock/Delete Account – Use an integration to lock/unlock a third-party account.

Reset Account - Perform a reset password command for a third-party account.

Lock an external credentials vault - in case of emergency (if the vault has been compromised), allow the option to lock/unlock the entire vault via an
integration.

Step-Up authentication - Enforce Multi Factor Authentication for an account.

Authentication Integration Example: CyberArk AIM

Case Management

Abstract

Learn more about the Case Management top use cases.

Top use cases:

Create, get, edit, close a ticket or issue, add + view comments.

Assign a ticket/issue to a specified user.

List all tickets, filter by name, date, assignee.

Get details about a managed object, update, create, delete.

Add and manage users.

Case Management/Ticketing integration example: ServiceNow

Data Enrichment & Threat Intelligence

Abstract

Learn more about the top uses cases for Data Enrichment and Threat Intelligence.

Top use cases:

Enrich information about different IOC types: Upload object for scan and get the scan results. (If there’s an option to upload private/public, the default
should be set to private.) Search for former scan results about an object to get information about a sample without uploading it yourself. Enrich information
and scoring for the object.

Add indicators to the system and search for existing indicators.

Add indicators to the exclusion list.

Calculate DBot Score for indicators.

Enrich asset – get vulnerability information for an asset (or a group of assets) in the organization.

Generate/trigger a scan on specified assets.

Get a scan report including vulnerability information for a specified scan and export it.

Get details for a specified vulnerability.

Scan assets for a specific vulnerability.

Data Enrichment & Threat Intelligence Integration Example: Unit 42 Objects Feed.

Email Gateway

Abstract

Learn more about the top use cases for the Email Gateway.

Top use cases:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 16/1003
5/8/24, 9:18 AM PDF Export

Get message – download the email itself, retrieve metadata, body.

Download attachments for a given message.

Manage senders – block/allow specified mail senders.

Manage URLs – block/allow the sending of specified URLs.

Encode/decode URLs in messages

Release a held message when a gateway has placed a suspicious message on hold.

Email Gateway integration example: MimeCast

Forensics and Malware Analysis

Abstract

Learn more about the top use cases for forensics and malware analysis.

Top use cases:

Submit a file and get a report (detonation).

Submit a URL and get a report (detonation).

Search for past analysis (input being a hash/URL).

Retrieve a PCAP file.

Retrieve screenshots taken during analysis.

Sandbox Integration Example: Cuckoo Sandbox

IAM (Identity and Access Management)

Abstract

Learn more about the top use cases for Identity and Access Management (IAM).

Top use cases:

Create, update, and delete users.

Manage user groups.

Block users, force change of passwords.

Manage access to resources and applications.

Create, update, and delete roles.

Network Security (Firewall)

Abstract

Learn more about the top use cases for network security (firewall).

Top use cases:

Create block/accept policies (source, destination, port), for IP addresses and domains.

Add addresses and ports (services) to predefined groups, create groups, etc.

Support custom URL categories.

Fetch network logs for a specific address for a configurable time frame.

URL filtering categorization change request.

Built-in blocked rule command for fast-blocking.

If there is a Management FW, allow the option to manage policy rules through it.

Network Security Firewall Integration Example: Palo Alto Networks PAN-OS

Network Security (IDS/IPS)

Abstract

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 17/1003
5/8/24, 9:18 AM PDF Export

Learn more about top use cases for network security (IDS/IPS).

Top use cases:

Get/fetch alerts.

Get PCAP file, packet.

Get network logs filtered by time range, IP addresses, ports, etc.

Create/manage/delete policies and rules.

Update signatures from an online source / upload + get last signature update information.

Install policy (if existing).

Network Security (IPS/IDS) Integration Example: ProtectWise

Vulnerability Management

Abstract

Learn more about the top use cases for vulnerability management.

Top use cases:

Enrich asset – get vulnerability information for an asset (or a group of assets) in the organization.

Generate/trigger a scan on specified assets.

Get a scan report including vulnerability information for a specified scan and export it.

Get details for a specified vulnerability.

Scan assets for a specific vulnerability.

Vulnerability Management integration example: Tenable.io

1.4 | Cortex XSIAM License

Abstract

Learn more about the Cortex XSIAM licenses that are split into two license tiers.

Cortex XSIAM collects and ingests endpoint, network, cloud, and identity data. The Cortex XSIAM license is split into two license tiers allowing you to select the
most suitable detection and protection capabilities, log ingestion, retention, and the number of users required.

Each license tier offers the following investigation and response capabilities by default per endpoint:

Cortex XSIAM Enterprise

Cortex XSIAM Enterprise is intended for on-prem environments. Collection and ingestion of endpoint logs and alerts, firewalls, and third-party data audit
and flow logs that include:

Three Cortex XDR Pro per Endpoint agent licenses, which provide tailored endpoint data and third-party logs collection to optimize detection and
investigation visibility.

Extended data collection and ingestion of endpoint logs and alerts, firewalls, and third-party audit and flow logs using Host Insights and Extended
Threat Hunting Data (XTH).

On-prem out-of-the-box analytics, detection, on-prem asset discovery, threat-hunting, analysis, response, automation, user, and entity behavior
analytics (UEBA) of endpoints, firewalls, and third-party logs.

Cortex XSIAM Enterprise Plus

Cortex XSIAM Enterprise Plus contains all the features available in Cortex XSIAM Enterprise with more capabilities expanded for the cloud. Enhanced
data collection, detection, automation, and response capabilities of cloud sources, endpoint logs and alerts, firewalls, and third-party audit and flow logs
using Host Insights and Extended Threat Hunting Data (XTH).

Three Cortex XDR Pro per Endpoint agent licenses, which provide tailored endpoint data and third-party logs collection to optimize detection and
investigation visibility.

Two Cortex XDR Cloud per Host agent licenses that can be installed on any physical endpoint or cloud workload, including Kubernetes hosts. The
agent provides a cloud-based endpoint protection and detection support with tailored endpoint and third-party logs data collection.

Comprehensive cloud data collection providing out-of-box analytics, detection, cloud asset discovery, threat-hunting, analysis, response,
automation, user, and entity behavior analytics (UEBA).

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 18/1003
5/8/24, 9:18 AM PDF Export

Cortex XSIAM is managed by a Base layer containing the data storage, ingestion, query, and reporting capabilities. You receive log storage based on the
amount of storage associated with your license. Generally, this capacity is determined by factors such as your daily ingestion needs and the number of users in
your deployment.

NOTE:

A tenant must have a Base layer; which includes the data ingestion license, and only one of the two tiers: XSIAM Enterprise or XSIAM Enterprise Plus.

To expand your capabilities, Cortex XSIAM offers several add-ons that allow for more granular investigation. The following table lists the add-ons available for
purchase for both Cortex XSIAM Enterprise and Cortex XSIAM Enterprise Plus licenses.

Read more...

Feature Description

Cortex XSIAM Add-ons

Attack Surface Provides Internet-facing Assets and ASM Enrichment, External Services, External IP Ranges, Attack Surface Rules and
Management (ASM) Alerts, ASM Widgets, and Reports capabilities.

Threat Intelligence Enables Indicators, Sample Analysis, Sessions and Submissions, Indicator Rules, Reports, Automation, and Feed
Management (TIM) Integrations.

Forensics Forensic File, Registry, and Log search capabilities. Available for a one-month trial period.

Can be purchased as an annual or monthly add-on with 31-day retention included.

Identity Threat Detection Enables Asset Roles Configuration, Advanced Analytics Alert layout, Risk Management Dashboard, User/Host Risk View,
and Response (ITDR) Designated Analytics for Compromised Accounts, and Insider Threat Coverage.

Available for a free trial period ending on July 31, 2023. After this date, the module will be available as an Add-on.

Compute Unit Additional compute units to run queries.

Requires a minimum of 50 units. Available for a one-month trial period.

Notebooks Enables analysis and and visualization of the extensive data collected by Cortex XSIAM using Jupyter tools.

After activation, Notebooks consumes 1000 compute units daily, which are charged at 00:00 UTC every day. The XQL
queries and the SQL queries to Big Query run through Notebooks are charged separately, using the usual Cortex XSIAM
calculation, at 00:00 UTC every day.

Endpoint Event Forwarding Enables exporting raw endpoint data for Cortex XSIAM Pro EP and Cloud Endpoints.

GB Event Forwarding Enables exporting parsed logs for Cortex XDR Pro per GB to an external SIEM for storage, so you can keep data in your own
storage in addition to the Cortex XSIAM data layer, for compliance requirements and machine learning purposes.

1.4.1 | License Retention

Abstract

Learn more about the default retention periods provided for all Cortex XSIAM licenses and retention add-ons available.

All of the Cortex XSIAM licenses provide you with the following default retention periods:

31-day Ingested Data

180-day Alert and Incident Data

365-day Forensics Data (requires Forensics add-on)

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 19/1003
5/8/24, 9:18 AM PDF Export

Incident and alert data are retained according to the last Update Date and Creation Date, respectively. Data collected within these dates is kept and displayed
for 180 days. To ensure the accuracy of incidents, Cortex XSIAM provides a grace period of up to 31 days for alerts displayed in the Incidents View, Alerts table,
and Casualty View.

For XQL Search capabilities, Cortex XSIAM enforces retention on all log-type datasets excluding Host Inventory, Vulnerability Assessment, Metrics, and Users.

Depending on your requirements and license add-ons, you can purchase one or more of the following retention add-ons on top of your license to extend your
storage. You can view your retention storage duration in the Dataset Management page.

The following table lists the additional retention available for purchase for both Cortex XSIAM Enterprise and Cortex XSIAM Enterprise Plus licenses:

NOTE:

Retention add-ons are provided for ingested data, and alert and incident data unless noted otherwise. Minimum requirements are dependent on the license
type.

Read more...

Feature Description

Additional Alert and Additional 31-day Hot storage of alert and incident data apart from the default 180 days.
Incident Retention
Available for purchase per month for each endpoint.

Period-Based Retention - Fully searchable storage for investigation and threat hunting of ingested data, and alert and incident data.
Hot Storage
Requires purchasing a minimum of 1 month of the additional retention.

Additional Hot Storage Flexible Hot Storage based retention to help accommodate varying storage requirements for different retention periods and
datasets. Fully searchable storage for investigation and threat hunting of ingested data.

Available for purchase by storage for a minimum of 1,000 GB.

Period-Based Retention - Lower cost storage of ingested data for long-term compliance needs with limited search options.
Cold Storage
Requires purchasing a minimum of 6 months of the additional retention.

Data Storage Lifecycle

Cortex XSIAM data storage is managed in the Cortex XSIAM Data Layer. You receive data storage based on the amount of storage associated with your
licenses. Generally, this capacity is determined by factors such as your daily ingestion needs and the number of users in your deployment. All Cortex XSIAM
licenses provide you with default retention periods. You can extend your license retention depending on your requirements for hot and cold storage.

To determine the licenses you require for your data storage requirements, it's important that you understand the data storage lifecycle specifically the differences
between hot and cold storage options available. To further illustrate these differences, the Hot and Cold Storage Timeline is provided below with examples.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 20/1003
5/8/24, 9:18 AM PDF Export

Data enters Cortex XSIAM via a data stream called the Data Ingestion Pipeline, where all the data manipulation occurs, such as normalization, enrichment, and
analytics. Once the data is ready, the data is transferred to any of the following 3 places, which is dependent on your licenses:

Hot Storage

With a regular Cortex XSIAM license, the data is automatically sent to hot storage for the default retention period according to the license, typically 1 month. If
you've purchased additional retention add-ons to extend the hot storage, this is added in monthly increments to the hot storage duration according to the
license. For example, a Period-Based Retention - Hot Storage license enables you to extend all the data in hot storage for the number of months designated,
while an Additional Hot Storage license provides flexible hot storage so you can extend only the data collected in specific datasets for the number of months
designated. During the additional hot storage retention period, data continues to be sent from the Data Ingestion Pipeline. This data is no longer accessible after
the hot storage retention period ends and the data is gradually purged.

In the Hot and Cold Storage Timeline example above, the regular Cortex XSIAM license and additional storage licenses purchased ensures that all the data is
accessible from Hot Storage for 2 months. While after these 2 months, the data begins to be purged, except for the data in Dataset 2 and Dataset 3. The data in
Dataset 2 is accessible for an additional month before it's gradually purged and the data in Dataset 3 is accessible for an additional 2 months before it's purged.

Cold Storage

A regular Cortex XSIAM license doesn't provide any default cold storage retention. Ensure that you understand the following about cold storage:

Read more...

Only after purchasing additional retention with a Period-Based Retention - Cold Storage license is data automatically sent to cold storage from the Data
Ingestion Pipeline starting from the purchase date. If you want the cold storage data to align with the hot storage data, you must ensure to purchase your
cold storage license at the same time as your regular Cortex XSIAM license.

There is no connection between the data in the hot storage and cold storage, so there is no way to add missing data from hot storage to cold storage.

The cold storage data is only accessible after the retention period for hot storage is expired. During the hot storage retention period, the cold storage data
is collected according to the purchase date. As a result, the retention period for cold storage only begins after the hot storage retention period ends. Once
the cold storage retention period ends, the data is no longer accessible and is gradually purged.

Requires purchasing a minimum of 6 months of the additional retention.

In the Hot and Cold Storage Timeline example above, the cold storage is aligned to the hot storage. The Data Ingestion Pipeline is configured to send data to
both hot and cold storage for the first 2 months, but is not accessible in cold storage during the hot storage retention period. After the 2 months, the Data
Ingestion Pipeline continues to send data to cold storage and the data becomes accessible in cold storage for 6 months except for the data related to Dataset 2
and Dataset 3, which are still within the hot storage retention periods. After the 6 months of cold storage retention, the data is gradually purged, except for the
data related to Dataset 2 and Dataset 3. When Dataset 2 and Dataset 3 finish their allotted hot storage retention periods, the dataset data becomes accessible
in cold storage for another 6 months. Once these 6 months are over, the dataset data is gradually purged.

Export

A regular Cortex XSIAM license doesn't provide any default export capabilites for Event Forwarding. Only after purchasing an Event Forwarding add-on license
is data automatically sent to an intermediate storage location from the Data Ingestion Pipeline starting from the purchase date. This data is no longer accessible
after 7 days and is gradually purged.

In the Hot and Cold Storage Timeline example above, the Export data is aligned to the hot and cold storage. The Data Ingestion Pipeline is configured to send
data to the intermediate storage location for Event Forwarding, which is accessible for 7 days before the data is gradually purged.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 21/1003
5/8/24, 9:18 AM PDF Export

NOTE:

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

TIP:

You can view details about your Cortex XSIAM licenses by selecting Settings → Cortex XSIAM License. For more information on your storage license details,
see Dataset Management.

1.4.2 | License Allocation

Abstract

Learn more about how Cortex XSIAM regulates agent licenses.

Cortex XSIAM regulates agent licenses according to the available license quota and revocation policy.

Enforcement of Licenses

Each Cortex XSIAM license provides 3 Cortex XDR Pro per Endpoint agents and an additional 2 Cortex XDR Cloud agents for the Enterprise Plus. You can add
additional agents to supplement the ones they get as part of the Cortex XSIAM base bundle. As the Cortex XSIAM-based bundle comes with integrated Host
Insights and Extended Threat Hunting Data (XTH) capabilities, any additional Cortex XDR Pro per Endpoint or XDR Cloud agents must also include the Host
Insights and XTH add-on.

If an endpoint requires a Pro per Endpoint license, and you’ve exceeded the number of available Pro per Endpoint licenses, one of your surplus Cloud per Host
licenses is automatically consumed as a Pro per Endpoint license for the endpoint.

Pro per Endpoint licenses can be allocated for Cloud virtual machines up to Pro per Endpoint license capacity. Cortex XSIAM auto-identifies if a host is running
a container orchestrator and assigns the Cloud per Host license accordingly. To protect a Kubernetes or similar container orchestrator endpoint, Cortex XSIAM
requires a Cortex Cloud per Host license.

After utilizing all available Pro per Endpoint and Cloud per Host licenses, Cortex XDR falls back to a Cortex XDR Prevent policy that protects the endpoint but
does not include Pro-specific capabilities. When you exceed the permitted number of Pro and Cloud agents, Cortex XSIAM displays a notification in the
notification area. Cortex XSIAM permits a small grace over the permitted number but begins enforcing the number of agents after 14 days. If additional Pro
agents are required, increase your Cortex XDR Pro per Endpoint license capacity.

Endpoint License Revocation

Cortex XSIAM manages licensing for all endpoints in your organization. Each time you install a new Cortex XDR agent on an endpoint, the Cortex XDR agent
registers with Cortex XSIAM to obtain a license. In the case of non-persistent VDI, the Cortex XDR agent registers with Cortex XSIAM as soon as the user logs
in to the endpoint.

Cortex XSIAM issues licenses until you exhaust the number of license seats available. Cortex XSIAM also enforces a license cleanup policy to automatically
return unused licenses to the pool of available licenses. The time at which a license returns to the license pool depends on the type of endpoint:

Endpoint Type License Return Agent Removal From Cortex XSIAM Console Agent Removal From Cortex XSIAM Database

Standard and mobile After 30 days After 180 days After 180 days
devices

(Non-Persistent) VDI Immediately after log-off After 6 hours After 7 days

and Temporary for VDI, otherwise after
Session 90 minutes

After a license is revoked, if the agent connects to Cortex XSIAM, reconnection of a specific endpoint will succeed as long as the agent has not been deleted,
otherwise, the endpoint is registered as a new endpoint.

If a deleted agent tries to connect to Cortex XSIAM during the 180 days period, the agent can resume connection and maintain its agent ID. After the 180 days
period, the agent ID is deleted alongside all the associated data. In order to reconnect the agent, you must use Cytool to reconnect it or reinstall it on the
endpoint, and the agent will be assigned a new ID and a fresh start.

NOTE:

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

1.4.3 | License Expiration

Abstract

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 22/1003
5/8/24, 9:18 AM PDF Export

Cortex XSIAM licenses are valid for the period of time associated with the license purchase.

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

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

1.4.4 | License Monitoring

Abstract

Cortex XSIAM provides visibility into the status and summary of licenses associated with your tenant.

You can view the license types and add-ons associated with your instance in Settings → Cortex XSIAM License.

The Cortex XSIAM License dialog is made of the following sections.

License

For each license, displays a tile with the expiration date of your license and additional details specific to your license type:

Cortex XSIAM —Number of users, agents, and daily ingestion amount of agents.

Cortex XDR Cloud per Host—Total number of hosts collecting cloud-based data.

Cortex XDR Pro per Endpoint—Total number of installed agents in addition to the number and percentage of agents with Pro features enabled.

Endpoints Usage

The total number of installed agents and enabled data collection for endpoints and Cloud hosts.

XSIAM Daily Data Ingestion Usage

Link to the Data Ingestion dashboard which provides information about the type and amount of data ingested by Cortex XSIAM. You can determine which users
can view this dashboard under Settings → Configurations → Access Management.

Add-ons

Displays a tile with specific details for each add-on associated with your instance. Hover over the information icon to view a list of all available add-ons including
the start and expired dates.

For information on your data usage and storage license, select Settings → Configurations → Data Management → Dataset Management.

To keep you informed of updates made to your license and avoid service disruptions, Cortex XSIAM displays license notifications when you log in. The
notification identifies any changes made to your license and describes any required actions.

2 | Get Started
Abstract

Learn how to set up and get started with Cortex XSIAM.

Plan your deployment, activate, and configure your Cortex XSIAM app.

2.1 | Setup Overview

Abstract

Learn more about setting up Cortex XSIAM by activating the app and related apps and services.

Before you can use Cortex XSIAM for advanced detection and response, you must activate the Cortex XSIAM app and set up related apps and services.

Perform the setup activities in the steps below.

1. Plan Your Deployment.

As part of your planning, ensure that you or the person activating your tenant has the appropriate role permissions.

2. Set up Cortex XSIAM.

a. Activate

b. Assign User Roles and Permissions

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 23/1003
5/8/24, 9:18 AM PDF Export

c. Allocate Log Storage

3. Set up Palo Alto Networks Data Ingestion.

You can configure Cortex XSIAM to stream data from other Palo Alto Networks products directly to your tenant. To stream data directly, you need to first
deploy your network devices and then set up your Palo Alto Networks Integrations.

4. (Optional) Configure a mail sender integration

Cortex XSIAM provides a built-in mail sender integration. An email integration enables the server to send emails and can be used for system notifications
and playbooks. However, if you want to use a different email sender, you can configure one during your initial setup.

5. (Optional) Set Up Cloud Identity Engine.

a. Activate and Set Up a Cloud Identity Engine Instance.

b. Add the Cloud Identity Engine Instance to Cortex XSIAM.

6. Set up Endpoint Protection.

a. Plan your agent deployment.

b. Create agent installation packages.

c. Define endpoint groups.

d. Deploy the agent to your endpoints.

e. Configure your endpoint security policy.

7. Set up your Data Sources and Alert Sensors the following:

a. (Optional) Integrate additional threat intelligence.

b. After 24 hours, enable Cortex XSIAM Analytics Analysis.

1. Configure Network Coverage.

2. (Recommended) Activate Pathfinder to interrogate endpoints that do not have the Cortex XSIAM agent installed.

c. Define alert exclusions

d. Prioritize incidents based on attributes by creating an incident starring policy.

e. Import or configure rules for known BIOC and IOCs, and create any applicable Correlation Rules.

f. (Optional) Manage External Dynamic Lists

8. (Optional) Set up Outbound Integration.

Integrate with Slack.

Integrate with a Syslog Server.

Integrate with Cortex XSIAM.

9. (Optional) Set up Managed Security.

10. (Optional) Set up a Cortex XSIAM development tenant.

11. Use the Interface.

2.2 | Plan Your Deployment

Abstract

Learn more about the deployment considerations for your deployment type.

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

Determine the amount of log storage you need for your Cortex XSIAM deployment. Talk to your partner or sales representative to determine whether you
must purchase additional storage within the Cortex XSIAM tenant.

Determine the region in which you want to host Cortex XSIAM and any associated services, such as Directory Sync Service. If you plan to stream data
from a Cortex Native Data Lake instance, it must be in the same region as Cortex XSIAM.

Review the Cortex XDR agent support for operating systems and versions. For more information, see the Cortex XDR compatibility matrix.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 24/1003
5/8/24, 9:18 AM PDF Export

2.2.1 | Cortex XSIAM supported regions

Abstract

List of supported regions in which you want to host Cortex XSIAM and any associated services.

The following table lists the regions available to host Cortex XSIAM and any associated services:

Country Description

United States (US) All Cortex XSIAM logs and data remain within the boundaries of the United States.

United Kingdom All Cortex XSIAM logs and data remain within the boundaries of the United Kingdom.
(UK)

Europe (EU) All Cortex XSIAM logs and data remain within the boundaries of Europe.

Singapore (SG) All Cortex XSIAM logs and data remain within the boundaries of Singapore.

Japan (JP) All Cortex XSIAM logs and data remain within the boundaries of Japan.

Canada (CA) All Cortex XSIAM logs and data remain within the boundaries of Canada. However, if you have a WildFire Canada cloud subscription,
consider the following:

You cannot send file submissions for bare-metal analysis.

You will not be protected against macOS-borne zero-day threats. However, you will receive protection against other macOS
malware in regular WildFire updates.

You will not be able to view file submissions in AutoFocus.

Australia (AU) All Cortex XSIAM logs and data remain within the boundaries of Australia.

Germany (DE) All Cortex XSIAM logs and data remain within the boundaries of Germany.

India (IN) All Cortex XSIAM logs and data remain within the boundaries of India.

Switzerland (CH) All Cortex XSIAM logs and data remain within the boundaries of Switzerland.

Poland (PL) All Cortex XSIAM logs and data remain within the boundaries of Poland.

Taiwan (TW) All Cortex XSIAM logs and data remain within the boundaries of Taiwan.

Qatar (QT) All Cortex XSIAM logs and data remain within the boundaries of Qatar.

France (FR) All Cortex XSIAM logs and data remain within the boundaries of France.

Israel (IL) All Cortex XSIAM logs and data remain within the boundaries of Israel.

Saudi Arabia (SA) All Cortex XSIAM logs and data remain within the boundaries of Saudi Arabia.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 25/1003
5/8/24, 9:18 AM PDF Export

Country Description

Indonesia (ID) All Cortex XSIAM logs and data remain within the boundaries of Indonesia.

2.3 | Activate
Abstract

Learn how to activate Cortex XSIAM after it has been deployed for your network.

To activate and manage user permissions of your Cortex XSIAM tenants, Cortex XSIAM operates as a standalone application known as the Gateway.

The Gateway allows you to:

Activate new tenants.

View and manage existing tenants and tenants available for activation that are allocated to your Customer Support Portal (CSP) account.

View and manage granular role-based access control (RBAC) settings.

NOTE:

The sizing calculator is managed on the hub.

Activating a Cortex XSIAM tenant is a one-time task you’ll need to perform when you first start using Cortex XSIAM. After you’ve activated your Cortex XSIAM
tenant—and completed all the steps described in the Setup Overview section—you’ll only need to repeat the activation if you want to add additional Cortex
XSIAM tenants.

The following are prerequisites to activate Cortex XSIAM:

Locate the email that contains your activation information.

Ensure you have CSP Super User role permissions to your existing administrator accounts. This role cannot be removed or changed through the
Gateway.

Activate your tenant

To activate your Cortex XSIAM tenant:

1. Navigate to the activation link you received in the email and sign in to begin activation in the Cortex Gateway.

NOTE:

As a first user with CSP Super User permissions to access the Gateway, you are automatically granted Account Admin permissions to the Gateway.
With these permissions, you are able to activate Cortex XSIAM tenants, create new roles, and assign permissions to users allocated to your tenant.

The Gateway displays tenants Available for Activation and Available Tenants.

In the Available for Activation section, you can view all the tenants allocated to your CSP account that are ready for activation. You can review the tenant
details, such as license type, number of endpoints, Strata Logging Service, and purchase date.

The Available Tenants section lists tenants that have already been activated. If you have more than one CSP account, the tenants are displayed according
to the CSP account name.

2. In the Available for Activation section, locate the tenant you want to activate according to the serial number and Activate to launch the Tenant Activation
wizard.

3. In Tenant Activation → Select Support Account, ensure the tenant you want to activate is allocated to the correct CSP account. You can expand Cortex
XSIAM to view the tenants associated with the CSP account.

NOTE:

If you manage multiple company CSP accounts, make sure you select the specific account to which you want to allocate the Cortex XSIAM tenant
before proceeding with activation. Once activated, the tenant will be associated with the account, and cannot be moved.

Strata Logging Service licenses created as a part of existing Cortex XSIAM Licenses will remain intact until the end of your remaining contract.

4. In Tenant Activation → Define Tenant Settings, define the following tenant details.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 26/1003
5/8/24, 9:18 AM PDF Export

Tenant Name—Give your Cortex XSIAM app instance an easily-recognizable name. Choose a name that has 59 or fewer characters and is unique
across your company account.

Region—Select a region in which you want to set up your Cortex XSIAM instance. Setting up a new or existing Strata Logging Service instance can
only be in the scope of the same region.

Tenant Subdomain—Give your Cortex XSIAM instance an easy-to-recognize name that is used to access the tenant directly using the full URL
(https://<subdomain>.xdr.<region>.paloaltonetworks.com).

NOTE:

Note this is a public FQDN, so be careful with sensitive information such as the company name.

Review and agree to the terms and conditions of the Privacy policy, Term of Use, EULA.

5. Activate your tenant.

Activation can take up to an hour. Cortex XSIAM sends a notification to your email when the tenant has completed the activation process.

6. Select Back to main gateway and in the Available Tenant section, search for your tenant name. Hover over a tenant to display the Tenant Status and
License Details. When the tenant displays an Active status, select the tenant name to confirm you can successfully access the Cortex XSIAM
management console.

7. (Optional) You can choose to change your tenant subdomain or tenant name following activation.

Hover over the tenant you want to update and select the ellipsis. Choose either Change Tenant Subdomain or Change Tenant Name to open the
corresponding dialog.

8. Continue to assign user roles and permissions.

Activate your tenant with your own keys (BYOK)

All data stored by Cortex XSIAM is encrypted at rest using a dedicated key management system. Cortex XSIAM provides strict key access controls and auditing,
and encrypts user data at rest according to AES-256 encryption standards. We recommend all our customers use this default system.

When creating new tenants, you can import your own encryption keys and use them to encrypt your Cortex XSIAM data at rest using the same key management
systems used by Cortex XSIAM by default.

To bring your own keys (BYOK), you must generate a key and encrypt it twice using two separate wrapping keys provided to you by Cortex XSIAM to create two
wrapped keys. A wrapping key is used to encrypt another key to store it or transmit it securely over an insecure channel.

NOTE:

You can only bring your own keys when creating new tenants.

To activate your Cortex XSIAM tenant using your own keys:

1. Create a Technical Case with the following specifications:

Select your product under AI-Driven Security Operations Platform as Cortex XSIAM.

Confirm the Issue Category as Server (Cloud).

Select Provide Additional Information.

Under Custom Technology Analysis, for Problem Concentration, select Activation.

You will receive a notification about when you can continue with the tenant activation.

2. After you receive the notification, navigate to the activation link you received in the email and sign in to begin activation in the Cortex Gateway.

NOTE:

As a first user with CSP Super User permissions to access the Gateway, you are automatically granted Account Admin permissions to the Gateway.
With these permissions, you are able to activate Cortex XSIAM tenants, create new roles, and assign permissions to users allocated to your tenant.

The Gateway displays tenants Available for Activation and Available Tenants.

In the Available for Activation section, you can view all the tenants allocated to your CSP account that are ready for activation. You can review the tenant
details, such as license type, number of endpoints, Strata Logging Service, and purchase date.

The Available Tenants section lists tenants that have already been activated. If you have more than one CSP account, the tenants are displayed according
to the CSP account name.

3. In the Available for Activation section, locate the tenant you want to activate according to the serial number and Activate to launch the Tenant Activation
wizard.

4. In Tenant Activation → Select Support Account, ensure the tenant you want to activate is allocated to the correct CSP account. You can expand Cortex
XSIAM to view the tenants associated with the CSP account.

NOTE:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 27/1003
5/8/24, 9:18 AM PDF Export

If you manage multiple company CSP accounts, make sure you select the specific account to which you want to allocate the Cortex XSIAM tenant
before proceeding with activation. Once activated, the tenant will be associated with the account, and cannot be moved.

Strata Logging Service licenses created as a part of existing Cortex XSIAM Licenses will remain intact until the end of your remaining contract.

5. In Tenant Activation → Define Tenant Settings, define the following tenant details.

Tenant Name—Give your Cortex XSIAM app instance an easily-recognizable name. Choose a name that has 59 or fewer characters and is unique
across your company account.

Region—Select a region in which you want to set up your Cortex XSIAM instance. Setting up a new or existing Strata Logging Service instance can
only be in the scope of the same region.

Tenant Subdomain—Give your Cortex XSIAM instance an easy-to-recognize name that is used to access the tenant directly using the full URL
(https://<subdomain>.xdr.<region>.paloaltonetworks.com).

NOTE:

Note this is a public FQDN, so be careful with sensitive information such as the company name.

Make sure Enable Palo Alto Networks managed data encryption keys is selected.

Review and agree to the terms and conditions of the Privacy policy, Term of Use, EULA.

6. Activate your tenant.

Activation can take up to an hour. Cortex XSIAM sends a notification to your email when the tenant has completed the activation process.

7. (Optional) You can choose to change your tenant subdomain or tenant name following activation.

Hover over the tenant you want to update and select the ellipsis. Choose either Change Tenant Subdomain or Change Tenant Name to open the
corresponding dialog.

8. After the activation, add the updated tenant details to the support ticket. To get your tenant details, click your user name in the navigation menu on the
bottom left, and under About, Copy to clipboard.

9. You will receive two wrapping keys which are valid for up to three days. After three days, you need to request new wrapping keys.

10. Generate a 32-byte encryption key in an OpenSSL editor with the following command. You can do this manually or using your key management tool.

openssl rand 32 <FILENAME>

This is the key that will be used for all encryption and decryption operations of your data. The key must be 32 bytes, in binary format, and not encoded.

11. Using the first wrapping key you received, wrap the key you generated in step 10. For wrapping the keys, use the following commands in an OpenSSL
editor with the CKM_RSA_AES_KEY_WRAP scheme. For more information about key wrapping, see the Google Cloud Key Management
documentation.

openssl pkeyutl \
-encrypt \
-pubin \
-inkey <WRAPPING_KEY_FULL_PATH> \
-in <YOUR_32_BYTE_KEY_FULL_PATH> \
-out <TARGET_WRAPPED_KEY_FULL_PATH> \
-pkeyopt rsa_padding_mode:oaep \
-pkeyopt rsa_oaep_md:sha256 \
-pkeyopt rsa_mgf1_md:sha256

12. Using the second wrapping key you received, wrap the key you generated in step 10, as above. You now have two wrapped keys.

13. Send the two wrapped keys to Cortex Support within 24 hours from when you received the wrapping keys.

The Cortex XSIAM team creates your tenant using your shared keys to encrypt all your tenant data and notifies you when the tenant is ready.

14. Continue to assign user roles and permissions.

2.4 | Deploy your Network Devices

Topic Not Found

2.5 | Manage User Roles

Abstract

Learn more about assigning and managing roles and permissions of any particular user of Cortex XSIAM.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 28/1003
5/8/24, 9:18 AM PDF Export

Role-based access control (RBAC) enables you to manage roles or specific permissions, and assign access rights to administrative users in the following areas
in Cortex XSIAM , where the role options to configure change slightly depending on where you access these RBAC settings.

Gateway—Select Tenant Navigator → Cortex Gateway → Permission Management where you can define Permission Management for one or more
tenants by selecting the Permissions and Roles subcategories.

Cortex XSIAM Access Management—Select Settings → Configurations → Access Management where you can define Access Management for a
specific tenant by selecting the Users, Roles, and User Groups subcategories. In addition, you can also set manage user access permissions for the
various Cortex Query Language (XQL) datasets as part of managing roles.

You can manage roles for all Cortex XSIAM apps and services. By assigning roles, you enforce the separation of viewing access and initiating actions among
functional or regional areas of your organization. Cortex XSIAM provides a number of predefined Palo Alto Networks roles to assign access rights to Cortex
XSIAM users.

2.5.1 | Permission Management

Abstract

Learn more about managing roles and permissions for tenants using the Permission Management console.

You can manage roles and permissions for a single tenant or a number of tenants at the same time using the Cortex XSIAM Permission Management console,
which is accessible via the Cortex Gateway. The Permission Management console is used for first-time activations. To create and assign roles, you must first
activate your Cortex XSIAM tenant and be assigned an Account Admin role in the Gateway.

The Permission Management console is divided into two subcategories, Permissions and Roles, which you can view on separate pages.

In the Permissions page, Cortex XSIAM lists all the users allocated to a specific Customer Support Portal (CSP) account and tenant name. If a user is not listed,
ensure that the user is added to the Customer Support Portal. The Permissions table provides different fields of information as detailed below. You can select
whether to Show User Subset to display only the users who are not designated as Hidden users (default). For example, this is useful when you have users, who
are not related to Cortex XSIAM and will not be designated with a Cortex XSIAM role, such as CSP Super Users, and you want to hide them from the list. You
can also select whether to View By Users (default) or Tenants.

NOTE:

Groups and Group Roles can only be configured in Cortex XSIAM in the Settings → Configurations → Access Management → User Groups page. For more
information, see the Manage User Groups section.

User Name—Displays the first and last name of the user and whether the user is a CSP Super User and Account Admin. If the user is allocated to more
than one tenant, expand the user name to display the details for each tenant.

Email—Email address of the user.

Tenant—Name of the tenant the user has permission to access. Next to the user name, expand ( ) to view the tenant name.

User Type—Indicates whether the user was defined in Cortex XSIAM using the CSP (Customer Support Portal), SSO (single sign-on) using your
organization’s IdP, or both CSP/SSO.

Direct XDR Role—Name of the role assigned specifically to the user that is not inherited from somewhere else, such as a User Group. Next to the user
name, expand ( ) to view the role assigned per tenant, if the user does not have any Cortex XSIAM access permissions that are assigned specifically to
them, the field displays No-Role.

Groups—Lists the groups that a user belongs to, where any group imported from Active Directory has the letters AD added beside the group name.

Group Roles—Lists the different group roles based on the groups the user belongs to. When you hover over the group role, the group associated with this
role is displayed.

Last Login Time—Last date and time the user accessed the tenant.

Status—Displays whether the user is Active or Inactive.

In the Roles page, Cortex XSIAM lists the pre-defined user roles and custom-defined roles. Use roles to assign specific view and action access privileges to
administrative user accounts. The way you configure administrative access depends on the security requirements of your organization. The built-in roles provide
specific access rights that cannot be changed. The roles you create provide more granular access control.

The Roles table provides the following fields of information.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 29/1003
5/8/24, 9:18 AM PDF Export

Role Name—Name of the role.

Created By—Displays one of the following options depending on whether the role is a custom role created by a user or a predefined role.

Palo Alto Networks—Predefined role granting user permissions in all tenants.

<user email address> —A custom role created in the Gateway granting user permission in all tenants.

<user email address> —A custom role created in the Cortex XSIAM app granting user permission for that specific tenant alone.

Tenant—Name of the tenant the role applies to according to where the role was created; Gateway or Cortex XSIAM app.

Description—Description of the role.

Creation Time—Date and time when the role was created. The field is available for only a custom role.

Modification Time—Date and time of when the role was last updated. The field is available for only a custom role.

1. Select Tenant Navigator → Cortex Gateway → Permission Management.

2. Manage your Cortex XSIAM roles and permissions.

If you are managing more than one CSP account, select the account you want to display the available roles. If you only manage one CSP account, Cortex
XSIAM only displays the roles available on your tenant.

In the Roles table, the following options are available to help you manage roles.

Create a custom role based on the Cortex XSIAM predefined roles.

1. Locate the predefined role that you want to base your custom role on, right-click and select Save As New Role.

2. In the Create Role window, specify a Role Name and update the Description.

3. Update the Views and Actions permissions you want the role to include and Create the role.

Create and save new roles based on the granular permission.

1. Select New Role.

2. In the Create Role window, specify a Role Name and Description.

3. Select the Views and Actions permissions you want the role to include and Create the role.

Edit role permissions (only available for roles you create).

1. Locate the custom role you want to edit, right-click and select Edit Role.

2. In the Edit Role window, update the Views and Actions permissions you want the role to include and Edit the role.

3. Assign roles to a Cortex XSIAM user.

In the Permissions page, select the Account Name. The following options are available to help you manage permissions. You can assign roles to one or
more users at a time.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 30/1003
5/8/24, 9:18 AM PDF Export

Assign permissions to a user that does not have a role.

1. Hover over the user name and select , located to the right of the row, to Add Permissions.

2. In the Add Permissions window, select from the list of Available Tenants for which you want to grant permissions.

3. Select a role from either the Default Roles or Custom Roles you want to assign the user and Add the role to the user.

Update permission for users with an existing role.

1. Hover over the user name and select , located to the right of the row to Update Permissions.

2. In the Update Permissions window, select a role from either the Default Roles or Custom Roles you want to assign the user and Update the
role.

NOTE:

Allow up to ten minutes for the new role to be updated in the system.

Deactivate a user.

Locate the user you want to deactivate, right-click, and select Deactivate User.

NOTE:

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

Designate a user as hidden.

Locate the user you want to hide, right-click, and select Hide User. When a user is designated as hidden, the user will no longer be displayed in the
Permissions table when the table is configured to Show User Subset (default configuration).

Manage User Scope

Assign users to specific endpoint groups in your organization.

2.5.2 | Access Management

Abstract

Cortex XSIAM enables you to manage roles for a specific tenant using the Access Management console.

The Access Management console is accessible by selecting Settings → Configurations → Access Management. The console is divided into the following
subcategories, which you can view on separate pages.

Users—Manage users allocated to a specific tenant.

Roles—Manage roles for a specific tenant.

User Groups—Manage your user groups for a specific tenant.

Single Sign-On—Manage your single sign-on (SSO) integration with the Security Assertion Markup Language (SAML) 2.0 standard to authenticate system
users across enterprise-wide applications and websites with one set of credentials.

2.5.2.1 | Manage Users

Abstract

Learn more about managing users in the Access Management console.

In the Users page, Cortex XSIAM lists all the users allocated to a specific Customer Support Portal (CSP) account and tenant. If a user is not listed, ensure that
the user is added to the Customer Support Portal. The Users table provides different fields of information as detailed below. At the top of the page, you can
perform the following actions.

Import Multiple User Roles as a CSV (Comma-separated values) file. This import can be used to quickly add users who already belong to a CSP account
and assign them preexisting roles in Cortex XSIAM . You can use the Download example file to view the required format of the CSV file to upload and
replace the file contents with the data you want to upload, where the following columns must be included.

User email—The email address of the user belonging to a CSP account that you want to import.

Role Name—The name of the role that you want to assign to this user, where the role must already be created in Cortex XSIAM.

Is an account role (default=false)—A boolean value to define whether the user is designated with an Account Admin role in the Cortex Gateway. To
define this in the CSV file, set the value to TRUE; otherwise, the value is set to FALSE (default).

Show User Subset to display only the users who are not designated as Hidden users (default).

Search for something in the search box.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 31/1003
5/8/24, 9:18 AM PDF Export

The following is a description of the different columns in the Users table.

NOTE:

Certain fields are exposed and hidden by default. An asterisk (*) is beside every field that is exposed by default.

User Name*—Displays the first and last name of the user.

Email*—Email address of the user.

User Type*—Indicates whether the user was defined in Cortex XSIAM using the CSP (Customer Support Portal), SSO (single sign-on) using your
organization’s IdP, or both CSP/SSO.

Direct XDR Role*—Name of the role assigned specifically to the user that is not inherited from somewhere else, such as a User Group. When the user
does not have any Cortex XSIAM access permissions that are assigned specifically to them, the field displays No-Role.

Groups*—Lists the groups that a user belongs to, where any group imported from Active Directory has the letters AD added beside the group name.

NOTE:

If a user group has scoping permissions, the users in the group are granted permissions according to the user group settings, even if the user does not
have configured scope settings.

If a user is assigned to multiple user groups, which are mapped to different roles, or if the user is assigned to nested user groups, the user has the
highest level of privileges based on the combination of roles.

Group Roles*—Lists the different group roles based on the groups the user belongs to. When you hover over the group role, the group associated with
this role is displayed.

Scope—Lists the scope assigned to the user either directly or through a group based on tags. The family includes the tag types and the related tags of the
selected family.

NOTE:

Only visible if the Scope Based Access Control feature is enabled for the tenant.

Last Login Time*—Last date and time the user accessed the tenant.

Status*—Displays whether the user is Active or Inactive.

First Name—Displays the first name of the user.

Last Name—Displays the last name of the user.

You can also pivot (right-click) from rows and specific values in the table, where a number of different options are available to help you manage your Cortex
XSIAM users from this page. You can perform these actions on one or more users at a time.

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

In the Users page, a number of different options are available to help you manage users.

2. Manage your Cortex XSIAM users.

The following options are available to help you manage users, which you can perform on one or more users at a time.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 32/1003
5/8/24, 9:18 AM PDF Export

Update a user role for users with an existing role.

1. You can either hover over the user name and select the Update User Role icon ( ), located to the right of the row or right-click the user
name and select Update User Role. You can also select more than one user to set and manage a role for all these system users belonging to
the same group at once.

2. Select a Role from the list of default and custom roles that you want to assign the user.

NOTE:

You can only reduce the permissions of an Account Admin user via the Cortex Gateway.

3. Add a particular user to a group by selecting the User Groups from the list.

4. Show Accumulated Permissions for the user(s) based on the Role and User Groups assigned to the user(s). Role permissions are comprised
of different Components permissionsfor all roles and Dataset permissions are also included for custom roles. By default, All permissions are
displayed, which lists the combined permissions of every Role and User Group assigned to the user. You can also select the specific roles
assigned to the user, which enables you to compare available permissions based on the roles selected. This can help you understand how
the role permissions for a particular user are built. For example, if you need to isolate a specific component, the permissions are provided by
a particular Role or User Group.

5. Scope tab enables you to select the Tag Family and it's corresponding Tags. The user's permissions are based on the tags assigned to them.

NOTE:

Only visible if the Scope Based Access Control feature is enabled for the tenant.

Roles defined as administrator or a part of the admin group, can't be scoped.

If you select a tag family without specific tags, permissions apply to all tags in the family.

The scope is based only on the selected Tag Families. If you scope only based on tags from Family A, then Family B is disregarded
in scope calculations and considered as allowed.

6. Update User Role to save your changes to the user role.

Deactivate a user.

Locate the user you want to deactivate, right-click, and select Deactivate User.

NOTE:

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

When a user is deactivated, API keys that the user created are not revoked.

Remove a role assigned to a user.

When you remove a role, the role associated with the API keys is deleted.

If more than one role was associated with the API key, a yellow warning symbol appears next to the API key in the API key table. When you
hover over the symbol, a message indicates that some of the roles associated with the API key had been deleted.

If all roles associated with the API key are removed, a red warning symbol appears appears next to the API key in the API key table. When
you hover over that symbol, a message indicates that the key is no longer usable because it does not have a role associated with it. The API
key is still visible in the API table but it cannot be assigned.

1. Locate the user you want to remove the role from, right-click, and select Remove User Role.

2. Click Remove.

NOTE:

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

Designate a user as hidden.

Locate the user you want to hide, right-click, and select Hide User. When a user is designated as hidden, the user will no longer be displayed in the
Users table when the table is configured to Show User Subset (default configuration). This is useful, for example, when you have users, who are not
related to Cortex XSIAM and will not be designated with a Cortex XSIAM role, such as CSP Super Users, and you want to hide them from the list.

If enabled, delete a Single Sign-on (SSO) user.

1. Locate the SSO user you want to delete, right-click, and select Delete SSO User.

2. Click Delete.

Copy text to clipboard to copy text from a specific row field in the row of a user.

Copy entire row to copy the text from all the fields in a row of a user.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 33/1003
5/8/24, 9:18 AM PDF Export

2.5.2.2 | Manage Roles

Abstract

Learn more about managing roles in the Access Management console.

NOTE:

Managing Roles requires an Account Admin or Instance Administrator role. For more information, see Predefined User Roles.

You can manage roles for a specific tenant only using the Cortex XSIAM Access Management console.In addition, you can also set manage user access
permissions for the various Cortex Query Language (XQL) datasets as part of managing roles.

On the Roles page, Cortex XSIAM lists the predefined user roles and custom-defined roles. Use roles to assign specific view and action access privileges to
administrative user accounts. The way you configure administrative access depends on the security requirements of your organization. The built-in roles provide
specific access rights that cannot be changed. The roles you create provide more granular access control.

The following is a description of the different columns in the Roles table.

Role Name—Name of the role.

Created By—Displays either the email address of the user who created a custom role or for predefined roles one of the following options is displayed.

Palo Alto Networks—Predefined role granting user permissions in all tenants.

<user email address> —A custom role created in the gateway granting user permission to this tenant.

<user email address> —A custom role created in the Cortex XSIAM app granting user permission to this specific tenant.

Description—Description of the role.

Creation Time—Date and time when the role was created. The field is available for only a custom role.

Update Date—Date and time of when the role was last updated. The field is available for only a custom role.

Custom—Displays a boolean value of either Yes or No to indicate whether the role is a custom role.

When creating a New Role or editing an existing role, you can manage roles for all Cortex XSIAM apps and services in the Components tab of the Create Role
window. Role permissions for the various Cortex XSIAM components are listed according to the sidebar navigation in Cortex XSIAM . By assigning roles, you
enforce the separation of viewing access and initiating actions among functional or regional areas of your organization.

In addition, Cortex XSIAM supports XQL dataset permission enforcement as part of managing roles or specific permissions using role-based access control
(RBAC). The Datasets tab of the Create Role window is where you can enable or disable the access permissions for the various datasets listed. The Datasets
permissions control the dataset access across the entire product components, as opposed to the Components RBAC tab, which controls access to a specific
component. When a dataset component is enabled for a particular role, the Alert and Incidents pages display all the alerts and incidents, where information
about the datasets is included. By default, the Enable dataset access management feature is disabled, and users have access to all datasets. Once you enable
this feature, you need to define for each dataset type the access permissions you want to grant for the role.

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

2. Manage your Cortex XSIAM roles.

Cortex XSIAM only displays the roles available on your tenant. To view the roles and permissions for multiple tenants, see the Permission Management
section.

In the Roles table, the following options are available to help you manage roles.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 34/1003
5/8/24, 9:18 AM PDF Export

Create a custom role based on Cortex XSIAM predefined role.

1. Locate the predefined role that you want to base your custom role on, right-click, and select Save As New Role.

2. Specify a Role Name and update the Description.

3. In the Components tab, where the components are listed according to the sidebar navigation in Cortex XSIAM, update the role permissions
for each Cortex XSIAM component to None, View, or View/Edit. Some components have an additional actions level to define.

4. In the Datasets tab, the Enable dataset access management permissions feature is disabled by default, and the user role has access to all
datasets. By default, even if you are basing your role on a preexisting role with access to datasets, access management permissions are
disabled unless you enable them. Once you enable this feature, you need to define for each dataset type the access permissions you want to
grant for the role in any of the following ways, where the options differ depending on the dataset type.

-Select Access All to enable this role to access all datasets that currently exist for this dataset type.

-Select Future datasets to enable this role to access all datasets that will be created in the future for this dataset type.

-Select access to choose the specific datasets that you want this role to be able to access for this dataset type. By default, the specific
datasets are displayed. If not, select the expander icon (>) beside the dataset type to display the datasets that currently exist for this dataset
type.

To help you easily know whether the Enable dataset access management permissions feature is enabled or disabled without having to open
the tab, the tab either displays as Datasets (Disabled) or Datasets (Enabled).

5. Create the role.

Create and save new roles based on the granular permission.

1. Select New Role.

2. Specify a Role Name and Description.

3. In the Components tab, where the components are listed according to the sidebar navigation in Cortex XSIAM , update the role permissions
for each Cortex XSIAM component to None, View, or View/Edit. Some components have an additional action level to define.

4. In the Datasets tab, the Enable dataset access management permissions feature is disabled by default, and the user role has access to all
datasets. By default, even if you are basing your role on a preexisting role with access to datasets, access management permissions are
disabled unless you enable them. Once you enable this feature, you need to define for each dataset type the access permissions you want to
grant for the role in any of the following ways, where the options differ depending on the dataset type.

-Select Access All to enable this role to access all datasets that currently exist for this dataset type.

-Select Future datasets to enable this role to access all datasets that will be created in the future for this dataset type.

-Select access to choose the specific datasets that you want this role to be able to access for this dataset type. By default, the specific
datasets are displayed. If not, select the expander icon (>) beside the dataset type to display the datasets that currently exist for this dataset
type.

To help you easily know whether the Enable dataset access management permissions feature is enabled or disabled without having to open
the tab, the tab either displays as Datasets (Disabled) or Datasets (Enabled).

5. Create the role.

Edit role permissions (only available for roles created in the tenant).

1. Locate the custom role you want to edit, right-click, and select Edit Role.

2. In the Components tab of the Edit Role window, where the components are listed according to the sidebar navigation in Cortex XSIAM,
update the role permissions for each Cortex XSIAM component to None, View, or View/Edit. Some components have an additional action
level to define.

3. In the Datasets tab, you can enable and disable dataset access permissions for the various datasets listed as required.

4. Edit the role.

2.5.2.3 | Manage User Groups

Abstract

Learn more about managing user groups in the Access Management console.

In the User Groups page, you can manage user groups for a specific tenant.

At the top of the page, you can perform the following actions.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 35/1003
5/8/24, 9:18 AM PDF Export

Import a single existing group from Active Directory that you want to manage in Cortex XSIAM.

NOTE:

This feature is only available if you enabled the Cloud Identity Engine in Configurations → Integrations → Cloud Identity Engine.

Create a new user group for a number of different system users or groups.

The User Groups table provides the following fields of information.

Group Name—Name of the user group.

Description —Description of the user group.

Role—Lists the group role associated with this user group. You can only have a single role designated per group.

Users—Lists all the users belonging to this user group.

NOTE:

The user has a union of all scopes from all memberships if they are a part of multiple groups.

Nested Groups—Lists any nested groups associated with this user group.

IDP Groups—When single sign-on is enabled in Cortex XSIAM, this column indicates your organization's Identity Provider (IdP) groups that are
automatically mapped to the user group.

Insert Time—Date and time when the user group was added.

Update Time—Date and time of when the user group was last updated.

Source—Displays the source of the user group as either a user group imported from Active Directory or a Custom user group created in Cortex XSIAM.

Scope—Lists the scope assigned to the user either directly or through a group based on tags. The family includes the tag types and the related tags of the
selected family.

NOTE:

Only visible if the Scope Based Access Control feature is enabled for the tenant.

You can also pivot (right-click) from rows and specific values in the table, where a number of different options are available to help you manage your Cortex
XSIAM user groups from this page.

Save an existing group as a new group.

Edit a group.

Remove a group.

Copy text to clipboard.

Copy the entire row.

1. Select Settings → Configurations → Access Management → User Groups.

In the User Groups page, a number of different options are available to help you manage user groups.

2. Manage your Cortex XSIAM user groups.

The following options are available to help you manage user groups, which you can perform on one or more user groups at a time.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 36/1003
5/8/24, 9:18 AM PDF Export

Import a single existing group from Active Directory that you want to manage in Cortex XSIAM.

NOTE:

This feature is only available if you enabled the Cloud Identity Engine in Configurations → Integrations → Cloud Identity Engine.

1. Import AD Group.

2. Set the following parameters in the Import Group from Active Directory window.

Import AD Group—Specify the particular Active Directory group in the field and select whether the AD group can be found in All, OUs, or
Groups.

NOTE:

Only CSP users will be imported.

Specify a Description.

Role—Select a role that you want to designate for this user group, where only a single role can be assigned to a group.

3. Import the user group.

Create a new user group for a number of different system users or groups.

1. Select New Group.

2. Set the following parameters in the New Custom Group window.

-Specify the Name and Description for the user group.

-Role—(optional) Select a role that you want to designate for this user group, where only a single role can be assigned to a group.

-Users—(optional) Select the user(s) that you want to belong to this user group, where you can also use the search field to narrow down the
list of users.

-Nested Groups—(optional) Select the nested group(s) that you want to be associated with this user group.

-SAML Group Mapping—(optional) Specify the name of the group(s) in your organization’s Identity Provider (IdP) that you want to
automatically map to this user group in Cortex XSIAM . This option is only displayed when single sign-on is enabled.

NOTE:

When using Azure AD for SSO, the SAML group mapping needs to be provided using the group object ID (GUID) and not the group name.

-Tag Family—Select the tag category (Endpoint Tags, Endpoint Groups).

-Tags—After selecting the Tag Family, select the relevant tags associated with the family.

NOTE:

If you select a tag family without specific tags, permissions apply to all tags in the family.

The scope is based only on the selected Tag Families. If you scope only based on tags from Family A, then Family B is disregarded
in scope calculations and considered as allowed.

3. Create the user group.

Save an existing group as a new group.

1. Select the user group or right-click the user group, and select Save as New Group.

2. Set the following parameters in the New Custom Group window.

-Specify the Name and Description for the user group.

-Role—Leave the designated role or select a new role that you want to designate for this user group.

-Users—Leave the current user(s) or select the user(s) that you want to belong to this user group. You can also use the search field to narrow
down the list of users.

-Nested Groups—Leave the current nested group(s), select the nested group(s) that you want to be associated with this user group, or
remove all nested groups if you don’t want any defined.

-SAML Group Mapping—Leave the current IdP group name, specify the group(s) in your organization’s Identity Provider (IdP) that you want to
automatically map to this user group in Cortex XSIAM , or remove all IdP groups if you don’t want any defined. This option is only displayed
when single sign-on is enabled.

NOTE:

When using Azure AD for SSO, the SAML group mapping needs to be provided using the group object ID (GUID) and not the group name.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 37/1003
5/8/24, 9:18 AM PDF Export

-Tag Family—Leave the current family or select the relevant family.

-Tags—Leave the tags or select the relevant tags associated with the family.

NOTE:

If you select a tag family without specific tags, permissions apply to all tags in the family.

The scope is based only on the selected Tag Families. If you scope only based on tags from Family A, then Family B is disregarded
in scope calculations and considered as allowed.

3. Create the user group.

a. Select the user group or right-click the user group, and select Edit Group.

b. Set the following parameters in the Edit Custom Group window.

-Update the Name and Description for the user group.

-Role—Leave the designated role or select a new role that you want to designate for this user group.

-Users—Leave the current user(s) or select the user(s) that you want to belong to this user group. You can also use the search field to
narrow down the list of users.

-Nested Groups—Leave the current nested group(s), select the nested group(s) that you want to be associated with this user group, or
remove all nested groups if you don’t want any defined.

-SAML Group Mapping—Leave the current IdP group name, specify the group(s) in your organization’s Identity Provider (IdP) that you
want to automatically map to this user group in Cortex XSIAM , or remove all IdP groups if you don’t want any defined. This option is
only displayed when single sign-on is enabled.

-Tag Family—Leave the current family or select the relevant family.

-Tags—Leave the tags or select the relevant tags associated with the family.

NOTE:

If you select a tag family without specific tags, permissions apply to all tags in the family.

The scope is based only on the selected Tag Families. If you scope only based on tags from Family A, then Family B is
disregarded in scope calculations and considered as allowed.

c. Save your changes.

Edit a user group.

1. Select the user group or right-click the user group, and select Edit Group.

2. Set the following parameters in the Edit Custom Group window.

-Update the Name and Description for the user group.

-Role—Leave the designated role or select a new role that you want to designate for this user group.

-Users—Leave the current user(s) or select the user(s) that you want to belong to this user group. You can also use the search field to narrow
down the list of users.

-Nested Groups—Leave the current nested group(s), select the nested group(s) that you want to be associated with this user group, or
remove all nested groups if you don’t want any defined.

-SAML Group Mapping—Leave the current IdP group name, specify the group(s) in your organization’s Identity Provider (IdP) that you want to
automatically map to this user group in Cortex XSIAM , or remove all IdP groups if you don’t want any defined. This option is only displayed
when single sign-on is enabled.

NOTE:

When using Azure AD for SSO, the SAML group mapping needs to be provided using the group object ID (GUID) and not the group name.

-Tag Family—Leave the current family or select the relevant family.

-Tags—Leave the tags or select the relevant tags associated with the family.

NOTE:

If you select a tag family without specific tags, permissions apply to all tags in the family.

The scope is based only on the selected Tag Families. If you scope only based on tags from Family A, then Family B is disregarded
in scope calculations and considered as allowed.

3. Save your changes.

Remove a user group.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 38/1003
5/8/24, 9:18 AM PDF Export

1. To remove more than one user group, select the user groups, right-click, and select Remove Groups.

To remove one user group, select the user group or right-click the user group, and select Remove Group.

2. Click Delete in the window that is displayed.

Copy text to clipboard to copy text from a specific row field in the row of a user group.

Copy entire row to copy the text from all the fields in a row of a user group.

2.5.2.4 | Authentication Settings

Abstract

Configure single sign-on for a tenant and enable and configure external user authentication for communication tasks.

You can enable and configure single sign-on for your tenant and you can also enable and configure external user authentication for surveys sent using a
communication task.

2.5.2.5 | Manage Single Sign-On

Abstract

Learn how to easily and securely authenticate system users with one set of credentials using SSO with the SAML 2.0 standard.

After you activate your tenant, you can authenticate users by doing one or both of the following options:

User authentication in the Customer Support Portal

When you create a Customer Support Portal (CSP) account you can set up two-factor authentication (2FA) to log into the CSP, by using one of the
following:

Email

Okta Verify

Google Authenticator (non FedRAMP accounts)

For more information about setting up 2FA in the CSP, see Two Factor Authentication (2FA) Overview. You can also add an IdP, which is recommended.
See How to Enable a Third Party IdP.

When you add users to the CSP account, they are added as users in the Cortex Gateway and the tenant. By default, users have access to the Cortex
Gateway, but cannot make any changes in the Cortex Gateway unless they are Account Admins and cannot access a tenant until they are assigned a role
or group role.

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

NOTE:

If you have multiple tenants, you will need to repeat this task for each tenant. The activation process includes accessing the gateway, activating the
tenant, and then accessing the tenant.

SAML single sign-on in the Cortex XSIAM tenant

In the Cortex XSIAM tenant, users can be authenticated using your IdP provider such as Okta, Ping, or Azure AD. You can use any IdP that supports
SAML 2.0. You define authentication in your identity provider’s account and configure the SSO settings in Cortex XSIAM.

There are several advantages to authenticating with SAML 2.0 versus a Customer Support Portal (CSP) account.

Removes the administrative burden of requiring separate accounts issued through the Customer Support Portal.

Enforces multi-factor authentication (MFA) and any conditional access policies on the user login at the IdP before granting a user access to Cortex
XSIAM.

Maps SAML group memberships to Cortex XSIAM user groups and roles, allowing you to manage role-based access control.

Removes access to Cortex XSIAM when a user is removed or disabled at the IdP.

If you want to rely on CSP authentication, it is useful where you have one CSP account and want the same users to have permissions in several tenants.

2.5.2.5.1 | Configure Single Sign-On Using SAML 2.0

Abstract

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 39/1003
5/8/24, 9:18 AM PDF Export

Learn how to easily and securely authenticate system users with one set of credentials using SSO with the SAML 2.0 standard.

Cortex XSIAM enables you to securely authenticate system users across enterprise-wide applications and websites with one set of credentials using single sign-
on (SSO) with SAML 2.0. System users can authenticate using your organization's Identity Provider (IdP).

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

To configure SSO, you must have the Instance Administrator or Account Admin role.

NOTE:

SAML 2.0 users must log in to Cortex XSIAM using the FQDN (full URL) of the tenant. To allow login directly from the IdP to Cortex XSIAM, you must
set the relay state on the IdP to the FQDN of the tenant.

If you have multiple tenants, you must set up the SSO configuration separately for each tenant, both in the IdP and in Cortex XSIAM.

Create groups in your IdP that correspond to the roles in Cortex XSIAM and assign users to those groups in your IdP. Users can belong to multiple
groups and receive permissions associated with multiple roles. Add the appropriate SAML group mapping from your IdP to each Cortex XSIAM role.

Cortex XSIAM requires the IdP to send the group membership as part of the SAML token. Some IdPs send values in a format that include a comma,
which is not compatible with Cortex XSIAM. In that case, you must configure your IdP to send a single value without a comma for each group
membership. For example, if your IdP sends the Group DN (a comma separated list), by default, you must configure IdP to send the the Group CN
(Common Name) instead.

If you are configuring Okta or Azure, follow the procedure in Okta and Azure AD. You can also adapy these instructions with any similar SAML 2.0 IdP.

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

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

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

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

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

NOTE:

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

The Domain parameter is predefined for the first SSO. You need to set it for added SSOs.

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

When mapping IdP user groups to Cortex XSIAM user groups, you must include the group attribute for each IdP you want to use. For example, if
you are using Microsoft Azure and Okta, your Cortex XSIAM user group SAML Group Mapping field must include the IdP groups for each
provider. Each group name is separated by a comma.

4. Set the following parameters using your organization’s IdP.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 40/1003
5/8/24, 9:18 AM PDF Export

General

Parameter Description

IdP SSO or Metadata URL Select the option that meets your organization's requirements.

Indicates your SSO URL, which is a fixed, read-only value based on your
tenant's URL using the format https://<name of Cortex-
Tenant>.paloaltonetworks.com/idp/saml. For
example, https://tenant1.Cortex
XSIAM.paloaltonetworks.com/idp/saml

You need this value when configuring your IdP.

IdP SSO URL Specify your organization’s SSO URL, which is copied from your organization’s
IdP.

Metadata URL

Audience URI (SP Entity ID) Indicates your Service Provider Entity ID, also known as the ACS URL. It is a
fixed, read-only value using the format, https://<name of Cortex-
Tenant>.paloaltonetworks.com. For
example https://tenant1.xdr.paloaltonetworks.com.

You need this value when configuring your organization’s IdP.

Default Role (Optional) Select the default role that you want any user to automatically
receive when they are granted access to Cortex XSIAM through SSO. This is
an inherited role and is not the same as a direct role assigned to the user.

IdP Issuer ID Specify your organization’s IdP Issuer ID, which is copied from your
organization’s IdP.

X.509 Certificate Specify your X.509 digital certificate, which is copied from your organization’s
IdP.

Domain Relevant only for multiple SSOs. For one SSO, this is a fixed, read-only value.
Associate this IdP with a specific email domain (user@<domain>). When
logging in, users are redirected to the IdP associated with their email domain or
to the default IdP if no association exists.

IdP Attribute Mappings

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

Parameter Description

Email Specify the email mapping according to your organization’s IdP.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 41/1003
5/8/24, 9:18 AM PDF Export

Parameter Description

Group Membership Specify the group membership mapping according to your organization’s IdP.

NOTE:

Cortex XSIAM requires the IdP to send the group membership as part of the
SAML token. Some IdPs send values in a format that include a comma,
which is not compatible with Cortex XSIAM. In that case, you must configure
your IdP to send a single value without a comma for each group
membership. For example, if your IdP sends the Group DN (a comma
separated list), by default, you must configure IdP to send the the Group CN
(Common Name) instead.

First Name Specify the first name mapping according to your organization’s IdP.

Last Name Specify the last name mapping according to your organization’s IdP.

Advanced Settings (Optional)

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

Parameter Description

Relay State (Optional) Specify the URL for a specific page that you want users to be
directed to after they’ve been authenticated by your organization’s IdP and
log in to Cortex XSIAM.

IdP Single logout URL (Optional) Specify your IdP single logout URL provided from your
organization’s IdP to ensure that when a user initiates a logout from Cortex
XSIAM, the identity provider logs the user out of all applications in the current
identity provider login session.

SP Logout URL (Optional) Indicates the Service Provider logout URL that you need to provide
when configuring single logout from your organization’s IdP to ensure that
when a user initiates a logout from Cortex XSIAM, the identity provider logs
the user out of all applications in the current identity provider login session.
This field is read-only and uses the following format https://<name of
Cortex-Tenant>.paloaltonetworks.com/idp/logout, such
as https://tenant1.xdr.paloaltonetworks.com/idp/logout.

Service Provider Public Certificate (Optional) Specify your organization’s IdP service provider public certificate.

Service Provider Private Key (Pem Format) (Optional) Specify your organization’s IdP service provider private key in Pem
Format.

Allow users to log in without entering a password (Optional) Select if you want to enable your users to log in to Cortex XSIAM
without any further authentication if they're already logged in to your IdP,
including when the IdP uses multi-factor authentication.

Force Authentication (Optional) If the IdP requires reauthentication, the users will be prompted to
perform a full login.

5. Save your changes.

When a user logs in to Cortex XSIAM, the following login options are available. If you selected Allow users to log in without entering a password above,
these options won't be displayed and the user will be logged in without a reauthentication request.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 42/1003
5/8/24, 9:18 AM PDF Export

Sign-in with SSO: Authenticates using your organization’s IdP, such as Okta or Azure AD.

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

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

Sign-in with your CSP credentials: Users log in with their Customer Support Portal (CSP) credentials, provided they have been added as a user
through the CSP.

2.5.2.5.2 | Set up Azure AD as the Identity Provider Using SAML 2.0

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

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

Step 1: Configure Azure AD Security Groups

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

Step 2: Copy Single SSO and Audience URI Values from Cortex XSIAM

1. In Cortex XSIAM go to Settings → Configurations → Access Management → Single Sign-On.

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

3. Expand the SSO Integration settings.

4. Copy and save the values for Single Sign-On URL and Audience URI (SP Entity ID). Both values are needed to configure your IdP settings.

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

Step 3: Configure Cortex XSIAM Application in Azure AD

1. From within Azure AD, create a Cortex XSIAM application and Edit the Basic SAML Configuration.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 43/1003
5/8/24, 9:18 AM PDF Export

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

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 44/1003
5/8/24, 9:18 AM PDF Export

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

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

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 45/1003
5/8/24, 9:18 AM PDF Export

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

Email address

First Name

Last Name

Step 4: Copy Login URL, Azure ID Identifier, and Attribute Claims

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

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

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 46/1003
5/8/24, 9:18 AM PDF Export

NOTE:

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

Step 5: Download the Certificate

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

Step 6: Copy the Source IDs for Azure AD Security Groups

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

Step 7: Configure the Cortex XSIAM SSO Integration

1. In Cortex XSIAM go to Settings → Configurations → Access Management → Single Sign-On.

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

3. Expand the SSO Integration settings.

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

Azure AD Cortex XSIAM Field

Login URL IdP SSO URL

Azure AD Identifier IdP Issuer ID

Contents of the downloaded certificate file. X.509 Certificate

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 47/1003
5/8/24, 9:18 AM PDF Export

5. In the IdP Attributes Mapping section, enter the attribute claim names from Azure AD. The names are case-sensitive and must match exactly.

6. (Optional) Under Advanced Settings, select the checkboxes for ADFS and Compress encode URL (ADFS). In some circumstances, these fields may be
required by your Azure AD configuration.

7. Save your settings.

Step 8: Map SAML Group Memberships to Cortex XSIAM User Groups

1. Select Settings → Configurations → Access Management → User Groups.

2. Right-click a user group and select Edit Group.

3. In the SAML Group Mapping field add the Azure AD group(s) Object Ids that should be associated with this user group. Multiple Object Ids should be
separated with a comma. The Azure AD group Object Id must match the exact value sent in the token.

4. Save your settings.

5. Repeat for each user group.

Step 9: Test SSO Login

NOTE:

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

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

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

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

To view your role and any user group role in which you belong, click your name in the bottom left-hand corner, and click About window.

2.5.2.5.3 | Set up Okta as the Identity Provider Using SAML 2.0

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

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

Step 1: Configure Okta Groups

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

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

Step 2: Copy Single SSO and Audience URI Values from Cortex XSIAM

1. In Cortex XSIAM go to Settings → Configurations → Access Management → Single Sign-On.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 48/1003
5/8/24, 9:18 AM PDF Export

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

3. Expand the SSO Integration settings.

4. Copy and save the values for Single Sign-On URL and Audience URI (SP Entity ID). Both values are needed to configure your IdP settings.

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

Step 3: Configure Cortex XSIAM Application in Okta

1. From within Okta, create a Cortex XSIAM application and Edit the SAML Settings.

2. Paste the Single sign-on URL and the Audience URI (SP Entity ID) that you copied from the Cortex XSIAM SSO settings. The Audience URI should also
be pasted in the Default RelayState field. This allows users to log in to Cortex XSIAM directly from the Okta dashboard.

3. Show Advanced Settings, verify that Okta is configured to sign both the response and the assertion signature for the SAML token, and then Hide
Advanced Settings.

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

Email address

Group membership

First Name

Last Name

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

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

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

1. In Okta, from your Cortex XSIAM application page, click View SAML setup instructions. If you do not see this button, verify you are on the Sign On tab of
the application.

2. Copy and save the values for Identity Provider Single Sign-On URL , Identity Provider Insurer, and the X.509 Certificate. These values are needed to
configure your Cortex XSIAM SSO Integration.

Step 5: Configure the Cortex XSIAM SSO Integration

1. Select Settings → Configurations → Access Management → Single Sign-On.

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

3. Expand the SSO Integration settings.

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

Okta Cortex XSIAM Field

Identity Provider Single Sign-On URL IdP SSO URL

Identity Provider Issuer IdP Issuer ID

X.509 Certificate X.509 Certificate

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

6. Save your settings.

Step 6: Map SAML Group Memberships to Cortex XSIAM User Groups

1. Select Settings → Configurations → Access Management → User Groups.

2. Right-click a user group and select Edit Group.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 49/1003
5/8/24, 9:18 AM PDF Export

3. In the SAML Group Mapping field add the Okta group(s) that should be associated with this user group. Multiple groups should be separated with a
comma. The Okta group name must match the exact value sent in the token.

4. Save your settings.

5. Repeat for each user group.

Step 7: Test SSO Login

NOTE:

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

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

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

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

To view your role and any user group role in which you belong, click your name in the bottom left-hand corner, and click About.

2.5.2.5.4 | Troubleshoot SAML 2.0 Issues

The following lists common errors and issues when using SAML 2.0 authentication.

Errors at your IdP could mean the Service Provider Entity ID and/or Service Identifier are not properly configured in the IdP or in the Cortex XSIAM
settings.

SAML attributes from the IdP are not properly mapped in Cortex XSIAM. The attributes are case sensitive and must exactly match in your IdP and in the
Cortex XSIAM IdP Attributes Mapping.

Group memberships from the IdP have not been properly mapped to Cortex XSIAM user groups. Verify the values your identity provider is sending, in
order to properly map the groups in Cortex XSIAM.

The identity provider is not configured to sign both the SAML response and the assertion on the login token. Your IdP must be configured to sign both to
ensure a secure login.

If you require further troubleshooting, we recommend using your browser's built-in developer tools or additional browser plugins to capture the login
request and SAML token.

2.5.2.5.5 | Use Multiple SAML 2.0 Providers

In Cortex XSIAM, you can use multiple SAML SSO providers.

To view providers, go to Settings → Configurations → Access Management → Authentication Settings. To add an additional provider, Add SSO Connection.

When using two or more SSO providers:

The first provider in the list is used as the default SSO provider. The Domain parameter is predefined for the first SSO.

If you add additional SSO providers, you must provide the email Domain in the SSO Integration settings for all providers except the first. Cortex XSIAM
uses this domain to determine which identity provider the user should be sent to for authentication. At the Cortex XSIAM login page, if you have enabled
more than one SSO provider, an optional email field displays above the Sign-In with SSO button. If the user does not enter an email address in this field or
if the email address does not match an existing domain, the user is automatically directed to the default IdP provider (the first in the list of SSO providers).
If the user enters an email address and it matches a domain listed in the email Domain field in the SSO Integration settings for one of your IdPs, Sign-In
with SSO sends the user to the IdP associated with that email domain.

When mapping IdP user groups to Cortex XSIAM user groups, you must include the group attribute for each IdP you want to use. For example, if you are
using Microsoft Azure and Okta, your Cortex XSIAM user group SAML Group Mapping field must include the IdP groups for each provider. Each group
name is separated by a comma.

2.5.3 | Predefined User Roles

Abstract

Learn more about predefined roles to easily assign user access to Cortex XSIAM views and actions.

Role-based access control (RBAC) enables you to use predefined Palo Alto Networks roles to assign access rights to Cortex XSIAM users. You can manage
roles for all Cortex XSIAM apps and services in the Gateway and Cortex XSIAM management console. By assigning roles, you enforce the separation of access
among functional or regional areas of your organization.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 50/1003
5/8/24, 9:18 AM PDF Export

Each role extends specific privileges to users. The way you configure administrative access depends on the security requirements of your organization. Use
roles to assign specific access privileges to administrative user accounts.

You can manage role permissions in Cortex XSIAM , which are listed by the various components according to the sidebar navigation in Cortex XSIAM. Some
components include additional action permissions, such as pivot (right-click) options, to which you can also assign access, but only when you’ve given the user
View/Edit permissions to the applicable component.

The default Palo Alto Networks roles provide a specific set of access rights to each role. You cannot edit the default roles directly, but you can save them as new
roles and edit the permissions of the new roles. To view the predefined permissions for each default role, go to Settings → Configurations → Access
Management → Roles.

NOTE:

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

Default Role Description

Account Admin The Account Admin has full access to the given app(s), including all
instances added to the app(s) in the future. The account admin can assign
roles for app instances, and can also activate app instances specific to the
app.

Instance Administrator A Instance Administrator has full access to the app instance for which this
role is assigned. The Instance Administrator can also make other users an
Instance Administrator for the app instance. If the app has predefined or
custom roles, the Instance Administrator can assign those roles to other
users.

Deployment Admin A Deployment Admin can manage and control endpoints and installations,
and configure Broker VMs.

Investigator An Investigator can view and triage alerts and incidents.

Investigation Admin An Investigation Admin can view and triage alerts and incidents, configure
rules, view endpoint profiles and policies, and analytics management
screens.

Responder A Responder can view and triage alerts, and access all response
capabilities excluding Live Terminal.

Privileged Investigator A Privileged Investigator can view and triage alerts, incidents, and rules,
view endpoint profiles and policies, and analytics management screens.

Privileged Responder A Privileged Responder can view and triage alerts and incidents, access all
response capabilities, and configure rules, policies, and profiles.

IT Admin An IT Admin can manage and control endpoints and installations, configure
Broker VMs, view endpoint profiles and policies, and view alerts.

Privileged IT Admin A Privileged IT Admin can manage and control endpoints and installations,
configure Broker VMs, create profiles and policies, view alerts, and initiate
Live Terminal.

Privileged Security Admin A Privileged Security Admin can triage and investigate alerts and incidents,
and respond to and edit profiles and policies.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 51/1003
5/8/24, 9:18 AM PDF Export

Default Role Description

Viewer The Viewer can view the majority of the features for this instance and can
edit reports.

Scoped Endpoint Admin The Scoped Endpoint Admin has access only to product areas that support
endpoint scoped based access control (SBAC) - Endpoint Administration,
Action Center, Response, Dashboards and Reports.

Security Admin The Security Admin can triage and investigate alerts and incidents, respond
(excluding Live Terminal), and edit profiles and policies.

App Service Account The default role for Apps, the App Service Account role enables the user to
query data, trigger alerts, and support public APIs.

2.5.4 | Manage User Scope

Abstract

Cortex XSIAM supports the scoping of users to particular endpoint groups.

With Scope-Based Access Control (SBAC), Cortex XSIAM enables you to assign users to specific tags of different types in your organization. By default, all
users have management access to all tags in the tenant. However, after you (as an administrator) assign a management scope to a Cortex XSIAM user (non-
administrator), the user is then able to manage only the specific tags and its associated entities that are predefined within that scope. To enable SBAC per
server, refer to Define Scoped Server Access in Set up Your Environment.

The permissions in user or group settings define which entity the user can access, and the scope defines what the user can view within the entity.

SBAC applies only to the following functional areas in Cortex XSIAM.

Endpoint Administration table—View endpoints and take actions on endpoints.

Policy Management—Create and edit Prevention policies and profiles, Extension policies and profiles, and global and device Exceptions that are within
the scope of the user.

Action Center—View and take actions only on endpoints that are within the scope of the user.

Dashboards and Reports—Scoping takes place only on agent-related widgets.

Incidents and Alerts—View and manage incidents and alerts filtered according to the scope of the user or group.

CAUTION:

Important: The rest of the functional areas and their permissions in Cortex XSIAM do not support SBAC. Accordingly, if these permissions are granted to a
scoped user, the user will be able to access all endpoints in the tenant within this functional area. For example, a scoped user with permission to view
incidents can view all incidents in the system without limitation to a scope, however, will not be able to create an alert or device exception.

Also, note that the Agent Installation widget is not available for scoped users.

To define the scope of a user.

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

The currently assigned scope of each user is displayed in the Scope column of the Users table.

2. Right-click the user name and select Update User.

3. In the Scope tab, select one or all of the following for Tag Family. The user's permissions are based on the tags assigned to them.

Select All

Endpoint Groups—User is scoped according to Endpoint Groups. The tag selected refers to the specific endpoint group.

Endpoint Tags—User is scoped according to Endpoint Tags. The tag selected refers to the specific endpoint tag.

4. If you selected a Tag Family option, from the Tags field, select the relevant tags associated with the family.

NOTE:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 52/1003
5/8/24, 9:18 AM PDF Export

If you select a tag family without specific tags, permissions apply to all tags in the family.

The scope is based only on the selected Tag Families. If you scope only based on tags from Family A, then Family B is disregarded in scope
calculations and considered as allowed.

5. Click Save.

The users to whom you have scoped particular endpoints are now able to use Cortex XDR only within the scope of their assigned endpoints.

NOTE:

Make sure to assign the required default permissions for scoped users. This depends on the structure and divisions within your organization and the particular
purpose of each organizational unit to which scoped users belong.

2.6 | Configure a Mail Sender Integration

Abstract

Learn more about configuring a mail integration to enable the server to send emails for system notifications and playbooks.

A mail integration enables the server to send emails and can be used for system notifications and playbooks. When you use the mail integration for playbook
tasks, you can pass arguments, such as to, subject, and body, to customize the contents of your email.

Cortex XSIAM provides a built-in mail sender integration. It is installed out-of-the-box and does not require you to set up an SMTP server or provide any
credentials. Emails sent via the built-in mail sender integration have a watermark that specifies the FQDN and mentions that the mail was sent via Cortex
XSIAM. This provides protection against possible abuse of the built-in mail sender.

However, if you want to use a different email sender, you can configure one during your initial setup.

1. Go to Marketplace.

2. Search for and download a mail sender content pack (such as EWS).

3. Configure the mail sender integration (for example, EWS O365). When configuring your mail sender integration, select Enable to enable your mail sender
integration and deselect the Enable option for the built-in mail sender.

2.7 | Set Up Cloud Identity Engine

Abstract

Learn more about setting up Cloud Identity Engine in Cortex XSIAM.

Cloud Identity Engine (previously called Directory Sync Service (DSS)) is an optional service that enables you to leverage Active Directory user, group, and
computer information in Cortex XSIAM, and to provide context when you investigate alerts. You can use Active Directory information in policy configuration and
endpoint management. Cortex XSIAM supports on-prem Active Directory and Microsoft Entra.

NOTE:

When using the Cloud Identity Engine , you can use XQL Query to query the data using the pan_dss_raw dataset.

After you finish the setup, Cortex XSIAM automatically updates when the Cloud Identity Engine updates.

To set up the Cloud Identity Engine:

1. Navigate and log into the hub.

2. Activate and configure your Cloud Identity Engine instance as described in the Cloud Identity Engine Getting Started guide.

NOTE:

The Cloud Identity Engine must be activated in the same region as Cortex XSIAM.

Activating a Cloud Identity Engine instance on your Cortex XSIAM account will allow you to pair your Cortex XSIAM tenant with the Active Directory
information collected by the Cloud Identity Engine instance. During the Activation step, make sure to take note of the instance name you create.

3. After you complete the Cloud Identity Engine Getting Started steps, navigate and log into your Cortex XSIAM management console.

NOTE:

Wait about ten minutes after you have activated the instance before you do this.

a. In the Cortex XSIAM app, select Settings → Configuration → Integrations → Cloud Identity Engine.

b. Add the Cloud Identity Engine instance you want to Cortex XSIAM to use.

c. In the Add Cloud Identity Engine dialog, select the App Instance Name you created in the hub and Save.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 53/1003
5/8/24, 9:18 AM PDF Export

2.8 | Set up Endpoint Protection

Abstract

Learn more about deploying the Cortex XDR agent on the endpoint to enable its protection.

The Cortex XDR agent monitors endpoint activity and collects endpoint data that Cortex XSIAM uses to raise alerts. Before you can begin collecting endpoint
data, you must deploy the XDR agent and configure the endpoint policy.

Review Where can I install the Cortex XDR agent for supported versions and operating systems.

To use endpoint management functions in Cortex XSIAM you must be assigned an administrative role in the hub.

1. Verify the status of your Cortex XSIAM tenant.

a. From the hub, click the gear icon next to your name.

b. In the area, review the STATUS for the tenant you just activated.

When Cortex XSIAM tenant is available, the status changes to the green check mark.

2. Plan Your Deployment.

3. Setup Access Services.

4. (Optional) Set up Broker VM communication.

5. Install the Cortex XSIAM agent on your endpoints.

Install the agent software directly on an endpoint or use a software deployment tool of your choice (such as JAMF or GPO) to distribute and install the
software on multiple endpoints.

a. Create an Agent Installation Package.

b. Install the Cortex XSIAM agent.

For instructions by the operating system, see the Cortex XDR Agent Administrator's Guide or the Traps Agent Administrator’s Guide if you use an
earlier version.

6. Define Endpoint Groups to which you can apply endpoint security policy.

7. Customize your Endpoint Security Profiles and assign them to your endpoints.

Cortex XSIAM provides out-of-the-box exploit and malware protection. However, at minimum, you must enable Data Collection in an Agent Settings profile
to leverage endpoint data in Cortex XSIAM apps. Data collection for Windows endpoints is available with Traps 6.0 and later releases and on endpoints
running Windows 7 SP1 and later releases. Data collection on macOS and Linux endpoints are available with Traps 6.1 and later releases.

8. (Optional) Configure Device Control profiles to restrict file execution on USB-connected devices.

9. Verify that the Cortex XSIAM agent can connect to your Cortex XSIAM instance.

If successful, Cortex XSIAM displays a Connected status. In your Cortex XSIAM console, navigate to Endpoints → All Endpoints to view the status of all
your agents.

10. Configure the internal networks that you want Cortex XSIAM to monitor.

1. From the Cortex XSIAM management console, navigate to Assets → Network Configuration → IP Address Ranges.

2. Define your IP Address Ranges.

This page provides a table of the IP address ranges Cortex XSIAM Analytics monitors, which is pre-populated with the default IPv4 and IPv6
address spaces.

3. Define your Domain Names.

11. If you have a Cortex XDR Pro per GB license, proceed to Set up Network Analysis. Otherwise, proceed to Set up your Data Sources and Alert Sensors.

2.8.1 | Plan Your Agent Deployment

Abstract

Plan your Cortex XDR agent software deployment carefully.

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

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

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 54/1003
5/8/24, 9:18 AM PDF Export

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

The POC doesn't always reflect all the variables that exist in your production environment.

There is a rare chance that the XDR agent will affect business applications, which can reveal vulnerabilities in the software as a prevented attack.

During the POC, it is much easier to isolate issues that appear and provide a solution before full implementation in a large environment where issues
could affect a large number of users.

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

Step Duration Plan

1. Calculate the bandwidth required to support the as needed For every 100,000 agents, you will need to allocate 120Mbps of
number of agents you plan to deploy. bandwidth. The bandwidth requirement scales linearly. For example,
to support 300,000 agents, plan to allocate 360Mbps of bandwidth
(three times the amount required for 100,000 agents).

2. Install Cortex XDR on endpoints. 1 week Install the Cortex XDR agent on a small number of endpoints (3 to
10).

Test the expected behavior of the XDR agents (injection and policy)
and confirm that there is no change in the user experience.

Review Where can I install the cortex XDR Agent for supported
versions and operating systems.

3. Expand the Cortex XSIAM deployment. 2 weeks Gradually expand agent distribution to larger groups that have similar
attributes (hardware, software, and users). At the end of two weeks,
you can have Cortex XSIAM deployed on up to 100 endpoints.

4. Complete the Cortex XSIAM installation. 2 or more weeks Broadly distribute the Cortex XDR agent throughout the organization
until all endpoints are protected.

5. Define corporate policy and protected processes. Up to 1 week Add protection rules for third-party or in-house applications and then
test them.

6. Refine corporate policy and protected processes. Up to 1 week Deploy security policy rules to a small number of endpoints that use
the applications frequently. Fine-tune the policy as needed.

7. Finalize corporate policy and protected A few minutes Deploy protection rules globally.
processes.

2.8.2 | Setup Access Services

Abstract

Learn more about enabling access to Cortex XSIAM services.

After you receive your account details, enable and verify access to Cortex XSIAM.

1. (Optional) If you are deploying the Broker VM as a proxy between Cortex XSIAM and the Cortex XDR agents, start by enabling the communication
between them.

2. In your firewall configuration, enable access to Cortex XSIAM communication servers, storage buckets, and resources.

For the complete list of resources, refer to Resources Required to Enable Access to Cortex.

With Palo Alto Networks firewalls, we recommend that you use the following App-IDs to allow communication between Cortex XDR agents and the Cortex
XSIAM management console when you configure your security policy:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 55/1003
5/8/24, 9:18 AM PDF Export

cortex-xdr—Requires PAN-OS Applications and Threats content update version 8279 or a later release.

traps-management-service—Requires PAN-OS Applications and Threats content update version 793 or a later release.

If you use App-ID in your security policy, you must also allow access to additional resources that are not covered by the App-ID. If you do not use Palo Alto
Networks firewalls with App-ID you must allow access to the full list of resources.

3. Optional for endpoints running Cortex XDR agent 8.2 or earlier. To establish secure communication (TLS) to Cortex XSIAM, the endpoints, and any other
devices that initiate a TLS connection with, you must have the following certificates installed on the operating system.

For Cortex XDR agent 8.3 or later, with Certificate Enforcement enabled, this step is obsolete.

Certificate Fingerprint

GoDaddy Root Certificate Authority - G2 (Godaddy) SHA1 Fingerprint—47 BE AB C9 22 EA E8 0E 78 78 34 62 A7 9F 45 C2 54 FD

E6 8B

SHA256 Fingerprint—45 14 0B 32 47 EB 9C C8 C5 B4 F0 D7 B5 30 91 F7 32
92 08 9E 6E 5A 63 E2 74 9D D3 AC A9 19 8E DA

GoDaddy Class 2 Root Certification Authority SHA1 Fingerprint—27 96 BA E6 3F 18 01 E2 77 26 1B A0 D7 77 70 02 8F 20

Certificate EE E4

SHA256 Fingerprint—C3 84 6B F2 4B 9E 93 CA 64 27 4C 0E C6 7C 1E CC 5E
02 4F FC AC D2 D7 40 19 35 0E 81 FE 54 6A E4

R1 GlobalSign Root Certificate (Google) SHA1 Fingerprint—b1 bc 96 8b d4 f4 9d 62 2a a8 9a 81 f2 15 01 52 a4 1d

82 9c

SHA256 Fingerprint—eb d4 10 40 e4 3e c7 c9 e3 81 d3 1e f2 a4 1a 48 b6
68 5c 96 e7 ce f3 c1 df 6c d4 33 1c 99

NOTE:

For the Cortex XDR agent 5.X release installed on endpoints running a Windows version
that does not support SHA256 by default, you must install KB2868626 to establish a
connection between Cortex XSIAM and the agent. This applies to Windows Server 2003
R2 (32-bit) (SP2 & later), Windows Server 2003 (32-bit) (SP2 & later), Windows XP (32-bit)
(SP3 & later), Windows Server 2008 (all editions; FIPS Mode), and Windows Vista (SP1 &
later; FIPS Mode).

4. (Windows only) Enable access for Windows CRL checks.

(Endpoints running the following or later releases: Traps 6.0.3, Traps 6.1.1, and Cortex XDR 7.0 and later) When the XDR agent examines portable
executables (PEs) running on the endpoint as part of the enforced Malware Security Profile, the agent performs a certificate revocation (CRL) check. The
CRL check ensures that the certificate used to sign a given PE is still considered valid by its Certificate Authority (CA), and has not been revoked. To
validate the certificate, the XDR agent leverages Microsoft Windows APIs and triggers the operating system to fetch the specific Certificate Revocation
List (CRL) from the internet. To complete the certificate revocation check, the endpoint needs HTTP access to a dynamic list of URLs, based on the PEs
that are executed or scanned on the endpoint.

1. If a system-wide proxy is defined for the endpoint (statically or using a PAC file), Microsoft Windows downloads the CRL lists through the proxy.

2. If a specific proxy is defined for the Cortex XDR agent, and the endpoint has no access to the internet over HTTP, then Microsoft Windows will fail to
download the CRL lists. As a result, the certificate revocation check will fail and the certificate will be considered valid by the Agent while creating a
latency in executing PEs. If the XDR agent is running in an isolated environment that prohibits the successful completion of certificate revocation
checks, the Palo Alto Networks Support team can provide a configuration file that will disable the revocation checks and avoid unnecessary latency
in the execution time of PEs.

5. Enable peer-to-peer (P2) content updates.

By default, the Cortex XDR agent retrieves content updates from its peer Cortex XDR agents on the same subnet. To enable P2P, you must enable UDP
and TCP over port 33221. You can change the port number or choose to download the content directly from the Cortex XSIAM sever in the Agent settings
profile.

6. Verify that you can access your Cortex XSIAM tenant.

After you download and install the XDR agent software on your endpoints and configure your endpoint security policy, verify that the Cortex XDR agents
can check in with Cortex XSIAM to receive the endpoint policy.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 56/1003
5/8/24, 9:18 AM PDF Export

7. If you use SSL decryption and experience difficulty in connecting the Cortex XDR agent to the server, we recommend that you add the FQDNs required
for access to your SSL Decryption Exclusion list.

With Cortex XDR agent 8.3 where Certificate Enforcement is enabled, you must add the the FQDNs required for access to your SSL Decryption Exclusion
list.

In PAN-OS 8.0 and later releases, you can configure the list in Device → Certificate Management → SSL Decryption Exclusion.

2.8.2.1 | Resources Required to Enable Access

Abstract

Learn more about enabling network access to the Cortex XSIAM resources.

To enable access to Cortex XSIAM components, you must allow access to various Palo Alto Networks resources. If you use the specific Palo Alto Networks App-
IDs indicated in the table, you do not need to explicitly allow access to the resource. A dash (—) indicates there is no App-ID coverage for a resource. Access
must be allowed from the agent to the console, but does not need to be bidirectional.

NOTE:

Some of the IP addresses required for access are registered in the United States. As a result, some GeoIP databases do not correctly pinpoint the location in
which IP addresses are used. All customer data is stored in your deployment region, regardless of the IP address registration, and restricts data transmission
through any infrastructure to that region. For considerations, see Plan Your Cortex Deployment.

NOTE:

Throughout this topic, <xsiam-tenant> refers to the chosen subdomain of your Cortex XSIAM tenant, and <region> is the region in which your tenant is
deployed (see Plan Your Cortex Deployment for supported regions).

Refer to the following tables for the FQDNs, IP addresses, ports, and App-ID coverage for your deployment.

For IP address ranges in GCP, refer to the following tables for IP address coverage for your deployment:

https://www.gstatic.com/ipranges/goog.json—Refer to this list to look up and allow access to the IP address ranges subnets.

https://www.gstatic.com/ipranges/cloud.json—Refer to this list to look up and allow access to the IP address ranges associated with your region.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 57/1003
5/8/24, 9:18 AM PDF Export

FQDN IP Addresses And Port App-ID Coverage

<xsiam-tenant>.xdr. IP address by region. cortex-xdr

<region>.paloaltonetworks.com
US (United States)—35.244.250.18
Used to connect to the Cortex XSIAM management
EU (Europe)— 35.227.237.180
console.
CA (Canada)—34.120.31.199

UK (United Kingdom)— 34.120.87.77

JP (Japan)—35.241.28.254

SG (Singapore)— 34.117.211.129

AU (Australia)—34.120.229.65

DE (Germany)—34.98.68.183

IN (India)—35.186.207.80

CH (Switzerland)—34.111.6.153

PL (Poland)—34.117.240.208

TW (Taiwan)—34.160.28.41

QT (Qatar)—35.190.0.180

FA (France)—34.111.134.57

IL (Israel)—34.111.129.144

SA (Saudi Arabia)—35.244.157.127

ID (Indonesia)—34.111.58.152

Port—443

distributions.traps.paloaltonetworks.com IP address—35.223.6.69 traps-management-service

Used for the first request in registration flow where the Port—443
agent passes the distribution id and obtains the ch-
<xsiam-tenant>.traps.paloaltonetworks.com of its
tenant

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 58/1003
5/8/24, 9:18 AM PDF Export

FQDN IP Addresses And Port App-ID Coverage

wss://lrc-<region>.paloaltonetworks.com IP address by region. cortex-xdr

Used in live terminal flow. US (United States)—35.190.88.43

EU (Europe)—35.244.251.25

CA (Canada)—35.203.99.74

UK (United Kingdom)—35.242.159.176

JP (Japan)—34.84.201.32

SG (Singapore)—34.87.61.186

AU (Australia)—35.244.66.177

DE (Germany)—34.107.61.141

IN (India)—35.200.146.253

CH (Switzerland)—34.65.213.226

PL (Poland)—34.118.62.80

TW (Taiwan)—34.80.34.30

QT (Qatar)—34.18.34.73

FA (France)—34.163.57.57

IL (Israel)—34.165.43.106

SA (Saudi Arabia)—34.166.54.6

ID (Indonesia)—34.101.214.157

Port—443

panw-xdr-installers-prod- IP ranges in GCP cortex-xdr

us.storage.googleapis.com
Port—443
Used to download installers for upgrade actions from the
server.

This storage bucket is used for all regions.

panw-xdr-payloads-prod- IP ranges in GCP cortex-xdr

us.storage.googleapis.com
Port—443
Used to download the executable for live terminal for
XDR agents earlier than version 7.1.0.

This storage bucket is used for all regions.

global-content-profiles- IP ranges in GCP cortex-xdr

policy.storage.googleapis.com
Port—443
Used to download content updates.

panw-xdr-evr-prod- IP ranges in GCP cortex-xdr

<region>.storage.googleapis.com
Port—443
Used to download extended verdict request results in
scanning.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 59/1003
5/8/24, 9:18 AM PDF Export

FQDN IP Addresses And Port App-ID Coverage

https://<region>-docker.pkg.dev IP ranges in GCP

Used to download the Kubernetes image from the Port—443

registry for Kubernetes agents installation.

dc-<xsiam-tenant>.traps.paloaltonetworks.com IP address by region. traps-management-service

Used for EDR data upload. US (United States)—34.98.77.231

EU (Europe)—34.102.140.103

CA (Canada)—34.96.120.25

UK (United Kingdom)—35.244.133.254

JP (Japan)—34.95.66.187

SG (Singapore)—34.120.142.18

AU (Australia)—34.102.237.151

DE (Germany)—34.107.161.143

IN (India)—34.120.213.187

CH (Switzerland)—34.149.180.250

PL (Poland)—35.190.13.237

TW (Taiwan)—34.149.248.76

QT (Qatar)—34.107.129.254

FA (France)—34.36.155.211

IL (Israel)—34.128.157.130

SA (Saudi Arabia)—34.107.213.85

ID (Indonesia)—34.128.156.84

Port—443

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 60/1003
5/8/24, 9:18 AM PDF Export

FQDN IP Addresses And Port App-ID Coverage

ch-<xsiam-tenant>.traps.paloaltonetworks.com IP address by region. traps-management-service

Used for all other requests between the agent and its US (United States)—34.98.77.231
tenant server including heartbeat, uploads, action
EU (Europe)—34.102.140.103
results, and scan reports.
CA (Canada)— 34.96.120.25

UK (United Kingdom)—35.244.133.254

JP (Japan)—34.95.66.187

SG (Singapore)—34.120.142.18

AU (Australia)—34.102.237.151

DE (Germany)—34.107.161.143

IN (India)—34.120.213.188

CH (Switzerland)—34.149.180.250

PL (Poland)—35.190.13.237

TW (Taiwan)—34.149.248.76

QT (Qatar)—34.107.129.254

FA (France)—34.36.155.211

IL (Israel)—34.128.157.130

SA (Saudi Arabia)—34.107.213.85

ID (Indonesia)—34.128.156.84

Port—443

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 61/1003
5/8/24, 9:18 AM PDF Export

FQDN IP Addresses And Port App-ID Coverage

api-<xsiam-tenant>.xdr. IP address by region. —

<region>.paloaltonetworks.com
US (United States)—35.222.81.194
Used for API requests and responses.
EU (Europe)— 34.90.67.58

CA (Canada)—35.203.82.121

UK (United Kingdom)— 34.89.56.78

JP (Japan)—34.84.125.129

SG (Singapore)—34.87.83.144

AU (Australia)—35.189.18.208

DE (Germany)—34.107.57.23

IN (India)—35.200.158.164

CH (Switzerland)—34.65.248.119

PL (Poland)—34.116.216.55

TW (Taiwan)—35.234.8.249

QT (Qatar)—34.18.46.240

FA (France)—34.155.222.152

IL (Israel)—34.165.156.139

SA (Saudi Arabia)—34.166.58.79

ID (Indonesia)—34.128.115.238

Port—443

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 62/1003
5/8/24, 9:18 AM PDF Export

FQDN IP Addresses And Port App-ID Coverage

cc-<xsiam-tenant>.traps.paloaltonetworks.com IP address by region. traps-management-service

Used for get-verdict requests. US (United States)—35.224.140.142

EU (Europe)—34.90.71.103

CA (Canada)—35.203.35.23

UK (United Kingdom)—34.89.42.214

JP (Japan)—34.84.225.105

SG (Singapore)—35.247.161.94

AU (Australia)—35.201.23.188

DE (Germany)—35.242.201.199

IN (India)—35.244.57.196

CH (Switzerland)—34.65.137.215

PL (Poland)—34.116.213.71

TW (Taiwan)—35.229.186.216

QT (Qatar)—34.18.53.229

FA (France)—34.155.110.169

IL (Israel)—34.165.2.110

SA (Saudi Arabia)—34.166.53.160

ID (Indonesia)—34.101.155.198

Port—443

https://cortex-gateway.paloaltonetworks.com/

Cortex Gateway UI for activating tenants and managing

user permissions

Broker VM Resources

Required for deployments that use Broker VM features

xdr-ova-installers-prod-us.storage.googleapis.com IP ranges in GCP cortex-xdr

Used to download Broker VM images from the server. Port—443

This storage bucket is used for all regions.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 63/1003
5/8/24, 9:18 AM PDF Export

FQDN IP Addresses And Port App-ID Coverage

br-<xsiam-tenant>.xdr. IP address by region. —

<region>.paloaltonetworks.com
US (United States)—104.155.131.72

EU (Europe)— 34.91.128.226

CA (Canada)— 34.95.8.232

UK (United Kingdom)—35.197.219.110

JP (Japan)— 34.85.74.43

SG (Singapore)—34.87.167.125

AU (Australia)—35.244.93.0

DE (Germany)—35.198.112.13

IN (India)—35.200.234.99

CH (Switzerland)—34.65.51.103

PL (Poland)—34.116.176.97

TW (Taiwan)—34.80.230.166

QT (Qatar)—34.18.37.73

FA (France)—34.155.90.61

IL (Israel)—34.165.24.222

SA (Saudi Arabia)—34.166.55.153

ID (Indonesia)—34.101.101.170

Port—443

distributions.traps.paloaltonetworks.com IP address—35.223.6.69 traps-management-service

Port—443

time.google.com UDP port—123 —

pool.ntp.org

App Login and Authentication

identity.paloaltonetworks.com IP address—34.107.215.35 —

(SSO) Port—443

login.paloaltonetworks.com IP address—34.107.190.184 —

(SSO) Port—443

In-App Help Center and Notifications

data.pendo.io Port—443 —

pendo-static- Port—443 —
5664029141630976.storage.googleapis.com

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 64/1003
5/8/24, 9:18 AM PDF Export

FQDN IP Addresses And Port App-ID Coverage

Email Notifications

— IP address for all regions—159.183.150.248 —

Egress

Used for communication between Cortex XSIAM and customer resources

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 65/1003
5/8/24, 9:18 AM PDF Export

FQDN IP Addresses And Port App-ID Coverage

US (United States) —

— 35.225.156.101

34.69.88.119

EU (Europe)

34.147.67.188

34.90.16.31

CA (Canada)

35.203.57.162

35.203.90.79

UK (United Kingdom)

34.142.3.42

34.142.44.136

JP (Japan)

34.146.60.215

34.84.93.160

SG (Singapore)

35.240.144.192

35.240.255.15

AU (Australia)

35.244.73.76

35.201.22.63

DE (Germany)

34.107.83.197

34.159.53.97

IN (India)

34.93.118.113

35.244.5.205

CH (Switzerland)

34.65.233.60

34.65.222.25

PL (Poland)

34.116.223.119

34.118.92.214

TW (Taiwan)

104.199.223.229

34.81.38.132

QT (Qatar)

34.18.39.0

34.18.32.96

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 66/1003
5/8/24, 9:18 AM PDF Export

FQDN IP Addresses And Port App-ID Coverage

FA (France)

34.155.197.131

34.155.5.100

IL (Israel)

34.165.33.165

34.165.27.131

SA (Saudi Arabia)

34.166.58.213

34.166.61.81

ID (Indonesia)

34.101.125.66

34.101.218.184

To Collect 3rd Party Data from Customer's SaaS and Cloud resources

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 67/1003
5/8/24, 9:18 AM PDF Export

FQDN IP Addresses And Port App-ID Coverage

— IP address by region. cortex-xdr

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 68/1003
5/8/24, 9:18 AM PDF Export

FQDN IP Addresses And Port App-ID Coverage

US (United States)

34.66.69.154

35.202.21.123

AU (Australia)

35.197.181.108

35.197.175.44

CA (Canada)

34.95.33.72

34.95.62.136

SG (Singapore)

35.247.148.38

35.247.173.40

JP (Japan)

34.85.68.167

34.84.99.239

IN (India)

34.93.3.196

34.93.175.218

DE (Germany)

34.89.197.46

34.107.3.224

UK (United Kingdom)

34.105.227.146

34.105.137.22

EU (Europe)

34.90.70.107

35.204.129.196

CH (Switzerland)

34.65.225.124

34.65.89.6

PL (Poland)

34.118.71.237

34.118.124.130

TW (Taiwan)

35.201.142.86

35.189.176.163

QT (Qatar)

34.18.44.71

34.18.30.132

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 69/1003
5/8/24, 9:18 AM PDF Export

FQDN IP Addresses And Port App-ID Coverage

FA (France)

34.163.125.167

34.163.155.105

IL (Israel)

34.165.131.171

34.165.120.206

SA (Saudi Arabia)

34.166.59.20

34.166.53.242

ID (Indonesia)

34.101.158.32

34.101.79.159

Log Forwarding to a Syslog Receiver

See Integrate a Syslog Receiver. — —

Table 1. Required Resources for Federal (United States - Government)

FQDN IP Addresses And Port App-ID Coverage

distributions-prod- IP address—104.198.132.24 traps-management-service

fed.traps.paloaltonetworks.com
Port—443
Used for the first request in registration flow where the
agent passes the distribution ID and obtains the ch-
<xsiam-tenant>.traps.paloaltonetworks.com of
its tenant

wss://lrc-fed.paloaltonetworks.com IP address—35.188.188.91 cortex-xdr

Used in live terminal flow. Port—443

panw-xdr-installers-prod- IP ranges in GCP cortex-xdr

fr.storage.googleapis.com
Port—443
Used to download installers for upgrade actions from
the server.

panw-xdr-payloads-prod- IP ranges in GCP cortex-xdr

fr.storage.googleapis.com
Port—443
Used to download the executable for live terminal for
Cortex XDR agents earlier than version 7.1.0.

global-content-profiles-policy-prod- IP ranges in GCP cortex-xdr

fr.storage.googleapis.com
Port—443
Used to download content updates.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 70/1003
5/8/24, 9:18 AM PDF Export

FQDN IP Addresses And Port App-ID Coverage

panw-xdr-evr-prod-fr.storage.googleapis.com IP ranges in GCP cortex-xdr

Used to download extended verdict request results in Port—443

scanning.

app-proxy.federal.paloaltonetworks.com IP address—35.186.217.42 —

Port—443

dc-<xsiam-tenant>.traps.paloaltonetworks.com IP address—130.211.195.231 traps-management-service

Used for EDR data upload. Port—443

ch-<xsiam-tenant>.traps.paloaltonetworks.com IP address—130.211.195.231 traps-management-service

Used for all other requests between the agent and its Port—443
tenant server including heartbeat, uploads, action
results, and scan reports.

api-<xsiam- IP address—130.211.195.231 —
tenant>.xdr.federal.paloaltonetworks.com
Port—443
Used for API requests and responses.

cc-<xsiam-tenant>.traps.paloaltonetworks.com IP address—35.222.50.74 traps-management-service

Used for get-verdict requests. Port—443

Broker VM Resources

Required for deployments that use Broker VM features

br-<xsiam- IP address—34.71.185.11 —
tenant>.xdr.federal.paloaltonetworks.com:443
Port—443

xsiam-gateway (Broker VM 3.0 only) Port—443 —

distributions-prod- IP address—104.198.132.24 traps-management-service

fed.traps.paloaltonetworks.com
Port—443

UDP port—123 —

App Login and Authentication

identity.paloaltonetworks.com IP address—34.107.215.35 —

(SSO) Port—443

login.paloaltonetworks.com IP address—34.107.190.184 —

(SSO) Port—443

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 71/1003
5/8/24, 9:18 AM PDF Export

FQDN IP Addresses And Port App-ID Coverage

To Collect 3rd Party Data from Customer's SaaS and Cloud resources

— IP addresses cortex-xdr

34.68.217.16

34.69.175.202

Log Forwarding to a Syslog Receiver

See Integrate a Syslog Receiver.

2.9 | Set up Network Analysis

Abstract

Learn more about setting up your network sensors and defining network coverage for your internal networks.

With a Cortex XSIAM license, you must set up your network sensors and define network coverage for your internal networks.

1. Set up your network sensors.

a. If you use unmanaged Palo Alto Networks firewalls and did not configure log-forwarding on your firewalls before activating Cortex XSIAM, start
sending logs to Cortex XSIAM.

b. (Optional) Set up External Data Ingestion.

If you have external (non-Palo Alto Networks) network sensors, you can set up a Syslog collector to receive alerts or logs from them. If you send
external alerts, Cortex XSIAM can include any of them in relevant incidents for a more complete picture of the activity involved. If you send logs and
alerts from external sources such as Check Point firewalls, Cortex XSIAM can apply analytics analysis and raise analytics alerts on the external logs
and include the external alerts in incidents for additional context.

c. (Optional) If you use a third-party authentication service, you can Ingest Authentication Logs and Data into authentication stories. After you set up
log collection, you can search for authentication data using the Query Builder.

d. (Optional) If you want to use Pathfinder to examine unmanaged network hosts, servers, and workstations for malicious or risky software, Activate
Pathfinder.

2. Configure the internal networks that you want Cortex XSIAM to monitor.

1. From the Cortex XSIAM management console, navigate to Assets → Network Configuration.

2. Define your IP Address Ranges.

This page provides a table of the IP address ranges Cortex XSIAM Analytics monitors, which is pre-populated with the default IPv4 and IPv6
address spaces.

3. Define your Domain Names.

3. If you use GlobalProtect or Prisma Access, add the GlobalProtect VPN IP address pool for the VPN traffic that you want to monitor.

1. To enable the Cortex XSIAM app to analyze your VPN traffic, add (+) a new segment and specify the first and last IP address of your GlobalProtect
VPN IP address pool.

2. Identify this network segment as Reserved for VPN. GlobalProtect dynamically assigns IP addresses from the IP pool to the mobile endpoints that
connect to your network. The Cortex XSIAM analytics engine creates virtual entity profiles for network segments that are reserved for VPN.

3. Save ( ) the network segment. If the Configuration saved notification does not appear, save again.

4. If you selected a Cloud Identity Engine (Directory Sync instance) during the Cortex XSIAM activation process, Set Up Cloud Identity Engine.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 72/1003
5/8/24, 9:18 AM PDF Export

2.10 | Set up your Data Sources and Alert Sensors

Abstract

Learn more about setting up your data sources and alert sensors.

Before you can begin using Cortex XSIAM, you must set up your alert sensors. The more sensors that you integrate with Cortex XSIAM, the more context you
have when a threat is detected.

You can also set up to raise Analytics alerts on network or endpoint data (or both) depending on your Cortex XSIAM Pro licenses.

The following workflow highlights the tasks that you must perform (in order) to configure Cortex XSIAM.

1. Integrate External Threat Intelligence Services.

Integrating external threat intelligence services enables you to view feeds from sources such as AutoFocus and VirusTotal in the context of your incident
investigation.

2. After you activate Cortex XSIAM apps and services, wait 24 hours and then configure the Cortex XSIAM analytics.

a. Specify the internal networks that you want Cortex XSIAM to monitor.

b. (Recommended) If you want to use Pathfinder to scan unmanaged endpoints, Activate Pathfinder.

c. Enable Cortex XDR - Analytics.

By default, Cortex XSIAM - Analytics is disabled. Activating Cortex XSIAM - Analytics enables the Cortex XSIAM analytics engine to analyze your
endpoint data to develop a baseline and raise Analytics and Analytics BIOC alerts when anomalies and malicious behaviors are detected.

To create a baseline for enabling Analytics, Cortex XSIAM requires a minimum set of data; EDR or Network logs from at least 30 endpoints over a
minimum of 2 weeks, or cloud audit logs over a minimum of 5 days. Once this requirement is met, Cortex XSIAM allows you to enable analytics and
begin triggering alerts within a few hours.

1. In Cortex XSIAM , select Settings → Configurations → Cortex XDR - Analytics.

The Enable option will be grayed out if you do not have the required data set.

2. When available, Enable Cortex XSIAM - Analytics. The analytics engine will immediately begin analyzing your data for anomalies.

NOTE:

Creating a baseline can take up to 3 hours.

d. Enable Identity Analytics.

By default, Identity Analytics is disabled. Activating Identity Analytics enables the Cortex XSIAM analytics engine to aggregate and display
throughout your investigation user profile information, activity, and alerts associated with a user-based Analytics type alert and Analytics BIOC rule.

To enable the Identity Analytics, you must first Activate the Cortex XSIAM Analytics and Set Up Cloud Identity Engine (Formally Directory Sync
Services (DSS)).

After configuring your Cloud Identity Engine instance and Cortex XSIAM Analytics, Enable Identity Analytics.

3. Add an Alert Exclusion Rule.

4. Manage Incident Starring.

5. (Optional) Palo Alto Networks also automatically delivers behavioral indicators of compromise (BIOCs) rules defined by the Palo Alto Networks threat
research team to all Cortex XSIAM tenants, but you can also import any additional indicators as rules, as needed.

To alert on specific BIOCs, Create a BIOC Rule. To immediately alert on known malicious indicators of compromise (IOCs)—such as known malicious IP
addresses—Create an IOC Rule or Create a Correlation Rule .

2.10.1 | Integrate External Threat Intelligence Services

Topic Not Found

2.10.2 | Set up Your Environment

Abstract

Learn more about setting up the Cortex XSIAM environment based on your preferences.

To create a more personalized user experience, Cortex XSIAM enables you to define your Server and Security Settings.

NOTE:

Keyboard shortcuts, timezone, and timestamp format are not set universally and only apply to the user who sets them.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 73/1003
5/8/24, 9:18 AM PDF Export

From the Cortex XSIAM management console, navigate to Settings → Configurations → General → Server Settings to define the following:

Server Setting Description

Keyboard Shortcuts Enables you to change the default shortcut settings. The shortcut value
must be a keyboard letter, A through Z, and cannot be the same for both
shortcuts.

Timezone Select a specific timezone. The timezone affects the timestamps displayed
in Cortex XSIAM, auditing logs, and when exporting files.

Timestamp Format The format in which to display Cortex XSIAM data. The format affects the
timestamps displayed in Cortex XSIAM, auditing logs, and when exporting
files.

This setting is configured per user and not per tenant.

Email Contacts A list of email addresses Cortex XSIAM can use as distribution lists. The
defined email addresses are used to send product maintenance, updates,
and new version notifications. These addresses are in addition to email
addresses registered with your Customer Support Portal account.

Password Protection (for downloaded files) Enable password protection to prevent executing malicious files that were
downloaded from an endpoint during incident investigation.

Administrator permissions required.

Google Maps Key Enter the Google Maps API key

to display the physical location of an entity on a Google map.

Scoped Server Access Enforces access restrictions on users with an assigned scope. A user can
inherit scope permissions from a group, or have a scope assigned directly
on top of the role assigned from the group.

If enabled, you must select the SBAC Mode, which is defined per tenant:

Permissive: Enables users with at least one scope tag to access the
relevant entity with that same tag.

Restrictive: Users must have all the scoped tags that are tagged
within the relevant entity of the system.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 74/1003
5/8/24, 9:18 AM PDF Export

Server Setting Description

Data Ingestion Monitoring (Beta) Data ingestion health monitors the availability and overall health of data
collection and provides notifications and alerts.

When data ingestion monitoring is enabled, Cortex XSIAM creates the

following types of alerts:

Ingestion alerts: Based on the data ingestion metrics and indicate

disruptions in data collection

Collection alerts: Based on error statuses in collection integrations

and indicate that a collector is not connected

If you disable data ingestion monitoring, Cortex XSIAM continues to collect

metrics, but alerts are not created.

Related information

Configure notification forwarding to forward your data ingestion and

collection alerts to an email distribution list, syslog receiver, or Slack
channel. For more information, see Configure Notification Forwarding.

Use data ingestion health metrics in Cortex Query Language queries,

and to create correlation rules with your own data ingestion logic. For
more information, see Monitoring Data Ingestion Health.

XQL Configuration Enables setting case sensitivity across Cortex XSIAM.

By default, this setting is set to false and field values are evaluated as
case insensitive. This setting overwrites any other default configuration
except for BIOCs, which will remain case insensitive no matter what this
configuration is set to.

Define the incidents target MTTR per incident severity Determines within how many days and hours you want incidents resolved
according to the incident severity Critical, High, Medium, and Low.

The defined MTTR is used to display the Resolved Incident MTTR

dashboard widgets.

Impersonation Role The type of role permissions granted to the Palo Alto Networks Support
team when opening support tickets. We recommend that role permissions
are granted only for a specific time frame, and full administrative
permissions are granted only when specifically requested by the Support
team.

Role permissions include:

Read-only: Default setting; grants read-only access to your tenant.

Support-related actions: Grants permissions to tech support file

collection, dump file collection, investigation query, correlation
rule, BIOC and IOC rule editing, alert starring, exclusion, and
exception editing

Full role permissions: No limitations are applied; grants full

permissions to all actions and content on your tenant

Permission Reset Timeframe: Determines how long role permissions are

valid.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 75/1003
5/8/24, 9:18 AM PDF Export

Server Setting Description

LICENSE TYPE:
Prisma Cloud Compute Tenant Pairing
Requires a Cortex XSIAM or Cortex XDR Pro license

To enable the capabilities of the Cloud Security Agent,

the Prisma Cloud Compute tenant must be paired with an existing Cortex
XSIAM tenant. Pairing is one-to-one, with the two tenants being in the same
region.

For more information, see Pairing Prisma Cloud Compute with Cortex
XSIAM.

Custom Content Export all custom content: Exports custom content, such as
playbooks and scripts as a content bundle, which you can import to
another Cortex XSIAM tenant.

Upload custom content: Imports custom content created from

another Cortex XSIAM tenant.

Alerts Create timer fields that display in the alerts table and alert layouts. For more
information, see Configure timer fields.

Set up Session Security Settings

Abstract

Learn more about setting up session security settings.

The session security settings include:

Session Expiration—Enables you to define the number of hours after which the user login session will expire, and automatic logout for user inactivity. You
can also define expiration time for the Cortex XSIAM dashboard.

Allowed Sessions—Enables you to define approved domains and approved IP address ranges through which access to Cortex XSIAM should be allowed.

To ensure tenant stability, some of Palo Alto Networks' monitoring tools require external IP address access. When Approved IP ranges are Enabled,
access to Palo Alto managed monitoring tools are allowed by default.

User Expiration—Enables you to deactivate an inactive user, and also set the user deactivation trigger period.

Approved Domains—Enables you to specify one or more domain names that can be used in your distribution lists.

Approved IP Ranges—If enabled, specify the IP address ranges from which you want to allow user access (login) to Cortex XSIAM. You can also choose
to limit API access from specific IP addresses.

1. From the Cortex XSIAM management console, select Settings → Configurations → Security Settings.

2. Under Session Expiration, define the following:

a. User Login Expiration—Select the number of session hours (1 - 24 hours) after which the user login should expire.

b. Enable Auto Logout—If desired, enable automatic logout, and then select the required period of user inactivity (10 - 30 minutes).

c. Dashboard Expiration—Select either 7 Days or As user login expiration (hours) to define the timing of the dashboard expiration.

3. Under Allowed Sessions, define the following:

a. Approved Domains—Select Enabled or Disabled. If enabled, specify the domains from which you want to allow the user access to Cortex XSIAM .
You can add or remove domains as necessary.

b. Approved IP Ranges—Select Enabled or Disabled. If enabled, specify the IP ranges from which you want to allow the user access to Cortex XSIAM
. You can add or remove IP CIDR addresses as necessary.

4. Under User Expiration, define if you want to Deactivate Inactive User. By default, user expiration is Disabled, when Enabled enter the number of days
after which inactive users should be deactivated.

5. Under Approved Domains, specify one or more domain names that users in your organization can use. For example, when generating a report, ensure the
reports are not sent to email addresses outside your organization.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 76/1003
5/8/24, 9:18 AM PDF Export

6. Under Approved IP Ranges, specify one or more IP address ranges that can be used to access Palo Alto Networks managed monitoring tools. You can
also select whether to limit API access to specific IP addresses.

7. Save.

2.11 | Set up Outbound Integration

Abstract

Learn more about setting up the integration of outbound data with other systems.

You can set up any of the following optional outbound integrations:

Integrate Slack for Outbound Notifications

Integrate a Syslog Receiver

Integrate with external receivers such as ticketing systems—To manage incidents from the application of your choice, you can use the Cortex XSIAM
API Reference to send alerts and alert details to an external receiver. After you generate your API key and set up the API to query Cortex XSIAM ,
external apps can receive incident updates, request additional data about incidents, and make changes such as setting the status and changing the
severity or assign an owner. To get started, see the Cortex XSIAM API Reference Guide.

2.12 | Use the Interface

Abstract

Learn more about monitoring and managing your network security in the management console interface.

Cortex XSIAM provides an easy-to-use interface that you can access from the hub. By default, Cortex XSIAM displays the Predefined Dashboards when you log
in. If desired, you can change the default dashboard or Build a Custom Dashboard that displays when you log in.

NOTE:

Each SAML login session is valid for 8 hours.

Depending on your license and assigned role, you can explore the following areas in the app.

Interface Description

Dashboard & Reports From the Dashboard & Reports menu, you can view and manage your dashboards and
reports from the dashboard and incidents table, and view alert exclusions.

Dashboard—Provides dashboards that you can use to view high-level statistics

about your agents and incidents.

Reports—View all the reports that Cortex XSIAM administrators have run.

Customize—Create and manage a new dashboard and reports.

Dashboards Manager—Add new dashboards with customized widgets to

surface the statistics that matter to you most.

Reports Templates—Build reports using pre-defined templates, or customize a

report. Reports can be generated on-demand scheduled.

Widget Library—Search, view, edit, and create widgets based on predefined

widgets and user-created custom widgets.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 77/1003
5/8/24, 9:18 AM PDF Export

Interface Description

Incident Response From the Incident Response menu, you can view, manage, investigate and take action on
all incidents.

Incidents—Investigate and manage your incidents.

Investigation

Query Builder—Build complex queries to investigate, identify connections, and

expose the root cause of alerts from your data sources.

Query Center—View and manage the results of all simple and complex
queries created from the Query Builder.

Scheduled Queries—View and manage all scheduled and reoccurring queries

created from the Query Builder.

Forensics—Streamline your incident response, data collection, threat hunting,

and analyses of your endpoint data to find the source and scope of an attack.

Host Inventory—

Response

Action Center—Provides a central location from which you can track the
progress of all investigation, response, and maintenance actions performed on
your endpoints.

Live Terminal—Initiate a remote connection to an endpoint enabling you to

remotely manage, investigate, and perform response actions on the endpoint.

EDL—Add malicious domains and IP addresses to an external dynamic list

enforceable on your Palo Alto Networks firewall.

Incident Configuration—Create a starring configuration that automatically

categorizes and starts incidents when a related alert contains specific attributes that
you define as important.

Detection From the Detection menu, you can define specific rules for which you want Cortex XSIAM
to raise alerts.

Detection Rules

IOC—Identify specific hashes, IP addresses, domains, file names, and paths

that indicate a threat.

BIOC—Identify a specific network, process, file, or registry activity that

indicates a threat.

Correlations—Analyze correlations of multi-events from multiple sources.

Exceptions—Define exception criteria for an IOC or BIOC rule.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 78/1003
5/8/24, 9:18 AM PDF Export

Interface Description

Assets From the Assets menu, you can define your network parameters and view a list of all the
assets in your network.

Network Configuration—Define your internal IP address ranges and domain names

to identify and track your network assets.

Vulnerability Assessment—Identify and quantify the security vulnerabilities on an

endpoint.

Asset Scores—Investigate user and host activities, and detect compromised

accounts and malicious devices using the Cortex XSIAM calculated User and Host
Scores.

Asset Inventory—Provides a central location from which you can view and
investigate information relating to assets in your network.

Cloud Inventory—Provides a unified, normalized asset inventory for cloud assets in

Google Cloud Platform, Microsoft Azure, and Amazon Web Services.

Endpoints From the Endpoints menu, you can manage your registered endpoints and configure the
policy.

All Endpoints—View and manage endpoints that have registered with your Cortex
XSIAM instance.

Endpoint Groups—Create endpoint groups to which you can perform actions and
assign the policy.

Agent Installations—Create packages of the Cortex XSIAM agent software for

deployment to your endpoints.

Policy Management—Configure your endpoint security profiles and assign them to

your endpoints.

Host Firewall—Control communications on your endpoints by applying sets of rules

that allow or block internal and external traffic.

Device Control Violations—Monitor all instances where end users attempted to

connect restricted USB-connected devices and Cortex XDR blocked them on the
endpoint.

Disk Encryption Visibility—View and manage endpoints that were encrypted using
BitLocker.

Managed Services The Managed Threat Hunting service augments your security by providing 24/7, year-
round monitoring by Palo Alto Networks threat researchers and Unit 42 experts.

Quick Launcher Open an in-context shortcut that you can use to search for information, perform common
investigation tasks, or initiate response actions from any place in the Cortex XSIAM
console.

Settings From the Settings menu, you can view information about your Cortex XSIAM license,
review logs of actions initiated by Cortex XSIAM analysts, and configure Cortex XSIAM
settings, integrations with other apps and services, and access management.

Tenant Navigator View and switch to tenants to which you have access divided per CSP account. You can
also navigate directly to the Cortex Gateway.

Notifications View Cortex XSIAM notifications.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 79/1003
5/8/24, 9:18 AM PDF Export

Interface Description

User From the User, see who is logged into Cortex XSIAM . Right-click and select:

About to view additional version and tenant ID information.

What’s New to view selected new features available for your license type.

Log Out to terminate the connection with your Cortex XSIAM Management Console.

2.12.1 | Manage Tables

Abstract

Learn more about managing and filtering page results in the Cortex XSIAM management console.

Most pages in Cortex XSIAM present data in table format and provide controls to help you manage and filter the results. If additional views or actions are
available for a specific value, you can pivot (right-click) from the value in the table. For example, you can view the incident details or pivot to the Causality View
for an alert or you can pivot to the results for a query.

On most pages, you can also refresh ( ) the content on the page.

Filter Page Results

Abstract

Learn more about filtering page results to reduce the number of results displayed.

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

Some fields also support additional operators such as =, !=, Contains, not Contains, *, !*.

There are three ways you can filter results:

By column using the filter next to a field heading

By building a filter query for one or more fields using the filter builder

By pivoting from the contents of a cell (show or hide rows containing)

Show me more

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 80/1003
5/8/24, 9:18 AM PDF Export

Filters are persistent. When you navigate away from the page and return, any filter you added remains active.

To build a filter using one or more fields:

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

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

2. For each field you want to filter:

a. Select or search the field.

b. Select the operator by which to match the criteria.

In most cases, this will be = to include results that match the value you specify, or != to exclude results that match the value.

c. Enter a value to complete the filter criteria.

NOTE:

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

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

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

4. Click out of the filter area into the results table to see the results.

Export Results to File

Abstract

Learn more about exporting page results to a tab-separated values (TSV) file.

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

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

2. Select export to file ( ).

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

Save and Share Filters

Abstract

Learn more about saving and sharing filters across your organization.

You can save and share filters across your organization.

1. Save a filter:

Saved filters are listed on the Filters tab for the table layout and filter manager menu.

a. Save ( ) the active filter.

b. Enter a name to identify the filter.

You can create multiple filters with the same name. Saving a filter with an existing name will not override the existing filter.

c. Choose whether to Share this filter or whether to keep it private for your own use only.

2. Share a filter:

You can share a filter across your organization.

a. Select the table layout and filter menu indicated by the three vertical dots, then select Filters.

b. Select the filter to share and click the share icon.

c. If needed, you can later unshare ( ) or delete ( ) a filter.

Unsharing a filter will turn a public filter private. Deleting a shared filter will remove it for all users.

Show or Hide Results

Abstract

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 81/1003
5/8/24, 9:18 AM PDF Export

Learn more about how you can show or hide table results.

As an alternative to building a filter query from scratch or using the column filters, you can pivot from rows and specific values to define the match criteria to fine-
tune the results in the table. You can also pivot on empty values to show only results with empty values or only results that do not have empty values in the
column from which you pivot.

NOTE:

CMD fields are limited to 128 characters. If you pivot on a CMD field with a truncated value, the app shows or hides all results that match the first 128
characters.

The show or hide action is a temporary means of filtering the results: If you navigate away from the page and later return, any results you previously hid will
appear again.

This option is available for fields that have a finite list of options.

To hide or show only results that match a specific field value:

1. Right-click the matching field value by which you want to hide or show.

2. Select the desired action:

Hide rows with <field value>

Show rows with <field value>

Hide empty rows

Show empty rows

Manage Columns and Rows

Abstract

Learn more about managing how to view the results table in the information to display in Cortex XSIAM.

From Cortex XSIAM pages, you can manage how you want to view the results table and what information you want Cortex XSIAM app to display.

Any adjustments you make to the columns or rows persist when you navigate away from and later return to the page.

1. Adjust the row height and column width:

a. On the Cortex XSIAM page, select the menu indicated by three vertical dots to the right of the filter button.

b. In View Configuration, select the desired:

Row height ranges from short to tall ( ).

Column width ranges from narrow, fixed width, or scaled to the column heading ( ).

2. Add or remove fields in the table:

a. On the Cortex XSIAM page, select the menu indicated by three vertical dots to the right of the filter button.

b. Below the column manager, search for a column by name, or select the fields you want to add or clear any fields you want to hide.

Cortex XSIAM adds or removes the fields to the table as you select or clear the fields.

c. If desired, drag and drop the fields to change the order in which they appear in the table.

3. Configure the order of the columns:

Define the order in which you want to display the field columns using the column index number. The column index number is the relative column number
displayed in the table.

a. On the Cortex XSIAM page, select the number ( ) assigned to the field name you want to change.

b. Enter the relative column number you want the field displayed in the table. The number you enter should not be greater that the number of columns.

NOTE:

Field names that are locked ( ) cannot be moved.

Display Quick Actions

Abstract

Learn more about displaying quick actions using icons available in the table rows.

From the Cortex XSIAM tables, you can quickly initiate actions using icons available in the table rows. Depending on the table, the icons provide a quick
alternative to the corresponding right-click pivot menus.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 82/1003
5/8/24, 9:18 AM PDF Export

1. Navigate to a Cortex XSIAM table throughout the Cortex XSIAM app.

2. Hover over a table row to display the available actions.

2.13 | In-product Support Case Creation

Abstract

Open a support case directly in Cortex XSIAM and record your console to capture your issues and have the case handled efficiently.

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

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

1. From Cortex XSIAM, select Help → Submit a Support Case.

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

NOTE:

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

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

NOTE:

Note: To select an endpoint from the endpoint table and to retrieve TSF requires full Retrieve Endpoint Data permissions under Endpoint Administration.

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

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

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

NOTE:

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

6. To submit the support case, click Submit Support Case.

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

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

3 | Endpoint Security
Abstract

Cortex XSIAM provides you with a wide range of endpoint security management options.

Cortex XSIAM enables you to secure your endpoints against different types of attacks using a wide range of endpoint security management options.

3.1 | Endpoint Security Concepts

Abstract

Learn about endpoint security concepts.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 83/1003
5/8/24, 9:18 AM PDF Export

3.1.1 | Endpoint Protection

Abstract

This topic provides an overview of traditional endpoint protection versus the protection of endpoints using Cortex XDR.

Cyberattacks target endpoints to inflict damage, steal information or achieve other goals that involve taking control of computer systems. Attackers perpetrate
cyberattacks either by causing a user to unintentionally run a malicious executable file, known as malware, or by exploiting a weakness in a legitimate
executable file to run malicious code behind the scenes without the knowledge of the user.

One way to prevent these attacks is to identify executable files, dynamic-link libraries (DLLs), and other pieces of code to determine if they are malicious and, if
so, to prevent the execution of these components by first matching each potentially dangerous code module against a list of specific, known threat signatures.
The weakness of this method is that it is time-consuming for signature-based antivirus (AV) solutions to identify newly created threats that are known only to the
attacker (also known as zero-day attacks or exploits) and add them to the lists of known threats, which leaves endpoints vulnerable until signatures are updated.

Cortex XSIAM takes a more efficient and effective approach to prevent attacks that eliminates the need for traditional AV. Rather than try to keep up with the
ever-growing list of known threats, Cortex XSIAM sets up a series of roadblocks—also referred to as traps—that prevent the attacks at their initial entry points—
the point where legitimate executable files are about to unknowingly allow malicious access to the system.

Cortex XSIAM provides a multi-method protection solution with exploit protection modules that target software vulnerabilities in processes that open non-
executable files and malware protection modules that examine executable files, DLLs, and macros for malicious signatures and behavior. Using this multi-
method approach, Cortex XSIAM can prevent all types of attacks, whether these are known or unknown threats.

Exploit Protection Overview

An exploit is a sequence of commands that takes advantage of a bug or vulnerability in a software application or process. Attackers use these exploits to access
and use a system to their advantage. Blocking any attempt to exploit a vulnerability in the chain will block the entire exploitation attempt.

To combat an attack in which an attacker takes advantage of a software exploit or vulnerability, Cortex XSIAM employs Endpoint Protection Modules (EPM).
Each EPM targets a specific exploit type in the attack chain. Some capabilities that Cortex XSIAM EPMs provide are reconnaissance prevention, memory
corruption prevention, code execution prevention, and kernel protection.

Malware Protection Overview

Malicious files, known as malware, are often disguised as or embedded in non-malicious files. These files can attempt to gain control, gather sensitive
information, or disrupt the normal operations of the system. Cortex XSIAM prevents malware by employing the Malware Prevention Engine. This approach
combines several layers of protection to prevent both known and unknown malware from causing harm to your endpoints. The mitigation techniques that the
Malware Prevention Engine employs vary by endpoint type.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 84/1003
5/8/24, 9:18 AM PDF Export

Malware Protection for Windows

WildFire integration—Enables automatic detection of known malware and analysis of unknown malware using WildFire threat intelligence.

Local static analysis—Enables Cortex XSIAM to use machine learning to analyze unknown files and issue a verdict. Cortex XSIAM uses the verdict
returned by the local analysis module until it receives a verdict from Cortex XSIAM.

DLL file protection—Enables Cortex XSIAM to block known and unknown DLLs on Windows endpoints.

Office file protection—Enables Cortex XSIAM to block known and unknown macros when run from Microsoft Office files on Windows endpoints.

Behavioral threat protection (Windows 7 SP1 and later versions)—Enables continuous monitoring of endpoint activity to identify and analyze chains of
events—known as causality chains. This enables Cortex XSIAM to detect malicious activity that could otherwise appear legitimate if inspected as
individual events. Behavioral threat protection requires Traps agent 6.0 or a later release.

Evaluation of trusted signers—Permits unknown files that are signed by highly trusted signers to run on the endpoint.

Malware protection modules—Target behaviors—such as those associated with ransomware—and enables you to block the creation of child processes.

Policy-based restrictions—Enables you to block files from executing from within specific local folders, network folders, or external media locations.

Periodic and automated scanning—Enables you to block dormant malware that has not yet attempted to execute on endpoints.

Malware Protection for Mac

WildFire integration—Enables automatic detection of known malware and analysis of unknown malware using WildFire threat intelligence.

Local static analysis—Enables Cortex XSIAM to use machine learning to analyze unknown files and issue a verdict. The Cortex XDR agent uses the
verdict returned by the local analysis module until it receives the WildFire verdict from Cortex XSIAM.

Behavioral threat protection—Enables continuous monitoring of endpoint activity to identify and analyze chains of events—known as causality chains.
This enables the Cortex XDR agent to detect malicious activity that could otherwise appear legitimate if inspected as individual events. Behavioral threat
protection requires Traps agent 6.1 or a later release.

Mach-O file protection—Enables you to block known malicious and unknown mach-o files on Mac endpoints.

DMG file protection—Enables you to block known malicious and unknown DMG files on Mac endpoints.

Evaluation of trusted signers—Permits unknown files that are signed by trusted signers to run on the endpoint.

Periodic and automated scanning—Enables you to block dormant malware that has not yet attempted to execute on endpoints.

Malware Protection for Linux

WildFire integration—Enables automatic detection of known malware and analysis of unknown malware using WildFire threat intelligence. WildFire
integration requires Traps agent 6.0 or a later release.

Local static analysis—Enables the Cortex XDR agent to use machine learning to analyze unknown files and issue a verdict. The Cortex XDR agent uses
the verdict returned by the local analysis module until it receives the WildFire verdict from Cortex XSIAM. Local analysis requires Traps agent 6.0 or a later
release.

Behavioral threat protection—Enables continuous monitoring of endpoint activity to identify and analyze chains of events—known as causality chains.
This enables Cortex XSIAM to detect malicious activity that could otherwise appear legitimate if inspected as individual events. Behavioral threat
protection requires Traps agent 6.1 or a later release.

ELF file protection—Enables you to block known malicious and unknown ELF files executed on a host server or within a container on a Cortex XSIAM -
protected endpoint. Cortex XSIAM automatically suspends the file execution until a WildFire or local analysis verdict is obtained. ELF file protection
requires Traps agent 6.0 or a later release.

Malware protection modules—Targets the execution behavior of a file—such as those associated with reverse shell protection.

Periodic and automated scanning—Enables you to block dormant malware that has not yet attempted to execute on endpoints.

Malware Protection for Android

WildFire integration—Enables automatic detection of known malware and grayware, and analysis of unknown APK files using WildFire threat
intelligence.

APK files examination—Analyzes and prevents malicious APK files from running.

Evaluation of trusted signers—Permits unknown files that are signed by trusted signers to run on the Android device.

3.1.2 | File Analysis and Protection Flow

Abstract

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 85/1003
5/8/24, 9:18 AM PDF Export

The Cortex XDR agent utilizes advanced multi-method protection and prevention techniques to protect from both known and unknown malware and software
exploits.

The Cortex XDR agent utilizes advanced multi-method protection and prevention techniques to protect your endpoints from both known and unknown malware
and software exploits.

Exploit Protection for Protected Processes

In a typical attack scenario, an attacker attempts to gain control of a system by first corrupting or bypassing memory allocation or handlers. Using memory-
corruption techniques, such as buffer overflows and heap corruption, a hacker can trigger a bug in the software or exploit a vulnerability in a process. The
attacker must then manipulate a program to run code provided or specified by the attacker while evading detection. If the attacker gains access to the operating
system, the attacker can then upload malware, such as Trojan horses (programs that contain malicious executable files), or can otherwise use the system to
their advantage. The Cortex XDR agent prevents such exploit attempts by employing roadblocks—or traps—at each stage of an exploitation attempt.

When a user opens a non-executable file, such as a PDF or Word document, and the process that opened the file is protected, the Cortex XDR agent
seamlessly injects code into the software. This occurs at the earliest possible stage before any files belonging to the process are loaded into memory. The
Cortex XDR agent then activates one or more protection modules inside the protected process. Each protection module targets a specific exploitation technique
and is designed to prevent attacks on program vulnerabilities based on memory corruption or logic flaws.

In addition to automatically protecting processes from such attacks, the Cortex XDR agent reports any security events to Cortex XSIAM and performs additional
actions as defined in the endpoint security policy. Common actions performed by the Cortex XDR agent include collecting forensic data and notifying the user
about the event.

The default endpoint security policy protects the most vulnerable and most commonly used applications but you can also add other third-party and proprietary
applications to the list of protected processes.

Malware Protection

The Cortex XDR agent provides malware protection in a series of four evaluation phases:

Phase 1: Evaluation of Child Process Protection Policy

When a user attempts to run an executable, the operating system attempts to run the executable as a process. If the process tries to launch any child
processes, the Cortex XDR agent first evaluates the child process protection policy. If the parent process is a known targeted process that attempts to launch a
restricted child process, the Cortex XDR agent blocks the child processes from running and reports the security event to Cortex XSIAM. For example, if a user

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 86/1003
5/8/24, 9:18 AM PDF Export

tries to open a Microsoft Word document (using the winword.exe process) and the document has a macro that tries to run a blocked child process (such as
WScript), the Cortex XDR agent blocks the child process and reports the event to Cortex XSIAM. If the parent process does not try to launch any child
processes or tries to launch a child process that is not restricted, the Cortex XDR agent next moves to Phase 2: Evaluation of the Restriction Policy.

Phase 2: Evaluation of the Restriction Policy

The Cortex XDR agent verifies that the executable file does not violate any restriction rules. For example, you might have a restriction rule that blocks
executable files launched from network locations. If a restriction rule applies to an executable file, the Cortex XDR agent blocks the file from executing and
reports the security event to Cortex XSIAM and, depending on the configuration of each restriction rule, the Cortex XDR agent can also notify the user about the
prevention event.

If no restriction rules apply to an executable file, the Cortex XDR agent next moves to Phase 3: Hash Verdict Determination.

Phase 3: Hash Verdict Determination

The Cortex XDR agent calculates a unique hash using the SHA-256 algorithm for every file that attempts to run on the endpoint. Depending on the features that
you enable, the Cortex XDR agent performs additional analysis to determine whether an unknown file is malicious or benign. The Cortex XDR agent can also
submit unknown files to Cortex XSIAM for in-depth analysis by WildFire.

To determine a verdict for a file, the Cortex XDR agent evaluates the file in the following order:

1. Hash exception—A hash exception enables you to override the verdict for a specific file without affecting the settings in your Malware Security profile.
The hash exception policy is evaluated first and takes precedence over all other methods to determine the hash verdict.

For example, you may want to configure a hash exception for any of the following situations:

You want to block a file that has a benign verdict.

You want to allow a file that has a malware verdict to run. In general, we recommend that you only override the verdict for malware after you use
available threat intelligence resources—such as WildFire and AutoFocus—to determine that the file is not malicious.

You want to specify a verdict for a file that has not yet received an official WildFire verdict.

After you configure a hash exception, Cortex XSIAM distributes it at the next heartbeat communication with any endpoints that have previously opened
the file.

When a file launches on the endpoint, the Cortex XDR agent first evaluates any relevant hash exception for the file. The hash exception specifies whether
to treat the file as malware. If the file is assigned a benign verdict, the Cortex XDR agent permits it to open.

If a hash exception is not configured for the file, the Cortex XDR agent next evaluates the verdict to determine the likelihood of malware.

2. Highly trusted signers (Windows and Mac)—The Cortex XDR agent distinguishes highly trusted signers such as Microsoft from other known signers. To
keep parity with the signers defined in WildFire, Palo Alto Networks regularly reviews the list of highly trusted and known signers and delivers any changes
with content updates. The list of highly trusted signers also includes signers that are included in the allow list from Cortex XSIAM. When an unknown file
attempts to run, the Cortex XDR agent applies the following evaluation criteria: Files signed by highly trusted signers are permitted to run, and files signed
by prevented signers are blocked, regardless of the WildFire verdict. Otherwise, when a file is not signed by a highly trusted signer or by a signer included
in the block list, the Cortex XDR agent next evaluates the WildFire verdict. For Windows endpoints, evaluation of other known signers takes place if the
WildFire evaluation returns an unknown verdict for the file.

3. WildFire verdict—If a file is not signed by a highly trusted signer on Windows and Mac endpoints, the Cortex XDR agent performs a hash verdict lookup
to determine if a verdict already exists in its local cache.

If the executable file has a malware verdict, the Cortex XDR agent reports the security event to Cortex XSIAM , and, depending on the configured
behavior for malicious files, the Cortex XDR agent performs one of the following actions.

Blocks the file.

Blocks and quarantines the file.

Notifies the user about the file but still allows the file to execute.

Logs the issue without notifying the user and allows the file to execute.

If the verdict is benign, the Cortex XDR agent moves on to the next stage of evaluation, Phase 4: Evaluation of Malware Protection Policy.

If the hash does not exist in the local cache or has an unknown verdict, the Cortex XDR agent next evaluates whether the file is signed by a known signer.

4. Local analysis—When an unknown executable, DLL, or macro attempts to run on a Windows or Mac endpoint, the Cortex XDR agent uses local analysis
to determine if it is likely to be malware. On Windows endpoints, if the file is signed by a known signer, the Cortex XDR agent permits the file to run and
does not perform additional analysis. For files on Mac endpoints and files that are not signed by a known signer on Windows endpoints, the Cortex XDR
agent performs local analysis to determine whether the file is malware. Local analysis uses a static set of pattern-matching rules that inspect multiple file
features and attributes, and a statistical model that was developed with machine learning on WildFire threat intelligence. The model enables the Cortex
XDR agent to examine hundreds of characteristics for a file and issue a local verdict (benign or malicious) while the endpoint is offline or Cortex XSIAM is
unreachable. The Cortex XDR agent can rely on the local analysis verdict until it receives an official WildFire verdict or hash exception.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 87/1003
5/8/24, 9:18 AM PDF Export

Local analysis is enabled by default in a Malware Security profile. Because local analysis always returns a verdict for an unknown file, if you enable the
Cortex XDR agent to Block files with unknown verdict, the agent only blocks unknown files if a local analysis error occurs or local analysis is disabled. To
change the default settings (not recommended), see Add a Malware Security Profile.

Phase 4: Evaluation of Malware Security Policy

If the prior evaluation phases do not identify a file as malware, the Cortex XDR agent observes the behavior of the file and applies additional malware protection
rules. If a file exhibits malicious behavior, such as encryption-based activity common with ransomware, the Cortex XDR agent blocks the file and reports the
security event to the Cortex XSIAM.

If no malicious behavior is detected, the Cortex XDR agent permits the file (process) to continue running but continues to monitor the behavior for the lifetime of
the process.

3.1.3 | Endpoint Protection Capabilities

Abstract

The endpoint protection capabilities vary depending on the platform (operating system) that is used on each of your endpoints.

Each security profile provides a tailored list of protection capabilities that you can configure for the platform you select. The following table describes the
protection capabilities you can customize in a security profile. The table also indicates which platforms support the protection capability (a dash (—) indicates the
capability is not supported).

Protection Capability Windows Mac Linux Android IOS

Exploit Security Profiles

Browser Exploits Protection — — —

Browsers can be subject to exploitation attempts from malicious web pages and exploit kits that are
embedded in compromised websites. By enabling this capability, the Cortex XDR agent automatically
protects browsers from common exploitation attempts.

Logical Exploits Protection — — —

Attackers can use existing mechanisms in the operating system—such as DLL-loading processes or built
in system processes—to execute malicious code. By enabling this capability, the Cortex XDR agent
automatically protects endpoints from attacks that try to leverage common operating system mechanisms
for malicious purposes.

Known Vulnerable Processes Protection — —

Common applications in the operating system, such as PDF readers, Office applications, and even
processes that are a part of the operating system itself can contain bugs and vulnerabilities that an
attacker can exploit. By enabling this capability, the Cortex XDR agent protects these processes from
attacks which try to exploit known process vulnerabilities.

Exploit Protection for Additional Processes — —

To extend protection to third-party processes that are not protected by the default policy from exploitation
attempts, you can add additional processes to this capability.

Operating System Exploit Protection — —

Attackers commonly leverage the operating system itself to accomplish a malicious action. By enabling
this capability, the Cortex XDR agent protects operating system mechanisms such as privilege escalation
and prevents them from being used for malicious purposes.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 88/1003
5/8/24, 9:18 AM PDF Export

Protection Capability Windows Mac Linux Android IOS

Unpatched Vulnerabilities Protection — — — —

If you have Windows endpoints in your network that are unpatched and exposed to a known vulnerability,
Palo Alto Networks strongly recommends that you upgrade to the latest Windows Update that has a fix for
that vulnerability. If you choose not to patch the endpoint, the Unpatched Vulnerabilities Protection
capability allows the Cortex XDR agent to apply a workaround to protect the endpoints from the known
vulnerability.

Malware Security Profiles

Behavioral Threat Protection — —

Prevents sophisticated attacks that leverage built-in OS executables and common administration utilities
by continuously monitoring endpoint activity for malicious causality chains.

Credential Gathering Protection — —

Targets attempts to access and harvest passwords and credentials.

Anti Webshell Protection — —

Prevents web shell attacks by continuously monitoring endpoints for processes that try to drop malicious
files.

Financial Malware Threat Protection — —

Targets attempts to access or steal financial or banking information.

Cryptominers Protection — —

Prevents cryptomining by monitoring for processes which attempt to locate or steal cryptocurrencies.

In-process Shellcode Protection — — — —

Targets attempts to run in-process shellcodes that load malicious code.

Ransomware Protection — — —

Targets encryption based activity associated with ransomware to analyze and halt ransomware before any
data loss occurs.

Prevent Malicious Child Process Execution — — — —

Prevents script-based attacks used to deliver malware by blocking known targeted processes from
launching child processes commonly used to bypass traditional security approaches.

Portable Executables and DLLs Examination — — — —

Analyzes and prevents malicious executable and DLL files from running.

ELF Files Examination — — — —

Analyzes and prevents malicious ELF files from running.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 89/1003
5/8/24, 9:18 AM PDF Export

Protection Capability Windows Mac Linux Android IOS

Local File Threat Examination — — — —

Analyzes and quarantines malicious PHP files arriving from the web server.

PDF Files Examination — — — —

Analyzes and prevents malicious macros embedded in PDF files from running.

Office Files Examination — — — —

Analyzes and prevents malicious macros embedded in Microsoft Office files from running.

Mach-O Files Examination — — — —

Analyzes and prevents malicious mach-o files from running.

DMG Files Examination — — — —

Analyzes and prevents malicious DMG files from running.

APK Files Examination — — — —

Analyzes and prevents malicious APK files from running.

Reverse Shell Protection — — — —

Detects suspicious or abnormal network activity from shell processes and terminate the malicious shell
process.

Network Packet Inspection Engine — — — —

Analyzes network packet data to detect malicious behavior.

SMS and MMS Malicious URL filtering — — — —

Spam Reports — — — —

Call and Messages Blocking — — — —

Container-escaping attempts — — — —

Network URL filtering — — — —

URL filtering for supervised devices

Restrictions Security Profiles

Execution Paths — — — —

Many attack scenarios are based on writing malicious executable files to certain folders such as the local
temp or download folder and then running them. Use this capability to restrict the locations from which
executable files can run.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 90/1003
5/8/24, 9:18 AM PDF Export

Protection Capability Windows Mac Linux Android IOS

Network Locations — — — —

To prevent attack scenarios that are based on writing malicious files to remote folders, you can restrict
access to all network locations except for those that you explicitly trust.

Removable Media — — — —

To prevent malicious code from gaining access to endpoints using external media such as a removable
drive, you can restrict the executable files, that users can launch from external drives attached to the
endpoints in your network.

Optical Drive — — — —

To prevent malicious code from gaining access to endpoints using optical disc drives (CD, DVD, and Blu-
ray), you can restrict the executable files, that users can launch from optical disc drives connected to the
endpoints in your network.

3.1.4 | Endpoint Protection Modules

Abstract

Security modules are activated for your endpoints depending on the chosen security profile and the operating system on the endpoint.

Each security profile applies multiple security modules to protect your endpoints from a wide range of attack techniques. While the settings for each security
module are not configurable, the Cortex XDR agent activates a specific protection module depending on the type of attack, the configuration of your security
policy, and the operating system of the endpoint.

When a security event occurs, the Cortex XDR agent logs details about the event including the security module employed by the Cortex XDR agent to detect
and prevent the attack based on the technique. To help you understand the nature of the attack, the alert identifies the protection module the Cortex XDR agent
employed.

The following table lists the modules and the platforms on which they are supported. A dash (—) indicates that the module is not supported.

Module Windows Mac Linux Android

Anti-Ransomware — —

Targets encryption-based activity

associated with ransomware and have
the ability to analyze and halt
ransomware activity before any data
loss occurs.

APC Protection — — —

Prevents attacks that change the

execution order of a process by
redirecting an asynchronous procedure
call (APC) to point to the malicious
shellcode.

Behavioral Threat —

Prevents sophisticated attacks that

leverage built-in OS executables and
common administration utilities by
continuously monitoring endpoint
activity for malicious causality chains.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 91/1003
5/8/24, 9:18 AM PDF Export

Module Windows Mac Linux Android

Brute Force Protection — — —

Prevents attackers from hijacking the

process control flow by monitoring
memory layout enumeration attempts.

Child Process Protection — — —

Prevents script-based attacks that are

used to deliver malware, such as
ransomware, by blocking known
targeted processes from launching child
processes that are commonly used to
bypass traditional security approaches.

Container Escaping Protection — — —

Prevents container-escaping attempts

CPL Protection — — —

Protects against vulnerabilities related

to the display routine for Windows
Control Panel Library (CPL) shortcut
images, which can be used as a
malware infection vector.

Data Execution Prevention (DEP) — — —

Prevents areas of memory defined to

contain only data from running
executable code.

DLL Hijacking — — —

Prevents DLL-hijacking attacks where

the attacker attempts to load dynamic-
link libraries on Windows operating
systems from unsecured locations to
gain control of a process.

DLL Security — — —

Prevents access to crucial DLL

metadata from untrusted code
locations.

Dylib Hijacking — — —

Prevents Dylib-hijacking attacks where

the attacker attempts to load dynamic
libraries on Mac operating systems
from unsecured locations to gain
control of a process.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 92/1003
5/8/24, 9:18 AM PDF Export

Module Windows Mac Linux Android

Exploit Kit Fingerprint — — —

Protects against the fingerprinting

technique used by browser exploit kits
to identify information—such as the OS
or applications which run on an
endpoint—that attackers can leverage
when launching an attack to evade
protection capabilities.

Font Protection — — —

Prevents improper font handling, a

common target of exploits.

Gatekeeper Enhancement — — —

Enhances the macOS gatekeeper

functionality that allows apps to run
based on their digital signature. This
module provides an additional layer of
protection by extending gatekeeper
functionality to bundles and child
processes so you can enforce the
signature level of your choice.

Hash Exception

Halts execution of files that an

administrator identified as malware
regardless of the WildFire verdict.

Hot Patch Protection — — —

Prevents the use of system functions to

bypass DEP and address space layout
randomization (ASLR).

Java Deserialization — — —

Blocks attempts to execute malicious

code during the Java objects
deserialization process on Java-based
servers.

JIT — —

Prevents an attacker from bypassing

the operating system's memory
mitigations using just-in-time (JIT)
compilation engines.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 93/1003
5/8/24, 9:18 AM PDF Export

Module Windows Mac Linux Android

Kernel Integrity Monitor (KIM) — — —

Prevents rootkit and vulnerability

exploitation on Linux endpoints. On the
first detection of suspicious rootkit
behavior, the behavioral threat
protection (BTP) module generates a
Cortex XDR Agent alert. Cortex XSIAM
stitches logs about the process that
loaded the kernel module with other
logs relating to the kernel module to aid
in the alert investigation. When the
Cortex XDR agent detects subsequent
rootkit behavior, it blocks the activity.

Local Analysis —

Examines hundreds of characteristics

of an unknown executable file, DLL, or
macro to determine if it is likely to be
malware. The local analysis module
uses a static set of pattern-matching
rules that inspect multiple file features
and attributes, and a statistical model
that was developed using machine
learning on WildFire threat intelligence.

Local Threat Evaluation Engine — — —

(LTEE)

Protects against malicious PHP files

arriving from the web server.

Local Privilege Escalation Protection —

Prevents attackers from performing

malicious activities that require
privileges that are higher than those
assigned to the attacked or malicious
process.

Master Boot Record (MBR) Model — — —

Protects against malicious Master Boot

Record (MBR) manipulations.

Network Packet Inspection Engine — — —

Analyze network packet data to detect

malicious behavior already at the
network level. The engine leverages
both Palo Alto Networks NGFW content
rules, and new Cortex XDR content
rules created by the Research Team
which are updated through the security
content.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 94/1003
5/8/24, 9:18 AM PDF Export

Module Windows Mac Linux Android

Null Dereference — — —

Prevents malicious code from mapping

to address zero in the memory space,
making null dereference vulnerabilities
unexploitable.

Restricted Execution - Local Path — — —

Prevents unauthorized execution from a

local path.

Restricted Execution - Network — — —

Location

Prevents unauthorized execution from a

network path.

Restricted Execution - Removable — — —

Media

Prevents unauthorized execution from

removable media.

Reverse Shell Protection — — —

Blocks malicious activity where an

attacker redirects standard input and
output streams to network sockets.

ROP —

Protects against the use of return-

oriented programming (ROP) by
protecting APIs used in ROP chains.

SEH — — —

Prevents hijacking of the structured

exception handler (SEH), a commonly
exploited control structure that can
contain multiple SEH blocks that form a
linked list chain, which contains a
sequence of function records.

Shellcode Protection — — —

Reserves and protects certain areas of

memory commonly used to house
payloads using heap spray techniques.

ShellLink — — —

Prevents shell-link logical

vulnerabilities.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 95/1003
5/8/24, 9:18 AM PDF Export

Module Windows Mac Linux Android

SO Hijacking Protection — — —

Prevents dynamic loading of libraries

from unsecured locations to gain
control of a process.

SysExit — — —

Prevents using system calls to bypass

other protection capabilities.

UASLR — — —

Improves or altogether implements

ASLR (address space layout
randomization) with greater entropy,
robustness, and strict enforcement.

Vulnerable Drivers Protection — — —

Detect attempts to load vulnerable

drivers.

WildFire

Leverages WildFire for threat

intelligence to determine whether a file
is malware. In the case of unknown
files, Cortex XDR can forward samples
to WildFire for in-depth analysis.

WildFire Post-Detection (Malware

and Grayware)

Identifies a file that was previously

allowed to run on an endpoint that is
now determined to be malware. Post-
detection events provide notifications
for each endpoint on which the file is
executed.

3.2 | Communication
Abstract

Learn about agent-initiated and server-initiated communication between Cortex XSIAM and its agents.

To stay up to date with the latest policy and endpoint status, Cortex XSIAM communicates regularly with your Cortex XDR agents. For example, when you
upgrade your endpoints to the latest release, Cortex XSIAM creates an installation package and distributes it to the agent on their next communication. Similarly,
the agent can send back data from the endpoint to Cortex XSIAM, such as data gathered on the endpoint or tech support files. In Cortex XSIAM, there are two
types of communication:

Agent-Initiated Communication

Server-Initiated Communication

Cortex XSIAM collects your agent logs to improve the agent stability. Collection of the logs is enabled by default and is recommended by Cortex XSIAM. You
can choose to disable in Settings → General → Agent Configurations → Cortex XSIAM Log Collection section.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 96/1003
5/8/24, 9:18 AM PDF Export

Agent-Initiated Communication

The Cortex XDR agent initiates communication with Cortex XSIAM every five minutes by sending a heartbeat to the server. An agent heartbeat includes data
about the Cortex XDR agent, and information gathered by the agent on the endpoint. For example, policy updates are performed via heartbeat: in each
heartbeat the Cortex XDR agent sends to the Cortex XSIAM server the content version it uses. The Cortex XSIAM server compares this number with the
number of latest content in use, and sends the agent a message to download newer content if it exists.

However not all agent-server communication is sent over the five-minute heartbeat. If a security event occurs on the endpoint, the agent immediately sends the
server a security event message so you can respond immediately to the event and initiate investigation and remediation actions on the endpoint. If the message
is not critical, such as status reports, the agent sends them once an hour.

Cortex XDR agents support secure communication with Cortex XSIAM using Transport Layer Security (TLS) 1.2 only.

Server-Initiated Communication

(Traps agent 6.1 and later releases) Cortex XSIAM can initiate some actions immediately on the endpoint through a web socket that is maintained between
Cortex XSIAM and the Cortex XDR agent, improving the response action time and preventing delays. Examples of these actions include:

Quarantine file and restore file

Terminate process

Isolate endpoint and cancel endpoint isolation

Initiate Live Terminal

Set endpoint proxy disable endpoint proxy

Retrieve endpoint files

Retrieve security event data

Retrieve support file

Perform heartbeat

NOTE:

The actions that can be performed via web socket are only actions that your current agent version already supports.

If the web socket communication fails, the action will be executed on the next successful Cortex XDR agent heartbeat. You can use Cytool to display the current
web socket connection status by running the websocket command on the endpoint.

3.3 | Manage Agents

Abstract

The Cortex XDR agent is installed on each of your endpoints, and you can manage the deployment of agents as necessary.

The Cortex XDR agent is installed on each of your endpoints. Using the management console, you can create an agent installation package, install the Cortex
XDR agent on your endpoints, and manage the deployment of agents.

3.3.1 | Create an Agent Installation Package

Abstract

Learn how to create a Cortex XDR agent installation package to deploy to your endpoints.

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

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

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

To create a new installation package:

1. From Cortex XSIAM, select Endpoints → Agent Installations.

2. Create a new installation package.

3. Enter a unique Name and an optional Description to identify the installation package.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 97/1003
5/8/24, 9:18 AM PDF Export

The package Name must be no more than 100 characters and can contain letters, numbers, hyphens, underscores, commas, and spaces.

4. Select the Package Type.

Standalone Installers—Use for fresh installations and to Upgrade Cortex XDR Agents on a registered endpoint that is connected to Cortex XSIAM.

Upgrade from ESM—Use this package to upgrade Traps agents which connect to the on-premises Traps Endpoint Security Manager to Cortex
XSIAM. For more information, see Migrate from Traps Endpoint Security Manager.

(Linux only) Kubernetes Installer—Use for fresh installations and upgrades of Cortex XDR agents running on Kubernetes clusters.

Helm Installer—Use this package for fresh installations and upgrades of Cortex XDR agents running on Kubernetes clusters.

5. Specify the installation package settings.

(Windows, macOS, and Linux) Select the Platform for which you want to create the installation package and the Agent Version for the package.

(Kubernetes only) Configure the settings for your YAML deployment. These settings cannot be changed after you create the installation package:

Select the Agent Version for the package. Critical Environment versions are displayed as CE versions. Enable Always deploy with latest agent
version to ensure that each new node will launch the latest Cortex XDR agent release for which a YAML installation package was created.
You must assign an Agent Settings Profile where Agent Auto Upgrade is enabled for this deployment method.

Set the Cortex XDR agent DaemonSet namespace. For simplified management, it is recommended to use the default cortex-xdr namespace.

For a more granular deployment, enter any labels or selectors in the Node Selector. The Cortex XDR agent will be deployed only on these
nodes.

Configure the Cortex XDR agent to communicate through an intermediary such as a proxy or the Palo Alto Networks Broker Service. To
enable the agent to communicate directly with the intermediary, use this installation option to assign the IP address and port number you want
the Cortex XDR agent to use. You can also configure the proxy by entering the FQDN and port number. When you enter the FQDN, you can
use both lowercase and uppercase letters. Avoid using special characters or spaces. Use commas to separate multiple addresses.

NOTE:

The Cortex XDR agent does not support proxy communication in environments where proxy authentication is required.

You can configure the Cortex XDR agent to Run on master node, or Run on all nodes.

6. Create the installation package.

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

7. Download your installation package.

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

For Windows endpoints, select between the architecture type. You can download the installer msi file only, or for Cortex XDR agents 7.4 and later, a
distribution package that includes both the installer msi file and the latest content zip. The distribution package is recommended to reduce the
network load and time typically required for the initial roll-out or major upgrades of the Cortex XDR agent. To understand the benefits, workflow, and
requirements to support this type of deployment, refer to the Cortex XDR Agent Administrator Guide.

For macOS endpoints, download the ZIP installation folder and upload it to the endpoint. To deploy the Cortex XDR agent using JAMF, upload the
ZIP folder to JAMF. Alternatively, to install the agent manually on the endpoint, unzip the ZIP folder and double-click the pkg file.

For Linux endpoints, you can download .rpm or .deb installers (according to the endpoint Linux distribution), and deploy the installers on the
endpoints using the Linux package manager. Alternatively, you can download a Shell installer and deploy it manually on the endpoint.

NOTE:

When you upgrade a Cortex XDR agent version without the package manager, Cortex XSIAM upgrades the installation process to the package
manager by default, according to the endpoint Linux distribution.

For Kubernetes clusters on Linux endpoints, download the YAML file. Palo Alto Networks strongly recommends that you do not edit this file.

For Android endpoints, Cortex XSIAM creates a tenant-specific download link that you can distribute to Android endpoints. When a newer agent
version is available, Cortex XSIAM identifies older package versions as [Outdated].

8. Next steps:

As needed, you can return to the Agent Installations page to manage your agent installation packages. To manage a specific package, right-click the agent
version, and select the desired action:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 98/1003
5/8/24, 9:18 AM PDF Export

Edit the package name or description.

Delete the installation package. Deleting an installation package does not uninstall the Cortex XDR agent software from any endpoints.

NOTE:

Since Cortex XSIAM relies on the installation package ID to approve agent registration during the installation, we recommend that you don't
delete the installation package of active endpoints. If you install the Cortex XDR agent from a package after you delete it, Cortex XSIAM denies
the registration request leaving the agent in an unprotected state. Hiding the installation package removes it from the default list of available
installation packages, and can be useful for preventing confusion within the management console main view. The hidden installation can be
viewed by removing the default filter.

Copy text to clipboard to copy the text from a specific field in the row of an installation package.

Hide installation packages. Using the Hide option provides a quick method to filter out results based on a specific value in the table. You can also
use the filters at the top of the page to build a filter from scratch. To create a persistent filter, save ( ) it.

3.3.2 | Set an Application Proxy for Cortex XDR Agents

Abstract

Set an application-specific proxy for the Cortex XDR agent without affecting the communication of other applications on the endpoint.

NOTE:

This capability is supported on endpoints with Traps agent 5.0.9 (Windows only) or Cortex XDR agent 7.0 and later releases.

In environments where agents communicate with the Cortex XSIAM server through a wide-system proxy you can now set an application-specific proxy for the
Traps and Cortex XDR agent without affecting the communication of other applications on the endpoint. You can set the proxy during the agent installation, after
installation using Cytool on the endpoint, or from All Endpoints in Cortex XSIAM, as described in this topic.

You can assign up to five different proxy servers per agent. The proxy server the agent uses is selected randomly and with equal probability. If communication
fails between the agent and the Cortex XSIAM server through the app-specific proxies, the agent resumes communication through the system-wide proxy
defined on the endpoint. If that fails as well, the agent resumes communication with Cortex XSIAM directly.

1. From Cortex XSIAM, select Endpoints → All Endpoints.

2. If needed, filter the list of endpoints.

3. Set an agent proxy.

a. Select the row of the endpoint for which you want to set a proxy.

b. Right-click the endpoint and select Endpoint Control → Set Agent Proxy.

c. You can assign up to five different proxies per agent. For each proxy, enter the IP address and port number. For Cortex XDR agents 7.2.1 and later,
you can also configure the proxy by entering the FQDN and port number. When you enter the FQDN, you can use either all lowercase letters or all
uppercase letters. Avoid using special characters or spaces.

For example, my.network.name:808,YOUR.NETWORK.COM:888,10.196.20.244:8080.

d. Set when you’re done.

e. If required, you can Disable Agent Proxy from the right-click menu.

When you disable the proxy configuration, all proxies associated with that agent are removed. The agent resumes communication with the Cortex
XSIAM server through the system-wide proxy. If a system-wide proxy is not defined, the agent resumes direct communication with the Cortex
XSIAM server. If neither a system-wide proxy nor direct communication exists, the agent will disconnect from Cortex XSIAM.

3.3.3 | Move Agents Between Managing Servers

Abstract

When needed, you can move Cortex XDR agents to other Cortex XSIAM managing servers.

You can move existing agents between Cortex XSIAM managing servers directly from the Cortex XSIAM management console. This can be useful during
migration, POCs or to better manage your agent allocation between tenants. When you change the server that manages the agent, the agent transfers to the
new managing server as a freshly installed agent, without any data that was stored on the original managing server. After the Cortex XDR agent registers with
the new server, it can no longer communicate with the previous one.

Consider the following prerequisites before you change the managing server of a Cortex XDR agent:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 99/1003
5/8/24, 9:18 AM PDF Export

Ensure that you are running a Cortex XDR agent 7.2 or later release.

Endpoint Type is not Kubernetes Node.

Installation Type is not VDI.

Ensure you have administrator privileges for Cortex XSIAM in the hub.

To register to another managing server, the Cortex XDR agent requires a distribution ID of an installation package on the target server in order to identify itself
as a valid Cortex XDR agent. The agent must provide an ID of an installation package that matches the same operating system for the same or a previous agent
version. For example, if you want to move a Cortex XDR Agent 7.0.2 for Windows, you can select from the target managing server the ID of an installation
package created for a Cortex XDR Agent 5.0.0 for Windows. The operating system version can be different.

NOTE:

Cortex XSIAM does not support moving agents between FedRamp and commercial tenants.

To change the managing server of a Cortex XDR Agent:

1. Obtain an installation package ID from the target managing server.

a. Log in to Cortex XSIAM on the target management server, then navigate to Endpoints → Agent Installations.

b. From the agent installations table, locate a valid installation package you can use to register the agent. Alternatively, you can create a new
installation package if required.

c. Right-click the ID field and copy the value. Save this value, as you will need it later for the registration process. If the ID column is not displayed in
the table, add it.

2. Locate the Cortex XDR agent you want to move.

Log in to the current managing server of the Cortex XDR agent and navigate to Endpoints → All Endpoints.

3. Change the managing server.

a. Select one or more agents that you want to move to the target server.

b. Right-click + Alt to open the options menu in advanced mode, and select Endpoint Control → Change managing server. This option is available only
for an administrator in Cortex XSIAM and for Cortex XDR agent 7.2 and later.

c. Enter the ID number of the installation package you obtained in Step 1. If you selected agents running on different operating systems, for example,
Windows and Linux, you must provide an ID for each operating system. When done, click Move.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 100/1003
5/8/24, 9:18 AM PDF Export

4. Track the action.

When you track the action in the Action Center, the original managing server will keep displaying In progress (Sent) status also after the action has ended
successfully, since the agent no longer reports to this managing server. The new managing server will add this as a new agent registration action.

3.3.4 | Upgrade Cortex XDR Agents

Abstract

You can upgrade the Cortex XDR agent software by using the appropriate method for the endpoint operating system.

After you install the Cortex XDR agent and the agent registers with Cortex XSIAM, you can upgrade the Cortex XDR agent software using a method supported
by the endpoint platform:

IMPORTANT:

The following list includes important points to take into account when upgrading the Cortex XSIAM agent:

You cannot upgrade the Cortex XSIAM agent on VDI endpoints or a Golden Image.

You must reinstall (uninstall and install again) the relevant agent version on the Golden Image,

Installing a Golden Image for the Citrix App Layering environment must be performed on OS layer only.

Every new agent version installation must be performed on OS layer's version where the agent was not previously installed. There is no possibility to
reinstall agent on the Golden Image for the Citrix App Layering environment.

WARNING:

You must ensure that the System Extensions were approved on the endpoint. Otherwise, if the extensions were not approved, after the upgrade the
extensions remain on the endpoint without any option to remove them which could cause the agent to display unexpected behavior. To check whether
the extensions were approved, you can either verify that the endpoint is in Fully Protected state in Cortex XSIAM, or execute the following command
line on the endpoint to list the extensions: systemextensionsctl list. If you need to approve the extensions, follow the workflow explained in the
Cortex XDR agent administration guide for approving System Extensions.

Android—Upgrade the app directly from the Google Play Store or push the app to your endpoints from an endpoint management system such as
AirWatch.

Windows, Mac, or Linux—Create new installation packages and push the Cortex XDR agent package to up to 5,000 endpoints from Cortex XSIAM.

Upgrades are supported using actions that you can initiate from the Action Center or from All Endpoints as described in this workflow.

1. Create an Agent Installation Package for each operating system version for which you want to upgrade the Cortex XDR agent.

Note the installation package names.

2. Select Endpoints → All Endpoints.

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

3. Select the endpoints you want to upgrade.

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

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

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

Starting in the Cortex XDR agent 7.1 release, you can install the Cortex XDR agent on Linux endpoints using a package manager. When you upgrade an
agent on a Linux endpoint that is not using a package manager, Cortex XSIAM upgrades the installation process by default according to the endpoint
Linux distribution. Alternatively, if you do not want to use the package manager, clear the option Upgrade to installation by package manager.

NOTE:

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

5. Upgrade.

Cortex XSIAM distributes the installation package to the selected endpoints at the next heartbeat communication with the agent. To monitor the status of
the upgrades, go to Response → Action Center. From the Action Center you can also view additional information about the upgrade (right-click the action
and select Additional data) or cancel the upgrade (right-click the action and select Cancel Agent Upgrade).

NOTE:

Custom dashboards that include upgrade status widgets, and the All Endpoints page display upgrade status.

During the upgrade process, the endpoint operating system might request a reboot. However, you do not have to perform the reboot for the
Cortex XDR agent upgrade process to complete it successfully.

After you upgrade to a Cortex XDR agent 7.2 or a later release on an endpoint with Cortex XSIAM Device Control rules, you need to reboot the
endpoint for the rules to take effect.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 101/1003
5/8/24, 9:18 AM PDF Export

3.3.5 | Set a Cortex XDR Agent Critical Environment Version

Topic Not Found

3.3.6 | Clear Agent Database

Abstract

Clear the Cortex XDR agent database

In cases where your Cortex XDR agent is having issues, you can attempt a reset by clearing the Cortex XDR agent state of one or more endpoints.

NOTE:

Clearing the agent database is supported on all platforms with Cortex XDR agent version 7.9 or above and is available only when using the debugging mode.

Clearing the agent database is available only when using the debugging mode, and can be tracked in the Action Center.

1. Clear Agent Database

a. Navigate to Endpoints → All Endpoints and select one or more endpoints for which you want to clear the database.

b. ALT+Right-Click, in macOS Option+Right-Click, to open the context menu in debugging mode.

c. Navigate to Endpoint Control → Clear Agent Database.

2. Track Clear Database Action

a. Navigate to Incident Response → Response → Action Center.

b. In the All Actions table, filter the Action Type field according to Agent Database Cleanup.

NOTE:

You can only right-click to cancel the clear agent database for actions with Status Pending.

3.3.7 | Delete Cortex XDR Agents

Abstract

Delete endpoints from the management console views.

If you have an endpoint that you no longer want to track through the Cortex XSIAM management console, for example, if the endpoint disconnected from Cortex
XSIAM, or an endpoint where the Cortex XDR agent was uninstalled, you can delete the endpoint from the management console views. Deleting an endpoint
triggers the following lifespan flow:

The endpoint status changes to Deleted, and the license returns immediately to the license pool. After a retention period of 90 days, the agent is deleted
from the database and is displayed in Cortex XSIAM as Endpoint Name - N/A (Deleted).

Data associated with the deleted endpoint is displayed in the Action Center tables and in the Causality View for the standard 90 days retention period.

Alerts that already include the endpoint data at the time of alert creation are not affected.

Additionally, Cortex XSIAM automatically deletes agents after a long period of inactivity.

Standard agents are deleted after 180 days of inactivity. Where day one is the first 24 hours of continuous inactivity.

VDI and TS agents are deleted after 6 hours of inactivity.

NOTE:

To reinstate an endpoint, you have to uninstall and reinstall the agent.

The following workflow describes how to delete the Cortex XDR agent from one or more Windows, Mac, or Linux endpoints.

1. Select Endpoints → All Endpoints.

2. Right-click the endpoint you want to remove.

You can also select multiple endpoints if you want to perform a bulk delete.

3. Select Endpoint Control → Delete Endpoint.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 102/1003
5/8/24, 9:18 AM PDF Export

3.3.8 | Uninstall the Cortex XDR Agent

Abstract

You can uninstall Cortex XDR agent from one or more endpoints at any time using the Action Center, or one-by-one using the All Endpoints page.

If you want to uninstall the Cortex XDR agent from the endpoint, you can do so from the Cortex XSIAM management console at any time. You can uninstall them
from an unlimited number of endpoints in a single bulk action using the Action Center. You can also uninstall each endpoints one-by-one, using the All Endpoints
page. Uninstalling an endpoint triggers the following lifespan flow:

Once you uninstall the agent from the endpoint, the action is immediate. All agent files and protections are removed from the endpoint, leaving the
endpoint unprotected.

The endpoint status changes to Uninstalled, and the license returns immediately to the license pool. After a retention period of 7 days, the agent is
deleted from the database and is displayed in Cortex XSIAM as Endpoint Name - N/A (Uninstalled).

Data associated with the deleted endpoint is displayed in the Action Center tables and in the Causality View for the standard 90 days retention period.

Alerts that already include the endpoint data at the time of the alert creation are not affected.

NOTE:

Before upgrading a Cortex XDR agent 7.0 or later running on macOS 10.15.4 or later, you must ensure that the System Extensions were approved on the
endpoint. Otherwise, if the extensions were not approved, after the upgrade the extensions remain on the endpoint without any option to remove them which
could cause the agent to display unexpected behavior. To check whether the extensions were approved, you can either verify that the endpoint is in a Fully
Protected state in Cortex XDR or execute the following command line on the endpoint to list the extensions: systemextensionsctl list. If you need to
approve the extensions, follow the workflow explained in the Cortex XDR agent administration guide for approving System Extensions.,

NOTE:

For iOS and Android endpoints, uninstallation will reset account registration and data, but the app itself will remain on the device until removed locally by the
user. The endpoint will be disconnected, and the user will no longer be able to connect the app to the tenant account.

Uninstall endpoints using the Action Center

1. Log in to Cortex XSIAM.

Go to Incident Response → ResponseAction Center.

2. Click + New Action.

3. Select Agent Uninstall.

4. Click Next.

5. Select the target endpoints (up to 100) for which you want to uninstall the Cortex XDR agent.

TIP:

If needed, Filter the list of endpoints by attribute or group name.

6. Click Next.

7. Review the action summary and click Done when finished.

8. To track the status of the uninstallation, return to the Action Center.

Uninstall endpoints using the All Endpoints page

1. Log in to Cortex XSIAM.

Go to Endpoints → All Endpoints.

2. Find and then right-click the agent that you want to uninstall, and select Endpoint Control → Uninstall Agent.

3. In the confirmation dialog box that appears, select I agree, and click OK.

3.3.9 | Set an Alias for an Endpoint

Abstract

To identify one or more endpoints by a name that is different from the endpoint hostname, you can configure an alias.

To identify one or more endpoints by a name that is different from the endpoint hostname, you can configure an alias. You can set an alias for a single endpoint
or you can set an alias for multiple endpoints in bulk. To quickly search for the endpoints during an investigation and when you need to take action, you can use
either the endpoint hostname or the alias.

1. Select Endpoints → All Endpoints.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 103/1003
5/8/24, 9:18 AM PDF Export

2. Select one or more endpoints.

3. Right-click anywhere in the endpoint rows.

4. Select Endpoint Control → Change Endpoint Alias.

5. Enter the alias name and Update.

TIP:

If you change your mind in the future, you can select Endpoint Control → Change Endpoint Alias again, and delete the required aliases.

6. Use the Quick Launcher to search the endpoints by alias across the Cortex XSIAM management console.

3.3.10 | Manage Endpoint Tags

Abstract

Segment your endpoints according to dynamic tags.

Endpoint tags enable multiple layers of segmentation to your endpoints. An endpoint tag is a dynamic entity that is created and assigned to one or more
endpoints. The assigned endpoint tags can then be used to create Endpoint Groups, Policies, and Actions.

NOTE:

The following uses Windows operating system installation parameters and Cytool argument examples.

Create an Endpoint Tag

An endpoint tag can be created during installation of the Cortex XSIAM agent.

An endpoint tag can be created after installation either from the Cortex XSIAM agent or from the Cortex XSIAM management console.

Add an endpoint tag as an installation parameter of the Cortex XSIAM agent's installer:

1. Installer parameter: run msiexec /i ... ENDPOINT_TAGS="Name1, Name 2, Name3".

Cytool argument: cytool endpoint_tags add "tag1 [,tag2,...,tagN]".

NOTE:

Tag names are case sensitive.

For Windows and Mac, a tag name can contain spaces.

Linux does not support tag names with spaces as command line arguments to the shell installer. Instead, tags can be set in the
/etc/panw/cortex.conf configuration file, which supports all Linux installers.

Add an endpoint tag after installation:

From the machine where theCortex XSIAM agent is installed:

1. Navigate to the Cytool folder location and open the CLI as an administrator.

2. Cytool argument: cytool endpoint_tags add "tag1 [,tag2, ...,tagN]".

NOTE:

Tag names are case sensitive and can contain spaces.

From the Cortex XSIAM management console (Server)

1. Navigate to Endpoints → All Endpoints → Tags field.

2. Select one or more endpoints, right-click, and select Endpoint Control → Assign Endpoint Tags.

3. Select Add tag... and choose one or more tags from the list of existing tags or begin to type a new tag name to Create tag.

NOTE:

Tag names are case sensitive and can contain spaces.

4. (This step requires administrator permissions) To assign the tag to users or user groups, select Add selected tags to Users or Groups, and
select the relevant Users and/or User Groups.

NOTE:

When SBAC is enabled, assigning tags may impact user permissions.

5. Save the tag names you selected.

Remove an Endpoint Tag

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 104/1003
5/8/24, 9:18 AM PDF Export

Depending on where you created your tag, Server or Agent, you can choose to edit or remove the tags.

From the Cortex XSIAM agent:

1. Navigate to the Cytool folder location and open the CLI as an administrator.

2. Cytool Argument: cytool endpoint_tags remove "tag1 [,tag2, ...,tagN]".

From the Cortex XSIAM management console:

1. Navigate to Endpoints → All Endpoints → Tags field.

2. Select one or more endpoints, right-click, and select Endpoint Control → Remove Endpoint Tags.

3. Save the tag names you removed.

NOTE:

If you remove the tag and there are assigned users or user groups with scope settings, this can impact user permissions in the system.

Track Your Endpoint Tags

From the XDR agent:

1. Navigate to the Cytool folder location and open the CLI as an administrator.

2. For Cytool: cytool endpoint_tags list.

From the Cortex XSIAM management console:

1. Navigate to Endpoints → All Endpoints → Tags field.

All Server and Agent tags associated with the specific endpoint are displayed. Tags created in the XDR agent are displayed with a shield icon.

2. Filter and search the Tags field for the endpoint tags you have created and assigned.

3.3.11 | Manage Agent Tokens

Topic Not Found

3.3.11.1 | Retrieve Support File Password

Abstract

Learn how to retrieve the password to access files from the Tech Support File (TSF), which is generated in a zip format protected by an encrypted password.

From agent version 7.8 and above, the Tech Support File (TSF) is generated in a zip format protected by an encrypted password. The TSF file is archived inside
another file which also includes a metadata file that contains a token. The token is used to retrieve the password to unzip the TSF file.

To retrieve the password for the TSF file from the endpoint, go to the Cortex XSIAM server from the Tokens and Passwords option.

To retrieve the password for the TSF file from the server, go to the Action Center.

1. Retrieve Support File Password from Endpoints → All Endpoints.

1. At the top of the page, click the Tokens and Passwords button and select Retrieve Support File Password option.

2. In the Retrieve Support File Password dialog, in the Encrypted Password field, paste the token that you copied from the metadata file located in the
saved file when running the Cytool log collect.

3. Click the copy button to copy the password displayed and then click Ok. Use the password to unzip the TSF file.

2. Retrieve Support File Password from Action Center → All Actions.

1. Right-click the relevant action of action type Support File Retrieval and select Additional Data.

2. Right-click the action and select Retrieve Support File Password.

3. In the Retrieve Support File Password dialog, in the Encrypted Password field, paste the token that you copied from the metadata file located in the
download file.

4. Click the copy button to copy the password displayed and then click Ok. Use the password to unzip the TSF file.

3.3.12 | Send Push Notifications to iOS

Abstract

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 105/1003
5/8/24, 9:18 AM PDF Export

Learn how to send push notifications to an iOS endpoint.

You can push a notification to the Cortex XDR agent on the iOS device from the Cortex XSIAM management console.

Navigate to Endpoints → All Endpoints and locate the required iOS device or devices.

Right-click and select from Endpoint Control, Send Push Notification.

Select one of the following notifications to send to the agent.

Notification Action

Device Checkup When the App user taps the received notification, the Cortex XDR app will
open on the device, ready to perform the checkup.

Tap Perform Check Up to initiate a device checkup.

Verify App Permissions If the Phone permissions are not set correctly for full protection, the user is
instructed to allow permission.

The App user must tap Open Permissions Wizard from the iOS device
Home screen and follow the wizard to enable and allow the required settings
for full protection.

Custom message Admin can send a message with a header and body text to designated
Cortex XDR App users. The App user will receive this textual message.

3.3.13 | Restart Agent

Abstract

How to restart the agent on the endpoint.

You can restart an agent from the Cortex XSIAM management console. This action is hidden by default.

As soon as the action is confirmed, the restart command triggers a restart of the agent on the endpoint.

1. From Cortex XSIAM, navigate to Endpoints → All Endpoints. Select the relevant endpoint/s to restart and right click + Alt and select Endpoint Control →
Restart Agent and click OK.

2. Select I agree and then click OK to confirm restarting the agent on all endpoints selected.

3.4 | Define Endpoint Groups

Abstract

To easily apply policy rules and manage specific endpoints, you can define an endpoint group.

To easily apply policy rules and manage specific endpoints, you can define an endpoint group. If you set up Cloud Identity Engine, you can also leverage your
Active Directory user, group, and computer information in endpoint groups.

There are two methods you can use to define an endpoint group:

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

Create a static group by selecting a list of specific endpoints.

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

To define an endpoint static or dynamic group:

1. From Cortex XSIAM , select Endpoints → Endpoint Groups → +Add Group.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 106/1003
5/8/24, 9:18 AM PDF Export

2. Select either Create New to create an endpoint group from scratch, or Upload From File, using plain text files with a new line separator, to populate a
static endpoint group from a file containing IP addresses, hostnames, or aliases.

3. Enter a Group Name and optional Description to identify the endpoint group. The name you assign to the group will be visible when you assign endpoint
security profiles to endpoints.

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

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

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

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

NOTE:

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

5. Create the endpoint group.

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

6. Manage an endpoint group, as needed.

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

Edit—View the endpoints that match the group definition, and optionally refine the membership criteria using filters.

Delete the endpoint group.

Save as new—Duplicate the endpoint group and save it as a new group.

Export group—Export the list of endpoints that match the endpoint group criteria to a tab separated values (TSV) file.

View endpoints—Pivot from an endpoint group to a filtered list of endpoints on the Endpoint Administration page where you can quickly view and
initiate actions on the endpoints within the group.

3.5 | About Content Updates

Abstract

To increase security coverage and quickly resolve any issues in policy, Palo Alto Networks can seamlessly deliver software packages called content updates.

To increase security coverage and quickly resolve any issues in policy, Palo Alto Networks can seamlessly deliver software packages for Cortex XSIAM called
content updates. Content updates can contain changes or updates to any of the following:

NOTE:

Starting with the Cortex XDR 7.1 agent release, Cortex XSIAM delivers the content update to the agent in parts and not as a single file, allowing the agent to
retrieve only the updates and additions it needs.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 107/1003
5/8/24, 9:18 AM PDF Export

Default security policy including exploit, malware, restriction, and agent settings profiles

Default compatibility rules per module

Protected processes

Local analysis logic

Trusted signers

Processes included in your block list by signers

Behavioral threat protection rules

Ransomware module logic including Windows network folders susceptible to ransomware attacks

Event Log for Windows event logs and Linux system authentication logs

Python scripts provided by Palo Alto Networks

Python modules supported in script execution

Maximum file size for hash calculations in File search and destroy

List of common file types included in File search and destroy

Network Packet Inspection Engine rules

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

The Cortex XSIAM research team releases more frequent content updates in-between major content versions to ensure your network is constantly protected
against the latest and newest threats in the wild. When you enable minor content updates, the Cortex XSIAM agent receives minor content updates, starting with
the next content releases. Otherwise, if you do not wish to deploy minor content updates, your Cortex XDR agents will keep receiving content updates for major
releases which usually occur on a weekly basis. The content version numbering format remains XXX-YYYY, where XXX indicates the version and YYYY indicates
the build number. To distinguish between major and minor releases, XXX is rounded up to the nearest ten for every major release, and incremented by one for a
minor release. For example, 180-<build_num> and 190-<build_num> are major releases, and 181-<build_num>, 182-<build_num>, and 191-<build_num>
are minor releases.

To adjust content update distribution for your environment, you can configure the following optional settings:

Content management settings as part of the Cortex XSIAM global agent configurations.

Content download source, as part of the Cortex XSIAM agent setting profile.

Otherwise, if you want the Cortex XDR agent to retrieve the latest content from the server immediately, you can force the Cortex XDR agent to connect to the
server using one of the following methods.

(Windows and Mac only) Perform manual check-in from the Cortex XDR agent console.

Initiate a check-in using the Cytool checkin command.

3.6 | Endpoint Security Profiles

Abstract

Rather than defining a new security profile for each of your endpoints, you can apply the pre-configured Cortex XDR security profiles instead.

Cortex XSIAM provides default security profiles that you can use out of the box to immediately begin protecting your endpoints from threats.

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

From Endpoints → Policy Management → Prevention → Profiles, you can create the following profiles. The Prevention Profiles table lists all the profiles per
operating system. Profiles associated with one or more targets that are beyond your defined user scope are locked and cannot be edited.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 108/1003
5/8/24, 9:18 AM PDF Export

Profile Name Description

Exploit Profiles Exploit profiles block attempts to exploit system flaws in browsers, and in
the operating system. For example, Exploit profiles help protect against
exploit kits, illegal code execution, and other attempts to exploit process and
system vulnerabilities. Exploit profiles are supported for Windows, Mac, and
Linux platforms.

Add a New Exploit Security Profile.

Malware Profiles Malware profiles protect against the execution of malware including trojans,
viruses, worms, and grayware. Malware profiles serve two main purposes:
to define how to treat behavior common with malware, such as ransomware
or script-based attacks, and to define how to treat known malware and
unknown files. Malware profiles are supported for all platforms.

Add a New Malware Security Profile.

Restrictions Profiles Restrictions profiles limit where executables can run on an endpoint. For
example, you can restrict files from running from specific local folders or
from removable media. Restrictions profiles are supported only for Windows
platforms.

Add a New Restrictions Security Profile.

Agent Settings Profiles Agent Settings profiles enable you to customize settings that apply to the
Cortex XDR agent (such as the disk space quota for log retention). For Mac
and Windows platforms, you can also customize user interface options for
the Cortex XSIAM console, such as accessibility and notifications.

Add a New Agent Settings Profile.

Exceptions Profiles Exceptions Security Profiles override the security policy to allow a process
or file to run on an endpoint, to disable a specific BTP rule, to allow a known
digital signer, and to import exceptions from the Cortex XSIAM support
team. Exceptions profiles are supported for Windows, Mac, and Linux
platforms.

Add a New Exceptions Security Profile.

After you add the new security profile, you can Manage Endpoint Security Profiles.

3.6.1 | Add a New Exploit Security Profile

Abstract

From the Cortex XDR management console, you can customize exploit protection capabilities in each Exploit security profile.

Exploit security profiles allow you to configure the action the Cortex XDR agent takes when attempts to exploit software vulnerabilities or flaws occur. To protect
against specific exploit techniques, you can customize exploit protection capabilities in each Exploit security profile.

By default, the Cortex XDR agent will receive the default profile that contains a pre-defined configuration for each exploit capability supported by the platform. To
fine-tune your Exploit security policy, you can override the configuration of each capability to block the exploit behavior, allow the behavior but report it, or
disable the module.

To define an Exploit security profile:

1. Add a new profile.

a. From Cortex XSIAM , select Endpoints → Policy Management → Prevention → Profiles → + Add Profile and select whether to Create New or
Import from File a new profile.

NOTE:

New imported profiles are added and not replaced.

b. Select the platform to which the profile applies and Exploit as the profile type.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 109/1003
5/8/24, 9:18 AM PDF Export

c. Click Next.

2. Define the General Information.

a. Enter a unique Profile Name to identify the profile. The name can contain only letters, numbers, or spaces, and must be no more than 30
characters. The name you choose will be visible from the list of profiles when you configure a policy rule.

b. To provide additional context for the purpose or business reason that explains why you are creating the profile, enter a profile Description. For
example, you might include an incident identification number or a link to a help desk ticket.

3. Configure the action to take when the Cortex XDR agent detects an attempt to exploit each type of software flaw.

For details on the different exploit protection capabilities, see Endpoint Protection Capabilities.

Block—Block the exploit attack.

Report—Allow the exploit activity but report it to Cortex XSIAM.

Disabled—Disable the module and do not analyze or report exploit attempts.

Default—Use the default configuration to determine the action to take. Cortex XSIAM displays the current default configuration for each capability in
parenthesis. For example, Default (Block).

To view which processes are protected by each capability, see Processes Protected by Exploit Security Policy.

For Known Vulnerable Process Protection, enable to automatically protect endpoints from attacks that try to leverage common operating system
mechanisms for malicious purposes. Select either to Block (default) or Report. When enabled, select Java Deserialization Protection Enabled
(Default)/Disabled. If enabled, the same action mode defined for the Known Vulnerable Process Protection is inherited.

Attackers can use existing mechanisms in the operating system to execute malicious code. By enabling this capability, Cortex XDR agent adds the
following section in Windows Exploit Profile Known Vulnerable Processes Protection Action Mode - Block (default) / Report / Disabled Inheriting from
action mode - Java Deserialization Protection - Enabled / Disabled (default) When the Action mode of Known Vulnerable Processes Protection is set to
disabled the Java protection becomes greyed out and is disabled as well regardless of its value. If enabled, the action mode - report or block is inherited
from the main setting.

For Logical Exploits Protection, you can also configure a block list for the DLL Hijacking module. The block list enables you to block specific DLLs when
run by a protected process. The DLL folder or file must include the complete path. To complete the path, you can use environment variables or the asterisk
(*) as a wildcard to match any string of characters (for example, */windows32/).

For Exploit Protection for Additional Processes, you also add one or more additional processes.

NOTE:

In Exploit Security profiles, if you change the action mode for processes, you must restart the protected processes for the following security modules to
take effect on the process and its forked processes: Brute Force Protection, Java Deserialization, ROP, and SO Hijacking.

4. (Windows only) Configure how to address unpatched known vulnerabilities in your network.

TIP:

If you have Windows endpoints in your network that are unpatched and exposed to a known vulnerability, Palo Alto Networks strongly recommends that
you upgrade to the latest Windows Update that has a fix for that vulnerability.

If you choose not to patch the endpoint, the Unpatched Vulnerabilities Protection capability allows the Cortex XDR agent to apply a workaround to protect
the endpoints from the known vulnerability. It takes the Cortex XDR agent up to 6 hours to enforce your configured policy on the endpoints.

To address known vulnerabilities CVE-2021-24074, CVE-2021-24086, and CVE-2021-24094, you can Modify IPv4 and IPv6 settings as follows:

Do not modify system settings (default)—Do not modify the IPv4 and IPv6 settings currently set on the endpoint, whether the current values are
your original values or values that were modified as part of this workaround.

Modify system settings until the endpoint is patched—If the endpoint is already patched, this option does not modify any system settings. For
unpatched endpoints, the Cortex XDR agent runs the following commands to temporarily modify the IPv4 and IPv6 settings until the endpoint is
patched. After the endpoint is patched for CVE-2021-24074, CVE-2021-24086, and CVE-2021-24094, all modified Windows system settings as part
of this workaround are automatically reverted to their values before modification. Palo Alto Networks strongly recommends that you review these
commands before applying this workaround in your network to ensure your critical business components are not affected or harmed:

netsh int ipv6 set global reassemblylimit=0, this command disables IPv6 fragmentation on the endpoint.

netsh int ipv4 set global sourceroutingbehavior=drop, this command disables LSR / loose source routing for IPv4.

Revert system settings to your previous settings—Revert all Windows system settings to their values before modification as part of this workaround,
regardless of whether the endpoint was patched or not.

WARNING:

This workaround applies only to the specific Windows versions listed as exposed to these CVEs, and requires a Cortex XDR agent 7.1 or later and
content 167-51646 or later. This workaround is not recommended for non-persistent, stateless, or linked-clone environments. In some cases, enabling
this workaround can affect the network functionality on the endpoint.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 110/1003
5/8/24, 9:18 AM PDF Export

5. Save the changes to your profile.

6. Apply Security Profiles to Endpoints.

You can do this in two ways: You can Create a new policy rule using this profile from the right-click menu or you can launch the new policy wizard from
Policy Rules.

3.6.1.1 | Processes Protected by Exploit Security Policy

Abstract

Application processes that run on your endpoint are protected by the exploit security policy.

By default, your exploit security profile protects endpoints from attack techniques that target specific processes. Each exploit protection capability protects a
different set of processes that Palo Alto Networks researchers determine are susceptible to attack. The following tables display the processes that are protected
by each exploit protection capability for each operating system.

Windows Processes Protected By Exploit Security Policy

Browser Exploits Protection

[updated version of Adobe Flash Player for flashutil_activex.exe opera.exe

Firefox installed on endpoint]
iexplore.exe plugin-container.exe
browser_broker.exe
microsoftedge.exe safari.exe
chrome.exe
microsoftedgecp.exe webkit2webprocess.exe
firefox.exe
opera_plugin_wrapper.exe

Logical Exploits Protection

cliconfg.exe excel.exe powerpnt.exe

dism.exe migwiz.exe sysprep.exe

dllhost.exe mmc.exe winword.exe

Known Vulnerable Processes Protection

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 111/1003
5/8/24, 9:18 AM PDF Export

Windows Processes Protected By Exploit Security Policy

7z.exe ipodservice.exe SLMail.exe

7zfm.exe itunes.exe soffice.exe

7zg.exe ituneshelper.exe telnet.exe

acrobat.exe journal.exe unrar.exe

acrord32.exe jqs.exe vboxservice.exe

acrord32info.exe microsoft.photos.exe vboxsvc.exe

allplayer.exe msaccess.exe vboxtray.exe

applemobiledeviceservice.exe mspub.exe video.ui.exe

apwebgrb.exe mstsc.exe visio.exe

armsvc.exe nginx.exe vlc.exe

blazehdtv.exe notepad++.exe vmware-authd.exe

bsplayer.exe nslookup.exe vmware-hostd.exe

cmd.exe outlook.exe vmware-vmx.exe

eqnedt32.exe powerpnt.exe vpreview.exe

excel.exe pptview.exe vprintproxy.exe

flashfxp.exe qttask.exe wab.exe

fltldr.exe quicktimeplayer.exe w3wp.exe

fontdrvhost.exe rar.exe winrar.exe

foxit reader.exe reader_sl.exe winword.exe

foxitreader.exe realconverter.exe wireshark.exe

groovemonitor.exe realplay.exe wmplayer.exe

hxmail.exe realsched.exe wmpnetwk.exe

i_view32.exe skype.exe xpsrchvw.exe

infopath.exe skypeapp.exe

skypehost.exe

Operating System Exploit Protection

ctfmon.exe runtimebroker.exe taskhost.exe

dllhost.exe spoolsv.exe wmiprvse.exe

dns.exe svchost.exe wmiprvse.exe

lsass.exe taskeng.exe wwahost.exe

msmpeng.exe

Mac Processes Protected By Exploit Security Policy

Browser Exploits Protection

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 112/1003
5/8/24, 9:18 AM PDF Export

Mac Processes Protected By Exploit Security Policy

com.apple.safariservices firefox plugin-container

com.apple.webkit.plugin firefox-bin safari

com.apple.webkit.plugin.64 google chrome helper seamonkey

com.apple.webkit.webcontent google chrome

Logical Exploits Protection

adobereader firefox pdf reader x

app drive for google drive firefox-bin plugin-container

app drop for dropbox google chrome helper quicktime player

app for dropbox google chrome safari

app for facebook itunes helper seamonkey

app for google drive itunes slack

app for googledocs mail+ for yahoo sonicwall mobile connect

app for instagram microsoft excel textwrangler

app for linkedin microsoft outlook vlc

app for youtube microsoft powerpoint vmware fusion services

com.apple.safariservices microsoft remote desktop vmware fusion

com.apple.webkit.plugin microsoft word vpn shield

com.apple.webkit.plugin.64 miniwriterfree winmail.dat file viewer

com.apple.webkit.webcontent parallels client

document writer pdf reader pro free

Known Vulnerable Processes Protection

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 113/1003
5/8/24, 9:18 AM PDF Export

Mac Processes Protected By Exploit Security Policy

adobereader document writer photos

airmail itunes helper photoshop

app drive for google drive itunes quickbooks

app drop for dropbox jump desktop quicktime player

app for dropbox mail signal

app for facebook mail+ for yahoo slack

app for google drive messages sonicwall mobile connect

app for googledocs microsoft excel telegram

app for instagram microsoft outlook textmate

app for linkedin microsoft powerpoint textwrangler

app for youtube microsoft remote desktop thunderbird

bbedit microsoft word vlc

c-lion miniwriterfree vmware fusion services

cisco anyconnect secure mobility client parallels client vmware fusion

com.apple.cloudphotosconfiguration pdf reader pro free vpn shield

pdf reader x winmail.dat file viewer

Linux Processes Protected By Exploit Security Policy

Known Vulnerable Processes Protection

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 114/1003
5/8/24, 9:18 AM PDF Export

Linux Processes Protected By Exploit Security Policy

anacron mailman samba

apache2 master saned

authproxy mongod sendmail

bluetoothd mysqld sendmail.sendmail

charon mysqld_safe smartd

chronyd named smbd

couriertcpd ndsd snmpd

cron nginx squid

crond nmbd squid3

cupsd node starter

cyrus_pop3d nscd syslog-ng

danted php tinyproxy

dhcpd php5-fpm vsftpd

dovecot pmmasterd wickedd-dhcp4

exim pop2d wickedd-dhcp6

ftpd pop3d winbindd

httpd postgres xinetd

ibserver proftpd

identd qmgr

lighttpd rpcbind

java rsync

kamailio

3.6.2 | Add a New Malware Security Profile

Abstract

From the management console, you can configure what action Cortex XDR agents take when known malware and unknown files try to run.

Malware security profiles allow you to configure the action Cortex XDR agents take when known malware and unknown files try to run on Windows, macOS,
Linux, and Android endpoints.

By default, the Cortex XDR agent will receive the default profile that contains a pre-defined configuration for each malware protection capability supported by the
platform. To fine-tune your Malware security policy, you can override the configuration of each capability to block the malicious behavior or file, allow but report it,
or disable the module. For each setting, you override, clear the option to Use Default.

To configure a Malware security profile:

1. Add a new profile.

a. From Cortex XSIAM, select Endpoints → Policy Management → Prevention → Profiles → + Add Profile and select whether to Create New or
Import from File a new profile.

NOTE:

New imported profiles are added and not replaced.

b. Select the platform to which the profile applies and Malware as the profile type.

2. Identify the profile.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 115/1003
5/8/24, 9:18 AM PDF Export

a. Select a unique Profile Name to identify the profile. The name can contain only letters, numbers, or spaces, and must be no more than 30
characters. The name will be visible from the list of profiles when you configure a policy rule.

b. To provide additional context for the purpose or business reason for creating the profile, specify a profile Description. For example, you might
include an incident identification number or a link to a help desk ticket.

3. Configure the Cortex XDR agent to examine executable files, macros, or DLL files on Windows endpoints, Mach-O files or DMG files on macOS-based
endpoints, ELF files on Linux endpoints, or APK files on Android endpoints.

a. Configure the Action Mode—the behavior of the Cortex XDR agent—when malware is detected:

Block—Block attempts to run malware.

Report—Report but do not block malware that attempts to run.

Disabled—Disable the module and do not examine files for malware.

b. Configure additional actions to examine files for malware.

By default, Cortex XSIAM uses the settings specified in the default malware security profile and displays the default configuration in parenthesis.
When you select a setting other than the default, you override the default configuration for the profile.

(Windows, macOS starting with Cortex XDR agent 7.4, Linux starting with Cortex XDR agent 7.5) Quarantine Malicious Executables / Mach-O
/ ELF files / DMG files—By default, the Cortex XDR agent blocks malware from running but does not quarantine the file. Enable this option to
quarantine files depending on the verdict issuer (local analysis, WildFire, or both local analysis and WildFire).

The quarantine feature is not available for malware identified in network drives.

Upload unknown files to WildFire—Enable the Cortex XDR agent to send unknown files to Cortex XSIAM, and for Cortex XSIAM to send the
files to WildFire for analysis. With macro analysis, the Cortex XDR agent sends the Microsoft Office file containing the macro. The file types
that the Cortex XDR agent analyzes depend on the platform type. WildFire accepts files up to 100MB in size.

Treat Grayware as Malware—Treat all grayware with the same Action Mode you configure for malware. Otherwise, if this option is disabled,
grayware is considered benign and is not blocked.

Action when file is Unknown to WildFire—Select the behavior of the Cortex XDR agent when an unknown file tries to run on the endpoint
(Allow, Run Local Analysis, or Block). With local analysis, the Cortex XDR agent uses embedded machine learning to determine the likelihood
that an unknown file is malware and issues a local verdict for the file. If you block unknown files but do not run local analysis, unknown files
remain blocked until the Cortex XDR agent receives an official WildFire verdict.

(Windows only)Action when file is benign with Low Confidence—Select the behavior of the Cortex XDR agent when a file with Benign Low
Confidence verdict from WildFire tries to run on the endpoint (Allow, Run Local Analysis, or Block). With local analysis, the Cortex XDR agent
uses embedded machine learning to determine the likelihood that an unknown file is malware and issues a local verdict for the file. If you
block this file but do not run a local analysis, it remains blocked until the Cortex XDR agent receives a high-confidence WildFire verdict. To
enable this capability, ensure that WildFire analysis scoring is enabled in your Global Agent Settings.

WARNING:

For optimal user experience, we recommend that you set the action mode to either Allow or Run Local Analysis.

Action on the Benign LC verdict is supported by agent version 7.5 and above. For agent version 7.4.X, the action on the Benign LC
verdict is the same as the action for files with Unknown verdict.

(Windows only) Examine Office Files From Network Drives—Enable the Cortex XDR agent to examine Microsoft Office files in network drives
when they contain a macro that attempts to run. If this option is disabled, the Cortex XDR agent will not examine macros in network drives.

NOTE:

(Windows only) As part of the anti-malware security flow, the Cortex XDR agent leverages the OS capability to identify revoked certificates for
executables and DLL files that attempt to run on the endpoint by accessing the Windows Certificate Revocation List (CRL). To allow the Cortex
XDR agent access the CRL, you must enable internet access over port 80 for Windows endpoints running Traps 6.0.3 and later releases, Traps
6.1.1 and later releases, or Cortex XDR 7.0 and later releases. If the endpoint is not connected to the internet, or you experience delays with
executables and DLLs running on the endpoint, please contact Customer Support.

IMPORTANT:

Starting with version 1.3, Cortex XSIAM enables you to manage the Malware Security exceptions from a central location and easily apply them
across multiple profiles in the Legacy Agent Exceptions management page.

To manage the prevention profile exceptions from Exception Configuration, you must first migrate your existing exceptions configured via the
Prevention profiles.

Your migrated rules are displayed on the Settings → Exception Configurations → Legacy Agent Exceptions page. For more information about the
migration, see Exception Configuration.

To create new Malware exceptions using the Legacy Agent Exceptions management page, see Add a Legacy Exception Rule.

If you don't migrate the legacy exceptions, you can continue to add exceptions as described below.

c. (Optional) Add files and folders to your allow list to exclude them from the examination.

1. +Add a file or folder.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 116/1003
5/8/24, 9:18 AM PDF Export

2. Specify the path and press Enter or click the check mark when done. You can also use a wildcard to match files and folders containing a
partial name. Use ? to match a single character or * to match any string of characters. To match a folder, you must terminate the path with * to
match all files in the folder (for example, c:\temp\*).

3. Repeat to add additional files or folders.

d. (Optional) Add signers to your allow list to exclude them from the examination.

When a file that is signed by a signer you included in your allow list attempts to run,

1. +Add a trusted signer.

2. Enter the name of the trusted signer (Windows) or the SHA1 hash of the certificate that signs the file (macOS) and press Enter or click the
check mark when done. You can also use a wildcard to match a partial name for the signer. Use ? to match any single character or * to match
any string of characters.

3. Repeat to add additional folders.

NOTE:

Cortex XDR agent evaluates the signer name using the CN (Common Name) value in the digital signature, while the Cortex XSIAMconsole can
display in the Alerts table both the O (Organization) value and the CN (Common Name).

4. (Windows) Configure the On-write File Protection.

Cortex XSIAM monitors and takes action on malicious files during the on-write process.

a. Define the Action Mode to take when Cortex XSIAM detects malicious files during the on-write process.

Enabled—Alerts and quarantines malicious files during the on-write process.

Disabled—Disable the protection module and do not alert and quarantine malicious files during the on-write process.

5. (Windows, macOS, and Linux) Configure the Global Behavioral Threat Protection Rules.

NOTE:

Behavioral threat protection requires Traps agent 6.0 or a later release for Windows endpoints and Traps 6.1 or later versions for macOS and Linux
endpoints.

With Behavioral threat protection, the agent continuously monitors endpoint activity to identify and analyze chains of events—known as causality chains.
This enables the agent to detect malicious activity in the chain that could otherwise appear legitimate if inspected individually. A causality chain can
include any sequence of network, process, file, and registry activities on the endpoint. Behavioral threat protection can also identify behavior related to
vulnerable drivers on Windows endpoints. For more information on data collection for Behavioral Threat Protection, see Endpoint Data Collection.

Palo Alto Networks researchers define the causality chains that are malicious and distribute those chains as behavioral threat rules. When the Cortex XDR
agent detects a match to a behavioral threat protection rule, the Cortex XDR agent carries out the configured action (default is Block). In addition, the
Cortex XDR agent reports the behavior of the entire event chain up to the process, known as the causality group owner (CGO), that the Cortex XDR agent
identified as triggering the event sequence.

To configure the Global Behavioral Threat Protection Rules:

a. Define the Action mode to take when the Cortex XDR agent detects malicious causality chains:

Block (default)—Block all processes and threads in the event chain up to the CGO.

Report—Allow the activity but report it to Cortex XSIAM.

Disabled—Disable the module and do not analyze or report the activity.

b. Define whether to quarantine the CGO when the Cortex XDR agent detects a malicious event chain.

Enabled—Quarantine the processes and the artifacts, such as files, related to the CGO.

Disabled (default)—Do not quarantine the CGO of an event chain nor any scripts or files called by the CGO.

c. (Windows only, requires a Cortex XDR agent 7.2 or later) Define the Action Mode for Vulnerable Drivers Protection.

Behavioral threat protection rules can also detect attempts to load vulnerable drivers. As with other rules, Palo Alto Networks threat researchers can
deliver changes to vulnerable driver rules with content updates.

Block (default)—Block all attempts to run vulnerable drivers.

Report—Allow vulnerable drivers to run but report the activity.

Disabled—Disable the module and do not analyze or report the activity.

d. Define the Advanced API Monitoring .

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 117/1003
5/8/24, 9:18 AM PDF Export

Enabled—Adds additional hooks in user mode processes for increased coverage of anti-exploit and anti-malware modules.

Disabled (default)—Disables the capability of Advanced API Monitoring.

e. (Optional) Add to your allow list the files that you do not want the Cortex XDR agent to terminate when a malicious causality chain is detected. The
allow list does not apply to vulnerable drivers.

IMPORTANT:

Starting with version 1.3, Cortex XSIAM enables you to manage the Malware Security exceptions from a central location and easily apply them
across multiple profiles in the Legacy Agent Exceptions management page.

To manage the prevention profile exceptions from Exception Configuration, you must first migrate your existing exceptions configured via the
Prevention profiles.

Your migrated rules are displayed on the Settings → Exception Configurations → Legacy Agent Exceptions page. For more information about the
migration, see Exception Configuration.

To create new Malware exceptions using the Legacy Agent Exceptions management page, see Add a Legacy Exception Rule.

If you don't migrate the legacy exceptions, you can continue to add exceptions as described below.

1. +Add a file path.

2. Enter the file path you want to exclude from the evaluation. Use ? to match a single character or * to match any string of characters. Adding a
process to the allow list doesn’t prevent the generation of a security event.

3. Click the checkmark to confirm the file path.

4. Repeat the process to add any additional file paths to your allow list.

6. (Windows, macOS, and Linux) Configure Credential Gathering Protection.

In a causality chain, when the Cortex XDR agent detects a process that attempts to access or steal passwords and other sensitive credentials, the Cortex
XDR agent carries out the configured action (default is Block).

To configure Credential Gathering Protection:

a. Define the Action mode to take when the Cortex XDR agent detects a credential gathering process:

Block (default)—Block all processes and threads in the event chain up to the credential gathering process or file.

Report—Allow the activity but report it to Cortex XSIAM.

Disabled—Disable the module and do not analyze or report the activity.

b. (Windows only) Define whether to quarantine the process or file when the Cortex XDR agent detects a credential gathering attempt.

Enabled—Quarantine the process or file related to the credential gathering event chain.

Disabled (default)—Do not quarantine the process or file of an event chain nor any scripts or files called by the process or file.

c. (Optional) Add files to your allow list that you do not want the Cortex XDR agent to terminate.

IMPORTANT:

Starting with version 1.3, Cortex XSIAM enables you to manage the Malware Security exceptions from a central location and easily apply them
across multiple profiles in the Legacy Agent Exceptions management page.

To manage the prevention profile exceptions from Exception Configuration, you must first migrate your existing exceptions configured via the
Prevention profiles.

Your migrated rules are displayed on the Settings → Exception Configurations → Legacy Agent Exceptions page. For more information about the
migration, see Exception Configuration.

To create new Malware exceptions using the Legacy Agent Exceptions management page, see Add a Legacy Exception Rule.

If you don't migrate the legacy exceptions, you can continue to add exceptions as described below.

+Add the file or folder paths to exclude from evaluation. Use ? to match a single character or * to match any string of characters. Adding a process
to the allow list doesn’t prevent the generation of a security event.

7. (Windows, macOS, and Linux) Configure Anti Webshell Protection.

In a causality chain, when the Cortex XDR agent detects a process that attempts to drop malicious web shells, the Cortex XDR agent carries out the
configured action (default is Block).

To configure Anti Webshell Protection:

a. Define the Action mode to take when the Cortex XDR agent detects a process attempting to drop a web shell:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 118/1003
5/8/24, 9:18 AM PDF Export

Block (default)—Block all processes and threads in the event chain up to the web shell dropping process or file.

Report—Allow the activity but report it to Cortex XSIAM.

Disabled—Disable the module and do not analyze or report the activity.

b. (Windows only) For a Block or Report action, define whether to quarantine the process or file when the Cortex XDR agent detects a web shell
dropping process.

Enabled—Quarantine the dropped or executed web shell.

Disabled (default)—Do not quarantine the processes or files that are related to the web shell drop event chain or any scripts or files called by
the web shell dropping process.

c. (Optional) Add files that you do not want the Cortex XDR agent to terminate to your allow list.

IMPORTANT:

Starting with version 1.3, Cortex XSIAM enables you to manage the Malware Security exceptions from a central location and easily apply them
across multiple profiles in the Legacy Agent Exceptions management page.

To manage the prevention profile exceptions from Exception Configuration, you must first migrate your existing exceptions configured via the
Prevention profiles.

Your migrated rules are displayed on the Settings → Exception Configurations → Legacy Agent Exceptions page. For more information about the
migration, see Exception Configuration.

To create new Malware exceptions using the Legacy Agent Exceptions management page, see Add a Legacy Exception Rule.

If you don't migrate the legacy exceptions, you can continue to add exceptions as described below.

Add+Add the file or folder paths to exclude from evaluation. Use ? to match a single character or * to match any string of characters. Adding a
process to the allow list doesn’t prevent the generation of a security event.

8. (Windows, macOS, and Linux) Configure Financial Malware Threat Protection.

In a causality chain, when the Cortex XDR agent detects a process that attempts to access or steal financial or banking information, the Cortex XDR agent
carries out the configured action (default is Block).

To configure Financial Malware Threat Protection:

a. Define the Action mode to take when the Cortex XDR agent detects a financial information gathering process.

Block (default)—Block all processes and threads in the event chain up to the credential gathering process or file.

Report—Allow the activity but report it to Cortex XSIAM.

Disabled—Disable the module and do not analyze or report the activity.

b. (Windows, macOS, and Linux) Define whether to quarantine the process or file when the Cortex XDR agent detects a financial information
gathering attempt.

Enabled—Quarantine the processes or files related to the financial information gathering event chain.

Disabled (default)—Do not quarantine the processes or files that are related to the financial information gathering event chain or any scripts or
files called by the financial information gathering process.

c. (Optional) Add files that you do not want the Cortex XDR agent to terminate to your allow list.

IMPORTANT:

Starting with version 1.3, Cortex XSIAM enables you to manage the Malware Security exceptions from a central location and easily apply them
across multiple profiles in the Legacy Agent Exceptions management page.

To manage the prevention profile exceptions from Exception Configuration, you must first migrate your existing exceptions configured via the
Prevention profiles.

Your migrated rules are displayed on the Settings → Exception Configurations → Legacy Agent Exceptions page. For more information about the
migration, see Exception Configuration.

To create new Malware exceptions using the Legacy Agent Exceptions management page, see Add a Legacy Exception Rule.

If you don't migrate the legacy exceptions, you can continue to add exceptions as described below.

+Add the file or folder paths to exclude from evaluation. Use ? to match a single character or * to match any string of characters. Adding a process
to the allow list doesn’t prevent the generation of a security event.

9. (Windows, macOS, and Linux) Configure Cryptominers Protection

In a causality chain, when the Cortex XDR agent detects a process that attempts to locate or steal cryptocurrencies, the Cortex XDR agent carries out the
configured action (default is Block).

To configure Cryptominers Protection:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 119/1003
5/8/24, 9:18 AM PDF Export

a. Define the Action mode to take when the Cortex XDR agent detects a cryptomining threat.

Block(default)—Block all processes and threads in the event chain up to the cryptomining process or file.

Report—Allow the activity but report it to Cortex XSIAM.

Disabled—Disable the module and do not analyze or report the activity.

b. (Windows, macOS, and Linux) Define whether to quarantine the process or file when the Cortex XDR agent detects a cryptocurrency gathering
attempt.

Enabled—Quarantine the processes or files related to the cryptomining event chain.

Disabled (default)—Do not quarantine the processes or files that are related to the cryptomining event chain or any scripts or files called by
the cryptomining process.

c. (Optional) Add files that you do not want the Cortex XDR agent to terminate to your allow list.

IMPORTANT:

Starting with version 1.3, Cortex XSIAM enables you to manage the Malware Security exceptions from a central location and easily apply them
across multiple profiles in the Legacy Agent Exceptions management page.

To manage the prevention profile exceptions from Exception Configuration, you must first migrate your existing exceptions configured via the
Prevention profiles.

Your migrated rules are displayed on the Settings → Exception Configurations → Legacy Agent Exceptions page. For more information about the
migration, see Exception Configuration.

To create new Malware exceptions using the Legacy Agent Exceptions management page, see Add a Legacy Exception Rule.

If you don't migrate the legacy exceptions, you can continue to add exceptions as described below.

+Add the file or folder paths to exclude from evaluation. Use ? to match a single character or * to match any string of characters. Adding a process
to the allow list doesn’t prevent the generation of a security event.

10. (Linux only) Configure Container Escaping Protection to protect against container-escaping attempts.

a. Define the Action Mode to take when the Cortex XDR agent detects container-escaping attempts.

Block (default)—Block the activity.

Report—Allow the activity but report it to Cortex XSIAM.

Disabled—Disable the module and do not analyze or report the activity.

b. Choose whether you want the Cortex XDR agent to Quarantine Malicious Files or not, when container-escaping attempts are detected.

11. (Windows) Configure In-process Shellcode Protection.

In a causality chain, when the Cortex XDR agent detects a process that attempts to run in-process shellcodes to load malicious code, the Cortex XDR
agent carries out the configured action (default is Block).

To configure In-process Shellcode Protection:

a. Define the Action mode to take when the Cortex XDR agent detects an in-process shellcode attack threat.

Block (default)—Block all processes and threads in the event chain up to the in-process shellcode process or file.

Report—Allow the activity but report it to Cortex XSIAM.

Disabled—Disable the module and do not analyze or report the activity.

b. (Windows) Define whether to quarantine the process or file when the Cortex XDR agent detects an in-process shellcode.

Enabled—Quarantine the in-process shellcode processes or files related to the chain.

Disabled (default)—Do not quarantine the processes or files that are related to the event chain or any scripts or files called by the in-process
shellcode.

c. Define whether to quarantine the 32 bit in-process shellcode processes detected by the Cortex XDR agent.

Enabled—Quarantine the 32 bit in-process shellcode processes or files related to the chain.

Disabled (default)—Do not quarantine the 32 bit processes that are related to the event chain or any scripts or files called by the in-process
shellcode.

d. (Optional) Add files that you do not want the Cortex XDR agent to terminate to your allow list.

IMPORTANT:

Starting with version 1.3, Cortex XSIAM enables you to manage the Malware Security exceptions from a central location and easily apply them
across multiple profiles in the Legacy Agent Exceptions management page.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 120/1003
5/8/24, 9:18 AM PDF Export

To manage the prevention profile exceptions from Exception Configuration, you must first migrate your existing exceptions configured via the
Prevention profiles.

Your migrated rules are displayed on the Settings → Exception Configurations → Legacy Agent Exceptions page. For more information about the
migration, see Exception Configuration.

To create new Malware exceptions using the Legacy Agent Exceptions management page, see Add a Legacy Exception Rule.

If you don't migrate the legacy exceptions, you can continue to add exceptions as described below.

+Add the file or folder paths to exclude from evaluation. Use ? to match a single character or * to match any string of characters. Adding a process
to the allow list doesn’t prevent the generation of a security event.

12. (Windows) Configure UAC Bypass Prevention.

When Cortex XSIAM detects a User Access Control (UAC) Bypass mechanism that's associated with privilege elevation attempts, the Cortex XDR agent
carries out the configured action (default is Block).

To configure UAC Bypass Prevention:

a. Define the Action mode to take when the Cortex XDR agent detects a UAC Bypass mechanism.

Block (default)—Block all processes and threads in the event chain up to the UAC Bypass mechanism.

Report—Allow the activity but report it to Cortex XSIAM.

Disabled—Disable the module and do not analyze or report the activity.

b. (Windows) Define whether to quarantine the process or file when the Cortex XDR agent detects a UAC Bypass mechanism.

Enabled—Quarantine the UAC bypass processes or files related to the chain.

Disabled (default)—Do not quarantine the processes or files that are related to event chain or any scripts or files called by the UAC bypass
mechanism.

c. (Windows) Configure Malicious Safe Mode Rebooting Protection—Define the action to take when Cortex XDR agent detects safe mode reboot
attempts made suspiciously by other apps. This feature is supported with Cortex XDR agent 8.1.0 and later.

Report (default)— Allow the activity but report it to Cortex XSIAM.

Block—Block all processes and threads in the event chain leading up to the safe mode reboot.

Disabled—Disable this feature and do not block or report the activity.

d. (Optional) Add files that you do not want the Cortex XDR agent to terminate to your allow list.

IMPORTANT:

Starting with version 1.3, Cortex XSIAM enables you to manage the Malware Security exceptions from a central location and easily apply them
across multiple profiles in the Legacy Agent Exceptions management page.

To manage the prevention profile exceptions from Exception Configuration, you must first migrate your existing exceptions configured via the
Prevention profiles.

Your migrated rules are displayed on the Settings → Exception Configurations → Legacy Agent Exceptions page. For more information about the
migration, see Exception Configuration.

To create new Malware exceptions using the Legacy Agent Exceptions management page, see Add a Legacy Exception Rule.

If you don't migrate the legacy exceptions, you can continue to add exceptions as described below.

+Add the file or folder paths to exclude from evaluation. Use ? to match a single character or * to match any string of characters. Adding a process
to the allow list doesn’t prevent the generation of a security event.

13. (Windows and macOS) Configure Anti Tampering Protection.

When Cortex XSIAM detects a tampering attempt, including modification or the termination of a Cortex XDR agent, the Cortex XDR agent carries out the
configured action (default is Block).

To configure Anti Tampering Protection:

a. Define the Action mode to take when the Cortex XDR agent detects an agent tampering attempt.

Block (default)—Block all processes and threads in the event chain up to the tampering process.

NOTE:

If you choose the Block option, you must also enable XDR Agent Tampering Protection in the Agent Settings profile, and ensure that both
profiles are assigned to the same endpoints.

Report—Allow the activity but report it to Cortex XSIAM.

Disabled—Disable the module and do not analyze or report the activity.

b. (Windows and macOS) Define whether to quarantine the process or file when the Cortex XDR agent detects a tampering attempt.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 121/1003
5/8/24, 9:18 AM PDF Export

Enabled—Quarantine the processes or files that are related to the tampering attempt.

Disabled (default)—Do not quarantine the processes or files that are related to the event chain or any scripts or files called by the tampering
process or file.

c. (Windows) Configure Malicious Safe Mode Rebooting Protection—Define the action to take when Cortex XDR agent detects safe mode reboot
attempts made suspiciously by other apps.

Report (default)— Allow the activity but report it to Cortex XSIAM.

Block—Block all processes and threads in the event chain leading up to the safe mode reboot.

Disabled—Disable this feature and do not block or report the activity.

d. (Optional) Add files that you do not want the Cortex XDR agent to terminate to your allow list.

IMPORTANT:

Starting with version 1.3, Cortex XSIAM enables you to manage the Malware Security exceptions from a central location and easily apply them
across multiple profiles in the Legacy Agent Exceptions management page.

To manage the prevention profile exceptions from Exception Configuration, you must first migrate your existing exceptions configured via the
Prevention profiles.

Your migrated rules are displayed on the Settings → Exception Configurations → Legacy Agent Exceptions page. For more information about the
migration, see Exception Configuration.

To create new Malware exceptions using the Legacy Agent Exceptions management page, see Add a Legacy Exception Rule.

If you don't migrate the legacy exceptions, you can continue to add exceptions as described below.

+Add the file or folder paths to exclude from evaluation. Use ? to match a single character or * to match any string of characters. Adding a process
to the allow list doesn’t prevent the generation of a security event.

14. (Windows) Configure IIS Protection.

When Cortex XSIAM detects a threat that targets the Internet Information Server (IIS), the Cortex XDR agent carries out the configured action (default is
Block).

To configure IIS Protection:

a. Define the Action mode to take when the Cortex XDR agent detects an IIS threat.

Block (default)—Block all processes and threads in the event chain up to the IIS threat.

Report—Allow the activity but report it to Cortex XSIAM.

Disabled—Disable the module and do not analyze or report the activity.

b. (Windows) Define whether to quarantine the process or file when the Cortex XDR agent detects an IIS attack.

Enabled—Quarantine the processes or files that are related to the IIS attack.

Disabled (default)—Do not quarantine the processes or files that are related to the event chain or any scripts or files called by the IIS threat
process or file.

15. (Windows) Configure UEFI Protection.

When Cortex XSIAM detects Unified Extensible Firmware Interface (UEFI) manipulation attempts, the Cortex XDR agent carries out the configured action
(default is Block).

a. Define the Action mode to take when the Cortex XDR agent detects a UEFI threat.

Block (default)—Block all processes and threads in the event chain up to the UEFI threat.

Report—Allow the activity but report it to Cortex XSIAM.

Disabled—Disable the module and do not analyze or report the activity.

b. (Windows) Define whether to quarantine the process or file when the Cortex XDR agent detects a UEFI manipulation attempt.

Enabled—Quarantine the processes or files that are related to the UEFI threat.

Disabled (default)—Do not quarantine the processes or files that are related to the event chain or any scripts or files called by the UEFI threat
process or file.

c. (Optional) Add files that you do not want the Cortex XDR agent to terminate to your allow list.

IMPORTANT:

Starting with version 1.3, Cortex XSIAM enables you to manage the Malware Security exceptions from a central location and easily apply them
across multiple profiles in the Legacy Agent Exceptions management page.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 122/1003
5/8/24, 9:18 AM PDF Export

To manage the prevention profile exceptions from Exception Configuration, you must first migrate your existing exceptions configured via the
Prevention profiles.

Your migrated rules are displayed on the Settings → Exception Configurations → Legacy Agent Exceptions page. For more information about the
migration, see Exception Configuration.

To create new Malware exceptions using the Legacy Agent Exceptions management page, see Add a Legacy Exception Rule.

If you don't migrate the legacy exceptions, you can continue to add exceptions as described below.

+Add the file or folder paths to exclude from evaluation. Use ? to match a single character or * to match any string of characters. Adding a process
to the allow list doesn’t prevent the generation of a security event.

16. (Windows) Respond to Malicious Causality Chains.

When the Cortex XDR agent identifies a remote network connection that attempts to perform malicious activity—such as encrypting endpoint files—the
agent can automatically block the IP address to close all existing communication and block new connections from this IP address to the endpoint.
When Cortex XSIAMblocks an IP address per endpoint, that address remains blocked throughout all agent profiles and policies, including any host-firewall
policy rules. You can view the list of all blocked IP addresses per endpoint from the Action Center, as well as unblock them to re-enable communication as
appropriate.

NOTE:

This module is supported with Cortex XDR agent 7.3.0 and later.

a. Select the Action Mode to take when the Cortex XDR agent detects remote malicious causality chains:

Enabled (default)—Terminate connection and block IP address of the remote connection.

Disabled—Do not block remote IP addresses.

b. To allow specific and known safe IP address or IP address ranges that you do not want Cortex XSIAMto block, add these IP addresses to your allow
list.

IMPORTANT:

Starting with version 1.3, Cortex XSIAM enables you to manage the Malware Security exceptions from a central location and easily apply them
across multiple profiles in the Legacy Agent Exceptions management page.

To manage the prevention profile exceptions from Exception Configuration, you must first migrate your existing exceptions configured via the
Prevention profiles.

Your migrated rules are displayed on the Settings → Exception Configurations → Legacy Agent Exceptions page. For more information about the
migration, see Exception Configuration.

To create new Malware exceptions using the Legacy Agent Exceptions management page, see Add a Legacy Exception Rule.

If you don't migrate the legacy exceptions, you can continue to add exceptions as described below.

+Add and then specify the IP address.

17. (Windows and macOS) Configure Ransomware Protection.

a. Define the Action mode to take when the Cortex XDR agent detects ransomware activity locally on the endpoint or in pre-defined network folders:

Block (default)—Block the activity.

Report—Allow the activity but report it to Cortex XSIAM.

Disabled—Disable the module and do not analyze or report the activity.

b. (macOS only) Choose whether you want the Cortex XDR agent to Quarantine Malicious Files or not, when ransomware is detected.

c. (Windows only) Choose whether you want the Cortex XDR agent to Quarantine Malicious Process when ransomware is detected.

The quarantine option is only available if the Action mode is Block.

d. (Windows only) Configure the ransomware module Protection mode.

By default, the protection mode is set to Normal where the decoy files on the endpoint are present, but do not interfere with benign applications and
end user activity on the endpoint. If you suspect your network has been infected with ransomware and need to provide better coverage, you can
apply the Aggressive protection mode. The aggressive mode exposes more applications in your environment to the Cortex XDR agent decoy files,
while also increasing the likelihood that benign software is exposed to decoy files, raising false ransomware alerts, and impairing user experience.

18. (Windows only) Configure the Cortex XDR agent to Prevent Malicious Child Process Execution.

a. Select the Action Mode to take when the Cortex XDR agent detects malicious child process execution:

Block—Block the activity.

Report—Allow the activity but report it to Cortex XSIAM.

b. To allow specific processes to launch child processes for legitimate purposes, add the child process to your allow list with optional execution criteria.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 123/1003
5/8/24, 9:18 AM PDF Export

IMPORTANT:

Starting with version 1.3, Cortex XSIAM enables you to manage the Malware Security exceptions from a central location and easily apply them
across multiple profiles in the Legacy Agent Exceptions management page.

To manage the prevention profile exceptions from Exception Configuration, you must first migrate your existing exceptions configured via the
Prevention profiles.

Your migrated rules are displayed on the Settings → Exception Configurations → Legacy Agent Exceptions page. For more information about the
migration, see Exception Configuration.

To create new Malware exceptions using the Legacy Agent Exceptions management page, see Add a Legacy Exception Rule.

If you don't migrate the legacy exceptions, you can continue to add exceptions as described below.

+Add and then specify the allow list criteria including the Parent Process Name, Child Process Name, and Command Line Params. Use ? to match
a single character or * to match any string of characters.

NOTE:

If you are adding child process evaluation criteria based on a specific security event, the event indicates both the source process and the
command line parameters in one line. Copy only the command line parameter for use in the profile.

19. Enable endpoint file scanning.

Periodic scanning enables you to scan endpoints on a reoccurring basis without waiting for malware to run on the endpoint. Periodic scanning is
persistent, and if the scan is scheduled to start while the endpoint is powered-off, then scan will be initiated when the endpoint is powered-on again. The
scheduling of future scans is not affected by this delay. To better understand how the agent scans the endpoint, refer to Scan an Endpoint for Malware.

NOTE:

When periodic scanning is enabled in your profile, the Cortex XDR agent initiates an initial scan when it is first installed on the endpoint, regardless of
the periodic scanning scheduling time.

NOTE:

We recommend that you disable scheduled scanning. VDI machine scans are based on the golden image and additional files will be examined upon
execution.

a. Configure the Action Mode for the Cortex XDR agent to periodically scan the endpoint for malware: Enabled to scan at the configured intervals,
Disabled (default) if you don’t want the Cortex XDR agent to scan the endpoint.

b. To configure the scan schedule, set the frequency (Run Weekly or Run Monthly) and day and time at which the scan will run on the endpoint.

Just as with an on-demand scan, a scheduled scan will resume after a reboot, process interruption, or operating system crash.

c. (Windows only) To include removable media drives in the scheduled scan, enable the Cortex XDR agent to Scan Removable Media Drives.

d. Add folders to your allow list to exclude them from examination.

IMPORTANT:

Starting with version 1.3, Cortex XSIAM enables you to manage the Malware Security exceptions from a central location and easily apply them
across multiple profiles in the Legacy Agent Exceptions management page.

To manage the prevention profile exceptions from Exception Configuration, you must first migrate your existing exceptions configured via the
Prevention profiles.

Your migrated rules are displayed on the Settings → Exception Configurations → Legacy Agent Exceptions page. For more information about the
migration, see Exception Configuration.

To create new Malware exceptions using the Legacy Agent Exceptions management page, see Add a Legacy Exception Rule.

If you don't migrate the legacy exceptions, you can continue to add exceptions as described below.

1. Add (+) a folder.

2. Enter the folder path. Use ? to match a single character or * to match any string of characters in the folder path (for example, C:\*\temp).

3. Press Enter or click the check mark when done.

4. Repeat to add additional folders.

20. (Windows Vista and later Windows releases) Enable Password Theft Protection.

Select Enabled to enable the Cortex XDR agent to prevent attacks that use the Mimikatz tool to extract passwords from memory. When set to Enabled,
the Cortex XDR agent silently prevents attempts to steal credentials (no notifications are provided when these events occur). The Cortex XDR agent
enables this protection module following the next endpoint reboot. If you don’t want to enable the module, select Disabled.

NOTE:

This module is supported with Traps agent 5.0.4 and later.

21. (Windows only) Configure the Network Packet Inspection Engine.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 124/1003
5/8/24, 9:18 AM PDF Export

By analyzing the network packet data, the Cortex XDR agent can detect malicious behavior already at the network level and provide protection to the
growing corporate network boundaries. The engine leverages both Palo Alto Networks NGFW content rules, and new Cortex XSIAMcontent rules created
by the Research Team which are updated through the security content.

NOTE:

This module is supported with Cortex XDR agent 7.5.0 and later.

a. Define the Action mode to take when the Cortex XDR agent detects malicious behavior:

Terminate Session (default)—Drop the malicious connections. In case of an outgoing connection, also terminate all associated processes.

Report—Allow the packets in your network but report it to Cortex XSIAM.

Disabled—Disable the module and do not analyze or report the activity.

22. (Linux and macOS) Enable Local File Threat Examination.

The Local Threat-Evaluation Engine (LTEE) enables the Cortex XDR agent to detect malicious files on the endpoint.

NOTE:

This module is supported with Cortex XDR agent 8.1.0 and later release.

a. Select the Action Mode to take when the Cortex XDR agent detects the malicious behavior.

Enable—Enable the Cortex XDR agent to analyze the endpoint for PHP files arriving from the web server and alert of any malicious PHP
scripts.

Disable—Disable the module and do not analyze or report the activity.

b. (macOS only) Terminate Malicious Processes.

When Enabled, the Cortex XDR agents terminate malicious PHP files on the endpoint.

c. Quarantine malicious files.

When Enabled, the Cortex XDR agents quarantine malicious files on the endpoint and does not quarantine updated files.

d. (Optional) Add files and folders to your allow list to exclude them from the examination.

IMPORTANT:

Starting with version 1.3, Cortex XSIAM enables you to manage the Malware Security exceptions from a central location and easily apply them
across multiple profiles in the Legacy Agent Exceptions management page.

To manage the prevention profile exceptions from Exception Configuration, you must first migrate your existing exceptions configured via the
Prevention profiles.

Your migrated rules are displayed on the Settings → Exception Configurations → Legacy Agent Exceptions page. For more information about the
migration, see Exception Configuration.

To create new Malware exceptions using the Legacy Agent Exceptions management page, see Add a Legacy Exception Rule.

If you don't migrate the legacy exceptions, you can continue to add exceptions as described below.

1. +Add a file or folder.

2. Enter the path and press Enter or click the check mark when done. You can also use * to match files and folders containing a partial name.
To match a folder, you must terminate the path with * to match all files in the folder (for example, /usr/bin/*).

3. Repeat to add additional files or folders.

23. (Linux only) Configure Reverse Shell Protection.

The Reverse Shell Protection module enables the Cortex XDR agent to detect and optionally block attempts to redirect standard input and output streams
to network sockets.

a. Define the Action Mode to take when the Cortex XDR agent detects the malicious behavior.

Block—Block the activity.

Report—Allow the activity but report it to Cortex XSIAM.

Disabled—Disable the module and do not analyze or report the activity.

b. (Optional) Add processes to your allow list that must redirect streams to network sockets.

IMPORTANT:

Starting with version 1.3, Cortex XSIAM enables you to manage the Malware Security exceptions from a central location and easily apply them
across multiple profiles in the Legacy Agent Exceptions management page.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 125/1003
5/8/24, 9:18 AM PDF Export

To manage the prevention profile exceptions from Exception Configuration, you must first migrate your existing exceptions configured via the
Prevention profiles.

Your migrated rules are displayed on the Settings → Exception Configurations → Legacy Agent Exceptions page. For more information about the
migration, see Exception Configuration.

To create new Malware exceptions using the Legacy Agent Exceptions management page, see Add a Legacy Exception Rule.

If you don't migrate the legacy exceptions, you can continue to add exceptions as described below.

1. +Add a connection.

2. Enter the path of the process, and the local and remote IP address and ports.

Use a wildcard to match a partial path name. Use a * to match any string of characters (for example, */bash). You can also use a * to match
any IP address or any port.

3. Press Enter or click the check mark when done.

4. Repeat to add additional folders.

24. (iOS only) Configure malware protection for iOS-based devices:

a. Configure URL filtering to analyze and block or report malicious URLs, and to block or allow custom URLs.

b. Configure Spam Reports to report calls and messages as spam to Cortex XSIAM analysts.

c. Configure Call and Messages Blocking from known spam numbers. You can add allowed numbers to the Allow List, and known spam numbers to
the Block List.

NOTE:

Ensure that the same numbers are not added multiple times with different leading zeros.

d. Configure Safari Browser Security Module. This security module can provide proactive gating of suspicious sites accessed using Safari, and
provides informative site analysis to the device user. This option is recommended for iOS devices that do not belong to your organization and are
not "supervised devices".

NOTE:

To fully enable the security module on the device side, each iOS device user must enable the Safari Safeguard module on the device, and grant it
permission to work on all websites. If the iOS device user does not do this, Cortex XSIAM shows the endpoint's operation status as Partially
Protected.

The Safari browser security module will only function when the URL filtering module (see earlier in this procedure) is set to Block.

Item Options More Details

Enforce use of Safari Enabled When set to Enabled, the Safari Safeguard security module displays
Security Module "Required" on the Modules screen of the app. Full protection for Safari
Disabled will only be active after the iOS device user has also activated it on
the device.

Safari malicious JS Enabled When set to Enabled, the Cortex XDR agent blocks the entire page in
blocking Safari where malicious JS files are detected.
Disabled

e. Configure Network and EDR Security Module. This module lets you configure granular control and monitoring of network traffic on iOS-based
supervised devices. The devices' profiles must be also configured on the MDM side as explained in the Cortex XDR Agent iOS Guide.

NOTE:

Cortex XDR agent version 8.4 or higher are required for this feature.

Item Options More Details

Auto detected malicious Enabled When set to Enabled, the Cortex XDR agent automatically filters
URL filtering known malicious URLs.
Disabled

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 126/1003
5/8/24, 9:18 AM PDF Export

Item Options More Details

URL filtering Enabled When set to Enabled, the Cortex XDR agent filters URLs according to
the lists of allowed and blocked URLs configured in the URL Filtering
Disabled
section above.

Predefined Blocked Apps List of apps A list of commonly known apps that your organization may be
interested in blocking on supervised devices is provided here. The
Cortex XDR agent will block use of the selected apps. You can select
one or more apps.

Blocked Bundle IDs A Bundle ID is an app's unique identifier, in string format, that is used
to identify the app in an app store. Communication will be blocked for
any process with exactly the Bundle ID defined here, or for a Bundle
ID that has the defined string as a suffix.

For example, the Calculator app's Bundle ID is: com.apple.calculator.

When you add com.apple.calculator to the list, the Cortex XDR agent
app will block all of these Bundle IDs:

com.apple.calculator

H3DT34.com.apple.calculator

widget.com.apple.calculator

To block apps according to Bundle ID, enter a Bundle ID and press

Enter. To add another Bundle ID to the list, click +Add and repeat this
process.

Block List of Remote The Cortex XDR agent will block the IP addresses that you add to this
IPV4/IPV6 IP Address field. Both IPV4 and IPv6 addresses are supported.

To block apps according to IP address, enter an IP address with a

subnet mask, a range, or an individual IP address, and press Enter.
To add another IP address to the list, click +Add and repeat this
process.

Digest alerts Enabled Digest alerts are alerts that contain a summary of blocked network
activity over a prolonged time period.
Disabled
When set to Enabled, the Cortex XDR agent sends digest alerts to
Cortex XSIAM.

Digest alerts max 1 to 7 days When Digest alerts is enabled, you can limit the digest alert to no
frequency more than one per <selected number of days>.

Max alerts per app Hours Limit alert notifications by the Cortex XDR agent to one alert for each
app per <selected period of time>.
Minutes

Max user notifications Hours Limit alert notifications by the Cortex XDR agent app to one user
notification per <selected number of hours>.

25. Create or Save the changes to your profile.

26. Apply Security Profiles to Endpoints.

You can do this in two ways: You can Create a new policy rule using this profile from the right-click menu or you can launch the new policy wizard from
Policy Rules.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 127/1003
5/8/24, 9:18 AM PDF Export

3.6.2.1 | WildFire Analysis Concepts

Abstract

Learn about the analysis concepts used by Wildfire.

File Forwarding

Cortex XSIAM sends unknown samples for in-depth analysis to WildFire. WildFire accepts up to 1,000,000 sample uploads per day and up to 1,000,000 verdict
queries per day from each Cortex XDR tenant. The daily limit resets at 23:59:00 UTC. Uploads that exceed the sample limit are queued for analysis after the
limit resets. WildFire also limits sample sizes to 100MB. For more information, see the WildFire documentation.

For samples that the Cortex XDR agent reports, the agent first checks its local cache of hashes to determine if it has an existing verdict for that sample. If the
Cortex XDR agent does not have a local verdict, the Cortex XDR agent queries Cortex XSIAM to determine if WildFire has previously analyzed the sample. If
the sample is identified as malware, it is blocked. If the sample remains unknown after comparing it against existing WildFire signatures, Cortex XSIAM forwards
the sample for WildFire analysis.

File Type Analysis

The Cortex XDR agent analyzes files based on the type of file, regardless of the file’s extension. For deep inspection and analysis, you can also configure your
Cortex XSIAM to forward samples to WildFire. A sample can be:

Any Portable Executable (PE) file including (but not limited to):

Executable files

Object code

FON (Fonts)

Microsoft Windows screensaver (.scr) files

Microsoft Office files containing macros opened in Microsoft Word (winword.exe) and Microsoft Excel (excel.exe):

Microsoft Office 2003 to Office 2016—.doc and .xls

Microsoft Office 2010 and later releases—.docm, .docx, .xlsm, and .xlsx

Dynamic-link library file including (but not limited to):

.dll files

.ocx files

Android application package (APK) files

Mach-o files

DMG files

Linux (ELF) files

For information on file-examination settings, see Add a New Malware Security Profile.

Verdicts

WildFire delivers verdicts to identify samples it analyzes as safe, malicious, or unwanted (grayware is considered obtrusive but not malicious):

Unknown—Initial verdict for a sample for which WildFire has received but has not analyzed.

Benign—The sample is safe and does not exhibit malicious behavior. If Low Confidence is indicated for the Benign verdict, Cortex XSIAM can treat this
hash as if the verdict is unknown and further run Local Analysis to get a verdict with higher confidence.

Malware—The sample is malware and poses a security threat. Malware can include viruses, worms, Trojans, Remote Access Tools (RATs), rootkits,
botnets, and malicious macros. For files identified as malware, WildFire generates and distributes a signature to prevent future exposure to the threat.

Grayware—The sample does not pose a direct security threat but might display otherwise obtrusive behavior. Grayware typically includes adware,
spyware, and Browser Helper Objects (BHOs).

NOTE:

In cases when the Cortex XSIAM agent gets a failed status from the WF service due to a general error or unsupported file type, and the Local Analysis is set
to disabled or not applicable, Cortex XSIAM will not generate an alert on the file.

When WildFire is not available or integration is disabled, the Cortex XDR agent can also assign a local verdict for the sample using additional methods of
evaluation: When the Cortex XDR agent performs local analysis on a file, it uses pattern-matching rules and machine learning to determine the verdict. The
Cortex XDR agent can also compare the signer of a file with a local list of trusted signers to determine whether a file is malicious:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 128/1003
5/8/24, 9:18 AM PDF Export

Local analysis verdicts:

Benign—Local analysis determined the sample is safe and does not exhibit malicious behavior.

Malware—The sample is malware and poses a security threat. Malware can include viruses, worms, Trojans, Remote Access Tools (RATs), rootkits,
botnets, and malicious macros.

Trusted signer verdicts:

Trusted—The sample is signed by a trusted signer.

Not Trusted—The sample is not signed by a trusted signer.

Local Verdict Cache

The Cortex XDR agent stores hashes and the corresponding verdicts for all files that attempt to run on the endpoint in its local cache. The local cache scales in
size to accommodate the number of unique executable files opened on the endpoint. On Windows endpoints, the cache is stored in the
C:\ProgramData\Cyvera\LocalSystem folder on the endpoint. When service protection is enabled (see Add a New Agent Settings Profile), the local cache is
accessible only by the Cortex XDR agent and cannot be changed.

Each time a file attempts to run, the Cortex XDR agent performs a lookup in its local cache to determine if a verdict already exists. If known, the verdict is either
the official WildFire verdict or manually set as a hash exception. Hash exceptions take precedence over any additional verdict analysis.

If the file is unknown in the local cache, the Cortex XDR agent queries Cortex XSIAM for the verdict. If Cortex XSIAM receives a verdict request for a file that
was already analyzed, Cortex XSIAM immediately responds to the Cortex XDR agent with the verdict.

If Cortex XSIAM does not have a verdict for the file, it queries WildFire and optionally submits the file for analysis. While the Cortex XDR agent attempts to wait
for an official WildFire verdict, it can use File Analysis and Protection Flow to evaluate the file. After Cortex XSIAM receives the verdict it responds to the Cortex
XDR agent that requested the verdict.

For information on file-examination settings, see Add a New Malware Security Profile.

3.6.3 | Add a New Restrictions Security Profile

Abstract

From the Cortex XDR management console, you can add and configure restriction security profiles to limit the surface of an attack on a Windows endpoint.

Restrictions security profiles limit the surface of an attack on a Windows endpoint by defining where and how your users can run files.

By default, the Cortex XDR agent will receive the default profile that contains a pre-defined configuration for each restrictions capability. To customize the
configuration for specific Cortex XDR agents, configure a new Restrictions security profile and assign it to one or more policy rules.

To define a Restrictions security profile:

1. Add a new profile.

a. Select the platform to which the profile applies and Restrictions as the profile type.

b. Click Next.

2. Define the basic settings.

a. Select a unique Profile Name to identify the profile. The name can contain only letters, numbers, or spaces, and must be no more than 30
characters. The name will be visible from the list of profiles when you configure a policy rule.

b. To provide additional context for the purpose or business reason for creating the profile, specify a profile Description. For example, you might
include an incident identification number or a link to a help desk ticket.

3. Configure each of the Restrictions Endpoint Protection Capabilities.

a. Configure the action to take when a file attempts to run from a specified location.

Block—Block the file execution.

Notify—Allow the file to execute but notify the user that the file is attempting to run from a suspicious location. The Cortex XDR agent also
reports the event to Cortex XSIAM.

Report—Allow the file to execute but report it to Cortex XSIAM.

Disabled—Disable the module and do not analyze or report execution attempts from restricted locations.

b. Add files to your allow list or block list, as needed.

The type of protection capability determines whether the capability supports an allow list, block list, or both. With an allow list, the action mode you
configure applies to all the paths except for those that you specify. With a block list, the action applies only to the paths that you specify.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 129/1003
5/8/24, 9:18 AM PDF Export

IMPORTANT:

Starting with version 1.3, Cortex XSIAM enables you to manage the Restriction Security Profile exceptions from a central location and easily
apply them across multiple profiles in the Legacy Agent Exceptions management page.

To manage the prevention profile exceptions from Exception Configuration, you must first migrate your existing exceptions configured via the
Prevention profiles.

To create new Restriction Security Profile exceptions using the Legacy Agent Exceptions management page, see Add a Legacy Exception Rule.

If you don't migrate the legacy exceptions, you can continue to add exceptions as described below.

1. +Add a file or folder.

2. Enter the path and press Enter or click the check mark when done. You can also use a wildcard to match a partial name for the folder and
environment variables. Use ? to match any single character or * to match any string of characters. To match a folder, you must terminate the
path with * to match all files in the folder (for example, c:\temp\*).

3. Repeat to add additional folders.

4. Configure Custom Indicator Prevention Rules.

If you have created custom indicator rules for prevention purposes, you enable their use here in the profile.

a. Prepare this restriction profile first, make a note of its name for later, but leave this setting disabled.

b. Prepare the prevention Indicator Rule (go to Detection & Threat Intel → Indicator Rules, ensuring to select Prevention when creating the rule), and
while preparing it, map it to your restriction profile.

c. Return to this restriction profile to modify it. Set this setting to Enabled.

5. Save the changes to your profile.

6. Apply Security Profiles to Endpoints.

You can do this in two ways: You can Create a new policy rule using this profile from the right-click menu or you can launch the new policy wizard from
Policy Rules.

3.6.4 | Manage Endpoint Security Profiles

Abstract

You can manage the security profiles of your Cortex XDR agent endpoints in various ways, including editing, duplicating, and populating security rules.

After you customize your Endpoint Security Profiles, you can manage these profiles from the Profiles page as needed.

1. View information about your security profiles.

The following table displays the fields that are available on the Profiles page in alphabetical order. The table includes both default fields and additional
fields that are available in the column manager.

Field Description

Associated Targets The targets the profile applies to.

Created By Administrative user who created the security profile.

Created Time Date and time at which the security profile was created.

Description Optional description entered by an administrator to describe the security profile.

Modification Time Date and time at which the security profile was modified.

Modified By Administrative user who modified the security profile.

Name Name provided to identify the security profile.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 130/1003
5/8/24, 9:18 AM PDF Export

Field Description

Platform Platform type of the security profile.

Summary Summary of security profile configuration.

Type Security profile type.

Usage Count Number of policy rules that use the profile.

2. Edit a security profile.

a. From Endpoints → Policy Management → Prevention → Profiles, right-click the security profile and select Edit.

b. Make your changes and then Save the security profile.

3. Export profile.

a. From Endpoints → Policy Management → Prevention → Profiles, right-click the security profile and select Export Profile.

b. Verify the profile you want to export.

NOTE:

New imported profiles are added and not replaced.

4. Duplicate a security profile.

a. From Endpoints → Policy Management → Prevention → Profiles, right-click the security profile and select Save as New.

b. Make your changes and then Create the security profile.

c. Step 6.

5. View the security policy rules that use a security profile.

From Endpoints → Policy Management → Prevention → Profiles, right-click the security profile and select View policy Rules.

Cortex XSIAM displays the policy rules that use the profile.

6. Populate a new policy rule with a security profile.

a. From Endpoints → Policy Management → Prevention → Profiles, right-click the security profile and Create a new policy rule using this profile.

Cortex XSIAM automatically populates the Platform selection based on your security profile configuration and assigns the security profile based on
the security profile type.

b. Enter a descriptive Policy Name and optional description for the policy rule.

c. Assign any additional security profiles that you want to apply to your policy rule, and select Next.

d. Select the target endpoints for the policy rule or use the filters to define criteria for the policy rule to apply, and then select Next.

e. Review the policy rule summary, and if everything looks good, select Done.

7. Delete a security profile.

a. If necessary, delete or detach any policy rules that use the profile before attempting to delete it.

b. From Endpoints → Policy Management → Prevention → Profiles, identify the security profile that you want to remove.

The Usage Count should have a 0 value.

c. Right-click the security profile and select Delete.

d. Confirm the deletion and you are done.

3.7 | Customizable Agent Settings

Abstract

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 131/1003
5/8/24, 9:18 AM PDF Export

You can apply predefined settings to your Cortex XDR agent endpoints, depending on the platform used on your endpoints.

Each Agent Settings Profile provides a tailored list of settings that you can configure for the platform that you select.

The following table describes these customizable settings and indicates which platforms support the setting (a dash (—) indicates the setting is not supported).

In addition to the customizable Agent Settings Profiles, you can also:

Configure Global Agent Settings that apply to all the endpoints in your network.

Configure Hardened Endpoint Security protections that leverage existing mechanisms and added capabilities to reduce the attack surface on your
endpoints.

Setting Windows Mac Linux Android

Agent Profiles

Disk Space —

Customize the amount of disk space the

Cortex XDR agent uses to store logs and
information about events.

User Interface — —

Determine whether and how end users

can access the Cortex XSIAM console.

Traps Tampering Protection — —

Prevent users from tampering with the

Cortex XDR agent components by
restricting access.

Uninstall Password — —

Change the default uninstall password to

prevent unauthorized users from
uninstalling the Cortex XDR agent
software.

Windows Security Center Configuration — — —

Configure your Windows Security Center

preferences to allow registration with the
Microsoft Security Center, to allow
registration with automated Windows
patch installation, or to disable
registration.

Forensics — — —

Change forensic data collection and

upload preferences.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 132/1003
5/8/24, 9:18 AM PDF Export

Setting Windows Mac Linux Android

XDR Pro Endpoints —

Enable the Cortex XDR Pro agent

capabilities, including enhanced data
collection, advanced responses, and
available Pro add-ons.

Requires a Cortex XDR Pro per Endpoint

license.

Response Actions —

Manual response actions that you can

take on the endpoint after a malicious file,
process, or behavior is detected. For
example, you can terminate a malicious
process, isolate the infected endpoint from
the network, quarantine a malicious file, or
perform additional action as necessary to
remediate the endpoint.

Content Updates —

Configure how the Cortex XDR agent

performs content updates on the endpoint:
whether to download the content directly
from Cortex XSIAM or from a peer agent,
whether to perform immediate or delayed
updates, and whether to perform
automatic content updates or continue
using the current content version.

Agent Auto Upgrade —

Enable the agent to perform automatic

upgrades whenever a new agent version
is released. You can select to upgrade
only to minor versions in the same line,
only to major versions, or both.

Upload Using Cellular Data — — —

Enable Android endpoints to send

unknown APK files for inspection as soon
as a user connects to a cellular network.

Global Agent Configurations

Global Uninstall Password —

Set the uninstall password for all agents in

the system.

Content Bandwidth Management —

Configure the total bandwidth to allocate

for content update distribution within your
organization.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 133/1003
5/8/24, 9:18 AM PDF Export

Setting Windows Mac Linux Android

Agent Auto Upgrade —

Configure the Cortex XDR agent auto

upgrade scheduler and number of parallel
upgrades.

Endpoint Data Collection —

Configure the type of information collected

by the Cortex XDR Agent for Vulnerability
Assessment and Host insights.

See Hardened Endpoint Security for the

list of all operating systems that support
these capabilities.

Advanced Analysis —

Enable Cortex XSIAM to automatically

upload alert data for secondary verdict
verification and security policy tuning.

3.7.1 | Add a New Agent Settings Profile

Abstract

Agent Settings Profiles enable you to customize Cortex XDR agent settings for different platforms and groups of users.

Agent Settings Profiles enable you to customize Cortex XDR agent settings for different platforms and groups of users.

1. Add a new profile.

a. From Cortex XSIAM, select Endpoints → Policy Management → Prevention → Profiles → +Add Profile and select whether to Create New or Import
from File a new profile.

NOTE:

New imported profiles are added and not replaced.

b. Select the platform to which the profile applies and Agent Settings as the profile type.

c. Click Next.

2. Define the basic settings.

a. Select a unique Profile Name to identify the profile. The name can contain only letters, numbers, or spaces, and must be no more than 30
characters. The name will be visible from the list of profiles when you configure a policy rule.

b. To provide additional context for the purpose or business reason for creating the profile, specify a profile Description. For example, you might
include an incident identification number or a link to a help desk ticket.

3. (Windows, Mac, and Linux only) Configure the Disk Space to allot for Cortex XDR agent logs.

Specify a value in MB from 100 to 10,000 (default is 5,000).

4. (Windows and Mac only) Configure User Interface options for the Cortex XSIAM console.

By default, Cortex XSIAM uses the settings specified in the default agent settings profile and displays the default configuration in parenthesis. When you
select a setting other than the default, you override the default configuration for the profile.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 134/1003
5/8/24, 9:18 AM PDF Export

Tray Icon—Choose whether you want the Cortex XDR agent icon to be Visible (default) or Hidden in the notification area (system tray).

XDR Agent Console Access—Enable this option to allow access to the Cortex XSIAM console.

XDR Agent User Notifications—Enable this option to operate display notifications in the notifications area on the endpoint. When disabled, the
Cortex XDR agent operates in silent mode where the Cortex XDR agent does not display any notifications in the notification area. If you enable
notifications, you can use the default notification messages, or provide custom text for each notification type. You can also customize a notification
footer.

From version 7.8, you can enable the option to maintain a persistent notification regarding the disconnection of the endpoint from the network. The
settings, Persistent Isolation Notification and Blocked Connectivity Notification must be enabled. Until the threat on the endpoint has been removed,
the endpoint remains disconnected from the network.

Live Terminal User Notifications—Choose whether to Notify the end user and display a pop-up on the endpoint when you initiate a Live Terminal
session. For Cortex XDR agents 7.3 and later releases only, you can select to Request end-user permission to start the session. If the end user
denies the request, you will not be able to initiate a Live Terminal session on the endpoint.

(Cortex XDR agent 7.3 and later releases only) Live Terminal Active Session Indication—Enable this option to display a blinking light ( ) on the tray
icon (or in the status bar for Mac endpoints) for the duration of the remote session to indicate to the end user that a live terminal session is in
progress.

5. (Android only) Configure network usage preferences.

When the option to Upload Using Cellular Data is enabled, the Cortex XDR agent uses cellular data to send unknown apps to the Cortex XSIAM for
inspection. Standard data charges may apply. When this option is disabled, the Cortex XDR agent queues any unknown files and sends them when the
endpoint connects to a Wi-Fi network. If configured, the data usage setting on the Android endpoint takes precedence over this configuration.

6. (Windows and Mac only) Configure Agent Security options that prevent unauthorized access or tampering with the Cortex XDR agent components.

Use the default agent settings or customize them for the profile. To customize agent security capabilities:

a. Enable XDR Agent Tampering Protection.

NOTE:

If you choose the Enabled option, you must also set Anti Tampering Protection in the Malware profile to Block, and ensure that both profiles are
assigned to the same endpoints.

b. (Windows only) By default, the Cortex XDR agent protects all agent components, however, you can configure protection more granularly for Cortex
XDR agent services, processes, files, and registry values according to the following options: With Traps 5.0.6 and later releases, when protection is
enabled, access will be read-only. In earlier Traps releases, enabling protection disables all access to services, processes, files, and registry values.

Service Protection-Protects against stopping the agent services. When this protection is on, the service won't accept OS requests to stop
willingly.

Process Protection-Protects against tampering attempts with the agent processes; injecting into them, terminating them, reading, or writing
into their virtual memory.

File Protection-Protects against tampering attempts with the agent files; deleting, replacing, renaming, moving, or writing files/directories.

Registry Protection-Protects against tampering attempts with the agent registry settings and agent policies, for example; deleting, adding, and
renaming registry keys or values which belong to the agent.

Pipe Protection-Protects against tampering attempts with the agent pipe-based inter-process communication (IPC) mechanism.

7. (Windows and Mac only) Configure an Uninstall Password.

Define and confirm a password the user must specify to uninstall the Cortex XDR agent. The uninstall password is encrypted using an encryption
algorithm (PBKDF2) when transferred between Cortex XSIAM and Cortex XDR agents. Additionally, the uninstall password is used to protect against
tampering attempts when using Cytool commands.

A new password must satisfy the Password Strength indicator requirements:

Must be 8 to 32 characters.

Contain at least one upper-case, at least one lower-case letter, at least one number, and at least one of the following characters: !@#%.

8. (Windows only) Configure Windows Security Center Integration.

The Windows Security Center is a reporting tool that monitors the system health and security state of Windows endpoints on Windows 7 and later
releases:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 135/1003
5/8/24, 9:18 AM PDF Export

Enabled—The Cortex XDR agent registers with the Windows Security Center as an official Antivirus (AV) software product. As a result, Windows
shuts down Microsoft Defender on the endpoint automatically, except for endpoints that are running Windows Server versions. To avoid
performance issues, Palo Alto Networks recommends that you disable or remove Windows Defender from endpoints that are running Windows
Server versions and where the Cortex XDR agent is installed.

Enabled (No Patches)—For the Cortex XDR agent 5.0 release only, select this option if you want to register the agent to the Windows Security
Center but prevent from Windows automatically install Meltdown/Spectra vulnerability patches on the endpoint.

Disabled—The Cortex XDR agent does not register to the Windows Action Center. As a result, Windows Action Center could indicate that Virus
protection is Off, depending on other security products that are installed on the endpoint.

NOTE:

When you Enable the Cortex XDR agent to register to the Windows Security Center, Windows shuts down Microsoft Defender on the endpoint
automatically. If you still want to allow Microsoft Defender to run on the endpoint where Cortex XSIAM is installed, you must Disable this option.
However, Palo Alto Networks does not recommend running Windows Defender and the Cortex XDR agent on the same endpoint since it might cause
performance issues and incompatibility issues with Global Protect and other applications.

9. Configure Alerts Data collection options.

When the Cortex XDR agent raises alerts on process-related activity on the endpoint, the Cortex XDR agent collects the contents of memory and other
data about the event in what is known as an alert data dump file. You can customize the Alert Data Dump File Size—Small, Medium, or Full (the largest
and most complete set of information)—and whether to Automatically Upload Alert Data Dump File to Cortex XSIAM. During event investigation, if
automatic uploading of the alert data dump file was disabled, you can manually retrieve the data.

10. (Requires a Cortex XDR Pro per Endpoint license) Enable and configure Cortex XDR Pro Endpoint capabilities on the endpoint, including enhanced data
collection, advanced responses, and available Pro add-ons.

a. Enable XDR Pro Endpoints Capabilities to configure which Pro capabilities to activate on the endpoint.

The Pro features are hidden until you enable the capability. Enabling this capability consumes a Cortex XDR Pro per Endpoint license.

b. (Supported on Cortex XDR agent 6.0 or later for Windows endpoints, and Cortex XDR agent 6.1 or later for Mac and Linux endpoints) Enable
Monitor and Collect Enhanced Endpoint Data.

By default, the Cortex XDR agent collects information about events that occur on the endpoint. If you enable Behavioral Threat Protection in a
Malware Security profile, the Cortex XDR agent also collects information about all active file, process, network, and registry activity on an endpoint
(see Endpoint Data Collection). When you enable the Cortex XDR agent to monitor and collect enhanced endpoint data, you enable Cortex XSIAM
to share the detailed endpoint information with other Cortex apps. The information can help to provide the endpoint context when a security event
occurs so that you can gain insight into the overall event scope during an investigation. The event scope includes all activities that took place during
an attack, the endpoints that were involved, and the damage caused. When disabled, the Cortex XDR agent will not share endpoint activity logs.

c. (Requires Host Insights add-on and Cortex XDR agent 7.1 or later releases) Enable Host Insights Capabilities.

Enable Endpoint Information Collection to allow the Cortex XDR agent to collect Host Inventory information such as users, groups, services,
drivers, hardware, and network shares, as well as information about applications installed on the endpoint, including CVE and installed KBs
for Vulnerability Assessment.

When enabled, the Cortex XDR agent collects detailed information about files on the endpoint to create a files inventory database. The agent
locally monitors any actions performed on these files and updates the local files inventory database in real-time.

With this option you can also select the File Search and Destroy Monitored File Types where Cortex XSIAM monitors all file types or only
common file types. If you choose Common file types, Cortex XSIAM monitors the following file types:

Windows—bin, msi, doc, docx, docm, rtf, xls, xlsx, xlsm, pdf, ppt, pptx, pptm, ppsm, pps, ppsx, mpp, mppx,
vsd, xsdx and wsf.

A hash will also be computed for these file types: zip, pe, and ole.

File size is limited to 30 MB by default. Searches of files larger than 30 MB by hash are not supported.

Mac—acm, apk, ax, bat, bin, bundle, csv, dll, dmg, doc, docm, docx, dylib, efi, hta, jar, js, jse, jsf,
lua, mpp, mppx, mui, o, ocx, pdf, pkg, pl, plx, pps, ppsm, ppsx, ppt, pptm, pptx, py, pyc, pyo, rb, rtf, scr,
sh, vds, vsd, wsf, xls, xlsm, xlsx, xsdx, and zip.

Additionally, you can exclude files that exist under a specific local path on the endpoint from inclusion in the files database.

d. (Requires Forensics Add-on and Cortex XDR agent 7.4 or later for Windows endpoints) Enable Monitor and Collect Forensics Data to allow the
Cortex XDR agent to collect detailed information about what happened on your endpoint to create a forensics database. Define the following if to
enable collection and in what time intervals of the following entity types:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 136/1003
5/8/24, 9:18 AM PDF Export

Process Execution

File Access

Persistence

Command History

Network

Remote Access

Search Collections

Data collected by the agent is displayed in the Forensic Data Analysis page.

e. When enabled, the Cortex XDR agent scans your network using Ping or Nmap to provide updated identifiers of your unmanaged network assets.
Ping scans return the IP address, MAC address, Hostname, and Platform, whereas Nmap will scan the most common ports for the IP address,
Hostname, Platform, and OS version.

The scan is performed according to the subnets detected in each network interface found on the endpoint, and up to a maximum of ~1K IP
addresses calculated according to agent_ip/22. For example, an agent with the IP address 121.121.121.121 will be assigned the scan range:
121.121.120.1 - 121.121.123.254 (1024 addresses). Each agent is assigned scan ranges randomly from all the scannable subnets, so the same
agent can scan multiple subnets.

The following criteria effects the scan:

There must be at least two endpoints detected in order to assign a scan.

Network Location configuration must be enabled.

Subnet masking settings and service name configurations influence the scan.

Excluded IP address ranges are not scanned.

1. In the Network Location Configuration section, set the Action Mode to Enabled.

2. In the Distributed Network Scan section, set the Action Mode to Enabled.

3. In Scan Mode, select Nmap or Ping.

NOTE:

When using Nmap, the Cortex XDR agent downloads an Nmap driver for the duration of the scan and removes the driver upon completion.
If an Nmap scan is in process, Cortex XDR identifies the Nmap driver and places any additional scans in a queue.

The scan is performed according to the subnets detected in each network interface found on the endpoint.

4. Select if you want to Excluded IP Address Ranges. The IP address ranges are populated from your Network Configurations.

5. If you selected Nmap, enable or disable whether to return the OS Fingerprinting of the IP address.

Depending on the type of scan you defined, the agent Ping scan takes 30 minutes and Nmap 60 minutes. Following each scan, Cortex XDR
aggregates the IP address collected and displays the results in the Asset Management table.

11. Configure XDR Cloud settings.

By default (auto detect mode), the agent detects whether an endpoint is a cloud-based (container) installation or a permanent installation, and uses
license allocation accordingly.

Auto detect automatically detects whether the endpoint is cloud-based, or a permanent installation, and applies the appropriate license.

Enabled treats any agent using this profile as if it is a cloud-based agent for licensing purposes.

12. Configure Response Actions.

If you need to isolate an endpoint but want to allow access for a specific application, add the process to the Network Isolation Allow List. The following are
considerations to the allow list:

When you add a specific application to your allow list from network isolation, the Cortex XDR agent continues to block some internal system
processes. This is because some applications, for example, ping.exe, can use other processes to facilitate network communication. As a result, if
the Cortex XDR agent continues to block an application you included in your allow list, you may need to perform additional network monitoring to
determine the process that facilitates the communication, and then add that process to the allow list.

(Windows) For VDI sessions, using the network isolation response action can disrupt communication with the VDI host management system
thereby halting access to the VDI session. As a result, before using the response action you must add the VDI processes and corresponding IP
addresses to your allow list.

1. +Add an entry to the allow list.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 137/1003
5/8/24, 9:18 AM PDF Export

2. Specify the Process Path you want to allow and the IPv4 or IPv6 address of the endpoint. Use the * wildcard on either side to match any process or
IP address. For example, specify * as the process path and an IP address to allow any process to run on the isolated endpoint with that IP address.
Conversely, specify * as the IP address and a specific process path to allow the process to run on any isolated endpoint that receives this profile.

3. Click the check mark when finished.

13. (Windows and Mac only) Configure Backup Management.

For Windows, you can enable or disable Shadowcopy Activation, If enabled, this automatically turns on the system protection of the endpoint. This
ensures that the data is backed up and may be recovered in cases of any security breaches or loss of data.

For MacOS, you can enable or disable Time Machine Activation. If enabled, this automatically turns on the Time Machine setting of the endpoint.
This ensures that the data is backed up and may be recovered in cases of any security breaches or loss of data.

14. (Linux only) Configure settings to automatically Revert Endpoint Isolation of an agent. When this feature is enabled, agent isolation will be cancelled when
a connection with the managing server is lost for the defined continuous period of time.

a. Either keep the recommended default setting (Enabled), or change it by selecting Disabled in the Revert Isolation field.

b. Set a time unit (Hours or Days) and enter the number of hours or days. We recommend 24 hours (default).

15. (Supported on Cortex XDR agent 7.0 or later for Windows endpoints and Cortex XDR agent 7.3 or later for Mac and Linux endpoints) Specify the Content
Configuration for your Cortex XDR agents.

Content Auto-update—By default, the Cortex XDR agent always retrieves the most updated content and deploys it on the endpoint so it is always
protected with the latest security measures. However, you can Disable the automatic content download. Then, the agent stops retrieving content
updates from the Cortex XSIAM Server and keeps working with the current content on the endpoint.

NOTE:

If you disable content updates for a newly installed agent, the agent retrieves the content for the first time from Cortex XSIAM and then
disables content updates on the endpoint.

When you add a Cortex XDR agent to an endpoint group with a disabled content auto-upgrades policy, the policy is applied to the added
agent as well.

Content Rollout—The Cortex XDR agent can retrieve content updates Immediately as they are available, or after a pre-configured Delayed period.
When you delay content updates, the Cortex XDR agent will retrieve the content according to the configured delay. For example, if you configure a
delay period of two days, the agent will not use any content released in the last 48 hours.

WARNING:

If you disable or delay automatic-content updates provided by Palo Alto Networks, it may affect the security level in your organization.

16. Enable Agent Auto Upgrade for your Cortex XDR agents.

To ensure your endpoints are always up-to-date with the latest Cortex XDR agent release, enable automatic agent upgrades. If you choose One release
before the latest one option,

a. Select the Automatic Upgrade Scope:

Latest agent release

One release before the latest one

Only maintenance release

Only maintenance release in a specific version

If you choose One release before the latest one, Cortex XSIAM upgrades the agent to the previous release before the latest, including
maintenance releases.

b. Select the Upgrade Rollout:

Immediate

Delayed—Specify the Delay Period In Days using a numeric value. Optional values are 7 through 45.

To control the agent auto upgrade scheduler and number of parallel upgrades in your network, see Configure Global Agent Settings.

NOTE:

Automatic upgrades are not supported with non-persistent VDI and temporary sessions.

c. (Optional) For Critical Environment (CE) versions, make sure to select if you want to upgrade your CE versions only within the CE lines. It can take
up to 15 minutes for new and updated auto-upgrade profile settings to take effect on your endpoints.

17. (Supported on Cortex XDR agent 7.0 or later for Windows endpoints and Cortex XDR agent 7.3 or later for Mac and Linux endpoints) Specify the
Download Source for agent and content updates.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 138/1003
5/8/24, 9:18 AM PDF Export

To reduce your external network bandwidth loads during updates, you can select the Download Source(s) from which the Cortex XDR agent retrieves
agent release upgrades and content updates: from a peer agent in the local network, from the Palo Alto Networks Broker VM, or directly from the Cortex
server. If all options are selected in your profile, then the attempted download order is first using P2P, then from Broker VM, and lastly from the Cortex
Server.

(Requires Cortex XDR agents 7.4 and later for P2P agent upgrade) P2P— Cortex XSIAM deploys serverless peer-to-peer P2P distribution to Cortex
XDR agents in your LAN network by default. Within the six hour randomization window during which the Cortex XDR agent attempts to retrieve the
new version, it will broadcast its peer agents on the same subnet twice: once within the first hour, and once again during the following five hours. If
the agent did not retrieve the files from other agents in both queries, it will proceed to the next download source defined in your profile.

To enable P2P, you must enable UDP and TCP over the defined PORT in Download Source. By default, Cortex XSIAM uses port 33221. You can
configure another port number.

(Requires Cortex XDR agents 7.4 and later releases and Broker VM 12.0 and later) Broker VM—If you have a Palo Alto Networks Broker VM in
your network, you can leverage the Local Agent Settings applet to cache release upgrades and content updates. When enabled and configured, the
Broker retrieves from Cortex XSIAM the latest installers and content every 15 minutes and stores them for a 30-days retention period since an
agent last asked for them. If the files were not available on the Broker VM at the time of the ask, the agent proceeds to download the files directly
from the Cortex XSIAM server.

If you enable the Broker download option, proceed to select one or more available Broker VMs from the list. Cortex XSIAM enables you to select
only Broker VMs that are connected and for which content caching is configured. For content caching to work properly, a FQDN and SSL Server
Certificate must be configured. When you select multiple Broker VMs, the agent chooses randomly which Broker VM to use for each download
request.

Cortex Server—To ensure your agents remain protected, the Cortex Server download source is always enabled to allow all Cortex XDR agents in
your network to retrieve the content directly from the Cortex XSIAM server on their following heartbeat.

NOTE:

Limitations in the content download process:

When you install the Cortex XDR agent, the agent retrieves the latest content update version available. A freshly installed agent can take between
five to ten minutes (depending on your network and content update settings) to retrieve the content for the first time. During this time, your
endpoint is not protected.

When you upgrade a Cortex XDR agent to a newer Cortex XDR agent version, if the new agent cannot use the content version running on the
endpoint, then the new content update will start within one minute in P2P and within five minutes from Cortex XSIAM.

18. Enable Network Location Configuration for your Cortex XDR agents.

(Requires Cortex XDR agents 7.1 and later releases) If you configure host firewall rules in your network, you must enable Cortex XSIAM to determine the
network location of your device, as follows:

1. A domain controller (DC) connectivity test— When Enabled, the DC test checks whether the device is connected to the internal network or not. If
the device is connected to the internal network, it is in the organization. Otherwise, if the DC test failed or returned an external domain, Cortex
XSIAM proceeds to a DNS connectivity test.

2. A DNS test—In the DNS test, the Cortex XDR agent submits a DNS name that is known only to the internal network. If the DNS returned the pre-
configured internal IP, the device is within the organization. Otherwise, if the DNS IP cannot be resolved, the device is located elsewhere. Specify
the IP Address and DNS Server Name for the test.

If the Cortex XDR agent detects a network change on the endpoint, the agent triggers the device location test and re-calculates the policy according to the
new location.

19. (Supported for Cortex XDR Agent 7.7 or later for Linux only) For Agent Operation Mode, if you want to run User Space mode when Kernel mode is
unavailable, select the checkbox. By default, the User Space fall-back is disabled.

20. Define your Agent Proxy Settings.

Select whether to Enable or Disable Direct Server Access for the agent when connected using a proxy.

21. (Supported for iOS only) Configure the following notifications that can be pushed to the iOS device.

a. App Notifications - Select whether to Disable or Enable app notifications to the device.

b. Jailbreak Detection - Select whether to Enable or Disable Jailbreak detection notification to the device.

c. Restart Recommendation - Select whether to Enable or Disable a reboot notification to the device. An option can be set for a reminder every
number of days. Default 15 days.

d. Stationary device indicators—Select whether to Enable or Disable notifications for stationary iOS devices, such as iPads that are expected to
remain in a fixed location. Options include significant location change, removal of power source, significant change of network, and low battery. In
the case of low battery notifications, you can configure a threshold for the device's remaining charge level (10% - 90%). You can also configure the
device to display a Stationary Device indication on its home screen.

22. (Linux only) Configure settings to automatically Revert Endpoint Isolation of an agent. When this feature is enabled, agent isolation will be cancelled when
a connection with the managing server is lost for the defined continuous period of time.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 139/1003
5/8/24, 9:18 AM PDF Export

a. Either keep the recommended default setting (Enabled), or change it by selecting Disabled in the Revert Isolation field.

b. Set a time unit (Hours or Days) and enter the number of hours or days. We recommend 24 hours (default).

23. (Linux only, for tenants paired with Prisma Cloud, optional) Configure periodic Active Vulnerability Analysis (AVA) scans. When AVA scans are enabled,
you can configure them to run at set intervals on a monthly, weekly, or hourly basis. The default period is once every 24 hours.

a. To enable periodic scanning, for Advanced Vulnerability Scanning, select Enabled.

b. Configure the Periodic Scan time period: For the default setting, select 24 Hours. For other time frames, select Custom, and then configure the
desired time frame.

c. Where relevant, select the start day and time for the periodic scans. If you select monthly scans, you can also configure a timeout period, in hours.

24. Define settings for collecting IT Metrics on the endpoint.

Select whether to enable or disable collection of IT metrics. When this option is set to Enabled, Cortex XSIAM collects IT data that provides visibility into IT
performance on the Agent.

25. Agent Certificates (Windows and Mac only). For improved security, enforce the use of root CA that is provided by Palo Alto Networks rather than on the
local machine.

Enabled - Enforcement is enabled. Note, If the Cortex XDR agent is initially unable to communicate without the local store, enforcement is not
enabled and the agent will show as partially protected.

Disabled (Notify) - Enforcement is disabled. Agents with this policy will trigger a banner in the server to notify customers about potential risk and
direct them to change the certificate and the setting. The Last Certificate Enforcement Fallback column of the All Endpoints table is updated and
management audit logs related to the local store fallback are received by the server.

Disabled - Enforcement is disabled. Agents with this policy will trigger a banner in the server to notify customers about potential risk and direct them
to change the certificate and the setting. The Last Certificate Enforcement Fallback column of the of the All Endpoints table is not updated and no
management audit logs related to the local store fallback are received by the server

26. Create your profile to save the changes to your profile.

27. Apply Security Profiles to Endpoints.

You can do this in two ways: You can Create a new policy rule using this profile from the right-click menu or you can launch the new policy wizard from
Policy Rules.

3.7.2 | Configure Global Agent Settings

Abstract

The different Cortex XDR agents that operate on your endpoints require configuration of different global settings.

On top of customizable Agent Settings Profiles for each Operating System and different endpoint targets, you can set global Agent Configurations that apply to
all the endpoints in your network.

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

2. Set global uninstall password.

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

A new password must satisfy the Password Strength indicator requirements:

Must be 8 to 32 characters.

Contain at least one upper-case, at least one lower-case letter, at least one number, and at least one of the following characters: !@#%.

3. Manage the content updates bandwidth and frequency in your network.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 140/1003
5/8/24, 9:18 AM PDF Export

Enable bandwidth control—Palo Alto Networks allows you to control your Cortex XDR agent network consumption by adjusting the bandwidth it is
allocated. Based on the number of agents you want to update with content and upgrade packages, active or future agents, the Cortex XSIAM
calculator configures the recommended amount of Mbps (Megabits per second) required for a connected agent to retrieve a content update over a
24 hour period or a week. Cortex XSIAM supports between 20 - 10000 Mbps, you can enter one of the recommended values or enter one of your
own. For optimized performance and reduced bandwidth consumption, it is recommended that you install and update new agents with Cortex XDR
agents 7.3 and later include the content package built in using SCCM.

Enable minor content version updates—The Cortex XSIAM research team releases more frequent content updates in-between major content
versions to ensure your network is constantly protected against the latest and newest threats in the wild. Enabled by default, the Cortex XDR agent
receives minor content updates, starting with the next content releases. To learn more about the minor content numbering format, refer to the About
Content Updates topic.

4. Configure content bandwidth allocated for all endpoints.

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

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

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

Amount of Parallel Upgrades—Set the number of parallel agent upgrades, while the maximum is 500 agents.

Days in week—You can schedule the upgrade task for specific days of the week and a specific time range. The minimum range is four hours.

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

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

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

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

a. Configure the desired options:

Enable Cortex XSIAM to automatically upload defined alert data files for advanced analysis. Advanced Analysis increases the Cortex XSIAM
exploit protection module accuracy.

Automatically apply Advanced Analysis exceptions to your Global Exceptions list. This will apply all Advanced Analysis exceptions suggested
by Cortex XSIAM, regardless of the alert data file source.

b. Save the Advanced Analysis configuration.

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

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

a. Configure the desired options:

Connection Lost (Days)—Configure the number of days after which the license should be returned when an agent loses the connection to
Cortex XSIAM. Default is 30 days; Range is 2 to 60 days. Where day one is counted as the first 24 hours with no connection.

Agent Deletion (Days)—Configure the number of days after which the agent and related data is removed from the Cortex XSIAM
management console and database. Default is 180 days; Range is 3 to 360 days and must exceed the Connection Lost value. Where day
one is the first 24 hours of lost connection.

b. Save the Agent Status configuration.

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

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

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 141/1003
5/8/24, 9:18 AM PDF Export

NOTE:

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

9. Enable Informative BTP Alerts.

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

NOTE:

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

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

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

Define whether to clean up according to Host Name, Host IP Address, MAC Address, or any combination of them. If not selected, the default is Host
Name. When you select more than one parameter, duplicate entries are removed only if they include all the selected parameters.

Configure the frequency of the cleanup—every 6 hours, 12 hours, 1 day, or 7 days. You can also select to perform an immediate One-time cleanup.

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

3.7.3 | Endpoint Data Collection

Abstract

To aid in endpoint detection and alert investigation, the Cortex XDR agent collects endpoint information when an alert is triggered.

When the Cortex XDR agent raises an alert on endpoint activity, a minimum set of metadata about the endpoint is sent to the server as described in Metadata
Collected for Cortex XDR Agent Alerts.

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

NOTE:

Agents with Cortex XDR Pro per Endpoint apply limits and filters on network, file, and registry logs. To expand these limits and filters, the Extended Threat
Hunting Data (XTH) add-on must be purchased.

The tables below note whether specific logs require the XTH add-on.

Metadata Collected for Cortex XDR Agent Alerts

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

Field Description

Absolute Timestamp Kernel system time

Relative Timestamp Uptime since the computer started

Thread ID ID of the originating thread

Process ID ID of the originating process

Process Creation Time Part of the process unique ID per boot session (PID + creation time)

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 142/1003
5/8/24, 9:18 AM PDF Export

Field Description

Sequence ID Unique integer per boot session

Primary User SID Unique identifier of the user

Impersonating User SID Unique identifier of the impersonating user, if applicable

EDR Data Collected for Windows Endpoints

Category Events Attributes

Mount a device (volume and hardware) Mount Storage device name

Unmount Storage device class GUID

Storage device class name

Storage device bus type

Storage device volume GUID

Storage device mount point

Storage device drive type

Storage device vendor ID

Storage device product ID

Storage device serial number

Storage device virtual volume image

Executable metadata (Traps 6.1 and later) Process start File size

File access time

Files Create Full path of the modified file before and after
modification
Write
SHA256 and MD5 hash for the file after
Delete
modification
Rename SetInformationFile for timestamps (Traps 6.1
and later)
Move

Modification (Traps 6.1 and later) File set security (DACL) information (Traps
6.1 and later)
Symbolic links (Traps 6.1 and later)
Resolve hostnames on local network (Traps
6.1 and later)

Symbolic-link/hard-link and reparse point

creation (Traps 6.1 and later)

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 143/1003
5/8/24, 9:18 AM PDF Export

Category Events Attributes

Image (DLL) Load Full path

Base address

Target process-id/thread-id

Image size

Signature (Traps 6.1 and later)

SHA256 and MD5 hash for the DLL (Traps

6.1 and later)

File size (Traps 6.1 and later)

File access time (Traps 6.1 and later)

Process Create Process ID (PID) of the parent process

Terminate PID of the process

Full path

Command line arguments

Integrity level to determine if the process is

running with elevated privileges

Hash (SHA256 and MD5)

Signature or signing certificate details

Thread Injection Thread ID of the parent thread

Thread ID of the new or terminating thread

Process that initiated the thread if from

another process

Network Accept Source IP address and port

Connect Destination IP address and port

Create Failed connection

Listen Protocol (TCP/UDP)

Close Resolve hostnames on local network

Bind

Network Protocols DNS request and UDP response Origin country

HTTP connect Remote IP address and port

HTTP disconnect Local IP address and port

HTTP proxy parsing Destination IP address and port if proxy

connection

Network connection ID

IPv6 connection status (true/false)

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 144/1003
5/8/24, 9:18 AM PDF Export

Category Events Attributes

Network Statistics On-close statistics Upload volume on TCP link

Periodic statistics Download volume on TCP link

Traps sends statistics both when a connection is

closed, and at periodic intervals while the
connection remains open.

Registry Registry value: Registry path of the modified value or key

Deletion Name of the modified value or key

Set Data of the modified value

Registry key:

Creation

Deletion

Rename

Addition

Modification (set information)

Restore

Save

Session Log on Interactive log-on (log-on at a computer

console using credentials such as a
Log off username and password)

Connect Session ID
Disconnect
Session State (equivalent to the event type)

Local (physically on the computer) or remote

(connected using a terminal services
session)

Host Status Boot Host name

Suspend OS Version

Resume Domain

Previous and current state

User Presence (Traps 6.1 and later) User Detection Detection when a user is present or idle per active
user session on the computer.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 145/1003
5/8/24, 9:18 AM PDF Export

Category Events Attributes

RPC Calls RpcCall action_rpc_interface_uuid

*Requires XTH add-on RpcPreCall action_rpc_interface_version_major

action_rpc_interface_version_minor

action_rpc_func_opnum

action_rpc_func_str_call_fields (optional)

action_rpc_func_int_call_fields (optional)

action_rpc_interface_name

action_rpc_func_name

System Calls Syscall types change frequently, and can be action_syscall_string_params

observed in each event's data.
*Requires XTH add-on action_syscall_int_params

action_syscall_target_instance_id

action_syscall_target_image_path

action_syscall_target_image_name

action_syscall_target_os_pid

action_syscall_target_thread_id

address_mapping

Event Log See the table below for the list of Windows Event Logs that can be sent to the server.

*Requires XTH add-on

Windows Event Logs

In Traps 6.1.3 and later releases, Cortex XDR and Traps agents can send the following Windows Event Logs to the tenant.

NOTE:

The XTH add-on is required for Windows event log collection.

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

Path Provider Event IDs And Description

Application EMET

Application Windows Error Reporting Only for Windows Error Reporting (WER) events when an application
stops unexpectedly

Application Microsoft-Windows-User 1511: A user logged on with a temporary profile because Windows
Profiles Service could not find the user's local profile.

1518: A profile could not be created using a temporary profile

Application Application Error 1000: Application unexpected stop/hang events, similar to WER/1001.
These events include the full path to the EXE file, or to the module with
the fault.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 146/1003
5/8/24, 9:18 AM PDF Export

Path Provider Event IDs And Description

Application Application Hang 1002: Application unexpected stop/hang events, similar to WER/1001.
These events include the full path to the EXE file, or to the module with
the fault.

Microsoft-Windows-LDAP-client 30: Windows Event Collector (WEC) recommended event

Microsoft-Windows-CAPI2/Operational Windows CAPI2 logging events:

11: Build Chain

70: A Private Key was accessed

90: X509 object

Microsoft-Windows-DNS- 3008: A DNS query was completed without local machine name
Client/Operational resolution events, and without empty name resolution events.

Microsoft-Windows-DriverFrameworks- 2004: Detection of User-Mode drivers loading, for potential BadUSB

UserMode/Operational detection

Microsoft-Windows- 4103: Block an activity

PowerShell/Operational
4104: Remote command

4105: Start command

4106: Stop command

Microsoft-Windows-PrintService Microsoft-Windows-PrintService

Microsoft-Windows- Microsoft-Windows- 106, 129, 141, 142, 200, 201

TaskScheduler/Operational TaskScheduler

Microsoft-Windows-TerminalServices- 1024: A terminal service (TS) attempted to connect to a remote server

RDPClient/Operational

Microsoft-Windows-Windows 1006: Microsoft Defender Antivirus detected suspicious behavior

Defender/Operational
1009: Microsoft Defender Antivirus restored an item from
quarantine

Microsoft-Antimalware-Scan-Interface 1101: Anti-Malware Scan Interface (AMSI) content scan event

Microsoft-Windows-Windows 1116: Microsoft Defender Antivirus detected malware or other

Defender/Operational potentially unwanted software

1119: Microsoft Defender Antivirus encountered a critical error

when taking action on malware or other potentially unwanted
software

Microsoft-Windows-Windows Firewall With Microsoft-Windows-Windows 2004, 2005, 2006, 2009, 2033: Windows Firewall With Advanced Security
Advanced Security/Firewall Firewall With Advanced Security Local Modifications (Levels 0, 2, 4)

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 147/1003
5/8/24, 9:18 AM PDF Export

Path Provider Event IDs And Description

Security 1102: The Security log cleared events

Security Microsoft-Windows-Eventlog Event log service events specific to the Security channel

Security 4880: Certificate Authority Service stopped

4881: Certificate Authority Service started

4896: Certificate Authority database rows were deleted

4898: A Certificate Authority template was loaded

Security Routing and Remote Access Service (RRAS) events (these are only
generated on Microsoft IAS server)

6272: User access was granted.

6280: User account unlocked

Security Microsoft-Windows-Security- 4624: Successful logon

Auditing
4625: Failed logon

4627: Group membership information

4634: Logoff

4647: User initiated logoff

4648: Logon attempted, explicit credentials

4649: Replay attack

4672: Special privileges attempted login

4768: Kerberos TGT request

4769: Kerberos service ticket requested

4770: Kerberos service ticket renewal

4771: Kerberos pre-authentication failed

4776: Domain controller validation attempt

4778: Session was reconnected to a Windows station

4800: Workstation locked

4801: Workstation unlocked

4802: Screensaver was invoked

4803: Screensaver was dismissed

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 148/1003
5/8/24, 9:18 AM PDF Export

Path Provider Event IDs And Description

Security Microsoft-Windows-Security- 4720: A user account was created

Auditing
4722: A user account was enabled

4723: An attempt was made to change an account's password

4724: An attempt was made to reset an account’s password

4725: A user account was disabled

4726: A user account was deleted

4727, 4731, 4754: Creation of Groups

4728, 4732, 4756: Group member additions

4729, 4733, 4757: Group member removals

4735, 4737, 4755, 4764: Group changes

4738: A user account was changed

4740: A user account was locked out

4741: A computer account was created

4742: A computer account was changed

4743: A computer account was deleted

4765, 4766: SID history

4767: A user account was unlocked

4780: ACL set on accounts

4781: The name of an account was changed

4799: Group membership enumeration

Security Microsoft-Windows-Security- 4616: System time was changed

Auditing
4821: Kerberos service ticket was denied

4822, 4823: New Technology LAN Manager (NTLM) authentication

failed

4824: Kerberos pre-authentication failed

4825: A user was denied access to Remote Desktop

5058: Key file operation

5059: Key migration operation

Security Microsoft-Windows-Security- 4698: A scheduled task was created

Auditing
4702: A scheduled task was updated

4886: Certificate Services received a certificate request

4887: Certificate Services approved a certificate request

4899: A Certificate Services template was updated

4900: Certificate Services template security was updated

5140: A network share object was accessed

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 149/1003
5/8/24, 9:18 AM PDF Export

Path Provider Event IDs And Description

Security Microsoft-Windows-Security- 4713: Kerberos policy was changed on a domain controller

Auditing

Security Microsoft-Windows-Security- 4662: An operation was performed on an Active Directory object

Auditing

EDR Data Collected for Mac Endpoints

Category Events Attributes

Files Create Full path of the modified file before and after
modification
*Requires XTH add-on Write
SHA256 and MD5 hash for the file after
Delete modification

Rename

Move

Open

Process Start Process ID (PID) of the parent process

Stop PID of the process

Full path

Command line arguments

Integrity level to determine if the process is

running with elevated privileges

Hash (SHA256 and MD5)

Signature or signing certificate details

Network Accept Source IP address and port

Connect Destination IP address and port

Connect Failure Failed connection

Disconnect Protocol (TCP/UDP)

Listen Aggregated send/receive statistics for the

connection
Statistics

Event Log Authentication Provider Name

*Requires XTH add-on Data fields

Message

EDR Data Collected for Linux Endpoints

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 150/1003
5/8/24, 9:18 AM PDF Export

Category Events Attributes

Files Create Full path of the file

*Requires XTH add-on Open Hash of the file

Write NOTE:

Delete For specific files only and only if the file was
written.

Copy Full paths of both the original and the

modified files
Move (rename)

Change owner (chown) Full path of the file

Change mode (chmod) Newly set owner/attributes

Network Listen Source IP address and port for explicit binds

Accept Destination IP address and port

Connect Failed TCP connections

Connect failure Protocol (TCP/UDP)

Disconnect

Process Start PID of the child process

PID of the parent process

Full image path of the process

Command line of the process

Hash of the image (SHA256 & MD5)

Stop PID of the stopped process

Event Log Authentication Provider Name

*Requires XTH add-on Data fields

Message

IT Performance Metrics

Field Description

Time Generated time

Timestamp

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 151/1003
5/8/24, 9:18 AM PDF Export

Field Description

Agent information Agent ID

Agent hostname

Agent OS type

Agent host boot time

Agent session start time

Agent request time

Event information Event ID

Event type

Event subtype

Event version

Event timestamp

Actor information Actor process instance ID

OS actor information OS actor process instance ID

OS actor process OS PID

OS actor process OS name

Sample information Sample start

Sample end

CPU usage information CPU max

CPU average

CPU 90th percentile

Memory usage information Memory max

Memory average

Memory 90th percentile

Vendor Vendor name

Product Product name

ZIP ZIP ID

Server information Server request time

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 152/1003
5/8/24, 9:18 AM PDF Export

3.8 | Apply Security Profiles to Endpoints

Abstract

Learn how to apply security profiles to your endpoints, depending on the platform used.

Cortex XSIAM provides out-of-the-box protection for all registered endpoints with a default security policy customized for each supported platform type. To
configure your security policy, customize the settings in a security profile and attach the profile to a policy.

Each policy you create must apply to one or more endpoints or endpoint groups. The Prevention Policy Rules table lists all the policy rules per operating system.
Rules associated with one or more targets that are beyond your defined user scope are locked and cannot be edited.

1. From Cortex XSIAM, create a policy rule.

Do one of the following:

Select Endpoints → Policy Management → Prevention → Policy Rules, and select + New Policy or Import from File.

NOTE:

When importing a policy, select whether to enable the associated policy targets. Rules within the imported policy are managed as follows:

New rules are added to the top of the list.

Default rules override the default rule in the target tenant.

Rules without a defined target are disabled until the target is specified.

Select Endpoints → Policy Management → Prevention → Profiles, right-click the profile you want to assign and Create a new policy rule using this
profile.

2. Define a Policy Name and optional Description that describes the purpose or intent of the policy.

3. Select the Platform for which you want to create a new policy.

4. Select the desired Exploit, Malware, Restrictions, and Agent Settings profiles you want to apply in this policy.

If you do not specify a profile, the Cortex XDR agent uses the default profile.

5. Click Next.

6. Use the filters to assign the policy to one or more endpoints or endpoint groups.

Cortex XSIAM automatically applies the platform filter you selected and, if it exists, the Group Name according to the groups within your defined user
scope.

7. Click Done.

8. In the Policy Rules table, change the rule position, if needed, to order the policy relative to other policies.

The Cortex XDR agent evaluates policies from top to bottom. When the Cortex XDR agent finds the first match it applies that policy as the active policy. To
move the rule, select the arrows and drag the policy to the desired location in the policy hierarchy.

Right-click to View Policy Details, Edit, Save as New, Disable, and Delete.

9. Export policy.

Select one or more policies, right-click and select Export Policies. You can include the associated Policy Targets, Global Exceptions, and endpoint groups.

NOTE:

The exported file is encoded in Base64 and cannot be edited.

3.9 | Exception Configuration

Abstract

Learn how to configure exceptions from your baseline policy.

To allow full granularity, Cortex XSIAM enables you to create exceptions from your baseline policy. With these exceptions you can remove specific folders or
paths from evaluation, or disable specific security modules. You can configure exception rules for Cortex XSIAM protection and prevention actions in a
centralized location, and apply them across multiple profiles. The exceptions can be configured from Settings → Exception Configuration.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 153/1003
5/8/24, 9:18 AM PDF Export

Alert Exclusion rules specify match criteria for alerts that you want to suppress.

IOC/BIOC Suppression Rules exclude one or more indicators from an IOC or BIOC rule which takes action on specific behaviors.

Disable Prevention Rules specify granular exceptions to prevention actions triggered for your endpoints.

Legacy Agent Exceptions define prevention profile exception rules for all endpoints.

Support Exception Rules generate exceptions based on files provided by the support team.

Prior to Cortex XSIAM version 1.3, Legacy Agent Exceptions and Support Exceptions were configured through their relevant profiles.

Starting with version 1.3, Cortex XSIAM enables you to manage the Legacy Agent Exceptions and Support Exception configurations from a central location and
easily apply them across multiple profiles in the Agent Exceptions Management page.

To manage the Prevention profile exceptions from Exception Configuration, you must first migrate your existing exceptions configured via profiles. Your existing
exception profiles are migrated per module.

Cortex XSIAM simulates the migration to enable you to review the results before activating the migration.

To run the simulation and migrate your exception configurations,

1. Select Settings → Exception Configuration → Legacy Exceptions and click Start Simulation.

2. Review the Legacy Agent Exceptions and the Support Exception Rules.

3. You can then Activate the new agent management page or Cancel to continue using the Prevention Profiles to configure individual exceptions.

IMPORTANT:

If you don't migrate the legacy exceptions, you can continue to create exceptions through the profiles.

Add a New Exceptions Security Profile

Add a Global Endpoint Policy Exception

Add a New Exploit Security Profile

Add a New Malware Security Profile

Add a New Restrictions Security Profile

After the migration, you can Add a Support Exception Rule or Create a Legacy Exception Rule.

3.9.1 | Alert Exclusions

Abstract

From theCortex XSIAM management console, you can review and manage all alert exclusions.

The Settings → Exception Configuration → Alert Exclusions page displays all the alert exclusion rules in Cortex XSIAM.

An Alert Exclusion is a rule that contains a set of alert match criteria that you want to suppress from Cortex XSIAM. You can add an Alert Exclusion rule from
scratch or you can base the exclusion off of alerts that you investigate in an incident. After you create an exclusion rule, Cortex XSIAM excludes and no longer
saves any of the future alerts that match the criteria from incidents and search query results. If you select to apply the policy to historic results as well as future
alerts, Cortex XSIAM identifies the historic alerts as grayed out.

The following table describes both the default fields and additional optional fields that you can add to the alert exclusions table and lists the fields in alphabetical
order.

Field Description

Checkbox to select one or more alert exclusions on which you want to perform actions.

BACKWARD SCAN STATUS Exclusion policy status for historic data, either enabled if you want to apply the policy to previous alerts or disabled if
you don’t want to apply the policy to previous alerts.

COMMENT Administrator-provided comment that identifies the purpose or reason for the exclusion policy.

DESCRIPTION Text summary of the policy that displays the match criteria.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 154/1003
5/8/24, 9:18 AM PDF Export

Field Description

MODIFICATION DATE Date and time when the exclusion policy was created or modified.

NAME Descriptive name provided to identify the exclusion policy.

POLICY ID Unique ID assigned to the exclusion policy.

STATUS Exclusion policy status, either enabled or disabled.

USER User that last modified the exclusion policy.

USER EMAIL Email associated with the administrative user.

3.9.1.1 | Add an Alert Exclusion Rule

Abstract

Learn how to create a rule to exclude certain criteria from raising alerts in Cortex XSIAM.

Through the process of triaging alerts or resolving an incident, you may determine whether a specific alert does not indicate a threat. If you do not want Cortex
XSIAM to display alerts that match certain criteria, you can create an alert exclusion rule.

After you create an exclusion rule, Cortex XSIAM hides any future alerts that match the criteria, and excludes the alerts from incidents and search query results.
If you choose to apply the rule to historic results as well as future alerts, the app identifies any historic alerts as grayed out.

NOTE:

If an incident contains only alerts with exclusions, Cortex XSIAM changes the incident status to Resolved - False Positive and sends an email
notification to the incident assignee (if set).

There are two ways to create an exclusion rule. You can define the exclusion criteria when you investigate an incident or you can create an alert exclusion from
scratch.

Alert Exclusions support SBAC (scoped based access control). The following parameters are considered when editing a rule:

If Scoped Server Access is enabled and set to restrictive mode, you can edit a rule if you are scoped to all tags in the rule.

If Scoped Server Access is enabled and set to permissive mode, you can edit a rule if you are scoped to at least one tag listed in the rule.

If a rule was added when set to restrictive mode, and then changed to permissive (or vice versa), you will only have view permissions.

Build an Alert Exclusion Policy from Alerts in an Incident

Abstract

You can create an exclusion rule based on the alerts in the incident.

If after reviewing the incident details, you want to suppress one or more alerts from appearing in the future, create an exclusion policy based on the alerts in the
incident. When you create an incident from the incident view, you can define the criteria based on the alerts in the incident. If desired, you can also create an
Alert Exclusion Policy from scratch.

1. In Incident Reponse → Incidents, from the Incident view, click the three dots menu and, select Create Exclusion.

2. Enter a Rule Name to identify your alert exclusion.

3. Enter a Description that specifies the reason or purpose of the alert exclusion rule.

4. Use the alert filters to add any match criteria for the alert exclusion policy.

You can also right-click a specific value in the alert to add it as match criteria. The app refreshes to show you which alerts in the incident would be
excluded. To see all matching alerts including those not related to the incident, clear the option to Show only alerts in the named incident.

5. Create the exclusion policy and confirm the action.

If you later need to make changes, you can view, modify, or delete the exclusion policy from the Settings → Exception Configuration → Alert Exclusions
page.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 155/1003
5/8/24, 9:18 AM PDF Export

Build an Alert Exclusion Rule from Scratch

Build your own alert exclusion rule.

1. Select Settings → Exception Configuration → Alert Exclusions.

2. Select + Add an Alert Exclusion Rule.

3. Specify a Rule Name to identify the exclusion rule.

4. Describe the reason or purpose of the rule.

5. Define the exclusion criteria.

Use the filters at the top of the table to build your exclusion criteria.

Use existing alert values to populate your exclusion criteria. To do so, right-click the column value on which you want to base your rule and select
Add alerts with <value> to configuration.

As you define the criteria, the app filters the results to display matches.

6. Review the results.

The alerts in the table will be excluded from appearing in the app after the rule is created and optionally, any existing alert matches will be grayed out.

CAUTION:

This action is irreversible. All historically excluded alerts will remain excluded if you disable or delete the rule.

7. Create the alert exception rule.

3.9.2 | Add an IOC or BIOC Rule Exception

Abstract

How to add an IOC or BIOC rule exception.

If you want to create a rule to take action on specific behaviors but also want to exclude one or more indicators from the rule, you can create an IOC or BIOC
rule exception. An indicator can include the SHA256 hash of a process, process name, process path, vendor name, user name, causality group owner (CGO)
full path, or process command-line arguments. For more information about these indicators, see Rules. For each exception, you also specify the rule scope to
which the exception applies.

NOTE:

Cortex XSIAM only supports exceptions with one attribute. See Add an Alert Exclusion Rule to create advanced exceptions based on your filtered criteria.

1. Select Settings → Exception Configuration → IOC/BIOC Suppression Rules.

2. Click + New Exception.

3. Specify a Rule Name and an optional Description.

4. Configure the indicators and conditions which define the exception.

You can use wildcards for matching the command line.

5. Select the scope of the exception, whether the exception applies to IOCs, BIOCs, or both.

By default all BIOC rules which match the criteria are excluded. To exclude only specific BIOC rules, select them from the provided rule list. You can add
multiple rules.

6. Save the exception rule.

By default, activity matching the indicators does not trigger any rule. As an alternative, you can select one or more rules. After you save the exception, the
Exceptions count for the rule increments. If you later edit the rule, you will also see the exception defined in the rule summary.

Export A Rule Exception

You can choose to export a BIOC rule exception.

1. Select Settings → Exception Configuration → IOC/BIOC Suppression Rules.

2. In the Exceptions table, locate the exception rule you want to export. You can select multiple rules.

3. Right-click and select Export.

If one or more of the selected exceptions are applied to a specific BIOC rule, select one of the following options:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 156/1003
5/8/24, 9:18 AM PDF Export

Export anyway.

Export only non-specific Exceptions—Only export exceptions are applied on all BIOC rules.

Export all Exceptions as non-specific—Export and apply specific Exceptions to BIOC rules.

3.9.3 | Add a Disable Prevention Rule

Abstract

Cortex XSIAM enables you to generate granular exceptions to prevention actions defined for your endpoints.

Cortex XSIAM enables you to generate granular exceptions to prevention actions defined for your endpoints. You can specify signers, command line, or
processes to exclude from the prevention actions triggered by specific security modules. This may be useful when you have processes that are essential to your
organization and must not be terminated. Cortex XSIAM still generates Alerts from the disabled rules.

IMPORTANT:

All applicable prevention actions are skipped for the files and process that match the properties defined in the rule.

You must consider the consequences of disabling a prevention rule before you add the exception and monitor it over time.

IMPORTANT:

You can only apply a Disable Prevention Rule to agents version 7.9 and later.

Configure a Disable Prevention Rule.

1. From Settings → Exception Configuration → Disable Prevention Rules, +Add Rule.

2. Specify an optional Description for the reason or intent for the rule.

3. Select the platform. To cover all your endpoints, you can prevent different exception rules per platform.

4. Under Target Properties, specify the Hash, Path, Command Line argument, or trusted Signer Name, or any combination of these.

When you specify two or more values, the exception is applied only if the file satisfies all the specified target properties.

You can use wildcards for matching the command line.

5. Select one or more security Modules which won't trigger prevention actions.

The actions triggered by the other modules are not affected.

6. Select the Scope for the rule. If you want to apply the rule to only specific Exception Profiles, select them from the drop-down list.

7. Enable the rule.

8. Review the configurations for the exception, and if the risks are acceptable to you, check I understand the risk.

3.9.4 | Add a Support Exception Rule

Abstract

How to add a support exception rule.

You can define and manage exceptions based on files received from the Customer Support team. You can apply the rule across all of your endpoints or to
specific profiles.

Prior to Cortex XSIAM version 1.3, Support Exceptions were configured through profiles.

Starting with version 1.3, Cortex XSIAM enables you to manage the Support Exceptions from a central location and easily apply them across multiple profiles in
the Support Exception Rules management page.

To manage the prevention profile exceptions from Exception Configuration, you must first migrate your existing exceptions configured via the Prevention profiles.

Your migrated rules are displayed on the Settings → Exception Configurations → Support Exception Rules page. For more information about the migration, see
Exception Configuration.

Import Support Exception Rules File.

1. From Settings → Exception Configuration → Support Exception Rules, click + Import from file.

2. Drag and drop or browse for the JSON file you received from the Customer Support team.

3. Select to apply the rule to specific Profiles or select Global to apply to all endpoints.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 157/1003
5/8/24, 9:18 AM PDF Export

IMPORTANT:

If you don't migrate the legacy exceptions, you can continue to create exceptions through the profiles.

Add a New Exceptions Security Profile

Add a Global Endpoint Policy Exception

Add a New Exploit Security Profile

Add a New Malware Security Profile

Add a New Restrictions Security Profile

3.9.5 | Add a Legacy Exception Rule

Abstract

Cortex XSIAM Legacy Exception rules enable you to configure an exception to prevention and protection modules on endpoints for selected profiles.

Legacy Exception rules enable you to configure an exception to prevention and protection modules on endpoints for selected profiles.

Items included in allow lists continue to generate Cortex XSIAM security events. If you want to exclude event reporting as well, configure this on the Alert
Exclusions page (Settings → Exception Configurations → Alert Exclusions).

Prior to Cortex XSIAM version 1.3, Legacy Exceptions were configured through profiles.

Starting with version 1.3, Cortex XSIAM enables you to manage the Malware Security exceptions from a central location and easily apply them across multiple
profiles in the Legacy Agent Exceptions Management page.

To manage the prevention profile exceptions from Exception Configuration, you must first migrate your existing exceptions configured via the Prevention profiles.

Your migrated rules are displayed on the Settings → Exception Configurations → Legacy Agent Exceptions page. For more information about the migration, see
Exception Configuration.

Create a new Legacy Exception rule.

1. From Settings → Exception Configurations → Legacy Agent Exceptions, + Add Rule.

2. Select the platform for which you want to create an agent exception.

3. Select the Module for which you want to create an exception.

4. For each module, specify the following parameters.

Type Module Platform Parameters

Malware Respond to Malicious Causality Windows Add to your allow list specific and
Chains known safe IP address or IP
address ranges that you do not
want Cortex XSIAM to block.

Behavioral Threat Protection Windows, MacOS, Linux Add to your allow list the file or
folder path you want to exclude
from evaluation. Use ? to match a
single character or * to match any
string of characters.

Office Files with Micros Windows Add to your allow list the file or
Examination folder path you want to exclude
from evaluation. Use ? to match a
single character or * to match any
string of characters.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 158/1003
5/8/24, 9:18 AM PDF Export

Type Module Platform Parameters

Portable Executable and DLL Windows Add to your allow list the file or
Examination folder path and the signers you
want to exclude from evaluation.
Use ? to match a single character
or * to match any string of
characters.

Malicious Child Process Protection Windows Add to your allow list the parent
processes that can launch child
processes to your allow list with
optional execution criteria. Specify
the allow list criteria including
the Parent Process Name, Child
Process Name, and Command
Line Params. Use ? to match a
single character or * to match any
string of characters.

Ransomware Protection Windows Add to your allow list the file or

folder path you want to exclude
from evaluation. Use ? to match a
single character or * to match any
string of characters.

Endpoint Scanning Windows, MacOS, Linux Add to your allow list the file or
folder path and the signers you
want to exclude from evaluation.
Use ? to match a single character
or * to match any string of
characters.

Credential Gathering Protection Windows, MacOS, Linux Add to your allow list the file or
folder paths to exclude from
evaluation. Use ? to match a
single character or * to match any
string of characters.

Anti Webshell Protection Windows, MacOS, Linux Add to your allow list the file or
folder paths to exclude from
evaluation. Use ? to match a
single character or * to match any
string of characters.

Financial Malware Threat Windows, MacOS, Linux Add to your allow list the file or
Protection folder paths to exclude from
evaluation. Use ? to match a
single character or * to match any
string of characters.

Cryptominers Protection Windows, MacOS, Linux Add to your allow list the file or
folder paths to exclude from
evaluation. Use ? to match a
single character or * to match any
string of characters.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 159/1003
5/8/24, 9:18 AM PDF Export

Type Module Platform Parameters

In-process Shellcode Protection Windows Add to your allow list the file or
folder paths to exclude from
evaluation. Use ? to match a
single character or * to match any
string of characters.

Malicious Device Prevention Windows Add to your allow list the file or
folder paths to exclude from
evaluation. Use ? to match a
single character or * to match any
string of characters.

UAC Bypass Prevention Windows Add to your allow list the file or
folder paths to exclude from
evaluation. Use ? to match a
single character or * to match any
string of characters.

Anti Tampering Protection Windows, MacOS Add to your allow list the file or
folder paths to exclude from
evaluation. Use ? to match a
single character or * to match any
string of characters.

Mach-o Files Examination MacOS Add to your allow list the file or
folder paths to exclude from
evaluation. Use ? to match a
single character or * to match any
string of characters.

DMG File Examination MacOS Add to your allow list the file or
folder paths to exclude from
evaluation. Use ? to match a
single character or * to match any
string of characters.

Local File Threat Examination Linux Add to your allow list the file or
folder paths to exclude from
evaluation. Use ? to match a
single character or * to match any
string of characters.

ELF File Examination Linux Add to your allow list the file or
folder paths to exclude from
evaluation. Use ? to match a
single character or * to match any
string of characters.

Reverse Shell Protection Linux Specify the Process Path. Local IP

Address and port, and the Remote
IP Address and port of the process
you want to allow. Use ? to match
a single character or * to match
any string of characters.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 160/1003
5/8/24, 9:18 AM PDF Export

Type Module Platform Parameters

APK Files Examination Android Specify the signers you want to

exclude from evaluation. Use ? to
match a single character or * to
match any string of characters.

SMS and MMS Malicious URL iOS Add to your allow list and known
filtering Allow list safe URLs that you do not want
Cortex XSIAM to block.

Call and Messages Blocking Allow iOS Add to your allow list names and
list phone numbers of contacts that
you do not want Cortex XSIAM to
block.

Dynamic Kernel Protection Windows Add to your allow list the file or
folder path you want to exclude
from evaluation. Use ? to match a
single character or * to match any
string of characters.

Restrictions Executable Files Windows Add to your allow list the file or
folder paths to exclude from
evaluation. Use ? to match a
single character or * to match any
string of characters.

Network Location Files Windows Add to your allow list the file or
folder paths to exclude from
evaluation. Use ? to match a
single character or * to match any
string of characters.

Optical Drive Files Windows Add to your allow list the file or
folder paths to exclude from
evaluation. Use ? to match a
single character or * to match any
string of characters.

Removable Media Files Windows Add to your allow list the file or
folder paths to exclude from
evaluation. Use ? to match a
single character or * to match any
string of characters.

Exceptions Process Exceptions Windows, MacOS, Linux Add to your allow list the process
and the module names to exclude
from evaluation. Use ? to match a
single character or * to match any
string of characters.

5. Select all to apply the exception to all profiles for this module or select specific profiles.
IMPORTANT:

If you don't migrate the legacy exceptions, you can continue to create exceptions through the profiles.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 161/1003
5/8/24, 9:18 AM PDF Export

Add a New Exceptions Security Profile

Add a Global Endpoint Policy Exception

Add a New Exploit Security Profile

Add a New Malware Security Profile

Add a New Restrictions Security Profile

3.9.5.1 | Add a New Exceptions Security Profile

Abstract

How to add a new Exceptions Security profile.

You can configure exceptions that apply to specific groups of endpoints or you can Add a Global Endpoint Policy Exception.

IMPORTANT:

Starting with version 1.3, Cortex XSIAM enables you to manage the Exception Security rules from a central location and easily apply them across multiple
profiles in the Legacy Agent Exceptions management page.

To manage the exceptions from Exception Configuration, you must first migrate your existing exceptions configured via the Exceptions Security profiles.

To create new Exception Security Profile rules using the Legacy Agent Exceptions management page, see Add a Legacy Exception Rule.

If you don't migrate the legacy exceptions, you can continue to create exceptions as described below.

Use the following workflow to create an endpoint-specific exception:

1. Add a new profile.

a. From Cortex XSIAM, select Endpoints → Policy Management → Prevention → Profiles → +Add Profile and select whether to Create New or Import
from File a new profile.

NOTE:

New imported profiles are added and not replaced.

b. Select the platform to which the profile applies and Exceptions as the profile type.

c. Click Next.

2. Define the basic settings.

a. Select a unique Profile Name to identify the profile. The name can contain only letters, numbers, or spaces, and must be no more than 30
characters. The name will be visible from the list of profiles when you configure a policy rule.

b. To provide additional context for the purpose or business reason for creating the profile, specify a profile Description. For example, you might
include an incident identification number or a link to a help desk ticket.

3. Configure the exceptions profile.

To configure a Process Exception:

1. Select the operating system.

2. Enter the name of the process.

3. Select one or more Endpoint Protection Modules that will allow this process to run. The modules displayed in the list are the modules relevant to the
operating system defined for this profile.

To apply the process exception on all security modules, Select all.

To apply the process exception on the following exploit modules, select Disable Injection.

APC Guard, CPL Execution Protection, DEP, DLL Hijacking Protection, DLL Security, EPM D02, Exception Heap Spray Check, Exception
SysExist Check, Exploit Kit Fingerprinting Protection, Font Protection, Hot Patch Protection, JIT Mitigation, Library Preallocation, Memory
Limit Heap Spray Check, Null Dereference Protection, Password Theft Protection, ROP Mitigation, SEH Protection, Shellcode Preallocation,
UASLR

4. Click the adjacent arrow.

5. After you've added all the processes, select Create.

You can return to the Process Execution profile from the Endpoint Profile page at any point and edit the settings. For example, if you want to add or
remove security modules.

To configure a Support Exception:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 162/1003
5/8/24, 9:18 AM PDF Export

1. Import the json file you received from Palo Alto Networks support team by either browsing for it in your files or by dragging and dropping the file on
the page.

2. Click Create.

To configure module specific exceptions relevant for the selected profile platform:

Behavioral Threat Protection Rule Exception—When you view an alert for a Behavioral Threat event that you want to allow in your network from
now on, right-click the alert and Create alert exception. Review the alert data (Platform and Rule name) and select from the following options as
needed.

- CGO hash—Causality Group Owner (CGO) hash value.

- CGO signer—CGO signer entity (for Windows and Mac only).

- CGO process path—Directory path of the CGO process.

- CGO command arguments—CGO command arguments. This option is available only if CGO process path is selected, and only if you are using
Cortex XDR Agent 7.5 or later on your endpoints. After selecting this option, check the full path of each relevant command argument within quote
marks. You can edit the displayed paths if needed.

From Exception Scope, select Profile and click Create.

Digital Signer Exception—When you view an alert for a Digital Signer Restriction that you want to allow in your network from now on, right-click the
alert and Create alert exception. Cortex XSIAM displays the alert data (Platform, Signer, and Generating Alert ID). Select Exception Scope: Profile
and select the exception profile name. Click Add.

Java Deserialization Exception—When you identify a Suspicious Input Deserialization alert that you believe to be benign and want to suppress
future alerts, right-click the alert and Create alert exception. Cortex XSIAM displays the alert data (Platform, Process, Java executable, and
Generating Alert ID). Select Exception Scope: Profile and select the exception profile name. Click Add.

Local File Threat Examination Exception—When you view an alert for a PHP file that you want to allow in your network from now on, right-click the
alert and Create alert exception. Cortex XSIAM displays the alert data (Process, Path, and Hash). Select Exception Scope: Profile and select the
exception profile name. Click Add.

Gatekeeper Enhancement Exception—When you view a Gatekeeper Enhancement security alert for a bundle or specific source-child combination
you want to allow in your network from now on, right-click the alert and Create alert exception. Cortex XSIAM displays the alert data (Platform,
Source Process, Target Process, and Alert ID). Select Exception Scope: Profile and select the exception profile name. Click Add. This exception
allows Cortex XSIAM to continue enforcing the Gatekeeper Enhancement protection module on the source process running other child processes.

At any point, you can click the Generating Alert ID to return to the original alert from which the exception originated. You cannot edit module specific
exceptions.

4. Apply Security Profiles to Endpoints.

If you want to remove an exceptions profile from your network, go to the Profiles page, right-click and select Delete.

3.9.5.2 | Add a Global Endpoint Policy Exception

Abstract

From the Cortex XSIAM management console, define and manage global endpoint policy exceptions.

IMPORTANT:

Starting with version 1.3, Cortex XSIAM enables you to manage the Global Endpoint Policy exceptions from a central location and easily apply them across
multiple profiles in the Legacy Agent Exceptions management page.

To manage the prevention profile exceptions from Exception Configuration, you must first migrate your existing exceptions configured via the Global
exceptions.

Your migrated rules are displayed on the Settings → Exception Configurations → Legacy Agent Exceptions page. For more information about the migration,
see Exception Configuration.

To create new Global Endpoint Policy exceptions using the Legacy Agent Exceptions management page, see Add a Legacy Exception Rule.

If you don't migrate the legacy exceptions, you can continue to add exceptions as described below.

As an alternative to adding an endpoint-specific exception in policy rules, you can define and manage global exceptions that apply across all of your endpoints.
On the Global Exception page, you can manage all the global exceptions in your organization for all platforms. Profiles associated with one or more targets that
are beyond your defined user scope are locked and cannot be edited.

Add a Global Process Exception

Abstract

Configure exception rules forCortex XSIAM protection and prevention actions in a centralized location, and apply them across multiple profiles.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 163/1003
5/8/24, 9:18 AM PDF Export

IMPORTANT:

Starting with version 1.3, Cortex XSIAM enables you to manage the Global Endpoint Policy exceptions from a central location and easily apply them across
multiple profiles in the Legacy Agent Exceptions management page.

To manage the prevention profile exceptions from Exception Configuration, you must first migrate your existing exceptions configured via the Global
exceptions.

Your migrated rules are displayed on the Settings → Exception Configurations → Legacy Agent Exceptions page. For more information about the migration,
see Exception Configuration.

To create new Global Endpoint Policy exceptions using the Legacy Agent Exceptions management page, see Add a Legacy Exception Rule.

If you don't migrate the legacy exceptions, you can continue to add exceptions as described below.

1. Go to Endpoints → Policy Management → Policy Exceptions.

2. Select Process exceptions.

a. Select the operating system.

b. Enter the name of the process.

c. Select one or more Endpoint Protection Modules that will allow this process to run. The modules displayed on the list are the modules relevant to
the operating system defined for this profile. To apply the process exception on all security modules, Select all. To apply the process exception on all
exploit security modules, select Disable Injection. Click the adjacent arrow to add the exception.

3. After you add all exceptions, Save your changes.

The new process exception is added to the Global Exceptions in your network and will be applied across all rules and policies. To edit the exception,
select it and click the edit icon. To delete it, select it and click the delete icon.

Add a Global Support Exception

Abstract

Configure Support exception rules for Cortex XSIAM protection and prevention actions in a centralized location, and apply them across multiple profiles.

IMPORTANT:

Starting with version 1.3, Cortex XSIAM enables you to manage the Global Support exceptions from a central location and easily apply them across multiple
profiles in the Legacy Agent Exceptions management page.

To manage the global support exceptions from Exception Configuration, you must first migrate your existing exceptions.

Your migrated rules are displayed on the Settings → Exception Configurations → Support Exception Rules page. For more information about the migration,
see Exception Configuration.

To create new Global Support exceptions using the Support Exception Rules page, see Add a Support Exception Rule.

If you don't migrate the legacy exceptions, you can continue to create exceptions as described below.

1. Go to Endpoints → Prevention → Global Exceptions.

2. Select Support Exceptions.

Import the json file you received from Palo Alto Networks support team by either browsing for it in your files or by dragging and dropping the file on the
page.

3. Click Save.

The new support exception is added to the Global Exceptions in your network and will be applied across all rules and policies.

Add a Global Behavioral Threat Protection (BTP) Rule Exception

Abstract

How to add a Global Behavioral Threat Protection (BTP) Rule Exception.

When you view a Behavioral Threat alert in the Alerts table which you want to allow across your organization, you can create a global exception for that rule.

1. Right-click the BTP alert and select Create alert exception.

2. Review the alert data (platform and rule name) and then select from the following options as needed:

a. CGO hash—Causality Group Owner (CGO) hash value.

b. CGO signer—CGO signer entity (for Windows and Mac only).

c. CGO process path—Directory path of the CGO process.

d. CGO command arguments—CGO command arguments. This option is available only if CGO process path is selected, and only if you are using
Cortex XDR Agent 7.5 or later on your endpoints. After selecting this option, check the full path of each relevant command argument within quote
marks. You can edit the displayed paths if needed.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 164/1003
5/8/24, 9:18 AM PDF Export

e. From Exception Scope, select Global.

3. Click Create.

The relevant BTP exception is added to the Global Exceptions in your network and will be applied across all rules and policies. At any point, you can click
the Generating Alert ID to return to the original alert from which the exception originated. To delete a specific global exception, select it and click X.

NOTE:

You cannot edit global exceptions generated from a BTP security event.

Add a Global Credential Gathering Protection Exception

Abstract

How to add a Global Credential Gathering Protection Exception.

When you view a Credential Gathering Protection alert in the Alerts table which you want to allow across your organization, you can create a global exception for
that rule.

1. Right-click the Credential Gathering Protection alert and select Create alert exception.

2. Review the alert data (platform and module name) and then select from the following options as needed:

a. CGO hash—Causality Group Owner (CGO) hash value.

b. CGO signer—CGO signer entity (for Windows and Mac only).

c. CGO process path—Directory path of the CGO process.

d. CGO command arguments—CGO command arguments. This option is available only if CGO process path is selected, and only if you are using
Cortex XDR Agent 7.5 or later on your endpoints. After selecting this option, check the full path of each relevant command argument within quote
marks. You can edit the displayed paths if needed.

e. From Exception Scope, select Global.

3. Click Create.

The relevant exception is added to the Global Exceptions in your network and will be applied across all rules and policies. At any point, you can click the
Generating Alert ID to return to the original alert from which the exception originated. To delete a specific global exception, select it and click X.

NOTE:

You cannot edit global exceptions generated from a Credential Gathering Protection security event.

Add a Global Anti Webshell Protection Exception

Abstract

How to add a Global Anti Webshell Protection Exception.

When you view an Anti Webshell Protection alert in the Alerts table which you want to allow across your organization, you can create a global exception for that
rule.

1. Right-click the Anti Webshell Protection alert and select Create alert exception.

2. Review the alert data (platform and module name) and then select from the following options as needed:

a. CGO hash—Causality Group Owner (CGO) hash value.

b. CGO signer—CGO signer entity (for Windows and Mac only).

c. CGO process path—Directory path of the CGO process.

d. CGO command arguments—CGO command arguments. This option is available only if CGO process path is selected, and only if you are using
Cortex XDR Agent 7.5 or later on your endpoints. After selecting this option, check the full path of each relevant command argument within quote
marks. You can edit the displayed paths if needed.

e. From Exception Scope, select Global.

3. Click Create.

The relevant exception is added to the Global Exceptions in your network and will be applied across all rules and policies. At any point, you can click the
Generating Alert ID to return to the original alert from which the exception originated. To delete a specific global exception, select it and click X.

NOTE:

You cannot edit global exceptions generated from an Anti Webshell Protection security event.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 165/1003
5/8/24, 9:18 AM PDF Export

Add A Global Local Analysis Rules Exception

Abstract

How to add a global Local Analysis Rules exception

When you view in the Alerts table a Local Analysis alert that was triggered as a result of local analysis rules, you can create a global exception to allow the rules
across your organization.

1. Right-click the alert and select Create alert exception.

2. Review the alert data (platform and rule name) and select Exception Scope: Global.

3. Click Add.

The relevant Local Analysis Rules exception is added to the Global Exceptions in your network and will be applied across all rules and policies. The
exception allows all the rules that triggered the alert, and you cannot choose to allow only specific rules within the alert. At any point, you can click the
Generating Alert ID to return to the original alert from which the exception originated. To delete a specific global exception, select it and click X. You cannot
edit global exceptions generated from a local analysis security event.

Review Advanced Analysis Exceptions

With Advanced Analysis, Cortex XSIAM can provide a secondary validation of Cortex XDR Agent alerts raised by exploit protection modules. To perform the
additional analysis, Cortex XSIAM analyzes alert data sent by the Cortex XDR agent. If Advanced Analysis indicates an alert is benign, Cortex XSIAM can
automatically create exceptions and distribute the updated security policy to your endpoints.

By enabling Cortex XSIAM to automatically create and distribute global exceptions you can minimize disruption for users when they subsequently encounter the
same benign activity. To enable the automatic creation of Advanced Analysis Exceptions, configure the Advanced Analysis options in
Settings+Configurations+General+Agent Configurations.

For each exception, Cortex XSIAM displays the affected platform, exception name, and the relevant alert ID for which Cortex XSIAM determined activity was
benign. To drill down into the alert details, click the Generating Alert ID.

Add a Global Digital Signer Exception

Abstract

How to add a Global Digital Signer Exception

When you view in the Alerts table a Digital Signer Restriction alerts for a digital signer you trust and want to allow from now on across your network, create a
Global Exception for that digital signer directly from the alert.

1. Right-click the alert and select Create alert exception.

Review the alert data (Platform, signer, and alert ID) and select Exception Scope: Global.

2. Click Add.

The relevant digital signer exception is added to the Global Exceptions in your network and will be applied across all rules and policies. At any point, you
can click the Generating Alert ID to return to the original alert from which the exception originated. To delete a specific global exception, select it and click
X. You cannot edit global exceptions generated from a digital signer restriction security event.

Add a Global Java Deserialization Exception

Abstract

How to add a Global Java Deserialization Exception

When you view in the Alerts table a Suspicious Input Desensitization alert for a Java executable you want to allow from now on across your network, create a
global exception for that executable directly from the alert of the security event that prevented it.

1. Right-click the alert and select Create alert exception.

Review the alert data (Platform, Process, Java executable, and alert ID) and select Exception Scope: Global.

2. Click Add.

The relevant digital signer exception is added to the Global Exceptions in your network and will be applied across all rules and policies. At any point, you
can click the Generating Alert ID to return to the original alert from which the exception originated. To delete a specific global exception, select it and click
X. You cannot edit global exceptions generated from a digital signer restriction security event.

Add a Global Local File Threat Examination Exception

Abstract

Configure exception rules forCortex XSIAM protection and prevention actions in a centralized location, and apply them across multiple profiles. Adding a local
file threat examination, global exemption.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 166/1003
5/8/24, 9:18 AM PDF Export

When you view in the Alerts table a Local Threat Detected alert for a PHP file you want to allow from now on across your network, create a global exception for
that file directly from the alert of the security event that prevented it.

1. Right-click the alert and select Create alert exception.

Review the alert data (Process, Path, and Hash) and select Exception Scope: Global.

2. Click Add.

The relevant PHP file is added to the Global Exceptions in your network and will be applied across all rules and policies. At any point, you can click the
Generating Alert ID to return to the original alert from which the exception originated. To delete a specific global exception, select it and click X. You cannot
edit global exceptions generated from a local file threat examination exception restriction security event.

Add a Global Gatekeeper Enhancement Exception

Abstract

How to add a Global Gatekeeper Enhancement Exception.

When you view a Gatekeeper Enhancement security alert in the Alerts table, you can create a global exception for this specific bundle or source-child
combination only, while allowing Cortex XSIAM to continue enforcing the Gatekeeper Enhancement protection module on the source process running other child
processes.

1. Right-click the alert and select Create alert exception.

Review the alert data (Platform, Source Process, Target Process, and Alert ID) and select Exception Scope: Global.

2. Click Add.

The relevant source and target processes are added to the Global Exceptions in your network and will be applied across all rules and policies. At any
point, you can click the Generating Alert ID to return to the original alert from which the exception originated. To delete a specific global exception, select it
and click X. You cannot edit global exceptions generated from a gatekeeper enhancement security event.

Import and Export Exceptions

Abstract

How to import and export execptions.

Select + Import/Export to Export your exceptions list and/or Import from File.

NOTE:

The exported file is encoded in Base64 and cannot be edited.

3.10 | Hardened Endpoint Security

Abstract

By hardening your endpoints with Cortex XDR you can make these endpoints more secure and safer from attackers.

Cortex XSIAM enables you to extend the security on your endpoints beyond the Cortex XDR agent built-in prevention capabilities to provide increased coverage
of network security within your organization. By leveraging existing mechanisms and added capabilities, the Cortex XDR agent can enforce additional
protections on your endpoints to provide a comprehensive security posture.

From Endpoints → Policy Management → Extensions → Profiles, you can create profiles for the following hardened endpoint security capabilities.

Device Control

Host Firewall

Host Firewall for Windows

Host Firewall for macOS

Disk Encryption

Host Inventory (Cortex XDR Pro)

Vulnerability Assessment (Cortex XDR Pro)

The Extensions Profiles table lists the profile details per operating system. Profiles associated with one or more targets that are beyond your defined user scope
are locked and cannot be edited.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 167/1003
5/8/24, 9:18 AM PDF Export

Field Description

Associated Targets The targets associated with the profile.

Created By Administrative user who created the profile.

Created Time Date and time at which the profile was created.

Description Optional description entered by an administrator to describe the profile.

Modification Time Date and time at which the profile was modified.

Modified By Administrative user who modified the profile.

Name Name provided to identify the security profile.

Platform Platform type of the profile.

Summary Summary of profile configuration.

Type Profile type.

Usage Count Number of policy rules that use the profile.

To apply the profiles, from Endpoints → Policy Management → Extensions → Policy Rules, you can view all the policy rules per operating system. Rules
associated with one or more targets that are beyond your defined user scope are locked and cannot be edited.

The following table describes for each capability the supported platforms and minimal agent version. A dash (—) indicates the setting is not supported.

CAUTION:

Hardened endpoint security capabilities are not supported for Android endpoints.

Module Windows Mac Linux

Device Control —
Cortex XDR agent 7.0 and later Cortex XDR agent 7.2 and later
Protects endpoints from loading malicious
files from USB-connected removable devices For VDI, Cortex XDR agent 7.3
(CD-ROM, disk drives, floppy disks, and and later
Windows portable devices drives).

Host Firewall —
Cortex XDR agent 7.1 and later Cortex XDR agent 7.2 and later
Protects endpoints from attacks originating in
network communications to and from the
endpoint.

Disk Encryption —
Cortex XDR agent 7.1 and later Cortex XDR agent 7.2 and later
Provides visibility into endpoints that encrypt
their hard drives using BitLocker or FileVault.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 168/1003
5/8/24, 9:18 AM PDF Export

Module Windows Mac Linux

Host Inventory
Cortex XDR agent 7.1 and later Cortex XDR agent 7.1 and later Cortex XDR agent 7.1 and later
Provides full visibility into the business and IT
operational data on all your endpoints.

Vulnerability Assessment —
Cortex XDR agent 7.1 and later Cortex XDR agent 7.1 and later
Identifies and quantifies the security
vulnerabilities (CVEs) that exist for
applications installed on your endpoints.

3.10.1 | Device Control

Abstract

Protect your Windows endpoints from connecting to malicious USB-connected removable devices.

By default, all external USB devices are allowed to connect to your Cortex XSIAM endpoints. To protect endpoints from connecting USB-connected removable
devices—such as disk drives, CD-ROM drives, floppy disk drives, and other portable devices—that can contain malicious files, Cortex XSIAM provides device
control.

Using device control, you can:

Block all supported USB-connected devices for an endpoint group.

Block a USB device type but add to your allow list a specific vendor from that list that will be accessible from the endpoint.

Temporarily block only some USB device types on an endpoint.

NOTE:

Depending on your defined user scope permissions, creating device profiles, policies, exceptions, and violations may be disabled.

The following are prerequisites to enforce device control policy rules on your endpoints:

Platform Requirements And Limitations

Windows Cortex XDR agent 7.0 or later.

For VDI—

Cortex XDR agent 7.3 or later.

Virtual environments leverage different stacks that might not be subject to the Device Control policy rules that
are enforced by the Cortex XDR agent and, therefore, could lead to USB devices that are allowed to connect
to the VDI instance in contrast to the configured policy rules.

The Cortex XDR agent provides best-effort enforcement of the Device Control policy rules on VDI instances
that are running on physical endpoints where a Cortex XDR agent is not deployed.

For Citrix Virtual Apps and Desktops, Cortex XSIAM Device Control is supported on generic virtual channels
only.

For VMWare Horizon, you must disable Sharing → Allow access to removable storage in your VMWare
horizon client settings.

Mac Cortex XDR agent 7.2 or a later.

Linux Not supported

Android/iOS Device Control policy rules do not take effect on Android/iOS devices.

NOTE:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 169/1003
5/8/24, 9:18 AM PDF Export

If you are running Cortex XDR agents 7.3 or earlier releases, device control rules take effect on your endpoint only after the Cortex XDR agent deploys the
policy. If you already had a USB device connected to the endpoint, you have to disconnect it and connect it again for the policy to take effect.

Device Control Profiles

To apply device control in your organization, define device control profiles that determine which device types Cortex XSIAM blocks and which it permits. There
are two types of profiles:

Profile Description

Configuration Profile Allow or block these USB-connected device type groups:

Disk Drives

CD-Rom Drives

Floppy Disk Drives

(Windows only) Windows Portable Devices

NOTE:

Cortex XSIAM relies on the device class assigned by the operating

system.

Add a New Configuration Profile.

The Cortex XDR agent relies on the device class assigned by the operating
system. For Windows endpoints only, you can configure additional device
classes.

Add a Custom Device Class.

Exceptions Profile Allow specific devices according to device types and vendor. You can further
specify a specific product and/or product serial number.

Add a New Exceptions Profile.

Device Configuration and Device Exceptions profiles are configured for each operating system separately. After you configure a device control profile, Apply
Device Control Profiles to Your Endpoints.

Add a New Configuration Profile

1. In Endpoints → Policy management → Extension → Profiles, select + New Profile or Import from File.

2. Select Platform and click Device Configuration → Next.

3. Fill in the General Information.

Assign the profile Name and add an optional Description. The profile Type and Platform are set by Cortex XSIAM.

4. Configure the Device Configuration.

For each group of device types, select whether to Allow or Block them on the endpoints. For Disk Drives only, you can also allow connecting in Read-only
mode. To use the default option defined by Palo Alto Networks, leave Use Default selected.

NOTE:

Currently, the default is set to Use Default (Allow), however, Palo Alto Networks may change the default definition at any time.

NOTE:

In XQL Search, to view connect and disconnect events of USB devices that are reported by the agent, the Device Configuration must be set to Block.
Otherwise, the USB events are not captured. The events are also captured when a group of device types are blocked on the endpoints with a
permanent or temporary exception in place. For more information, see Ingest Connect and Disconnect Events of USB Devices.

5. Save your profile.

When you’re done, Create your device profile definitions.

If needed, you can edit, delete, or duplicate your profiles.

NOTE:

You cannot edit or delete the default profiles pre-defined in Cortex XSIAM.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 170/1003
5/8/24, 9:18 AM PDF Export

6. (Optional) To define exceptions to your Device Configuration profile, Add a New Exceptions Profile.

7. Apply Device Control Profiles to Your Endpoints.

Add a New Exceptions Profile

1. In Endpoints → Policy management → Extension → Profiles, select + New Profile or Import from File.

2. Select Platform and click Device Exceptions → Next.

3. Fill in the General Information.

Assign the profile Name and add an optional Description. The profile Type and Platform are set by the system.

4. Configure Device Exceptions.

You can add devices to your allow list according to different sets of identifiers-vendor, product, and serial numbers.

(Disk Drives only) Permission—Select the permissions you want to grant: Read only or Read/Write.

Type—Select the Device Type you want to add to the Allow List (Disk Drives, CD-Rom, Portable, or Floppy Disk).

Vendor—Select a specific vendor from the list or enter the vendor ID in hexadecimal code.

(Optional) Product—Select a specific product (filtered by the selected vendor) to add to your allow list, or add your product ID in hexadecimal code.

(Optional) Serial Number—Enter a specific serial number (pertaining to the selected product) to add to your allow list. Only devices with this serial
number are included in the allow list.

5. Save your profile.

When you’re done, Create your device exceptions profile.

If needed, you can later edit, delete, or duplicate your profiles.

NOTE:

You cannot edit or delete the predefined profiles in Cortex XSIAM.

6. Apply Device Control Profiles to Your Endpoints.

Apply Device Control Profiles to Your Endpoints

After you define the required profiles for Device Configuration and Exceptions, you must configure Device Control Policies and enforce them on your endpoints.
Cortex XSIAM applies Device Control policies on endpoints from beginning to end, as you’ve ordered them on the page. The first policy that matches the
endpoint is applied. If no policies match, the default policy that enables all devices is applied.

1. In Endpoints → Policy management → Extension → Policy Rules , select + New Policy or Import from File.

NOTE:

When importing a policy, select whether to enable the associated policy targets. Rules within the imported policy are managed as follows:

New rules are added to the top of the list.

Default rules override the default rule in the target tenant.

Rules without a defined target are disabled until the target is specified.

2. Configure settings for the Device Control policy.

a. Assign a policy name and select the platform. You can add a description.

The platform will automatically be assigned to Windows.

b. Assign the Device Type profile you want to use in this rule.

c. Click Next.

d. Select the target endpoints on which to enforce the policy.

Use filters or manual endpoint selection to define the exact target endpoints of the policy rules. If exists, the Group Name is filtered according to the
groups within your defined user scope.

e. Click Done.

3. Configure policy hierarchy.

Drag and drop the policies in the desired order of execution. The default policy that enables all devices on all endpoints is always the last one on the page
and is applied to endpoints that don’t match the criteria in the other policies.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 171/1003
5/8/24, 9:18 AM PDF Export

4. Save the policy hierarchy.

After the policy is saved and applied to the agents, Cortex XSIAM enforces the device control policies on your environment.

5. (Optional) Manage your policy rules.

In the Protection Policy Rules table, you can view and edit the policy you created and the policy hierarchy.

a. View your policy hierarchy.

b. Right-click to View Policy Details, Edit, Save as New, Disable, and Delete.

c. Select one or more policies, right-click and select Export Policies. You can choose to include the associated Policy Targets, Global Exceptions, and
endpoint groups.

6. Monitor device control violations.

After you apply Device Control rules in your environment, use the Endpoints → Device Control Violations page to monitor all instances where end users
attempted to connect restricted USB-connected devices and Cortex XSIAM blocked them on the endpoint. All violation logs are displayed on the page.
You can sort the results and use the filters menu to narrow down the results. For each violation event, Cortex XSIAM logs the event details, the platform,
and the device details that are available.

If you see a violation for which you’d like to define an exception on the device that triggered it, right-click the violation and select one of the following
options:

Add device to permanent exceptions—To ensure this device is always allowed in your network, select this option to add the device to the Device
Permanent Exceptions list, the type of Permissions , and an optional comment.

Add device to temporary exceptions—To allow this device only temporarily on the selected endpoint or on all endpoints, select this option and set
the allowed time frame for the device, the type of Permissions , and an optional comment.

Add device to a profile exception—Select this option to allow the device within an existing Device Exceptions profile, the type of Permissions, and
an optional comment.

7. Tune your device control exceptions.

To better deploy device control in your network and allow further granularity, you can add devices on your network to your allow list and grant them access
to your endpoints. Device control exceptions are configured per device and you must select the device category, vendor, and type of permission that you
want to allow on the endpoint. Optionally, to limit the exception to a specific device, you can also include the product and/or serial number.

Cortex XSIAM enables you to configure the following exceptions:

Exception Name Description

Permanent Exceptions Permanent exceptions approve the device in your network across all Device Control
policies and profiles. You can create them directly from the violation event that blocked the
device, or through the Permanent Exceptions list.

NOTE:

Permanent exceptions apply across platforms, allowing the devices on all operating
systems.

Create a Permanent Exception.

Temporary Exceptions Temporary exceptions approve the device for a specific time period up to 30 days. You
create a temporary exception directly from the violation event that blocked the device.

Create a Temporary Exception.

Profile Exceptions Profile exceptions approve the device in an existing exceptions profile. You create a profile
exception directly from the violation event that blocked the device.

Create an Exception within a Profile.

a. Create a Permanent Exception.

Permanent device control exceptions are managed in the Permanent Exception list and are applied to all devices regardless of the endpoint
platform.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 172/1003
5/8/24, 9:18 AM PDF Export

If you know in advance which device you’d like to allow throughout your network, create a general exception from the list:

1. Go to Endpoints → Policy Management → Extensions and select Device Permanent Exceptions on the left menu. The list of existing
Permanent Exceptions is displayed.

2. Select Type, Permission, and Vendor.

3. (Optional) Select a specific product and/or enter a specific serial number for the device.

4. Click the adjacent arrow and Save. The exception is added to the Permanent Exceptions list and will be applied in the next heartbeat.

Otherwise, you can create a permanent exception directly from the violation event that blocked the device in your network:

1. On the Device Control Violations page, right-click the violation event triggered by the device you want to permanently allow.

2. Select Add device to permanent exceptions. Review the exception data and change the defaults if necessary.

3. Click Save.

b. Create a Temporary Exception.

1. On the Device Control Violations page, right-click the violation event triggered by the device you want to temporarily allow.

2. Select Add device to temporary exceptions. Review the exception data and change the defaults if necessary. For example, you can configure
the exception to this endpoint only or to all endpoints in your network, or set which device identifiers will be included in the exception.

3. Configure the exception TIME FRAME by defining the number of days or number of hours during which the exception will be applied, up to 30
days.

4. Click Save. The exception is added to the Device Temporary Exceptions list and will be applied in the next heartbeat.

c. Create an Exception within a Profile.

1. On the Device Control Violations page, right-click the violation event triggered by the device you want to add to a Device Exceptions profile.

2. Select the PROFILE from the list.

3. Save. The exception is added to the Exceptions Profile and will be applied in the next heartbeat.

Add a Custom Device Class

(Windows only) You can include custom USB-connected device classes beyond Disk Drive, CD-ROM, Windows Portable Devices, and Floppy Disk Drives, such
as USB connected network adapters. When you create a custom device class, you must supply Cortex XSIAM the official ClassGuid identifier used by Microsoft.
Alternatively, if you configured a GUID value to a specific USB connected device, you must use this value for the new device class. After you add a custom
device class, you can view it in Device Management and enforce any device control rules and exceptions on this device class.

To create a custom USB-connected device class:

1. Go to Endpoints → Policy Management → Settings → Device Management.

This is the list of all your custom USB-connected devices.

2. Create the new device class.

Select +New Device. Set a Name for the new device class, and supply a valid and unique GUID Identifier. For each GUID value, you can define one class
type only.

3. Save.

The new device class is now available in Cortex XSIAM as all other device classes.

Add a Custom User Notification

(Requires a Cortex XDR agent 7.5 or a later release for Windows) You can personalize the Cortex XSIAM notification pop-up on the endpoint when the user
attempts to connect a USB device that is either blocked on the endpoint or allowed in read-only mode. To edit the notifications, refer to the Agent Settings
Profile.

Ingest Connect and Disconnect Events of USB Devices

The Cortex Query Language (XQL) supports the ingestion of connect and disconnect events of USB devices that are reported by the agent. To view these USB
device events in XQL Search, you must set the Device Configuration of the endpoint profile to Block. Otherwise, the USB events are not captured. The events
are also captured when a group of device types are blocked on the endpoints with a permanent or temporary exception in place. For more information, see Add
a New Configuration Profile.

You can use XQL Search to query for this data and build widgets based on the xdr_data dataset, where the following use cases are supported:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 173/1003
5/8/24, 9:18 AM PDF Export

Displaying devices by Vendor ID, Vendor Name, Product ID, and Product Name.

Displaying hosts that a specific device, based on the serial number, is connected.

Query for USB devices that are connected to specific hosts or groups of hosts.

Examples of XQL queries that query the USB device data.

This query returns the action_device_usb_product_name field from all xdr_data records, where the event_type is DEVICE and the event_sub_type
is DEVICE_PLUG.

dataset = xdr_data
| filter event_type = DEVICE and event_sub_type = DEVICE_PLUG
| fields action_device_usb_product_name

This query returns the action_device_usb_vendor_name field from all device_control records (preset of the xdr_data dataset) where the
event_type is DEVICE.

preset = device_control
| filter event_type = DEVICE
| fields action_device_usb_vendor_name

3.10.2 | Host Firewall

Abstract

Control communications on your endpoints based on the network location of your device by using the Cortex XDR host firewall.

The Cortex XSIAM host firewall enables you to control communications on your endpoints. To use the host firewall, you set rules that allow or block the traffic on
the devices and apply them to your endpoints using host firewall policy rules. Additionally, you can configure different sets of rules based on the current location
of your endpoints - within or outside your organization network. The Cortex XSIAM host firewall rules leverage the operating system firewall APIs and enforce
these rules on your endpoints, but not your Windows or Mac firewall settings.

The following apply Cortex XSIAM host firewall policy rules on your endpoints.

Platform Requirements And Limitations

Windows Cortex XDR agent 7.5 or a later release.

By default, Cortex firewall is disabled and Windows firewall has control. Enforcing Cortex firewall rules will
take control away from Windows Firewall, and Windows firewall rules will no longer apply.

It is recommended to disable the windows firewall on endpoints running Windows 7 SP1 before applying the
Cortex XSIAM host firewall profile.

Mac Cortex XDR agent 7.5 or a later release.

After you disable or remove the Cortex XSIAM host-firewall policy on the endpoint, the system firewall on the
endpoint is disabled.

You cannot configure the following Mac host firewall settings with the Cortex XSIAM host firewall.

Automatically allow built-in software to receive incoming connections.

Automatically allow downloaded signed software to receive incoming connections.

Linux Not supported.

3.10.2.1 | Host Firewall for Windows

Abstract

Control communications on your endpoints based on the network location of your device by using the host firewall.

Enforce the Cortex XSIAM host firewall policy in your organization to control communications on your endpoints and gain visibility into your network connections.
The host firewall policy consists of unique rules groups that are enforced hierarchically and can be reused across all host firewall profiles. The Cortex XSIAM
host firewall rules are integrated with the Windows Security Center and leverage the operating system firewall APIs and enforce these rules on your endpoints,
but not your operating system firewall settings. Once you deploy the host firewall, use the Host Firewall Events table to track the enforcement events in your
organization.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 174/1003
5/8/24, 9:18 AM PDF Export

To configure the Cortex XSIAM host firewall in your network, follow this high-level workflow:

Ensure you meet the host firewall requirements and prerequisites.

Create rule(s) within rule groups—Create host firewall rules groups that you can reuse across all host firewall profiles. Add rules to each group and
prioritize the rules from top to bottom to create an enforcement hierarchy.

Configure a profile—Select one or more rule groups into a host firewall enforcement profile that you later associate with an enforcement policy. The
profile can enforce different rules when the endpoint is located within the organization’s internal network, and when it is outside. Prioritize the groups
within the profile from top to bottom to create an enforcement hierarchy.

Configure a policy—Add your host firewall profile to a new or existing policy that will be enforced on selected target endpoints.

Monitor and troubleshoot—View aggregated host firewall enforcement events, or all single host firewall activities the agent performed in your network.
Cortex XDR Pro customers can also query the host firewall events using the new host_firewall_events dataset in XQL Search for data and network
analysis.

Migration and Backwards Supportability

Host firewall is supported with Cortex XDR agents 7.1 or later. Starting with Cortex XDR 3.0 and Cortex XDR agent 7.5, new capabilities were added. Your
existing host firewall rules and policies are migrated as follows:

Any existing host firewall profile in Cortex XDR 2.9 is converted into a single rules group in Cortex XDR 3.0 and located on the Host Firewall Rules Groups
page.

If the existing profile contains both internal and external rules, then two groups are created: an external rules group and an internal rules group, and the
rule name is added with an internal/external suffix respectively. For example, internal rule-x is renamed as rule-x-internal.

Cortex XDR 3.0 host firewall includes new features which are supported only with Cortex XDR agents 7.5 and later, such as multiple IP addresses,
reporting mode, and more. For an older agent release, existing host firewall rules remain unaffected. However, if you create a rule from Cortex XDR 3.0,
or edit an already existing rule that was created in an old Cortex XDR release and add one of these unsupported parameters, the agent could display
unexpected behavior and the host firewall policy will be disabled on the endpoint.

NOTE:

As a result, all migrated rules are set not to report matching traffic by default, and enforcement events are not included in the Host Firewall Events table.

Set Up the Host Firewall

Set up your rule groups and host firewall profile.

Create a Rules Group

Abstract

Learn how to create a Rules group.

Group rules into Rules Groups that you can reuse across all host firewall profiles. A host firewall group includes one or more host firewall unique rules. The rules
are enforced according to their order of appearance within the group, from top to bottom. After you create a rules group, you can assign the group to a host
firewall profile. When you edit, re-prioritize, disable, or delete a rule from a group, the change takes effect in all policies where this group is included. To support
this scalability and structure, every rule in Cortex XSIAM is assigned a unique ID and must be contained within a group. Additionally, you can import existing
firewall rules into Cortex XSIAM, or export them in JSON format.

1. Create a group.

From Endpoints → Host Firewall → Host Firewall Rules Groups, click +New Group on the upper bar.

2. Fill-in general information.

Enter the rule name and optional description. To enforce the rules within the group in all policies they are associated with, Enable the group. When
Disabled, the group exists but is not enforced.

3. Create rules within the rules group.

Create rules within rules groups to allow or block traffic on the endpoint. Use a variety of parameters to fine tune your policy such as specific protocols,
applications, services, and more. For every group, you need to create its own list of rules. Each rule is assigned a unique ID and can be associated with a
single group only.

NOTE:

A rule is always part of a rules group. It cannot stand on its own.

A rule can belong to one rules group only and cannot be reused in different groups.

a. Configure rule settings.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 175/1003
5/8/24, 9:18 AM PDF Export

A host firewall rule allows or blocks the communication to and/or from an endpoint. Enter the rule Name, optional Description, and select the
Platforms you want to associate the rule with.

Fine tune the rule by applying the action to the following parameters:

Protocol—Select any of the 256 internet protocols:

Any

Custom

TCP

UDP

ICMPv4

ICMPv6

Once you select one of the available protocols or enter the protocol number, you will be able to specify additional parameters per protocol as
needed. For example, for TCP(6) you can set local and remote ports, whereas for ICMPv4(1) you can add the ICMP type and code.

NOTE:

When selecting ICMP protocol, you must enter a the ICMP Type and Code. Without these values the ICMP protocol is ignored by the
Windows and macOS Cortex XDR agents.

Direction—Select the direction of the communication this rule applies to: Inbound communication to the endpoint, Outbound communication
from the endpoint, or Both.

Action—Select whether the rule action is to Allow or Block the communication on the endpoint.

Local/Remote IP Address—Configure the rule for specific local or remote IP addresses s and/or Ports. You can set a single IP address,
multiple IP addresses separated by a comma, range of IP addresses separated by a hyphen, or a combination of these options.

Depending on the type of platform you selected, define the Application, Service, and Bundle IDs of the Windows Settings and/or macOS
Settings—Configure the rule for all applications/services or specific ones only by entering the full path and name. If you use system variables
in the path definition, you must re-enforce the policy on the endpoint every time the directories and/or system variables on the endpoint
change.

Report Matched Traffic—When Enabled, enforcement events captured by this rule are reported periodically to Cortex XSIAM and displayed in
the Host Firewall Events table, whether the rule is set to Allow or Block the traffic. When Disabled, the rule is applied but enforcement events
are not reported periodically.

b. Save rule.

After you fill-in all the details, you need to save the rule. If you know you need to create a similar rule, click Create another to save this rule and
leave the specified parameters available for edit for the next rule. Otherwise, to save the rule and exit, click Create.

4. Prioritize rules.

The rules within the group are enforced by priority from top to bottom. By default, every new rule is added to the top of the already existing rules in the
group, meaning it is assigned the highest priority and will be enforced first. To change the rules priority and order of enforcement within the group, click the
rule priority number and drag the rule up or down the table to the proper row. Repeat this process to prioritize all the rules.

5. Save.

When you are done, click Create. The new rules group is created and can be associated with a host firewall profile.

Manage Rules Groups

Abstract

How to manage rules groups.

After you create a group, you can perform additional actions. From Endpoints → Host Firewall → Host Firewall Rules Groups, click a group:

View group data—From the Host Firewall Rules Groups table you can view details about all the existing rules groups in your organization. The table lists
high level information about the group such as name, mode, and number of rules included. To view all rules within a group and all the profiles the group is
associated with, click the expand icon.

Edit group—Right-click the group and Edit its settings.

Delete/Disable—To stop enforcing the rules within this group, right-click the group and Delete/Disable it. On the next heartbeat, its rule will be
removed/disabled from all profiles this group is associated with.

Import/Export group rules—Using a JSON file, you can import rules into the Cortex XSIAM host firewall or export them. Right-click the rule and
Import/Export.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 176/1003
5/8/24, 9:18 AM PDF Export

Manage Rules

Abstract

How to manage endpoint host firewall rules.

After you create a host firewall rule and assign it to a rules group, you can manage the rule settings and enforcement as follows.

View/Edit—Right-click the rule to view it or edit its parameters.

Change priority—Change the rule priority within the group by dragging its row up and down the rules list.

Delete/Disable—To stop enforcing the rule, you can right-click the rule and Delete/Disable it. On the next heartbeat, the rule will be removed/disabled in
all profiles where this rules group is included.

Create a Host Firewall Profile

Abstract

How to create a host firewall profile.

Configure host firewall profiles that contain one or more rules groups. The groups are enforced according to their order of appearance within the profile, from top
to bottom (and within each group, the rules are also enforced from top to bottom). You can also configure profiles based on the device location within your
internal network. When you edit, re-prioritize, disable, or delete a rules group from a profile, the change takes effect on the next heartbeat in all policies where
this profile is included.

1. Create a profile.

From Endpoints → Policy Management → Extensions and select + Add Profile or Import from File.

2. Select the platform and click Host Firewall → Next.

3. Fill-in General Information.

Enter the profile name and optional description.

4. Configure Report Settings.

When the profile operates in report mode, Cortex XSIAM overrides all rules set to Block traffic. Instead, the traffic is allowed to go through, and the
enforcement event is reported as Override Block. You can configure a profile in report mode if you need for example to test new block rules before you
actually apply them.

5. Configure Internal and External Rule Groups.

To apply location based host firewall rules, you must first enable network location configuration in your Agent Settings Profile. When enabled, Cortex
XSIAM enforces the host firewall rules based on the current location of the device within the internal organization network (Internal Rules), enabling you
for example to enforce more strict rules when the device is outside the office and in a public place (External Rules). If you disable the Location Based
option, your policy will apply the internal set of rules only, and that will be applied to the device regardless of its location.

Create a New Rule or add a rules group to the Internal/External Groups:

a. Click +Add Group.

b. Select one or more groups, and click Add.

To quickly apply the exact same rules in both cases, select Add as external/internal rules groups as well.

c. Review the rule group field details.

The groups are listed according to the order of enforcement from top to bottom. To change this order, click on the group priority number and drag
the group to the desired row.

Field Description

Applicable Rules Count Displays the number of rules in the specific group that are associated
with the platform profile.

Created by Displays the email address of the user that created the rule.

Creation Time Date and time of when the rule was created.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 177/1003
5/8/24, 9:18 AM PDF Export

Field Description

Description Description of the rule, if available.

Group ID Unique rules group ID.

Group Name Name of the group rules group.

Mode Displays whether the rules group is enabled or not.

Modified by Displays the email address of the last user that made changes to the
group.

Modification Time Date and time of when the group was modified.

d. (Optional) Select View Rules to view a list of all the rule details within the rules group. The table is filtered according to the rules associated with the
platform profile you are creating.

e. Allow or Block the Default Action for Inbound/Outbound Traffic in the profile if you want to allow all network connections that have not been matched
to any other rule in the profile.

6. Save the profile.

When you are done, click Create. You can now configure a host firewall policy.

Manage Policy Rules

Abstract

How to manage policy rules.

After you create the host firewall extensions profile, you can perform additional actions. The changes take effect on the next heartbeat. From Endpoints → Policy
Management → Extensions → Policy Rules, right-click to:

Edit— Change the profile settings and Save. The change takes effect in all policies enforcing this profile.

Delete—The profile is deleted from all policies it was associated with, while the rules groups are not deleted and are still available in Cortex XSIAM.

Save As New—Duplicate the profile, edit, and save as new.

Export Profile—Select one or more policies, right-click and select Export Policies. You can choose to include the associated Policy Targets, Global
Exceptions, and endpoint groups.

Create a Host Firewall Policy

Abstract

How to create a host firewall policy.

After you define the required host firewall profiles, configure host firewall policies that will be enforced on your target endpoints. You can associate the profile
with an existing policy, or create a new one.

1. Create a policy.

From Endpoints → Policy Management → Extensions → Policy Rules, click +New Policy or Import from File.

NOTE:

When importing a policy, select whether to enable the associated policy targets. Rules within the imported policy are managed as follows.

New rules are added to the top of the list.

Default rules override the default rule in the target tenant.

Rules without a defined target are disabled until target is specified.

2. Fill-in general information.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 178/1003
5/8/24, 9:18 AM PDF Export

Enter the policy name, description, and platform. Click Next.

3. Select profile.

Select the desired profile for host firewall from the drop-down list, and any other profiles you want to include in this policy. Click Next.

4. Select endpoints.

Select the target endpoints on which to enforce the policy. Use filters or manual endpoint selection to define the exact target endpoints of the policy. Click
Done.

5. Configure policy hierarchy.

Drag and drop the policies in the desired order of execution, from top to bottom.

6. Save the policy.

After the policy is saved and applied to the agents, Cortex XSIAM enforces the host firewall policies in your environment.

Monitor Host Firewall Activity in Your Network

Abstract

How to monitor host firewall activity in your network.

The Host Firewall Events table provides an aggregated view of the host firewall enforcement events in your network. An enforcement event represents the
number of rule hits per endpoint in 60 minutes.

NOTE:

The data is aggregated and reported periodically every 60 minutes since the first time the host firewall policy was enforced on the endpoint, not every
round hour.

The table lists enforcement events only for rules set to Report Matching Traffic.

Every enforcement event includes additional data such as the time of the first rule hit, the rule action, protocol, and more.

Collect Detailed Log Files

To gain deeper visibility into all the host firewall activity that occurred on an endpoint, you can retrieve a log file listing all single actions the agent performed for
all rules (whether set to Report Matched Traffic or not). The logs are stored in a cyclic 50MB file on the endpoint, which is constantly being re-written and
overridden older logs. When you upload the file, the logs are loaded to the Host Firewall Events table. You can filter the table using the Event Source field to
view only the aggregated periodic logs, or only non-aggregated on-demand logs.

To collect the log file, right-click the event containing the endpoint you are interested in and select Collect Detailed Host Firewall Logs. Alternatively, you can
perform this action for multiple endpoints from Endpoints Administration.

3.10.2.2 | Host Firewall for macOS

Abstract

Control communications on your endpoints based on the network location of your device by using the host firewall.

The Cortex XSIAM host firewall enables you to control communications on your endpoints. To use the host firewall, you set rules that allow or block the traffic on
the devices and apply them to your endpoints using Cortex XSIAM host firewall policy rules. Additionally, you can configure different sets of rules based on the
current location of your endpoints - within or outside your organization network. The Cortex XSIAM host firewall rules leverage the operating system firewall APIs
and enforce these rules on your endpoints, but not your Windows or Mac firewall settings.

To configure the Cortex XSIAM host firewall in your network, follow this high-level workflow. Ensure you meet the host firewall requirements.

Enable Network Location Configuration

If you want to apply location based host firewall rules, you must first enable network location configuration in your Agent Settings Profile. On every heartbeat,
and if the Cortex XDR agent detects a network change on the endpoint, the agent triggers the device location test and re-calculates the policy according to the
new location.

Add a New Host Firewall Profile

Configure host firewall profiles that contain one or more rules groups. The groups are enforced according to their order of appearance within the profile, from top
to bottom (and within each group, the rules are also enforced from top to bottom). You can also configure profiles based on the device location within your
internal network. When you edit, re-prioritize, disable, or delete a rules group from a profile, the change takes effect on the next heartbeat in all policies where
this profile is included.

Rules created on macOS 10 and Cortex XDR agent 7.5 and prior are managed only in the Legacy Host Firewall Rules and do not appear in the Rule Groups
tables.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 179/1003
5/8/24, 9:18 AM PDF Export

1. From Endpoints → Policy Management → Extensions Profiles → Profiles, select + New Profile or Import from File. Select the Platform and click Host
Firewall → Next.

2. Fill-in the General Information for the new profile.

Assign a Profile Name and optional description to the profile.

3. Define your Report Settings.

When the profile operates in report mode, Cortex XSIAM overrides all rules set to Block traffic. Instead, the traffic is allowed to go through, and the
enforcement event is reported as Override Block. You can configure a profile in report mode if you need for example to test new block rules before you
actually apply them.

4. Configure Internal and External Rule Groups.

To apply location based host firewall rules, you must first enable network location configuration in your . When enabled, Cortex XSIAM enforces the host
firewall rules based on the current location of the device within the internal organization network (Internal Rules), enabling you for example to enforce
more strict rules when the device is outside the office and in a public place (External Rules). If you disable the Location Based option, your policy will
apply the internal set of rules only, and that will be applied to the device regardless of its location.

Create a New Rule or add a rules group to the Internal/External Groups.

a. Click +Add Group.

b. Select one or more groups, and click Add.

To quickly apply the exact same rules in both cases, select Add as external/internal rules groups as well.

c. Review the rule group field details.

The groups are listed according to the order of enforcement from top to bottom. To change this order, click on the group priority number and drag
the group to the desired row.

Field Description

Applicable Rules Count Displays the number of rules in the specific group that are associated
with the platform profile.

Created by Displays the email address of the user that created the rule.

Creation Time Date and time of when the rule was created.

Description Description of the rule, if available.

Group ID Unique rules group ID.

Group Name Name of the group rules group.

Mode Displays whether the rules group is enabled or not.

Modified by Displays the email address of the last user that made changes to the
group.

Modification Time Date and time of when the group was modified.

d. (Optional) Select View Rules to view a list of all the rule details within the rules group. The table is filtered according to the rules associated with the
platform profile you are creating.

Any type protocol and specific ports cannot be edited. If saved as a new rule, the specific ports previously defined are removed from the cloned rule.

e. Allow or Block the Default Action for Inbound/Outbound Traffic in the profile if you want to allow all network connections that have not been matched
to any other rule in the profile.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 180/1003
5/8/24, 9:18 AM PDF Export

5. (Optional) Manage Legacy Host Firewall Rules.

Manage Host Firewall Rules created on macOS 10 and Cortex XDR agent 7.5 and prior.

a. Enable Manage Host Firewall to allow Cortex XSIAM to manage the host firewall on your Mac endpoints.

b. Configure the host firewall Internal and External settings.

The host firewall settings allow or block inbound communication on your Mac endpoints. Enable or Disable the following actions:

Stealth Mode—Hide your mac endpoint from all TCP and UDP networks by enabling the Apple Stealth mode on your endpoint.

Block All Incoming Connections—Select where to block all incoming communications on the endpoint or not.

Application Exclusions—Allow or block specific programs running on the endpoint using a Bundle ID.

If the profile is location based, you can define both internal and external settings.

6. Save your profile.

When you’re done, Create your host firewall profile.

7. Apply Host Firewall Profiles to Your Endpoints.

Apply Host Firewall Profiles to Your Endpoints

After you define the required host firewall profiles, configure the Protection Policies and enforce them on your endpoints. Cortex XSIAM applies Protection
policies on endpoints from top to bottom, as you’ve ordered them on the page. The first policy that matches the endpoint is applied. If no policies match, the
default policy that enables all communication to and from the endpoint is applied.

1. From Endpoints → Policy Management → Extensions → Policy Rules, select +New Policy or Import from File.

NOTE:

When importing a policy, select whether to enable the associated policy targets. Rules within the imported policy are managed as follows:

New rules are added to the top of the list.

Default rules override the default rule in the target tenant.

Rules without a defined target are disabled until the target is specified.

2. Configure settings for the host firewall policy.

a. Assign policy name, an optional description, and operating system.

b. Assign the host firewall profile you want to use in this rule.

c. Click Next.

d. Select the target endpoints on which to enforce the policy.

Use filters or manual endpoint selection to define the exact target endpoints of the policy rules.

e. Click Done.

Alternatively, you can associate the host firewall profile with an existing policy. Right-click the policy and select Edit. Select the Host Firewall profile and
click Next. If needed, you can edit other settings in the rule, such as target endpoints and description. When you’re done, click Done.

3. Configure policy hierarchy.

Drag and drop the policies in the desired order of execution.

4. Save the policy hierarchy.

After the policy is saved and applied to the agents, Cortex XSIAM enforces the host firewall policies on your environment.

Monitor the Host Firewall Activity on your Endpoint

To view only the communication events on the endpoint to which the Cortex XSIAM host firewall rules were applied, you can run the Cytool firewall show
command.

Additionally, to monitor the communication on your macOS endpoint, you can use the following operating system utilities: From the endpoint System
Preferences → Security and Privacy → Firewall → Firewall options, you can view the list of blocked and allowed applications in the firewall. The Cortex XSIAM
host firewall blocks only incoming communications on Mac endpoints, still allowing outbound communication initiated from the endpoint.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 181/1003
5/8/24, 9:18 AM PDF Export

3.10.3 | Disk Encryption

Abstract

For enhanced security, you can configure and apply disk encryption profiles to the disks of your Windows and Mac endpoints.

Cortex XSIAM provides full visibility into encrypted Windows and Mac endpoints that were encrypted using BitLocker and FileVault, respectively. Additionally,
you can apply Cortex XSIAM Disk Encryption rule on the endpoints by creating disk encryption rules and policies that leverage BitLocker and FileVault
capabilities.

Before you start applying disk encryption policy rules, ensure you meet the following requirements and refer to these known limitations:

Requirement / Limitation Windows Mac

Endpoint Pre-requisites The endpoint must be running a Microsoft The endpoint must be running a macOS
Windows version that supports BitLocker. version that supports FileVault.

The endpoint must be within the The endpoint must be running a Cortex
organization's network domain. XDR agent 7.2 or later.

The endpoint must be running a Cortex

XDR agent 7.1 or later.

To allow the agent to encrypt the endpoint,

Trusted Platform Module (TPM) must be
supported and enabled on the endpoint.

Active Directory Domain Services is

required for recovery key backup.

Disk Encryption Scope You can enforce XDR disk encryption policy rules You can enforce XDR disk encryption
only on the Operating System volume. policy rules only on the Operating System
volume.

The Cortex XSIAM Disk Encryption profile

for Mac can encrypt the endpoint disk,
however, it cannot decrypt it. After you
disable the Cortex XSIAM policy rule on
the endpoint, you can decrypt the endpoint
manually.

Other Group Policy configuration: Provide a FileVaultMaster certificate /

institutional recovery key (IRK) that is
Make sure the GPO configuration applying signed by a valid authority.
to the endpoint enables Save BitLocker
recovery information to AD DS for It can take the agent up to 5 minutes to
operating system drives. report the disk encryption status to Cortex
XSIAM if the endpoint was encrypted
Make sure your Cortex XSIAM disk through Cortex XSIAM, and up to one hour
encryption policy does not conflict with the if it was encrypted through another MDM.
GPO configuration to Choose drive
encryption method and cipher strength. In line with the operating system
requirements, the Cortex XSIAM
encryption profile will take place on the
endpoint after the user logs off and back
on, and approves the prompt to enable the
endpoint encryption.

Palo Alto Networks recommends that you

do not apply an encryption enforcement
from another MDM on the endpoint
together with the Cortex XSIAM encryption
profile.

Follow this high-level workflow to deploy the Cortex XSIAM disk encryption in your network:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 182/1003
5/8/24, 9:18 AM PDF Export

Monitor the Endpoint Encryption Status

You can monitor the Encryption Status of an endpoint in the Endpoints → Disk Encryption Visibility table. For each endpoint, the table lists both system and
custom drives that were encrypted.

The following table describes both the default and additional optional fields that you can view in the Disk Encryption Visibility table per endpoint. The fields are in
alphabetical order.

Field Description

Encryption Status The endpoint encryption status can be:

Applying Policy—Indicates that the Cortex XSIAM disk encryption

policy is in the process of being applied on the endpoint.

Compliant—Indicates that the Cortex XDR agent encryption status

on the endpoint is compliant with the Cortex XSIAM disk encryption
policy.

Not Compliant—Indicates that the Cortex XDR agent encryption

status on the endpoint is not compliant with the Cortex XSIAM disk
encryption policy.

Not Configured—Indicates that no disk encryption rules are

configured on the endpoint.

Not Supported—Indicates that the operating system running on the

endpoint is not supported by Cortex XSIAM.

Unmanaged—Indicates that the endpoint encryption is not managed

by Cortex XSIAM.

Endpoint ID Unique ID assigned by Cortex XSIAM that identifies the endpoint.

Endpoint Name Hostname of the endpoint.

Endpoint Status The status of the endpoint. For more details, see Endpoints Table.

IP Address Last known IPv4 or IPv6 address of the endpoint.

Last Reported Date and time of the last change in the agent’s status. For more details, see
Endpoints Table.

MAC Address The MAC address of the endpoint.

Operating System The platform running on the endpoint.

OS Version Name of the operating system version running on the endpoint.

Volume Status Lists all the disks on the endpoint along with the status per volume,
Decrypted or Encrypted. For Windows endpoints, Cortex XSIAM includes
the encryption method.

You can also monitor the endpoint Encryption Status in your Endpoint Administration table.

Configure a Disk Encryption Profile

1. Under Endpoints → Policy Management → Extensions → Profiles, select + New Profile or Import from File. Choose the Platform and select Disk
Encryption. Click Next.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 183/1003
5/8/24, 9:18 AM PDF Export

2. Fill-in the general information for the new profile.

Assign a name and an optional description to the profile.

3. Enable disk encryption.

To enable the Cortex XDR agent to apply disk encryption rules using the operating system disk encryption capabilities, Enable the Use disk encryption
option.

4. Configure Encryption details.

For Windows:

Encrypt or decrypt the system drives.

Encrypt the entire disk or only the used disk space.

For Mac:

Inline with the operating system requirements, when the Cortex XDR agent attempts to enforce an encryption profile on an endpoint, the endpoint
user is required to enter the login password. Limit the number of login attempts to one or three. Otherwise, if you do not force log in attempts, the
user can continuously dismiss the operating system pop-up and the Cortex XDR agent will never encrypt the endpoint.

5. (Windows only) Specify the Encryption methods per operating system.

For each operating system (Windows 7, Windows 8-10, Windows 10 (1511), and above), select the encryption method from the corresponding list.

NOTE:

You must select the same encryption method configured by the Microsoft Windows Group Policy in your organization for the target endpoints.
Otherwise, if you select a different encryption method than the one already applied through the Windows Group Policy, Cortex XSIAM displays errors.

6. (Mac only) Upload the FileVaultMaster certificate.

To enable the Cortex XDR agent to encrypt your endpoint, or to help users who forgot their password to decrypt the endpoint, you must upload to Cortex
XSIAM the FileVaultMaster certificate / institutional recovery key (IRK). You must ensure the key is signed by a valid authority and upload a CER file only.

7. Save your profile.

When you’re done, Create your disk encryption profile.

8. Apply Disk Encryption Profile to Your Endpoints.

Apply Disk Encryption Profile to Your Endpoints

After you define the required disk encryption profiles, configure Protection Policies and enforce them on your endpoints. Cortex XSIAM applies Protection
policies on endpoints from top to bottom, as you’ve ordered them on the page. The first policy that matches the endpoint is applied. If no policies match, the
default policy that enables all communication to and from the endpoint is applied.

1. Under Endpoints → Policy Management → Extensions → Policy Rules, select +New policy or Import from File.

NOTE:

When importing a policy, select whether to enable the associated policy targets. Rules within the imported policy are managed as follows:

New rules are added to the top of the list.

Default rules override the default rule in the target tenant.

Rules without a defined target are disabled until the target is specified.

2. Configure settings for the disk encryption policy.

a. Assign a policy name and optional description.

The platform will automatically be assigned to Windows.

b. Assign the disk encryption profile you want to use in this rule.

c. Click Next.

d. Select the target endpoints on which to enforce the policy.

Use filters or manual endpoint selection to define the exact target endpoints of the policy rules. If exists, the Group Name is filtered according to the
groups within your defined user scope.

e. Click Done.

Alternatively, you can associate the disk encryption profile with an existing policy. Right-click the policy and select Edit. Select the Disk Encryption profile
and click Next. If needed, you can edit other settings in the rule, such as target endpoints and description. When you’re done, click Done.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 184/1003
5/8/24, 9:18 AM PDF Export

3. Configure policy hierarchy.

Drag and drop the policies in the desired order of execution.

4. Save the policy hierarchy.

After the policy is saved and applied to the agents, Cortex XSIAM enforces the disk encryption policies on your environment.

5. Select one or more policies, right-click and select Export Policies. You can choose to include the associated Policy Targets, Global Exceptions, and
endpoint groups.

6. Monitor the Endpoint Encryption Status.

3.10.4 | Host Inventory

Abstract

Cortex XSIAM enables you to review the inventory of all your hosts (endpoints), and identify in the inventory any IT and security issues in your network.

With Host Inventory, you gain full visibility and inventory into the business and IT operational data on all your endpoints. By reviewing the inventory for all your
hosts in a single place, you can quickly identify IT and security issues that exist in your network, such as identifying a suspicious service or autorun that was
added to an endpoint.

The Cortex XDR agent scans the endpoint every 24 hours for any updates and displays the data found over the last 30 days. Alternatively, you can rescan the
endpoint to retrieve the most updated data. It can take Cortex XSIAM up to 6 hours to collect initial data from all endpoints in your network.

The following are prerequisites to enable Host Inventory for your Cortex XSIAM instance:

Requirement Description

Licenses and Add-ons Cortex XDR Pro per Endpoint license.

Host Insights Add-on.

Supported Platforms Windows, Mac, and Linux

Setup and Permissions Ensure Host Inventory Data Collection is enabled for your Cortex XDR agent.

The Cortex XSIAM Host inventory includes the following entities and information, according to the operating system running on the endpoint:

Entity Windows Mac Linux

Accessibility — —

Applications

Autoruns

Daemons —

Disks

Drivers —

Extensions — —

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 185/1003
5/8/24, 9:18 AM PDF Export

Entity Windows Mac Linux

Groups

Mounts —

Services — —

Shares

System Information

Users

Users to Groups

For each entity, Cortex XSIAM lists all the details about the entity, and the details about the endpoint it applies to. For example, the default Services view lists a
separate row for every service on every endpoint:

Alternatively, to better understand the overall presence of each entity on the total number of endpoints, you can switch to aggregated view (click ) and group
the data by the main entity. You can also sort and filter according to the number of affected endpoints. For example, in the Services aggregated view, you can
sort by the number of affected endpoints to identify the least commonly deployed service in your network. To get a closer view of all endpoints, right-click and
select View affected endpoints:

View Host Inventory

To view the Host inventory, go to Incident Response → Investigation → Host Inventory. You can export the tables and respective asset views to a tab-separated
values (TSV) file.

Data Description

Accessibility Details about installed applications that require and were allowed special permissions to enable a camera,
microphone, accessibility features, full disk access, or screen captures.

Applications Details about all applications installed on your endpoints.

For each application, Cortex XSIAM lists the existing CVEs and the vulnerability severity score that reflects the
highest NIST vulnerability score detected for the application.

To further examine these vulnerabilities, see Application Analysis.

Autoruns Details about executables that start automatically when the user logs in or boots the endpoint.

Cortex XSIAM displays information about autoruns that are configured in the endpoint Registry, startup folders,
scheduled tasks, services, drivers, daemons, extensions, Crond tasks, login items, login, and logout hooks.

For each autorun, Cortex XSIAM lists the autorun type and configuration, such as startup method, CMD, user details,
and image path.

Daemons Details about all daemons that exist on the endpoint.

For each daemon, Cortex XSIAM lists the following details.

Information about the daemon, such as the name, type, and path.

Daemon state, indicating whether it is loaded, running, or not running.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 186/1003
5/8/24, 9:18 AM PDF Export

Data Description

Disks Details about the disk volumes that exist on an endpoint.

For each disk that exists on an endpoint, Cortex XSIAM lists details such as the drive type, name, file system, free
space, and total size.

Drivers Details about all the drivers installed on an endpoint.

For each driver, Cortex XSIAM lists all the following details:

Information about the driver, such as the driver name, type, and path.

Listing details about the driver runtime configuration:

The driver type

Whether the driver is currently running, in which mode, and the runtime state

Extensions Details about the system and kernel extensions currently running on your Mac endpoints.

For each extension, Cortex XSIAM lists the following details:

Extension type, name, path, and version.

Extension state, indicating whether it is running, requires enabling, or unloaded.

Groups Details about all user groups defined on an endpoint.

For each group, Cortex XSIAM lists identifying details, such as name, SID/GID name, and type.

Mounts Details about all the drives, volumes, and disks that were mounted on endpoints.

For each mount, Cortex XSIAM lists the mount point directory, file system type, mount spec, and GUID.

Services Details about all the services running on an endpoint.

For each service, Cortex XSIAM lists all the following details:

Information about the service, such as the service name, type, and path.

Listing details about the service runtime configuration and status:

Whether the service is currently running and what is the runtime state

Whether you can stop, pause, or delay the service start time

Whether the service requires interaction with the endpoint desktop

The name of the user who started the service and the start mode

Shares Details about network shared folders defined on an endpoint.

For each folder, Cortex XSIAM lists all the following details:

Shared network folder type: Disk Drive, Print Queue, Device, IPC, Disk Drive Admin, Print Queue Admin,
Device Admin, IPC Admin.

Identifying details such as folder name, description, and path.

Whether the folder is limited to a maximum number of shares, and the maximum number of allowed shares.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 187/1003
5/8/24, 9:18 AM PDF Export

Data Description

System Information General system information about an endpoint.

For each endpoint, Cortex XSIAM lists all the following details:

Information about the endpoint hardware, such as manufacturer, model, physical memory, processor
architecture, and CPU.

The operating system name and release running on the endpoint.

Users List of users whose credentials are stored on the endpoint.

For each user, Cortex XSIAM lists all the following details.

Identifying details about the user, such as name and SID/UID.

Details about the account, such as whether the account is active and the account type.

Information about the password set for this user account, such as whether it is required to login, has an
expiration date or can be changed.

Users to Groups A list mapping all the users, local and in your domain, to the existing user groups on an endpoint.

NOTE:

Cortex XSIAM includes only the first 10,000 results per endpoint.

Cortex XSIAM lists only users that belong to each group directly, and does not include users who belong to a
group within the main group.

If a local users group includes a domain user (whose credentials are stored on the Domain Controller server
and not on the endpoint), Cortex XSIAM includes this user in the user-to-group mapping, but does not include
it in the user's insights view.

3.10.5 | Vulnerability Assessment

Abstract

Perform a vulnerability assessment of all endpoints in your network using Cortex XSIAM. This includes CVE, endpoint, and application analysis.

Cortex XSIAM vulnerability assessment enables you to identify and quantify the security vulnerabilities on an endpoint. After evaluating the risks to which each
endpoint is exposed and the vulnerability status of an installed application in your network, you can mitigate and patch these vulnerabilities on all the endpoints
in your organization.

Legacy Vulnerability Assessment

For a comprehensive understanding of the vulnerability severity, Cortex XSIAM retrieves the latest data for each Common Vulnerabilities and Exposures (CVE)
from the NIST National Vulnerability Database, including CVE severity and metrics.

PREREQUISITE:

The following are prerequisites for Cortex XSIAM to perform a vulnerability assessment of your endpoints.

Requirement Description

Licenses and Add-ons Host Insights Add-on.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 188/1003
5/8/24, 9:18 AM PDF Export

Requirement Description

Supported Platforms Windows

Cortex XDR agent 7.1 or a later release.

Cortex XSIAM lists only CVEs relating to the operating system, and not CVEs
relating to applications provided by other vendors.

Cortex XSIAM retrieves the latest data for each CVE from the NIST National
Vulnerability Database as well as from the Microsoft Security Response Center
(MSRC).

Cortex XSIAM collects KB and application information from the agents but
calculates CVE only for KBs based on the data collected from MSRC and other
sources

For endpoints running Windows Insider, Cortex XSIAM cannot guarantee an

accurate CVE assessment.

Cortex XSIAM does not display open CVEs for endpoints running Windows
releases for which Microsoft no longer fixes CVEs.

Linux

Cortex XDR agent 7.1 or a later release.

Cortex XSIAM collects all the information about the operating system and the installed
applications, and calculates CVE based on the the latest data retrieved from the NIST.

MacOS

Cortex XDR agent 7.1 or a later release.

Cortex XSIAM collects only the applications list from MacOS without CVE
calculation.

If Cortex XSIAM doesn't match any CVE to its corresponding application, an error message is
displayed, "No CVEs Found".

Setup and Permissions Ensure Host Inventory Data Collection is enabled for your Cortex XDR agent.

Limitations Cortex XSIAM calculates CVEs for applications according to the application version, and not
according to application build numbers.

Enhanced Vulnerability Assessment

The Enhanced Vulnerability Assessment mode uses an advanced algorithm to collect extensive details on CVEs from comprehensive databases and to produce
an in-depth analysis of the endpoint vulnerabilities. Turn on the Enhanced Vulnerability Assessment mode from Settings → Configurations → Vulnerability
Assessment. This option may be disabled for the first few days after updating Cortex XSIAM as the Enhanced Vulnerability Assessment engine is initialized.

PREREQUISITE:

The following are prerequisites for Cortex XSIAM to perform an Enhanced Vulnerability Assessment of your endpoints.

Requirement Description

Licenses and Add-ons Host Insights Add-on.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 189/1003
5/8/24, 9:18 AM PDF Export

Requirement Description

Supported Platforms Windows

Cortex XDR agent 8.3 or a later release.

Cortex XSIAM collects all the information about the operating system and the
installed applications, and calculates CVE based on the latest data retrieved from
the NIST.

CVEs that apply to applications that are installed by one user aren't detected when
another user without the application installed is logged in during the scan.

MacOS

Cortex XDR agent 8.3 or a later release.

Cortex XSIAM collects all the information about the operating system and the
installed applications, and calculates CVE based on the latest data retrieved from
the NIST.

Setup and Permissions Ensure Host Inventory Data Collection is enabled for your Cortex XDR agent.

Limitations Some CVEs may be outdated if the Cortex XDR agent wasn't updated recently.

Application versions which have reached end-of-life (EOL) may have their version listed
as 0. This doesn't affect the detection of the CVEs.

Some applications are listed twice. One of the instances may display invalid version,
however, this doesn't affect the functionality.

The scanning process may impact performance on the Cortex XDR agent during
scanning. The scan may take up to two minutes.

You can access the Vulnerability Assessment panel from Assets → Vulnerability Assessment.

Collecting the initial data from all endpoints in your network could take up to 6 hours. After that, Cortex XSIAM initiates periodical recalculations to rescan the
endpoints and retrieve the updated data. If at any point you want to force data recalculation, click Recalculate. The recalculation performed by any user on a
tenant updates the list displayed to every user on the same tenant.

CVE Analysis

To evaluate the extent and severity of each CVE across your endpoints, you can drill down into each CVE in Cortex XSIAM and view all the endpoints and
applications in your environment that are impacted by the CVE. Cortex XSIAM retrieves the latest information from the NIST public database. From Assets →
Host Insights → Vulnerability Assessment, select CVEs on the upper-right bar. This information is also available in the va_cves dataset, which you can use to
build queries in XQL Search.

If you have the Identity Threat Module enabled, you can also view the CVE analysis in the Host Risk View. To do so, from Assets → Asset Scores, select
the Hosts tab, right click on any endpoint, and select Open Host Risk View.

For each vulnerability, Cortex XSIAM displays the following default and optional values.

Value Description

Affected endpoints The number of endpoints that are currently affected by this CVE. For
excluded CVEs, the affected endpoints are N/A.

Applications The names of the applications affected by this CVE.

CVE The name of the CVE.

TIP:

You can click each individual CVE to view in-depth details about it on a
panel that appears on the right.

Description The general NIST description of the CVE.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 190/1003
5/8/24, 9:18 AM PDF Export

Value Description

Excluded Indicates whether this CVE is excluded from all endpoint and application
views and filters, and from all Host Insights widgets.

Platforms The name and version of the operating system affected by this CVE.

Severity The severity level (Critical, High, Medium, or Low) of the CVE as ranked in
the NIST database.

Severity score The CVE severity score is based on the NIST Common Vulnerability Scoring
System (CVSS). Click the score to see the full CVSS description.

You can perform the following actions from Cortex XSIAM as you analyze the existing vulnerabilities:

View CVE details—Left-click the CVE to view in-depth details about it on a panel that appears on the right. Use the in-panel links as needed.

View a complete list of all endpoints in your network that are impacted by a CVE—Right-click the CVE and then select View affected endpoints.

Learn more about the applications in your network that are impacted by a CVE—Right-click the CVE and then select View applications.

Exclude irrelevant CVEs from your endpoints and applications analysis—Right-click the CVE and then select Exclude. You can add a comment if
needed, as well as Report CVE as incorrect for further analysis and investigation by Palo Alto Networks. The CVE is grayed out and labeled Excluded and
no longer appears on the Endpoints and Applications views in Vulnerability Assessment, or in the Host Insights widgets. To restore the CVE, you can right-
click the CVE and Undo exclusion at any time.

NOTE:

The CVE will be removed/reinstated to all views, filters, and widgets after the next vulnerability recalculation.

Endpoint Analysis

To help you assess the vulnerability status of an endpoint, Cortex XSIAM provides a full list of all installed applications and existing CVEs per endpoint and also
assigns each endpoint a vulnerability severity score that reflects the highest NIST vulnerability score detected on the endpoint. This information helps you to
determine the best course of action for remediating each endpoint. From Assets → Vulnerability Assessment, select Endpoints on the upper-right bar. This
information is also available in the va_endpoints dataset. In addition, the host_inventory_endpoints preset lists all endpoints, CVE data, and additional metadata
regarding the endpoint information. You can use this dataset and preset to build queries in XQL Search.

For each vulnerability, Cortex XDR displays the following default and optional values.

Value Description

CVEs A list of all CVEs that exist on applications that are installed on the endpoint.

Endpoint ID Unique ID assigned by Cortex XSIAM that identifies the endpoint.

Endpoint name Hostname of the endpoint.

TIP:

You can click each individual endpoint to view in-depth details about it on
a panel that appears on the right.

Last Reported Timestamp The date and time of the last time the Cortex XDR agent started the process
of reporting its application inventory to Cortex XSIAM.

MAC address The MAC address associated with the endpoint.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 191/1003
5/8/24, 9:18 AM PDF Export

Value Description

IP address The IP address associated with the endpoint.

Platform The name of the platform running on the endpoint.

Severity The severity level (Critical, High, Medium, or Low) of the CVE as ranked in
the NIST database.

Severity score The CVE severity score based on the NIST Common Vulnerability Scoring
System (CVSS). Click the score to see the full CVSS description.

You can perform the following actions from Cortex XSIAM as you investigate and remediate your endpoints:

View endpoint details—Left-click the endpoint to view in-depth details about it on a panel that appears on the right. Use the in-panel links as needed.

View a complete list of all applications installed on an endpoint—Right-click the endpoint and then select View installed applications. This list
includes the application name, version, and installation path on the endpoint. If an installed application has known vulnerabilities, Cortex XSIAM also
displays the list of CVEs and the highest Severity.

(Windows only) Isolate an endpoint from your network—Right-click the endpoint and then select Isolate the endpoint before or during your remediation
to allow the Cortex XSIAM agent to communicate only with Cortex XSIAM .

(Windows only) View a complete list of all KBs installed on an endpoint—Right-click the endpoint and then select View installed KBs. This list includes
all the Microsoft Windows patches that were installed on the endpoint and a link to the Microsoft official Knowledge Base (KB) support article. This
information is also available in the host_inventory_kbs preset, which you can use to build queries in XQL Search.

Retrieve an updated list of applications installed on an endpoint—Right-click the endpoint and then select Rescan endpoint.

Application Analysis

You can assess the vulnerability status of applications in your network using the Host inventory. Cortex XSIAM compiles an application inventory of all the
applications installed in your network by collecting from each Cortex XDR agent the list of installed applications. For each application on the list, you can see the
existing CVEs and the vulnerability severity score that reflects the highest NIST vulnerability score detected for the application. Any new application installed on
the endpoint will appear in Cortex XSIAM within 24 hours. Alternatively, you can re-scan the endpoint to retrieve the most updated list.

NOTE:

Starting with macOS 10.15, Mac built-in system applications are not reported by the Cortex XDR agent and are not part of the Cortex XSIAM Application
Inventory.

From Incident Response → Host Inventory, select Applications.

To view the details of all the endpoints in your network on which an application is installed, right-click the application and select View endpoints.

To view in-depth details about the application, left-click the application name.

3.11 | Cortex XDR Agent for Cloud

Abstract

Cortex XDR Agent for Cloud (CSA) is an expanded version of the Cortex XDR Agent that augments Cortex's runtime security and threat protection with Prisma
Cloud's powerful vulnerability and security compliance management capabilities to deliver a complete Cloud Detection and Response solution.

The Prisma cloud vulnerability and compliance scanner is integrated in the Cortex XDR agent to provide a unified agent that gives runtime security including
vulnerability and compliance. To use this functionality, you need a Cloud for Host license and your Cortex XDR tenant must be paired with a Prisma Cloud
Compute tenant. This is done with a one-time pairing encoded key either on the Prisma tenant or on the Cortex XDR tenant. Create an Agent Settings Profile
with Active Vulnerability Analysis set to enabled and add it to the Endpoint Policy.

The vulnerability and compliance scanning is executed by the Cortex XDR agent and is triggered by a schedule that is defined in the Agent Setting Profile, or
when the Cortex XDR agent detects a new asset; image, or container etc.

Cortex XDR Agents that are enabled with Active Vulnerability Analysis, send all their data to the Cortex XDR server. The Prisma-related data found by the
Prisma Scanner, vulnerability and compliance results, with any Cortex security alerts, are subsequently forwarded to the Prisma tenant at the server level and
are displayed only in the corresponding Prisma console screens.

Scanner Result Distribution:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 192/1003
5/8/24, 9:18 AM PDF Export

Cortex XDR security alerts are displayed in both the Cortex XDR and Prisma consoles. Prisma with limited investigation details.

Vulnerabilities and Compliance are displayed only in the Prisma console.

The list of paired Cloud Security Agents are displayed in the Prisma console

All Cortex XDR Agent for Cloud configurations are managed in the Cortex XDR console.

Vulnerability and Compliance scanned by Cortex XDR Agent for Cloud is only displayed in the Prisma Console.

3.11.1 | Pairing Prisma Cloud Compute with Cortex XSIAM

Abstract

Learn how to pair Prisma Cloud Compute with Cortex XSIAM for use with the unified cloud security agent.

Cortex XSIAM and Prisma Cloud Compute are offering a unified cloud security agent for Linux. The Cloud Security Agent provides end to end prevention and
vulnerability coverage on Linux cloud environments.

The Cloud Security Agent has a single management server that is based on a Cortex XSIAM tenant. Policy management, data, and alerts are managed first
between the Cortex XSIAM tenant and the Cloud Security Agent, and then runtime protection and vulnerability coverage can be provided on Prisma Cloud
Compute and Cortex XSIAM.

Prerequisites

To enable the capabilities of the Cloud Security Agent, the Prisma Cloud Compute tenant must be paired with an existing Cortex XSIAM tenant. Pairing is one to
one, with the two tenants being in the same region.

Pairing Prisma Cloud Compute to Cortex XSIAM can only be done when both Cortex XSIAM and Prisma Cloud Compute tenants are already active.

Pair Prisma Cloud Compute with Cortex XSIAM

1. From the Prisma Cloud Compute console, copy the access pairing key.

a. Select Manage → System, and scroll to Pair Cortex XDR Tenant.

b. Click the copy icon to copy the Access Key, which is the pairing key used in Cortex XSIAM.

2. Paste the pairing key in Cortex XSIAM.

a. Select Settings → Configurations → Server Settings, and scroll to Prisma Cloud Compute Tenant Pairing.

b. Paste the Prisma Cloud pairing key and click Pair.

After a few seconds, the Cortex XSIAM and Prisma Cloud Compute tenants are paired.

A Successfully paired with <Prisma Tenant URL> message will be shown.

Unpair Prisma Cloud Compute from Cortex XSIAM

1. The two paired tenants can be unpaired from either

console.

In Cortex XSIAM, select Settings → Configurations → Server Settings, and scroll to Prisma Cloud Compute Tenant Pairing.

In Prisma Cloud Compute, select Manage → System, and scroll to Pair Cortex XDR Tenant.

2. Click Unpair.

NOTE:

Note that all Advanced Vulnerability settings (under the Agent Settings profile) will be reset and all Agent Installations created via the Prisma Cloud
Compute console will be deleted.

3. Confirm the unpairing by clicking Yes at the warning message.

After a few seconds, the Cortex XSIAM and Prisma Cloud Compute tenants are unpaired.

NOTE:

When unpairing, the Active Vulnerability Analysis Module under the Agent Settings profile is reset to Disable mode.

If Prisma Cloud and Cortex XSIAM are to be paired again, the Active Vulnerability Analysis Module must be enabled manually.

4 | Investigation and Response

Abstract

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 193/1003
5/8/24, 9:18 AM PDF Export

Cortex XSIAM provides you with a wide range of investigation and response operations.

Cortex XSIAM provides you with a wide range of investigation and response operations. You can create rules for detecting threats and then investigate and
respond to the malicious activity in your network using different actions.

4.1 | Rules
Abstract

When you identify a threat, you can define specific rules for which you want Cortex XSIAM to raise alerts.

When you identify a threat, you can define specific rules for which you want Cortex XSIAM to raise alerts. You can define the following rules:

Behavioral indicators of compromise (BIOCs)—Identifying threats based on their behaviors can be quite complex. As you identify specific activities
(network, process, file, registry, etc) that indicate a threat, you create BIOCs that can alert you when the behavior is detected. If you enable Cortex XSIAM
- Analytics, Cortex XSIAM can also raise Analytics BIOCs (ABIOCs). Whenever you create or enable a BIOC rule, the rule begins to monitor the stream of
incoming data for any new matches in real-time and analyzes the historical data collected in the Cortex XSIAM tenant. BIOCs can also be used for
prevention in real-time at the agent level using a Restriction Profile. See Working with BIOCs.

Indicators of compromise (IOCs)—Known artifacts that are considered malicious or suspicious. IOCs are static and based on criteria, such as SHA256
hashes, IP addresses and domains, file names, and paths. You create IOC rules based on information that you gather from various threat-intelligence
feeds or that you gather as a result of an investigation within Cortex XSIAM . As soon as you create or enable an IOC rule, the rule begins to monitor the
stream of incoming data for any new matches in real-time and analyzes the historical data collected in the Cortex XSIAM tenant. See Working with IOCs.

Correlation Rules—Help you analyze correlations of multi-events from multiple sources by using the Cortex Query Language (XQL) based engine for
creating scheduled rules called Correlations Rules. When created, Correlation Rules run based on a time interval, as these rules are configured to run
every X min/hours, and on data already in Cortex XSIAM . See Working with Correlation Rules.

After you create an indicator rule, you can Manage Existing Indicators.

4.1.1 | Working with BIOCs

Abstract

Behavioral indicators of compromise (BIOCs) alert you to respond to potentially compromising behaviors.

Behavioral indicators of compromise (BIOCs) enable you to alert and respond to behaviors—tactics, techniques, and procedures. Instead of hashes and other
traditional indicators of compromise, BIOC rules detect behavior such as is related to processes, registry, files, and network activity.

To enable you to take advantage of the latest threat research, the Cortex XSIAM tenant automatically receives pre-configured rules from Palo Alto Networks.
These global rules are delivered to all tenants with content updates. In cases where you need to override a global BIOC rule, you can disable it or set a rule
exception. You can also configure additional BIOC rules as you investigate threats on your network and endpoints. BIOC rules are highly customizable: you can
create a BIOC rule that is simple or quite complex.

As soon as you create or enable a BIOC rule, the tenant begins to monitor input feeds for matches. It also analyzes historical data collected in the tenant.
Whenever there is a match, or hit, on a BIOC rule, Cortex XSIAM logs an alert.

To further enhance the BIOC rule capabilities, you can also configure BIOC rules as custom prevention rules and incorporate them with your Restrictions
profiles. The tenant can then raise behavioral threat prevention alerts based on your custom prevention rules in addition to the BIOC detection alerts.

4.1.1.1 | BIOC Rule Details

Abstract

From the Cortex XSIAM management console, you can define your own rules based on behavior with the behavioral indicator of compromise (BIOC) rules.

If you are assigned a role that enables Investigation → Rules privileges, you can view all user-defined and preconfigured rules for behavioral indicators of
compromise (BIOCs) from Detection & Threat Intel → Detection Rules → BIOC.

If you have Cortex XSIAM - Analytics enabled, Cortex XSIAM also provides a separate page from which you can view Analytics BIOCs (ABIOCs). To access this
page, use the link next to the refresh icon at the top of the page.

Each page displays fields that are relevant to the specific rule type.

BIOC Rule Fields

By default, the BIOC Rules page displays all enabled rules. To search for a specific rule, use the filters above the results table to narrow the results. From the
BIOC Rules page, you can also manage existing rules using the right-click pivot menu.

The following table describes the fields that are available for each BIOC rule in alphabetical order.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 194/1003
5/8/24, 9:18 AM PDF Export

Field Description

# OF HITS The number of hits (matches) on this rule.

BACKWARDS SCAN STATUS Status of the Cortex XSIAM search for the first 10,000 matches when the BIOC
rule was created or edited. Status can be:

Done

Failed

Pending

Queued

BACKWARDS SCAN TIMESTAMP Timestamp of the Cortex XSIAM search for the first 10,000 matches in your
Cortex XSIAM when the BIOC rule was created or edited.

BACKWARDS SCAN RETRIES Number of times Cortex XSIAM searched for the first 10,000 matches in your
Cortex XSIAM when the BIOC rule was created or edited.

BEHAVIOR A schematic of the behavior of the rule.

COMMENT Free-form comments specified when the BIOC was created or modified.

EXCEPTIONS Exceptions to the BIOC rule. When there's a match on the exception, the event
will not trigger an alert.

GLOBAL RULE ID Unique identification number assigned to rules created by Palo Alto Networks.

INSERTION DATE Date and time when the BIOC rule was created.

MITRE ATT&CK TACTIC Displays the type of MITRE ATT&CK tactic the BIOC rule is attempting to trigger
on.

MITRE ATT&CK TECHNIQUE Displays the type of MITRE ATT&CK technique and sub-technique the BIOC rule
is attempting to trigger on.

MODIFICATION DATE Date and time when the BIOC was last modified.

NAME Unique name that describes the rule. Global BIOC rules defined by Palo Alto
Networks are indicated with a blue dot and cannot be modified or deleted.

RULE ID Unique identification number for the rule.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 195/1003
5/8/24, 9:18 AM PDF Export

Field Description

TYPE Type of BIOC rule:

Collection

Credential Access

Dropper

Evasion

Execution

Evasive

Exfiltration

File Privilege Manipulation

File Type Obfuscation

Infiltration

Lateral Movement

Other

Persistence

Privilege Escalation

Reconnaissance

Tampering

SEVERITY BIOC severity that was defined when the BIOC was created.

SOURCE User who created this BIOC, the file name from which it was created, or Palo Alto
Networks if delivered through content updates.

STATUS Enabled

Partially Enabled (Agent Disabled)

Partially Enabled (Server Disabled)

Disabled

When you hover over a rule that's disabled, a pop-up message appears to
provide more information about the Disable action.

USED IN PROFILES Displays if the BIOC rule is associated with a Restriction profile.

Analytics BIOC Fields

By default, the Analytics BIOC Rules page displays all enabled rules. To search for a specific rule, use the filters above the results table to narrow the results.
From the Analytics BIOC Rules page, you can also disable and enable rules using the right-click pivot menu.

The following table describes the fields that are available for each Analytics BIOC rule in alphabetical order.

Field Description

Activation Prerequisites Displays a description of the prerequisites Cortex XSIAM requires in order to
activate the rule.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 196/1003
5/8/24, 9:18 AM PDF Export

Field Description

Description Description of the behavior that will raise the alert.

# OF HITS The number of hits (matches) on this rule.

NAME Unique name that describes the rule. New rules are identified with a blue badge
icon.

Rules associated with Identity Analytics are displayed with an Identity Analytics
tag.

SEVERITY BIOC severity that was defined when the BIOC rule was created. Severity levels
can be Low, Medium, High, Critical, and Multiple.

Multiple severity BIOC rules can raise alerts with different severity levels. Hover
over the flag to see the severities defined for the rule.

STATUS Displays whether the rule is Enabled, Disabled, or Pending Activation.

Rules that are Pending Activation are in the process of collecting the data
required to enable the rule. Hover over the field to view how much data within a
certain period of time has already been collected.

TAGS Filter the results according to Detector Tags. This tag enables you to filter for
specific detectors such as Identity Threat, Identity Analytics, and others.

4.1.1.2 | Create a BIOC Rule

Abstract

You can configure rules for behavioral indicators of compromise (BIOCs) to raise an alert on an identified threat.

After identifying a threat and its characteristics, you can configure rules for behavioral indicators of compromise (BIOCs). After you create a BIOC rule, Cortex
XSIAM searches for the first 10,000 matches in your Cortex XSIAM tenant and raises an alert if a match is detected. Going forward, the app alerts when a new
match is detected.

NOTE:

To ensure your BIOC rules raise alerts efficiently and do not overcrowd your Alerts table, Cortex XSIAM automatically disables BIOC rules that reach 5000 or
more hits over a 24-hour period.

Create a Rule from Scratch

You can create a new BIOC rule in a similar way as you create a search with Query Builder or by building the rule query with XQL Search. In both methods, you
use Cortex Query Language (XQL) to define the rule using XQL syntax. The XQL query must at a minimum filter on the event_type field in order for it to be a
valid BIOC rule. In addition, you can create BIOC rules using the xdr_data and cloud_audit_log datasets and presets for these datasets.

NOTE:

A cloud_audit_log dataset requires a Cortex XDR Pro per GB license.

Currently, you cannot create a BIOC rule on customized datasets and only the filter stage, alter stage, and functions without any aggregations are
supported for XQL queries that define a BIOC.

For BIOC rules, the field values in XQL are evaluated as case insensitive (config case_sensitive = false).

The following is an example of creating a BIOC rule in XQL.

dataset = xdr_data
| filter event_type = PROCESS and
event_sub_type = PROCESS_START and
action_process_image_name ~= ".*?\.(?:pdf|docx)\.exe"

The following describes the event_type values for which you can create a BIOC rule.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 197/1003
5/8/24, 9:18 AM PDF Export

FILE—Events relating to file create, write, read, and rename according to the file name and path.

INJECTION—Events related to process injections.

LOAD_IMAGE—Events relating to module IDs of processes.

NETWORK—Events relating to incoming and outgoing network, filed IP addresses, port, host name, and protocol.

PROCESS—Events relating to execution and injection of a process name, hash, path, and CMD.

REGISTRY—Events relating to registry write, rename and delete according to registry path.

STORY—Events relating to a combination of firewall and endpoint logs over the network.

EVENT_LOG—Events relating to Windows event logs and Linux system authentication logs.

To create a BIOC rule:

1. From Cortex XSIAM , select Detection & Threat Intel → Detection Rules → BIOC.

2. Select + Add BIOC.

3. Configure your BIOC criteria using one of the following methods.

Build the rule query with XQL Search.

1. Click XQL Search.

2. The XQL query field is where you define the parameters of your query for the BIOC rule. To help you create an effective XQL query, the
search field provides suggestions as you type. The XQL query must at a minimum filter on the event_type field in order for it to be a valid
BIOC rule. In addition, you can create BIOC rules using the xdr_data and cloud_audit_log datasets and presets for these datasets.
Currently, you cannot create a BIOC rule on customized datasets and only the filter stage, alter stage, and functions without any
aggregations are supported for XQL queries that define a BIOC. For BIOC rules, the field values in XQL are evaluated as case insensitive
(config case_sensitive = false). After configuring the XQL query for your BIOC rule and the syntax is valid, a indication is
displayed, and it is possible to add the BIOC rule.

3. Click Test BIOC. Rules that you do not refine enough can create thousands of alerts. As a result, it is highly recommended that you test the
behavior of a new or edited BIOC rule before you save it. For example, if a rule will return thousands of hits because you negated a single
parameter, it is a good idea to test the rule before you save it and make it active.

When you test the rule, Cortex XSIAM immediately searches for rule matches across all your Cortex XSIAM tenant data. If there are
surprises, now is the time to see them and adjust the rule definition. The results are displayed in the Query Results tab underneath the XQL
query field.

NOTE:

For the purpose of showing you the expected behavior of the rule before you save it, Cortex XSIAM tests the BIOC on historical logs. After
you save a BIOC rule, it will operate on both historical logs (up to 10,000 hits) and new data received from your log sensors.

4. (Optional) Use the Schema tab to view schema information for every field found in the result set. This information includes the field name,
data type, descriptive text (if available), and the dataset that contains the field. In order for a field to appear in the Schema tab, it must contain
a non-NULL value at least once in the result set.

5. Add as BIOC the new query rule configured.

Build the BIOC rule query through a specific entity in a similar way that you create a search with Query Builder.

1. Select a particular entity icon. Define any relevant activity or characteristics for the entity type. Create a new BIOC rule in the same way that
you create a search with the Query Builder. You use XQL to define the rule. The XQL query must filter on an event_type in order for it to be a
valid BIOC rule.

2. Test your BIOC rule. Rules that you do not refine enough can create thousands of alerts. As a result, it is highly recommended that you test
the behavior of a new or edited BIOC rule before you save it. For example, if a rule will return thousands of hits because you negated a single
parameter, it is a good idea to test the rule before you save it and make it active.

When you test the rule, Cortex XSIAM immediately searches for rule matches across all your Cortex XSIAM tenant data. If there are
surprises, now is the time to see them and adjust the rule definition.

NOTE:

For the purpose of showing you the expected behavior of the rule before you save it, Cortex XSIAM tests the BIOC on historical logs. After
you save a BIOC rule, it will operate on both historical logs (up to 10,000 hits) and new data received from your log sensors.

3. Save your BIOC rule.

4. Define the following parameters.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 198/1003
5/8/24, 9:18 AM PDF Export

a. Name—Specify a descriptive Name to identify the BIOC rule or leave the default name that is automatically populated using the format XQL-BIOC-
<rule number>.

b. Type—Select a rule TYPE that describes the activity.

c. Severity—Specify the Severity you want to associate with an alert generated based on this rule.

d. (Optional) Select the MITRE Technique and MITRE Tactic you want to associate with the alert. You can select up to 3 MITRE Techniques/Sub-
Techniques and MITRE Tactics.

e. (Optional) Select the +<number> more global exceptions to view the EXCEPTIONS associated with this BIOC rule.

f. (Optional) Comment—Specify any additional comments, such as why you created the BIOC.

g. Click OK.

Configure a Custom Prevention Rule

Custom prevention rules are supported on Cortex XSIAM agent 7.2 and later versions and enable you to configure and apply user-defined BIOC rules to
Restriction profiles deployed on your Windows, Mac, and Linux endpoints.

By using the BIOC rules, you can configure custom prevention rules to terminate the causality chain of a malicious process according to the Action Mode
defined in the associated Restrictions Secuirty Profile and trigger Cortex XSIAM Agent behavioral prevention type alerts in addition to the BIOC rule detection
alerts.

For example, if you configure a custom prevention rule for a BIOC Process event, apply it to the Restrictions profile with an action mode set to Block, the Cortex
XSIAM agent:

Blocks a process at the endpoint level according to the defined rule properties.

Raises a behavioral prevention alert you can monitor and investigate in the Alerts table.

Before you configure a BIOC rule as a custom prevention rule, create a Restriction Profile for each type of operating system (OS) that you want to deploy your
prevention rules.

To configure a BIOC rule as a prevention rule.

1. In the BIOC Rule table, from the Source field, filter and locate a user-defined rule you want to apply as a custom prevention rule. You can only apply a
BIOC rule that you created either from Create a Rule from Scratch or a Cortex XSIAM Global Rule template that meets the following criteria.

The user-defined BIOC rule does not include the following field configurations.

All Events—Host Name

File Event—Device Type, Device Serial Number

Process Event—Device Type, Device Serial Number

Network Event—Country, Raw Packet

BIOC rules with OS scope definitions must align with the Restrictions profile OS.

When defining the Process criteria for a user-defined BIOC rule event type, you can select to run only on actor, causality, and OS actor on Windows,
and causality and OS actor on Linux and Mac.

2. Test your BIOC rule.

Rules that you do not refine enough can create thousands of alerts. As a result, it is highly recommended that you test the behavior of a new or edited
BIOC rule before you save it. Cortex XSIAM automatically disables BIOC rules that reach 5000 or more hits over a 24-hour period.

3. Right-click and select Add to restrictions profile.

If the rule is already referenced by one or more profiles, select See profiles to view the profile names.

4. In the Add to Restrictions Profile pop-up:

Ensure the rule you selected is compatible with the type of endpoint operating system.

Select the Restriction Profile name you want to apply the BIOC rule to for each of the operating systems. BIOC event rules of type Event Log and
Registry are only supported by Windows OS.

NOTE:

You can only add to existing profiles you created, Cortex XSIAM Default profiles will not appear as an option.

5. Add the BIOC rule to the selected profiles.

The BIOC rule is now configured as a custom prevention rule and applied to your Restriction profiles. After the Restriction profile is pushed to your
endpoints, the custom prevention rule can start triggering behavioral prevention-type alerts.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 199/1003
5/8/24, 9:18 AM PDF Export

6. Review and edit your custom prevention rules.

a. Navigate to Endpoints → Policy Management → Profiles.

b. Locate the Restrictions Profile to which you applied the BIOC rule. In the Summary field, Custom Prevention Rules appears as Enabled.

c. Right-click and select Edit.

d. In the Custom Prevention Rules section, you can review and modify the following:

Action Mode—Select to Enable or Disable the BIOC prevention rules.

Auto-disable—Select if to auto-disable a BIOC prevention rule if it triggers after a defined number of times during a defined duration.

NOTE:

Auto-disable will turn off both the BIOC rule detection and the BIOC prevention rule.

Prevention BIOC Rules table—Filter and maintain the BIOC rules applied to this specific Restriction Profile. Right-click to Delete a rule or Go
to BIOC Rules table.

e. Save your changes if necessary.

f. Investigate the BIOC prevention rules alerts.

Select Incident Response → Incidents → Alerts Table.

Filter the fields as follows:

Alert Source: XDR Agent

Action: Prevention (<profile action mode>)

Alert Name: Behavioral Threat

In the Description field, you can see the rule name that raised the prevention alert.

Import Rules

You can use the import feature of Cortex XSIAM to import BIOCs from external feeds or that you previously exported. The export/import capability is useful for
rapid copying of BIOCs across different Cortex XSIAM instances.

NOTE:

You can only import files that were exported from Cortex XSIAM. You can not edit an exported file.

1. From Cortex XSIAM, select Detection & Threat Intel → Detection Rules → BIOC.

2. Select Import Rules.

3. Drag and drop the file on the import rules dialog or browse to a file.

4. Click Import.

Cortex XSIAM loads any BIOC rules. This process may take a few minutes depending on the size of the file.

5. Refresh the BIOC Rules page to view matches (# of Hits) in your historical data.

6. To investigate any matches, view the Alerts page and filter the Alert Name by the name of the BIOC rule.

4.1.1.3 | Manage Global BIOC Rules

Abstract

Update and copy BIOC rules, and add rule exceptions in Cortex XSIAM.

Cortex XSIAM checks for the latest update of global BIOC rules. If there are no new global BIOC rules, the app displays a content status of Content up to
date next to the BIOC rules table heading. A dot to the left of the rule name indicates a global BIOC rule.

You can also view the optional Source field to see which rules are pushed by Palo Alto Networks.

1. Get the latest global BIOC rules.

a. Navigate to Detection & Threat Intel → Detection Rules → BIOC.

b. To view the content details, hover over the status Content up to date, to show the global rules version number and last check date.

The content status displays the date when the content was last updated, either automatically or manually by an administrator.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 200/1003
5/8/24, 9:18 AM PDF Export

c. If the status displays Could not check update, click the status to check for updates manually.

The last updated date changes when the download is successful.

2. Copy a global BIOC rule.

You cannot directly modify a global rule, but you can copy global rules as a template to create new rules.

a. Locate a Palo Alto Networks Source type rule, right-click and select Save as New.

b. Review and modify the BIOC properties as needed.

c. Select OK to save the rule.

The rule appears in the BIOC Rules table as a user-defined Source type rule that you can edit.

3. Add a rule exception.

Although you cannot edit global rules, you can add exceptions to the rule, if needed.

4.1.2 | Working with IOCs

Abstract

Indicators of compromise (IOCs) alert you about known malicious objects on your endpoints.

IOCs provide the ability to alert known malicious objects on endpoints across the organization. You can load IOC lists from various threat-intelligence sources
into the Cortex XSIAM app or define them individually.

NOTE:

Cortex XSIAM supports a maximum of 4,000,000 IOCs.

You can define the following types of IOCs:

Full path

File name

Domain

Destination IP address

MD5 hash

SHA256 hash

After you define or load IOCs, the tenant checks for matches in the endpoint data collected from agents. Checks are both retroactive and ongoing: The app
looks for IOC matches in all data collected in the past and continues to evaluate new any new data it receives in the future.

Alerts for IOCs are identified by a source type of IOC.

4.1.2.1 | IOC Rule Details

Abstract

Manage all indicators of compromise (IOCs) configured from or uploaded to Cortex XSIAM.

In the Rules → IOC page, you can view all indicators of compromise (IOCs) configured from or uploaded to Cortex XSIAM. To filter the number of IOC rules you
filter by one or more fields in the IOC rules table. You can also manage or clone existing rules.

The following table describes the fields that are available for each IOC rule in alphabetical order.

Field Description

# OF HITS The number of hits (matches) on this indicator.

CLASS The IOC's class. For example, 'Malware'.

NOTE:

Field cannot exceed 36 characters.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 201/1003
5/8/24, 9:18 AM PDF Export

Field Description

COMMENT Free-form comments specified when the IOC was created or modified.

EXPIRATION DATE The date and time at which the IOC will be removed automatically.

INDICATOR The indicator value itself. For example, if the indicator type is a destination IP address,
this could be an IP address such as 1.1.1.1.

INSERTION DATE Date and time when the IOC was created.

MODIFICATION DATE Date and time when the IOC was last modified.

RELIABILITY Indicator's reliability level:

A - Completely Reliable

B - Usually Reliable

C - Fairly Reliable

D - Not Usually Reliable

E - Unreliable

REPUTATION Indicator's reputation level. One of Unknown, Good, Bad, or Suspicious.

RULE ID Unique identification number for the rule.

SEVERITY IOC severity that was defined when the IOC was created.

SOURCE User who created this IOC, or the file name from which it was created, or one of the
following keywords:

Public API—the indicator was uploaded using the Insert Simple Indicators,
CSV or Insert Simple Indicators, JSON REST APIs.

XSOAR TIM—the indicator was retrieved from XSOAR.

STATUS Rule status: Enabled or Disabled.

TYPE Type of indicator: Full path, File name, Host name, Destination IP, MD5 hash.

VENDORS A list of threat intelligence vendors from which this IOC was obtained.

4.1.2.2 | Create an IOC Rule

Abstract

From the Cortex XSIAM management console, you can upload or configure indicator of compromise (IOC) rules criteria.

There are two options for creating new indicator of compromise (IOC) rules:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 202/1003
5/8/24, 9:18 AM PDF Export

Configure a single IOC.

Upload a file, one IOC per line, that contains up to 20,000 IOCs. For example, you can upload multiple file paths and MD5 hashes for an IOC rule. To help
you format the upload file in the syntax that Cortex XSIAM will accept, you can download the example file.

If you have a Cortex XSIAM Pro per Endpoint license, you can upload IOCs using REST APIs in either CSV or JSON format.

NOTE:

To ensure your IOC rules raise alerts efficiently and do not overcrowd your Alerts table, Cortex XSIAM automatically:

Disables any IOC rules that reach 5000 or more hits over a 24 hour period.

Creates a Rule Exception based on the PROCESS SHA256 field for IOC rules that hit more than 100 endpoints over a 72 hour period.

1. From Cortex XSIAM , select Detection & Threat Intel → Detection Rules → IOC.

2. Select + Add IOC.

3. Configure the IOC criteria.

If after investigating a threat, you identify a malicious artifact, you can create an alert for the Single IOC right away.

a. Configure the INDICATOR value on which you want to match.

b. Configure the IOC TYPE. Options are Full Path, File Name, Domain, Destination IP, and MD5 or SHA256 Hash.

c. Configure the SEVERITY you want to associate with an alert for the IOC.

d. (Optional) Enter a comment that describes the IOC.

e. (Optional) Configure the IOC's REPUTATION.

f. (Optional) Configure the IOC's RELIABILITY.

g. (Optional) Enter an EXPIRATION for the IOC. Default, Specific Expiration Date, No Expiration.

h. Click Create.

If you want to match multiple indicators, you can upload the criteria in a CSV file.

1. Select Upload File.

2. Drag and drop the CSV file containing the IOC criteria in the drop area of the Upload File dialog or browse the file.

Cortex XSIAM supports a file with multiple IOCs in a pre-configured format. For help determining the format syntax, Cortex XSIAM provides an
example text file that you can download.

3. Configure the SEVERITY you want to associate with an alert for the IOCs.

4. Define the DATA FORMAT of the IOCs in the CSV file. Options are Mixed, Full Path, File Name, Domain, Destination IP, and MD5 or SHA256 Hash.

5. (Optional) Configure the IOC's REPUTATION.

6. (Optional) Configure the IOC's RELIABILITY.

7. (Optional) Enter an EXPIRATION for the IOC. Default, Specific Expiration Date, No Expiration.

8. Click Upload.

4. (Optional) Define any expiration criteria for your IOC rules.

If desired, you can also configure additional expiration criteria per IOC type to apply to all IOC rules. In most cases, IOC types like Destination IP or Host
Name are considered malicious only for a short period of time since they are soon cleaned and then used by legitimate services, from which time they
only cause false positives. For these types of IOCs, you can set a defined expiration period. The expiration criteria you define for an IOC type will apply to
all existing rules and additional rules that you create in the future. By default, Cortex XSIAM does not apply an expiration date set on IOCs.

a. Select Default Rule Expiration.

b. Set the expiration for any relevant IOC type. Options are Never, 7 Days, 30 days, 90 days, or 180 days.

c. Click Save.

4.1.3 | Working with Correlation Rules

Abstract

Correlation Rules help you analyze correlations of multi-events from multiple sources by using the Cortex Query Language based engine for creating scheduled
rules.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 203/1003
5/8/24, 9:18 AM PDF Export

Correlation Rules help you analyze correlations of multi-events from multiple sources by using the Cortex Query Language (XQL) based engine for creating
scheduled rules called Correlation Rules. Alerts can then be triggered based on these Correlation Rules with a defined time frame and set schedule, including
every X minutes, once a day, once a week, or a custom time.

Once you have configured your Correlation Rules, you can manage the Correlation Rules in the Correlation Rules page, view and analyze the alerts generated
from the Correlation Rules in the Alerts and Incidents pages. In addition, these Correlation Rules are factored into the number of incidents displayed in the
dashboard.

4.1.3.1 | Correlation Rule Details

Abstract

In the Correlation Rules page, you can view all of your enabled rules in a table format and the various fields displayed.

NOTE:

There may be future changes to the Correlation Rules offerings, which can impact your licensing agreements. You will receive a notification ahead of time
before any changes are implemented.

If you are assigned a role that enables Investigation → Rules privileges, you can view all user-defined Correlation Rules from Detection & Threat Intel →
Detection Rules → Correlations.

By default, the Correlation Rules page displays all enabled rules. To search for a specific rule, use the filters above the results table to narrow the results. From
the Correlation Rules page, you can also manage existing rules using the right-click pivot menu.

In addition, the Correlation Rules page helps you easily identify and resolve Correlation Rules errors. The number of errors is indicated at the top of the page in
red font using the format <number> errors found. You can change the view to only display the Correlation Rules with errors by selecting Show Errors Only. The
LAST EXECUTION column in the table indicates a Correlation Rule with an error by displaying the last execution time in a red font and providing a description of
the Correlation Rule Error when hovering over the field. The following error messages are displayed in the applicable scenarios.

Invalid query

Query timeout

Dependency correlation did not complete

Unknown error

Delayed rule—This rule is running past its scheduled time, which can cause delayed results.

Dataset does not exist: <name of dataset>

NOTE:

Only an administrator can create and view queries built with an unknown dataset that currently does not exist in Cortex XSIAM .

A notification is also displayed in Cortex XSIAM to indicate these Correlation Rules errors.

The following table describes the fields that are available for each Correlation Rule in alphabetical order.

NOTE:

Certain fields are exposed and hidden by default. An asterisk (*) is beside every field that is exposed by default.

Field Description

# OF ALERTS* The number of alerts triggered for this rule.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 204/1003
5/8/24, 9:18 AM PDF Export

Field Description

ALERT CATEGORY* Type of alert as configured when creating the rule.

Collection

Credential Access

Dropper

Evasion

Execution

Evasive

Exfiltration

File Privilege Manipulation

File Type Obfuscation

Infiltration

Lateral Movement

Persistence

Privilege Escalation

Reconnaissance

Tampering

Other

DATASET* The text displayed here depends on the resulting action configured for the
Correlation Rule when the rule was created.

alerts—When your resulting action for the rule was configured to Generate
alert.

Dataset name—When your resulting action for the rule was configured to
Save to dataset.

DESCRIPTION* The description for the Correlation Rule that was configured when the rule was
created.

DRILL-DOWN QUERY Displays the Drill-Down Query that you configured for additional information about
the alert for further investigation using Cortex Query Language (XQL) when you
created the rule. If you did not configure one, the field is left empty.

Once configured any alert generated for the Correlation Rule has a right-click pivot
menu Open Drilldown Query option, an Open drilldown query link after you
investigate any contributing events, and a quick action Open Drilldown Query icon
( ) that is accessible in the Alerts page, which opens a new browser tab in XQL
Search to run this query. If you do not define a Drill-Down Query, no right-click
menu option, link, or icon is displayed.

The Drill-Down Query Time Frame can be configured as either.

Generated Alert—Uses the time frame of the alert that is triggered, which is
the first event and last event timestamps for the alert (default option).

XQL Search—Uses the time frame from when the Correlation Rule was run
in XQL Search.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 205/1003
5/8/24, 9:18 AM PDF Export

Field Description

FAILURE REASON For a Correlation Rule with an error, displays the error message, which can be one
of the following.

Invalid query

Query timeout

Dependency correlation did not complete

Unknown error

Delayed rule—This rule is running past its scheduled time, which can cause
delayed results.

Dataset does not exist: <name of dataset>

NOTE:

Only an administrator can create and view queries built with an unknown
dataset that currently does not exist in Cortex XSIAM.

INSERTION DATE Date and time when the Correlation Rule was created.

LAST EXECUTION* Date and time when the Correlation Rule was last executed. Indicates a
Correlation Rule with an error by displaying the last execution time in a red font
and providing a description of the Correlation Rule Error when hovering over the
field. Indicates Real-time in the case of Real Time Correlation Rules.

MITRE ATT&CK TACTIC* Displays the type of MITRE ATT&CK tactic the Correlation Rule is attempting to
trigger.

MITRE ATT&CK TECHNIQUE* Displays the type of MITRE ATT&CK technique and sub-technique the Correlation
rule is attempting to trigger.

MODIFICATION DATE* Date and time when the Correlation Rule was last modified.

NAME* Unique name that describes the rule.

RULE ID Unique identification number for the rule.

SCHEDULE* Displays the Time Schedule for the frequency of running the XQL Search definition
set for the Correlation Rule when the rule was created. The options displayed are
one of the following.

Every 10 Minutes

Every 20 Minutes

Every 30 Minutes

Hourly

Daily

Displays the Time Schedule as Cron Expression fields.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 206/1003
5/8/24, 9:18 AM PDF Export

Field Description

SEVERITY* Correlation Rule severity that was defined when the Correlation Rule was created.
Severity levels can be Informational, Low, Medium, High, Critical, and Customized.

Whenever an alert is generated with a severity type of Medium and above based
on the Correlation Rule, a new incident is automatically opened.

SOURCE* User who created this Correlation Rule.

STATUS Rule status: Enabled or Disabled.

SUPPRESSION DURATION* The duration time for how long to ignore other events that match the alert
suppression criteria that was configured when the rule was created. This is
required to configure.

SUPPRESSION FIELDS* The fields that the alert suppression is based on, which was configured when the
rule was created. The fields listed are based on the XQL query result set for the
rule. This is optional to configure.

SUPPRESSION STATUS* Displays the Suppression Status as either Enabled or Disabled as configured
when the rule was created.

TIME FRAME* Displays the time frame for running a query, which can be up to 7 days as
configured when the rule was created.

TIMEZONE Displays the Timezone when the Time Schedule for the frequency of running the
XQL Search definition set for the Correlation Rule is set to run daily or using a cron
expression. Otherwise, this field is left empty.

XQL SEARCH Displays the XQL definition for the Correlation Rule that was configured in XQL
Search when the rule was created.

4.1.3.2 | Create a Correlation Rule

Abstract

Create new Correlation Rules from either the Correlation Rules page or when building a query in XQL Search.

LICENSE TYPE:

There may be future changes to the Correlation Rules offerings, which can impact your licensing agreements. You will receive a notification ahead of time
before any changes are implemented.

You can create a new Correlation Rule from either the Correlation Rules page or when building a query in XQL Search.

When setting up Correlation Rules, you have the following capabilities.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 207/1003
5/8/24, 9:18 AM PDF Export

Specify whether the Correlation Rule is Scheduled, or scans the data in Real Time, as it’s ingested.

Define when the Correlation Rule runs.

Define whether alerts generated by the Correlation Rule are suppressed by a duration time and field.

Set the resulting action for the Correlation Rule as either to generate an alert or save the data to a dataset.

When generating an alert, you can also define the alert settings, which include the Alerts Field Mapping for incident enrichment, Alert domain, Alert
Severity, MITRE Attack Tactics and Techniques, and other alert settings.

When saving the data to a dataset, you can test and fine-tune new rules before initiating alerts and applying correlation of correlation use cases.

NOTE:

When creating a Real Time Correlation Rule, you can’t save the data to a dataset.

NOTE:

To ensure your Correlation rules raise alerts efficiently and do not overcrowd your Alerts table, Cortex XSIAM automatically disables Correlation rules that
reach 5000 or more hits over a 24-hour period.

How to create a correlation rule

1. Open the New Correlation Rule editor.

You can do this in two ways.

From the Correlation Rules page.

1. Select Detection & Threat Intel → Detection Rules → Correlations.

2. Select +Add Correlation.

From XQL Search.

1. Select Incident Response → Investigation → Query Builder → XQL Search.

2. In the XQL query field, define the parameters for your Correlation Rule.

3. Select Save as → Correlation Rule.

The New Correlation Rule editor is displayed where the XQL Search section is populated with the query you already set in the XQL query
field.

2. Configure the General settings.

Specify a descriptive Name to identify the Correlation Rule.

(Optional) Specify a Description for the Correlation Rule.

3. Use XQL to define the Correlation Rule in XQL Search field.

Define the Correlation Rule in the XQL Search field. After writing at least one line in XQL, you can Open full query mode to display the query in XQL
Search. You can Test the XQL definition for the rule whenever you want.

NOTE:

When you open the New Correlation Rule editor from XQL Search, this XQL Search field is already populated with the XQL query that you
defined.

An administrator can create and view queries built with an unknown dataset that currently does not exist in Cortex XSIAM . All other users can
only create and view queries built with an existing dataset.

When you finish writing the XQL for the Correlation Rule definition, select Continue editing rule to bring you back to the New Correlation Rule editor, and
the complete query you set is added to the XQL Search field.

NOTE:

The XQL features for transaction, call, top, and wildcards in datasets (dataset in (<dataset prefix>_*)) are not currently supported in
Correlation Rules. If you add them to the XQL definition, you will not be able to Create or Save the Correlation Rule.

Using the current_time() function in your XQL query for a correlation rule can yield unexpected results when there are lags or during
downtime. This happens if the correlation rule doesn’t run exactly at the time of the data inside the timeframe, for example when a rule is
dependent on another rule, or when a rule is stuck due to an error, and then runs in recovery mode. Instead, we recommend using the c function,
which returns the timestamp at the end of the time frame in which the rule is executed.

4. Select to run the Correlation Rule in Real Time or Scheduled.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 208/1003
5/8/24, 9:18 AM PDF Export

Real Time Correlation Rules scan the data as it’s ingested.

You can run Real Time Correlation Rules on Cortex XSIAM alerts, Cloud audit logs, third party datasets, and Data Models.

When you start typing a Correlation Rule, Cortex XSIAM can detect that the query can be run in Real Time and recommend that you select Real
Time.

Real Time Correlation Rules only support the following XQL stages: dataset,datamodel, filter, alter, fields, and config case_sensitive. A
Real Time Correlation Rule must include an XQL filter stage. For more information on these XQL stages, see the Cortex XSIAM XQL Language
Reference Guide.

The following XQL functions are not supported in a Real Time Correlation Rule: json_extract_scalar_array, parse_epoch, and
time_frame_end.

5. If the Correlation Rule is Scheduled, configure the Timing settings.

Time Schedule—Select the Time Schedule for the frequency of running the XQL Search definition set for the Correlation Rule as one of the
following.

Every 10 Minutes—Runs every rounded 10 minutes at preset 10 minute intervals from the beginning of the hour, such as 10:10 AM, 10:20
AM, and 10:30 AM.

Every 20 Minutes—Runs every rounded 20 minutes at preset 20 minute intervals from the beginning of the hour, such as 10:20 AM, 10:40
AM, and 11:00 AM.

Every 30 Minutes—Runs every rounded 30 minutes at preset 30 minute intervals from the beginning of the hour, such as 10:30 AM, 11:00
AM, and 11:30 AM.

Hourly — Runs at the beginning of the hour, such as 1:00 AM or 2:00 AM.

Daily— Runs at midnight, where you can set a particular Timezone.

Custom— Displays the Time Schedule as Cron Expression fields, where you can set the cron expression in each time field to define the
schedule frequency for running the XQL Search. The minimum query frequency is every 10 minutes and is already configured. You can also
set a particular Timezone.

By default, the query is set to run once an hour (1 Hour/s).

Timezone—(Optional) You can only set the Timezone when the Time Schedule is set to Daily or Custom. Otherwise, the option is disabled.

Query time frame—Set the time frame for running a query, which can be up to 7 days. Specify a number in the field and in the other field select
either Minute/s, Hour/s, or Day/s.

6. (Optional) Configure Alert Suppression settings.

Define whether the alerts generated by the Correlation Rule are suppressed by a duration time, field, or both.

Enable alert suppression—Select this checkbox to Enable alert suppression. By default, this checkbox is clear and the alerts of the Correlation Rule
are configured to not be suppressed.

Duration time—Set the Duration time for how long to ignore other events that match the alert suppression criteria, which are based on the Fields
listed. Specify a number in the field and in the other field select either Minute/s, Hour/s, or Day/s. By default, the generated alerts are configured to
be suppressed by 1 hour (1 Hour/s). The Duration time can be configured for a maximum of 1 day.

Fields—(Optional) Select the fields that the alert suppression is based on. The fields listed are based on the XQL query result set. You can perform
the following.

Select multiple fields from the list.

Select all to configure all the fields for suppression. This means that all the fields must match for the alerts to be suppressed. This option will
generate multiple alerts during the suppression period.

Search for a particular field, which narrows the available options as you begin typing.

Do not set any Fields by leaving the field empty only 1 alert is generated during the suppression period.

7. Configure the resulting Action for the Correlation Rule.

a. You can select either of the following resulting actions to occur, where the configuration settings change depending on your selection.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 209/1003
5/8/24, 9:18 AM PDF Export

Generate alert—Generates a Correlation type of alert according to the configured settings in the New Correlation Rule editor (default). When
this option is selected a number of new sections are opened to configure the alert.

Save to dataset (only for Scheduled Correlation Rules)—Saves the data generated from the Correlation Rule to a separate Target Dataset.
This option is helpful when you are fine-tuning and testing a rule before promoting the rule to production. You can also save a rule to a dataset
as a building block for the next Correlation Rule, which will be based on the results of the first Correlation Rule instead of building too complex
XQL queries.

You can either create a new Target Dataset by specifying the name for the dataset in the field or select a preexisting Target Dataset that was
created for a different Correlation Rule. The list only displays the datasets configured when creating a Correlation Rule. Different Correlation
Rules can be saved to the same dataset and Cortex XSIAM will expand the dataset schema as needed. The dataset you configure for the
Correlation Rule contains the following additional fields.

_rule_id

_rule_name

_insert_time

When you are finished configuring the Target Dataset, you can now either Createthe Correlation Rule or Save for later.

b. If you selected Generate alert, configure the Alert Settings.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 210/1003
5/8/24, 9:18 AM PDF Export

Alert Name—Specify a name. You can incorporate a variable based on a query output field in the format $fieldName.

Alert Domain—Select the domain to which you want to assign any triggered alerts.

NOTE:

The incident that contains the alerts will also be assigned to this domain. For more information, see Incident and alert domains.

Severity—Select the severity type whenever an alert is generated for this Correlation Rule as one of the following.

Informational

Low

Medium

High

Critical

User Defined—Select fields from inside the query.

NOTE:

Whenever the severity type is Medium or above for the alert generated, an incident is automatically opened.

Category—Select the type of alert that is generated, which can be any of the following.

Collection

Credential Access

Dropper

Evasion

Execution

Evasive

Exfiltration

File Privilege Manipulation

File Type Obfuscation

Infiltration

Lateral Movement

Persistence

Privilege Escalation

Reconnaissance

Tampering

Other

User Defined—Select fields from inside the query.

Alert Description—(Optional) Specify a description of the behavior that will raise the alert. You can include dollar signs ($), which represent
the fields names (i.e. output columns) in XQL Search.

For example.

The user $user_name has made $count failed login requests to $dest in a 24 hours period

Output.

The user lab_admin has made 234 failed login requests to 10.10.32.44 in a 24 hours period

NOTE:

There is no validation or auto complete for these parameters and the values can be null or empty. In these scenarios, Cortex XSIAM does
not display the null or empty values, but adds the text NULL or EMPTY in the descriptions.

Drill-Down Query—(Optional) You can configure a Drill-Down Query for additional information about the alert for further investigation using
XQL. This XQL query can accept parameters from the alert output for the Correlation Rule. Yet, keep in mind that when you create the
Correlation Rule, Cortex XSIAM does not know in advance if the parameters exist or contain the correct values. As a result, Cortex XSIAM
enables you to save the query, but the query can fail when you try and run it. You can also refer to field names using dollar signs ($) as
explained in the Alert Description.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 211/1003
5/8/24, 9:18 AM PDF Export

Once configured any alert generated for the Correlation Rule has a right-click pivot menu Open Drilldown Query option, an Open drilldown
query link after you investigate a contributing event, and a quick action Open Drilldown Query icon ( ) that is accessible in the Alerts page,
which opens a new browser tab in XQL Search to run this query. If you do not define a Drill-Down Query, no right-click pivot menu option, link,
or icon is displayed.

Drill-Down Query Time Frame—Select the time frame used to run the Drill-Down Query from one of the following options, which provides
more informative details about the alert generated by the Correlation Rule.

Generated Alert—Uses the time frame of the alert that is triggered, which is the first event and last event timestamps for the alert
(default option). If there is only one event, the event timestamp is the time frame used for the query.

XQL Search—Uses the time frame from when the Correlation Rule was run in XQL Search.

MITRE ATT&CK—(Optional) Select the MITRE Tactics and MITRE Techniques you want to associate with the alert using the MITRE ATT&CK
matrix.

1. You can access the matrix by selecting the MITRE ATT&CK bar or Open complete MITRE matrix link underneath the bar on the right.

2. Select the MITRE Tactics listed in the first row of the matrix and the applicable MITRE techniques and Sub-Techniques, which are listed
in the other rows in the table. You can select either MITRE Tactics only, MITRE techniques and Sub-Techniques only, or a combination
of both.

3. Click Select and the matrix window closes and the MITRE ATT&CK section in the New Correlation Rule editor lists the number of
Tactics and Techniques configured, which is also listed in the bar. For example, in the following image, there are 3 Tactics and 4
Techniques configured. The three MITRE Tactics are Resource Development with 2 Techniques configured, Credential Access with 1
Technique configured, and Discovery with 1 Technique configured.

c. (Optional) Configure the Alerts Fields Mappings.

You can map the alert fields so that the mapped fields are displayed in the Alerts page to provide important information in analyzing your alerts. In
addition, mapping the fields helps to improve incident grouping logic and enables Cortex XSIAM to list the artifacts and assets based on the map
fields in the incident. The options available can change depending on your Correlation Rule definitions in XQL Search. There are two ways to map
the alert fields.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 212/1003
5/8/24, 9:18 AM PDF Export

Use the preconfigured Cortex XSIAM alert field mapping—Select this option if you want Cortex XSIAM to automatically map the fields for you.
This checkbox only displays when your Correlation Rule can be configured to use Cortex XSIAM incident enrichment and then it is set as the
default option. We recommend using this option whenever it is available to you.

When creating a Correlation Rule that runs on the Cortex Data Model (XDM), we recommend that this checkbox is selected. Cortex XSIAM
automatically maps the XDM fields to alert fields as listed in the table below. This means that these XDM field values are displayed in the
Alerts page.

NOTE:

When more than one XDM field is listed, Cortex XSIAM looks for the field value according to the order of the fields listed.

List of XDM fields mapped to Alert fields

XDM Fields Cortex XSIAM Alert Fields

xdm.event.type Event Type

xdm.target.file.filename, xdm.target.module.filename, xdm.email.attachment.filename File name

xdm.target.file.sha256, xdm.target.module.sha256, xdm.email.attachment.sha256 File SHA256

xdm.source.host.ipv4_addresses Host IP

xdm.source.host.hostname Host Name

xdm.source.host.os_family Host OS

xdm.source.process.executable.filename, xdm.source.process.name Initiated By

xdm.source.process.command_line Initiator CMD

xdm.source.process.executable.path Initiator path

xdm.source.process.executable.sha256 Initiator SHA256

xdm.source.process.executable.signature_status Initiator signature

xdm.source.process.executable.signer Initiator signer

xdm.source.ipv4, xdm.source.host.ipv4_addresses Local IP

xdm.target.process.executable.signature_status Process execution signature

xdm.target.process.executable.signer Process execution signer

xdm.target.host.hostname Remote Host

xdm.target.ipv4, xdm.target.host.ipv4_addresses Remote IP

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 213/1003
5/8/24, 9:18 AM PDF Export

XDM Fields Cortex XSIAM Alert Fields

xdm.target.port Remote port

xdm.target.process.command_line Target process CMD

xdm.target.process.executable.sha256 Target process SHA256

xdm.source.user.username User name

(Optional) Select or deselect Set fields as default for new Security Domain correlations.

This option saves the custom alert fields that are configured for this rule for all users. When a user next creates an incident for the same
domain, these fields are automatically configured instead of the default field set.

To restore the system defaults, click Restore Default Field Set.

Manually map the alert fields by selecting the fields that you want to map. When you create the Correlation Rule, Cortex XSIAM does not
know whether the alert fields that you mapped manually are valid. If the fields are invalid according to your mapping, null values are assigned
to those fields.

NOTE:

In a case where Use the Cortex XSIAM default incident enrichment is not selected and you have not mapped any alert fields, the alert is
dispatched into a new incident.

8. (Optional) Disable the Correlation Rule.

Select Disable → Create if you want to finish configuring your Correlation Rule at a different time, but do not want to lose your settings. The Create button
is only enabled when you have configured all the mandatory fields in the New Correlation Rule editor. Once configured, your Correlation Rule is listed in
the Correlation Rules page, but is disabled. You can edit or enable the rule at any time by right-clicking the rule and selecting Edit Rule or Enable.

9. Create the Correlation Rule.

The rule is added to the table in the Correlation Rules page as an active rule and a notification is displayed.

10. Manage a Correlation Rule, as needed.

At any time, you can return to the Correlation Rules page to view and manage your Correlation Rules. To manage a Correlation Rule, right-click the
Correlation Rule and select the desired action.

You can also monitor your correlation rule executions with the correlations_auditing data set. For more information, see Monitor correlation rules.

Right-click actions for managing correlation rules

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 214/1003
5/8/24, 9:18 AM PDF Export

Open in XQL—View the XQL results for the Correlation Rule in XQL Search. You can Show results in new tab or Show results in same tab.

View related alerts—View the alerts generated by this Correlation Rule in the Alerts page. You can Show alerts in new tab or Show alerts in same
tab.

Execute Rule—Run the rule now without waiting for the scheduled time.

NOTE:

Execute Rule is not available for Real Time Correlation Rules.

Disable the selected Correlation Rule. This option is only available on an active rule.

Enable the selected Correlation Rule. This option is only available on an inactive rule.

Edit Rule—Edit the rule parameters configured in the Edit Correlation Rule editor.

Save as new—Duplicate the Correlation Rule and save it as a new Correlation Rule.

Delete the Correlation Rule.

Show rows with ‘<field value>’ to filter the Correlation Rules list to only display the Correlation Rules with a specific field value that you selected in
the table. On certain fields that are null, this option does not display.

Hide rows with ‘<Rule Description>’ to filter the Correlation Rules list to hide the Correlation Rules with a specific field value that you selected in the
table. On certain fields that are null, this option does not display.

Copy entire row to copy the text from all the fields in a row of a Correlation Rule.

4.1.3.3 | Monitor correlation rules

Abstract

You can monitor your correlation executions with the correlations_auditing dataset.

Cortex XSIAM audits all correlation executions in the correlations_auditing dataset. The dataset records the query initiation times, end times, retry
attempts, failure reasons, and other useful metrics. You can use this dataset to monitor your correlation executions, and set up correlation rules to trigger alerts
when correlation errors occur.

In the correlations_auditing dataset, audit entries are added as follows:

The rule starts executing. This is audited with the status of Initiated or Initiated Manually.

The rule completes successfully. This is audited as Completed.

The rule completes with errors. This is audited as Error.

NOTE:

In the dataset, the Query start time and Query end time indicate the timeframe of the data that was queried. The actual start and end times of the correlation
rule execution are recorded in the _time field for the Initiated and Completed entries.

Set up a correlation rule to monitor correlation errors

The following correlation rule triggers alerts when correlations fail to run:

Field Value To Specify

Rule Name Correlation errors

dataset = correlations_auditing | filter status = "Error"

XQL

Time Schedule Hourly

Query time frame 1 Hour

Action Generate alert

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 215/1003
5/8/24, 9:18 AM PDF Export

Field Value To Specify

Alert Name Correlation error

Severity Medium

Category User Defined

After setting up the correlation rule, you can set up a new forwarding configuration to send an email or Slack message when Correlation error alerts are
triggered. For more information, see Configure Notification Forwarding.

Field descriptions for the correlations_auditing dataset

The following table describes the fields in the correlations_auditing dataset:

Field Description

_time Timestamp of the audit.

For entries with an Initiated or Initiated Manually status, this is the start time of the correlation rule execution.
For entries with a Completed or Error status, this is the end time of the rule execution.

_id Unique identifier of the audit entry.

Rule ID Unique identification number for the correlation rule.

Name Correlation rule name.

Status The status of the correlation rule query.

Possible values are Initiated, Initiated Manually, Completed, and Error.

Query start time The start time of the query timeframe.

Query end time The end time of the query timeframe.

Time frame Time frame for the query.

Failure reason For correlation rules with errors, this field displays the error message.

Retry attempts Number of retry attempts before the query initiated or failed to run.

Schedule Scheduled frequency to execute the correlation rule.

Rule creation time Date and time that the correlation rule was created.

Rule modification time Date and time that the correlation rule was last modified.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 216/1003
5/8/24, 9:18 AM PDF Export

Field Description

Description Description of the correlation rule.

Severity Defined severity of the correlation rule.

Dataset Target data set, as defined in the correlation rule

Suppression status Whether alert suppression is Enabled or Disabled.

Suppression duration Duration for which to ignore additional events that match the alert suppression criteria.

Suppression fields Fields on which the alert suppression is based.

Timezone Timezone on which the scheduled frequency is based.

MITRE ATT&CK Tactic MITRE ATT&CK tactic that the correlation rule attempted to trigger.

MITRE ATT&CK Technique MITRE ATT&CK technique that the correlation rule attempted to trigger.

Alert category Category of alert as configured when creating the rule.

Source Source of the correlation rule.

XQL search XQL query for the correlation rule.

Drill-down query XQL query configured for further investigation.

Alert name Name of the alert that the correlation rule will trigger.

4.1.4 | Attack Surface Rules

Abstract

Learn more about Attack Surface Rules.

An attack surface rule is a definition managed by Cortex XSIAM that is used to identify risks in an attack surface. It defines what Cortex XSIAM is looking for and
the associated risk. Cortex XSIAM creates an alert when it detects an instance of that rule.

4.1.5 | Manage Existing Indicators

Abstract

Edit, export, copy, disable, or remove rules, and add rule exceptions for existing indicators in Cortex XSIAM.

After you create an indicator rule, you can take the following actions:

NOTE:

For Analytics BIOC rules, you can only disable and enable rules.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 217/1003
5/8/24, 9:18 AM PDF Export

View Alerts Triggered by a Rule

As your IOC and BIOC rules trigger alerts, Cortex XSIAM displays the total # OF HITS for the rule in the the BIOC or IOC rules page. For rules with a high,
medium, or low severity that have raised one or more alerts, you can quickly pivot to a filtered view of those alerts raised by the indicator:

1. Select Detection & Threat Intel → Detection Rules and the type of rule (BIOC or IOC).

2. Right-click anywhere in a rule, and then select View associated alerts.

You can see a filtered query of alerts associated with the Rule ID.

Use a BIOC Rule as the Basis of a Query

1. Select Detection & Threat Intel → Detection Rules and the type of rule (BIOC or IOC).

2. Right-click anywhere in the rule, and then select Open in query builder.

populates a query using the criteria of the BIOC rule.

3. If desired, add or change the query criteria.

4. (Optional) Test your query to see the sample results.

5. If you are satisfied with query, Save the query.

For more information, see Manage Your Queries.

Edit a Rule

After you create a rule, it may be necessary to tweak or change the rule settings. You can open the rule configuration from the Rules page or from the pivot
menu of an alert triggered by the rule. To edit the rule from the Rules page:

1. Select Detection & Threat Intel → Detection Rules and the type of rule (BIOC or IOC).

2. Locate the rule you want to edit.

3. Right-click anywhere in the rule and select Edit.

4. Edit the rule settings as needed, and then click OK.

If you make any changes, Test and then Save the rule.

Export a Rule (BIOC Only)

1. Select Detection & Threat Intel → Detection Rules → BIOC.

2. Select the rules that you want to export.

3. Right-click any of the rows, and select Export selected.

The exported file is not editable, however, you can use it as a source to import rules at a later date.

Copy a BIOC Rule

You can use an existing rule as a template to create a new one. Global BIOC rules cannot be deleted or altered, but you can copy a global rule and edit the
copy.

1. From Cortex XSIAM, select Detection & Threat Intel → Detection Rules and then BIOC.

2. Locate the rule you want to copy.

3. Right-click anywhere in the rule row and then select Save as New to create a duplicate rule.

Disable or Remove a Rule

If you no longer need a rule you can temporarily disable or permanently remove it.

NOTE:

You cannot delete global BIOCs delivered with content updates.

1. Select Detection & Threat Intel → Detection Rules and the type of rule (BIOC or IOC).

2. Locate the rule that you want to change.

3. Right-click anywhere in the rule row and then select Remove to permanently delete the rule, or Disable to temporarily stop the rule. If you disable a rule
you can later return to the rule page to Enable it.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 218/1003
5/8/24, 9:18 AM PDF Export

Partially Disable or Re-enable a BIOC Rule

You can disable one or more BIOC rules on the agent, on the server, or on both. This provides you more granularity for managing the prevention actions
triggered by the BIOC Rules.

1. From Cortex XSIAM, select Detection Rules → BIOC.

2. Select the rules you want to disable.

3. Right-click any of the rules and select to disable the rules on the agent, on the server, or on both.

NOTE:

For BIOC rules that are applied to prevention profiles:

If you disable a rule only on the agent, detection on the server works as usual.

If you disable a rule only on the server, prevention on the agent works as usual.

4. We recommend you supply a reason for disabling the rule.

NOTE:

When a BIOC rule is disabled automatically by Cortex XSIAM, for example due to the server anti flooding mechanism, prevention on the agent works as
before.

You can re-enable a rule granularly for detection, prevention, or both in the same way.

4.2 | Investigate Incidents

Abstract

Track and investigate incidents, assign analysts to investigate, and document the incident resolution in Cortex XSIAM.

The Incidents page displays all incidents to help you prioritize, track, triage, investigate and take remedial action.

4.2.1 | Incidents

Abstract

Learn more about the Cortex XSIAM Incidents table displaying all the incidents reported to and surfaced from your Cortex XSIAM instance.

An attack can affect several hosts or users and raises different alert types stemming from a single event. All artifacts, assets, and alerts from a threat event are
gathered into an Incident.

The logic behind which alert the Cortex XSIAM app assigns to an incident is based on a set of rules which take into account different attributes. Examples of
alert attributes include alert source, type, and time period. The app extracts a set of artifacts related to the threat event, listed in each alert, and compares it with
the artifacts appearing in existing alerts in the system. Alerts on the same causality chain are grouped with the same incident if an open incident already exists.
Otherwise, the new incoming alert will create a new incident.

To keep incidents fresh and relevant, Cortex XSIAM provides thresholds after which an incident stops adding alerts:

30 days after the incident was created

14 days since the last alert in the incident was detected (excludes backward scan alerts)

After the incident reaches either threshold, it stops accepting alerts, and Cortex XSIAM groups subsequent related alerts in a new incident. You can track the
grouping threshold status in the Alerts Grouping Status field in the Incidents table:

Enabled—The incident is open to accepting new related alerts.

Disabled—The grouping threshold is reached and the incident is closed to further alerts or if the incident reached the 1,000 alert limit. To view the exact
reason for a Disabled status, hover over the status field.

You can select to view the Incidents page in a table format or split pane mode. Use to toggle between the views. By default, Cortex XSIAM displays the split
pane mode. Any changes you make to the incident fields, such as description, resolution status, filters, and sort selections persist when you toggle between the
modes.

The split pane mode displays a side-by-side view of your incidents list and the corresponding incident details.

The table view displays only the incident fields in a table format. Right-click an incident to view the incident details, and investigate the related assets, artifacts,
and alerts.

NOTE:

You can query data related to the Incidents and Alerts tables by using the incidents and alerts datasets.

The following table describes both the default and additional optional fields that you can view in the Incidents table and lists the fields in alphabetical order.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 219/1003
5/8/24, 9:18 AM PDF Export

Field Description

Check box to select one or more incidents on which to perform the following
actions.

Assign incidents to an analyst in bulk

Change the status of multiple incidents

Change the severity of multiple incidents

Alert Categories Type of alert categories triggered by the incident alerts.

Alert Source Source of the alert, such as XDR Analytics BIOC, XDR BIOC, and Correlation.

Alerts Grouping Status Displays whether Alert Grouping is currently enabled.

Alerts Breakdown The total number of alerts and number of alerts by severity.

Assignee Email Email address associated with the assigned incident owner.

Assigned To The user to which the incident is assigned. The assignee tracks which analyst is
responsible for investigating the threat. Incidents that have not been assigned
have a status of Unassigned.

Automated Whether the incident contains any playbooks.

Creation Time Date and time when the incident was created.

High Severity Alerts Number of high severity alerts that are part of the incident.

Hosts Displays the host names affected by the incident.

Incident Description The description is generated from the alert name from the first alert added to the
incident, the host and user affected, or number of users and hosts affected.

Incident ID A unique number to identify the incident.

Incident Name A user-defined incident name.

Incident Sources List of sources that raised high and medium severity alerts in the incident.

Last Updated The last time a user took an action or an alert was added to the incident.

Low Severity Alerts Number of low severity alerts that are part of the incident.

Medium Severity Number of medium severity alerts that are part of the incident.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 220/1003
5/8/24, 9:18 AM PDF Export

Field Description

MITRE ATT&CK Tactic Displays the types of MITRE ATT&CK tactics triggered by the alerts that are part of
the incident.

MITRE ATT&CK Technique Displays the type of MITRE ATT&CK technique and sub-technique triggered by the
alerts that are part of the incident.

Resolve Comment The user-added comment when the user changes the incident status to a
Resolved status.

Resolved Timestamp Displays the date and time when the incident was set with a resolved status.

Score Displays the score defined by the incident scoring rule.

For SmartScore incident scores, hover your cursor over each score to view the
main reasons for the score calculation.

Severity The highest alert in the incident or the user-defined severity.

Starred The incident includes alerts that match your incident prioritization policy. Incidents
that have alert matches include a star by the incident name in the Incident details
view and a value of Yes in this field.

Status When incidents are generated they have the status set to New. To begin
investigating an incident, set the status to Under Investigation. When the incident
is resolved, set the status to Resolved and select a resolution reason. For a
description of each resolution reason, see Resolution Reasons for Incidents and
Alerts.

Tags Displays one or more of the following categories, which is used to filter the results
according to the selected tag:

Asset Roles

Data Sources

Detector Tags

Endpoint Groups / Endpoint Tags —

Displays the tag family and the corresponding tags. If SBAC is enabled, the
user can view and manage the alerts table according the user's scope
settings.

NOTE:

When viewing alerts as a scoped user when a tenant is set to permissive

mode, the user can view the alert but not have access to entities outside
their scope.

When viewing alerts as a scoped user when a tenant is set to restrictive

mode, the alert content is not visible. The user can send the alert ID to the
administrator to add to the user scope so the user can view the alert.

Total Alerts The total number of alerts in the incident.

Users Users affected by the alerts in the incident. If more than one user is affected, click
on + <n> more to see the list of all users in the incident.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 221/1003
5/8/24, 9:18 AM PDF Export

Field Description

WildFire Hits Number of the Malware, Phishing, and Grayware artifacts that are part of the
incident.

4.2.1.1 | Incident and alert domains

Abstract

Cortex XSIAM assigns each incident and alert to a domain. Domains help you to organize and manage your work efforts, and differentiate between use cases.

Incident Domains help you to organize and manage your work efforts by associating incidents and alerts to a domain, and creating a tailored experience for
each domain. Incident domains are a logical contextual boundary that allow you to manage and prioritize each operational use case, and help you to
differentiate between your security use cases and non-security use cases.

When an alert is triggered, Cortex XSIAM automatically assigns it to a domain, and the same domain is assigned to the associated incident. If you create your
own incident or correlation rule, you can select the domain to which you want to assign the incident or alerts.

On the Incidents and Alerts pages, you can see the domain to which your incidents and alerts are assigned. Each incident and alert is assigned to a single
domain, and you cannot change the assigned domain.

Cortex XSIAM provides the following built-in domains:

Domain Description

Security For incidents and alerts that are associated with incident response activities for detecting, preventing, and
blocking threats. For example, alerts that can harm the security of your organization's assets.

IT For incidents and alerts that are associated with operational activities for ensuring availability and reliability
in system performance. For example, server outages, network connectivity issues, application performance
problems, or IT tasks.

Hunting For incidents and alerts that are associated with identifying and mitigating potential security threats before
they cause any damage. For example, monitoring network traffic, analyzing logs, and conducting
vulnerability assessments.

You can see all domains under Configurations → Object Setup → Incidents → Domains. From this tab you can edit the properties of the built in domains, and
create your own domains for non-security use cases. For more information, see Create an incident domain.

NOTE:

Consider the following information:

You can't merge incidents with different domains, and you can't move alerts between incidents with a different domains.

SmartScore is currently supported for the Security domain only.

For SBAC, there is a new tag family for Incident Domains, and new tags for each domain that enable you to control access to your domains.

Domains might affect custom content that is connected to incidents and alerts. Review you custom content to ensure it is associated with the intended
domains, this includes:

Playbook Triggers

Starring Rules

Notifications

Alert Exclusions

Scoring Rules

XQL that accesses the incident or alert datasets in Scheduled Queries, and Widgets

4.2.1.2 | Create an incident domain

Abstract

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 222/1003
5/8/24, 9:18 AM PDF Export

You can create custom incident domains to help you to differentiate between your work efforts, and effectively manage and prioritize your workload.
WARNING:

Before you add a custom domain, please review the built-in options. For more information, see Incident and alert domains.

We recommend using the built-in domains where possible. Custom domains might not be supported by all content. In addition, custom domains affect Cortex
XSIAM’s ability to learn, correctly identify, and score future incidents.

In addition, alert grouping and Smartscore are only supported for the Security domain.

Custom domains help you to differentiate between your work efforts. You can create tailored workflows for each domain, so that you can effectively manage and
prioritize your workload.

NOTE:

Adding custom domains requires a View/Edit RBAC permission for Incident Properties (under Object Setup).

Once created, a custom incident domain cannot be deleted or renamed.

How to add an incident domain

1. Go to Configurations → Object Setup → Incidents → Domains .

The existing domains are listed.

2. Click + New Domain.

3. Assign a name and color to the domain, and an optional description.

4. In the Status field, select one or more statuses that are relevant to the domain. These statuses will be available for selection in the incidents and alerts
associated with this domain.

5. In the Resolution Type field, select one or more resolution reasons that are relevant to the domain. These reasons will be available for selection in the
incidents and alerts associated with this domain.

6. Click Save.

7. (Optional) Update SBAC permissions to enable access to the domain.

Go to Configurations → Access Management → User Groups or Users and update the Scope to include the tag for the new domain.

4.2.2 | Create an Incident

Abstract

You can manually create a new incident, assign it to a specific domain, and define custom fields for the incident.

You can create an incident in Cortex XSIAM directly from the user interface to manage all aspects of operations within a single location.

NOTE:

To create an incident manually, you must have the Create incident permission selected under Settings → Access Management → Roles → Components →
Incident Response. To add a playbook to the manually created incident, you must have the Add Trigger Playbook permission selected.

In Incident Response → Incidents, click New Incident and enter all relevant data. If required, you can also include custom fields. Consider the following
information:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 223/1003
5/8/24, 9:18 AM PDF Export

Assign the incident to an incident domain, or use the default domain (Security). Cortex XSIAM provides built-in domains, for more information see Incident
and alert domains.

NOTE:

You can assign an incident to a single domain only, and after incident creation you cannot change the assigned domain.

The severity of a manually generated incident cannot be low.

You can select multiple MITRE ATT&CK tactics and techniques.

Cortex XSIAM validates the Host IP, Local IP, and Remote IP fields.

You can select custom fields from Alerts fields.

If you select Set fields as default for new Security Domain correlations, the custom alert fields that are configured for this incident are saved for all users.
When a user next creates an incident for the same domain, these fields are automatically configured instead of the default field set.

To reset the custom fields to the system default, click Restore Default Field Set.

By default, the Playbook is run Automatically by trigger as defined in the Incident Configuration.

Each incident creation generates one alert. The name, the severity, and the description of the generated alert mirrors the name, the severity, and the
description of the incident.

You can't attach files to manually created incidents.

4.2.3 | External Integrations

Abstract

You can integrate Cortex XSIAM with other security products of Palo Alto Networks, and of third parties as well.

To aid you with threat investigation, Cortex XSIAM displays the WildFire-issued verdict for each Key Artifactin in an incident. To provide additional verification
sources, you can integrate external threat intelligence services with Cortex XSIAM which can then be displayed for each Key Artifactin in an incident. Cortex
XSIAM supports the following integrations.

Integration Description

Threat Intelligence

WildFire Cortex XSIAM automatically includes WildFire threat intelligence in the incident and
alert investigation. WildFire detects known and unknown threats, such as malware.
The WildFire verdict contains detailed insights into the behavior of identified threats.
The WildFire verdict displays next to relevant Key Artifacts in the incidents details
page. See Review WildFire Analysis Details for more information.

AutoFocus™ AutoFocus groups conditions and indicators related to a threat with a tag. Tags can
be user-defined or come from threat-research team publications and are divided into
classes, such as exploit, malware family, and malicious behavior. See the
AutoFocus Administrator’s Guide for more information on AutoFocus tags.

To view AutoFocus tags in Cortex XSIAM incidents, you must obtain the license key
for the service and add it to the Cortex XSIAM Configuration. When you add the
service, the relevant tags display in the incident details page under Key Artifacts.

VirusTotal VirusTotal provides aggregated results from over 70 antivirus scanners, domain
services included in the block list, and user contributions. The VirusTotal score is
represented as a fraction, where, for example, a score of 34/52 means out of 52
queried services, 34 services determined the artifact to be malicious.

To view VirusTotal threat intelligence in Cortex XSIAM incidents, you must obtain the
license key for the service and add it to the Cortex XSIAM Configuration. When you
add the service, the relevant VirusTotal (VT) score displays in the incident details
page under Key Artifacts.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 224/1003
5/8/24, 9:18 AM PDF Export

Incident Management

Integration Description

Third-party To manage incidents from the application of your choice, you can use the Cortex XSIAM API Reference to send alerts and alert details to
ticketing an external receiver. After you generate your API key and set up the API to query Cortex XSIAM , external apps can receive incident
systems updates, request additional data about incidents, and make changes such as setting the status and changing the severity or assigning
an owner. To get started, see the Cortex XDR API Reference guide.

4.2.4 | Manage Incident Starring

Abstract

Create an incident starring configuration that categorizes and stars incidents when alerts contain attributes that you decide are important.

To help you focus on the incidents that matter most, you can star an incident. Cortex XSIAM identifies starred incidents with a purple star. You can star incidents
in two ways: You can manually star an incident after reviewing it, or you can create an incident starring configuration that automatically categorizes and stars
incidents when a related alert contains the specific attributes that you decide are important.

After you define an incident starring configuration, Cortex XSIAM adds a star indicator to any incidents that contain alerts that match the configuration.

You can then sort or filter the Incidents table for incidents containing starred alerts and similarly filter the Alerts table for starred alerts. In addition, you can also
choose whether to display all incidents or only starred incidents on the Incidents Dashboard.

Incident Starring supports SBAC. The following parameters are considered when editing a starring policy:

If Scoped Sever Access is enabled and set to restrictive mode, you can edit a policy if you are scoped to all tags in the policy.

If Scoped Sever Access is enabled and set to permissive mode, you can edit a policy if you are scoped to at least one tag listed in the policy.

If a policy was added when set to restrictive mode, and then changed to permissive (or vice versa), you will only have view permissions.

Star a Specific Incident

To manually star an incident during or after investigation:

1. Select Incident Response → Incidents.

2. From the Incident List, locate the incident you want to star.

3. Select the star icon.

Create a Starring Configuration

To proactively star alerts and incidents containing alerts, create a starring configuration.

1. Select Incident Response → Incident Configuration → Starred Alerts.

2. + Add Starring Configuration.

3. Enter a Configuration Name to identify your starring configuration.

4. Enter a descriptive Comment that identifies the reason or purpose of the starring configuration.

5. Use the alert filters to build the match criteria for the policy.

You can also right-click a specific value in the alert to add it as match criteria. The app refreshes to show you which alerts in the incident would be
included.

6. Create the policy and confirm the action.

If you later need to make changes, you can view, modify, or delete the exclusion policy from the Investigation → Incident Management → Starred Alerts
page.

4.2.5 | Manage Incident Scoring

Abstract

From the Cortex XSIAM management console, you can prioritize incidents based on the requirements of your organization by assigning score to incidents.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 225/1003
5/8/24, 9:18 AM PDF Export

Cortex XSIAM uses stitching logic to gather and assign alerts to incidents based on a set of rules which take into account different alert attributes, such as
SHA256 of files that are involved and IP addresses. The incidents displayed in the Incidents Table can be prioritized according to these alert attributes.

To enable you to prioritize incidents that are significant to the needs of your organization, you can assign one of the following scores to each incident:

Manual Score-User-defined score

Scoring Rules-Rule-based score determined by a set of alert attributes and assets you define.

When an alert is triggered, Cortex XSIAM matches the alert with each of the custom incident rules you created. If the alert matches one or more of the
rules, the alert is given the score defined by each rule. An incident rule can also contain a sub-rule that allows you to create a rule hierarchy. Where a sub-
rule exists, if the same alert matches one or more of the sub-rules, the alert is also given the score defined by each sub-rule. By default, a score is applied
only to the first alert that matches the defined rule and sub-rule. Within each incident, Cortex XSIAM aggregates the alert scores and assigns the incident
a total score.

NOTE:

A sub-rule score is only applied to an alert if the top-level rule was a match.

SmartScore-Automatic calculated score, based on machine learning.

SmartScore relies on machine learning, statistical analysis, incident attributes, and cross-customer insights to identify high-risk incidents. When an alert is
triggered, Cortex XSIAM calculates the SmartScore according to the compiled data.

For Cortex XSIAM to calculate the SmartScore, you must ensure the Cortex XSIAM - Analytics is enabled in Settings → Configurations → Cortex XSIAM-
Analytics.

NOTE:

Enabling SmartScore subsequently impacts the User Score.

Incident Scoring supports SBAC. The following parameters are considered when editing a rule:

If Scoped Sever Access is enabled and set to restrictive mode, you can edit a rule if you are scoped to all tags in the rule.

If Scoped Sever Access is enabled and set to permissive mode, you can edit a rule if you are scoped to at least one tag listed in the rule.

To change the order of a rule, you must have permissions to the other rule/s of which you want to change the order.

If a rule was added when set to restrictive mode, and then changed to permissive (or vice versa), you will only have view permissions.

Set Your Incident Scores

For Cortex XSIAM to assign the incident scores, you need to first enable the SmartScore and define your Rule Based Scores.

Incident scores are assigned according to a prioritized order where Manual Score takes precedence over Rule Based Scores and SmartScore, and Rule Based
Scores over SmartScore. Dependent on sufficient data collected by Cortex XSIAM, incidents with no scores are assigned a SmartScore.

Enable Cortex XSIAM SmartScore

Navigate to Incident Response → Incident Configuration → Incident Scoring and enable SmartScore.

NOTE:

On the first activation, it can take up to 48 hours for SmartScore to calculate and display the score.

Define Scoring Rules

1. Navigate to Incident Response → Incident Configuration → Scoring Rules.

The Scoring Rules table displays the rules and, if applicable, the sub-rules.

2. Select Add Scoring Rule to define the rule criteria.

3. In the Create New Scoring Rule dialog, define the following:

1. Rule Name—Enter a unique name for your rule.

2. Score—Set a numeric value that is applied to an alert matching the rule criteria.

3. Base Rule—Select whether to create a top-level rule, Root, or sub-rule, listed Rule Name (ID:#). By default, rules are defined at the root level.

4. Comment—Enter an optional comment.

5. Mark whether to Apply score only to first alert of incident—By selecting this option you choose to apply the score only to the first alert that matches
the defined rule. Subsequent alerts of the same incident will not receive a score from this rule again. By default, a score is applied only to the first
alert that matches the defined rule and sub-rule.

6. Determine which alert attribute you want to use as the rule match criteria. Use the filter at the top of the table to build your rule criteria.

4. Review the rule criteria and Create the incident rule.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 226/1003
5/8/24, 9:18 AM PDF Export

You are automatically redirected to the Scoring Rules table.

5. In the Scoring Rules table, Save your scoring rule.

NOTE:

If you're a scoped user, a small lock icon indicates that you don't have permissions to edit a rule.

Manage Your Incident Scores

The incident score is displayed in the Incidents view as a filterable field in the Incident table, Score, and as a score box in the Details Pane.

To easily manage your scores, you can edit and refine existing scoring rules and also update an existing incident score directly from the Incidents view.

Refine Existing Scoring Rules

In the Scoring Rules table review your existing rules and sub-rules.

Use the to rearrange a rule. Make sure to Save after any changes you make.

Right-click one rule or select more than one to:

Edit rule—Edit the rule criteria for an existing rule.

Delete rule—Remove a rule and the sub-rules.

Disable / Enable rule—Disables or enables rule. Disabled rules appear in the table but are grayed out and you cannot perform any actions on them.

Copy rule—Copy the rule criteria to a clipboard to create a sub-rule. Locate the rule you want to add a sub-rule, right-click and Paste “rule name”.

Add sub-rule—Add a sub-rule to an existing rule.

Save your changes.

Update Existing Incident Score

To change an existing incident score:

From the Incident table- Right-click the score box and select Manage Incident Score.

From the Details Pane- Select the score box to open the Manage Incident Score dialog.

In the Manage Incident Score dialog, select the type of score you want to assign to the incident:

Rule based score-Determined according to the Scoring Rule matching the alerts trigged in the incident.

SmartScore-Determined according to the calculated score.

In cases where you see a discrepancy with the assigned SmartScore you can send a numeric and textual feedback form to Cortex XSIAM. The feedback
is sent anonymously and is used to improve the calculations.

NOTE:

Ensure you are not including any PII data in the feedback form.

Manual Score-A user-defined score that overrides the rule base and SmartScore scores.

4.2.6 | Featured Fields

Abstract

Highlight important alerts by tagging specific alert attributes, such as host names, user names, IP addresses, and Active Directory.

Highlight alerts that are important to you by tagging specific alert attributes, such as host names, user names, IP addresses, and Active Directory, as featured
fields. This can help you track alerts in the Alerts table.

4.2.7 | Triage Incidents

Abstract

Triage your incidents using the incident view tabs.

To help you triage and investigate your incidents, Cortex XSIAM displays your incidents in a split-pane view allowing you to easily investigate the entire scope
and cause of an event, view all relevant assets, suspicious artifacts, and alerts within the incident details.

Navigate to Incident Response → Incidents. The Incident split-pane view is divided into two main sections:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 227/1003
5/8/24, 9:18 AM PDF Export

Incident List

Details Pane

NOTE:

The Details pane includes two views, Legacy view and Advanced view. Legacy view allows you to view incidents from earlier versions.

The Incident List enables you to filter and sort according to the incident fields, such as status, score, severity, and timestamp. Each incident displays a summary
of the incident severity, assignee, status, creation time, description, and assets. From the Incident List you can also review additional information.

The Details pane displays the information of the selected incident in the Incident List. The pane is made up of the following tabs that allow you to further
investigate and manage each incident.

Overview—Made up of an Incident Header listing the incident details, the MITRE tactics and techniques, and widgets that present a breakdown of alerts
by severity and sources, automation details, artifacts, hosts, and users associated with the incident. Select the pin icon next to the tab name to always
display a specific tab first when you investigate incidents.

Key Assets & Artifacts—Displays the incident asset and artifact information of hosts, users, and key artifacts associated with the incident.

Alerts & Insights—Displays a table of the alerts and insights associated with the incident.

Timeline—A chronological representation of alerts and actions relating to the incident.

Incident War Room—Real-time investigation is facilitated through the Incident War Room, which is powered by ChatOps, and helps analysts perform
different tasks related to their incident investigation using CLI commands. For example, running real-time security actions through the CLI, without
switching consoles, and running security playbooks, scripts, and commands.

Executions—Displays the causality chains associated with the incident.

4.2.8 | Manage Incidents

Abstract

Lean how to investigate and manage your incidents.

The Incident view allows you to track incidents, investigate incident details and take remedial action. Navigate to Incident Response → Incidents and locate the
incident you want to investigate.

NOTE:

If you do not have permissions to access an asset of an incident (which is shown as grayed out and locked), check your scoping permissions in Manage
Users or Manage User Groups.

Review Incident List Details

To provide a summary of each incident, Cortex XSIAM displays the following incident details for each incident:

1. View the incident severity, score, and assignee. Select whether to Star the incident.

2. View the status of the incident and when it was last updated.

3. Review the incident ID and incident summary.

4. Investigate the incident assets and alert sources:

Review the host name associated with the incident. If there is more than one host, select the [+x] to display the additional host names.

Review the user name associated with the incident. If there is more than one user, select the [+x] to display the additional user names.

Hover over the alert source icons to display the alert source type. Select the alert source icon to display the three most common alerts that were
triggered and how many alerts of each are associated with the incident.

Update Incident Details

The incident header allows you to quickly review and update your incident details. You can update various data such as the severity, incident name, score, and
merge incidents.

1. Change the incident severity.

The default severity is based on the highest alert in the incident. To manually change the severity select the severity tag and choose the new severity.

2. Add or edit the incident name.

Hover over Add incident name and select the pencil icon to add or edit the incident name.

3. Edit the incident description.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 228/1003
5/8/24, 9:18 AM PDF Export

Hover over the incident description and select the pencil icon to edit the incident description.

4. Update the incident score.

Select the Incident Score to investigate how the Rule based score was calculated.

In the Manage incident Score dialog, review the Rule ID, Rule Name, Description, Alert IDs, and the Total Added Score associated with an incident. The
table displays all rules that contributed to the incident total score, including rules that have been deleted. Deleted scores appear with a N/A.

Override the Rule based score by selecting Set score manually and Apply the change.

5. Assign an incident.

Select the assignee (or Unassigned) and begin typing the assignee’s email address for automated suggestions. Users must have logged in to the app to
appear in the auto-generated list.

6. Assign an incident status.

Select the incident Status to update the status to either New, Under Investigation, or Resolved to indicate which incidents have been reviewed and to filter
by status in the incidents table.

When setting an incident to Resolved, select the reason the resolution was resolved, add an optional comment, and select whether to Mark all alerts as
resolved. For more information, see Resolution Reasons for Incidents and Alerts.

7. Merge incidents.

To merge incidents you think belong together, select the ellipsis icon, Merge Incidents and enter the target incident ID you want to merge the incident with.

Incident scoring is managed as follows:

Rule Based Score recalculates the incident score to include the merged incident scores.

Manual Score allows you to enter a score and override the rule-based score.

Incident assignees are managed as follows:

If both incidents have been assigned, the merged incident takes the target incident assignee.

If both incidents are unassigned, the merged incident remains unassigned.

If the target incident is assigned and the source incident is unassigned, the merged incident takes the target assignee.

If the target incident is unassigned and the source incident is assigned, the merged incident takes the existing assignee.

In the merged incident, all source context data is lost even if the target incident does or doesn't contain context data. If the target incident contains
context data, that context data is preserved in the merged incident.

8. Create an exclusion.

Select the ellipsis icon, Create Exclusion and enter the Policy Name. Select the alerts to include in the policy by filtering the Alert table and Create the
exclusion.

9. Review Cortex XSIAM remediation suggestions.

Select the ellipsis icon to open the Remediation Suggestions dialog.

10. Review the incident assets.

Review the number of alerts, alert sources, hosts, users, and wildfire hits associated with the incident. Select Hosts, Users, and Wildfire Hits to display the
asset details.

11. Track and share your investigation progress.

Add notes or comments to track your investigative steps and any remedial actions taken.

Select the Incident Notepad ( ) to add and edit the incident notes. You can use notes to add code snippets to the incident or add a general
description of the threat.

Use the Incident Messenger ( ) to coordinate the investigation between analysts and track the progress of the investigation. Select the comments
to view or manage comments.

If needed, Search to find specific words or phrases in Notepad and Messenger.

Investigate Incident Overview

The incident Overview tab displays the MITRE tactics and techniques, summarized timeline, and interactive widgets that visualize the number of alerts, types of
sources, hosts, and users associated with the incident.

1. Review the incident MITRE tactics and techniques widget.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 229/1003
5/8/24, 9:18 AM PDF Export

Cortex XSIAM displays the number of alerts associated with each tactic and technique. Select the centered arrow at the bottom of the widget to expand
the widget and display the sub-techniques. Hover over a number of alerts to display a link to the MITRE ATT&CK official site.

NOTE:

In some cases, the number of alerts associated with the techniques will not be aligned with the number of the parent tactic because of missing tags or
in case an alert belongs to several techniques.

2. Review the summarized timeline.

The summarized Timeline displays the timestamp of the following four types of actions that occurred in the incident:

When the incident was created.

When the incident was assigned.

If the incident assignee was changed, the action is marked in blue. Select the action to display the history.

When the last alert was added to the incident.

When the incident was resolved.

3. Investigate information about the Alerts,Automation, Alert Sources, and Assets associated with the incident.

In the Alerts widget:

Select See All to pivot to the Alerts & Insights table.

Review the Total number of alerts and the colored line indicating the alert severity. Select the severity tag to pivot to the Alerts & Insights table
filtered according to the selected severity.

In the Automation widget:

If there is an alert that runs a playbook or a playbook recommends a playbook, either select the alert or to view all the alerts in more detail,
select the View in Alerts & Insights tab.

If there are alerts that did not trigger a playbook, select Go To Alerts & Insights to view the alerts and select a playbook, if relevant.

In the Alert Sources widget:

Select See All to pivot to the Alerts & Insights table.

Select each of the alert source types to pivot to the Alerts & Insights table filtered according to the selected alert source.

In the Assets widget:

Select See All to pivot to the Key Assets and Artifacts tab.

Select the host names to display the Details panel. The panel is only available for hosts with Cortex XDR agent installed and displays the host
name, whether it’s connected, along with the Endpoint Details, Agent Details, Network, and Policy information. Use the available actions listed
in the top right-hand corner to take remedial actions.

Review Users that are marked as Featured.

If available, review the User Score allocated to each user.

Investigate Incident Key Assets and Artifacts

The Key Assets & Artifacts tab displays all the incident asset and artifact information of hosts, users, and key artifacts associated with the incident.

1. Navigate to the Key Assets & Artifacts tab.

2. Investigate artifacts.

In the Artifacts section, search for and review the artifacts associated with the incident. Each artifact displays, if available, the following artifact information
and available actions according to the type of artifact; File, IP Address, and Domain.

File Artifact

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 230/1003
5/8/24, 9:18 AM PDF Export

File Details

File name

SHA256 value

Number of alerts in the incident that include the file.

Signature status and signer.

WildFire Report. Select to view the Wildfire Analysis Report.

AutoFocus (AF) tags. Select the tag to display the Source, Tag Class, and Description.

VirusTotal (VT) Score. You can select the score to pivot to the VirusTotal report.

Number of alerts in the incident that include the file according to severity.

Ellipses File Actions

Open in Quick Launcher.

Go to VirusTotal.

Go to AutoFocus.

Search File on all Endpoints.

Open Hash View.

View Related Alerts.

Add to Block List.

Add to Allow List.

IP Address Artifact

IP Address Details

IP Address value and name.

Number of alerts in the incident that include the IP address.

Whether the IP address is External or Internal.

Whois information. Hover to display the Net Range, Registered Date, Registered name, Organization, Updated Date details.

VirusTotal (VT) Score. You can select the score to pivot to the VirusTotal report.

Number of alerts in the incident that include the IP address according to severity.

Ellipsis IP Address Actions

Open in Quick Launcher.

Go to VirusTotal.

Open IP View.

View Related Alerts.

Add to EDL.

Domain Artifact

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 231/1003
5/8/24, 9:18 AM PDF Export

Domain Details

Domain name and IP Address.

Number of alerts that include the domain.

VirusTotal (VT) Score. You can select the score to pivot to the VirusTotal report.

Number of alerts that include the domain according to severity.

Ellipsis Domain Actions

Go to VirusTotal.

Open IP View.

View Related Alerts.

Add to EDL.

3. Investigate hosts.

In the Hosts section, search for and review the hosts associated with the incident. Each host displays, if available, the following host information and
available actions:

Host Details

Icons representing whether an agent is installed on the host and the operating system platform. A green icon indicates the host is connected.

Host Name

IP address associated with the host.

Number of alerts that include the host according to severity.

Ellipsis Host Actions

You can choose to perform an action on multiple hosts by marking the entries you want to include or Select All.

Security Operations > Isolate Endpoint, Initiate Malware Scan, Retrieve Endpoint Files, Initiate Live Terminal.

Open in Quick Launcher.

Open Asset View.

View Related Alerts.

To further investigate the host:

Select the host name to display the Details panel. The panel is only available for hosts with the agent installed and displays the host name, whether it’s
connected, along with the Endpoint Details, Agent Details, Network, and Policy information details. In addition, you can perform the available actions listed
in the top right-hand corner.

4. Investigate users.

In the Users section, search for and review the users associated with the incident. Each user displays, if available, the following user information and
available actions:

User Details

User Name

Whether the user is Featured.

The User Score if available.

Active Directory and Organization Unit names. Hover to display if the name is an Active Directory or OU.

Workday icon. Hover to display the Workday information.

Number of alerts that include the user according to severity.

Ellipsis User Actions

View Related Alerts.

Open User View.

Investigate Incident Alerts and Insights

Abstract

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 232/1003
5/8/24, 9:18 AM PDF Export

You can review the details of alerts and insights related to the incident.

The Alerts & Insights tab displays a table of the alerts and insights associated with the incident.

1. Navigate to the Alerts & Insights tab.

2. Filter the Alerts and Insights tables as you would in the dedicated Cortex XSIAM pages.

3. Select an alert or insight to display the corresponding Details panel. The panel displays the following alert details, if available.

Alert

Alert name, severity, alert source, and rule name.

General

MITRE ATT&CK

Host

Rule

Network Connections

Insight

Insight name, type, source, and description.

General

MITRE ATT&CK

Host

Rule

Process Execution

Use the available actions listed in the top right-hand corner to take remedial actions.

You can also Investigate the alert further in the following tabs that are displayed.

NOTE:

These options are also displayed when you Investigate an alert in the Alerts page.

Investigation

Work Plan

Alert War Room

Run a Playbook on an Alert

You can run or rerun a playbook on one or more alerts. If there is currently a playbook running on one or more of the selected alerts, the Run Playbook option
does not appear. If a playbook is running on the alert, but has been paused (for example, waiting for a user action), you can select to rerun the playbook or
select a new playbook.

1. Right-click one or more alerts in the Alerts Table or the Alerts & Insights table within an incident and select Run Playbook.

2. If the alerts have a playbook already assigned, choose Rerun current Playbook or Choose another Playbook. If the playbooks do not have a playbook
assigned, Choose a Playbook.

3. If you are not rerunning the current assigned playbook, select a playbook to run for the selected alert(s).

4. Run the playbook.

Investigate Incident Timeline

The incident Timeline tab is a chronological representation of alerts and actions relating to the incident.

To begin investigating:

1. Navigate to the Timeline tab and filter the actions according to the following action types:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 233/1003
5/8/24, 9:18 AM PDF Export

All actions

Alerts

Response Actions

Incident Management Actions

Automatic Incident Updates

Automation

2. Investigate timeline entry.

Each timeline entry is a representation of a type of action that was triggered in the alert. Alerts that include the same artifacts are grouped into one
timeline entry and display the common artifact in an interactive link. Depending on the type of action, you can select the entry, host names, and artifacts to
further investigate the action:

Locate the action you want to investigate:

Response and Management Actions ( )—Add and view comments relating to this action.

Alert and Automatic Updates ( )—Display the Details panel. In the panel, navigate to the Alerts tab to view the Alerts table filtered according
to the Alert ID, the Key Assets to view a list of Hosts and Users associated to the alert, and an option to add Comments.

Select the Host name to display, if available, the endpoint data.

Select the Artifact to display the following type of information:

Hash Artifact—Displays the Verdict, File name, and Signature status of the hash value. Select the hash value to view the Wildfire Analysis
Report, Add to Block list, Add to Allow list and Search file.

Domain Artifact—Displays the IP address and VT score of the domain. Select the domain name to Add to EDL.

IP Address—Display whether the IP address is Internal or External, the Whois findings, and the VT score. Expand Whois to view the findings
and Add to EDL.

In action entries that involved more artifacts, expand Additional artifacts found to further investigate.

Investigate Incident Executions

The Executions tab displays all the alert causality chains associated with the incident. The causality chains are aggregated according to the following types of
groupings:

Host Name

Host with an agent installed

Host without an agent installed

Multiple Hosts

Undetected Host

User Name

Username

Multiple Users

Undetected Users

NOTE:

Cloud related alerts are displayed in the User Name grouping.

Prisma Cloud Compute alerts are displayed in the Host Name grouping.

1. Navigate to the Executions tab.

2. Investigate the host causality chains.

In the Executions section, search for and review the hosts associated with the incident. Each host displays, if available, the following host information and
available actions:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 234/1003
5/8/24, 9:18 AM PDF Export

Execution Details

Icons representing whether an Agent is installed on the host and the operating system platform. A green icon indicates the host is connected.

Host Name

IP address associated with the host.

Alert Sources associated with this host.

Number of alerts that include the host according to severity.

Ellipsis Execution Actions

Select the ellipsis to perform the following action on the host:

Security Operations > Isolate Endpoint, Initiate Malware Scan, Retrieve Endpoint Files, Initiate Live Terminal

Open in Quick Launcher

Open Asset View

View Related Alerts

3. Investigate a causality chain.

The causality chains are listed according to the Causality Group Owner (CGO), expand the CGO card you want to investigate. Each CGO card displays
the CGO name, the following CGO event details, and the causality chain:

CGO Name

Alert Sources associated with the entire causality chain

Execution time of the causality chain

Number of alerts that include the CGO according to severity.

Expand the causality chain to further investigate and perform available Causality View actions.

4.2.8.1 | Resolution Reasons for Incidents and Alerts

Abstract

Describes the resolution reasons for incidents and alerts.

When an incident or alert is resolved, select the Resolution status and specify one of the following resolution reasons:

Resolution Reason Description

Resolved - True The incident was correctly identified by Cortex XSIAM as a real threat, and the incident was successfully handled and resolved.
Positive
NOTE:

Incidents resolved as True Positive and False Positive help Cortex XSIAM to identify real threats in your environment by
comparing future incidents and associated alerts to the resolved incidents. Therefore, the handling and scoring of future
incidents is affected by these resolutions.

Resolved - False The incident is not a real threat.

Positive
NOTE:

Incidents resolved as True Positive and False Positive help Cortex XSIAM to identify real threats in your environment by
comparing future incidents and associated alerts to the resolved incidents. Therefore, the handling and scoring of future
incidents is affected by these resolutions.

Resolved - Security The incident is related to security testing or simulation activity such as a BAS, pentest, or red team activity.
Testing

Resolved - Known The incident is related to an existing issue or an issue that is already being handled.
Issue

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 235/1003
5/8/24, 9:18 AM PDF Export

Resolution Reason Description

Resolved - Duplicate The incident is a duplicate of another incident.

Incident

If you created a custom resolution, it is also available for selection. For more information, see Adding Custom Incident Statuses and Resolution Reasons.

4.2.8.2 | Adding Custom Incident Statuses and Resolution Reasons

Abstract

Add custom incident status and resolutions to your workflow.

WARNING:

Before you add a custom status, please review the built-in options. For more information, see Resolution Reasons for Incidents and Alerts.

We recommend using the built-in statuses and resolution reasons where possible. Custom statuses and resolution reasons might not be supported by all
content, and status syncing can take time.

In addition, custom statuses affect Cortex XSIAM’s ability to learn, correctly identify, and score future incidents.

You can create custom incident statuses and custom resolution reasons that are tailored to your workflow. Custom incident statuses and resolution reasons
apply to incident and alert statuses, and can also be used in playbooks.

Adding custom incident statuses and resolution reasons requires a View/Edit RBAC permission for Incident Properties (under Object Setup).

How to create custom incident statuses

1. Go to Configurations+Object Setup+Incidents+Properties.

The existing statuses and resolution types are listed.

2. In the Add another status field, type a new status and click Save.

3. Click Edit to rearrange the order of the statuses. This order is presented when you set a status or select a resolution type.

4.3 | Search Queries

Abstract

Search data by creating Queries in the Query Builder.

To support investigation and analysis, you can search your data by creating queries in the Query Builder. You can create queries with the Cortex Query
Language (XQL) or by using the Query Builder templates.

4.3.1 | XQL Search

Abstract

Use the Cortex Query Language (XQL) to query data ingested into Cortex XSIAM, for rigorous endpoint and network event analysis.

The Cortex Query Language (XQL) enables you to query data ingested into Cortex XSIAM for rigorous endpoint and network event analysis. To help you create
an effective XQL query with the proper syntax, the query field in the user interface provides suggestions and definitions as you type.

XQL forms queries in stages. Each stage performs a specific query operation and is separated by a pipe character (|). Queries require a dataset, or data
source, to run against. You can either query the Cortex Data Model (XDM) to which datasets are mapped, or you can query specific datasets. In a dataset query,
unless otherwise specified, the query runs against the xdr_data dataset, which contains all log information that Cortex XSIAM collects. In XDM queries, the
xdr_data dataset is mapped to the XDM, by default, with some data mapping exceptions. In addition, Next-Generation Firewall (NGFW) network log data are
mapped to the XDM from various datasets.

XQL queries can contain different components depending on the type of query you want to build. For a complete list of the syntax options available with example
queries, see the Cortex XSIAM XQL Language Reference Guide.

IMPORTANT:

Forensic datasets are not inlcuded by default in XQL Search query results, unless the dataset query is explicitly defined to use a forensic dataset.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 236/1003
5/8/24, 9:18 AM PDF Export

Cortex Data Model

The Cortex Query Language (XQL) supports a single Cortex Data Model (XDM), which is a normalized data structure. Datasets are mapped to the XDM in 3
different ways:

1. The xdr_data dataset is automatically mapped to the XDM with some data mapping exceptions (default). In addition, Next-Generation Firewall (NGFW)
network log data are mapped to the XDM from the following datasets.

panw_ngfw_traffic_raw

panw_ngfw_threat_raw

panw_ngfw_url_raw

panw_ngfw_filedata_raw

panw_ngfw_globalprotect_raw

panw_ngfw_hipmatch_raw

2. Out-of-the-box mappings of the datasets as part of the Data Model Rules via the Marketplace. For more information, see Marketplace.

3. You can create your own mappings by creating your own Data Model Rules. For more information, see Create Data Model Rules.

For more information on the XDM Schema, specifically the fields, fieldsets, fields designated as ENUMS (CONST), and aliases, see the Cortex XSIAM Data
Model Schema.

XDM Queries

The basic syntax structure for querying the Cortex Data Model (XDM) is:

datamodel
| <STAGE> ...
| <STAGE> ...
| <STAGE> ...

In a query using the datamodel command, unless specific datasets are specified, a query will run against all mapped datasets, which contain log information
ingested by Cortex XSIAM. You can also install Marketplace Content Packs, or map an ingested dataset into the XDM, to query additional datasets.

In XDM queries that specify datasets, use either of the following syntax:

datamodel dataset in (<dataset_name>,...) …

or

datamodel dataset = <dataset_name> …

Adding a wildcard suffix (*) is supported in the <dataset_name>, which matches all datasets that are mapped to the data model and begin with the specified
text. For example, datamodel dataset = xdr* or datamodel dataset in (xdr*).

When querying the XDM, fields that are not mapped to the XDM are accessible by <dataset>.<field>. They can be used at any stage of a datamodel query.

When creating XDM queries, auto-suggestions are available, according to the existing XDM fields.

Dataset Queries

In a dataset query, unless otherwise specified, the query runs against the xdr_data dataset, which contains all log information that Cortex XSIAM collects. In a
dataset query, if you are running your query against a dataset that has been set as default, there is no need to specify a dataset. Otherwise, specify a dataset in
your query. The Dataset Queries lists the available datasets, depending on system configuration.

NOTE:

Users with different dataset permissions can receive different results for the same XQL query.

An administrator or a user with a predefined user role can create and view queries built with an unknown dataset that currently does not exist in Cortex
XSIAM. All other users can only create and view queries built with an existing dataset.

When you have more than one dataset or lookup, you can change your default dataset by navigating to Settings → Configurations → Data
Management → Dataset Management, right-click on the appropriate dataset, and select Set as default. For more information about setting default
datasets, see Dataset Management.

The basic syntax structure for querying datasets that are not mapped to the XDM is:

dataset = <dataset name>

| <stage1> ...
| <stage2> ...
| <stage3> ...

or

dataset in (<dataset name>)

| <stage1> ...

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 237/1003
5/8/24, 9:18 AM PDF Export

| <stage2> ...
| <stage3> ...

You can specify a dataset using one of the following formats, which is based on the data retention offerings available in Cortex XSIAM.

Hot Storage queries use the format dataset = <dataset name>. This is the default option. For example:

dataset = xdr_data

Cold Storage queries use the format cold_dataset = <dataset name>. For example:

cold_dataset = xdr_data

NOTE:

You can build a query that investigates data in both a cold dataset and a hot dataset in the same query. In addition, as the hot storage dataset format is
the default option and represents the fully searchable storage, this format is used throughout this guide for investigation and threat hunting. For more
information on hot and cold storage, see Dataset Management.

When using the hot storage default format, this returns every xdr_data record contained in your Cortex XSIAM instance over the time range that you provide to
the Query Builder user interface. This can be a large amount of data, which may take a long time to retrieve. You can use a limit stage to specify how many
records you want to retrieve.

There is no practical limit to the number of stages that you can specify. See Stages Commands Reference for information on all the supported stages.

In the xdr_data dataset, every user field included in the raw data for network, authentication, and login events has an equivalent normalized user field
associated with it that displays the user information in the following standardized format:

<company domain>\<username>

For example, the login_data field has the login_data_dst_normalized_user field to display the content in the standardized format. To ensure the most
accurate results, we recommend that you use these normalized_user fields when building your queries.

4.3.1.1 | Useful XQL User Interface Features

Abstract

Learn about useful XQL query features in the user interface.

The user interface contains several useful features for querying data, and for viewing results:

XQL query—The XQL query field is where you define the parameters of your query. To help you create an effective XQL query, the search field provides
suggestions and definitions as you type.

Translate to XQL— Converts your existing Splunk queries to the XQL syntax. When you enable Translate to XQL , both an SPL query field and an XQL
query field are displayed. You can easily add a Splunk query, which is converted automatically into XQL in the XQL query field. This option is disabled by
default.

Query Results—After you create and run an XQL query, you can view, filter, and visualize your Query Results.

XQL Helper—Describes common stage commands and provides examples that you can use to build a query.

Query Library—Contains common, predefined queries that you can use or modify to your liking. In addition, there is a Personal Query Library for saving
and managing your own queries so that you can share with others, and queries can be shared with you.

Schema—Contains schema information for every field found in the result set. This information includes the field name, data type, descriptive text (if
available), and the dataset that contains the field.

For dataset queries, it contains the list of all the fields of all the datasets that were involved in the query.

For data model queries, it contains the list of all the data model fields.

4.3.1.2 | XQL Query Best Practices

Abstract

Learn about best practices for streamlining XQL queries.

Cortex XSIAM includes built-in mechanisms for mitigating long-running queries, such as default limits for the maximum number of allowed alerts, and for the
maximum number of returned rows. All mapped datasets are searched when querying by the Cortex Data Model (XDM), unless stated otherwise. We therefore
recommend that you refine your query to use system resources and time more efficiently. The following suggestions can help you to streamline your queries:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 238/1003
5/8/24, 9:18 AM PDF Export

Add a smaller limit to queries by using a limit stage. To help reduce the Cortex Query Language (XQL) response time, the default results for an XDM
query or an XQL basic query is limited to 1000, when no limit is explicitly stated in the query. This applies to basic queries with no stages except the
fields stage. This default limit does not apply to widgets, Correlation Rules, public APIs, saved queries, or scheduled queries, where the limit is a
maximum of 1,000,000 results. Therefore, adding a smaller limit can greatly reduce the response time. For example:

datamodel
| fields *host*
| limit 100

Use a small time frame for queries (specify the specific date and time in the custom option, instead of picking the nearest larger option available).

Specify the relevant products/datasets, and exclude irrelevant products/datasets.

Use filters that exclude data, along with other possible filters.

Select the specific fields that you would like to see in the query results.

4.3.1.3 | Expected Results when Querying Fields

Abstract

Learn what to expect in the query results when querying fields.

The following are returned when querying fields:

If specific fields are stated in the fields stage, those exact fields will be returned.

If no fields are stated in the query, the xdm_core fieldset will be returned.

Unmapped fields are treated as NULL. An unmapped field is an xdm field that hasn't been mapped from the relevant datasets (using a Data Model Rule).

By default, the _time system field will be added to all data model queries. However, the _time system field will not be added to queries that contain the
comp stage.

For dataset queries, all current system fields will be returned, even if they are not stated in the query.

For UNION between XDM and dataset, each part of the UNION will return its own fields.

Each new column in the result set created by the alter stage will be added as the last column. You can specify a different column order by modifying the
field order in the fields stage of the query.

Each new column in the result set created by the comp stage will be added as the last column. Other fields that are not in the group by / calculated column
will be removed from the result set (including the core fields and _time system field).

When no limit is explicitly stated in a datamodel query, a maximum of 1000 results are returned (default). When this limit is applied to results, it will be
indicated in the user interface.

4.3.1.4 | Create an XQL Query

Abstract

Learn how to create queries using the Cortex Query Language (XQL).

Use XQL Search to analyze raw log data stored in Cortex XSIAM. You can query either the data model or a dataset, using the following syntax, respectively:

Data model

datamodel
| <STAGE> ...
| <STAGE> ...
| <STAGE> ...

Dataset

dataset = <DATASET NAME>

| <STAGE> ...
| <STAGE> ...
| <STAGE> ...

or

dataset in (<DATASET NAME>)

| <STAGE> ...
| <STAGE> ...
| <STAGE> ...

NOTE:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 239/1003
5/8/24, 9:18 AM PDF Export

For further help constructing queries, use the XQL Language Reference Guide.

Create a Data Model Query

1. From Cortex XSIAM, select Incident Response → Investigation → Query Builder.

2. Select XQL Search.

3. (Optional) To change the default time period against which to run your query, at the top right of the window, select the required time period, or create a
customized one.

4. (Optional) To translate Splunk queries to XQL queries, enable Translate to XQL. If you choose to use this feature, enter your Splunk query in the Splunk
field, click the arrow icon to convert to XQL, and then go to Step 6.

5. Create your query by typing in the query field. Relevant commands, their definitions, and operators are suggested as you type. When multiple suggestions
are displayed, use the arrow keys to select a suggestion and to view an explanation for each one.

a. Type datamodel.

b. Optionally, specify one or more datasets. For example:

datamodel dataset in (xdr_data)

c. Press Enter, and then type the pipe character (|). Select a command, and complete the command using the suggested options.

d. Continue adding stages until your query is complete. For example:

datamodel dataset in (xdr_data)

| filter xdm.source.ipv4 = "10.9.165.1"
| fields xdm.source.ipv4, xdm.source.port
| limit 100

6. Choose when to run your query:

Run the query immediately.

Run the query by the specified date and time, or on a specific date, by selecting the calendar icon ( ).

7. (Optional) The Save As options save your query for future use:

a. BIOC Rule—when compatible, saves the query as a BIOC rule. The XQL query must contain a filter for the event_type field.

b. Correlation Rule.

c. Query to Library—saves the query to your personal query library.

d. Widget to Library—for more information, see View XQL Query Results.

TIP:

While the query is running, you can navigate away from the page. A notification is sent when the query has finished. You can also Cancel the query or run a
new query, where you have the option to Run only new query (cancel previous) or Run both queries.

Create a Dataset Query

1. From Cortex XSIAM, select Incident Response → Investigation → Query Builder.

2. Select XQL Search.

3. (Optional) To change the default time period against which to run your query, at the top right of the window, select the required time period, or create a
customized one.

4. (Optional) To translate Splunk queries to XQL queries, enable Translate to XQL. If you choose to use this feature, enter your Splunk query in the Splunk
field, click the arrow icon to convert to XQL, and then go to Step 6.

5. Create your query by typing in the query field. Relevant commands, their definitions, and operators are suggested as you type. When multiple suggestions
are displayed, use the arrow keys to select a suggestion and to view an explanation for each one.

a. Specify a dataset. For example:

dataset = xdr_data

b. Press Enter, and then type the pipe character (|). Select a command, and complete the command using the suggested options.

c. Continue adding stages until your query is complete. For example:

dataset = xdr_data
| filter agent_os_type = ENUM.AGENT_OS_MAC
| limit 250

6. Choose when to run your query:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 240/1003
5/8/24, 9:18 AM PDF Export

Run the query immediately.

Run the query by the specified date and time, or on a specific date, by selecting the calendar icon ( ).

7. (Optional) The Save As options save your query for future use:

a. BIOC Rule—when compatible, saves the query as a BIOC rule. The XQL query must contain a filter for the event_type field.

b. Correlation Rule.

c. Query to Library—saves the query to your personal query library.

d. Widget to Library—for more information, see View XQL Query Results.

TIP:

While the query is running, you can navigate away from the page. A notification is sent when the query has finished. You can also Cancel the query or run a
new query, where you have the option to Run only new query (cancel previous) or Run both queries.

4.3.1.5 | View XQL Query Results

Abstract

Learn how to view the results returned from an XQL query.

View the results returned from a Cortex Query Language (XQL) query.

1. From Cortex XSIAM, select Incident Response → Investigation → Query Center.

2. Hover over the desired row in the table, and then select Show Results.

3. Use the following options to investigate your query results.

Option Use

Table tab Displays results in rows and columns according to the entity fields. Columns can be filtered, using their filter icons.

More options (kebab icon ) displays table layout options, which are divided into different sections:

In the Appearance section, you can Show line breaks for any text field in the Query Results. By default, the text in these fields
are wrapped unless the Show line breaks option is selected. In addition, you can change the way rows and columns are
displayed.

In the Log Format section, you can change the way that logs are displayed:

RAW—Raw format of the entity in the database.

JSON—Condensed JSON format with key value distinctions. NULL values are not displayed.

TREE—Dynamic view of the JSON hierarchy with the option to collapse and expand the different hierarchies.

In the Search column section, you can find a specific column; enable or disable display of columns using the checkboxes.

Show and hide rows according to a specific field in a specific event: select a cell, right-click it, and then select either Show rows with
… or Hide rows with …

Graph tab Use the Chart Editor to visualize the query results.

Advanced Displays results in a table format which aggregates the entity fields into one column. You can change the layout, decide whether to
tab Show line breaks for any text field in the results table, and change the log format from the menu.

Select Show more to pivot an Expanded View of the event results that include NULL values. You can toggle between the JSON and
Tree views, search, and Copy to clipboard.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 241/1003
5/8/24, 9:18 AM PDF Export

Option Use

Export to Exports the results to a TSV (tab-separated values) file.

File
More options ( ) works in a similar way to how it works on the Table tab.

Show more in the bottom left corner of each row opens the Expanded View of the event results that also include NULL values.
Here, you can toggle between the JSON and Tree views, search, and Copy to clipboard.

Log format options change the way that logs are displayed:

RAW—Raw format of the entity in the database.

JSON—Condensed JSON format with key value distinctions. NULL values are not displayed.

TREE—Dynamic view of the JSON hierarchy with the option to collapse and expand the different hierarchies.

Refresh Refreshes the query results.

Free text Searches the query results for text that you specify in the free text search. Click the Free text search icon to reveal or hide the free
search text search field.

Filter Enables you to filter a particular field in the interface that is displayed to specify your filter criteria.

For integer, boolean, and timestamp (such as _time) fields, we recommend that you use the Filter instead of the Free text search, in
order to retrieve the most accurate query results.

Fields menu Filters query results. To quickly set a filter, Cortex XSIAM displays the top ten results from which you can choose to build your filter.

From within the Fields menu, click on any field (excluding JSON and array fields) to see a histogram of all the values found in the
result set for that field. This histogram includes:

A count of the total number of times a value was found in the result set.

The value's frequency as a percentage of the total number of values found for the field.

A bar chart showing the value's frequency.

NOTE:

In order for Cortex XSIAM to provide a histogram for a field, the field must not contain an array or a JSON object.

4. (Optional) Save the query to your personal query library.

5. (Optional) Continue investigation in the Causality View or Timeline View.

Right-click the event and select the desired view. This option is available for the following types of events: process (except for those with an event sub-
type of termination), network, file, registry, injection, load image, system calls, event logs for Windows, and system authentication logs for Linux. For
network stories, you can pivot to the Causality View only. For cloud Cortex XSIAM events and Cloud Audit Logs, you can only pivot to the Cloud Causality
View, while software-as-a-service (SaaS) related alerts for audit stories, such as Office 365 audit logs and normalized logs, you can only pivot to the SaaS
Causality View.

6. (Optional) Add a file path to your existing Malware Profile allowed list. Right-click a <path> field, such as target_process_path, and select Add <path type>
to malware profile allow list.

7. (Optional) Visualize your query results.

4.3.1.6 | Translate to XQL

Topic Not Found

4.3.1.7 | Visualize Query Results

Abstract

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 242/1003
5/8/24, 9:18 AM PDF Export

Cortex XSIAM enables you to generate helpful visualizations of your XQL query results.

To help you better understand your Cortex Query Language (XQL) query results and share your insights with others, Cortex XSIAM enables you to generate
visualizations of your query data directly from the XQL Search page.

1. Select Incident Response → Investigation → Query Builder → XQL.

2. Run an XQL query.

For example, enter dataset = xdr_data | fields action_total_upload, _time | limit 10. The query returns the action_total_upload, a
number field, and _time, a string field, for up to 10 results.

3. In the Query Results section, to visualize the results either:

a. Navigate to Query Results → Chart Editor ( ) to manually build and view the graph using the selected visualization parameters.

Main

Graph Type—Type of visualization; Area, Bubble, Column, Funnel, Gauge, Line, Map, Pie, Scatter, Single Value, or Word Cloud.

Subtype and Layout—Depending on the selected type of graph, choose from the available display options.

Header—Title your graph.

Show Callouts—Display numeric values on graph.

Data

X-axis—Select a field with a string value.

Y-axis—Select a field with a numeric value.

Depending on the selected type of graph, customize the Color, Font, and Legend.

b. Enter the visualization parameters in the XQL query section.

You can express any chart preferences in XQL. This is helpful when you want to save your chart preferences in a query and generate a chart every
time that you run it. To define the parameters, either:

Manually enter the parameters, for example, view graph type = column subtype = grouped header = “Test 1” xaxis = _time
yaxis = _product,action_total_upload.

Select ADD TO QUERY to insert your chart preferences into the query itself.

4. (Optional) Create a custom widget.

To easily track your query results, you can create custom widgets based on the query results in the Manage Your Widget Library. The custom widgets you
create can be used in your custom dashboards and reports.

Select Save to Widget Library to pivot to the Widget Library and generate a custom widget based on the query results.

4.3.2 | About the Query Builder

Abstract

Build XQL queries that search your ingested data, and assist you in the investigation and analysis process. You can use a query template or build your own.

To support investigation and analysis, you can search all of the data ingested by Cortex XSIAM by creating queries in the Query Builder. You can create queries
that investigate leads, expose the root cause of an alert, perform damage assessment, and hunt for threats from your data sources.

Cortex XSIAM provides different options in the Query Builder for creating queries:

XQL Search (Build your own queries)

You can use the Cortex Query Language (XQL) to build complex and flexible queries that search specific datasets or presets, or the entire Cortex Data
Model (XDM). With XQL Search you create queries based on stages, functions, and operators. To help you build your queries, Cortex XSIAM provides
tools in the interface that provide suggestions as you type, or you can look up predefined queries, common stages and examples.

Query Builder templates (No XQL knowledge required)

You can use the Query Builder templates to access your data without prior XQL knowledge. The templates include predefined filtering fields and key
fieldsets, and can include any field from the XDM schema.

As the templates are also based on XQL, you can also translate your template queries into XQL. With this flexibility, you can enrich the basic queries
created by templates for more detailed investigation, or use the templates as a starting point for creating complex queries with full XQL functionality.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 243/1003
5/8/24, 9:18 AM PDF Export

Cortex XSIAM saves every query that you run in the Query Center. From the Query Center you can view query results, edit, re-run, or reschedule a query. You
can then visualize your query results in tables or graphs, and create widgets and correlations with the data. You can also save you queries to your own personal
query library.

TIP:

If you prefer to use the Query Builder in Legacy mode, switch the toggle in the header. In Legacy mode, the Query Builder searches predefined datasets only.
To search the full XDM Data Model, switch to New mode or select XQL Search.

4.3.2.1 | Query Builder templates

Abstract

Use Query Builder templates to query your data sets without using the Cortex Query Language.

You can use the Query Builder templates to create effective queries without using the Cortex Query Language (XQL).

From the Query Builder, you can select the following templates:

Basic: Search by IP address, host name, user name and domain.

Free text: Search for a free text string.

Identity: Search by user name and type.

Endpoint: Search by host name, files, and processes.

Network IP: Search by IP address and connection status.

Cloud: Search by cloud provider and zone.

The templates are set up with predefined filtering fields and fieldsets that are specific to the template type. For example, a query built with the Endpoint template
includes fields from fieldset.xdm_endpoint. You can specify values for the default fields and add any other required fields to refine and adapt your search.
The Query Builder templates support any filtering fields from the Cortex Data Model (XDM) schema.

TIP:

To get started with queries, you can run an empty template query with no values specified. The query results will include all of the fields in the template
specific fieldset. Based on the query results, you can run subsequent queries to narrow down your search.

4.3.2.1.1 | Get started with Query Builder templates

Abstract

Information to help you get started with Query Builder templates.

Before you start running queries with Query Builder templates, consider the following information:

Learn about the templates: Although the templates don’t require XQL knowledge, they do require knowledge of operators and other factors.
Understanding how the templates work will help you to build effective queries. For more information, see Considerations for using Query Builder
templates.

Look up field and alias descriptions: The templates are based on the fields and aliases in the Cortex Data Model (XDM). If you want more information
about a field or alias, see the XSIAM Cortex Data Model Schema Guide.

Try out our examples: To help you feel confident with Query Builder templates, start by following our step-by-step examples and tailor them for your
environment. For more information, see Query Builder template examples.

4.3.2.1.2 | Considerations for using Query Builder templates

Abstract

Provides information about using filtering fields and operators in Query Builder templates.

The following sections provide information and considerations for using Query Builder templates.

General considerations

The following general considerations apply to Query Builder templates:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 244/1003
5/8/24, 9:18 AM PDF Export

The query uses an AND operator between the filtering fields.

Separate multiple values with pipes and do not add spaces between the value and the pipe.

Some of the filtering fields are aliases and therefore search all fields that are associated with the alias.

Fields with dropdown options support ENUMs and free text values.

In IP address fields, you can also specify subnets.

The asterisk (*) wildcard is supported, except in subnet values.

You cannot remove the predefined fields, but you can leave them blank.

When filtering integer and float fields, you can only specify two operators from the four available options.

= (equal to) and != (not equal to) operators

Filtering fields support the = (equal to) and != (not equal to) operators, and you can specify both operators for the same field. The following conditions apply to
these operators:

If you specify multiple values for a field with the = operator, the OR operator is applied. For example, User Name = aaa|bbb searches for instances of
user name equal to aaa OR bbb.

If you specify multiple values for a field with the != operator, the AND operator is applied. For example, User Name != aaa|bbb searches for instances of
user name not equal to aaa AND bbb.

If you specify both operators (= and !=) for the same field, the AND operator is applied. For example, COUNTRY = Empty values AND COUNTRY != USA.

>= (greater than and equal) and <= (less than and equal) operators

Filtering fields support the >= (greater than and equal) and <= (less than and equal) operators, and you can specify both operators for the same field. The
following conditions apply to these operators:

Cortex XSIAM supports using these operators for integer and float fields.

Empty values are not supported with these operators.

Include and exclude empty values

You can use the Empty values field to include or exclude fields with empty values and strings. In the search results, some fields might return empty values. This
occurs if no data is mapped to a field. The following conditions apply to the Empty values field:

If you specify = and select Empty values, the query includes fields with empty values with an OR operator.

For example, _vendor = aaa OR _vendor = Empty values searches the _vendor field for any instances of aaa or empty values.

If you specify != and select Empty values, the query excludes fields with empty values with an AND operator.

For example, _vendor != aaa AND _vendor != Empty values searches the _vendor field for values that are not equal to aaa AND do not contain
empty values.

If you specify != and select Empty values for an alias, you might not receive any results. The query searches all of the fields associated with the alias for
non-empty values. If any of the associated fields contain empty values, no results are returned.

For example, User Name != aaa AND User Name != Empty values searches the User Name alias fields for values that are not equal to aaa AND
empty values. If the query finds either aaa or empty values in any of the alias fields, no results are returned.

4.3.2.1.3 | Create a query from a template

Abstract

Explains how to run queries with Query Builder templates that do not require prior Cortex Query Language (XQL) knowledge.

You can use the Query Builder templates to create effective queries without using the Cortex Query Language (XQL).

Review the following topics:

Query Builder templates

Get started with Query Builder templates

Considerations for using Query Builder templates

How to create a query from a Query Builder template

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 245/1003
5/8/24, 9:18 AM PDF Export

1. Select Incident Response → Investigation → Query Builder.

2. In the Query Builder, select the template that you want to use.

If you want to use the Free Text Search template, see Run a free text query.

3. Enter values for any of the predefined fields and specify whether to include Empty values in the query.

Guidelines

The query uses an AND operator between the filtering fields.

Separate multiple values with pipes and do not add spaces between the value and the pipe.

Some of the filtering fields are aliases and therefore search all fields that are associated with the alias.

You can run an empty template with no values specified. The query results will show data from all of the fields in the template specific fieldset.

For more information about using the filtering fields, operators, and including Empty values, see Considerations for using Query Builder templates.

4. (Optional) Click Add Field and select the additional filtering fields or aliases to include in the query."

NOTE:

Field names and aliases are listed without their prefix, for example xdm.SOURCE.USER.USERNAME is listed as SOURCE.USER.USERNAME
and XDM_ALIAS.ipv4 is listed as ipv4.

Fields that are already included in the query template are shown as grayed out.

In the Identity and Network templates, xdm.event.outcome shows as grayed out. In these templates, the ACTION STATUS and CONNECTION
STATUS fields are linked to the xdm.event.outcome enum. Therefore, you can't duplicate this field in a query.

5. Click TIME and select a time frame for the query.

6. Click Run to start the query, or click Schedule to run the query at a specific time.

You can also click Continue in XQL to open the XQL Query Builder showing the defined XQL fields. In XQL you have the flexibility to add additional stages
and functions that are not available in the Query Builder templates.

7. Review the Results.

The search is limited to 1,000 results. In the Fields column, you can see all of the fields that were included in the query in the following order: (1) _time, (2)
the filtering fields that you defined, and (3) the fields from the template specific fieldset.

NOTE:

This order might change if you include a filtering field that is listed in the fieldset. In that case, the field is taken out of the fieldset and ordered at the top
of the list with the other filtering fields.

The query is also saved in the Query Center. In the Query Center, you can identify your query by filtering the Created By column and looking in the Query
Description column. Queries created from a template are prefixed with the template name.
Example 1. Example

The following query searches for instances of IP 3.3.3.3 with a source host name equal to host1 or host2. IP is an alias field; therefore, the query searches
all fields associated with the alias.

IP ADDRESS = 3.3.3.3, SOURCE.HOST.OS = host1|host2

The following query searches for the event outcome success with an event duration value that is not equal to null:

EVENT.OUTCOME = XDM_CONST.OUTCOME_SUCCESS, EVENT.DURATION != Empty values

What to do next

To edit or rerun the query, click Back to edit to review the template, or Continue in XQL to review the XQL.

Practice running queries with Query Builder template examples.

4.3.2.1.4 | Run a free text query

Abstract

Query your datasets for free-text strings with the Free text search template.

You can use the Free text template to query your datasets for free-text strings without building a Cortex Query Language (XQL) query. The template queries all
of the datasets that are stored in your tenant and returns up to 1,000 results.

NOTE:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 246/1003
5/8/24, 9:18 AM PDF Export

Free-text search is also available in XQL queries. You can use the search stage to query free-text strings in specific datasets, or all of the datasets in your
tenant.
How to run a free text query

1. Select Incident Response → Investigation → Query Builder.

2. Under General Search, select Free text.

3. In the Text Contains field, type one or more strings. Separate multiple strings with pipes, which applies the OR operator.

4. Click TIME and select a time frame for the query.

NOTE:

Free text search is limited to the last 90 days of data. Specifying a time frame outside of this limitation will cause the query to fail.

5. Click Run to start the query, or click Schedule to run the query at a specific time.

Free text search searches the relevant columns in each dataset. Relevant columns are subject to a change and can vary between datasets.

You can also click Continue in XQL to translate the query with the fields that you specified into XQL. In XQL you have the flexibility to add additional
stages and functions that are not available in the Query Builder templates.

6. Review the results.

The searched string is highlighted in the results.

In the Fields column, you can see all of the fields in which the string was discovered. Fields are listed in the following order: (1) _time, (2) _dataset, and
(3) the fields in which the string was discovered, ordered by highest to lowest number of hits.

In the RAW_DATA column, click Show more to see the specific row in the dataset in which the string was discovered.

What to do next

To edit or rerun the query, click Back to edit to review the template in the Query Builder, or Continue in XQL to review the XQL.

Practice running queries with Query Builder template examples.

4.3.2.1.5 | Query Builder template examples

Topic Not Found

4.3.2.2 | The Legacy Query Builder

Abstract

Explains the entities in the Legacy Query Builder.

NOTE:

We recommend using the Query Builder in New mode to take advantage of the Query Builder templates and ability to search the full XDM Data Model.

In Legacy mode, the Query Builder searches predefined datasets only. To search the full XDM, switch to New mode or select XQL Search.

The Legacy Query Builder provides queries for the following types of entities:

Process—Search on process execution and injection by process name, hash, path, command line arguments, and more. See Create a Process Query.

File—Search on file creation and modification activity by file name and path. See Create a File Query.

Network—Search network activity by IP address, port, host name, protocol, and more. See Create a Network Query.

Registry—Search on registry creation and modification activity by key, key value, path, and data. See Create a Registry Query.

Event Log—Search Windows event logs and Linux system authentication logs by username, log event ID (Windows only), log level, and message. See
Create an Event Log Query.

Network Connections—Search security event logs by firewall logs, endpoint raw data over your network. See Create a Network Connections Query.

All Actions—Search across all network, registry, file, and process activity by endpoint or process. See Query Across All Entities.

The Query Builder also provides flexibility for both on-demand query generation and scheduled queries.

4.3.2.2.1 | Create a File Query

Abstract

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 247/1003
5/8/24, 9:18 AM PDF Export

From the Cortex XSIAM management console, you can create a query to investigate the connections between file activity and endpoints.

From the Query Builder you can investigate connections between file activity and endpoints. The Query Builder searches your logs and endpoint data for the file
activity that you specify. To search for files on endpoints instead of file-related activity, use the XQL Search.

Some examples of file queries you can run include:

Files modified on specific endpoints.

Files related to process activity that exist on specific endpoints.

To build a file query:

1. From Cortex XSIAM, select Incident Response → Investigation → Query Builder.

2. Select FILE.

3. Enter the search criteria for the file events query.

File activity—Select the type or types of file activity you want to search: All, Create, Read, Rename, Delete, or Write.

File attributes—Define any additional process attributes for which you want to search. Use a pipe (|) to separate multiple values (for example
notepad.exe|chrome.exe). By default, Cortex XSIAM will return the events that match the attribute you specify. To exclude an attribute value,
toggle the = option to =!. Attributes are:

NAME—File name.

PATH—Path of the file.

PREVIOUS NAME—Previous name of a file.

PREVIOUS PATH—Previous path of the file.

MD5—MD5 hash value of the file.

SHA256—SHA256 hash value of the file.

ACTION_DISK_DRIVER_NAME—The driver where the file was created.

FILE_SYSTEM_TYPE—Operating system type where the file was run.

ACTION_IS_VFS—Denotes if the file is on a virtual file system on the disk. This is relevant only for files that are written to disk.

DEVICE TYPE—Type of device used to run the file: Unknown, Fixed, Removable Media, CD-ROM.

DEVICE SERIAL NUMBER—Serial number of the device type used to run the file.

To specify an additional exception (match this value except), click the + to the right of the value and specify the exception value.

4. (Optional) Limit the scope to a specific acting process:

Select and specify one or more of the following attributes for the acting (parent) process.

Use a pipe (|) to separate multiple values. Use an asterisk (*) to match any string of characters.

NAME—Name of the parent process.

PATH—Path to the parent process.

CMD—Command-line used to initiate the process including any arguments, up to 128 characters.

MD5—MD5 hash value of the process.

SHA256—SHA256 hash value of the process.

USER NAME—User who executed the process.

SIGNATURE—Signing status of the parent process: Signature Unavailable, Signed, Invalid Signature, Unsigned, Revoked, Signature Fail.

SIGNER—Entity that signed the certificate of the parent process.

PID—Process ID of the parent process.

Run search for process, Causality, and OS actors—The causality actor—also referred to as the causality group owner (CGO)—is the parent
process in the execution chain that the Cortex XDR agent identified as being responsible for initiating the process tree. The OS actor is the parent
process that creates an OS process on behalf of a different indicator. By default, this option is enabled to apply the same search criteria to initiating
processes. To configure different attributes for the parent or initiate the process, clear this option.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 248/1003
5/8/24, 9:18 AM PDF Export

5. (Optional) Limit the scope to an endpoint or endpoint attributes:

Select and specify one or more of the following attributes:

HOST—HOST NAME, HOST IP address, HOST OS, HOST MAC ADDRESS, or INSTALLATION TYPE.

INSTALLATION TYPE can be either Cortex XDR agent or Data Collector.

PROCESS—NAME, PATH, CMD, MD5, SHA256, USER NAME, SIGNATURE, or PID.

Use a pipe (|) to separate multiple values. Use an asterisk (*) to match any string of characters.

6. Specify the time period for which you want to search for events.

Options are Last 24H (hours), Last 7D (days), Last 1M (month), or select a Custom time period.

7. Choose when to run the query.

Select the calendar icon to schedule a query to run on or before a specific date or Run to run the query immediately and view the results in the Query
Center.

While the query is running, you can always navigate away from the page and a notification is sent when the query completes. You can also Cancel the
query or run a new query, where you have the option to Run only new query (cancel previous) or Run both queries.

8. When you are ready, View the Results of a Query.

4.3.2.2.2 | Create a Process Query

Abstract

Create a query to investigate connections between processes, child processes, and endpoints.

From the Query Builder you can investigate connections between processes, child processes, and endpoints.

For example, you can create a process query to search for processes executed on a specific endpoint.

To build a process query:

1. From Cortex XSIAM , select Incident Response → Investigation → Query Builder.

2. Select PROCESS.

3. Enter the search criteria for the process query.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 249/1003
5/8/24, 9:18 AM PDF Export

Process action—Select the type of process action you want to search: On process Execution or Injection into another process.

Process attributes—Define any additional process attributes for which you want to search.

Use a pipe (|) to separate multiple values. Use an asterisk (*) to match any string of characters.

By default, Cortex XSIAM will return results that match the attribute you specify. To exclude an attribute value, toggle the operator from = to !=.
Attributes are:

NAME—Name of the process. For example, notepad.exe.

PATH—Path to the process. For example, C:\windows\system32\notepad.exe.

CMD—Command-line used to initiate the process including any arguments, up to 128 characters.

MD5—MD5 hash value of the process.

SHA256—SHA256 hash value of the process.

USER NAME—User who executed the process.

SIGNATURE—Signing status of the process: Signature Unavailable, Signed, Invalid Signature, Unsigned, Revoked, Signature Fail.

SIGNER—Signer of the process.

PID—Process ID.

PROCESS_FILE_INFO—Metadata of the process file, including file property details, file entropy, company name, encryption status, and
version number.

PROCESS_SCHEDULED_TASK_NAME—Name of the task scheduled by the process to run in the Task Scheduler.

PROCESS_TOKEN_INFORMATION—Bitwise token of the process privileges.

DEVICE TYPE—Type of device used to run the process: Unknown, Fixed, Removable Media, CD-ROM.

DEVICE SERIAL NUMBER—Serial number of the device type used to run the process.

To specify an additional exception (match this value except), click the + to the right of the value and specify the exception value.

4. (Optional) Limit the scope to a specific acting process:

Select and specify one or more of the following attributes for the acting (parent) process.

NAME—Name of the parent process.

PATH—Path to the parent process.

CMD—Command-line used to initiate the parent process including any arguments, up to 128 characters.

MD5—MD5 hash value of the parent process.

SHA256—SHA256 hash value of the process.

USER NAME—User who executed the process.

SIGNATURE—Signing status of the parent process: Signed, Unsigned, N/A, Invalid Signature, Weak Hash

SIGNER—Entity that signed the certificate of the parent process.

PID—Process ID of the parent process.

Run search on process, Causality and OS actors—The causality actor—also referred to as the causality group owner (CGO)—is the parent process
in the execution chain that the Cortex XDR agent identified as being responsible for initiating the process tree. The OS actor is the parent process
that creates an OS process on behalf of a different initiator. By default, this option is enabled to apply the same search criteria to initiating
processes. To configure different attributes for the parent or initiate a process,

5. (Optional) Limit the scope to an endpoint or endpoint attributes:

Select and specify one or more of the following attributes:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 250/1003
5/8/24, 9:18 AM PDF Export

HOST—HOST NAME, HOST IP address, HOST OS, HOST MAC ADDRESS, or INSTALLATION TYPE.

INSTALLATION TYPE can be either Cortex XDR agent or Data Collector.

PROCESS—NAME, PATH, CMD, MD5, SHA256, USER NAME, SIGNATURE, or PID.

6. Specify the time period for which you want to search for events.

Options are Last 24H (hours), Last 7D (days), Last 1M (month), or select a Custom time period.

7. Choose when to run the query.

Select the calendar icon to schedule a query to run on or before a specific date or Run to run the query immediately and view the results in the Query
Center.

While the query is running, you can always navigate away from the page and a notification is sent when the query completes. You can also Cancel the
query or run a new query, where you have the option to Run only new query (cancel previous) or Run both queries.

8. When you are ready, Visualize Query Results.

4.3.2.2.3 | Create a Network Query

Abstract

Create a query to investigate the connections between network activity, acting processes, and endpoints.

From the Query Builder, you can investigate connections between network activity, acting processes, and endpoints.

Some examples of a network query you can run include:

Network connections to or from a specific IP address and port number.

Processes that created network connections.

Network connections between specific endpoints.

To build a network query:

1. From Cortex XSIAM , select INVESTIGATION → Query Builder.

2. Select NETWORK.

3. Enter the search criteria for the network events query.

Network traffic type—Select the type or types of network traffic alerts you want to search: Incoming, Outgoing, or Failed.

Network attributes—Define any additional process attributes for which you want to search. Use a pipe (|) to separate multiple values (for example
80|8080). By default, Cortex XSIAM will return the events that match the attribute you specify. To exclude an attribute value, toggle the = option to
=!. Options are:

REMOTE COUNTRY—Country from which the remote IP address originated.

REMOTE IP—Remote IP address related to the communication.

REMOTE PORT—Remote port used to make the connection.

LOCAL IP—Local IP address related to the communication. Matches can return additional data if a machine has more than one NIC.

LOCAL PORT—Local port used to make the connection.

PROTOCOL—Network transport protocol over which the traffic was sent.

To specify an additional exception (match this value except), click the + to the right of the value and specify the exception value.

4. (Optional) To limit the scope to a specific source, click the + to the right of the value and specify the exception value.

Specify one or more attributes for the source.

Use a pipe (|) to separate multiple values. Use an asterisk (*) to match any string of characters.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 251/1003
5/8/24, 9:18 AM PDF Export

NAME—Name of the parent process.

PATH—Path to the parent process.

CMD—Command-line used to initiate the process including any arguments, up to 128 characters.

MD5—MD5 hash value of the process.

SHA256—SHA256 hash value of the process.

USER NAME—User who executed the process.

SIGNATURE—Signing status of the parent process: Signature Unavailable, Signed, Invalid Signature, Unsigned, Revoked, Signature Fail.

SIGNER—Entity that signed the certificate of the parent process.

PID—Process ID of the parent process.

Run search for process, Causality, and OS actors—The causality actor—also referred to as the causality group owner (CGO)—is the parent
process in the execution chain that the Cortex XDR agent identified as being responsible for initiating the process tree. The OS actor is the parent
process that creates an OS process on behalf of a different indicator. By default, this option is enabled to apply the same search criteria to initiating
processes. To configure different attributes for the parent or initiate the process, clear this option.

5. (Optional) Limit the scope to an endpoint or endpoint attributes:

Specify one or more of the following attributes: Use a pipe (|) to separate multiple values.

Use an asterisk (*) to match any string of characters.

HOST—HOST NAME, HOST IP address, HOST OS, HOST MAC ADDRESS, or INSTALLATION TYPE.

INSTALLATION TYPE can be either Cortex XDR agent or Data Collector.

PROCESS—NAME, PATH, CMD, MD5, SHA256, USER NAME, SIGNATURE, or PID.

6. Specify the time period for which you want to search for events.

Options are Last 24H (hours), Last 7D (days), Last 1M (month), or select a Custom time period.

7. Choose when to run the query.

Select the calendar icon to schedule a query to run on or before a specific date or Run to run the query immediately and view the results in the Query
Center.

While the query is running, you can always navigate away from the page and a notification is sent when the query completes. You can also Cancel the
query or run a new query, where you have the option to Run only new query (cancel previous) or Run both queries.

8. When you are ready, Visualize Query Results.

4.3.2.2.4 | Create an Image Load Query

Abstract

Create a query to investigate the connections between image load activity, acting processes, and endpoints.

From the Query Builder, you can investigate connections between image load activity, acting processes, and endpoints.

Some examples of image load queries you can run include:

Module load into process events by module path or hash.

To build an image load query:

1. From Cortex XSIAM , select INVESTIGATION → Query Builder.

2. Select IMAGE LOAD.

3. Enter the search criteria for the image load activity query.

Type of image activity: All, Image Load, or Change Page Protection.

Identifying information about the image module: Full Module Path, Module MD5, or Module SHA256.

By default, Cortex XSIAM will return the activity that matches all the criteria you specify. To exclude a value, toggle the = option to =!.

4. (Optional) To limit the scope to a specific source, click the + to the right of the value and specify the exception value.

Specify one or more attributes for the source.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 252/1003
5/8/24, 9:18 AM PDF Export

Use a pipe (|) to separate multiple values. Use an asterisk (*) to match any string of characters.

NAME—Name of the parent process.

PATH—Path to the parent process.

CMD—Command-line used to initiate the process including any arguments, up to 128 characters.

MD5—MD5 hash value of the process.

SHA256—SHA256 hash value of the process.

USER NAME—User who executed the process.

SIGNATURE—Signing status of the parent process: Signature Unavailable, Signed, Invalid Signature, Unsigned, Revoked, Signature Fail.

SIGNER—Entity that signed the certificate of the parent process.

PID—Process ID of the parent process.

Run search for both the process and the Causality actor—The causality actor—also referred to as the causality group owner (CGO)—is the parent
process in the execution chain that the app identified as being responsible for initiating the process tree. Select this option if you want to apply the same
search criteria to the causality actor. If you clear this option, you can then configure different attributes for the causality actor.

5. (Optional) Limit the scope to an endpoint or endpoint attributes:

Specify one or more of the following attributes: Use a pipe (|) to separate multiple values.

Use an asterisk (*) to match any string of characters.

HOST—HOST NAME, HOST IP address, HOST OS, HOST MAC ADDRESS, or INSTALLATION TYPE.

INSTALLATION TYPE can be either Cortex XDR agent or Data Collector.

PROCESS—NAME, PATH, CMD, MD5, SHA256, USER NAME, SIGNATURE, or PID.

6. Specify the time period for which you want to search for events.

Options are Last 24H (hours), Last 7D (days), Last 1M (month), or select a Custom time period.

7. Choose when to run the query.

Select the calendar icon to schedule a query to run on or before a specific date or Run to run the query immediately and view the results in the Query
Center.

While the query is running, you can always navigate away from the page and a notification is sent when the query completes. You can also Cancel the
query or run a new query, where you have the option to Run only new query (cancel previous) or Run both queries.

8. When you are ready, View the Results of a Query.

4.3.2.2.5 | Create a Registry Query

Abstract

Create a query to investigate connections between registry activity, processes, and endpoints.

From the Query Builder you can investigate connections between registry activity, processes, and endpoints.

Some examples of a registry query you can run include:

Modified registry keys on specific endpoints.

Registry keys related to process activity that exist on specific endpoints.

To build a registry query:

1. From Cortex XSIAM , select INVESTIGATION → Query Builder.

2. Select REGISTRY.

3. Enter the search criteria for the registry events query.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 253/1003
5/8/24, 9:18 AM PDF Export

Registry action—Select the type or types of registry actions you want to search: Key Create, Key Delete, Key Rename, Value Set, or Value Delete.

Registry attributes—Define any additional registry attributes for which you want to search. By default, Cortex XSIAM will return the events that
match the attribute you specify. To exclude an attribute value, toggle the = option to =!. Attributes are:

KEY NAME—Registry key name.

DATA—Registry key data value.

KEY PREVIOUS NAME—Name of the registry key before modification.

VALUE NAME—Registry value name.

To specify an additional exception (match this value except), click the + to the right of the value and specify the exception value.

4. (Optional) To limit the scope to a specific source, click the + to the right of the value and specify the exception value.

Specify one or more attributes for the source.

Use a pipe (|) to separate multiple values. Use an asterisk (*) to match any string of characters.

NAME—Name of the parent process.

PATH—Path to the parent process.

CMD—Command-line used to initiate the process including any arguments, up to 128 characters.

MD5—MD5 hash value of the process.

SHA256—SHA256 hash value of the process.

USER NAME—User who executed the process.

SIGNATURE—Signing status of the parent process: Signature Unavailable, Signed, Invalid Signature, Unsigned, Revoked, Signature Fail.

SIGNER—Entity that signed the certificate of the parent process.

PID—Process ID of the parent process.

Run search for process, Causality, and OS actors—The causality actor—also referred to as the causality group owner (CGO)—is the parent
process in the execution chain that the Cortex XDR agent identified as being responsible for initiating the process tree. The OS actor is the parent
process that creates an OS process on behalf of a different indicator. By default, this option is enabled to apply the same search criteria to initiating
processes. To configure different attributes for the parent or initiate the process, clear this option.

5. (Optional) Limit the scope to an endpoint or endpoint attributes:

Specify one or more of the following attributes: Use a pipe (|) to separate multiple values.

Use an asterisk (*) to match any string of characters.

HOST—HOST NAME, HOST IP address, HOST OS, HOST MAC ADDRESS, or INSTALLATION TYPE.

INSTALLATION TYPE can be either Cortex XDR agent or Data Collector.

PROCESS—NAME, PATH, CMD, MD5, SHA256, USER NAME, SIGNATURE, or PID.

6. Specify the time period for which you want to search for events.

Options are Last 24H (hours), Last 7D (days), Last 1M (month), or select a Custom time period.

7. Choose when to run the query.

Select the calendar icon to schedule a query to run on or before a specific date or Run to run the query immediately and view the results in the Query
Center.

While the query is running, you can always navigate away from the page and a notification is sent when the query completes. You can also Cancel the
query or run a new query, where you have the option to Run only new query (cancel previous) or Run both queries.

8. When you are ready, Visualize Query Results.

4.3.2.2.6 | Create an Event Log Query

Abstract

Create a query to investigate Windows and Linux event log attributes and investigate event logs across endpoints.

From the Query Builder you can search Windows and Linux event log attributes and investigate event logs across endpoints with a Cortex XDR agent installed.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 254/1003
5/8/24, 9:18 AM PDF Export

Some examples of event log queries you can run include:

Critical level messages on specific endpoints.

Message descriptions with specific keywords on specific endpoints.

To build a file query:

1. From Cortex XSIAM , select INVESTIGATION → Query Builder.

2. Select EVENT LOG.

3. Enter the search criteria for your Windows or Linux event log query.

Define any event attributes for which you want to search. By default, Cortex XDR will return the events that match the attribute you specify. To exclude an
attribute value, toggle the = option to =!. Attributes are:

PROVIDER NAME—The provider of the event log.

USERNAME—The username associated with the event.

EVENT ID—The unique ID of the event.

LEVEL—The event severity level.

MESSAGE—The description of the event.

To specify an additional exception (match this value except), click the + to the right of the value and specify the exception value.

4. (Optional) Limit the scope to an endpoint or endpoint attributes:

Specify one or more of the following attributes: Use a pipe (|) to separate multiple values.

Use an asterisk (*) to match any string of characters.

HOST—HOST NAME, HOST IP address, HOST OS, HOST MAC ADDRESS, or INSTALLATION TYPE.

INSTALLATION TYPE can be either Cortex XDR agent or Data Collector.

PROCESS—NAME, PATH, CMD, MD5, SHA256, USER NAME, SIGNATURE, or PID.

5. Specify the time period for which you want to search for events.

Options are Last 24H (hours), Last 7D (days), Last 1M (month), or select a Custom time period.

6. Choose when to run the query.

Select the calendar icon to schedule a query to run on or before a specific dateor Run to run the query immediately and view the results in the Query
Center.

While the query is running, you can always navigate away from the page and a notification is sent when the query completes. You can also Cancel the
query or run a new query, where you have the option to Run only new query (cancel previous) or Run both queries.

7. When you are ready, View the Results of a Query.

4.3.2.2.7 | Create a Network Connections Query

Abstract

Create a query to investigate the connections between firewall logs, endpoints, and network activity.

From the Query Builder, you can investigate network events stitched across endpoints and the Palo Alto Networks next-generation firewall logs.

Some examples of a network query you can run include:

Source and destination of a process.

Network connections that included a specific App ID

Processes that created network connections.

Network connections between specific endpoints.

To build a network query:

1. From Cortex XSIAM , select INVESTIGATION → Query Builder.

2. Select NETWORK CONNECTIONS.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 255/1003
5/8/24, 9:18 AM PDF Export

3. Enter the search criteria for the network events query.

Network attributes—Define any additional process attributes for which you want to search. Use a pipe (|) to separate multiple values (for example
80|8080). By default, Cortex XSIAM will return the events that match the attribute you specify. To exclude an attribute value, toggle the = option to
=!. Options are:

APP ID—App ID of the network.

PROTOCOL—Network transport protocol over which the traffic was sent.

SESSION STATUS

FW DEVICE NAME—Firewall device name.

FW RULE—Firewall rule.

FW SERIAL ID—Firewall serial ID.

PRODUCT

VENDOR

To specify an additional exception (match this value except), click the + to the right of the value and specify the exception value.

4. (Optional) To limit the scope to a specific source, click the + to the right of the value and specify the exception value.

Specify one or more attributes for the source.

Use a pipe (|) to separate multiple values. Use an asterisk (*) to match any string of characters.

HOST NAME—Name of the source.

HOST IP—IP address of the source.

HOST OS—Operating system of the source.

PROCESS NAME—Name of the process.

PROCESS PATH—Path to the process.

CMD—Command-line used to initiate the process including any arguments, up to 128 characters.

MD5—MD5 hash value of the process.

SHA256—SHA256 hash value of the process.

PROCESS USER NAME—User who executed the process.

SIGNATURE—Signing status of the parent process: Signature Unavailable, Signed, Invalid Signature, Unsigned, Revoked, Signature Fail.

PID—Process ID of the parent process.

IP—IP address of the process.

PORT—Port number of the process.

USER ID—ID of the user who executed the process.

Run search for both the process and the Causality actor—The causality actor—also referred to as the causality group owner (CGO)—is the parent
process in the execution chain that the app identified as being responsible for initiating the process tree. Select this option if you want to apply the
same search criteria to the causality actor. If you clear this option, you can then configure different attributes for the causality actor.

5. (Optional) Limit the scope to a destination.

Use a pipe (|) to separate multiple values. Use an asterisk (*) to match any string of characters.

Specify one or more of the following attributes:

REMOTE IP—IP address of the destination.

COUNTRY—Country of the destination.

Destination TARGET HOST,NAME, PORT, HOST NAME, PROCESS USER NAME, HOST IP, CMD, HOST OS, MD5, PROCESS PATH, USER ID,
SHA256, SIGNATURE, or PID

6. Specify the time period for which you want to search for events.

Options are Last 24H (hours), Last 7D (days), Last 1M (month), or select a Custom time period.

7. Choose when to run the query.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 256/1003
5/8/24, 9:18 AM PDF Export

Select the calendar icon to schedule a query to run on or before a specific date or Run to run the query immediately and view the results in the Query
Center.

While the query is running, you can always navigate away from the page and a notification is sent when the query completes. You can also Cancel the
query or run a new query, where you have the option to Run only new query (cancel previous) or Run both queries.

8. When you are ready, Visualize Query Results.

4.3.2.2.8 | Create an Authentication Query

Topic Not Found

4.3.2.2.9 | Query Across All Entities

Abstract

From the Cortex XSIAM management console, you can search for endpoints and processes across all endpoint activity.

From the Query Builder you can perform a simple search for hosts and processes across all file events, network events, registry events, process events, event
logs for Windows, and system authentication logs for Linux.

Some examples of queries you can run across all entities include:

All activities on a host

All activities initiated by a process on a host

To build a query:

1. From Cortex XSIAM , select INVESTIGATION → Query Builder.

2. Select ALL ACTIONS.

3. (Optional) Limit the scope to a specific acting process:

Select Add Process to your search, and specify one or more of the following attributes for the acting (parent) process. Use a pipe (|) to separate multiple
values. Use an asterisk (*) to match any string of characters.

Table 2.

Name Description

NAME Name of the parent process.

PATH Path to the parent process.

CMD Command line used to initiate the parent process including any arguments, up to 128 characters.

MD5 MD5 hash value of the parent process.

SHA256 SHA256 hash value of the process.

USER NAME User who executed the process.

SIGNATURE Signing status of the parent process: Signed, Unsigned, N/A, Invalid Signature, Weak Hash.

SIGNER Entity that signed the certificate of the parent process.

PID Process ID of the parent process.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 257/1003
5/8/24, 9:18 AM PDF Export

Name Description

Run search on The causality actor, also referred to as the causality group owner (CGO), is the parent process in the execution chain that
process, Causality the agent identified as being responsible for initiating the process tree. The OS actor is the parent process that creates an
and OS actors OS process on behalf of a different initiator. By default, this option is enabled to apply the same search criteria to initiating
processes. To configure different attributes for the parent or initiating process, clear this option.

4. (Optional) Limit the scope to an endpoint or endpoint attributes:

Select Add Host to your search and specify one or more of the following attributes:

HOST - HOST NAME, HOST IP address, HOST OS, HOST ADDRESS, or INSTALLATION TYPE.

INSTALLATION TYPE can be either an agent, or data collector.

PROCESS — NAME , PATH , CMD , MD5 , SHA256 , USER NAME , SIGNATURE, or PID.

Use a pipe (|) to separate multiple values. Use an asterisk (*) to match any string of characters.

5. Specify the time period for which you want to search for events.

Options are Last 24H (hours), Last7D (days), Last1M (month), or select a Custom time period.

6. Choose when to run the query.

Select the calendar icon to schedule a query to run on or before a specific date or Run the query immediately and view the results in the Query Center.

While the query is running, you can always navigate away from the page and a notification is sent when the query completes. You can also Cancel the
query or run a new query, where you have the option to Run only new query (cancel previous) or Run both queries.

7. When ready, view the results in a query.

4.3.3 | Edit and rerun queries

Abstract

From the Query Center, you can view the results of a query, modify a query, and rerun queries.

The Query Center displays information about all queries that were run in the Query Builder. From the Query Center you can manage your queries, view query
results, and adjust and rerun queries. Right-click a query to see the available options.

View the results of a query

1. Select Investigation → Query Center.

2. Identify the query by looking in the Query Description column.

The Query Description column displays the parameters that were defined for a query. If necessary, use the Filter to reduce the number of queries that
Cortex XSIAM displays.

Queries that were created from a Query Builder template are prefixed with the template name.

3. Right-click anywhere in the query row and select Show results.

4. (Optional) Export to file to export the results to a tab-separated values (TSV) file.

5. (Optional) Perform additional investigation on the alerts.

Right-click a value in the results table to see the options for further investigation.

Modify a query

After you run a query, you might need to change your search parameters to refine the search results or correct a search parameter. You can modify a query from
the Results page:

For queries created in XQL, the Results page includes the XQL query builder with the defined parameters. Modify the query and Run, schedule, or save
the query.

For queries created with a Query Builder template, the defined parameters are shown at the top of the Results page. Select Back to edit to modify the
query with the template format or Continue in XQL to open the query in XQL.

Rerun or schedule a query to run

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 258/1003
5/8/24, 9:18 AM PDF Export

If you want to rerun a query, you can either schedule it to run on or before a specific date, or you can rerun it immediately. Cortex XSIAM creates a new query in
the Query Center, and when the query completes, it displays a notification in the notification bar.

To rerun a query immediately, right-click anywhere in the query and then select Rerun Query.

How to schedule a query

1. In the Query Center, right-click anywhere in the query and then select Schedule.

2. Choose a schedule option and the date and time that the query should run:

Run one time query on a specific date

Run query by date and time: Schedule a recurring query.

3. Click OK to schedule the query.

Cortex XSIAM creates a new query and schedules it to run on or by the selected date and time.

4. View the status of the scheduled query on the Scheduled Queries page.

You can also make changes to the query, edit the frequency, view when the query will next run, or disable the query. For more information, see Manage
scheduled queries.

4.3.3.1 | Query Center reference information

Abstract

Descriptions of the fields in the Query Center table.

The following is a list of common fields in the Query Center table.

NOTE:

Certain fields are exposed and hidden by default. An asterisk (*) is beside every field that is exposed by default.

Read more...

Field Description

BQL Whether the query was created by the native search.

Native search has been deprecated; this field allows you to view data for queries
performed before deprecation.

COMPUTE UNIT USAGE Number of query units that were used to execute the API query and Cold Storage
query.

CREATED BY * User who created or scheduled the query.

DURATION (SEC) Number of seconds it took to execute the query.

EXECUTION ID Unique identifier of Cortex Query Language (XQL) queries in the tenant. The
identifier ID generated for queries executed in Cortex XSIAM and XQL query API.

NUM OF RESULTS* Number of results returned by the query.

PUBLIC API Whether the source executing the query was an XQL query API.

QUERY DESCRIPTION* Query parameters used to run the query.

QUERY ID Unique identifier of the query.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 259/1003
5/8/24, 9:18 AM PDF Export

Field Description

QUERY NAME* For saved queries, the Query Name identifies the query specified by the
administrator.

For scheduled queries, the Query Name identifies the auto-generated name
of the parent query. Scheduled queries also display an icon to the left of the
name to indicate that the query is recurring.

QUERY STATUS* Status of the query:

Queued: The query is queued and will run when there is an available slot.

Running

Failed

Partially completed: The query was stopped after exceeding the maximum
number of permitted results; 100,000 for queries executed in Cortex XSIAM
and 1,000,000 for XQL Query API. To reduce the number of results returned,
you can adjust the query settings and rerun.

Stopped: The query was stopped by an administrator.

Completed

Deleted: The query was pruned.

RESULTS SAVED* Yes or No.

SIMULATED COMPUTE UNITS Number of query units that were used to execute the Hot Storage query.

TENANT List of tenants on which an XQL query were executed.

TIMESTAMP* Date and time the query was created.

XQL Whether the query was created by an XQL search.

4.3.4 | Manage scheduled queries

Abstract

Learn how to manage your scheduled and recurring queries.

The Scheduled Queries page displays information about your scheduled and recurring queries. From this page, you can edit scheduled query parameters, view
previous executions, disable, and remove scheduled queries. Right-click a query to see the available options.

View executed queries

1. Select Investigation → Scheduled Queries.

2. Locate the scheduled query for which you want to view previous executions.

If necessary, use the Filter to reduce the number of queries returned.

3. Right-click anywhere in the query row, and select Show executed queries.

Cortex XSIAM filters the queries on the Query Center.

Edit the query frequency

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 260/1003
5/8/24, 9:18 AM PDF Export

1. Select Investigation → Scheduled Queries.

2. Locate the scheduled query that you want to edit.

If necessary, use the Filter to reduce the number of queries returned.

3. Right-click anywhere in the query row and then select Edit.

4. Adjust the schedule settings, and then click OK.

4.3.4.1 | Scheduled Queries reference information

Abstract

Descriptions of the fields in the Scheduled Queries table.

The following is a list of common fields in the Scheduled Queries table.

Read more...
NOTE:

Certain fields are exposed and hidden by default. An asterisk (*) is beside every field that is exposed by default.

Field Description

BQL Whether the query was created by the native search.

Native search has been deprecated, this field allows you to view data for queries performed before
deprecation.

CREATED BY User who created or scheduled the query.

MITRE ATT&CK TACTIC MITRE ATT&CK tactics tagged in the scheduled query.

MITRE ATT&CK TECHNIQUE MITRE ATT&CK techniques tagged in the scheduled query.

NEXT EXECUTION For queries that are scheduled to run at a specific frequency, this displays the next execution time.

For queries that were scheduled to run at a specific time and date, this field will show None.

PUBLIC API Whether the source executing the query was an XQL query API.

QUERY DESCRIPTION Query parameters used to run the query.

QUERY ID Unique identifier of the query.

QUERY NAME For saved queries, the Query Name identifies the query specified by the administrator.

For scheduled queries, the Query Name identifies the auto-generated name of the parent query.
Scheduled queries also display an icon to the left of the name to indicate that the query is reoccurring.

SCHEDULE TIME Frequency or time at which the query was scheduled to run.

XQL Whether the query was created by XQL search.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 261/1003
5/8/24, 9:18 AM PDF Export

4.3.5 | Manage Your Personal Query Library

Abstract

Cortex XSIAM provides as part of the Query Library a personal library for saving and managing your own queries.

Cortex XSIAM provides as part of the Query Library a personal query library for saving and managing your own queries. When creating a query in XQL Search
or managing your queries from the Query Center, you can save queries to your personal library. You can also decide whether the query is shared with others (on
the same tenant) in their Query Library or unshare it, so it is only visible to you. You can also view the queries that are shared by others (on the same tenant) in
your Query Library.

The queries listed in your Query Library have different icons to help you identify the different states of the queries.

Created by me and unshared.

Create by me and shared.

Created by someone else and shared.

The Query Library contains a powerful search mechanism that enables you to search in any field related to the query, such as the query name, description,
creator, query text, and labels. In addition, adding a label to your query enables you to search for these queries using these labels in the Query Library.

To add a query to your personal query library.

1. Save a query to your personal query library.

You can do this in two ways.

From XQL Search

1. Select Incident Response → Investigation → Query Builder → XQL Search.

2. In the XQL query field, define the parameters of your query.

3. Select Save as → Query to Library.

From the Query Center

1. Select Incident Response → Investigation → Query Center.

2. Locate the query that you want to save to your personal query library.

3. Right-click anywhere in the query row, and select Save query to library.

2. Set these parameters.

Query Name—Specify a unique name for the query. Query names must be unique in both private and shared lists, which includes other people’s
queries.

Query Description—(Optional) Specify a descriptive name for your query.

Labels—(Optional) Specify a label that is associated with your query. You can select a label from the list of predefined labels or add your label and
then select Create Label. Adding a label to your query enables you to search for queries using this label in the Query Library.

Share with others—You can either set the query to be private and only accessible by you (default) or move the toggle to Share with others the
query, so that other users using the same tenant can access the query in their Query Library.

3. Click Save.

A notification appears confirming that the query was saved successfully to the library, and closes on its own after a few seconds.

The query that you added is now listed as the first entry in the Query Library. The query editor is opened to the right of the query.

4. Other available options.

As needed, you can return to your queries in the Query Library to manage your queries. Here are the actions available to you.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 262/1003
5/8/24, 9:18 AM PDF Export

Edit the name, description, labels, and parameters of your query by selecting the query from the Query Library, hovering over the line in the query
editor that you want to edit, and selecting the edit icon to edit the text.

Search query data and metadata—Use the Query Library’s powerful search mechanism that enables you to search in any field related to the query,
such as the query name, description, creator, query text, and label. The Search query data and metadata field is available at the top of your list of
queries in the Query Library.

Show—Filter the list of queries from the Show menu. You can filter by the Palo Alto Networks queries provided with Cortex XSIAM , filter by the
queries Created by Me, or filter by the queries Created by Others. To view the entire list, Select all (default).

Save as new—Duplicate the query and save it as a new query. This action is available from the query menu by selecting .

Share with others—If your query is currently unshared, you can share with other users on the same tenant your query, which will be available in

their Query Library. This action is only available from the query menu by selecting when your query is unshared.

Unshare—If your query is currently shared with other users, you can Unshare the query and remove it from their Query Library. This action is only

available from the query menu by selecting when your query is shared with others. You can only Unshare a query that you created. If another
user created the query, this option is disabled in the query menu.

Delete the query. You can only delete queries that you created. If another user created the query, this option is disabled in the query menu when

selecting .

4.3.6 | Quick Launcher

Abstract

The Quick Launcher provides a quick, in-context shortcut that you can use to search for information, perform common investigation tasks, or initiate actions.

The Quick Launcher provides a quick, in-context shortcut that you can use to search for information, perform common investigation tasks, or initiate response
actions from any place in Cortex XSIAM. The tasks that you can perform with the Quick Launcher include:

Search for host, username, IP address, domain, filename, filepath, timestamp to easily launch the artifact and assets views.

NOTE:

For hosts, Cortex XSIAM displays results for exact matches but supports the use of wildcard (*) which changes the search to return matches that
contain the specified text. For example, a search of compy-7* will return any hosts beginning with compy-7 such as compy-7000, compy-7abc, and so
forth.

Search in the Asset Inventory table for a specific Asset Name or IP address. In addition, 2 actions are available when searching for Asset Inventory data.

Change search to <host name of asset> to display additional actions related to that host. This option is only relevant when searching for an IP
address that is connected to an asset.

Open in Asset Inventory is a pivot available when the host name of an asset is selected.

Begin Go To mode. Enter forward slash (/) followed by your search string to filter and navigate to Cortex XSIAM pages. For example, / rules searches
for all pages that include rules and allows you to navigate to those pages. Select Esc to exit Go To mode.

Add a processes by SHA256 hash to the allow list or block list

Add domains or IP addresses to the EDL block list

Create a new IOC for an IP address, domain, hash, filename, or filepath

Isolate an endpoint

Open a terminal to a given endpoint

Initiate a malware scan on an endpoint

You can bring up the Quick Launcher either using the default keyboard shortcut— Ctrl-Shift+X on Windows or CMD+Shift+X on macOS, by using the Quick
Launcher icon located in the top navigation bar, or from the application menus. To change the default keyboard shortcut, select Settings → Configurations →
General → Server Settings → Keyboard Shortcuts. The shortcut value must be a keyboard letter, A through Z, and cannot be the same as the Artifact and Asset
Views defined shortcut.

You can also prepopulate searches in Quick Launcher by selecting text in the app or selecting a node in the Causality or Timeline Views.

By default, Cortex XSIAM opens the Quick Launcher in the center of the page. To change the default position, drag the Quick Launcher to another preferred
location. The next time you open the Quick Launcher, it opens in the previous location. To close the Quick Launcher, click Esc or click out of the Quick Launcher
dialog.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 263/1003
5/8/24, 9:18 AM PDF Export

4.3.7 | Research a Known Threat

Abstract

Cortex XSIAM enables you to investigate any threat, also referred to as a lead, which has been detected.

This topic describes what steps you can take to investigate a lead. A lead can be:

An alert from a non-Palo Alto Networks system with information relevant to endpoints or firewalls.

Information from online articles or other external threat intelligence provides well-defined characteristics of the threat.

Users or hosts that have been reported as acting abnormally.

1. Use the threat intelligence you have to build a query using the Query Builder.

For example, if external threat intelligence indicates a confirmed threat that involves specific files or behaviors, search for those characteristics.

2. View the Results of a Query and refine as needed to filter out noise.

3. Select an event of interest, and open the Causality View.

Review the chain of execution and data, navigate through the processes on the tree, and analyze the information.

4. Open the Timeline View to view the sequence of events over time.

5. Inspect the information again, and identify any characteristics you can use to Create a BIOC Rule or Create a Correlation Rule.

If you can create a BIOC or Correlation Rule, test and tune it as needed.

4.4 | Investigate Artifacts and Assets

Abstract

Cortex XSIAM enables you to investigate artifacts and assets by providing information about IP addresses, network assets, files, and processes.

To streamline the investigation process and reduce the number of steps it takes to investigate and threat hunt artifacts and assets, Cortex XSIAM provides
dedicated views of information relating to IP address, Network Assets, and File and Process Hash.

Each of the views automatically aggregates and displays a summary of all the information Cortex XSIAM and threat intelligence services have regarding a
specific artifact and asset.

4.4.1 | Investigate an IP Address

Abstract

Cortex XSIAM aggregates and enables you to view a summary of all information and threat intelligence regarding specific IP addresses.

The IP Address View provides a powerful way to investigate and take action on IP addresses by reducing the number of steps it takes to collect, research, and
threat hunt related incidents. Cortex XSIAM automatically aggregates and displays a summary of all the information Cortex XSIAM and threat intelligence
services have regarding a specific IP address over a defined 24-hour or 7-day time frame.

To help you determine whether an IP address is malicious, the IP Address View displays an interactive visual representation of the collected activity for a specific
IP address.

To investigate an IP address:

1. Open the IP View for an IP address.

You can access the view from an IP address in Cortex XSIAM console, where available, by either right-clicking Open IP View, selecting the IP address, or
using the default keyboard shortcut Ctrl/CMD+Shift+E combination, or searching for a specific IP address in the Quick Launcher.

To change the default keyboard shortcut, select Settings → Configurations → General → Server Settings → Keyboard Shortcuts. The shortcut value must
be a keyboard letter, A through Z, and cannot be the same as the Quick Launcher defined shortcut.

2. Review the overview for the IP address.

The overview displays network operations, incidents, actions, and threat intelligence information relating to a specific IP address and provides a summary
of the network operations and processes related to the IP address.

a. Review the auto-generated summary of the number of network operations and processes related to the IP that occurred over the past 7 days.

b. Add an Alias or Comment to the IP address.

c. Review the location of the IP address. By default, Cortex XDR displays information on whether the IP address is an internal or external IP address.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 264/1003
5/8/24, 9:18 AM PDF Export

External—Connection Type: Incoming displaying IP address is located outside of your organization. Displays the country flag if the location
information is available.

Internal—Connection Type: Outgoing displaying IP address is from within your organization. The XDR Agent icon is displayed if the
corresponding endpoint identified by the IP address has an agent is installed at that point in time.

d. Identify the IOC severity.

The color of the IP address value is color-coded to indicate the IOC severity.

Low—Blue

Medium—Yellow

High—Red

Critical—Red

e. Review any available threat intelligence for the IP address.

Depending on the threat intelligence sources that you integrate with Cortex XSIAM, you can review any of the following threat intelligence.

Virus Total score and report

NOTE:

Requires a license key. Select Settings → Configurations → Integrations → Threat Intelligence.

Whois identification data for the specific IP address.

IOC Rule, if applicable, includes the IOC Severity, Number of hits, and Source.

EDL IP address if the IP address was added to an EDL.

f. Review any related incidents:

Related Incidents lists the most recent incidents that contain the specific IP address as part of the incident Key Artifacts according to the Last
Updated timestamp. If the IP address belongs to an endpoint with a Cortex XDR agent installed, the incidents are displayed according to the host
name rather than the IP address. To dive deeper into specific incidents, select the Incident ID. To view all the related incidents, select View All.
Cortex XSIAM displays Recently Updated Incidents which filters incidents for those that contain the IP address.

3. Filter the IP address information you want to visualize.

Select from the following criteria to refine the scope of the IP address information you want visualized. Each selection aggregates the displayed data.

Filter Description

Type The type of information you want to display.

Host Insights—Pivot to the Asset View of the host associated with

the IP address.

Network Connections—Display the IP View of the network

connections made with the IP address.

Primary The main set of values you want to display. The values depend on the
selected Connection Type.

All Aggregations—Summary of all the related IP address data.

Destination/Source Country

Destination/Source Port

Destination/Source IP

Destination/Source Process

App-ID

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 265/1003
5/8/24, 9:18 AM PDF Export

Filter Description

Secondary The set of values you want to apply as the secondary set of
aggregations. Must differ from your Primary selection:

Destination Country

Destination/Source Port

Destination/Source IP

Destination/Source Process

App-ID

Node Size The node size displays the type of values.

Number of Connections

Total Traffic

Total Download

Total Upload

Showing The number of the Primary and Secondary aggregated connections.

Top 5

Top 3

Bottom 5

Bottom 3

Connection Type Type of connection you want to display your defined set of values.

Incoming

Outgoing

Timeframe Time period over which to display your defined set of values.

24 Hours

7 Days

Select to apply your selections and update the information displayed in the visualization pane. If necessary, Refresh to retrieve data.

4. Review the selected data.

Select each node for additional information.

Select Recent Outgoing Connections to view the most recent connections made by this IP address. Search all Outgoing Connections to run a
Network Connections query on all the connections made by this IP address.

5. After reviewing the available information for the IP address, take action if desired:

Depending on the current IOC and EDL status, select Actions to:

Edit Rule

Disable Rule

Delete Rule

Add to EDL

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 266/1003
5/8/24, 9:18 AM PDF Export

4.4.2 | Investigate an Asset

Abstract

Investigate host insights, such as users, groups, services, drivers, hardware, and network shares.

The Asset View provides a powerful way to investigate assets by reducing the number of steps it takes to collect and research hosts. Cortex XSIAM
automatically aggregates information on hosts and displays the host insights and a list of related incidents.

NOTE:

If you have selected the Unified Inventory toggle on the Asset Inventory page, you can Open Asset Inventory View while investigating an asset. For more
information, see Asset Inventory.

To investigate an asset:

1. Open the Asset View for an asset.

You can access the view from:

A host with Cortex XDR agent installed in Cortex XSIAM console by right-click > Open Asset View.

The IP View of an internal IP address with a Cortex XDR Agent by selecting Host Insights from the navigation bar.

The Quick Launcher, by searching for a specific Host Name.

2. Review the Asset overview.

The overview displays the host name and any related incidents.

a. Review the Host name.

b. Add an Alias or Comment to the host name.

c. Review any related incidents:

Related Incidents lists the most recent incidents that contain the host as part of the incident Key Artifacts according to the Last Updated timestamp.
If the host belongs to an endpoint with a Cortex XDR agent installed, the incidents are displayed according to the host name. To dive deeper into
specific incidents, select the Incident ID. To view all the related incidents, select View All.

3. Filter the host information you want to display.

Select from the following criteria to refine the scope of the host information you want to display. Each selection aggregates the displayed data.

Filter Description

Type The type of information you want to display.

Host Insights—A list of the host artifacts.

Network Connections—Pivot to the IP view of the IP addresses

associated with the host.

Host Risk View—Insights and profiling information. Available with

the the Identity Threat Module.

Primary List of host artifacts you want to display.

Users

Groups

Users to Groups

Services

Drivers

Autorun

System Information

Shares

Disks

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 267/1003
5/8/24, 9:18 AM PDF Export

Filter Description

Compare Compare host insights collected by Cortex XSIAM over the last 30 days.

Select to apply your selections and update the information displayed in the visualization pane.

4. Review the Host Inventory.

Select Run insights collection to initiate a new collection. The next time the Cortex XDR agent connects, the insights are collected and displayed.

4.4.3 | Investigate a Host

NOTE:

The Host Risk View is available only if the Identity Threat Module add-on is enabled.

The Host Risk view provides insights and profiling information about a host when investigating alerts and incidences. Viewing anomalies in the context of the
host enables you to make better and faster decisions about risks. With the Host Risk view, you can do the following:

Assess the host's behavior and score.

Analyze the host's behavior over time and compare to their peers with the same asset role.

Review related incidents and past alerts for the host.

Star the host to be included in the watchlist.

Open the Host Risk View.

1. Under Assets → Asset Scores, select the Hosts tab, right click on any endpoint, and select Open Host Risk View.

2. Select the timeframe to view the host's details.

3. Investigate the Host overview.

The Host Risk view displays the following data. Depending on your permissions, some information might be limited by your scope.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 268/1003
5/8/24, 9:18 AM PDF Export

General Information

Actions enables you to perform the available actions for this endpoint.

Star—indicates if the host is part of a watch list. The star is reflected in the context of the current host, not globally.

Name—Unique ID of the host.

Host Score assigned on the last day of the selected time frame, and the change in the score for the selected time frame. The score is updated
continuously as new alerts are associated with incidents.

Host metadata enriched by the information aggregated by Cortex XSIAM

IP Addresses

Default User

Location

Agent Installed—last time the agent was installed

Last Communication—last time the console communicated with the endpoint

Operating System

Tags

Asset Role—automatically detected or manually configured

CVEs breakdown by severity—Common Vulnerabilities and Exposures (CVE) are grouped by severity. For more information on each of the
CVEs, refer to Related CVEs.

Time period based information.

Host Score Trend for the selected time period—the straight line represents the host score, which is based on the scores of the incidents associated
with the host. The graph is based on both new incidents created within the selected time frame and updates on past incidents that are still active.

The bubbles in the graph represent the number of alerts and insights generated on the selected day. Bigger bubbles indicate more alerts and
insights, and a possible risk.

Click a bubble to display in the Related Incidents and the Related Alerts and Insights tables the incidents, alerts, and insights that contributed to the
total host score on a specific day.

For hosts with associated Asset Roles, you can compare the data with other peer hosts with the same asset role. Select an asset role to Compare
To. The dashed line presents the average score for peers with the same asset role as the host, over the same time period.

Hover over a bubble on the dashed line to see the Average score for the selected peer, and a breakdown of the score per endpoint. Click Show x
Hosts to see a full breakdown of the score on the Peer Score Breakdown, filtered by the selected asset role. From the Peer Score Breakdown you
can select any host name and pivot to additional views for further investigation.

The Related Incidents table displays the following incident details for the day selected in the Score Trend graph.

Starred—Whether the incident is starred.

Date Created

Description

Severity

Status—gives visibility into the reason for the score change. For example, if an incident is resolved, its score will decrease, bringing down the
host score.

Points—Risk score that the incident contributed to the host score. The points are calculated according to either Cortex XSIAM SmartScore or
Incident Scoring Rules ( ).

The Related Alerts and Insights widget displays the timeline of all the detection activities associated with the host for the day selected in the Score
Trend graph. The information is grouped into buckets according to mitre attack tactics.

Latest Logins to Host displays the details and outcomes of the related login attempts to the host. When you select a day in the Score Trend graph, the
information changes to reflect the logins for that day.

Latest Authentication Attempts displays the details and outcomes of the related authentication attempts to the host. When you select a day in the Score
Trend graph, the information changes to reflect the authentication attempts for that day.

Related CVEs displays the details of the specified CVE. The information can help you to access and prioritize security threats on each of the endpoints.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 269/1003
5/8/24, 9:18 AM PDF Export

4.4.4 | Investigate a File and Process Hash

Abstract

Investigate incidents, actions, and threat intelligence reports related to a specific file or process hash.

The file and process Hash View provides a powerful way to investigate and take action on SHA256 hash processes and files by reducing the number of steps it
takes to collect, research, and threat hunt related incidents. The Hash View automatically aggregates and displays a summary of all the information Cortex
XSIAM and threat intelligence services have regarding a specific SHA256 hash over a defined 24 hour or 7 day time frame.

The Hash View allows you to drill down on each of the process executions, file operations, incidents, actions, and threat intelligence reports relating to the hash.

To investigate a file or process hash:

1. Open the Hash View for a file or process hash.

You can access the view from every hash value in the Cortex XSIAM console by either right-clicking Open Hash View, selecting the hash and using the
keyboard shortcut Ctrl/CMD+Shift+E combination, or searching for a specific hash in the Quick Launcher.

2. Review the overview for the hash.

The overview displays host/user, incidents, actions, and threat intelligence information relating to a specific hash and provides a summary of the files and
processes related to the hash.

a. Review the auto-generated summary of the number of network operations and processes related to the hash that occurred over the past 7 days.

b. Review the signature of the hash, if available.

c. Identify the WildFire verdict.

The color of the hash value is color-coded to indicate the WildFire report verdict:

Blue—Benign

Yellow—Grayware

Red—Malware

Light gray—Unknown verdict

Dark gray—The verdict is inconclusive

d. Add an Alias or Comment to the hash value.

e. Review any available threat intelligence for the hash.

Depending on the threat intelligence sources that you integrate with Cortex XSIAM , you can review any of the following threat intelligence.

Virus Total score and report.

NOTE:

Requires a license key. Navigate to Settings → Configurations → Integrations → Threat Intelligence.

AutoFocus identification data for the specific hash.

IOC Rule, if applicable, including the IOC Severity, Number of hits, and Source according to the color-coded values:

Low—Blue

Medium—Yellow

High—Red

Critical—Red

WildFire analysis report.

f. Review if the hash has been added to:

Allow List or Block List.

Quarantined, select the number of endpoints to open the Quarantine Details view.

g. Review any related incidents:

Related Incidents lists the most recent incidents that contain the specific hash as part of the incident Key Artifacts according to the Last Updated
timestamp. To dive deeper into specific incidents, select the Incident ID. To view all the related incidents, select View All. Cortex XSIAM displays
Recently Updated Incidents which filters incidents for those that contain the hash.

3. Filter the hash information you want to visualize.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 270/1003
5/8/24, 9:18 AM PDF Export

Select from the following criteria to refine the scope of the hash information you want visualized. Each selection aggregates the displayed data.

Filter Description

Event Type The main set of values you want to display. The values depend on the
selected type of process or file.

All Aggregations—Summary of all the related hash data.

Process Executions

Process Injections

File Read

File Write

File Delete

File Rename

File Create

Primary The set of values you want to apply as the primary set of aggregations.
Values depend on the selected Event Type.

Initiating Process

Target Process / File

Secondary The set of values you want to apply as the secondary set of
aggregations.

Host

User

Showing The number of the Primary and Secondary aggregated values.

Top 5

Top 3

Bottom 5

Bottom 3

Timeframe Time period over which to display your defined set of values.

24 Hours

7 Days

Select to apply your selections and update the information displayed in the visualization pane. If necessary, Refresh to retrieve data.

4. Review the selected data. For more information, select Recent Process Executions to view the most recent processes executed by the hash. Search all
Process Executions to run a query on the hash.

5. After reviewing the available information for the hash, take action if desired:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 271/1003
5/8/24, 9:18 AM PDF Export

Select File Search to initiate a search for this hash across your network.

Depending on the current hash status, select Actions to:

Add the hash to an Allow List.

Add the hash to a Block List.

Create an IOC rule.

4.4.5 | Investigate a User

Abstract

Investigate user assets associated with your incidents.

The User Risk View enables you to investigate user type assets by reducing the number of steps it takes to collect data to research a user. Cortex XSIAM uses
Identity Analytics to aggregate information on a user and displays insights about the user. The data displayed in the view depends on whether the Identity Threat
module is enabled.

If the Identity Threat module is enabled, this view displays insights and profiling information to help you investigate alerts and incidents. Viewing anomalies in the
context of baseline behavior facilitates risk assessment and shortens the time you require for making verdicts. With the User Risk view, you can do the following.

Assess the user's behavior and score.

Review the user's working hours and past alerts.

Analyze the user's behavior over time and compare to their peers with the same asset role.

Star the user to be included in the watchlist.

If the Identity Threat module is not enabled, the User View is displays an overview of the user and information about the User's Score and activity.

Open the User Risk View or the User View.

1. Under Assets → Asset Scores, select the Users tab, right click on any user, and select Open User Risk View.

2. Select the timeframe to view the User's details.

3. Investigate the User overview.

The User Risk View with the Identity Threat Module enabled

Read more...

The User Risk View displays the following data. Depending on your permissions, some information might be limited by your scope.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 272/1003
5/8/24, 9:18 AM PDF Export

General Information

Star—indicates if the user is part of a watch list.

Name—Unique ID of the user. The queries used for the widgets in this view are based on the normalized user name, in the format <company
domain>\<user name>, and the email address.

Host Score assigned on the last day of the selected time frame and the change in the score for the selected time frame. The score is updated
continuously as new alerts are associated with incidents.

User metadata enriched by the information aggregated from Active Directory and Workday, if you have an integration with Workday for the tenant.

Full Name—assigned user name.

Email

Title

Last Login— date and time of the last login event associated with the username.

Location

Department—assigned department name.

Last Authentication

Asset Role—automatically detected or manually configured

Common Locations—the countries from which the user connected most in the past few weeks.

Common UAs—the user agents the user used most in the past few weeks.

Regular Activity Hours for the user. This data is based on the preceding several weeks and takes into account holidays and seasonality to present
an accurate picture.

Time period based information.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 273/1003
5/8/24, 9:18 AM PDF Export

User Score Trend for the selected time period—the straight line represents the user score, which is based on the scores of the incidents associated
with the user. The graph is based on both new incidents created within the selected time frame and updates on past incidents that are still active.

The bubbles in the graph represent the alerts and insights generated on the selected day. Bigger bubbles indicate more alerts and insights, and a
possible risk.

Click a bubble to display in the Related Incidents and the Related Alerts and Insights tables the incidents, alerts, and insights that contributed to the
total user score on a specific day.

For users with associated Asset Roles, you can compare the data with other peer users with the same asset role. Select an asset role to Compare
To. The dashed line presents the average score for peers with the same asset role as the user, over the same time period.

Hover over a bubble on the dashed line to see the Average score for the selected peer, and a breakdown of the score per endpoint. Click Show x
Users to see a full breakdown of the score on the Peer Score Breakdown, filtered by the selected asset role. From the Peer Score Breakdown you
can select any user name and pivot to additional views for further investigation.

The Related Incidents table displays the following incident details for the day selected in the Score Trend graph.

Starred—Whether the incident is starred.

Date Created

Description

Severity

Status—gives visibility into the reason for the score change. For example, if an incident is resolved, its score will decrease, bringing down the
user score.

Points—Risk score that the incident contributed to the user score. The points are calculated according to either Cortex XSIAM SmartScore (
) or Incident Scoring Rules ( ).

The Related Alerts and Insights widget displays the timeline of all the detection activities associated with the user for the day selected in the Score
Trend timeline. The information is grouped into buckets according to mitre attack tactics.

To view the details of the Alert in the Alert Panel view, click the alert. This enables you to see all the details about the alert in one page.

Actual Activity that took place per day. The darker the cells, the more activity took place in that time slot. If there is a dashed frame around the
slot, Cortex XSIAMdetected uncommon activity in that time slot.

Login Attempts displays the details and outcomes of the related login attempts by the user. When you select a day in the Score Trend graph, the
information changes to reflect the logins for that day.

Latest Authentication Attempts displays the details and outcomes of the related authentication attempts by the user. When you select a day in the
Score Trend graph, the information changes to reflect the authentication attempts for that day.

SAAS Logs associated with the user. When you select a day in the Score Trend graph, the information changes to reflect the SAAS Logs for that
day.
NOTE:

Cortex XSIAM normalizes and displays incident and alert times in your time zone. If you're in a half-hour time zone, the activity in the Normal Activity and the
Actual Activity charts is displayed in the whole-hour time slot preceding it. For example, if you're in a UTC +4.5 time zone, the time displayed for the activity
will be UTC +4.5, however, the visualization in the Normal Activity and the Actual Activity charts will be in the UTC +4 slot.

The User View without the Identity Threat Module enabled

Read more...

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 274/1003
5/8/24, 9:18 AM PDF Export

Details Header

Displays the following information aggregated by Cortex XSIAMfrom incidents, Workday, and Active Directory data.

User Name—Represents the assigned user name.

Department—Represents the user assigned department name.

Phone Number—Represents the user assigned phone number.

Location—Represents the user assigned location.

Last Authentication—Last date and time of an authentication event associated with the username.

Last Login—Last date and time of a login event associated with the username.

Workday Fields—If available, select All Info to display Workday user details.

Current User Score—User Score currently assigned to the user. The score is updated continuously as new alerts are associated with incidents.

Score Trend

Investigate the User Score variation over the selected timeframe.

Select a score to display in the Incidents table the incidents that contributed to the total user score on a specific day. In the table, you can view the
following incident details:

Starred—Whether the incident is starred, you can select to Star if you wish.

Creation Time—When the incident was created

Description—Description of the incident

Severity—Severity of the incident

Points Added—Risk score that the incident contributed to the user score. The points are calculated according to either Cortex XSIAM SmartScore or
Incident Scoring Rules ( ).

Select an incident and pivot to the Incident View. Incidents that no longer exist or have been merged are grayed out.

User Associated Insights

Displays all the insights associated with the user filtered.

Top 5 Hosts Logged Into

Top 5 hosts the user logged into.

Top 5 Authentication Target Hosts

Top 5 host names to which the user requested access.

Top 5 Authentication Source Hosts

Top 5 host names where the user started authentication.

Recent Login

Displays the recent user login details.

Recent Authentications

Displays the recent user authentication.

4.5 | Investigate Alerts

Abstract

Within the scope of alert investigation, you can perform a range of operations for gaining further insights.

4.5.1 | Alerts

Abstract

Learn more about the Alerts page in Cortex XSIAM.

The Alerts page displays a table of all alerts in Cortex XSIAM.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 275/1003
5/8/24, 9:18 AM PDF Export

The Alerts page consolidates non-informational alerts from your detection sources to enable you to efficiently and effectively triage the events you see each day.
By analyzing the alert, you can better understand the cause of what happened and the full story with context to validate whether an alert requires additional
action. Cortex XSIAM supports saving 2M alerts per 4000 agents or 20 terabytes, half of the alerts are allocated for informational alerts and half for severity
alerts.

You can view detailed information for an alert in the Alert Panel, Causality View and Timeline View.

By default, the Alerts page displays the alerts received over the last seven days. Every 12 hours, Cortex XSIAM enforces a cleanup policy to remove the oldest
alerts that exceed the maximum alerts limit.

Cortex XSIAM processes and displays the name of users in the following standardized format, also termed “normalized user”.

<company domain>\<username>

As a result, any alert triggered based on network, authentication, or login events displays the User Name in the standardized format in the Alerts and Incidents
pages. This impacts every alert for Cortex XSIAM Analytics and Cortex XSIAM Analytics BIOC, including Correlation, BIOC, and IOC alerts triggered on one of
these event types.

NOTE:

You can query data related to the Alerts and Incidents tables by using the incidents and alerts datasets. For the alerts dataset, INFO alerts are not
included in this dataset. In addition, the alert fields included in this dataset are limited to certain fields available in the API. For the full list, see Get Alerts Multi-
Events v2 API.

The following table describes both the default fields and additional optional fields that you can add to the alerts table using the column manager and lists the
fields in alphabetical order.

Read more...

Field Description

Status Indicator ( Identifies whether there is enough endpoint data to analyze an alert.

Check box to select one or more alerts on which to perform actions. Select
multiple alerts to assign all selected alerts to an analyst, or to change the status
or severity of all selected alerts.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 276/1003
5/8/24, 9:18 AM PDF Export

Field Description

ACTION Action taken by the alert sensor, either Detected or Prevented with action
status displayed in parenthesis. Options are:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 277/1003
5/8/24, 9:18 AM PDF Export

Field Description

Detected

Detected (Allowed The Session)

Detected (Download)

Detected (Forward)

Detected (Post Detected)

Detected (Prompt Allow)

Detected (Raised An Alert)

Detected (Reported)

Detected (Scanned)

Detected (Sinkhole)

Detected (Syncookie Sent)

Detected (Wildfire Upload Failure)

Detected (Wildfire Upload Success)

Detected (Wildfire Upload Skip)

Detected (XDR Managed Threat Hunting)

Prevented (Block)

Prevented (Blocked)

Prevented (Block-Override)

Prevented (Blocked The URL)

Prevented (Blocked The IP)

Prevented (Continue)

Prevented (Denied The Session)

Prevented (Dropped All Packets)

Prevented (Dropped The Session)

Prevented (Dropped The Session And Sent a TCP Reset)

Prevented (Dropped The Packet)

Prevented (Override)

Prevented (Override-Lockout)

Prevented (Post Detected)

Prevented (Prompt Block)

Prevented (Random-Drop)

Prevented (Silently Dropped The Session With An ICMP Unreachable

Message To The Host Or Application)

Prevented (Terminated The Session And Sent a TCP Reset To Both Sides
Of The Connection)

Prevented (Terminated The Session And Sent a TCP Reset To The Client)

Prevented (Terminated The Session And Sent a TCP Reset To The Server)

N/A

AGENT OS SUB TYPE The operating system subtype of the agent from which the alert was triggered.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 278/1003
5/8/24, 9:18 AM PDF Export

Field Description

ALERT ID A unique identifier that Cortex XSIAM assigns to each alert.

ALERT DOMAIN The domain to which the alert is assigned.

Out-of-the-box alerts are automatically assigned to a domain. Custom alerts and

correlations are assigned to a domain during creation. For more information, see
Incident and alert domains.

ALERT NAME Module that triggered the alert. If the alert was generated by Cortex XSIAM , the
Alert Name will be the specific Cortex XSIAM rule that created the alert (BIOC,
IOC, or Correlation Rule name). If from an external system, it will carry the name
assigned to it by Cortex XSIAM . Alerts that match an alert starring policy also
display a purple star.

NOTE:

For alerts coming from firewalls, if duplicate alerts with the same name and
host are raised within 24 hours, they are aggregated and identified by a +n
tag.

Alerts that contain a Featured Alert Field are displayed with flag.

Alerts associated with Identity Analytics are displayed with an Identity Analytics
tag.

ALERT SOURCE Source of the alert: BIOC, Analytics BIOC, Correlation, IOC, XDR Agent,
Firewall, or Analytics.

APP-ID Related App-ID for an alert. App-ID is a traffic classification system that
determines what an application is irrespective of port, protocol, encryption (SSH
or SSL) or any other evasive tactic used by the application. When known, you
can also pivot to the Palo Alto Networks Applipedia entry that describes the
detected application.

APP CATEGORY APP-ID category name associated with a firewall alert.

APP SUBCATEGORY APP-ID subcategory name associated with a firewall alert.

APP TECHNOLOGY APP-ID technology name associated with a firewall alert.

CATEGORY Alert category based on the alert source. An example of an XDR Agent alert
category is Exploit Modules. An example of a BIOC alert category is Evasion. If a
URL filtering category is known, this field also displays the name of the URL
filtering category.

CGO CMD Command-line arguments of the Causality Group Owner.

CGO MD5 The MD5 value of the CGO that initiated the alert.

CGO NAME The name of the process that started the causality chain is based on Cortex
XSIAM causality logic.

CGO SHA256 The SHA256 value of the CGO that initiated the alert.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 279/1003
5/8/24, 9:18 AM PDF Export

Field Description

CGO SIGNATURE Signing status of the CGO:

Unsigned

Signed

Invalid Signature

Unknown

CGO SIGNER The name of the software publishing vendor that signed the file in the causality
chain that led up to the alert.

NOTE:

Cortex XSIAM can display both the O (Organization) value and the CN
(Common Name).

CLOUD IDENTITY TYPE Classification is used to map the identity type that initiated an operation that
triggered an alert. For example, Service, Application, and Temporary
Credentials.

CLOUD IDENTITY SUB-TYPE A more specific classification of the identity initiated the operation. For example,
for Identity Type: Temporary Credentials the subtype could be Assumed Role.

CLOUD OPERATION TYPE Represents what has happened because of the identity operation. For example,
Create, Delete, and Modify.

CLOUD PROJECT Represents the cloud provider folders or projects. For example, AWS Accounts
and Azure Subscriptions.

CLOUD PROVIDER The name of the cloud provider where the alert occurred:

AWS

GCP

Azure

CLOUD REFERENCED RESOURCE Represents the resources that are referenced in the alert log. In most cases, the
referred resource will be where the operation was initiated on.

CLOUD RESOURCE TYPE Classifications are used to map similar types of resources across different cloud
providers. For example, EC2, Google Compute Engine, and Microsoft
Compute are all mapped to Compute.

CLOUD RESOURCE SUB-TYPE A more specific classification is used to map the types of resources. For
example, DISK, VPC, and Subnet are all mapped to Compute.

CONTAINS FEATURED HOST Displays whether the alert includes a host name that has been flagged as a
Featured Alert Field.

CONTAINS FEATURED USER Displays whether the alert includes a user name that has been flagged as a
Featured Alert Field.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 280/1003
5/8/24, 9:18 AM PDF Export

Field Description

CONTAINS FEATURED IP ADDRESS Displays whether the alert includes an IP address name that has been flagged as
a Featured Alert Field.

CID Unique identifier of the causality instance generated by Cortex XSIAM .

DESCRIPTION Text summary of the event including the alert source, alert name, severity, and
file path. For alerts triggered by BIOC, IOC, and Correlation Rules, Cortex
XSIAM displays detailed information about the rule.

DESTINATION ZONE NAME The destination zone of the connection for firewall alerts.

DNS Query Name The domain name is queried in the DNS request.

DOMAIN The domain on which an alert was triggered.

EMAIL RECIPIENT The email recipient value of a firewall alerts triggered on the content of a
malicious email.

EMAIL SENDER The email sender value of a firewall alerts triggered on the content of a malicious
email.

EMAIL SUBJECT The email subject value of a firewall alerts triggered on the content of a malicious
email.

EVENT TYPE The type of event on which the alert was triggered:

File Event

Injection Event

Load Image Event

Network Event

Process Execution

Registry Event

EXCLUDED Whether the alert is excluded by an exclusion configuration.

EXTERNAL ID The alert ID as recorded in the detector from which this alert was sent.

FILE PATH When the alert is triggered on a file (the Event Type is File) this is the path to the
file on the endpoint. If not, then N/A.

FILE MACRO SHA256 SHA256 hash value of a Microsoft Office file macro

FILE MD5 MD5 hash value of the file.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 281/1003
5/8/24, 9:18 AM PDF Export

Field Description

FILE SHA256 SHA256 hash value of the file.

FW NAME Name of firewall on which a firewall alert was raised.

FW RULE ID The firewall rule ID that triggered the firewall alert.

FW RULE NAME The firewall rule name that matches the network traffic that triggered the firewall
alert.

FW SERIAL NUMBER The serial number of the firewall that raised the firewall alert.

HOST The hostname of the endpoint or server on which this alert was triggered. The
hostname is generally available for XDR agent alerts or alerts that are stitched
with EDR data. When the hostname is unknown, this field is blank.

HOST FQDN The fully qualified domain name (FQDN) of the Windows endpoint or server on
which this alert was triggered.

HOST IP IP address of the endpoint or server on which this alert was triggered.

HOST IPv6 IPv6 address of the endpoint or server on which this alert was triggered.

HOST MAC ADDRESS MAC address of the endpoint or server on which this alert was triggered.

HOST OS Operating system of the endpoint or server on which this alert was triggered.

INCIDENT ID The ID of any incident that includes the alert.

INITIATED BY The name of the process that initiated an activity such as a network connection
or registry change.

INITIATOR MD5 The MD5 value of the process which initiated the alert.

INITIATOR SHA256 The SHA256 hash value of the initiator.

INITIATOR CMD Command-line used to initiate the process including any arguments.

INITIATOR SIGNATURE Signing status of the process that initiated the activity:

Unsigned

Signed

Invalid Signature

Unknown

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 282/1003
5/8/24, 9:18 AM PDF Export

Field Description

INITIATOR PATH Path of the initiating process.

INITIATOR PID Process ID (PID) of the initiating process.

INITIATOR SIGNER Signer of the process that triggered the alert.

NOTE:

Cortex XSIAM can display both the O (Organization) value and the CN
(Common Name).

INITIATOR TID Thread ID (TID) of the initiating process.

IS PHISHING Indicates whether a firewall alert is classified as phishing.

LOCAL IP If the alert is triggered on network activity (the Event Type is Network
Connection) this is the IP address of the host that triggered the alert. If not, then
N/A.

LOCAL PORT If the alert is triggered on network activity (the Event Type is Network
Connection) this is the port on the endpoint that triggered the alert. If not, then
N/A.

MAC ADDRESS The MAC address on which the alert was triggered.

MISC Miscellaneous information about the alert.

MITRE ATT&CK TACTIC Displays the type of MITRE ATT&CK tactic on which the alert was triggered.

MITRE ATT&CK TECHNIQUE Displays the type of MITRE ATT&CK technique and sub‑technique on which the
alert was triggered.

MODULE For XDR Agent alerts, this field identifies the protection module that triggered the
alert.

NGFW VSYS NAME Name of the virtual system for the Palo Alto Networks firewall that triggered an
alert.

OS PARENT CREATED BY Name of the parent operating system that created the alert.

OS PARENT CMD Command line used by the parent operating system to initiate the process
including any arguments.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 283/1003
5/8/24, 9:18 AM PDF Export

Field Description

OS PARENT SIGNATURE Signing status of the operating system of the activity:

Unsigned

Signed

Invalid Signature

Unknown

OS PARENT SIGNER Parent operating system signer.

NOTE:

Cortex XSIAM can display both the O (Organization) value and the CN
(Common Name).

OS PARENT SH256 Parent operating system SHA256 hash value.

OS PARENT ID Parent operating system ID.

OS PARENT PID OS parent process ID.

OS PARENT TID OS parent thread ID.

OS PARENT USER NAME Name of the user associated with the parent operating system.

PHONE NUMBER Shows the phone number that triggered the alert. This is the number that sent a
malicious URL/spam or was blocked.

PROCESS EXECUTION SIGNATURE Signature status of the process that triggered the alert:

Unsigned

Signed

Invalid Signature

Unknown

PROCESS EXECUTION SIGNER Signer of the process that triggered the alert.

NOTE:

Cortex XSIAM can display both the O (Organization) value and the CN
(Common Name).

REGISTRY DATA If the alert is triggered on registry modifications (the Event Type is Registry) this
is the registry data that triggered the alert. If not, then N/A.

REGISTRY FULL KEY If the alert is triggered on registry modifications (the Event Type is Registry) this
is the full registry key that triggered the alert. If not, then N/A.

REMOTE HOST If the alert is triggered on network activity (the Event Type is Network
Connection) this is the remote host name that triggered the alert. If not, then N/A.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 284/1003
5/8/24, 9:18 AM PDF Export

Field Description

REMOTE IP The remote IP address of a network operation that triggered the alert.

REMOTE PORT The remote port of a network operation that triggered the alert.

RESOLUTION STATUS The status that was assigned to this alert when it was triggered (or modified):
New, Under Investigation, Resolved. Right-click an alert to Change Status. If you
set the status to Resolved, select a resolution reason, for more information see
Resolution Reasons for Incidents and Alerts.

Any update made to an alert impacts the associated incident. An incident with all
its associated alerts marked as resolved is automatically set to Auto-Resolved.
Cortex XSIAM continues to group Alerts to an Auto-Resolved Incident for up to 6
hours. In the case where an alert is triggered during this duration, Cortex XSIAM
re-opens the Incident.

RULE ID The ID that matches the rule that triggered the alert.

SEVERITY The severity that was assigned to this alert when it was triggered (or modified):
Informational, Low, Medium, High, Critical, or Unknown. Right-click an alert to
Change Severity.

For BIOC, IOCs, and Correlation Rules, you define the severity when you create
the rule. Insights are low and informational severity alerts that do not raise
incidents but provide additional details when investigating an event.

STARRED Whether the alert is starred by starring configuration.

SOURCE ZONE NAME The source zone name of the connection for firewall alerts.

TAGS Displays one or more of the following categories, which is used to filter the
results according to the selected tag:

Asset Roles

Data Sources

Detector Tags

Endpoint Groups / Endpoint Tags —

Displays the tag family and the corresponding tags. If SBAC is enabled,
the user can view and manage the alerts table according the user's scope
settings.

NOTE:

When viewing alerts as a scoped user when a tenant is set to

permissive mode, the user can view the alert but not have access to
entities outside their scope.

When viewing alerts as a scoped user when a tenant is set to restrictive

mode, the alert content is not visible. The user can send the alert ID to
the administrator to add to the user scope so the user can view the alert.

TARGET FILE SHA256 The SHA256 hash value of an external DLL file that triggered the alert.

TARGET PROCESS CMD The command line of the process whose creation triggered the alert.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 285/1003
5/8/24, 9:18 AM PDF Export

Field Description

TARGET PROCESS NAME The name of the process whose creation triggered the alert.

TARGET PROCESS SHA256 The SHA256 value of the process whose creation triggered the alert.

TIMESTAMP The date and time when the alert was triggered.

Right-click to Show rows 30 days prior or 30 days after the selected timestamp
field value.

URL The URL destination address of the domain triggering the firewall alert.

USER NAME The name of the user that initiated the behavior that triggered the alert. If the
user is a domain user account, this field also identifies the domain.

Any alert triggered based on network, authentication, or login events, displays

the User Name in the follow standardized format in the Alerts and Incidents
pages.

<company domain>\<username>

XFF X-Forwarded-For value from the HTTP header of the IP address connecting with
a proxy.

4.5.2 | Alert Investigation

Topic Not Found

4.5.2.1 | Context Data Management

Abstract

Learn about incident context data, how it is stored in Cortex XSIAM, and how to access it.

Context data is a map (dictionary) that stores structured results from data such as commands, playbooks, correlation rules, and scripts. Context data includes
keys (strings) and values (numbers, maps, arrays, and strings).

You can use context data to pass data between playbook tasks and capture important structured data. Context data acts as an incident data dump from which
you can map data into alerts/incident fields using a script. When an alert is generated in Cortex XSIAM and a playbook or analyst begins investigating it, context
data will be written to the alert. You can add context data to a parent incident to assist with the investigation and remediation process.

Alert Context Data

When an automation is executed on an alert (command, script, or playbook execution) the results are entered into the alert context, along with all alert fields.
Although an alert can access incident data (context and fields), it cannot access data related to other alerts' context and the incident context may be empty,
unless you add alert context to incident context data.

All alert data which is stored in alert fields is also stored in the context data. In most cases, not all context data is stored in alert fields. Alert fields represent a
subset of the total alert data.

To view context data, when investigating an alert, on the right-hand side of an alert click . When viewing the alert context data, you can see both the alert and
parent's incident context data.

NOTE:

When an alert is created, the alert data is stored in the context data, under the alert key. When an investigation is opened and commands are run, the data
returned from those commands is also stored as context data, outside of the main alert key.

Incident Context Data

As a general rule, when an alert is generated in Cortex XSIAM, context data is written to the alert and not to the incident. You can add data to the incident
context and Update Incident Fields From an Alert, By adding incident context data, it enables you to:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 286/1003
5/8/24, 9:18 AM PDF Export

Add context for remediation: If you have multiple alerts in an incident, you can avoid running duplicate actions, by using the parent incident context in a
playbook. You can add the alert context results to the incident context, such as the status, action, or ID and allow other playbooks to use the parent
incident context to see if action has occurred.

Incident Assignment: You may want to know if an analyst has been assigned to the incident or other alerts.

Insights at the incident level: As an automation engineer, you may want to set responses based on characteristics in the incident.

To view context data on the right-hand side of an incident, click .

Add Context Data to the Alert and Incident Using the CLI

To add context data to an alert or an incident, you can run the following commands in the CLI in the Alert or Incident War Room:

Run the Set command to add data to incident or alert context. The Set command enables you to set a value in context under a specific key. For example,
!Set key=hello value=world adds the key and value hello:world to the incident or alert context.

NOTE:

If you use the Set command in the Incident War Room, context is added to the Incident context. If running in the Alert War Room, it is added to the Alert
context.

Run the !setParentIncidentContext in the Alert or Incident War Room to add context to the parent incident. It is useful to add it in the alert war room,
so you can easily view the alert context and see what you want to add to the incident. For example, run !setParentIncidentContext key="hello"
value="world". In the incident context, you can see the owner of the alert.

If you run this command in the Incident War Room, the data is added to incident context data dialog box (click the Incident Context Data button to view the
added data). If running in the Alert War Room, you can see it both in the incident data dialog box and in the alert context data dialog box (incident tab).

To delete the context in the parent Incident, run the !deleteParentIncidentContext command in the Alert or Incident War Room. You can delete a specific
key or delete all the context.

Add Context Data Using a Playbook

In a playbook, context data can be used as follows:

When configuring playbook tasks, use information stored in the alert context as task inputs and outputs. You can apply filters and transformers to context
data before using the data in playbook tasks.

While running a playbook using the debugger. As context data may be updated during a playbook run, you can set a breakpoint to view the context data
after a specific task, which can be useful for designing and troubleshooting playbooks.

To see how to use context data in the playbook, see Use Context Data in a Jira Ticketing System.

When running a playbook, the data is written to the alert context data. You can also write the data to incident context data by using the
setParentIncidentContext script in a standard task. When you add data to the incident context, if you run playbooks in other alerts, those playbooks can use
the incident context data.

CAUTION:

Users with Trigger Playbook permissions on a given alert may still be able to modify the parent incident via commands and scripts, even without full access to
the incident.

By default, context data for sub-playbooks is stored in a separate context key. When a task in a main playbook accesses context data, it does not have direct
access to sub-playbook data. When a task in a sub-playbook accesses context data, it does not have direct access to the main playbook data. If the sub-
playbook has been configured to share globally, the sub-playbook context data is available to the main playbook and vice versa.

NOTE:

Generic polling does not work if a playbook’s context data is shared globally.

Add Context Data using a Script

In any script that runs in an alert, the data is written to the alert context. If you want to add the data to the incident context, in the JSon file, add the
setParentIncidentContext to the demisto.executeCommand key. For example, demisto.executeCommand("setParentIncidentContext", {"key":"
<key>", "value":"<value>"}).

For example, to add the close reason with the value to the incident context, add demisto.executeCommand("setParentIncidentContext",
{"key":"hello", "value":"world"}) to the Json file.

NOTE:

Ensure that you have the required RBAC permission to write scripts.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 287/1003
5/8/24, 9:18 AM PDF Export

Search Context Data

To view context data from within an alert or incident, on the right-hand side click . In the Context Data pane, you can use Query to search within the JSON for
specific items and expand nested keys.

Search examples:

${c} finds the value of the object c.

${HelloWorld.Domain(val.domain == 'example.com')} shows the full object for the example.com domain, as stored in the context data by the
domain command that is part of the HelloWorld integration.

${HelloWorld.Domain(val.domain == 'example.com').registrar} shows the registrar for the example.com domain, as stored in the context data
by the domain command that is part of the HelloWorld integration.

${HelloWorld.Alert(val.alert_status === "ACTIVE").alert_id} fetches the HelloWorld.Alert.alert_id of all ACTIVE alerts.

4.5.2.2 | Use Context Data in a Jira Ticketing System

Abstract

How to use Jira to manage alerts.

In Cortex XSIAM the playbook runs on each alert and not on the incident. In this example, a Jira ticketing system is used to manage alerts. When an action is
taken on an endpoint, some incidents may contain several alerts for the same endpoint. If each alert runs a playbook on the same endpoint, several tickets can
be created for each incident. This playbook checks existing endpoints and Incident IDs and decides whether to create a new ticket or whether to add to the
existing ticket, rather than having duplicate tickets.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 288/1003
5/8/24, 9:18 AM PDF Export

1. After checking that the Jira v3 integration is enabled, in this task, the playbook adds the EndpointFromAlerts key to the incident context, by retrieving
the alert.hostname using the setParentIncidentContext script.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 289/1003
5/8/24, 9:18 AM PDF Export

2. In this task, the playbook checks if there is an open ticket for the incident by retrieving the parentIncidentContext.TicketID.

3. If there is no open ticket, a new ticket is created in Jira and the TicketID is added to the Incident context.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 290/1003
5/8/24, 9:18 AM PDF Export

4. If there is an open ticket, this task checks whether there is an open ticket for the endpoint by comparing the alert.hostname (alert endpoint) to the
parentincidentContentEndpointFromAlerts key.

5. After retrieving the alert.hostname in the parentIncidentContextEndpointFromAlerts context, if there is no open ticket for the endpoint, the
playbook updates the Jira ticket for the incident.

In this example, you can see that the EndpointFromAlerts and TicketID has been added to the incident context data.

4.5.2.3 | Update Incident Fields From an Alert

Abstract

The different ways to update the incident fields.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 291/1003
5/8/24, 9:18 AM PDF Export

Sometimes you may want to update incident fields based on a change in the alert. For example, an analyst may want to change the severity of the incident,
which contains many alerts with different severities. After investigating one of the alerts, the analyst wants to change the severity to low.

You can update the following incident fields through a playbook, script, or command:

manual_severity

starred

assigned_user_email

status

score

incident_name

description

Update Incident Fields Using the CLI

You can update incident fields in the Incident or Alert War Room by running the !setParentIncidentFields command. For example, to change the name of
the incident to Malware, run !setParentIncidentFields incident_name=Malware.

NOTE:

You can add multiple fields at once. For example, !setParentIncidentFields incident_name=Malware starred=true

When selecting a field, you can see available values (for enums).

Update Incident Fields Using a Playbook

When running a playbook, by default the data is added to the alert context data and alert fields. You can add this data to incident context data and incident
fields, when configuring tasks in a playbook.

CAUTION:

Users with Trigger Playbook permissions on a given alert may still be able to modify the parent incident via commands and scripts, even without full access to
the incident.

In the following example, you want to star an incident in a playbook.

1. Add the following tasks to a new or existing playbook.

a. Create a Conditional task to check whether the parent incident fields are starred using the ${parentIncidentFields.starred} key.

b. Create a standard task using the setParentIncidentFields script to update the starred field.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 292/1003
5/8/24, 9:18 AM PDF Export

c. Create a standard task to print the value to the War Room.

2. Run the playbook.

In the incident context data, you can see the key starred: true. If running in an alert or an incident, after refreshing the incident, the incident is now
starred.

Update Incident Fields Using a Script

In any script that runs in an alert, the data is added to the alert fields. If you want to update incident fields, in a Json file, add the setParentIncidentFields to
the demisto.executeCommand function.

For example, to update the incident status to resolved, type demisto.executeCommand("setParentIncidentFields", {"status":"resolved_other"})

NOTE:

Ensure that you have the required RBAC permission to write scripts.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 293/1003
5/8/24, 9:18 AM PDF Export

4.5.2.4 | Alert Automation

Abstract

Save time and expense by automatically investigating and taking remedial action using a playbook.

You can automate relevant alerts by running a playbook, which can save time and expense by automatically investigating and taking remedial action. Playbooks
run on alerts to enrich information and combine with other products in your security set up, to assist with the investigation. You can view the playbook that is
running or has run in the Alert Work Plan.

You have the ability to resolve incidents or to automate parts of the incident investigation and resolution workflow. Some content packs include out-of-the-box
playbooks that run when a new alert is created. After configuring the playbook, when a playbook runs in an alert, the playbook can prompt the analyst for input
(in a task) to keep the remediation moving forward and to enable them to make remediation decisions while still getting the benefits of automation.

A playbook runs either when an alert is created or when you run it manually, as part of an investigation.

Run a playbook automatically

You can run a playbook in an alert automatically, as soon as the alert is created, by creating playbook triggers. Once the criteria is met, the playbook is
triggered. You can create your own playbook trigger, add a recommended playbook trigger (from a content pack in the Marketplace), or after resolving an
incident, accept the recommended playbook trigger. For more information about triggers, see Playbook triggers.

Select a playbook to run (the alert did not trigger a playbook)

If no playbook runs automatically, you can select a recommended playbook, or if there is no recommendation, select a different playbook to run. For
example, playbooks can take IP address information from one integration and enrich that IP address with information from additional integrations or
sources.

Before running a recommended playbook, you can preview the playbook to decide whether to accept the recommendation.

NOTE:

If you do not see a relevant playbook, ensure that you have installed the relevant content pack from Marketplace.

4.5.2.4.1 | Playbook triggers

Abstract

Learn how to create and add a playbook trigger to an alert.

A playbook trigger is a filter on an alert that creates conditions, so if an alert with specific characteristics is created (for example by source, severity, or MITRE
TTP), a suitable response is issued (via a playbook). This saves the analyst time and expense when investigating an alert.

You can create playbook triggers by doing the following:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 294/1003
5/8/24, 9:18 AM PDF Export

Create a playbook trigger

In the Playbook Triggers page (Incident Response → Incident Configuration → Playbook Triggers), create your playbook trigger from a playbook. After
you create a trigger, the next time an alert is triggered, the playbook runs automatically.

NOTE:

When ingesting alerts from a third party integration such as EWS, the playbook does not run automatically. You need to create a playbook trigger to run
the playbook including running any out-of-the-box playbooks.

Add a Recommended Playbook Trigger

In the Playbook Triggers page, add a playbook trigger from the Playbook Trigger Recommendations table. These playbooks are recommended to run
whenever the alert is triggered. These recommendations are part of the Core - Investigation and Response content pack and are designed for
Ransomware, WildFire, IOC Alerts, etc. Before adding them to the Playbook Triggers table you can view the playbooks in more detail. If you want to add
these triggers you need to add them to the Playbook Triggers table and then save your changes. The next time an alert is triggered, the playbook trigger
filter is created.

Add the Playbook Trigger after resolving an incident.

In some cases, Cortex XSIAM recommends a playbook to run in the alert. An analyst may want to investigate an alert that has an out-of-the-box playbook
available, but since this playbook is not connected to the incident or alert, Cortex XSIAM recommends the relevant playbook. If you have not added the
recommended trigger to the Playbook Trigger table, you have the option of adding a playbook trigger after resolving the incident, so the next time an alert
is ingested with similar criteria, the playbook trigger filter is created.

For example, the Core - Investigation and Response content pack includes several playbooks, such as Impossible Traveler, Ransomware, Wildfire
Malware, T1036 - Masquerading, etc. Once the content pack is installed, if any alerts are relevant for these playbooks, Cortex XSIAM recommends a
playbook to run in this alert.

In the following example, we have set up a BIOC rule based on the MITRE technique T1036 Masquerading.

Cortex XSIAM ingests an alert from the Agent and detects the BIOC Rule. In the Alert Work Plan tab, Cortex XSIAMrecommends using the Masquerading
playbook, which is based on the MITRE 1036 technique. If you want more information about the playbook or want to run the playbook, select Preview
Playbook. If you do not want to run the recommended playbook, select a different one.

When you mark the incident as resolved, you are prompted to create a playbook trigger.

After clicking Playbook Triggers, you can review which playbook Triggers to add in the Recommended Triggers for Alerts in this Incident table, so the next
time a similar alert is ingested, the playbook filter is created.

You do not need to run the recommended playbook in the Alert for the trigger to appear in the Recommended Triggers for Alerts in this Incident table. If
you use a playbook that is not recommended, it does not appear in the table.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 295/1003
5/8/24, 9:18 AM PDF Export

IMPORTANT:

Playbook triggers only apply to alerts that are grouped into incidents by the system. Most alerts with low and informational security do not allow a playbook to
be automatically executed on them. However, you can run a playbook on low severity alerts manually.

After you create a playbook trigger, the trigger is added to the Playbook Triggers table. In the Playbook Triggers table, you can do the following:

Set the priority of the playbook triggers, so when an alert is ingested, the first trigger takes priority, then the second, third, etc.

All recommended playbook triggers that are added (from the incident or the trigger table) are added to the top of the Playbook Triggers table. New triggers
created manually are added to the bottom of the table.

View details of the triggers that have been created.

By default, you can see the playbook name and trigger criteria, the playbook, and the creation dates and source. You can add columns and filters as
required. When right-clicking a playbook trigger, you can edit the trigger, and the playbook, delete, copy, or copy text.

Scope-based access control for playbook triggers

Playbook Triggers support SBAC (scoped based access control). The following parameters are considered when editing a trigger:

If Scoped Server Access is enabled and set to restrictive mode, you can edit a playbook trigger if you are scoped to all tags in the trigger.

If Scoped Server Access is enabled and set to permissive mode, you can edit a playbook trigger if you are scoped to at least one tag listed in the trigger.

As a scoped user that has editing permissions to a trigger, you can change the order among other triggers that are locked.

If a rule was added when set to restrictive mode, and then changed to permissive (or vice versa), you will only have view permissions.

4.5.2.4.2 | Create a Playbook Trigger

Abstract

Create a playbook trigger, so when an alert with specific characteristics is created, a suitable response is issued.

In the Playbook Triggers page, you can create a playbook trigger, add a recommended playbook trigger, view all playbook triggers, and change the order of
priority.

1. Select Incident Response → Incident Configuration → Playbook Triggers → New Triggers.

2. Add the following information:

Trigger name

Select a playbook to run

Add a meaningful description

3. In the Alerts field, select the criteria you want to add.

In this example, there are a number of alerts that are being ingested called McAfee + Zscaler - Malware Downloaded And Dropped To Disk. These alerts are as
a result of malware which was detected by the Agent. We created a custom playbook to run these alerts, so that if action is detected by the ePO, to either
quarantine the machine, where the malware is detected, or if no action to close the investigation. We want to create a playbook trigger, so the next time an alert
is ingested, the playbook runs automatically.

1. Created a trigger called McAfee + Zscaler - Malware Downloaded And Dropped To Disk.

2. Add the custom playbook.

3. In the Alerts section, select the name McAfee + Zscaler - Malware Downloaded And Dropped To Disk alerts.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 296/1003
5/8/24, 9:18 AM PDF Export

The alert is added to the playbook trigger table. The next time an alert is ingested with the criteria, the playbook runs according to the playbook trigger.

In this incident, you can see that there were 18 alerts that automatically ran 16 playbooks.

4. Select one of the alerts to see that the playbook ran (Work Plan or Alert War Room).

4.5.2.4.3 | Add a Recommended Playbook Trigger

Abstract

Add playbook triggers to an alert, so if the condition is met, a suitable response is issued through a playbook.

In the Playbook Triggers page, you can create a playbook trigger, add a recommended playbook trigger, view all playbook triggers, and change the order of
priority. The Core - Investigation and Response content pack includes a number of recommended playbook triggers for alerts, which you can to add to relevant
alerts that are ingested.

1. Select Incident Response → Incident Configuration → Playbook Triggers → View Recommendations.

2. In the Playbook Trigger Recommendations table, view and select the required recommended playbook triggers to add to the trigger table.

You can view each playbook in detail in the Playbooks page.

3. Click Add Selected triggers.

4. Verify the order of the playbook triggers and change the order (if required),

5. Save the changes to the Playbook Trigger table.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 297/1003
5/8/24, 9:18 AM PDF Export

4.5.2.5 | Run Indicator Extraction in the CLI

Abstract

Use reputation commands, extractindicators command, or the enrichIndicators command in the CLI.

In the Alert War Room CLI you can run the following commands at the alert level to extract and enrich indicators:

!extractIndicators

If you want to extract indicators from non-War-Room-entry sources (such as extracting from files), use the !extractIndicators command from the Alert
War Room CLI. The command does not create indicators but extracts them only. Use the command to do the following:

Validate regex: Test a specific string to see if the relevant indicators are extracted correctly, such as a URL.

In a playbook or automation. The command extracts indicators in a playbook or automation non-war-room-source, and potentially also creates and
enriches them (if required).

You can extract from the following:

A specified entry (an entry ID)

Investigation (Investigation ID)

Text

File path

For example, type !extractIndicators text="some text 1.1.1.1 something" Auto extract=inline. The entry text contains the text of the
indicators, which is extracted and enriched. You can also extract indicators by adding the auto-extract parameter with the script and the mode for which
you are setting it up. For example, !ReadFile entryId=826@101 auto-extract=inline. Usually, when using the CLI, you want to disable indicator
extraction. For example, if you return internal/private data to the War Room, and you do not want it to be extracted and enriched in third-party services,
add auto-extract=none to your CLI command.

!enrichIndicators

The !enrichIndicators command is usually used when you want to batch enrich indicators. This command works on existing indicators only (it does not
create them on its own). When running the command, the relevant enrichment command is triggered (such as !ip), which is based on the indicator type
that is found. The data is saved to context and to the indicator.

NOTE:

Triggering enrichment on a substantial amount of indicators can take time (since it's activating all enrichment integrations per indicator) and can result in
performance degradation.

Reputation commands (such as !ip)

This command can work on existing and non-existing indicators. If extraction is on, the data is saved both to the indicator and the alert’s context. If not,
then just to the context because the mapping flow is always triggered in enrichment commands. The default configuration is set to none in playbook tasks
for extraction.

The indicator does not need to exist to run the reputation command, as the command uses a third-party threat intel integration, such as Unit 42, IPinfo,
etc. You can also click the Enrich indicator button in the indicator layout.

4.5.2.6 | Alert Investigation Customization

Abstract

Customize an alert by creating fields and creating layouts.

You can create custom alert fields and custom alert layouts. Custom alert layouts can include both out-of-the-box and custom alert fields. Alert layouts are
applied to alerts according to layout rules.

4.5.2.6.1 | Alert Fields

Abstract

Add alerts fields for mapping, correlation rules, alert custom layouts and for display in the alerts table.

Cortex XSIAM includes out-of-the-box alert fields, alert fields from installed content packs, and user defined custom alert fields. Alert fields can be used for
mapping, correlation rules, custom alert layouts, and for display in the Alerts table.

All system and custom alert fields are available in the Alerts table. New custom fields are hidden by default. To show custom alert fields in the Alerts table view,
click the three dot vertical ellipses and select the column(s) from the list.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 298/1003
5/8/24, 9:18 AM PDF Export

For Grid fields, HTML fields, and Markdown fields, the Alerts table shows Data Available instead of the values, if the field contains data. To view the data, open
the alert and click Investigate to see the full alert layout. For multi-select fields, the first value is shown in the Alerts table and the number of additional values is
stated, but the additional values are not shown. For example, if a multi-select field holds the values x, y, and z, the Alerts table shows x + 2 More.

Cortex XSIAM stores both the original value of the field and the current value of the field, if different. Any changes made between the original value and the
current value are not stored. For example, if the original value of the field was x, the value was then changed to m, and then changed to y, only the x and y

values are stored. To view the original value and the current value of changed fields, hover over the updated alert fields icon on the right side of the row in
the Alerts table. To revert all of the fields in an alert to their original values, click Restore all fields to their original values, in the updated alert fields box.
Restoring all fields to their original values also restores the original values in the alert context data. Once you restore fields to their original values, this action
can not be undone.

Custom alert fields can be exported and imported. To export a single custom alert field, right-click on the field in the fields table, and select Export. To export all
custom alert fields in a single JSON file, click the Export All button above the fields table. System alert fields cannot be exported or imported.

After a custom alert field is created, it can be edited, deleted, or exported by right-clicking on the row. The field name and field type cannot be changed after the
field is created. System fields cannot be edited, deleted, or exported.

WARNING:

Deleting an alert field or uninstalling a content pack containing an alert field may affect detection and other capabilities based on the deleted field. For
example, correlation, layouts, incident scoring, starring rules, and playbook triggers.

4.5.2.6.1.1 | Alert Field Types

Abstract

When creating alert fields, you can add field types, such as boolean, date picker, and grid (table).

You can create the following types of alert fields.

Field Description

Boolean True or False

Incoming values 0, false, and False are treated as False.

Incoming values true, True, or any number besides 0 are treated as True.

Other values are treated as null.

Date picker Adds the date to the field.

Supported time formats for validation are ISO 8601 and Epoch. Other values are treated as null.

NOTE:

You cannot set filters, starring rules, playbook triggers, layout rules, or alert exclusions based on the values in custom timestamp fields.

Grid (table) Include an interactive, editable grid as a field. For details, see Create a Grid Field.

NOTE:

When grid field is shown in the Alerts table, if there are values in the field, they do not display in the Alerts table. Instead, the column
shows Data Available.

HTML Create and view HTML content.

NOTE:

When an HTML field is shown in the Alerts table, if there is a value in the field, it does not display in the Alerts table. Instead, the
column shows Data Available.

Long text Long text is analyzed and tokenized, and entries are indexed as individual words, enabling you to perform advanced searches and
use wildcards.

Long text fields cannot be sorted and cannot be used in graphical dashboard widgets.

While editing a long text field, pressing enter will create a new line. Case is insensitive.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 299/1003
5/8/24, 9:18 AM PDF Export

Field Description

Markdown Add markdown-formatted text as a Template which is displayed to users in the field. Markdown lets you add basic formatting to text to
provide a better end-user experience.

NOTE:

When a Markdown field is shown in the Alerts table, if there is a value in the field, it does not display in the Alerts table. Instead, the
column shows Data Available.

Multi select / Includes two options:

Array
Multi select from a pre-filled list.

An empty array field for the user to add one or more values as a comma-separated list.

In the Basic Settings section, enter a comma-separated list of values.

Number Can contain any number. Default is 0.

Short Text Short text is treated as a single unit of text, and is not indexed by word. Advanced search, including wildcards, is not supported.

Short text fields are case insensitive.

While editing a short text field, pressing enter will save and close.

Recommended use is one word entries. Examples: username, email address, etc.

Single select Select one from a list of options. Add a list of comma-separated values. By default, the first value is used, unless the checkbox for Use
first as default is cleared.

Timer Timer fields enable you to view how much time has passed since the timer was started and how much time remains until the timer times
out. You can also configure a script to run when a timer times out.

URL Contains a URL.

4.5.2.6.1.2 | Create Custom Alert Fields

Create alert fields so you can map from incoming alerts, map the output of queries from correlation rules, and add them to custom alert layouts.

You can create custom alert fields to:

Map raw JSON fields from incoming alerts.

Display custom fields data in the Alerts table.

Create correlation rules that generate alerts from XQL queries and map the output of the queries to custom alert fields.

Design custom alert layouts that include custom alert fields.

To create a new custom alert field:

1. Select Settings → Configurations → Object Setup → Alerts → Fields → New Field.

2. Choose a field type and enter a field name. For a description of available field types, see Alert Field Types. You can add an optional tooltip to provide
users with information about the field.

If adding a grid, see Create a Grid Field.

3. Save your changes.

Custom alert fields can be exported and imported. To export a single custom alert field, right-click on the field in the fields table, and select Export. To export all
custom alert fields in a single JSON file, click the Export All button above the fields table.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 300/1003
5/8/24, 9:18 AM PDF Export

After a custom alert field is created, it can be edited, deleted, or exported by right-clicking on the row. The field name and field type cannot be changed after the
field is created.

Create a Grid Field

The grid field enables you to view and edit a table. You can add a grid field to a custom alert layout.

1. Select Settings → Configurations → Object Setup → Alerts → Fields → New Field.

2. In the New Alert Field window Field Type field drop down list, select Grid (table).

3. Complete the following parameters:

Parameter Description

Field Name A meaningful name for the grid field.

Tooltip (Optional) A brief descriptive message that explains what the field is and how to use it.

User can add rows (Optional) Enables users to add/remove rows in the grid.

4. In the Grid tab, add or remove the required rows and columns.

How you design the grid determines how it appears to users. If the user can add rows field is selected, the user can add rows but not columns.

5. Configure each column by selecting the required field types, such as short text, Boolean, URL, etc. You can move the columns, rename, add values, etc.

If you select the Lock check box, the value for that field is static (not editable). If you do not select the Lock check box (default), users can perform inline
editing.

6. Click Save.

Timer fields in Cortex XSIAM

Abstract

Timer fields count up from when a specific event begins and can also count down to a deadline. You can trigger actions in the event the timer field is breached.

By default, timer fields are disabled in Cortex XSIAM. To enable timer fields, go to Settings → Configurations → General → Server Settings → Alerts and Enable
Timer Field.

Timer alert fields provide you with the ability to track reaction time and help you measure alert-level metrics. Timers can measure multiple aspects of an alert.
You can, for example, have a timer track how long since the first playbook ran, and have another timer track how long you've been waiting for a user's response.
Timers display in the alerts table and in alert layouts.

Timer fields can be started, stopped, or paused in a playbook, script, or manually in the CLI.

Timer fields count up from when a specific action or task began and also (optionally) count down from a target. The Risk Threshold tells you when a timer is
considered at risk and you can customize the time period for the Risk Threshold.

Timer fields always show the total duration while they are still running. If they are at risk, they show the at risk status. After a timer field has timed out (passed
the target), the timer shows both the total duration and how long past the target.

Timer fields do not automatically trigger actions when timers time out. You can configure a script to run when a timer times out.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 301/1003
5/8/24, 9:18 AM PDF Export

Scripts

You can run scripts to act on timeouts, such as sending an email when a timeout occurs. You can also make specific changes to an alert field or a parent
incident alert, such changing the incident owner. Cortex XSIAM includes out-of-the-box scripts or you can create your own scripts. Scripts must have the SLA tag
to be used for timer fields. For more information, see Automate changes to alert fields using timer scripts.

Using the CLI

If you want to set or change timers for an alert you can use the setAlert command in the CLI. You can also use commands such as startTimer, stopTimer,
and pauseTimer. For more information, see Use timer field commands manually in the CLI.

Configure timer fields

Abstract

Create a timer fields and optionally add scripts to trigger when timers have been breached.

You can create timer fields that display in the alerts table and alert layouts. When you create a timer field, you have the option of providing a target for
completion and also the option of triggering a script when the timer field has timed out (the target has passed). For more information about scripts, see Automate
changes to alert fields using timer scripts.

If you set a target for a timer field, the Risk Threshold is automatically activated and displays when the timer is considered at risk. You can customize the
timeframe for the Risk Threshold

If you do not provide a target, the timer only counts up from when it was triggered.

Timers can be started, stopped, or paused from the CLI, from scripts, and from playbooks.

To create a timer alert field:

1. Navigate to Settings → Configurations → Object Setup → Alerts → Fields → +New Field.

2. Select Timer as the Field Type.

3. Provide a Field Name.

4. (Optional) Under Basic Settings, Timer you have the option of setting a target for the timer field. By default, the timer field shows hours and minutes. You
can change this to days and hours, by clicking Hours. If you do not enter the number of hours and minutes, the timer only counts up from when it is
triggered.

If you set a target in the timer field, by default the Risk Threshold field is activated. You can edit the Risk Threshold value.

5. (Optional) Under Run script on timeout, select the script to run when the target has timed out. For example, you could write a script that sends an email
when the target has timed out. For more information, see Automate changes to incident fields using SLA scripts.

NOTE:

Only scripts to which you have added the SLA tag appear in the list of scripts you can select. To add a tag to a script, create a new script or edit an
existing script and enter the tag name in the script settings.

When you hover over the machine name (below the Field Name) note the name which is used in the command line or script.

6. Save the field.

7. (Optional) Add the field to one or more alert layouts. By default, the timer field is available to view in the alerts table.

Configure a playbook to run timers

Abstract

Add or configure a playbook to run timers.

Within a playbook, a timer can be set to start, pause, or stop at a specific section header or task. For example, you can create a timer called Pending user
response and have it start in a playbook when an email is sent to a user. If the user does not respond within the target timeframe, then you can automatically
send an additional reminder to the user or run a different task.

When selecting a timer in a task or section header, in the Timers tab, select the action that you want the timer to perform for the task. You can add multiple
timers to a task or section header, so in the same task you can stop one timer and start another.

NOTE:

When a task or section has a timer configured, it displays the hourglass icon.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 302/1003
5/8/24, 9:18 AM PDF Export

Option Description

Timer.start Starts the timer.

NOTE:

Timers are not started automatically when an incident is created.

Timer.pause Pauses the timer. A paused timer can be started again without being reset.

Timer.stop Stops the timer. Information about the timer is still displayed in the alert layout and/or alerts table, but the status displays as Ended.

NOTE:

If you stop a timer before the alert is closed, you must reset the timer using the resetTimer command before you can start the timer
again. When you reset the timer, all fields are cleared.

Some playbooks, such as Phishing - Generic v3, come out-of-the-box with timer tasks included. If you need the same timers across use cases, create a sub-
playbook based on your use case or conditions such as alert severity.

If you want to stop or pause a timer in a playbook, you can use an existing task or create a new section header/task. When you select Timer.stop, the run is
considered finished and cannot be restarted without setting it to zero. If you plan to restart the timer, select Timer.pause so you do not lose the accumulated
time. By default, all timers stop when the incident closes.

Automate changes to alert fields using timer scripts

Abstract

Create scripts to perform specific actions in Cortex XSIAM Cortex XSIAM when the SLA is breached. Properties in the timer field value.

Scripts in Cortex XSIAM enable you to automate processes. You can create scripts that will perform specific actions when a timer field times out. Scripts used
with timers must have the SLA tag.

You can use an out-of-the-box or custom script and attach it to an timer alert field.

A common use of scripts for timer fields is to send an email when a timer is breached. You can create a custom script that sends an email to specific users when
the script is triggered. You can add this to any timer alert field as needed.

Create timer scripts

Abstract

Create scripts that perform specific actions in Cortex XSIAM when a timer field times out.

When you create your scripts, the following arguments are automatically added, in addition to the basic elements provided with every script (for example, current
investigation and current alert):

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 303/1003
5/8/24, 9:18 AM PDF Export

field: The current triggered timer field object (contains: name, cliName, threshold and more.).

fieldValue: The current triggered timer field's value. For example the startDate.

The following table lists the different properties in the SLA timer field value:

Property Type Description

dueDate Date The date the timer is due.

breachTriggered Boolean Whether the timer has timed out.

sla INT (in minutes) The time period for this timer. This is the value that you defined in the Timer field.

endDate Date The date the timer completed.

lastPauseDate Date The last date the timer was paused.

startDate Date The date at which the timer was started.

accumulatedPause INT (in seconds) The total number of seconds that the timer was in a paused state.

totalDuration INT (in seconds) The total number of seconds that the timer was running. This property is populated after the timer
is stopped.

slaStatus INT Represents the Cortex XSIAM timerstatus. Values are:

-1: The timer has not been set.

0: The timer is within the allotted range.

1: The timer is below the defined risk threshold.

2: The timer has timed out.

runStatus String Represents the current status of the timer. Values are:

idle

running

paused

ended

Use timer field commands manually in the CLI

Abstract

Set and change timers for specific alerts, such as decreasing the required response time for a high-priority incident.

You can manage the timers for a specific alert manually in the CLI. This enables you to manage timers on a more granular level within specific alerts when the
need arises. For example, the severity of the alert might dictate that you decrease the response time for the given alert.

Set timer fields

Use the setAlert command to set a specific alert due date or to set a specific timer field in an alert. When adding the sla parameter to the command, it sets
the time for the alert's due date. If you also add the slaField you set the timer for the incident field.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 304/1003
5/8/24, 9:18 AM PDF Export

For example, to change the Time to Assignment field target to 30 minutes in the current alert:

!setAlert sla=30 slaField=timetoassignment

To change the timer to February 1, 2024, at 11.12 am:

!setAlert sla=2024-02-01T11:12

NOTE:

When defining the values for the slaField use the machine name for the field, which is lowercase and without spaces. You can check the machine name by
editing the alert field.

Start/stop timer fields

Use the following commands in the CLI:

Command Description

startTimer Starts the timer. For example, !startTimer timerField=timetoassignnment. This command can also be used to restart a paused timer.

NOTE:

Timer fields are not started automatically when an alert is created unless run in a playbook.

pauseTimer Pauses the timer. For example, !pauseTimer timerField=timetoassignment. Use this command when a timer field has already started.

stopTimer Stops the timer. For example, !stopTimer timerField=timetoassignment. After a timer field is stopped, you can only start the timer
again after you reset the timer using the resetTimer command.

NOTE:

Timers are automatically stopped when an alert is closed.

resetTimer Clears all fields for the timer. This command must be used before restarting a timer that was stopped. For example, !resetTimer
timerField=timetoassignment.

NOTE:

When running commands in the CLI, you can specify the alertID to change the timer for a different alert.

4.5.2.6.2 | Alert Layouts

Abstract

View system layouts or create custom layouts for your alert type.

Cortex XSIAM includes default alert layouts. Additional alert layouts can be added by installing content packs, duplicating system alert layouts for editing, or
creating new custom alert layouts. Alert layouts are applied to incoming alerts based on alert layout rules.

When viewing an alert, to see how alert information is displayed in a layout, click on Investigate. To see which alert layout has been applied to the layout and

which rule triggered the use of the layout, click the Layout Info button in the upper right corner of the layout. Empty layout fields are hidden by default, but
are shown if you select Show empty fields.

The default alert layouts and any layouts that are added from content packs, are locked by default and cannot be deleted, edited, or exported. To view a system
layout, right-click the layout row and select View. If you want to edit a system layout, you can detach or duplicate the layout by right-clicking the layout row in the
alert layout table and selecting Detach or Duplicate. If you detach a layout, the layout does not receive content updates until it is reattached. To reattach a
system layout, right-click the layout row and select Attach. If you detach a layout and make changes, those changes may be overwritten if you later reattach the
layout. If a layout is detached, you can edit or duplicate it, but you cannot delete or export it. If you instead duplicate the alert layout, the new duplicated layout
can be edited, deleted, or exported, the same as a custom alert layout.

When viewing an alert, most alert fields can be edited inline, by users with editing permissions. . After editing a field inline, click the check mark to save
your change. Some system fields, such as Source Instance, cannot be edited.

To modify an existing custom layout, go to Settings → Configurations → Object Setup → Alerts → Layouts , right-click the layout in the layouts table, and select
Edit, Duplicate, Delete, or Export.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 305/1003
5/8/24, 9:18 AM PDF Export

4.5.2.6.2.1 | Create Custom Alert Layouts

Abstract

Create an alert layout to select the specific fields and buttons you require.

Custom alert layouts let you choose the specific fields and buttons that are displayed for different types of alerts. You can create custom alert layouts that
include both custom and out-of-the-box alert fields.

The Alert Info tab and any new tabs you create can be renamed, hid, duplicated, or deleted. To make these changes, hover over the tab name, click the settings
button, and select the relevant option. You can drag and drop tabs to change the order they appear. By default, empty fields within the tab are hidden in the alert
layout. To show empty fields, hover over the tab name, click the settings button, and select Show empty fields.

You cannot edit the War Room and Work Plan tabs in the alert layout. You can hide these tabs from the layout by hovering over the tab name, clicking the
settings button, and selecting Hide tab.

Custom alert layouts, as well as duplicates of system alert layouts, can be exported. To export a single alert layout, right-click on the layout in the layouts table,
and select Export. To export all custom alert layouts and duplicates of system alert layouts in a single JSON file, click the Export All button above the layouts
table.

You can import a custom alert layout by clicking Import and uploading the JSON file.

Create a Custom Alert Layout

1. Select Settings → Configurations → Object Setup → Alerts → Layouts → New Layout.

2. Enter a name for the layout.

3. You can add sections and fields to the Alert Info tab or click +New tab .

4. To add a new section, in the Library dialog box Sections tab, drag and drop New Section into the Alert Info tab or your new custom tab.

By clicking on the pencil icon for a section, you can configure how a section appears, by hiding or showing the section header, as well as configuring the
section fields to appear in rows or as cards.

Some sections have additional configuration options. If you add a Malicious or Suspicious Indicators section, for example, you can configure the indicator
search query. If you add a War Room Entries section, you can filter by type of entry, such as chats, notes, files, etc.

The General Purpose Dynamic Section enables you to configure a section that displays the results of a script. Only scripts to which you have added the
dynamic-section tag appear in the dropdown list. You can use the General Purpose Dynamic Section to display custom or system widgets, text,
markdown, or HTML.

5. To add custom or out-of-the-box alert fields to the layout, drag the fields from the Fields and Buttons tab into existing sections or new sections that you
added to the layout.

TIP:

Limit the number of alert fields to 50 in each section. You can create additional sections as needed.

6. Custom buttons can simplify and assist an analyst in carrying out various tasks. For example, you can add a button to scan a host or kill a process.

For fields (script arguments) that are optional, you can define whether to show them to analysts when they click on buttons. To expose an optional field,
select the Ask User checkbox next to the script argument(s) in the button settings page.

NOTE:

The script that runs when an action button is clicked accepts only mandatory arguments through the pop up window and does not provide an option for
any non-mandatory arguments to be filled in when the button is clicked. We recommend using a wrapper script to collect and validate arguments in
scenarios where there can be a combination of mandatory and non-mandatory arguments for a button.

To add a button to a layout:

a. Drag the +New Button from the Fields and Buttons tab and drop into the relevant section.

b. Click to configure.

c. Enter a descriptive name for the button, select a color, and select the script that you want to run when the button is clicked.

d. Click Save.

7. Save the layout.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 306/1003
5/8/24, 9:18 AM PDF Export

8. (Optional) To modify an existing layout, right-click the layout in the layout table and select Edit, Duplicate, Delete, or Export.

Add a Custom Widget to an Alert Layout

Abstract

Add any widget to a a custom alert layout.

You can add a custom or system widget to a custom alert layout.

The following example shows how to add an Indicator Widget Bar. This custom widget script shows the severity of indicators in an alert, as a bar chart.

1. Add the Indicator Widget Bar script to Cortex XSIAM.

a. On the Scripts page, upload the following script:

commonfields:
id: ee3b9604-324b-4ab5-8164-15ddf6e428ab
version: 49
name: IndicatorWidgetBar
script: |-
# Constants
HIGH = 3
SUSPICIOUS = 2
LOW = 1
NONE = 0

indicators = []
scores = {HIGH: 0, SUSPICIOUS: 0, LOW: 0, NONE: 0}
incident_id = demisto.incidents()[0].get('id')

foundIndicators = demisto.executeCommand("findIndicators", {"query":'investigationIDs:{}'.format(incident_id), 'size':999999})[0]['Contents']

for indicator in foundIndicators:

scores[indicator['score']] += 1

data = {
"Type": 17,
"ContentsFormat": "bar",
"Contents": {
"stats": [
{
"data": [
scores[HIGH]
],
"groups": None,
"name": "high",
"label": "incident.severity.high",
"color": "rgb(255, 23, 68)"
},
{
"data": [
scores[SUSPICIOUS]
],
"groups": None,
"name": "medium",
"label": "incident.severity.medium",
"color": "rgb(255, 144, 0)"
},
{
"data": [
scores[LOW]
],
"groups": None,
"name": "low",
"label": "incident.severity.low",
"color": "rgb(0, 205, 51)"
},
{
"data": [
scores[NONE]
],
"groups": None,
"name": "unknown",
"label": "incident.severity.unknown",
"color": "rgb(197, 197, 197)"
}
],
"params": {
"layout": "horizontal"
}
}
}

demisto.results(data)
type: python
tags:
- dynamic-section
enabled: true
scripttarget: 0
subtype: python3
runonce: false

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 307/1003
5/8/24, 9:18 AM PDF Export

dockerimage: demisto/python3:3.7.3.286
runas: DBotWeakRole

b. Click Save.

2. Add the widget to an alert layout.

a. Go to Settings → Configurations → Object Setup → Alerts → Layouts.

b. Create a new custom alert layout or right-click to open an existing custom alert layout or a detached or duplicated system layout.

c. Drag and drop the General Purpose Dynamic Section into a layout tab.

d. Edit the General Purpose Dynamic Section by clicking the pencil icon.

e. Enter a name for the section and choose the automation script you uploaded in Step 1.

f. Click Ok.

4.5.2.6.2.2 | Create Rules for Alert Layouts

Abstract

Add rules to assign a custom alert layout based on the alert source,

Alert layouts are applied to alerts according to layout rules. For example, using a layout rule, you can assign a custom alert layout based on the alert source,
such as a specific layout for alerts generated from a correlation rule.

You can create multiple rules. If the first rule does not apply to the incoming alert, the next rule is checked, and so on. If a content pack is installed and it
contains a layout rule, the layout rule is placed at the top of the rules list, by default. You can change the order of the rules by dragging and dropping the rules in
the list. You can filter the rule list by name, description, rule, layout, and source. If no layout rules apply to the alert, a default alert layout is used.

To edit or delete existing rules, right-click on the rule in the list and select Edit or Delete.

NOTE:

Layout rules support SBAC (scoped based access control). The following parameters are considered for editing access.

If Scoped Server Access is enabled and set to restrictive mode, you can edit a rule if you are scoped to all tags in the rule.

If Scoped Server Access is enabled and set to permissive mode, you can edit a rule if you are scoped to at least one tag listed in the rule.

As a scoped user who has editing permissions to a rule, you can change the order among other rules that are locked.

If a rule was added when set to restrictive mode, and then changed to permissive (or vice versa), you will only have view permissions.

1. Select Settings → Configurations → Object Setup → Alerts → Layout Rules → New Rule.

2. Enter a Rule Name, select the custom or out-of-the-box Layout to Display if the rule is met, and provide a Description.

3. Search for alert(s) that match the criteria you want to use for the layout rule. For example, you can search for alerts from a specific alert source.

4. Create the rule.

5. Repeat as needed to create multiple rules.

6. Save the rules you have created.

4.5.3 | Triage Alerts

Abstract

Manage and investigate alerts in the Cortex XSIAM management console.

When the Cortex XSIAM management console displays a new alert on the Alerts page, use the following steps to investigate and triage the alert:

1. Review the data shown in the alert such as the command-line arguments (CMD), process info, etc.

For more information about the alert fields, see Alerts.

2. Analyze the chain of execution in the Causality View.

When the app correlates an alert with additional endpoint data, the Alerts table displays a green dot to the left of the alert row to indicate the alert is
eligible for analysis in the Causality View. If the alert has a gray dot, the alert is not eligible for analysis in the Causality View. This can occur when there is
no data collected for an event, or the app has not yet finished processing the EDR data. To view the reason analysis is not available, hover over the gray
dot.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 308/1003
5/8/24, 9:18 AM PDF Export

3. Review the Timeline View of the sequence of events over time.

The timeline is available for alerts that have been stitched with endpoint data.

4. If deemed malicious, consider responding by isolating the endpoint from the network.

5. Remediate the endpoint and return the endpoint from isolation.

6. Inspect the information again to identify any behavioral details that you can use to Create a BIOC Rule and Create a Correlation Rule.

If you can create a BIOC or Correlation rule, test and tune the logic for the rule, and then save it.

4.5.4 | Manage Alerts

Abstract

You can manage alerts and view alert details from the Alerts page in Cortex XSIAM.

In the Incident Response → Incidents → Alerts Table, you can manage the alerts you see and the information about each alert.

The options available can change depending on the Alert Source.

Copy Alerts

Abstract

Copy an alert into memory.

You can copy an alert into memory as follows:

Copy the URL of the alert record

Copy the value for an alert field

Copy the entire row of alert record

With either option, you can paste the contents of memory into an email to send. This is helpful if you need to share or discuss a specific alert with someone. If
you copy a field value, you can also easily paste it into a search or begin a query.

1. Create a URL for an alert record:

a. From the Alerts page, right-click the alert you want to send.

b. Select Copy alert URL.

Cortex XSIAM saves the URL to memory.

c. Paste the URL into an email or use it as needed to share the alert.

2. Copy a field value in an alert record:

a. From the Alerts page, right-click the field in the alert that you want to copy.

b. Select Copy text to clipboard.

Cortex XSIAM saves the field contents to memory.

c. Paste the value into an email or use it as needed to share information from the alert.

3. Copy the entire row of alert record

a. From the Alerts page, right-click on one or more alerts you want to copy.

b. Select Copy entire row(s).

c. Paste the value into an email or use it as needed to share information from the alert.

Analyze an Alert

Abstract

Learn more about analyzing alerts in the Alert Panel View and the Causality View.

To help you understand the full context of an alert, Cortex XSIAM provides the Alert Panel view and the Causality view that enable you to quickly make a
thorough analysis.

The Causality View is available for XDR agent alerts that are based on endpoint data and for alerts raised on network traffic logs that have been stitched with
endpoint data. In addition, you can use the Cloud Causality View to analyze cloud Cortex XSIAM alerts and Cloud Audit Logs. While the SaaS Causality View

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 309/1003
5/8/24, 9:18 AM PDF Export

enables you to analyze and investigate software-as-a-service (SaaS) related alerts for audit stories, such as Office 365 audit logs and normalized logs.

To view the analysis:

1. From the Alerts page, locate the alert you want to analyze.

2. Click the alert and review the information in the Alert Panel view.

3. Right-click anywhere in the alert, and select Investigate Causality Chain.

4. Choose whether to open the Causality View card for an alert in a new tab or the same tab.

You can also view the causality chain over time using the Timeline view.

5. Review the chain of execution and available data for the process and, if available, navigate through the process tree.

Run a Playbook on an Alert

You can run or rerun a playbook on one or more alerts. If there is currently a playbook running on one or more of the selected alerts, the Run Playbook option
does not appear. If a playbook is running on the alert, but has been paused (for example, waiting for a user action), you can select to rerun the playbook or
select a new playbook.

1. Right-click one or more alerts in the Alerts Table or the Alerts & Insights table within an incident and select Run Playbook.

2. If the alerts have a playbook already assigned, choose Rerun current Playbook or Choose another Playbook. If the playbooks do not have a playbook
assigned, Choose a Playbook.

3. If you are not rerunning the current assigned playbook, select a playbook to run for the selected alert(s).

4. Run the playbook.

Pivot to Views

Abstract

Pivot to an alert-related view.

From any listed alert you can pivot to the following alert-related views:

Open Asset View—Open the Asset View panel and view information related to the alert there.

View full endpoint details—View the full details of the endpoint to which the alert relates.

View related incident—View information about an incident related to the alert.

View Observed Behaviors—View information about observed behaviors that are related to the alert.

To pivot to any of these views:

1. Right-click a listed alert.

2. From the pop-up menu, select the view to which you want to pivot.

Create Profile Exceptions

Abstract

For Agent alerts, you can create profile exceptions.

For XDR Agent alerts, you can create profile exceptions for Window processes, BTP, and JAVA deserialization alerts directly from the Alerts table.

1. Right-click an XDR Agent alert which has a category of Exploit and Create alert exception.

2. Select an Exception Scope:

Global—Apply the exception across your organization.

Profile—Apply the exception to an existing profile or click and enter a Profile Name to create a new profile.

3. Add the scope.

4. (Optional) View your profile exceptions.

a. Navigate to Endpoints → Policy Management → Profiles.

b. In the Profiles table, locate the OS in which you created your global or profile exception and right-click to view or edit the exception properties.

Add File Path to Malware Profile Allow List

Abstract

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 310/1003
5/8/24, 9:18 AM PDF Export

Add file path on existing Malware profile.

Add a file path to an existing Malware profile Allow List directly from the Alerts table.

1. In the Alerts table, select the Initiator Path, CGO path, and/or File Path field values you want to add to your malware profile allow list.

2. Right-click and select Add <path type> to malware profile allow list.

3. In the Add <path type> to malware profile allow list dialog, select from your existing Profiles and Modules to which you want to add the file path to the
allow list.

4. (Optional) View your Malware profile allow list.

a. Navigate to Endpoints → Policy Management → Prevention → Profiles and locate the malware profile you selected.

b. Right-click, select Edit Profile and locate in the Files / Folders in Allow List section the path file you added.

Create a Featured Alert Field

Abstract

You can label specific alert attributes as Featured Alert Fields.

To better highlight alerts that are significant to you, Cortex XSIAM enables you to label specific alert attributes as Featured Alert Fields. Featured alert fields help
you track in the Alerts Table alerts that involve specific host names, user names, and IP addresses.

1. Navigate to Incident Response → Incident Configuration → Featured Fields and select a type of featured field:

Hosts

Users

IP Addresses

Active Directory

2. In the field type table, Add featured <field-type> to define a list of alert fields you want to be flagged in the Alerts Table. You can either Create New
featured alert field from scratch or Upload from File.

To create a new alert field:

a. Enter one or more field-type values and Add to the list.

b. (Optional) Add a comment.

c. Add the featured alert field.

To import fields:

a. Browse or Drag and Drop your CSV file of field values. Download example file to ensure you use the correct format.

b. Import your file.

3. (Optional) Manage your featured alert field list.

Locate the alert field you want to edit or delete.

Right-click and Edit <field-type> to modify the field definition, or Delete Field Name to remove the featured flag.

4. Investigate alerts that contain the featured alert fields.

Navigate to the Alerts Table.

In the Alerts table, sort according to the following fields:

Contains Featured Host

Contains Featured User

Contains Featured IP Address

In the Alert Name field, Cortex XSIAM displays alerts that contain a matching featured field value with a flag.

NOTE:

Featured Active Directory values are displayed in the User and Host fields accordingly.

(Optional) Create an Incident Scoring Rule using the Alert table Contains Featured Field Name fields to further highlight and prioritize alerts
containing the Host, User, and IP address attributes.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 311/1003
5/8/24, 9:18 AM PDF Export

View Generating BIOC or IOC Rule

Abstract

You can view the BIOC or IOC rules that generated alerts directly from the Alerts table.

Easily view the BIOC or IOC rules that generated alerts directly from the Alerts table.

1. From the Alerts page, locate alerts with Alert Sources: XDR BIOC and XDR IOC.

2. Right-click the row, and select Manage Alert → View generating rule.

Cortex XSIAM opens the BIOC rule that generated the alert in the BIOC Rules page. If the rule has been deleted, an empty table is displayed.

3. Review the rule, if necessary, right-click to perform available actions.

Retrieve Additional Alert Details

Abstract

You can access additional information relating to an alert.

To easily access additional information relating to an alert:

1. From the Alerts page, locate the alert for which you want to retrieve information.

2. Right-click anywhere in the alert, and select one of the following options:

Retrieve Additional Data— Cortex XSIAM can provide related files and additional analysis of the memory contents when an exploit protection
module raises an Alert.

Select Retrieve alert data and analyze to retrieve alert data consisting of the memory contents at the time the alert was raised. You can also
enable Cortex XSIAM to automatically retrieve alert data for every relevant Alert. After Cortex XSIAM receives the data and performs the
analysis, it issues a verdict for the alert. You can monitor the retrieval and analysis progress from the Action Center (pivot to view Additional
data). When the analysis is complete, it displays the verdict in the Advanced Analysis field.

Select Retrieve related files To further examine files that are involved in an alert, you can request the agent send them to the Cortex XSIAM
tenant. If multiple files are involved, the tenant supports up to 20 files and 200MB in total size. The agent collects all requested files into one
archive and includes a log in JSON format containing additional status information. When the files are successfully uploaded, you can
download them from the Action Center for up to one week.

Retrieve related files—To further examine files that are involved in an alert, you can request the agent send them to the Cortex XSIAM tenant. If
multiple files are involved, the tenant supports up to 20 files and 200MB in total size. The agent collects all requested files into one archive and
includes a log in JSON format containing additional status information. When the files are successfully uploaded, you can download them from the
Action Center for up to one week.

For PAN NGFW source type alerts, Download triggering packet—Download the session PCAP containing the first 100 bytes of the triggering packet
directly from Cortex XSIAM . To access the PCAP, you can download the file from the Alerts table, Incident, or Causality view.

3. Navigate to Response → Action Center to view the retrieval status.

4. Download the retrieved files locally.

In the Action Center, wait for the data retrieval action to complete successfully. Then, right-click the action row and select Additional Data. From the
Detailed Results view, right-click the row and select Download Files. A ZIP folder with the retrieved data is downloaded locally.

TIP:

If you require assistance from Palo Alto Networks Support to investigate the alert, ensure to provide the downloaded ZIP file.

Export Alert Details to a File

Abstract

You can review alert details offline by exporting alerts to a TSV file.

To archive, continue investigation offline, or parse alert details, you can export alerts to a tab-separated values (TSV) file.

1. From the Alerts page, adjust the filters to identify the alerts you want to export.

2. When you are satisfied with the results, click the download icon ( ).

The icon is grayed out when there are no results.

Cortex XSIAM exports the filtered result set to the TSV file.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 312/1003
5/8/24, 9:18 AM PDF Export

Exclude Alert

Abstract

You can exclude alerts.

To exclude an alert.

1. From the Alerts page, locate the alert you want to exclude.

2. Right-click the row, and select Manage Alert → Exclude Alert.

A notification displays indicating the exclusion is in progress.

Investigate Contributing Events

Abstract

You can go over events created by an alert.

When managing alerts generated by a Correlation Rule, you can Investigate Contributing Events, which opens a window with all the events created for this alert.
You can have up to 1000 events per Correlation Rule. In addition, if the alert generated for this Correlation Rule includes a Drilldown Query, you can select
Open drilldown query, which opens a new browser in XQL Search to run this query.

To investigate contributing events.

1. From the Alerts page, locate the alert you want to investigate contributing events.

2. Right-click the row, and select Manage Alert → Investigate Contributing Events.

3. (Optional) Open drilldown query.

If the Correlation Rule that generated this alert is configured with a Drilldown Query to provide additional information about the alert for further
investigation, you can open a new browser in to run the query. This Cortex Query Language (XQL) query can accept parameters from the alert output for
the Correlation Rule. If the Correlation Rule that generated this alert does not include a Drilldown QUERY, no link is displayed.

The time frame used to run the Drilldown Query provides more informative details about the alert generated by the Correlation Rule. The alert time frame
is the minimum and maximum timestamps of the events for the alert. If there is only one event, the event timestamp is the time frame used for the query.

a. Select the Open drilldown query link.

A new browser in XQL Search is opened where you can run the query and any other operations related to XQL Search.

b. Select Run.

Open Drilldown Query

Abstract

You can drilldown to examine additional information.

When the Correlation Rule that generated an alert is configured with a Drilldown Query to provide additional information about the alert for further investigation,
you can open a new browser in to run the query. This Cortex Query Language (XQL) query can accept parameters from the alert output for the Correlation Rule.
If the Correlation Rule that generated this alert does not include a Drilldown Query, the option is not available.

The time frame used to run the Drilldown Query provides more informative details about the alert generated by the Correlation Rule. The alert time frame is the
minimum and maximum timestamps of the events for the alert. If there is only one event, the event timestamp is the time frame used for the query.

To open the Drilldown Query.

1. From the Alerts page, locate the alert you want to open the Drilldown Query.

2. Open Drilldown Query.

You can open the Drilldown Query in the following ways.

Select the quick action Open Drilldown Query icon ( ).

Right-click the row, and select Manage Alert → Open Drilldown Query.

Right-click the row, and select Manage Alert → Investigate Contributing Events.

A new browser in XQL Search is opened where you can run the query and any other operations related to XQL Search.

3. Select Run.

Manage Automation Rules

Add or edit an automation rule to trigger an action when the alert matches the condition of the rule created.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 313/1003
5/8/24, 9:18 AM PDF Export

1. Navigate to Incident Response → Response → Automation and select Automation Rules.

2. Click the Add Automation Rule button or hover over the rule and select the pencil icon to edit the rule.

3. Rule Name and Conditions:

a. Enter a Rule Name and set the Rule Status.

b. From the Alerts table, use the filter to retrieve the criteria to define the condition of the automation rule.

c. Click Next.

4. Select Action:

a. From the Action list, select the relevant action to initiate when the alert condition is triggered.

5. Exclude Endpoints:

NOTE:

This option is only accessible to Action type Endpoint Response.

a. In the Exclude Endpoints page, select the endpoint/s and click Next or click Skip.

6. In the Summary page, verify the settings and click Done.

7. Manage the automation rule, as needed.

Edit

Save as new—Opens the Clone Automation Rule wizard which enables you to save as a new rule.

Disable—The rule will not be processed.

Delete

Copy entire row—Copy the entire row to your clipboard.

4.5.5 | Alert Panel View

Abstract

The Alert Panel provides detailed information about alerts at a glance and in the context of the incident.

The Alert Panel provides detailed information about alerts at a glance and in the context of the incident. To open the Alerts panel, in the Alerts Table, click on any
alert.

In this view, you can change the severity of an alert, star it, investigate it in the Causality view, and exclude it from the Analytics.

This panel displays the name and description of the alert, the source that triggered the alert, and the following details where applicable.

GENERAL

Displays the following information about the alert.

Timestamp

ID

Number of suppressed alerts (for IOC, BIOC, and Analytics alerts) —Number of alerts that were suppressed because they were detected as duplicates of
the alert

Last suppressed alert timestamp (for IOC, BIOC, and Analytics alerts)—The last time Cortex XSIAM suppressed an alert because it was detected as a
duplicate of the alert

Action taken as a result of the alert

Category—type of threat detected

File Macro SHA256

Tags applied by Cortex XSIAM

BEHAVIORAL ANALYTICS

NOTE:

The Behavioral Analytics section is available only when the Identity Threat Module add-on is enabled. Cortex XSIAM displays Behavioral Analytics widgets for
selected alerts and is continuously adding widgets to more alerts.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 314/1003
5/8/24, 9:18 AM PDF Export

The BEHAVIORAL ANALYTICS section displays graphs that visualize the anomalies that were observed by the detector. This enables you to evaluate the
deviation in the context of the baseline behavior. As you navigate between the different factors that triggered the alert, the event and the baseline information are
displayed in tabular format or in timeline format, depending on the type of event.

The tabular view displays the baseline behavior in a table, with the anomaly highlighted and in a separate line.

The timeline view displays the highlighted atypical value, and if applicable, the minimum, maximum, and average values, for the selected period.

From the Behavioral Analytics section, you can navigate to the Causality chain.

MITRE ATTACK

Displays the Mitre Attack tactics and techniques.

HOST

Displays the Host platform, Host name, Host IP, Host MAC address, Host FQDN.

RULE

When the alert is triggered by a rule, the RULE section displays details about the rule, for example Type, Severity, Name, Description, Number of Hits, and
Source.

NETWORK CONNECTIONS or LOGIN or PROCESS EXECUTION or RPC CALL, SYSTEM CALL, or REGISTRY EVENTS

Displays relevant information about the connection details.

CLOUD AUDIT LOG

Displays the Audit log details for alerts generated on Cloud hosts.

4.5.6 | Causality View

Abstract

See the causality of an alert—the entire process execution chain that led up to the alert in the Cortex XSIAM app.

The Causality View provides a powerful way to analyze and respond to alerts. The scope of the Causality View is the Causality Instance (CI) to which this alert
pertains. The Causality View presents the alert (generated by Cortex XSIAM or sent to Cortex XSIAM from a supported alert source such as the XDR agent)
and includes the entire process execution chain that led up to the alert. On each node in the CI chain, Cortex XSIAM provides information to help you
understand what happened around the alert.

The Causality View comprises five sections:

Context

Summarizes information about the alert you are analyzing, including the host name, the process name on which the alert was raised, and the host IP and MAC
address . For alerts raised on endpoint data or activity, this section also displays the endpoint connectivity status and operating system.

Causality Instance Chain

Includes the graphical representation of the Causality Instance (CI) along with other information and capabilities to enable you to conduct your analysis.

The Causality View presents a single CI chain. The CI chain is built from process nodes, events, and alerts. The chain presents the process execution and might
also include events that these processes caused and alerts that were triggered by the events or processes. The Causality Group Owner (CGO) is displayed on
the left side of the chain. The CGO is the process that is responsible for all the other processes, events, and alerts in the chain. You need the entire CI to fully
understand why the alert occurred.

NOTE:

There are no CGOs in the Cloud Causality View, when investigating cloud Cortex XSIAM alerts and Cloud Audit Logs, or SaaS Causality View, when
investigating SaaS-related alerts for 501 audit events, such as Office 365 audit logs and normalized logs.

Causality data is displayed as follows:

Visualization of the branch between the CGO and the actor process of the alert/event.

Display up to nine additional process branches that reveal alerts related to the alert/event. Branches containing alerts with the nearest timestamp to the
original alert/event are displayed first.

Causality cards that contain more causality data display a Showing Partial Causality flag. You can manually add additional child or parent processes
branches by right-clicking on the process nodes displayed in the graph.

The Causality View provides an interactive way to view the CI chain for an alert. You can move it, extend it, and modify it. To adjust the appearance of the CI
chain, you can enlarge/shrink the chain for easy viewing using the size controls on the right. You can also move the chain around by selecting and dragging it.
To return the chain to its original position and size, click in the lower-right of the CI graph.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 315/1003
5/8/24, 9:18 AM PDF Export

Click an alert to display its name, source, timestamp, timestamp, severity, the action taken, the tags assigned to it, and description.

When the Identity Threat Module is enabled, Cortex XSIAM displays the anomaly that triggered the alert against the backdrop of baseline behavior for some
alerts. To see the profiles that are generated by the detector, Open Alert Visualization. Each tab displays the factors that triggered the alert, the event and the
baseline information in tabular format or in timeline format, depending on the type of event. The graphs display the information in full mode, covering 30 days.

The tabular view displays the baseline behavior in a table, with the anomaly highlighted and in a separate line.

The timeline view displays the highlighted atypical value, and if applicable, the minimum, maximum, and average values, for the selected period.

The process node displays icons to indicate when an RPC protocol or code injection event was executed on another process from either a local or remote host.

Injected Node

Remote IP address

Hover over a process node to display a Process Information pop-up listing useful information about the process. If available, the pop-up includes the process
Analytics Profiles.

Path of the process.

Command line of the process.

SHA256 value of the process.

Username of the user that initiated the process.

Signature associated with the process, if available.

WildFire verdict, if available.

Running time of the process.

From any process node, you can also right-click to display additional actions that you can perform during your investigation:

Show parents and children—If the parent is not presented by default, you can display it. If the process has children, Cortex XSIAM opens a dialog
displaying the Children Process Start Time, Name, CMD, and Username details.

Hide branch—Hide a branch from the Causality View.

Add to block list or allow list, terminate, or quarantine a process—If after investigating the activity in the CI chain, you want to take action on the
process, you can select the desired action to allow or block the process across your organization.

In the causality view of a Detection (Post Detected) type alert, you can also Terminate process by hash.

Depending on the type of node—file, process, or IP address—open the artifact view:

Open Hash View to display detailed information about the files and processes relating to the hash.

Open IP View to display detailed information about the IP address.

Initiate a remediation analysis.

Entity Data

Provides additional information about the entity that you selected. The data varies by the type of entity but typically identifies information about the entity related
to the cause of the alert and the circumstances under which the alert occurred.

For example, device type, device information, and remote IP address.

When you investigate command-line arguments, click {***} to obfuscate or decode the base64-encoded string.

For continued investigation, you can copy the entire entity data summary to the clipboard.

Response Actions

You can choose to isolate the host, on which the alert was triggered, from the network or initiate a live terminal session to the host to continue investigation and
remediation.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 316/1003
5/8/24, 9:18 AM PDF Export

Events Table

The Events table displays up to 100,000 related events for the process node which matches the alert criteria that were not triggered in the alert table but are
informational. The Prevention Actions tab displays the actions Cortex XSIAM takes on the endpoint based on the threat type discovered by the agent.

To continue the investigation, you can perform the following actions from the right-click pivot menu:

View in XQL to populate the event in an XQL search query that you can further refine if needed.

Add <path type> to malware profile allow list from the Process and File table <path> fields. For example, target_process_path, src_process_path,
file_path, or os_parent_path.

For the behavioral threat protection results, you can take action on the initiator to add it to an allow list or block list, terminate it, or quarantine it.

Revise the event results to see possible related events near the time of an event using an updated timestamp value to Show rows 30 days prior or 30
days after.

TIP:

To view statistics for files on VirusTotal, you can pivot from the Initiator MD5 or SHA256 value of the file on the Files tab.

4.5.7 | Network Causality View

Abstract

The Causality View shows a chain of individual network processes that together and in a particular sequence of operation triggered an alert.

The Network Causality View provides a powerful way to analyze and respond to the stitched firewall and endpoint alerts. The scope of the Causality View is the
Causality Instance (CI) to which this alert pertains. The Causality View presents the network processes that triggered the alert, generated by Cortex XSIAM,
Palo Alto Networks next-generation firewalls, and supported alert source such as the Cortex XDR agent.

The network causality view includes the entire process execution chain that led up to the alert. On each node in the CI chain, Cortex XSIAM provides
information to help you understand what happened around the alert.

The CI chain visualizes the firewall logs, endpoint files, and network connections that triggered alerts connected to a security event.

NOTE:

The network causality view displays only the information it collects from the detectors. It is possible that the CI may not show some of the firewall or agent
processes.

The Network Causality View comprises five sections:

Section Description

Context Summarizes information about the alert you are analyzing, including the host name,
the process name on which the alert was raised, and the host IP address. For alerts
raised on endpoint data or activity, this section also displays the endpoint connectivity
status and operating system.

Host Isolation You can choose to isolate the host, on which the alert was triggered, from the network
or initiate a live terminal session to the host to continue investigation and remediation.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 317/1003
5/8/24, 9:18 AM PDF Export

Section Description

CI Chain Includes the graphical representation of the Causality Instance (CI) along with other
information and capabilities to enable you to conduct your analysis.

The Causality View presents a CI chain for each of the processes and the network
connection. The CI chain is built from process nodes, events, and alerts. The chain
presents the process execution and might also include events that these processes
caused and alerts that were triggered by the events or processes. The Causality
Group Owner (CGO) is displayed on the left side of the chain. The CGO is the
process that is responsible for all the other processes, events, and alerts in the chain.
You need the entire CI to fully understand why the alert occurred.

The Causality View provides an interactive way to view the CI chain for an alert. You
can move it, extend it, and modify it. To adjust the appearance of the CI chain, you
can enlarge/shrink the chain for easy viewing using the size controls on the right. You
can also move the chain around by selecting and dragging it. To return the chain to its
original position and size, click in the lower-right of the CI graph.

From any process node, you can also right-click to display additional actions that you
can perform during your investigation:

Show parents and children—If the parent is not presented by default, you can
display it. If the process has children, Cortex XSIAM displays the number of
children beneath the process name and allows you to display them for
additional information.

Hide branch—Hide a branch from the Causality View.

Add to block list or allow list, terminate, or quarantine a process—If after

investigating the activity in the CI chain, you want to take action on the process,
you can select the desired action on the process across your organization.

In the causality view of a Detection (Post Detected) type alert, you can also
Terminate process by hash.

When selecting the Network Appliance node in the Network Causality View, the event
timestamp is now displayed in the Entity Data section of the card.

The color of a process node also correlates to the WildFire verdict.

Blue—Benign.

Yellow—Grayware.

Red—Malware.

Light gray—Unknown verdict.

Dark gray—The verdict is inconclusive.

To view and download the WildFire report, in the Entity Data section, click .

Entity Data Provides additional information about the entity that you selected. The data varies by
the type of entity but typically identifies information about the entity related to the
cause of the alert and the circumstances under which the alert occurred.

Events Table Displays all related events for the process node which match the alert criteria that
were not triggered in the alert table but are informational. You can also export the
table results to a tab-separated values (TSV) file.

For the Behavioral Threat Protection table, right-click to add to allow list or block list,
terminate, and quarantine a process.

TIP:

To view statistics for files on VirusTotal, you can pivot from the Initiator MD5 or
SHA256 value of the file on the Files tab.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 318/1003
5/8/24, 9:18 AM PDF Export

4.5.8 | Cloud Causality View

Abstract

See the causality of a cloud-type alert—the entire process execution chain that led up to the alert in the Cortex XSIAM app.

The Cloud Causality View provides a powerful way to analyze and respond to Cortex XSIAM alerts and Cloud Audit Logs. The scope of the Cloud Causality
View is the Causality Instance (CI) of an event to which this alert pertains. The Cloud Causality View presents the event identity and /or IP address and the
actions performed by the identity on the cloud resource. On each node in the CI chain, Cortex XSIAM provides information to help you understand what
happened around the event.

The Causality View comprises the following sections:

Context

Summarizes information about the alert you are analyzing, including the type of Cloud Provider, Project, and Region on which the event occurred. Select View
Raw Log to view the raw log as provided by the Cloud Provider in JSON format.

Causality Instance Chain

Includes the graphical representation of the Causality Instance (CI) along with other information and capabilities to enable you to conduct your analysis.

The Causality View presents a single event CI chain. The CI chain is built from Identity and Resource nodes. The Identity node represents for example keys,
service accounts, and users, while the Resource node represents for example network interfaces, storage buckets, or disks. When available, the chain might
also include an IP address and alerts that were triggered on the Identity and Cloud Resource.

Causality data is displayed as follows:

The Causality View provides an interactive way to view the CI chain for an alert. You can move it, extend it, and modify it. To adjust the appearance of the CI
chain, you can enlarge/shrink the chain for easy viewing using the size controls on the right. You can also move the chain around by selecting and dragging it.
To return the chain to its original position and size, click in the lower-right of the CI graph.

Identity Node

Displays the name of the identity, generated alert information, and if available the associated IP address.

To further investigate the user:

1. Hover over an Identity node to display, if available, the identity Analytics Profiles.

2. Select the Identity node to display in the Entity Data section additional information about the Identity entity.

3. Select the Alert icon to display in the Entity Data section additional information about the alert.

IP Address Node

Displays the IP address associated with the Identity.

Operations

Lists the type of operations performed by the identity on the cloud resources. Hover over the operation to display the original operation name as provided by the
Cloud Provider.

Cloud Resource Node

Displays the referenced resource on which the operation was performed. Cortex XSIAM displays information on the following resources:

Icon Type Of Resource

Compute Instance Resource

Disk Resource

General Resource

Image Resource

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 319/1003
5/8/24, 9:18 AM PDF Export

Icon Type Of Resource

Network Interface Resource

Security Group (FW Rule) Resource

Storage Bucket Resource

Virtual Private Cloud (VPC) Resource

To further investigate the resource:

1. Hover over a Resource node to display, if available, the resource Analytics Profiles and Resource Editors statistics.

2. Select the Resource node to display in the Entity Data section additional information about the Resource entity.

Entity Data

Provides additional information about the entity that you selected. The data varies by the type of entity but typically identifies information about the entity related
to the cause of the alert and the circumstances under which the alert occurred.

Events Table

Displays up to 100,000 related events and up to 1,000 related alerts.

To continue the investigation, in the Alerts table, you can perform the following actions from the right-click pivot menu:

Investigate Causality Chain of the associated alert.

Open in XQL to populate the event in an XQL search query that you can further refine if needed.

Manage Alert to perform available actions.

Pivot to views to view the related incidents.

In the All Events table, Cortex XSIAM displays detailed information about each of the related events. To simplify your investigation, Cortex XSIAM scans your
Cortex XSIAM data aggregating the events that have the same Identity or Resource and displays the entry with an aggregated icon. Right-click and select
Show Grouped Events to view the aggregated entries.

Entries highlighted in red indicate that the specific event triggered an alert. To continue the investigation, right-click to View in XQL.

4.5.9 | SaaS Causality View

Abstract

Learn more about the SaaS Causality View used to identify and investigate SaaS-specific data associated with SaaS-related alerts and SaaS Audit Logs.

The SaaS Causality View provides a powerful way to analyze and investigate software-as-a-service (SaaS) related alerts for audit stories, such as Office 365
audit logs and normalized logs, by highlighting the most relevant events and alerts associated with a SaaS-related alert. To help you identify and investigate
SaaS-specific data associated with SaaS-related alerts and SaaS Audit Logs, Cortex XSIAM displays a SaaS Causality View, which enables you to swiftly
investigate a SaaS alert by displaying the series of events and artifacts that are shared with the alert.

A SaaS Causality View is only available when Cortex XSIAM is configured to collect SaaS Audit Logs and data. For example, this is possible by configuring an
Office 365 data collector or Google Workspace data collector with the applicable SaaS Audit logs. This enables you to investigate any Cortex XSIAM alerts
generated from any IOC, BIOC, or Correlation Rules, including SaaS events. The SaaS Causality View is available from either the Alerts table or from the Query
Results after running a query on the SaaS related data in XQL Search. From both of these places, you can pivot (right-click) to the SaaS Causality View from
any row in the table and selecting Investigate Causality Chain → Open Card in new tab or Investigate Causality Chain → Open Card in same tab.

The scope of the SaaS Causality View is the Causality Instance (CI) of an event to which this alert pertains. The SaaS Causality View presents the event identity
and /or IP address and the actions performed by the identity on the SaaS resource. On each node in the CI chain, Cortex XSIAM provides information to help
you understand what happened around the event.

The SaaS Causality View contains the following sections:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 320/1003
5/8/24, 9:18 AM PDF Export

Context

Summarizes information about the alert you are analyzing, including the type of SaaS Provider, Project, and Region on which the event occurred. Select View
Raw Log to view the raw log as provided by the SaaS Provider in JSON format.

SaaS Causality Instance Chain

Includes the graphical representation of the SaaS Causality Instance (CI) along with other information and capabilities to enable you to conduct your analysis.

The SaaS Causality View presents a single event CI chain. The CI chain is built from Identity and Resource nodes. The Identity node represents for example
keys, service accounts, and users, while the Resource node represents for example network interfaces, storage buckets, or disks. When available, the chain
can also include an IP address and alerts that were triggered on the Identity and SaaS Resource.

The SaaS Causality View provides an interactive way to view the CI chain for an alert. You can move it, extend it, and modify it. To adjust the appearance of the
CI chain, you can enlarge/shrink the chain for easy viewing using the size controls on the right. You can also move the chain around by selecting and dragging
it. To return the chain to its original position and size, click in the lower-right of the CI graph.

Identity Node: Displays the name of the identity, generated alert information, and if available the associated IP address.

To further investigate the user:

1. Hover over an Identity node to display, if available, the identity Analytics Profiles.

2. Select the Identity node to display in the Entity Data section additional information about the Identity entity.

3. Select the Alert icon to display in the Entity Data section additional information about the alert.

IP Address Node: Displays the IP address associated with the Identity.

Resource Node: Displays the referenced resource on which the operation was performed. Cortex XSIAM displays information on the following resources.

Icon Type Of Resource

Google Workspace Admin Console

Google Workspace for Google Drive

Microsoft Office 365 Exchange Online

Microsoft 365 Office Groups

Microsoft Office 365 OneDrive

Microsoft Office 365 SharePoint Online

Microsoft Office 365 Skype for Business

Microsoft Office 365 Teams

To further investigate the resource:

1. Hover over a Resource node to display, if available, the resource Analytics Profiles and Resource Editors statistics.

2. Select the Resource node to display in the Entity Data section additional information about the Resource entity.

Entity Data

Provides additional information about the entity that you selected. The data varies by the type of entity but typically identifies information about the entity related
to the cause of the alert and the circumstances under which the alert occurred.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 321/1003
5/8/24, 9:18 AM PDF Export

Alerts and All Events Table Tabs

The All Events table displays up to 100,000 related events, while the Alerts table, if available, displays up to 1,000 related alerts.

To continue the investigation, in the Alerts table, you can perform the following actions from the right-click pivot menu:

Change Status of the associated alert.

Change Severity of the associated alert.

Investigate Causality Chain of the associated alert.

Open in XQL to populate the event in an XQL search query that you can further refine if needed.

Manage Alert to perform available actions.

Pivot to views to view the related incidents.

In the All Events table, Cortex XSIAM displays detailed information about each of the related events. To simplify your investigation, Cortex XSIAM scans your
Cortex XSIAM data aggregating the events that have the same Identity or Resource and displays the entry with an aggregated icon. Right-click and select
Show Grouped Events to view the aggregated entries.

Entries highlighted in red indicate that the specific event triggered an alert. To continue the investigation, right-click to View in XQL.

4.5.10 | Analytics Alert View

Abstract

From the Cortex XSIAM management console, you can view a detailed summary of the behavior that triggered analytics alerts.

The >analytics alert view provides a detailed summary of the behavior that triggered an Analytics or Analytics BIOC alert. This view also provides a visual
depiction of the behavior and additional information you can use to assess the alert. This includes the endpoint on which the activity was initiated, the user that
performed the action, the technique the analytics engine observed, and activity and interactions with other hosts inside or outside of your network.

When enabling Identity Analytics , alerts associated with suspicious user activity such as stolen or misused credentials, lateral movement, credential harvesting,
or brute-force data are displayed with a User node.

Section Description

1. Context For Analytics alerts, the analytics view indicates the endpoint for which the alert was raised.

For Analytics BIOC alerts, the Analytics view summarizes information about the alert, including the source host
name, IP address, the process name on which the alert was raised, and the corresponding process ID.

2. Alert summary (Analytics alerts only) Describes the behavior that triggered the alert and activity impact.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 322/1003
5/8/24, 9:18 AM PDF Export

Section Description

3. Graphic summary Similar to the Causality View, the analytics view provides a graphic representation of the activity that triggered the
alert and an interactive way to view the chain of behavior for an Analytics alert. You can move the graphic, extend it,
and modify it. To adjust the appearance, you can enlarge/shrink the chain for easy viewing using the size controls on
the right. You can also move the chain around by selecting and dragging it. To return the chain to its original position
and size, click in the lower-right of the graph.

The activity depicted in the graphic varies depending on the type of alert:

Analytics alerts—You can view a summary of the aggregated activity including the source host, the anomalous
activity, connection count, and the destination host. You can also select the host to view any relevant profile
information.

Analytics BIOC alerts—You can view the specific event behavior including the causality group owner that
initiated the activity and related process nodes. To view the summary of the specific event, you can select the
above the process node.

The following nodes display information unique to the Analytics Alert View:

User node— Hover over to display the User Information and user Analytics Profile data.

Multi-Event—Display in the Event Table all the event types associated with the alert.

Right-click on the following nodes to view additional information:

Device—Open in IP View

Process—View Process Instances

IP Address—Add to EDL

4. Alert description The alert description provides details and statistics related to the activity. Beneath the description, you can also view
the alert name, severity assigned to the alert, time of the activity, alert tactic (category) and type, and links to the
MITRE summary of the attack tactic.

When selecting a User node, Identity User Details, such as Active Directory Group, Organizational Unit, and Role
associated with the user are displayed. If available, Login Details also appear.

5. Events table Displays events related to the alert.

User node—Displays the logins, hosts, alerts, and process executions associated with the user aggregated by the
Identity Analytics 7 days prior to and after the analytics alert timestamp. Right-click to Investigate Causality Chain
and View in XQL the associated events.

Multi-Event—Displays the events associated with the alert according to the type of event type. Right-click to View in
XQL and further Investigate with XQL the event details.

6. Response actions Actions you can take in response to an Analytics alert. These actions can include isolating a host from the network,
initiating a live terminal session, and adding an IP address or domain name to an external dynamic list (EDL) that is
enforceable in your Palo Alto Networks firewall security policy.

4.5.11 | Timeline View

Abstract

From the Cortex XSIAM tenant you can view the sequence (or timeline) of events and alerts that are involved in any particular threat.

The Timeline provides a forensic timeline of the sequence of events, alerts, and informational BIOCs and Correlation Rules involved in an attack. While the
Causality View of an alert surfaces related events and processes that Cortex XSIAM identifies as important or interesting, the Timeline displays all related
events, alerts, and informational BIOCs and Correlation Rules over time.

NOTE:

The Timeline View is not available when investigating cloud Cortex XSIAM alerts and Cloud Audit Logs or SaaS-related alerts for 501 audit events, such as
Office 365 audit logs and normalized logs. Only the applicable Cloud Causality View and SaaS Causality View is available for this data.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 323/1003
5/8/24, 9:18 AM PDF Export

Cortex XSIAM presents the Timeline in four parts:

Section Description

CGO (and process instances that are part of Cortex XSIAM displays the Causality Group Owner (CGO) and the host on which the CGO ran in the top left
the CGO) of the timeline. The CGO is the parent process in the execution chain that Cortex XSIAM identified as being
responsible for initiating the process tree. In the example above, wscript.exe is the CGO and the host it
ran on was HOST488497. You can also click the blue corner of the CGO to view and filter related processes
from the Timeline. This will add or remove the process and related events or alerts associated with the
process from the Timeline.

Timespan By default, Cortex XSIAM displays a 24-hour period from the start of the investigation and displays the start
and end time of the CGO at either end of the timescale. You can move the slide bar to the left or right to
focus on any time-gap within the timescale. You can also use the time filters above the table to focus on set
time periods.

Activity Depending on the type of activities involved in the CI chain of events, the activity section can present any of
the following three lanes across the page:

Alerts—The alert icon indicates when the alert occurred.

BIOCs and Correlation Rules—The category of the alert is displayed on the left (for example
tampering or lateral movement). Each BIOC event also indicates a color associated with the alert
severity. An informational severity can indicate something interesting has happened but there were not
any triggered alerts. These events are likely benign but are byproducts of the actual issue.

Event Information—The event types include process execution, outgoing or incoming connections,
failed connections, data upload, and data download. Process execution and connections are indicated
by a dot. One dot indicates one connection while many dots indicates multiple connections. Uploads
and Downloads are indicated by a bar graph that shows the size of the upload and download.

The lanes depict when the activity occurred and provide additional statistics that can help you investigate.
For BIOC, Correlation Rules, and Alerts, the lanes also depict activity nodes, highlighted with their severity
color: high (red), medium (yellow), low (blue), or informational (gray), and provide additional information
about the activity when you hover over the node.

Related events, alerts, and informational Cortex XSIAM displays up to 100,000 alerts, BIOCs and Correlation Rules (triggered and informational), and
BIOCs events. Click on a node in the activity area of the Timeline to filter the results you see here. Similar to other
pages in Cortex XSIAM , you can create filters to search for specific events.

4.6 | Investigate Endpoints

Abstract

Cortex XSIAM provides you with a wide range of options to investigate incidents on endpoints.

NOTE:

Endpoint investigation requires either a Cortex XDR Prevent or a Cortex XDR Pro per Endpoint license.

Action Center

Endpoints Table

Investigate a Host

Retrieve Files from an Endpoint

Retrieve Support Logs from an Endpoint

Scan an Endpoint for Malware

4.6.1 | Action Center

Abstract

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 324/1003
5/8/24, 9:18 AM PDF Export

From the Cortex XSIAM Action Center, you can track the progress of all investigation, response, and maintenance actions performed on your endpoints.

The Action Center provides a central location from which you can track the progress of all investigation, response, and maintenance actions performed on your
Cortex XSIAM -protected endpoints. The main All Actions tab of the Action Center displays the most recent actions initiated in your deployment. To narrow down
the results, click Filter on the top right.

You can also jump to filtered Action Center views for the following actions:

Quarantine—View details about quarantined files on your endpoints. You can also switch to an Aggregated by SHA256 view that collapses results per file
and lists the affected endpoints in the Scope field.

Block List/Allow List—View files that are permitted and blocked from running on your endpoints regardless of file verdict.

NOTE:

Blocking files on endpoints is enforced by the endpoint malware profile. To block a hash value, ensure the hash value is configured in the Malware
Security Profile.

Select Override Report mode to allow the agent to block hashes even if the Malware Profile is set to Report.

Scripts Library—View Palo Alto Networks and administrator-uploaded scripts that you can run on your endpoints.

Isolation—View the endpoints in your organization that have been isolated from the network. For more information, refer to Isolate an Endpoint.

Endpoint Blocked IP Addresses—View remote IP addresses that the Cortex XDR agent has automatically blocked from communicating with endpoints in
your network. For more information, refer to Add a New Malware Security Profile.

For actions that can take a while to complete, the Action Center tracks the action progress and displays the action status and current progress description for
each stage. For example, after initiating an agent upgrade action, Cortex XSIAM monitors all stages from the Pending request until the action status is
Completed. Throughout the action lifetime, you can view the number of endpoints on which the action was successful and the number of endpoints on which the
action failed. After a period of 90 days since the action creation, the action is removed from Cortex XSIAM and is no longer displayed in the Action Center. You
cannot delete actions manually from the Action Center.

The following table describes both the default and additional optional fields that you can view from the All Actions tab of the Action Center and lists the fields in
alphabetical order.

Field Description

Action Type Type of action initiated on the endpoint (for example Agent Upgrade).

Agent Restart Restart an agent on <endpoint name>.

Statuses:

In progress—Action initiated, but no start indication from agent after stop.

Failed—Agent reports failed back to the Cortex XSIAM server if it was

started after more than 10 minutes after restart initiation.

Expired—After 4 days.

Success—Agent reports success to the Cortex XSIAM server if it was

started within 10 minutes after restart initiation.

Created By The name of the user who initiated the action.

Creation Timestamp Date and time the action was created.

Description Includes the action scope of affected endpoints and additional data relevant to
each of the specific actions, such as agent version, file path, and file hash.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 325/1003
5/8/24, 9:18 AM PDF Export

Field Description

Expiration Date Time the action will expire. To set an expiration the action must apply to one or
more endpoints.

By default, Cortex XSIAM assigns a 7-day expiration limit to the following

actions:

Agent Uninstall

Agent Upgrade

Files Retrieval

Isolate

Cancel Endpoint Isolation

Additional actions such as malware scans, quarantine, and endpoint data

retrieval are assigned a 4-day expiration limit.

After the expiration limit, the status for any remaining Pending actions on
endpoints change to Expired and these endpoints will not perform the action.

Status The status of the action is currently at:

Pending—No endpoint has started to perform the action yet.

In Progress—At least one endpoint has started to perform the action.

Canceled—The action was canceled before any endpoint started

performing it.

Pending Abort—No endpoint has started to perform the action yet.

Aborted—The action was canceled for all endpoints after at least one
endpoint has started performing it.

Expired—The action expired before any endpoint has started performing

it.

Completed with Partial Success—The action was completed on all

endpoints. However, some endpoints did not complete it successfully.
Depending on the action type, it may have failed, been canceled,
expired, or failed to retrieve all data.

Completed Successfully—The action was completed successfully on all

endpoints.

Failed—The action failed on all endpoints.

Timeout—The action timed-out on all endpoints.

Additional data—If additional details are available for an action or for specific endpoints, you can pivot (right-click) to the Additional data view. You can also
export the additional data to a TSV file. The page can include details in the following fields but varies depending on the type of action.

Endpoint Name Target host name of each endpoint for which an action was initiated.

IP Addresses IP address associated with the endpoint.

Status Status of the action for the specific endpoint. (Linux)—Completed with Partial
Success for a single endpoint that did not complete the action successfully.

Action Last Update Time at which the last status update occurred for the action.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 326/1003
5/8/24, 9:18 AM PDF Export

Field Description

Advanced Analysis For Retrieve alert data requests related to Cortex XSIAM Alerts raised by
exploit protection modules, Cortex XSIAM can analyze the memory state for
additional verdict verification. This field displays the analysis progress and
resulting verdict.

Action Parameters Summary of the Action including the alert name and alert ID.

Additional Data | Malicious Files Additional data, if any is available, for the action. For malware scans, this field
is titled Malicious Files and indicates the number of malicious files identified
during the scan.

4.6.1.1 | Manage Endpoint Actions

Abstract

Use the Action Center to initiate or monitor actions on your endpoints in Cortex XSIAM.

There are two ways to initiate an endpoint action: you can either initiate an endpoint action from the Action Center or initiate an action when you view details
about an endpoint. Then, to monitor the progress and status of an endpoint action, you can monitor the actions from the Action Center.

Initiate an Endpoint Action

You can create new administrative actions using the Action Center wizard in three easy steps:

Select the action type and configure its parameters.

Define the target agents for this action.

Review and confirm the action summary.

1. Go to Incident Response → Response → Action Center → +New Action.

2. Select the action you want to initiate and follow the required steps and parameters you need to define for each action.

Cortex XSIAM displays only the endpoints eligible for the action you want to perform.

3. Review the action summary.

Cortex XSIAM will inform you if any of the agents in your action scope will be skipped. Click Done.

4. Track your action.

Track the new action in the Action Center. The action status is updated according to the action progress, as listed in the table above.

Monitor Endpoint Actions

1. Go to Incident Response → Response → Action Center.

2. Select the relevant view.

Use the left-side menu on the Action Center page to monitor the different actions according to their type:

All—Lists all the administrative actions created in your network, including time of creation, action type and description, action status, the name of
the user who initiated the action, and the action expiration date, if it exists.

Quarantine—Lists only actions initiated to quarantine files on endpoints, including the file hash, file name, file path, and scope of target agents
included in this action.

Block List/Allow List—Lists only actions initiated to block or allow files, including file hash, status, and any existing comments.

3. Filter the results.

To further narrow the results, use the Filters menu at the top of the page.

4. Take further actions.

After inspecting an action log, you may want to take further action. Right-click the action and select one of the following (where applicable):

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 327/1003
5/8/24, 9:18 AM PDF Export

View additional data—Display more relevant details for the action, such as file paths for quarantined files or operating systems for agent upgrades.

For actions with Status, Failed or Completed with partial success, you can create an upgrade action to rerun the action on endpoints that have not
been completed successfully. From the Actions table, select the failed/partial success endpoints, right-click and select create upgrade action. A new
upgrade action is added to the All Actions table for tracking.

Archive—Archive the action for future reference. You can select multiple actions to archive at the same time.

Cancel for Pending endpoints—Cancel the original action for agents that are still in Pending status.

Download output—Download a zip file with the files received from the endpoint for actions such as file and data retrieval.

Rerun—Launch the Define an Action wizard populated with the same details as the original action.

Run on additional agents—Launch the action wizard populated with the details as the original action except for the agents which you have to fill
in.

Restore—Restore quarantined files.

4.6.2 | Endpoints Table

Abstract

You can view details and an overview of all your endpoints.

The Endpoints → All Endpoints page provides a central location from which you can view and manage the endpoints on which the agent is installed.

To ensure the All Endpoints table is displaying the most useful list of endpoints, you can perform a one-time or periodic cleanup of duplicated entities of the
same endpoint from the table. After the cleanup, duplicated entities are removed leaving only one endpoint entry - the last endpoint to connect with the server.
Deleted endpoint data is retained for 90 days from the last connection timestamp. If a deleted endpoint reconnects, Cortex XDR recovers and redisplays the
endpoint’s existing data.

Navigate to Settings → Configurations → General → Agent Configurations → Endpoint Administration Cleanup. Enable the Periodic duplicate cleanup and
select to either run one-time cleanup or define to run according to the Host Name, Host IP Address, and/or MAC Address fields every 6 hours, 12 hours, 1 day,
or 7 days.

To investigate a single endpoint, right click it, select Endpoint Data , and open the Asset view.

Manage Endpoints

The right-click pivot menu that is available for each endpoint displays the actions you can perform. The following table describes the list of actions you can
perform on your endpoints.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 328/1003
5/8/24, 9:18 AM PDF Export

Field Action

Endpoint Control Open in interactive mode

Perform Heartbeat

Change Endpoint Alias

Upgrade Agent Version

WARNING:

You cannot upgrade VDI endpoints.

Retrieve Support File

Collect Detailed Host Firewall Logs

Triage Endpoint

Set Endpoint Proxy

Uninstall Agent

Delete Endpoint

Disable Capabilities (Live Terminal, Script Execution, and File Retrieval)

Include / Exclude endpoints from auto upgrade

Clear the Agent database

Available only when using debugging mode (Alt+Right-Click)

Assign and Remove endpoint tags

Send Push Notification (iOS App)

Manage Agent Tokens

Security Operations Retrieve Endpoint Files

Initiate Malware Scan

Abort Malware Scan

Initiate Live Terminal

Isolate Endpoint

Endpoint Data Open Asset View

View Incidents (in same tab or new tab)

View Endpoint Policy

View Actions

View Endpoint Logs

View Endpoint Data

The following table describes both the default and additional optional fields that you can view in the All Endpoints table and lists. Clicking on a row in the All
Endpoints table opens a detailed view of the endpoint.

Read more...

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 329/1003
5/8/24, 9:18 AM PDF Export

Field Description

Check box to select one or more endpoints on which to perform actions.

Active Directory Lists all Active Directory Groups and Organizational Units to which the user belongs.

Assigned Extensions Policy Policy related to extensions and devices connected to the endpoint.

Assigned Prevention Policy Policy assigned to the endpoint.

Agent Version Shows the agent version that is installed on the endpoint.

Auto Upgrade Status When Agent Auto Upgrades are enabled, indicates the action status is either:

In progress—Indicates that the agent upgrade is in progress on the endpoint.

Up to date—Indicates that the current agent version on the endpoint is up to date.

Failure—Indicates that the agent upgrade failed after three retries.

Not configured—Indicates that automatic agent upgrades are not configured for this endpoint.

Pending—Indicates that the agent version running on the endpoint is not up to date, and the agent is waiting
for the upgrade message from Cortex XSIAM.

Not supported—Indicates this endpoint type does not support automatic agent upgrades. Relevant for VDI,
TS, or Android endpoints.

To include or exclude one or more endpoints from auto upgrade, right-click and select Endpoint Control →
include/exlude endpoints from auto upgrade

NOTE:

After an endpoint is excluded, the Auto upgrade profile configuration will no longer be available.

If you exclude the endpoint from Auto Upgrade while the Auto Upgrade Status is In progress status, the ongoing
upgrade will still take place.

Cloud Info Displays IBM and Alibaba Cloud metadata reported by the endpoint.

Content Auto Update Indicates whether automatic content updates are Enabled or Disabled for the endpoint. See Agent Settings profile.

Content Release Timestamp Displays the time and date of when the current content version was released.

Content Rollout Delay (days) If you configured delayed content rollout, the number of days for delay is displayed here. See Agent Settings profile.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 330/1003
5/8/24, 9:18 AM PDF Export

Field Description

Content Status Displays the status of the content version on the relevant endpoint. The Cortex XSIAM tenant attempts to contact an
endpoint and check the content version over a 7 day period. After this period the tenant displays one of the following
statuses:

Up to Date - The endpoint is running with the latest content version

Waiting for Update - Cortex XSIAM is in the process of updating the new content version. Depending on your
bandwidth and network connection, updating the content version may take time.

Outdated - The endpoint is running on an outdated content version.

Offline - The endpoint is disconnected.

NOTE:

Content Status is calculated every 30 minutes, therefore, there could be a delay of up to 30 minutes in displaying
the data.

Content Version Content update version used with the agent.

Disabled Capabilities A list of the capabilities that were disabled on the endpoint. To disable one or more capabilities, right-click the
endpoint name and select Endpoint Control → Disable Capabilities. Options are:

Live Terminal

Script Execution

File Retrieval

You can disable these capabilities during the agent installation on the endpoint or through Endpoint Administration.
Disabling any of these actions is irreversible, so if you later want to enable the action on the endpoint, you must
uninstall the agent and install a new package on the endpoint.

Domain Domain or workgroup to which the endpoint belongs, if applicable.

NOTE:

Only supported for Windows and macOS.

Endpoint Alias If you assigned an alias to represent the endpoint in Cortex XSIAM, the alias is displayed here. To set an endpoint
alias, right-click in the endpoint row, select Endpoint Control → Change endpoint alias. The alias can contain any of
the following characters:

a-Z, 0-9, !@#$%^&:()-'{}~_.

Endpoint ID Unique ID assigned by Cortex XSIAM that identifies the endpoint.

Endpoint Isolated Isolation status, either:

Isolated—The endpoint has been isolated from the network with communication permitted to only Cortex
XSIAM and to any IP addresses and processes included in the allow list.

Not Isolated—Normal network communication is permitted on the endpoint.

Pending Isolation—The isolation action has reached the server and is pending contact with the endpoint.

Pending Isolation Cancellation—The cancel isolation action has reached the server and is pending contact
with the endpoint.

Endpoint Name Hostname of the endpoint. If the agent enables Pro features, this field also includes a PRO badge. For Android
endpoints, the hostname comprises the <firstname>—<lastname> of the registered user, with a separating dash.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 331/1003
5/8/24, 9:18 AM PDF Export

Field Description

Endpoint Status Registration status of the agent on the endpoint:

Connected—The agent has checked in within 10 minutes for standard endpoints, and within 3 hours for
mobile endpoints.

Connection Lost—The agent has not checked in within 30 to 180 days for standard endpoints, and between
90 minutes and 6 hours for VDI and temporary sessions.

Disconnected—The agent has not checked in within the defined inactivity window: between 10 minutes and
30 days for standard and mobile endpoints, and between 10 minutes and 90 minutes for VDI and temporary
sessions.

VDI Pending Log-on—(Windows only) Indicates a non-persistent VDI endpoint is waiting for user logon, after
which the agent consumes a license and starts enforcing protection.

Uninstalled—The agent has been uninstalled from the endpoint.

Endpoint Type Type of endpoint: Mobile, Server, or Workstation.

Endpoint Version Versions of the agent that runs on the endpoint.

First Seen Date and time the agent first checked in (registered) with Cortex XSIAM.

Golden Image ID For endpoints with a System Type of Golden Image, the image ID is a unique identifier for the golden image.

Group Names Endpoint Groups to which the endpoint is a member, if applicable. See Define Endpoint Groups.

Incompatibility Mode Agent incompatibility status, either:

Agent Incompatible—The agent is incompatible with the environment and cannot recover.

OS Incompatible—The agent is incompatible with the operating system.

When agents are compatible with the operating system and environment, this field is blank.

Isolation Date Date and time of when the endpoint was Isolated. Displayed only for endpoints in Isolated or Pending Isolation
Cancellation status.

Install Date Date and time at which the agent was first installed on the endpoint.

Installation Package Installation package name used to install the agent.

Installation Type Type of installation:

Standard

VDI

Golden Image

Temporary Session

IP Address Last known IPv4 address of the endpoint.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 332/1003
5/8/24, 9:18 AM PDF Export

Field Description

IPv6 Address Last known IPv6 address of the endpoint.

Is EDR Enabled Whether EDR data is enabled on the endpoint.

IT Metric Collection Indicates whether the endpoint is collecting IT performance data.

Last Certificate Enforcement For Windows and MacOS Endpoints. If Certificate Enforcement is Enabled, this column shows the date and time of
Fallback use of a fallback certificate from the local store. If no fallback is used, this will remain empty.

Last Content Update Time Displays the time and date when the agent last deployed a content update.

Last Origin IP Represents the last IPv4 address from which the XDR agent connected.

Last Origin IPv6 Represents the last IPv6 address from which the XDR agent connected.

Last Scan Date and time of the last malware scan on endpoint.

Last Seen Date and time of the last change in an agent's status. This can occur when Cortex XSIAM receives a periodic status
report from the agent (once an hour), a user performed a manual Check In, or a security event occurred.

NOTE:

Changes to the agent status can take up to ten minutes to display on Cortex XSIAM .

Last Used Proxy The IP address and port number of proxy that was last used for communication between the agent and Cortex
XSIAM.

Last Used Proxy Port Last proxy port used on endpoint.

Linux Operation Mode (Agent v7.7 and later for Linux) Displays the type of operation mode your Linux endpoint is running by the agent.
The operation modes available are; Kernel, User Space, or Kernel Disabled.

Last Upgrade Failure Reason Shows the reason an upgrade failed.

Last Upgrade Source Shows the source of the upgrade installaton file.

Last Upgrade Status Shows the status of the last upgrade.

Last Upgrade Status Time Shows the date and time of the last upgrade.

MAC Address The endpoint MAC address that corresponds to the IP address. Currently, this information is available only for IPv4
addresses.

Mobile ID Unique identifier of the agent located on an Android or iOS mobile.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 333/1003
5/8/24, 9:18 AM PDF Export

Field Description

Network Interface The relationship between the MAC address and the IP address for agents that can report the network interfaces
information. Information is displayed in JSON format, and searches can be performed on attributes in JSON.

Network Location Agent v7.1 and later for Windows and agent v7.2 and later for macOS and Linux) Endpoint location is reported by
the agent when you enable this capability in the Agent Settings profile:

Internal

External

Not Supported—The agent is running a prior agent version that does not support network location reporting.

Disabled—The Cortex XDR agent was unable to identify the network location.

Operating System Name of the operating system.

Operational Status XDR agent operational status:

Protected—Indicates that the agent is running as configured and did not report any exceptions to Cortex
XSIAM.

Partially protected—Indicates that the agent reported to Cortex XSIAM one or more exceptions. Clicking on
the row shows in the detailed view why an endpoint may be partially protected.

Unprotected—Indicates the Cortex XDR agent was shut down.

OS Description Operating system version name.

OS Type Name of the operating system.

OS Version Operating system version number.

Platform Platform architecture.

Proxy IP address and port number of the configured proxy server.

Scan Status Malware scan status, either:

None—No scan initiated

Pending—Scan was initiated, waiting for action to reach endpoint.

In Progress—Scan in process.

Success—Scan completed.

Pending Cancellation—Scan was aborted, waiting for action to reach endpoint.

Canceled—Scan canceled.

Error—Scan failed to run.

System Uptime—Length of time since last device reboot.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 334/1003
5/8/24, 9:18 AM PDF Export

Field Description

Managed Device Indicates whether an iOS device has a corporate profile installed on it and is to some extent controlled and managed
by the corporation.

Managed—the iOS device is controlled and managed by the corporation.

Unmanaged—the iOS device is not controlled and managed by the corporation.

Tags Displays the tags associated with the endpoint.

Tags created in the agent are displayed with a shield icon.

User User that was last logged into the endpoint. On Android endpoints, the Cortex XSIAM tenant identifies the user from
the email prefix specified during app activation.

4.6.3 | Retrieve Files from an Endpoint

Abstract

If during investigation you want to retrieve files from one or more endpoints, you can initiate a files retrieval request from Cortex XSIAM.

If during an investigation you want to retrieve files from one or more endpoints, you can initiate a files retrieval request from Cortex XSIAM .

For each files retrieval request, Cortex XSIAM supports up to:

20 files

500MB in total size

10 different endpoints

The request instructs the agent to locate the files on the endpoint and upload them to Cortex XSIAM. The agent collects all requested files into one archive and
includes a log in JSON format containing additional status information. When the files are successfully uploaded, you can download them from the Action
Center.

To retrieve files from one or more endpoints:

1. Go to Incident Response → Response → Action Center → + New Action.

2. Select Files Retrieval and click Next.

3. Select the operating system and enter the paths for the files you want to retrieve, pressing ADD after each completed path.

NOTE:

You cannot define a path using environment variables on Mac and Linux endpoints.

4. Click Next.

5. Select the target endpoints (up to 10) from which you want to retrieve files.

TIP:

If needed, Filter the list of endpoints.

6. Click Next.

7. Review the action summary and click Done when finished.

To track the status of a file retrieval action, return to the Action Center. Cortex XSIAM retains retrieved files for up to 30 days.

If at any time you need to cancel the action, right-click, and select Cancel for pending endpoint. You can cancel the retrieval action only if the endpoint is
still in Pending status and no files have been retrieved from it yet. The cancellation does not affect endpoints that are already in the process of retrieving
files.

8. To view additional data and download the retrieved files, right-click the action and select Additional data.

This view displays all endpoints from which files are being retrieved, including their IP Address, Status, and Additional Data such as error messages of
names of files that were not retrieved.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 335/1003
5/8/24, 9:18 AM PDF Export

9. When the action status is Completed Successfully, right-click the action and download the retrieved files logs.

Cortex XSIAM retains retrieved files for up to 30 days.

Disable File Retrieval

If you want to prevent Cortex XSIAM from retrieving files from an endpoint running the agent, you can disable this capability during agent installation or later on
through Cortex XSIAM Endpoint Administration. Disabling script execution is irreversible. If you later want to re-enable this capability on the endpoint, you must
re-install the agent. See the XDR agent administrator’s guide for more information.

NOTE:

Disabling File Retrieval does not take effect on file retrieval actions that are in progress.

4.6.4 | Retrieve Support Logs from an Endpoint

Abstract

Retrieve support logs from an endpoint when additional forensic data is needed.

When you need to investigate or share additional forensic data, you can initiate a request to retrieve all support logs and alert data dump files from an endpoint.
After Cortex XSIAM receives the logs, you can select to either download the log files or generate a secured link to access them on the Cortex XSIAM server.

1. Retrieve support files.

You can retrieve support files either from the All Endpoints table or Action Center.

All Endpoints

a. Navigate to Endpoints → All Endpoints.

b. Locate one or more endpoints, right-click and select Endpoint Control → Retrieve Support File.

Action Center

Navigate to Incident Response → Response → Action Center → + New Action.

Select Retrieve Support File followed by Next.

Select the target endpoints (up to 10) from which you want to retrieve logs followed by Next.

Review the action summary and click Done when finished.

In the next heartbeat, the agent will retrieve the request to package and send all logs to Cortex XSIAM .

2. Navigate back to the Action Center, locate your Support File Retrieval action type and wait for the Status field to display Completed Successfully.

If at any time you need to cancel the action, you can right-click it and select Cancel for pending endpoint. You can cancel the retrieval action only if the
endpoint is still in Pending status and no files have been retrieved from it yet. The cancellation does not affect endpoints that are already in the process of
retrieving files.

3. When the status is Completed Successfully, right-click and select Additional data.

In the Actions table, you can see the endpoints from which support files were retrieved.

4. Select an endpoint, right-click and select either Download files or Generate support file link.

Cortex XSIAM retains retrieved files for up to 30 days.

The secured link is valid for only 7 days. Following the 7 day period, in order to access the files, you will need to initiate a new support file link.

4.6.5 | Scan an Endpoint for Malware

Abstract

The agent can scan your Windows and Mac endpoints and attached removable drives for dormant malware that is not actively attempting to run.

In addition to blocking the execution of malware, the Cortex agent can scan your Windows, Mac and Linux endpoints and attached removable drives for dormant
malware that is not actively attempting to run. The agent examines the files on the endpoint according to the Malware Security Profile that is in effect on the
endpoint (quarantine settings, unknown file upload, etc.) When a malicious file is detected during the scan, the agent reports the malware to Cortex XSIAM so
you can manually take additional action to remove the malware before it is triggered and attempts to harm the endpoint.

You can scan the endpoint in the following ways:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 336/1003
5/8/24, 9:18 AM PDF Export

System scan—Initiate a full scan on demand from Endpoints Administration for an endpoint. To initiate a system scan, see Initiate a Full Scan.

Periodic scan—Configure periodic full scans that run on the endpoint as part of the malware security profile. To configure periodic scans, see Add a New
Malware Security Profile.

Custom scan—(Windows, requires agent v7.1 or later) The end user can initiate a scan on demand to examine a specific file or folder. For more
information, see the Cortex XDR Agent Administrator's Guide for Windows.

Initiate a Full Scan

You can initiate full scans of one or more endpoints from either All Endpoints table or the Action Center. After initiating a scan, you can monitor the progress from
Incident Response → Response → Action Center. From both locations, you can also abort an in-progress scan. The time a scan takes to complete depends on
the number of endpoints, connectivity to those endpoints, and the number of files for which Cortex XSIAM needs to obtain verdicts.

1. Log in to Cortex XSIAM.

Select Incident Response → Response → Action Center → +New Action.

2. Select Malware Scan.

3. Click Next.

4. Select the target endpoints (up to 100) on which you want to scan for malware.

Scanning is available on Windows, Mac and Linux endpoints. Cortex XSIAM automatically filters out any endpoints for which scanning is not supported.
Scanning is also not available for inactive endpoints.

TIP:

If needed, Filter the list of endpoints by attribute or group name.

5. Click Next.

6. Review the action summary and click Done when finished.

Cortex XSIAM initiates the action at the next heartbeat and sends the request to the agent to initiate a malware scan.

7. To track the status of a scan, return to the Action Center.

When the status is Completed Successfully, you can view the scan results.

8. View the scan results.

After an agent completes a scan, it reports the results to Cortex XSIAM .

To view the scan results for a specific endpoint:

a. In the Action Center, when the scan status is complete, right-click the scan action and select Additional data.

Cortex XSIAM displays additional details about the endpoint.

b. Right-click the endpoint for which you want to view the scan results and select View related security events.

Cortex XSIAM displays a filtered list of malware alerts for files that were detected on the endpoint during the scan.

4.7 | Investigate Files

Abstract

Cortex XSIAM provides you with different methods to handle and investigate files.

Manage File Execution

Manage Quarantined Files

Review WildFire Analysis Details

Import File Hash Exceptions

4.7.1 | Manage File Execution

Abstract

Set rules for the execution (or running) of particular files on your endpoints in Cortex XSIAM.

You can manage file execution on your endpoints by using file hashes that are included in 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 and allow it 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 any of your endpoints, you can add the associated hash to the block list.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 337/1003
5/8/24, 9:18 AM PDF Export

Adding files to the block list or allow list takes precedence of any other policy rules that may have otherwise been applied to these files. In the Action Center, you
can monitor the block list and allow list actions performed in your network, and add/remove file from these lists.

Supported file types are:

Operating System Supported File Types

Windows PE, PE64

doc, docx, xls, xlsx (only if they contain macro files)

Mac macho, DMG

Linux ELF

1. Go to Incident Response → Response → Action Center → + New Action.

2. Select either 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 once. You can add a comment that will be 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 will retrieve the updated lists from Cortex XSIAM .

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 the file and select one of the following:

Disable—The file hash remains on the list but will not be applied to your agents.

Move to Block List or Move to Allow List—Removes this file hash from the current list and adds it to the opposite one.

Edit Incident ID—Select to either Link to existing incident or Remove incident link.

Edit Comment—Enter a comment.

Delete—Delete the file hash from the list altogether, meaning this file hash will no longer be applied to your endpoints.

Open in VirusTotal—Directs you to the VirusTotal analysis of this hash.

Open Hash View—Pivot the hash view of the hash.

Open in Quick Launcher—Open the quick launcher search results for the hash.

4.7.2 | Manage Quarantined Files

Abstract

You can review and manage all files that have been quarantined by the agent due to a security incident.

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.

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

Quarantining a file in Cortex XSIAM can be done in one of two ways:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 338/1003
5/8/24, 9:18 AM PDF Export

Enable the agent to automatically quarantine malicious executables by configuring quarantine settings in the Malware security profile.

Right-click a specific file from the causality card and select Quarantine.

1. View the quarantined files in your network.

Navigate to Incident Response → Response → Action Center → File Quarantine. Toggle between DETAILED and AGGREGATED BY SHA256 views to
display 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.

Right-click one or more rows and select Restore all files by SHA256 to reinstate the selected files.

NOTE:

This will restore all files with the same hash on all of your endpoints.

In the Hash field, right-click to:

Open in VirusTotal—Review the quarantined file inspection results on VirusTotal. You will be redirected in a new browser tab to the VirusTotal
site and view all analysis details on the selected quarantined file.

Open Hash View—Drill down on each of the process executions, file operations, incidents, actions, and threat intelligence reports relating to
the hash value.

Open in Quick Launcher—Search for where the hash value appears in Cortex XSIAM.

Export to file 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.

Right-click a row and select Additional Data to open the Quarantine Details page detailing the Endpoint Name, Domain, File Path, Quarantine
Source, and Quarantine Date of a specific file hash.

Right-click and select Restore to reinstate one or more of the selected file hashes.

Right-click and select Delete all files by SHA256 to permanently delete quarantined files on the endpoint.

In the Hash field, right-click to:

Open in VirusTotal—Review the quarantined file inspection results on VirusTotal. You will be redirected in a new browser tab to the VirusTotal
site and view all analysis details on the selected quarantined file.

Open Hash View—Drill down on each of the process executions, file operations, incidents, actions, and threat intelligence reports relating to
the hash.

Open in Quick Launcher—Search for where the hash value appears in Cortex XSIAM .

4.7.3 | Review WildFire Analysis Details

Abstract

For each file, Cortex XSIAM receives a file verdict and the WildFire Analysis Report detailing additional information you can use to assess the nature of a file.

For each file, Cortex XSIAM receives a file verdict and the WildFire Analysis Report. This report contains detailed sample information and behavior analysis in
different sandbox environments, leading to the WildFire verdict. You can use the report to assess whether the file poses a real threat on an endpoint. The details
in the WildFire analysis report for each event vary depending on the file type and the behavior of the file.

1. Drill down into the WildFire Analysis Details.

WildFire analysis details are available for files that receive a WildFire verdict. The Analysis Reports section includes the WildFire analysis for each testing
environment based on the observed behavior for the file.

a. Open the WildFire report.

If you are analyzing an incident, right-click the incident and View Incident. From the Key Artifacts involved in the incident, select the file for which you
want to view the WildFire report and open ( ). Alternatively, if you are analyzing an alert, right-click the alert and Analyze. You can open ( ) the
WildFire report of any file included in the alert Causality Chain.

NOTE:

Cortex XSIAM displays the preview of WildFire reports that were generated within the last couple of years only. To view a report that was
generated more than two years ago, you can download the WildFire report.

b. Analyze the WildFire report.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 339/1003
5/8/24, 9:18 AM PDF Export

On the left side of the report, you can see all the environments in which the Wildfire service tested the sample. If a file is low risk and WildFire can
easily determine that it is safe, only static analysis is performed on the file. Select the testing environment on the left, for example, Windows 7 x64
SP1, to review the summary and additional details for that testing environment. To learn more about the behavior summary, see WildFire Analysis
Reports—Close Up.

c. (Optional) Download the WildFire report.

If you want to download the WildFire report as it was generated by the WildFire service, click ( ). The report is downloaded in PDF format.

2. Report an incorrect verdict to Palo Alto Networks.

If you know the WildFire verdict is incorrect, for example, WildFire assigned a Malware verdict to a file you wrote and know to be Benign, you can report
an incorrect verdict to Palo Alto Networks to request the verdict change.

a. Review the report information and verify the verdict that you are reporting.

b. Report ( ) the verdict to Palo Alto Networks.

c. Suggest a different Verdict for the hash.

d. Enter any details that may help us to better understand why you disagree with the verdict.

e. Enter an email address to receive an email notification after Palo Alto Networks completes the additional analysis.

f. After you enter all the details, click OK.

From this point on, the threat team will perform further analysis of the sample to determine if it should be reclassified. If a malware sample is
determined to be safe, the signature for the file is disabled in an upcoming antivirus signature update or if a benign file is determined to be
malicious, a new signature is generated. After the investigation is complete, you will receive an email describing the action that was taken.

4.7.4 | Import File Hash Exceptions

Abstract

You can import file hash exceptions from the Endpoint Security Manager or from external feeds.

The Action Center page displays information on files quarantined and included in the allow list and block list. To import hashes from the Endpoint Security
Manager or from external feeds, you can initiate an action.

1. From Cortex XSIAM , select Incident Response → Response → Action Center → + New Action.

2. Select Import Hash Exceptions.

3. Drag your Verdict_Override_Exports.csv file to the drop area.

If necessary, resolve any conflicts encountered during the upload and retry.

4. Click Next twice.

5. Review the action summary, and click Done.

Cortex XSIAM imports and then distributes your hashes to the allow list and block list based on the assigned verdict.

4.8 | Forensic investigations

Abstract

Learn about forensics, how to create forensic investigations, how to create and manage data collections, and how to assess other forensic related settings.

The Forensics investigations provides a single location for grouping, tracking, and analyzing all forensic data collections.

The one-stop shop that enables you to:

View any alerts triggered during data ingested as part of the investigation.

Tag relevant evidence for inclusion for the Investigation Timeline.

Export collected data for long-term retention.

Set user permissions that can be assigned to investigations allowing you to restrict access to the Investigation page including the Investigation Timeline
and collection details.

The Forensic Investigation fields shows information relating to the investigation.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 340/1003
5/8/24, 9:18 AM PDF Export

Fields Description

Investigation The name of the investigation.

Description Shows the Information that describes the investigation.

Status Shows the present status of the investigation:

Open

Close pending: After selecting close, the investigation status changes to close pending. It takes 24 hours until officially removed
from the investigations repository. This gives the users a chance to revert back if necessary.

Evidence Shows the number of completed collections from the total collections.
collections

New alerts Shows the total count of alerts for the collection with the status New.

You can click the link to open the investigation on the Alerts tab with the filter of status=new.

Total alerts Shows the total number of alerts for data collected in the investigation

You can click the link to open the investigation on the Alerts tab.

Created by Shows the username of the user who created the investigation.

Created Shows the timestamp of when the investigation was created.

4.8.1 | Manage an investigation

Abstract

Manage an investigation by adding collections, managing alerts, adjusting the timeline, analyzing assets and artifacts.

Investigations are comprised of one or more data collections from endpoints within an environment. Grouping all of the collections within a single location allows
you to focus on the endpoints relevant to your investigation. There are two types of collections to choose from when searching for data:

Hunt collections enable you to search for a specific activity across a large number of hosts. It provides more details about where something occurred.
Such examples would be, finding which endpoints ran a piece of malware, which users accessed a particular file, or which endpoints were accessed by a
specific user.

Triage collections enable you to collect detailed information about specific activities that occurred on an endpoint. The triage functionality is configurable
and supports the collection of all the currently supported forensic artifacts, user-defined file paths, a full file listing for all of the connected drives, full event
logs, and registry hives. The amount of data collected during a triage can be large, so triages are limited to ten or fewer endpoints per collection.

On the Forensic Investigation page, you can create a new investigation or you can edit an existing one.

The Forensic Investigations table gives you an overview of important information of the ongoing investigations. If you click on the highlighted name of the
investigation, you're directed right to the Investigation page. From here, you can add or monitor collections, manage timelines or just review key assets &
artifacts.

From an investigation page, click the UTC Timezone to configure the timezone and timestamp format. Refer to Select Timezone for information on setting up
your timezone.

If you right-click on the investigation, you can edit or close the investigation.

NOTE:

When you close an investigation, it waits 24 hours before deleting any collections associated with that investigation. During that timeframe, you have the
option to cancel the close investigation action.

When editing an investigation, you can change the name, description and add or remove users from the permissions list. For information on users, see User
permissions.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 341/1003
5/8/24, 9:18 AM PDF Export

4.8.1.1 | Create a new investigation

Abstract

Learn how to create a forensics investigation. This includes adding a collection, exporting the data collection, managing alerts and key assets & artifacts.

Create a forensics investigation that includes all the forensics data relevant to the investigation. This includes adding collections (hunts and triages), exporting
the data collections, managing alerts and evaluating key assets & artifacts.

1. In Cortex XSIAM, select Incident Response → Investigation → Forensics → Forensics Investigations.

2. Click New Investigation.

3. Enter a unique name and optional description for the investigation.

4. In the Permissions table. select the users that can access the data of the investigation.

NOTE:

Scope-Based Access Control (SBAC) must be enabled for you to set up user permissions.

Refer to User permissions for detailed information on permissions.

5. Click Save to save the investigation in the Forensics Investigations table or click Save & Start A Collection to start the process of adding collections.

6. In the New Collection widget, select Triage orHunt.

7. The investigation is saved to the forensic investigation table.

4.8.1.2 | Edit an investigation

Abstract

Learn how to edit an existing investigation from the Forensic Investigation page.

From the list of ongoing investigations, you can edit the name, description or update the user permissions for the investigation.

1. From the Forensic Investigations table, right-click one of the investigations and select Edit.

2. In the Edit Investigation widget, you can update the Investigation Name, Description and Permissions. For information on Permissions, refer to User
permissions.

4.8.1.3 | Close an investigation

Abstract

Learn how to close an existing investigation from the Forensic Investigation page.

From the list of ongoing investigations, you can close an investigation.

NOTE:

When you close an investigation, it waits 24 hours before deleting any collections associated with that investigation. During that timeframe, you have the
option to cancel the close investigation action.

1. From the Forensic Investigations table, right-click an investigation and select Close.

2. In the Close Investigation widget, all evidence collections exported for the investigation are shown. Click Close Investigation, to start closing investigation
process.

3. In the Forensic Investigation table, the status is changed to Close Pending, with the timestamp when the investigation expires and all the data associated
with the investigation gets deleted.

4. Right-click the investigation to activate one of the options:

Edit: Enables you to update the investigation name, description, or adjust user permissions.

Open: After selecting open, the close request is cancelled.

Permanently delete: The investigation and all the associated data is deleted immediately and can't be cancelled.

4.8.1.4 | User permissions

Abstract

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 342/1003
5/8/24, 9:18 AM PDF Export

You can assign users to the investigation for them to view and manage the investigation.

The Permissions table appears only when Scope-Based Access Control (SBAC) is enabled. Go to Server Settings → Scoped Server Access to enable
investigation permissions.

Users with account administrator or instance administrator roles have access to investigations and can't be cleared from the Permissions table. They can view
and edit all Investigations, including adding/removing users, creating/deleting collections, closing the Investigation. This prevents investigation lockout in the
event of a user leaving before the Investigation is complete.

When SBAC is enabled, you can limit access to selected users with other assigned roles, and assign them permissions to the investigation.

If SBAC is disabled, the permissions is limited to role-based access (RBAC), so anyone with forensic investigator or forensics viewer access will be able to see
the investigations.

NOTE:

Even if a user does not have access to view an investigation via the Forensics Investigations page, they can still query the results of the collections via an
XQL event.

The Permissions fields describe the following information:

Field Description

User Name Name of the user as logged in the Settings → Access Management → Users.

Email The user's email as logged in the Settings → Access Management → Users.

User Type Indicates whether the user was defined in Cortex XSIAM using the CSP (Customer Support Portal), SSO (single sign-on) using your
organization’s IdP, or both CSP/SSO.

Role Name of the role assigned specifically to the user that is not inherited from somewhere else, such as a User Group. When the user does not
have any Cortex XSIAM access permissions that are assigned specifically to them, the field displays No-Role.

Permissions Options are None, View, View/Edit

4.8.2 | Data collection

Abstract

This section includes information related to each collection type.

The data collection section includes information related to each collection type.

4.8.2.1 | Hunting

Abstract

Hunting refers to searching for specific data across a large number of hosts.

Hunting allow investigators to search for specific data across a large number of hosts. Hunt collections provide more details about where something occurred.
Such examples would be, finding which endpoints executed a piece of malware, which users accessed a particular file, or which endpoints were accessed by a
specific user.

4.8.2.1.1 | Create a hunt

Abstract

Hunt collections enable you to search endpoints for suspicious activity to contribute to helping resolve the investigation.

Hunt collections should be selected when searching for a specific activity across a large number of hosts. Hunt Collections obtain more details about where
something occurred. Such examples of when you would use a Hunt, is finding which endpoints executed a piece of malware, which users accessed a particular
file, or which endpoints a specific user authenticated to.

When adding a new hunt collection, there are various artifact types for Windows and macOS to select from to carry out the search.

1. In the Hunt Collection Name field, enter a name that will be easy to find in the collections table.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 343/1003
5/8/24, 9:18 AM PDF Export

2. Select the Platform, either Windows or macOS.

3. Select one of the time range options:

One Time Collection: Select to run the hunt collection only once.

Repeat Collection Every: Select to run the hunt collection every x hours set.

Schedule: Select a time range of days during the week and time frame.

4. In the Description field, enter information that is relevant to the collection you are creating .

5. In the Maximum Concurrent Endpoints field, enter the maximum number of endpoints that will run the searches at the same time within the time range
specified. The default is 200 endpoints.

6. In the Configuration page, refer to Configuration for hunt collection section for information of each of the artifacts.
NOTE:

You can save hunts in an incomplete state and edit them later. After a hunt has run, you will not be able to edit. Instead of editing the running hunt, you can
select duplicate to create a new hunt with the same configuration in order to edit.

Configuration for hunt collection

NOTE:

For the hunt searches, if an artifact type is selected but no search fields are specified, then all of the parsed artifact entries are returned.

When search fields are specified, the results of the search are limited based upon those filters. If more than one entry is provided in a search filter field then
the search returns entries that match any of the provided entries. For example: A File Search with two specified paths ("C:\Test\*" and "C:\Windows\*") will
return results from both the Test folder as well as the Windows folder.

When multiple search fields are specified for the same search, then at least one entry for each field must match in the returned results. For example: A File
Search with one path ("C:\Test") and one size filter (">= 100MB") will only return results from the Test folder that are greater-than or equal to 100 megabytes.

Not all artifacts within an artifact category support the same search fields. If an artifact does not support one of the specified fields then that filter will not be
applied to the search results. For example: For Windows, Process Execution search with the search field for User Name="jsmith", all results from the
CidSizeMRU, LastVisitedPidlMRU, and UserAssist artifacts will be filtered by that user name. Results from the Amcache, Prefetch, and Shimcache artifacts
will not be filtered by that user name because those artifacts do not have a User Name field.

You can create a search query adding any of the following artifacts for a Hunt Collection.

Category Default Timeout Description

Archive 60 minutes The Archive History Search enables you to collect the following artifacts from the endpoint/s:
History
(Windows) 7-Zip Folder History: A registry key containing a list of archive files accessed using 7-Zip.
(Windows
only) (Windows) WinRAR ArcHistory: A registry key containing a list of archive files accessed using WinRAR.

Supported filters:

File Name: regular expression (case-insensitive)

Example: [0-9A-F]{8}\.exe

File Path: path (wildcards ? * ** supported)

Example: C:Windows\Temp\**\*.exe

Command 60 minutes The Command History Search enables you to collect the following artifact from the endpoint/s:
History
(Windows) PSReadline: A record of commands typed into a PowerShell terminal by user. The history file is only
enabled by default, starting with Powershell 5 on Windows 10 or newer.

(macOS) Shell History: Commands recorded to the history files for Bash and Zsh shells.

Supported filters:

Search Regex: regular expression (case-insensitive)

Example: [0-9A-F]{8}\.exe

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 344/1003
5/8/24, 9:18 AM PDF Export

Category Default Timeout Description

Deleted Files 180 minutes The Deleted Files Search enables you to collect the following artifact from the endpoint:
(Windows
(Windows) Recycle Bin: Folder used by Windows as temporary storage for deleted files prior to permanent
only)
deletion.

Supported filters:

File Name: regular expression (case-insensitive)

Example: [0-9A-F]{8}\.exe

File Path: path (wildcards ? * ** supported)

Example: C:Windows\Temp\**\*.exe

User Search: User SID or User Name selector.

Example: ACME\jsmith

File Access 60 minutes The File Access Search enables you to collect the following file access artifacts from the endpoint/s:

(Windows) Jumplists: A feature of the Windows Task bar that provides shortcuts to users for recently accessed
files or applications.

(Windows) OpenSavePidlMRU: A registry key containing a list of recently opened and saved files for a user’s
account.

(Windows) Recent Files: Contents of the shortcut (.lnk) files found in a user's Recent folder. These files
represent files recently accessed for a user account.

(Windows) ShellBags: Registry keys that record user layout preferences for each folder with which the user
interacts.

(Windows) TypedPaths: A registry key containing a list of paths that the user typed into the Windows Explorer
path bar.

(macOS) Recent Documents: Plist files located within a user's Library directory that contain a list of documents
accessed by that user.

Supported filters:

Target File Name: regular expression (case-insensitive)

Example: [0-9A-F]{8}\.exe

Target File Path: path (wildcards ? * ** supported)

Example: C:Windows\Temp\**\*.exe

User Search: User SID or User Name selector.

Example: ACME\jsmith

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 345/1003
5/8/24, 9:18 AM PDF Export

Category Default Timeout Description

File Search 180 minutes The File Search enables you to collect the following artifact from the endpoint/s:

(Windows, macOS) File Search: Search for a file across endpoints by specifying a file path that can include
wildcards, and then filter those results based on the file size, the file name (supports regular expressions), or
file hash (MD5, SHA1, or SHA256).

Supported filters:

File Path: path (wildcards ? * ** supported)

Example: C:Windows\Temp\**\*.exe

File Name: regular expression (case-insensitive)

Example: [0-9A-F]{8}\.exe

File Hash: Supports MD5, SHA1, and SHA256.

Example: f9d9b9ded9a67aa3cfdbd5002f3b524b265c4086c188e1be7c936ab25627bf01

Size

Example: >= 100 MB

Log Search 180 minutes The Log Search enables you to collect the following artifact from the endpoint/s:

(Windows) Event Log: A component of Microsoft Windows, where the user can view record of events that
occurred within a system or process.

(macOS) Apple Unified Logs: Predicate is a custom filter component for Apple Unified Logs.

Supported filters:

Event Log Channel: Does not support wildcards.

Example: Security

Event ID:

Example: 4624

Providers: Does not support wildcards.

Example: Security

Message: regular expression (case-insensitive)

Example: [0-9A-F]{8}\.exe

Predicate: Custom filter component for Apple Unified Logs.

Example: eventType=logEvent AND eventMessage Contains abc

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 346/1003
5/8/24, 9:18 AM PDF Export

Category Default Timeout Description

Network Data 60 minutes The Network Data Search enables you to collect the following artifacts from the endpoint/s:

(Windows) ARP Cache: A cache of Address Resolution Protocol (ARP) records for resolved MAC and IP
addresses.

(Windows) DNS Cache: A cache of Domain Name System (DNS) records for resolved domains and IP
addresses.

(Windows.macOS) Hosts File: Listing of entries from the etc/hosts file.

(macOS) Recent Places: A plist file located within a user's Library directory that contains a list of recently
accessed servers and hosts.

Supported filters:

IP Address: IPv4 or IPv6 addresses.

Example: 10.0.0.5

Domain: regular expression (case-insensitive)

Example: goo.*\.com

Path: path (wildcards ? * ** supported)

Example: /Volumes/VMware*

User Search: User SID or User Name selector.

Example: ACME\jsmith

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 347/1003
5/8/24, 9:18 AM PDF Export

Category Default Timeout Description

Persistence 60 minutes The Persistence Search enables you to collect the following application persistence artifacts from the endpoint/s:

(Windows) Drivers: Windows device drivers installed on each endpoint.

(Windows) Registry Persistence: A collection of registry keys that can be used for malware persistence.

(Windows) Scheduled Tasks: Tasks used to execute Windows programs or scripts at specified intervals.

(Windows) Services: Windows applications that run in the background and do not require user interaction.

(Windows) Shim Databases: Databases used by the Application Compatibility Infrastructure to apply shims to
executables for backwards compatibility. These databases can be used to inject malicious code into legitimate
processes and maintain persistence on an endpoint.

(Windows) Startup Folder: Contents of the shortcut .lnk files found in the Startup folder for both the system and
users. The folders are used to automatically launch applications during system startup or user logon
processes.

(Windows) WMI Persistence: List of WMI EventConsumers and any EventFilters that are bound to them using
a FilterToConsumerBinding. WMI EventConsumers can be used as a method of fileless malware persistence.

(macOS) Cron: A system utility that executes programs or scripts at specified intervals.

(macOS) Launchd: Listing of applications and daemons configured to launch using the launchd process.

(macOS) Login Items: Plist files containing applications, files, or folders configured to launch during user login.

Supported filters:

Registry Path: path (wildcards ? * ** supported)

Example: HKEY_USERS\*\Software\Microsoft\Windows\CurrentVersion\Run\*

Executable Path: path (wildcards ? * ** supported)

Example: C:Windows\Temp\**\test.exe

User Search: User SID or User Name selector.

Example: ACME\jsmith

SHA256: Supports SHA256 hashes.

Example: f9d9b9ded9a67aa3cfdbd5002f3b524b265c4086c188e1be7c936ab25627bf01

Command: regular expression (case-insensitive)

Example: /bin/sh /private/etc/periodic/weekly/.*

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 348/1003
5/8/24, 9:18 AM PDF Export

Category Default Timeout Description

Process 60 minutes The Process Execution Search enables you to collect the following artifacts from the endpoint/s:
Execution
(Windows) Amcache: A registry hive used by the Application Compatibility Infrastructure to cache the details of
executed or installed programs.

(Windows) Background Activity Monitor: Per-user registry keys created by Background Activity Monitor (BAM)
service to store the full paths of executable files and a timestamp, indicating when they were last executed.

(Windows) CidSizeMRU: A registry key containing a list of recently launched applications.

(Windows) LastVisitedPidlMRU: A registry key containing a list of the applications and folder paths associated
with recently opened files found in the user’s OpenSavePidMRU key.

(Windows) Prefetch: A type of file created to optimize application startup in Windows. These files contains a run
count for each application, between one and eight timestamps of the most recent executions, and a record of
all of the files opened for a set duration after the application was started.

(Windows) Recentfilecache: A cache created by the Application Compatibility Infrastructure to store the details
of executed or installed programs (Windows 7 only).

(Windows) Shimcache: A registry key used by the Application Compatibility Infrastructure to cache details
about local executables.

(Windows) UserAssist: A registry value that records a count for each application that a user launches via the
Windows UI.

(Windows) Windows Activities: A database containing user activity for a particular Microsoft user account,
potentially across multiple devices. This is also called the Windows Timeline.

(macOS) CoreAnalytics: A diagnostic log that contains details of files executed on the system.

(macOS) Recent Applications: A plist file located within a user's Library directory that contains a list of
applications opened by that user.

Supported filters:

Executable File Name: regular expression (case-insensitive)

Example: [0-9A-F]{8}\.exe

Executable Path: path (wildcards ? * ** supported)

Example: C:Windows\Temp\**\test.exe

User Search: User SID or User Name selector.

Example: ACME\jsmith

SHA256: Supports SHA256 hashes.

Example: f9d9b9ded9a67aa3cfdbd5002f3b524b265c4086c188e1be7c936ab25627bf01

Registry 180 minutes The Registry Search enables you to collect the following artifact from the endpoint/s:
Search
(Windows (Windows) Registry Search: Registry listings collected during Forensic investigation.
only) Supported filters:

Path: path (wildcards ? * ** supported)

Example: HKEY_USERS\*\Software\Microsoft\Windows\CurrentVersion\Run\*

Data: regular expression (case-insensitive)

Example: [0-9A-F]{8}\.exe

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 349/1003
5/8/24, 9:18 AM PDF Export

Category Default Timeout Description

Remote 60 minutes The Remote Access Search enables you to collect the following artifacts from the endpoint/s:
Access
(Windows) AnyDesk Connection Logs: Records of activity found in the AnyDesk connection logs.
(Windows
only) (Windows) AnyDesk Trace Logs: Records of activity found in the AnyDesk trace logs.

(Windows) LogMein: Records of activity found in the LogMeIn event logs.

(Windows) TeamViewer: Records of incoming TeamViewer connections found in the Connections_incoming.txt

file.

(Windows) User Access Logging: A Windows Server feature that records details about client access to the
server. Only found on Windows Server 2012 and newer.

Supported filters:

IP Address: IPv4 or IPv6 addresses

Example: 10.0.0.5

User Search: User SID or User Name selector.

Example: ACME\jsmith

System 60 - 120 minutes The System Statistics Search enables you to collect the following artifacts from the endpoint/s:
Statistics
(Windows) Application Resource Usage: A table in the System Resource Usage database that stores statistics
(Windows
pertaining to resource usage by running applications.
only)
(Windows) Network Connectivity Usage: A table in the System Resource Usage database that stores statistics
pertaining to network connections, containing the start time and duration of the connections for each network
interface.

(Windows) Network Data Usage: A table in the System Resource Usage database that stores statistics
pertaining to network data usage for running applications. Includes application path, network interface, bytes
sent, and bytes received.

Supported Filters:

Application: path (wildcards ? * ** supported)

Example: C:Windows\Temp\**\test.exe

User Search: User SID or User Name selector.

Example: ACME\jsmith

User Searches 60 minutes The User Searches enables you to collect the following artifact from the endpoint/s:

(Windows) WordWheelQuery: Registry key containing a list of terms that a user searched for in Windows
Explorer.

(macOS) Spotlights Shortcuts: A plist file that contains the Spotlight search terms entered by each user and the
items that they selected from the search results.

Supported filters:

User Search: User SID or User Name selector.

Example: PANW\jsmith

Search Regex: regular expression (case-insensitive)

Example: [0-9A-F]{8}\.exe

4.8.2.1.2 | Hunt results

Abstract

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 350/1003
5/8/24, 9:18 AM PDF Export

The hunt results page consolidates information collected by the Cortex XDR agent enabling you to investigate and take action on your endpoints.

The hunt results page consolidates information collected by the Cortex XDR agent enabling you to investigate and take action on your endpoints.

Review process execution search

Abstract

Manage the process execution artifacts collected from the endpoints.

The Process Execution table displays a normalized table containing an overview of all of the different process execution artifacts collected from the endpoints.
Investigate the following detailed fields:

Field Description

Context Contextual detail relating to the executed process such as files opened,
command line arguments, or process run count.

Description Description of the timestamp associated with executable name.

Executable Name Name of the executable.

The grouping button ( ) shows the number of affected endpoints grouped

by executable name. This enables you to perform hunting via frequency
analysis (referred to as stacking) and provides a birds eye view of potential
malware files that require further analysis.

Executable Path Path of the executable.

The grouping button ( ) shows the number of affected endpoints grouped

by executable path. This enables you to perform hunting via frequency
analysis (referred to as stacking) and provides a birds eye view of potential
malware files that require further analysis.

Hostname Name of the host on which the process resided.

MDS MDS value of the executable file, if available on the file system.

SHA1 SHA1 value of the executable file, if available on the file system.

SHA256 SHA256 value of the executable file, if available on the file system.

The grouping button ( ) shows the number of affected endpoints grouped

by SHA256. This enables you to perform hunting via frequency analysis
(referred to as stacking) and provides a birds eye view of potential malware
files that require further analysis.

Timestamp Timestamp associated with the executable file or process execution.

Type Type of process artifact.

User User name associated with the execution artifact.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 351/1003
5/8/24, 9:18 AM PDF Export

Field Description

Verdict WildFire verdict for the following process execution artifacts.

Prefetch

Recentfilecache

Shimcache

UserAssist

If there is a WildFire verdict, the relevant Verdict is displayed.

Unknown

Benign

Malware

Grayware

Also, a link to the WildFire analysis report is available for review.

Review File Access

Abstract

Manage file access collected from endpoints.

The File Access table displays a normalized table containing an overview of all of the different file access artifacts collected from the endpoints. Investigate the
following detailed fields:

Field Description

Description Description of the timestamp associated with file or folder.

Hostname Name of the host on where the file access artifact resided.

Path Path of the accessed file or folder.

Timestamp Timestamp associated with the accessed file or folder.

Type Type of file access artifact.

User User name of who accessed the file or folder, if available.

Review persistence search

Abstract

Manage persistence artifacts collected from the endpoints.

The Persistence table displays a normalized table containing an overview of all of the application persistence artifacts collected from the endpoints. Investigate
the following detailed fields:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 352/1003
5/8/24, 9:18 AM PDF Export

Field Description

Command Command to be executed.

The grouping button ( ) shows the number of affected endpoints grouped

by command. This enables you to perform hunting via frequency analysis
(referred to as stacking) and provides a birds eye view of potential malware
files that require further analysis.

Description Description of the timestamp associated with this row.

Endpoint ID Unique identifier of the endpoint on which the persistence mechanism

resides.

File Path Path of a secondary executable (often a dll) associated with this persistence
mechanism.

The grouping button ( ) shows the number of affected endpoints grouped

by file path. This enables you to perform hunting via frequency analysis
(referred to as stacking) and provides a birds eye view of potential malware
files that require further analysis.

File SHA256 SHA256 value of the file.

The grouping button ( ) shows the number of affected endpoints grouped

by file SHA256. This enables you to perform hunting via frequency analysis
(referred to as stacking) and provides a birds eye view of potential malware
files that require further analysis.

Hostname Name of the host on which the persistence mechanism resides.

Image Path Path of the executable associated with this persistence mechanism.

Name Name associated with persistence mechanism, if available.

The grouping button ( ) shows the number of affected endpoints grouped

by name. This enables you to perform hunting via frequency analysis
(referred to as stacking) and provides a birds eye view of potential malware
files that require further analysis.

Registry Path Path of the registry value.

The grouping button ( ) shows the number of affected endpoints grouped

by registry path. This enables you to perform hunting via frequency analysis
and provides a birds eye view of potential malware files that require further
analysis.

Timestamp Timestamp associated with the persistence mechanism.

Type Type of persistence mechanism.

User User account associated with persistence mechanism.

User SID User account associated with persistence mechanism.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 353/1003
5/8/24, 9:18 AM PDF Export

Field Description

Verdict WildFire verdict for the following persistence artifacts.

Drivers

Registry

Scheduled Tasks

Services

Startup Folder

If there is a WildFire verdict, the relevant Verdict is displayed.

Unknown

Benign

Malware

Grayware

Also, a link to the WildFire analysis report is available for review.

Review network data search

Abstract

Manage the different network artifacts collected on the endpoints.

The Network table displays an overview of the different types of network artifacts collected on the endpoints. Investigate the following detailed fields:

Field Description

Hostname Name of the host on which the network activity occurred.

Interface Type of network interface.

IP Address IP address associated with network activity.

Resolution Network data type associated with the IP address.

Type Type of network artifact.

Review remote access search

Abstract

Manage the remote access artifacts collected from the endpoints.

The Remote Access table displays a normalized table containing an overview of all of the remote access artifacts collected from the endpoints. Investigate the
following detailed fields:

Field Description

Connection ID Unique Identifier associated with the particular remote access connection
found in this row.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 354/1003
5/8/24, 9:18 AM PDF Export

Field Description

Connection Type Type of remote access connection.

Description Description of the timestamp associated with this remote access connection.

Duration Duration of remote access connection.

Endpoint ID A unique ID assigned by Cortex XDR that identifies the endpoint.

Hostname Name of the host on which the remote access occurred.

Message Description of activity related to this remote access collection.

Source Host Origination host of remote access connection.

Timestamp Date and time of the remote access activity.

Type Type of remote access artifact.

User User account associated with remote access connection.

Review archive history search

Abstract

Manage archive processes that were executed on an endpoint.

The Archive History table displays an overview of the different types of archive processes that were executed on an endpoint. Investigate the following detailed
fields:

Field Description

Hostname Name of the host on which the archive history was found.

Timestamp Timestamp associated with archive history file.

Type Type of archive history artifact.

7-Zip Folder History

WinRAR ArcHistory

Description Description of the timestamp associated with this archive history file.

Path Path of archive history file.

User User account associated with archive history file.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 355/1003
5/8/24, 9:18 AM PDF Export

4.8.2.1.3 | Hunt status

Abstract

In the Actions table, you can scroll or use the filters to see the status of any search within a hunt across any of the targeted endpoints.

Hunts consist of searches across multiple endpoints and those searches can take time to return results from all of the targeted endpoints. To view the status of
all of the searches contained within a hunt, click on the Actions link within the Status column for that hunt on the Collections page. This will launch a new
browser tab displaying the Actions table. Within the Actions table, you can scroll or use the filters to see the status of any search within a hunt across any of the
targeted endpoints.

Using this information, you can identify the successful and failed searches and take the necessary action.

Field Description

Endpoint name Agent hostname.

Endpoint ID Agent unique ID.

Action ID A unique identifier for the agent action.

Name Name of search.

Status Shows one of the following statuses of the search:

Pending

In progress

Completed successfully

Failed

Timeout

Artifact category Name of category for the search.

Example: Process execution

Artifact Artifact targeted by this search.

Example: Amcache

Results Number of results received for the search.

Last updated The last time results were received for this action.

Parameters The string that describes the search parameters.

Example: C:\Users\* File Name Regex: *\.exe

Creation time The timestamp when the search was created.

4.8.2.2 | Triage

Topic Not Found

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 356/1003
5/8/24, 9:18 AM PDF Export

4.8.2.2.1 | Create triage

Abstract

Triage collections enable you to obtain additional information for certain activities that have occurred on the endpoints. This helps towards the forensics analytics
of an investigation.

Triage collections should be used when a certain activity, group of activities, or the actions of a specific user on that endpoint have been identified, and
additional information is required. The triage functionality collects detailed system information, including a full file listing for all of the connected drives, full event
logs, and registry hives, to provide you with a complete, holistic picture of an endpoint.

Triage supports data collection from both online and offline hosts, on both Windows and macOS platforms.

1. In the Triage Collection Name field, enter a name that will be easy to find in the collections table.

2. Select the Platform either Windows or macOS.

3. In the Description field, enter information that is relevant to the collection you are creating .

4. For Triage Type, you can select Offline or Online or both.

5. Select Offline to upload archives containing forensic data collected by the Offline Collector. After the archive has been uploaded, the data is extracted and
ingested into the Forensics tables on the tenant. Import Offline Triage supports uploading packages created on both the Windows and macOS platforms.

6. Click Save Collection and Exit or click Next to continue.

7. In the configuration page, select the options from the Artifacts, Volatiles and File Collection list.

You can click Add Custom to add your own file to the File Collections.

8. You can select a preset from Select Presets (Windows/macOS) to copy the options of artifacts, volatiles and file collections from another collection.

You can also click Save new preset to save the options of the current collection for prospective triage collections to use.

9. Click Save Collection and Exit or click Next to continue.

4.8.2.2.2 | Upload an offline triage package

Abstract

Use the Upload Offline Triage to upload archives containing forensic data collected by the offline collector.

The Forensics Triage feature enables you to create a custom, standalone executable package that collects all of the forensic artifacts in the configuration.

Use the Upload Offline Triage to upload archives containing forensic data collected by the offline collector. After the archive has been uploaded, the data is
extracted and ingested into the forensics table on the tenant. Upload Offline Triage supports uploading packages created on both the Windows and macOS
platforms..

1. In Cortex XSIAM, select Incident Response → Investigation → Forensics → Forensics Investigations.

2. Click the link of the relevant investigation.

3. When in the Collections page, search for or select the triage and click the menu options button ( ) to select Upload Offline Package.

4. Drag and drop or use the browse link to search for the file. More than one offline triage package can be uploaded at a time.

NOTE:

Do not upload memory images captured by the Offline Triage Collector. These images are collected for analysis using third-party tools and are not
intended for upload.

5. Click Done.

4.8.2.2.3 | Triage results

Abstract

You can drill down from the triage collection to review the results.

The Triage collection results page displays an overview of the different types of triage collections that were initiated on an endpoint.

Drill down to further investigate the triage artifact.

The triage results page is divided by the following tabs:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 357/1003
5/8/24, 9:18 AM PDF Export

Alerts: Refer to Alerts for descriptions of the fields.

Artifacts: Shows all of the artifact categories collected. You can select the item to add to a timeline.

**Host Timeline:

4.8.2.2.4 | Triage status

Abstract

From the Actions table, you can view the search status of all the artifacts for the triage.

You can drill down to the Actions table from the status link of the triage to view the search the status of all the artifacts for the triage.

Field Description

Endpoint name Agent hostname.

Endpoint ID Agent unique ID.

Action ID Unique identifier for this agent action.

Type Type of collection.

Example: Amcache, File Collection, Event Logs

Path Path for files, registry path for registry artifacts.

Status Shows one of the following statuses of the search:

Pending: agent action sent

In progress: SAM not sent

Results received: received SAM results

Timeout: SAM timed out

Ingesting: Ingestion started

Uploaded: data received, but not parsed

Ingested: ingestion completed

Partially ingested: ingested with errors

Failed: ingestion failed

Details Shows the detailed output from the ingestion script.

Example: Ingested X of Y records

Collected Time the data was collected.

Download expiration Time when bucket data (raw files) is to be deleted.

Preset Name of the triage configuration.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 358/1003
5/8/24, 9:18 AM PDF Export

Field Description

Collection Type Collection type.

Triage ID Unique ID associated with this triage data.

4.8.3 | Analysis and documentation

Abstract

Learn more about your investigation by reviewing the additional data for analysis and documentation purposes.

Forensic investigations include additional data for analysis and documentation purposes.

Alerts

Forensics Timeline

Key Assets & Artifacts

4.8.3.1 | Review alerts

Abstract

The alerts table shows you all the collections within the investigation that has identified suspicious or malicious activity within the forensics data sets.

The alerts table shows you all the collections within the investigation that has identified suspicious or malicious activity within the forensics data sets.

Refer to Alerts for the descriptions of the table fields.

You can implement any of the available actions from the selected alert.

Change status

Change severity

Investigate causality chain

Run playbook

Manage alerts

4.8.3.2 | Investigation timeline

Abstract

Investigation timeline shows the forensic artifacts that were tagged. The tags show details of the forensic data collected from the endpoints.

The Timeline page enables you to view the list of forensic artifacts that were tagged. The tags show details of the forensic data collected from the endpoints.

The Timeline table displays the following fields:

Field Description

Hostname Name of the host machine.

Timestamp Timestamp associated with the artifact.

Type Forensic artifact of which a tag was added.

Description Name of the timestamp field.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 359/1003
5/8/24, 9:18 AM PDF Export

Field Description

Tags There are three default tags to choose from.

legitimate

malicious

suspicious

You can also create your own tag.

User User account associated with the forensic artifact.

Data Data summary for the tagged item.

Mitre Att&ck Tactic Displays the type of MITRE ATT&CK tactic of the tagged item.

Mitre Att&ck Technique Displays the type of MITRE ATT&CK technique of the tagged item.

Notes Displays notes entered by the user.

1. Edit a timeline entry:

You can edit a tag of an artifact in the Timeline table.

a. Locate the relevant item to update the tag.

b. Right-click and select Edit timeline entry.

c. In Edit timeline entry, update the information as required and then click Save to update the changes.

2. Clear a timeline entry:

You can remove a tag from the artifact in the Timeline table.

a. Locate the relevant item to remove the tag.

b. Right-click and select Clear timeline entry. The tag is removed from the artifact and the row is removed from the Timeline table.

4.8.3.3 | Key assets & artifacts

Abstract

Shows the forensic investigation based on the tagged data and aligns it to the corresponding category.

Key assets & artifacts are automatically created based on the tagged data from the investigation timeline of the investigation and dividing them among the
categories:

Data Access: Shows all the items that have been tagged in the File Access tables.

The following table for Endpoints shows the endpoints that have at least one or more items tagged:

Field Description

Endpoint Name The name of the endpoint.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 360/1003
5/8/24, 9:18 AM PDF Export

Field Description

Endpoint Type Shows the endpoint type:

Mobile

Server

Workstation

Kubernetes Node

Endpoint Status Shows the status of the endpoint:

Connected

Connected Lost

Deleted

Disconnected

Uninstalled

VDI Pending Login

Forensics Offline

Partial Registration

Earliest Activity The timestamp of the earliest tagged item in the incident timeline for the endpoint.

Latest Activity The timestamp of the last tagged item in the incident timeline for the endpoint.

IP Address List of associated IP addresses.

IPv6 Address List of associated IPv6 addresses.

First Seen Timestamp of first seen.

Last Seen Timestamp of last seen.

Endpoint Isolated Shows the status of endpoint isolation:

Pending Isolation Cancellation

Pending Isolation

Isolated

Not Isolated

Isolation Date The isolation date of the endpoint.

The following table for Malware shows all the items that have been tagged in the Process Execution or Persistence tables.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 361/1003
5/8/24, 9:18 AM PDF Export

Field Description

File Name The name of the artifact collected from the endpoint.

Path The executable path.

Tags Assigned tags of the artifact.

SHA256 The SHA256 value of the executable file.

Verdicts WildFire verdicts.

User User name of the person who ran the process.

Endpoint Name The name of endpoint.

Endpoint ID The unique ID of the endpoint.

Mitre ATT&CK Tactic The tactic selected during tagging.

Mitre ATT&CK Technique The technique selected during tagging.

Platform The operating system of the endpoint:

Windows

macOS

Linux

Android

Created The creation timestamp of the file accessed.

Accessed The accessed timestamp of the file accessed.

Modified The modified timestamp of the file accessed.

The following table forUsers shows any artifact data with a non-null user field that has been tagged.

Field Description

Username The username of the person who ran the process.

Domain The domain of the user's computer.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 362/1003
5/8/24, 9:18 AM PDF Export

Field Description

ID Indicates the operating system:

UID for macOS and Linux

SID for Windows

Earliest Activity Timestamp of earliest tagged item in Incident Timeline for the user.

Latest Activity Timestamp of last tagged item in Incident Timeline for the user.

The following table for Network Indicators shows the event logs with the IP addresses that have been tagged.

Field Description

Indicator The data field that was tagged.

Type IP Address

Hostname

URL

Endpoint Name The name of the endpoint.

Endpoint ID A unique ID of the endpoint.

Country Geolocation data for IP addresses.

Flag Flag of geolocated country.

Organization Organization associated with IP address.

The table shows for Data Access all the items that have been tagged in the File Access tables.

Field Description

Path Path of the accessed file.

User User name of person who accessed the file.

Endpoint Names The name of the endpoint.

Endpoint ID The unique ID of the endpoint.

Created The creation timestamp of the file accessed.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 363/1003
5/8/24, 9:18 AM PDF Export

Field Description

Accessed The accessed timestamp of the file accessed.

Modified The modified timestamp of the file accessed.

Size The size of the file.

4.8.4 | Export

Abstract

Select the export option to export data collection for long-term retention or offline analysis.

You can export the data collection for long-term retention or offline analysis.

From the collections page, choose a search item from a hunt collection or the endpoint from a triage collection and click the export icon ( ). For export of all
items, select the Export All option from the Exports button at the top of the Collections page.

NOTE:

You can export a collection more than once.

To view the status of the export, click the Exports button.

The Investigation Exports table shows the status of the requested exports for the selected collection. The compressed export data expires from the bucket after
30 days.

Field Description

Collection name Shows the name of the triage or hunt. For triage, the endpoint name of the triaged host is displayed.

Exported Shows the time when the exported package was created (compressed).

Exported by Shows the name of the user who requested the export.

Export expiration Shows the timestamp of when the bucket data (compressed data) will be deleted.

The timestamp changes to red after the timestamp and the last column shows Expired.

Status The progress indicates how many tables from the collections have been successfully exported to a bucket.

Download button Enables you to download the the compressed (zip) export of the collection.

Bin icon Enables you to delete the compressed export file.

4.9 | Response Actions

Abstract

As a result of an incident investigation, different response actions are possible.

After or during the investigation of malicious activity in your network, Cortex XSIAM offers various response actions that enable you to investigate the endpoint
and take immediate action to remediate it. For example, when you detect a compromised endpoint, you can isolate it from your network to prevent it from

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 364/1003
5/8/24, 9:18 AM PDF Export

communicating with any other internal or external device and thereby reducing an attacker’s mobility on your network. The available response actions are:

For response actions that rely on the Cortex XDR agent, the following table describes the supported platforms and minimal agent version. A dash (—) indicates
the setting is not supported.

Module Windows Mac Linux

Initiate a Live Terminal Session

Agent 6.1 and later Agent 7.0 and later Agent 7.0 and later
Initiates a remote connection to an
endpoint allowing you to investigate
and respond to security events on
endpoints. Using Live Terminal you
can navigate and manage files in the
file system, manage active processes,
and run the operating system or Python
commands.

Isolate an Endpoint
Agent 6.0 and later Agent 7.3 and later on macOS Agent 7.7 and later
Halts all network access on the
10.15.4 and later
endpoint except for traffic to Cortex
XSIAM to prevent a compromised
endpoint from communicating with any
other internal or external device.

Run Scripts on an Endpoint

Agent 7.1 and later Agent 7.1 and later Agent 7.1 and later
Allows executing Python 3.7 scripts on
your endpoints directly from Cortex
XSIAM , including out-of-the-box scripts
provided by Cortex XSIAM or your own
Python scripts and code snippets.

Remediate Changes from Malicious — —

Activity Agent 7.2 and later

Investigates suspicious causality

process chains and incidents on your
endpoints, and displays a list of
suggested actions to remediate
processes, files and registry keys on
your endpoint that were changed as a
result of malicious activity.

Search and Destroy Malicious Files —

Agent 7.2 and later Agent 7.3 and later on macOS
Searches for the presence of known
10.15.4 and later
and suspected malicious files on
endpoints and destroys the file from
endpoints where it exists.

CAUTION:

Response actions are not supported for Android endpoints.

4.9.1 | Initiate a Live Terminal Session

Abstract

Initiate a Live Terminal session from the Cortex XSIAM management console to control the endpoint remotely.

To investigate and respond to security events on endpoints, you can use the Live Terminal to initiate a remote connection to an endpoint. The Cortex XDR agent
facilitates the connection using a remote procedure call. Live Terminal enables you to manage remote endpoints. Investigative and response actions that you

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 365/1003
5/8/24, 9:18 AM PDF Export

can perform include the ability to navigate and manage files in the file system, manage active processes, run the operating system or Python commands,
download files of up to 200 MB, and upload files of up to 40 MB.

Live Terminal is supported for endpoints that meet the following requirements:

Operating System Requirements

Windows Traps 6.1 or a later release

Windows 7 SP1 or a later release

Windows update patch for WinCRT (KB 2999226)—To verify the Hotfixes that are installed on the
endpoint, run the systeminfo command from a command prompt.

Endpoint activity reported within the last 90 minutes (as identified by the Last Seen time stamp in the
endpoint details).

Mac Cortex XDR agent 7.0 or a later release

macOS 10.12 or a later release

Endpoint activity reported within the last 90 minutes (as identified by the Last Seen time stamp in the
endpoint details).

Linux Cortex XDR agent 7.0 or a later release

Any Linux supported version as listed in Where Can I Install the Cortex XDR Agent? in the Palo Alto
Networks Compatibility Matrix.

Endpoint activity reported within the last 90 minutes (as identified by the Last Seen time stamp in the
endpoint details).

If the endpoint supports the necessary requirements, you can initiate a Live Terminal session from the Endpoints page.

NOTE:

You can run PowerShell 5.0 or a later release on Live Terminal of Windows.

You can also initiate a Live Terminal as a response action to a security event. If the endpoint is inactive or does not meet the requirements, the option is
disabled.

After you terminate the Live Terminal session, you also have the option to save a log of the session activity. All logged actions from the Live Terminal session are
available for download as a text file report when you close the live terminal session.

You can fine tune the Live Terminal session visibility on the endpoint by adjusting the User Interface options in your Agent Settings Profile.

1. Start the session.

From a security event or endpoint details, select Incident Response → Response → Live Terminal. It can take the Cortex XDR agent a few minutes to
facilitate the connection.

2. Use the Live Terminal to investigate and take action on the endpoint.

3. When you are done, Disconnect the Live Terminal session.

You can optionally save a session report containing all activities you performed during the session.

The following example displays a sample session report:

Live Terminal Session Summary

Initiated by user [email protected] on target TrapsClient1 at Jun 27th 2019 14:17:45

Jun 27th 2019 13:56:13 Live Terminal session has started [success]
Jun 27th 2019 14:00:45 Kill process calc.exe (4920) [success]
Jun 27th 2019 14:11:46 Live Terminal session end request [success]
Jun 27th 2019 14:11:47 Live Terminal session has ended [success]

No artifacts marked as interesting

Manage Processes

Abstract

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 366/1003
5/8/24, 9:18 AM PDF Export

Monitor processes running on the endpoint.

From the Live Terminal you can monitor processes running on the endpoint. The Task Manager displays the task attributes, owner, and resources used. If you
discover an anomalous process while investigating the cause of a security event, you can take immediate action to terminate the process or the whole process
tree, and block processes from running.

1. From the Live Terminal session, open the Task Manager to navigate the active processes on the endpoint.

You can toggle between a sorted list of processes and the default process tree view ( ). You can also export the list of processes and process details to
a comma-separated values file.

If the process is known as malware, the row displays a red indicator and identifies the file using a malware attribute.

2. To take action on a process, right-click the process:

Terminate process—Terminate the process or the entire process tree.

Suspend process—To stop an attack while investigating the cause, you can suspend a process or process tree without killing it entirely.

Resume process—Resume a suspended process.

Open in VirusTotal—VirusTotal aggregates known malware from antivirus products and online scan engines. You can scan a file using the VirusTotal
scan service to check for false positives or verify suspected malware.

Get WildFire verdict—WildFire evaluates the file hash signature to compare it against known threats.

Get file hash—Obtain the SHA256 hash value of the process.

Download Binary—Download the file binary to your local host for further investigation and analysis. You can download files up to 200MB in size.

Mark as Interesting—Add an Interesting tag to a process to easily locate the process in the session report after you end the session.

Remove from Interesting—If no threats are found, you can remove the Interesting tag.

Copy Value—Copy the cell value to your clipboard.

3. Select Disconnect to end the Live Terminal session.

Choose whether to save the remote session report including files and tasks marked as interesting. Administrator actions are not saved to the endpoint.

Manage Files

Abstract

Manage files on the remote endpoint.

The File Explorer enables you to navigate the file system on the remote endpoint and take remedial action to:

Create, manage (move or delete), and download files, folders, and drives, including connected external drives and devices such as USB drives and CD-
ROM.

NOTE:

Network drives are not supported.

View file attributes, creation, and last modified dates, and the file owner.

Investigate files for malicious content.

To navigate and manage files on a remote endpoint:

1. From the Live Terminal session, open the File Explorer to navigate the file system on the endpoint.

2. Navigate the file directory on the endpoint and manage files.

To locate a specific file, you can:

Search for any filename rows on the screen from the search bar.

Double-click a folder to explore its contents.

3. Perform basic management actions on a file.

View file attributes

Rename files and folders

Export the table as a CSV file

Move and delete files and folders

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 367/1003
5/8/24, 9:18 AM PDF Export

4. Investigate files for malware.

Right-click a file to take investigative action. You can take the following actions:

Open in VirusTotal—VirusTotal aggregates known malware from antivirus products and online scan engines. You can scan a file using the VirusTotal
scan service to check for false positives or verify suspected malware.

Get WildFire verdict—WildFire evaluates the file hash signature to compare it against known threats.

Get file hash—Obtain the SHA256 hash value of the file.

Download Binary—Download the file binary to your local host for further investigation and analysis. You can download files up to 200MB in size.

Mark as Interesting—Add an Interesting tag to any file or directory to easily locate the file. The files you tag are recorded in the session report to
help you locate them after you end the session.

Remove from Interesting—If no threats are found, you can remove the Interesting tag.

Copy Value—Copies the cell value to your clipboard.

5. Select Disconnect to end the live terminal session.

Choose whether to save the live terminal session report including files and tasks marked as interesting. Administrator actions are not saved to the
endpoint.

Run Operating System Commands

Abstract

Run operating system commands on a remote endpoint.

The Live Terminal provides a command-line interface from which you can run operating system commands on a remote endpoint. Each command runs
independently and is not persistent. To chain multiple commands together so as to perform them in one action, use && to join commands. For example:

cd c:\windows\temp\ && <command1> && <command2>

NOTE:

On Windows endpoints, you cannot run GUI-based cmd commands like winver or appwiz.cpl

1. From the Live Terminal session, select Command Line.

2. Run commands to manage the endpoint.

Examples include file management or launching batch files. You can enter or paste the commands, or you can upload a script. After you are done, you
can save the command session output to a file.

3. When you are done, Disconnect the Live Terminal session.

Choose whether to save the live terminal session report including files and tasks marked as interesting. Administrator actions are not saved to the
endpoint.

Run Python Commands and Scripts

Abstract

Run Python commands and scripts on a remote endpoint.

The Live Terminal provides a Python command line interface that you can use to run Python commands and scripts.

The Python command interpreter uses Unix command syntax and supports Python 3 with standard Python libraries. To issue Python commands or scripts on
the endpoint, follow these steps:

1. From the Live Terminal session, select Python to start the python command interpreter on the remote endpoint.

2. Run Python commands or scripts as desired.

You can enter or paste the commands, or you can upload a script. After you are done, you can save the command session output to a file.

3. When you are done, Disconnect the Live Terminal session.

Choose whether to save the live terminal session report including files and tasks marked as interesting. Administrator actions are not saved to the
endpoint.

Disable Live Terminal Sessions

Abstract

You can disable Live Terminal remote sessions on an endpoint during the agent installation.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 368/1003
5/8/24, 9:18 AM PDF Export

If you want to prevent Cortex XSIAM from initiating Live Terminal remote sessions on an endpoint running the Cortex XDR agent, you can disable this capability
during agent installation or later on through Cortex XSIAM Endpoint Administration. Disabling script execution is irreversible. If you later want to re-enable this
capability on the endpoint, you must re-install the Cortex XDR agent.

NOTE:

Disabling Live Terminal does not take effect on sessions that are in progress.

4.9.2 | Isolate an Endpoint

Abstract

In the event that an endpoint is compromised, you can immediately isolate it to reduce an attacker’s mobility.

When you isolate an endpoint, you halt all network access on the endpoint except for traffic to Cortex XSIAM. This can prevent a compromised endpoint from
communicating with other endpoints thereby reducing an attacker’s mobility on your network. After the agent receives the instruction to isolate the endpoint and
carries out the action, Cortex XSIAM shows an Isolated check-in status. To ensure an endpoint remains in isolation, agent upgrades are not available for
isolated endpoints.

NOTE:

IP-based file storage protocol traffic will also be blocked. This might affect endpoint functionality if the endpoint uses such mounts.

Network isolation is supported for endpoints that meet the following requirements:

Operating System Prerequisites

Windows Agent 6.0 or later

(VDI) Network isolation allow list in the Agent Settings Profile is configured to ensure VDI
sessions remain uninterrupted.

Mac Agent 7.3 or later

macOS 10.15.4 or later

Cortex XSIAM Network extension is enabled on the endpoint.

Network isolation on Mac endpoints does not terminate active connections that were initiated before the
agent was installed on the endpoint.

Linux iptables and ip6tables

Agent 7.7 or later

Linux kernel with the following enabled:

CONFIG_NETFILTER

CONFIG_IP_NF_IPTABLES

CONFIG_IP_NF_MATCH_OWNER

Network isolation allow list configured in the Agent Settings Profile

Network isolation on Linux endpoints is based on the defined IP addresses and ports.

1. Initiate an action to isolate an endpoint.

Go to Incident Response → Response → Action Center → + New Action and select Isolate.

You can also initiate the action (for one or more endpoints) from the Isolation page of the Action Center or from Endpoints → Endpoint Management →
Endpoint Administration.

2. Select Isolate.

3. Enter a Comment to provide additional background or other information that explains why you isolated the endpoint.

After you isolate an endpoint, Cortex XSIAM displays the Isolation Comment on the Action Center → Isolation. If needed, you can edit the comment from
the right-click pivot menu.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 369/1003
5/8/24, 9:18 AM PDF Export

4. Click Next.

5. Select the target endpoint that you want to isolate from your network.

TIP:

If needed, Filter the list of endpoints. To learn how to use filters, see Filter Page Results.

6. Click Next.

7. Review the action summary and click Done when finished.

In the next heartbeat, the agent will receive the isolation request from Cortex XSIAM.

8. To track the status of an isolation action, select Incident Response → Response → Action Center → Currently Applied Actions → Endpoint Isolation.

If after initiating an isolation action, you want to cancel, right-click the action and select Cancel for pending endpoint. You can cancel the isolation action
only if the endpoint is still in Pending status and has not been isolated yet.

9. After you remediate the endpoint, cancel endpoint isolation to resume normal communication.

You can cancel isolation from the Actions Center (Isolation page) or from Endpoints → Endpoint Management → Endpoint Administration. From either
place right-click the endpoint and select Endpoint Control → Cancel Endpoint Isolation.
NOTE:

If file system operations become unresponsive during isolation, such as being unable to list folder content, unmount the mounted network shares.

4.9.3 | Pause Endpoint Protection

Abstract

Disable the Cortex XDR agent protection capabilities on an endpoint.

As of agent 7.7 and above, you can pause the agent protection capabilities on one or more endpoints while maintaining connectivity with Cortex XSIAM. By only
pausing the protection and retaining connectivity, the agent will run with all the profiles disabled, but continue to send data and take actions from the server. After
you are ready, you can resume the endpoint protection.

NOTE:

Pausing your endpoint protection modules leaves your machines exposed to risks.

To pause one or more endpoint protections:

1. Navigate to Endpoints → All Endpoints.

2. In the All Endpoints page, select the endpoints you want to pause protection on, right-click and select Endpoint Control → Pause Endpoint Protection.

3. Verify the endpoints, add an optional comment that appears in the Management Audit log, and Pause the protection.

Endpoints that have been paused appear with a pause icon in the Endpoint Name field, and depending on the action progress, one of the following
statuses in Manual Protection Pause field:

Protection Active

Pending Pause

Protection Paused

Pending Activation

4. When you are ready to resume protection, select the endpoints, right-click and select Endpoint Control → Resume Endpoint Protection and Resume
protection on the listed endpoints.

The All Endpoint table fields are updated accordingly.

5. (Optional) Track your pause and resume endpoint protection actions.

Navigate to Incident Response → Response → Action Center and locate Action Type Pause Endpoint Protection or Resume Endpoint Protection.

4.9.4 | Remediate Changes from Malicious Activity

Abstract

You can obtain action remediation suggestions from Cortex XSIAM about malicious causality chains that have been detected.

When investigating suspicious incidents and causality chains you often need to restore and revert changes made to your endpoints as result of a malicious
activity. To avoid manually searching for the affected files and registry keys on your endpoints, you can request Cortex XSIAM for remediation suggestions.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 370/1003
5/8/24, 9:18 AM PDF Export

Cortex XSIAM investigates suspicious causality process chains and incidents on your endpoints and displays a list of suggested actions to remediate processes,
files, and registry keys on your endpoint.

To initiate remediation suggestions, you must meet the following requirements:

Cortex XSIAM Pro per Endpoint license

An App Administrator, Privileged Responder, or Privileged Security Admin role permissions which include the remediation permissions

EDR data collection enabled

Agent version 7.2 and above on Windows endpoints

1. Initiate a remediation analysis.

You can initiate a remediation suggestions analysis from either of the following places:

In the Incident View, navigate to Actions → Remediation Suggestions.

NOTE:

Endpoints that are part of the incident view and do not meet the required criteria are excluded from the remediation analysis.

In the Causality View, either:

Right-click any process node involved in the causality chain and select Remediation Suggestion.

Navigate to Actions → Remediation Suggestions.

Analysis can take a few minutes. If desired, you can minimize the analysis pop-up while navigating to other pages.

2. Review the remediation suggestion summary and details.

Field Description

ORIGINAL EVENT DESCRIPTION Summary of the initial event that triggered the malicious causality chain.

ORIGINAL EVENT TIMESTAMP Timestamp of the initial event that triggered the malicious causality chain.

ENDPOINT NAME Hostname of the endpoint.

IP ADDRESS The IP address associated with the endpoint.

ENDPOINT STATUS Connectivity status of the endpoint. Can be either:

Connected

Disconnected

Uninstalled

Connection lost

DOMAIN Domain or workgroup to which the endpoint belongs, if applicable.

ENDPOINT ID Unique ID assigned by Cortex XSIAM that identifies the endpoint.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 371/1003
5/8/24, 9:18 AM PDF Export

Field Description

SUGGESTED REMEDIATION Action suggested by the Cortex XSIAM remediation scan to apply to the causality
chain process:

Delete File

Restore File

Rename File

Delete Registry Value

Restore Registry Value

Terminate Process—Available when selecting Remediation Suggestions for a

node in the Causality View.

Terminate Causality—Terminate the entire causality chain of processes that

have been executed under the process tree of the listed Causality Group
Owner (GCO) process name.

Manual Remediation—Requires you to take manual action to revert or restore.

SUGGESTED REMEDIATION DESCRIPTION Summary of the remediation suggestion to apply to the file or registry.

REMEDIATION STATUS Status of the applied remediation:

Pending

In Progress

Failed

Completed Successfully

Partial Success

REMEDIATION DATE Displays the timestamp of when all of the endpoint artifacts were remediated. If
missing a successful remediation, the field will not display the timestamp.

3. Select one or more Original Event Descriptions and right-click to Remediate.

4. Track your remediation process.

a. Navigate to Response → Action Center → All Actions.

b. In the Action Type field, locate your remediation process.

c. Right-click Additional data to open the Detailed Results window.

4.9.5 | Run Scripts on an Endpoint

Abstract

Execute Python scripts from Cortex XSIAM directly on the endpoint to perform actions, retrieve data, and retrieve files.

For enhanced endpoint remediation and endpoint management, you can run Python 3.7 scripts on your endpoints directly from Cortex XSIAM . For commonly
used actions, Cortex XSIAM provides out-of-the-box scripts. You can also write and upload your own Python scripts and code snippets into Cortex XSIAM for
custom actions. Cortex XSIAM enables you to manage, run, and track the script execution on the endpoints, as well as store and display the execution results
per endpoint.

The following are prerequisites to executing scripts on your endpoints:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 372/1003
5/8/24, 9:18 AM PDF Export

Cortex XSIAM Pro Per Endpoint license

Endpoints running the Agent v7.1 and later. Since the agent uses its built-in capabilities and many available Python modules to execute the scripts, no
additional setup is required on the endpoint.

Role in the hub with the following permissions to run and configure scripts:

Run Standard scripts

Run High-risk scripts

Script configuration (required to upload a new script, run a snippet, and edit an existing script)

Scripts (required to view the Scripts Library and the script execution results)

NOTE:

Running snippets requires both Run High-risk scripts and Script configuration permissions. Additionally, all scripts are executed as System User on the
endpoint.

Manage All Scripts in the Scripts Library

Abstract

Manage the default and additional optional fields in the Scripts Library.

All your scripts are available in the Action Center → Scripts Library, including out-of-the-box scripts and custom scripts that you uploaded. From the Scripts
Library, you can view the script code and meta data.

The following table describes both the default and additional optional fields that you can view in the Scripts Library per script. The fields are in alphabetical order.

Field Description

Compatible OS The operating systems the script is compatible with.

Created By Name of the user who created the script. For out-of-the-box scripts, the user
name is Palo Alto Networks.

Description The script description is an optional field that can be completed when creating,
uploading, or editing a script.

Id Unique ID assigned by Cortex XSIAM that identifies the script.

Modification Date Last date and time in which the script or its attributes were edited in Cortex
XSIAM .

Name The script name is a mandatory field that can be completed when creating,
uploading, or editing a script.

Outcome High-risk—Scripts that may potentially harm the endpoint.

Standard—Scripts that do not have a harmful impact on the endpoint.

Script FileSHA256 The SHA256 of the code file.

From the Scripts Library, you can perform the following additional actions:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 373/1003
5/8/24, 9:18 AM PDF Export

Download script—To see exactly what the script does, right-click and Download the Python code file locally.

View / Download definitions file—To view or download the script meta-data, right-click the script and select the relevant option.

Run—To run the selected script, right-click and select Run. Cortex XSIAM redirects you to the Action Center with the details of this script already
populating the new action fields.

Edit—To edit the script code or meta-data, right-click and Edit. This option is not available for pre-canned scripts provided by Palo Alto Networks.

By default, Palo Alto Networks provides you with a variety of out-of-the-box scripts for your use. You can view the script, download the script code and meta-
data, and duplicate the script, however you cannot edit the code or definitions of out-of-the-box scripts.

The following table lists the out-of-the-box scripts provided by Palo Alto Networks, in alphabetical order. New scripts are continuously uploaded into Cortex
XSIAM through content updates, and are labeled New for a period of three days.

Script Name Description

delete_file Delete a file on the endpoint according to the full path.

file_exists Search for a specific file on the endpoint according to the full path.

get_process_list List CPU and memory for all processes running on the endpoint.

list_directories List all the directories under a specific path on the endpoint, You can limit the
number of levels you want to list.

process_kill_cpu Set a minimum CPU value and kill all process on the endpoint that are using
higher CPU.

process_kill_mem Set a minimum RAM usage in bytes and kill all process on the endpoint that are
using higher private memory.

process_kill_name Kill all processes by a given name.

*registry_delete Delete a Registry key or value on the endpoint.

(Windows)

*registry_get Retrieve a Registry value from the endpoint.

(Windows)

*registry_set Set a Registry value from the endpoint.

(Windows)

NOTE:

*Since all scripts are running under System context, you cannot perform any Registry operations on user-specific hives (HKEY_CURRENT_USER of a
specific user).

Upload Your Scripts

Abstract

How to create and upload scripts.

You can write and upload additional scripts to the Scripts Library.

To upload a new script:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 374/1003
5/8/24, 9:18 AM PDF Export

1. From Action Center → Scripts Library select +New Script.

Drag and drop your script file, or browse and select it. During the upload, Cortex XSIAM parses your script to ensure you are using only supported Python
modules. Click Supported Modules if you want to view the supported modules list. If your script is using unsupported Python modules, or if your script is
not using proper indentation, you will be required to fix it. You can use the editor to update your script directly in Cortex XSIAM.

2. Add meta-data to your script.

You can fill-in the fields manually, and also upload an existing definitions file in the supported format to automatically fill-in some or all of the definitions. To
view the manifest format and create your own, see Creating a Script Manifest.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 375/1003
5/8/24, 9:18 AM PDF Export

General—The general script definitions include: name and description, risk categorization, supported operating systems, and timeout in seconds.

Input—Set the starting execution point of your script code. To execute the script line by line, select Just run. Alternatively, to set a specific function in
the code as the entry point, select Run by entry point. Select the function from the list, and specify for each function parameter its type.

Output—If your script returns an output, Cortex XSIAM displays that information in the script results table.

Single parameter—If the script returns a single parameter, select the Output type from the list and the output will be displayed as is. To
detect the type automatically, select Auto Detect.

Dictionary—If the script returns more than a single value, select Dictionary from the Output type list. By default, Cortex XSIAM displays in the
script results table the dictionary value as is. To improve the script results table display and be able to filter according to the returned value,
you can assign a user friendly name and type to some or all of your dictionary keys, and Cortex XSIAM will use that in the results table
instead.

To retrieve files from the endpoint, add to the dictionary the files_to_get key to include an array of paths from which files on the endpoint will be
retrieved from the endpoint.

3. When you are done, Create the new script.

The new script is uploaded to the Scripts Library.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 376/1003
5/8/24, 9:18 AM PDF Export

Creating a Script Manifest

The script manifest file you upload into Cortex XSIAM has to be a single line textual file, in the exact format explained below. If your file is structured differently,
the manifest validation will fail and you will be required to fix the file.

NOTE:

For the purpose of this example, we are showing each parameter in a new line. However, when you create your file, you must remove any \n or \t
characters.

This is an example of the manifest file structure and content:

{
"name":"script name",
"description":"script description",
"outcome":"High Risk|Standard",
"platform":"Windows,macOS,Linux",
"timeout":600,
"entry_point":"entry_point_name",
"entry_point_definition":{
"input_params":[
{"name":"registry_hkey","type":"string"},
{"name":"registry_key_path","type":"number"},
{"name":"registry_value","type":"number"}],
"output_params":{"type":"JSON","value":[
{"name":"output_auto_detect","friendly_name":"name1","type":"auto_detect"},
{"name":"output_boolean","friendly_name":"name2","type":"boolean"},
{"name":"output_number","friendly_name":"name3","type":"number},
{"name":"output_string","friendly_name":"name4","type":"string"},
{"name":"output_ip","friendly_name":"name5","type":"ip"}]
}
}

NOTE:

Always use lower case for variable names.

1. Type the script name and description.

You can use letters and digits. Avoid the use of special characters.

2. Categorize the script.

If a script is potentially harmful, set it as High— Risk to limit the user roles that can run it. Otherwise, set it as Standard.

3. Assign the platform.

Enter the name of the operating system this script supports. The options are Windows, macOS, and Linux. If you need to define more than one, use a
comma as a separator.

4. Set the script timeout.

Enter the number of seconds after which Cortex XSIAM agent halts the script execution on the endpoint.

5. Configure the script input and output.

To Run by entry point, you must specify the entry point name, and all input and output definitions.

The available parameter types are:

auto_detect

boolean

number

string

ip

number_list

string_list

ip_list

To set the script to Just run, leave both Entry_point and Entry_point_definitions empty:

{
"name":"scrpit name",
"description":"script description",
"outcome":"High Risk|Standard",
"platform":"Windows,macOS,Linux",
"timeout":600,
"entry_point":"",

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 377/1003
5/8/24, 9:18 AM PDF Export

"entry_point_definition":{}
}

Run a Script on Your Endpoints

Abstract

Run scripts on your endpoints to perform actions.

Follow this high-level workflow to run scripts on your endpoints that perform actions, or retrieve files and data from the endpoint back to Cortex XSIAM.

1. Initiate a new action to run a script.

From Action Center → +New Action, select Run Script.

2. Select an existing script or add a code snippet.

a. To run an existing script, start typing the script name or description in the search field, or scroll down and select it from the list. Set the script timeout
in seconds and any other script parameters, if they exist. Click Next

b. Alternatively, you can insert a Code Snippet. Unlike scripts, snippets are not saved in the Cortex XSIAM Scripts Library and cannot receive input or
output definitions. Write you snippet in the editor, fill-in the timeout in seconds, and click Next

3. Select the target endpoints.

Select the target endpoints on which to execute the script. When you’re done, click Next.

4. Review the summary and run script.

Cortex XSIAM displays the summary of the script execution action. If all the details are correct, Run the script and proceed to ???. Alternatively, to track
the script execution progress on all endpoints and view the results in real-time, Run Scripts in Interactive Mode.

Run Scripts in Interactive Mode

When you need to run several scripts on the same target scope of endpoints, or when you want to view and inspect the results of those scripts immediately and
interactively, you can run your scripts in Interactive Mode. You can also initiate interactive mode for an endpoint directly from Endpoints Management. In this
mode, Cortex XSIAM enables you to track the execution progress on all endpoints in real-time, run more scripts or code snippets as you go, and view the results
of these scripts all in one place.

In Interactive Mode, Cortex XSIAM displays general information that includes the scope of target endpoints and a list of all the scripts that are being executed in
this session. For each script on the executed scripts list, you can view the following:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 378/1003
5/8/24, 9:18 AM PDF Export

The script name, date and time the script execution action was initiated, and a list of input parameters.

A progress bar that indicates in real-time the number of endpoints for which the script execution is In Progress, Failed, or Completed. When you hover
over the progress bar, you can drill-down for more information about the different sub-statuses included in each group. Similarly, you can also view this
information on the scripts list to the left in the form of a pie chart that is dynamically updated per script as it is being executed.

NOTE:

Cortex XSIAM does not include disconnected endpoints in the visualization of the script execution progress bar or pie chart. If a disconnected endpoint
later gets connected, Cortex XSIAM will execute the script on that endpoint and the graphic indicators will change accordingly to reflect the additional
run and its status.

Dynamic script results that are continuously updated throughout the script execution progress. Cortex XSIAM lists the results, and graphically aggregates
results only if they have a small variety of values. When both views are available, you can switch between them.

While in Interactive Mode, you can continuously execute more scripts and add code snippets that will be immediately executed on the target endpoints scope.
Cortex XSIAM logs all the scripts and code snippets you execute in Interactive Mode, and you can later view them in the Action Center.

To add another script, select the script from the Cortex XSIAM scripts library, or start typing a Code Snippet. Set the script timeout and input parameters
as necessary, and Run when you are done. The script is added to the executed scripts list and its runtime data is immediately displayed on screen.

Track Script Execution and View Results

Abstract

After running a script, refer to the action center to see the script execution action.

After you run a script, you see the script execution action in the Action Center.

From the Action Center, you can:

Track Script Execution Status

All script execution actions are logged in the Action Center. The Status indicates the action progress, which includes the general action status and the
breakdown by endpoints included in the action. The following table lists the possible status of a script execution action for each endpoint, in alphabetical order:

Status Description

Aborted The script execution action was aborted after it was already In Progress on the
endpoint.

Canceled The script execution action was canceled from Cortex XSIAM before the agent
pulled the request from the server.

Completed Successfully The script was executed successfully on the endpoint with no exceptions.

Expired Script execution actions expire after four days. After an action expires, the
status of any remaining Pending actions on endpoints changes to Expired and
these endpoints will not receive the action.

Failed A script can fail due to these reasons:

The agent failed to execute the script.

Exceptions occurred during the script execution.

To understand why the script execution failed, see ???.

In Progress The agent pulled the script execution request.

Pending The agent has not yet pulled the script execution request from the Cortex
XSIAM server.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 379/1003
5/8/24, 9:18 AM PDF Export

Status Description

Pending Abort The agent is in the process of executing the script, and has not pulled the abort
request from the Cortex XSIAM server yet.

Timeout The script execution reached its configured time out and the agent stopped the
execution on the endpoint.

Cancel or Abort Script Execution

Depending on the current status of the script execution action on the target endpoints, you can cancel or abort the action for Pending and In Progress actions:

When the script execution action is Pending, the agent has not pulled the request yet from Cortex XSIAM . When you cancel a pending action, the Cortex
XSIAM server pulls back the pending request and updates the action status as Canceled. To cancel the action for all pending endpoints, go to the Action
Center, right-click the action and Cancel for pending endpoints. Alternatively, to cancel a pending action for specific endpoints only, go to Action Center →
Additional data → Detailed Results, right-click the endpoint(s) and Cancel pending action

When the script execution action is In Progress, the agent has begun running the script on the endpoint. When you abort an in progress action, the agent
halts the script execution on the endpoint and updates the action status as Aborted. To abort the action for all In Progress endpoints and cancel the action
for any Pending endpoints, go to the Action Center, right-click the action and Abort and cancel execution. Alternatively, to abort an in progress action for
specific endpoints only, go to Action Center → Additional data → Detailed Results, right-click the endpoint(s) and Abort for endpoint in progress

View Script Execution Results

Cortex XSIAM logs all script execution actions, including the script results and specific parameters used in the run. To view the full details about the run,
including returned values, right-click the script and select Additional data.

The script results are divided into two sections. On the upper bar, Cortex XSIAM displays the script meta-data that includes the script name and entry point, the
script execution action status, the parameter values used in this run and the target endpoints scope. You can also download the exact code used in this run as a
py file.

In the main view, Cortex XSIAM displays the script execution results in two formats:

Aggregated results—A visualization of the script results. Cortex XSIAM automatically aggregates only results that have a small variety of values. To see
how many of the script results were aggregated successfully, see the counts on the toggle (for example, aggregated results 4/5). You can filter the results
to adjust the endpoints considered in the aggregation. You can also generate a PDF report of the aggregated results view.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 380/1003
5/8/24, 9:18 AM PDF Export

Main results view—A detailed table listing all target endpoints and their details.

In addition to the endpoint details (name, IP, domain, etc), the following table describes both the default and additional optional fields that you can view per
endpoint. The fields are in alphabetical order.

Field Description

*Returned values If your script returned values, the values are also listed in the additional data
table according to your script output definitions.

Execution timestamp The date and time the agent started the script execution on the endpoint. If
the execution has not started yet, this field is empty.

Failed files The number of files the agent failed to retrieve from the endpoint.

Retention date The date after which the retrieved file will no longer be available for
download in Cortex XSIAM . The value is 90 days from the execution date.

Retrieved files The number of files the Cortex XSIAM successfully retrieved from the
endpoint.

Status See the list of statuses and their descriptions in Track Script Execution
Status.

Standard output The returned stdout

For each endpoint, you can right-click and download the script stdout, download retrieved files if there are any, and view returned exceptions if there are
any. You can also Export to file to download the detailed results table in TSV format.

Open Script Interactive Mode

In Run Scripts in Interactive Mode, Cortex XSIAM enables you to dynamically track the script execution progress on all target endpoints and view the results as
they are being received in real-time. Additionally, you can start executing more scripts on the same scope of target endpoints.

To initiate Interactive Mode for an already running script:

From the Action Center, right-click the execution action of the relevant script and select Open in interactive mode.

Rerun a Script

Cortex XSIAM allows you to select a script execution action and rerun it. When you rerun a script, Cortex XSIAM uses the same parameter values, target
endpoints, and defined timeout that were defined for the previous run. However, if the target endpoints in the original run were defined using a filter, then that
filter will be recalculated when you rerun the script. Cortex XSIAM will use the current version of the script. If since the previous run the script has been deleted,
or the supported operating system definition has been modified, you will not be able to rerun the script.

1. From the Action Center, right-click the script you want to rerun and select Rerun.

You are redirected to the final summary stage of the script execution action.

2. Run the script.

To run the script with the same parameters and on the same target endpoints as the previous run, click Done. To change any of the previous run
definitions, navigate through the wizard and make the necessary changes. Then, click Done. The script execution action is added to the Action Center.

Troubleshoot Script Execution

Abstract

How to check why a script returned a failed execution status.

To understand why a script returned Failed execution status, you can do the following:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 381/1003
5/8/24, 9:18 AM PDF Export

1. Check script exceptions—If the script generated exceptions, you can view them to learn why the script execution failed. From the Action Center, right-
click the Failed script and select Additional data. In the Script Results table, right-click an endpoint for which the script execution failed and select View
exceptions. The agent executes scripts on Windows endpoints as a SYSTEM user, and on Mac and Linux endpoints as a root user. These context
differences could cause differences in behavior, for instance when using environment variables.

2. Validate custom scripts—When a custom script you uploaded failed and the reason the script failed is still unclear from the exceptions, or if the script did
not generate any exceptions, try to identify whether it failed due to an error in Cortex XSIAM or due to an error in the script. To identify the error source,
execute the script without the agent on the same endpoint with regular Python 3.7 installation. If the script execution is unsuccessful, you should fix your
script. Otherwise, if the script was executed successfully with no errors, contact Customer Support.

Disable Script Execution

Abstract

Disable a script execution from running on an agent.

If you want to prevent Cortex XSIAM from running scripts on an agent, you can disable this capability during agent installation or later on through Cortex XSIAM
Endpoint Administration. Disabling script execution is irreversible. If you later want to reenable this capability on the endpoint, you must reinstall the agent. See
the Cortex XDR Agent Administrator’s Guide for more information.

NOTE:

Disabling Script Execution does not take effect on scripts that are in progress.

4.9.6 | Search and Destroy Malicious Files

Abstract

Cortex XSIAM enables you to effectively hunt down any identified malicious file that may exist on any of your endpoints.

To take immediate action on known and suspected malicious files, you can search and destroy the files. After you identify the presence of a malicious file, you
can immediately destroy the file from any or all endpoints on which the file exists.

The agent builds a local database on the endpoint with a list of all the files, including their path, hash, and additional metadata. Depending on the number of files
and disk size of each endpoint, it can take a few days for Cortex XSIAM to complete the initial endpoint scan and populate the files database. You cannot search
an endpoint until the initial scan is complete and all file hashes are calculated.

After the initial scan is complete and the agent retains a snapshot of the endpoint files inventory, the agent maintains the files database by initiating periodic
scans and closely monitoring all actions performed on the files.

You can search for specific files according to the file hash, the file full path, or a partial path using regex parameters from the Action Center or the Query Builder.
After you find the file, you can quickly select it in the search results and destroy the file by hash or by path. You can also destroy a file from the Action Center,
without performing a search, if you know the path or hash. When you destroy a file by hash, all the file instances on the endpoint are removed.

You can validate a hash against VirusTotal and WildFire to provide additional context before initializing the File Destroy action.

NOTE:

The Cortex XSIAM agent does not include the following information in the local files inventory.

Information about files that existed on the endpoint and were deleted before the Cortex XSIAM agent was installed.

Information about files where the file size exceeds the maximum file size for hash calculations that are pre-configured in Cortex XSIAM .

If the Agent Settings Profile on the endpoint is configured to monitor common file types only, then the local files inventory includes information about
these file types only. You cannot search or destroy file types that are not included in the list of common file types.

The following are prerequisites to enable Cortex XSIAM to search and destroy files on your endpoints:

Requirement Description

Licenses and Add-ons Provision an active Cortex XSIAM Pro per Endpoint license.

Ensure the Hosts Endpoint license is enabled on your tenant.

Ensure that the Host Insights add-on is enabled on your tenant.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 382/1003
5/8/24, 9:18 AM PDF Export

Requirement Description

Supported Platforms Windows— Cortex XSIAM agent 7.2 or a later release. If you plan to
enable Search and Destroy on VDI sessions, you must perform the initial
scan on the Golden Image.

Mac— Cortex XSIAM agent 7.3 or a later release running on macOS

10.15.4 or later release.

Linux—Not supported.

Setup and Permissions Ensure File Search and Destroy is enabled for your Cortex XSIAM agent.

Ensure your Cortex XSIAM role has File search and Destroy files
permissions.

Search a File

You can search for files on the endpoint by file hash or file path. The search returns all instances of this file on the endpoint. You can then immediately proceed
to destroy all the file instances on the endpoint or upload the file to Cortex XSIAM for further investigation.

You can search for a file using the Query Builder or XQL Search, or use the Action Center wizard as described in the following workflow.

1. From the Action Center select +New Action → File Search.

2. Configure the search method:

To search by hash, enter the file SHA256 value. When you search by hash, you can also search for deleted instances of this file on the endpoint.

To search by path, enter the specific path for the file on the endpoint or specify the path using wildcards. When you provide a partial path or partial
file name using *, the search will return all the results that match the partial expression. Note the following limitations:

The file path must begin with a drive name, for example: c:\.

You must specify the exact path folder hierarchy, for example c:\users\user\file.exe. You must specify the exact path folder hierarchy
also when you replace folder names with wildcards, by using a wildcard for each folder in the hierarchy. For example, c:\*\*\file.exe.

Click Next.

3. Select the target endpoints.

Select the target endpoints on which you want to search for the file. Cortex XSIAM displays only endpoints eligible for file search. When you’re done, click
Next.

4. Review the summary and initiate the search.

Cortex XSIAM displays the summary of the file search action. If you need to change your settings, go Back. If all the details are correct, click Run. The File
search action is added to the Action Center.

5. Review the search results.

In the Action Center, you can monitor the action progress in real-time and view the search results for all target endpoints. For a detailed view of the results,
right-click the action and select Additional data. Cortex XSIAM displays the search criteria, timestamp, and real-time status of the action on the target
endpoints. You can:

View results by file (default view)— Cortex XSIAM displays the first 100 instances of the file from every endpoint. Each search result includes
details about the endpoint (such as endpoint status, name, IP address, and operating system) and details about the file instance (such as full file
name and path, hash values, and creation and modification dates).

View the results by endpoint—For each endpoint in the search results, Cortex XSIAM displays details about the endpoint (such as endpoint
status, name, IP address, and operating system), the search action status, and details about the file (whether it exists on the endpoint or not, how
many instances of the file exist on the endpoint, and the last time the action was updated).

If not all endpoints in the query scope are connected or the search has not completed, the search action remains in Pending status in the Action Center.

6. (Optional) Destroy a file.

After you located the malicious file instances on all your endpoints, proceed to Destroy a File destroy all the file instances on the endpoint. From the
search results Additional data, right-click the file to immediately Destroy by path, Destroy by hash, or Get file to upload it to Cortex XSIAM for further
examination.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 383/1003
5/8/24, 9:18 AM PDF Export

Destroy a File

When you know a file is malicious, you can destroy all its instances on your endpoints directly from Cortex XSIAM . You can destroy a file immediately from the
File search action result, or initiate a new action from the Action Center. When you destroy a file, the Cortex XSIAM agent deletes all the file instances on the
endpoint.

To destroy a file from the file search results, go to step 6 above.

Go to the Action Center Wizard to destroy a file.

1. From the Action Center select +New Action → Destroy File.

2. To destroy by hash, provide the SHA256 of the file. To destroy by path, specify the exact file path and file name. Click Next.

3. Select the target endpoints.

Select the target endpoints from which you want to remove the file. Cortex XSIAM displays only endpoints eligible for file destroy. When you’re done, click
Next.

4. Review the summary and initiate the action.

Cortex XSIAM displays the summary of the file destroy action. If you need to change your settings, go Back. If all the details are correct, click Run. The
File destroy action is added to the Action Center.

4.9.7 | Manage External Dynamic Lists

Abstract

Configure and manage your external dynamic lists in Cortex XSIAM.

An External Dynamic List (EDL) is a hosted text file. In Cortex XSIAM, you can configure an EDL to share a list of Cortex XSIAM indicators with other products
in your network, such as a firewall. For example, your Palo Alto Networks firewall can add IP address and domain data from the EDL to block or allow lists.

Cortex XSIAM hosts two external dynamic lists you can configure and manage.

IP Addresses EDL

Domain Names EDL

NOTE:

To configure an EDL, you must have a role that includes EDL permissions, such as Instance Admin or Account Admin.

Configuring custom certificates or private API Keys in the EDL integration instance is supported only on engines, not on the Cortex XSIAM server.

For EDL integrations on the server, you must set a username and password. For long running integrations running on an engine, we strongly
recommend setting a username and password, but it is not required.

You can set credentials for all EDL integrations or for a specific integration instance. If you set a username and password in an EDL integration
instance, only those credentials are accepted and the username and password you set in the Cortex XSIAM do not work.

You can set up Cortex XSIAM to export internal data to an EDL using an EDL integration installed either on the Cortex XSIAM tenant or on an engine.

NOTE:

The legacy external dynamic list PAN-OS integration is deprecated. Configure the EDL integration by clicking the Automation & Feed Integration link.

Access EDL Data on the Cortex XSIAM Server

If the EDL integration runs on the Cortex XSIAM server, you must set a username and password to allow external access to the data.

1. Navigate to Settings → Configurations → Integrations → External Dynamic List Integration.

2. Enter a username and password for all EDL integration instances. If you do not enter credentials here, you must set them for each integration instance.

3. Click the Automation & Feed Integration link.

4. Add an instance of the Generic Export Indicators Service.

5. (Optional) Enter a Username and Password if you want credentials specific for this integration instance.

NOTE:

If the EDL integration runs on the Cortex XSIAM server, there is no need to enter a Listen Port in the instance settings. The system auto-selects an
unused port for the EDL integration when the instance is saved. If you enter a value for Listen Port, it will be overwritten by the port auto-selected by the
system

6. Enter an indicator query.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 384/1003
5/8/24, 9:18 AM PDF Export

The query updates the EDL list. To view expected results, run !findIndicators query=<your query> from the Cortex XSOAR CLI. Field names in your
query must match the machine name for each field.

7. Enter the maximum list size.

8. You can run curl commands to access and test the External Dynamic List with this URL: https://edl-<cortex-xsiam-
address>/xsoar/instance/execute/<instance-name>.

For example: curl -v -u user:pass https://ext-mytenant.paloaltonetworks.com/xsoar/instance/execute/edl_instance_01\?

q\=type:ip

IMPORTANT:

The EDL URL must always be prefixed by ext-.

9. Save your changes.

Access EDL Data on an Engine

Provide access to internal data via an engine using an endpoint port. We strongly recommend also setting a username and password for additional security.

1. Click the Automation & Feed Integration link.

2. For the Generic Export Indicators Service, click + Add instance and enter:

Listen Port - The service to access the EDL runs on this port from within Cortex XSIAM. You need a unique port for each long running integration
instance (do not use the same port for multiple instances).

(Optional) Username and Password - The username and password for the EDL.

Run on single engine - Select the engine from a drop-down.

3. Enter an indicator query.

The query updates the EDL list. To view expected results, run !findIndicators query=<your query> from the Cortex XSOAR CLI. Field names in your
query must match the machine name for each field.

4. Enter the maximum list size.

5. You can run curl commands to access and test the External Dynamic List with the engine URL: http://<engine-address>:<integration listen
port>/.

For example: curl -v -u user:pass http://<engine_address>:<listen_port>/?n=50

6. Save your changes.

4.9.8 | Collect a Memory Image

Abstract

Collect a memory image from a Windows endpoint.

Certain forensic artifacts exist only in the computer’s memory, such as volatile data created by running processes. The Memory Collection option from the Define
an Action procedure, enables Cortex XSIAM to capture the memory of a Windows endpoint. After the memory image has been captured from the Cortex XSIAM
endpoint, the image is available to download. Use the image to perform a full analysis using industry-standard tools.

NOTE:

Memory collection requires a Forensics add-on license.

This feature is not currently supported on Windows 11.

1. From the Action Center select +New Action → Memory Collection.

2. Select the target endpoint (only one endpoint at a time).

Select the target Windows endpoint from which you want to collect the memory image. When you’re done, click Next.

3. Review the summary and initiate the action.

Cortex XSIAM displays the summary of the memory collection action. If you need to change your settings, go Back. If all the details are correct, click
Done. The Memory Collection action is added to the Action Center.

4. Review the collection results.

In the Action Center, you can monitor the action progress in real-time and view the status for the target endpoint. For a detailed view of the results, right-
click the action and select Additional data. Cortex XSIAM displays the action, timestamp, and real-time status of the action on the target endpoint.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 385/1003
5/8/24, 9:18 AM PDF Export

5. Download the file of the image.

In the Detailed Results - Memory Collection screen, right-click the action and select Download files.

The file is downloaded to the local computer.

4.10 | Playbooks
Abstract

Cortex XSIAM playbooks enable you to structure and automate many of your security processes. Parse incident information, interact with users, and remediate.

Playbooks are a series of tasks, conditions, automations, conditions, commands, and loops that run in a predefined flow to save time and improve the efficiency
and results of the investigation and response process. They are at the heart of the Cortex XSIAM system, because they enable you to automate many security
processes, including handling investigations and managing tickets. You can also structure and automate security responses that were previously handled
manually. For example, a playbook task can parse the information in an incident, whether it is an email or a PDF attachment.

Playbooks have different task types for each of the actions you want to take. For example:

Use manual tasks when an analyst needs to confirm information or escalate an alert.

Use conditional tasks to validate conditions based on values or parameters and take appropriate direction in the playbook workflow.

Use communication tasks to interact with users in your organization

Use automation tasks to automatically remediate an incident by interacting with a third-party integration, open tickets in a ticketing system such as Jira, or
detonate a file using a sandbox.

Playbooks run during the investigation and response stage of the incident lifecycle. But you start defining the logical flow of your playbook during the initial
planning stage when designing your use case.

NOTE:

You can create a new playbook or update an existing playbook from a content pack.

4.10.1 | Playbook development

Abstract

Cortex XSIAM playbooks enable you to structure and automate many of your security processes.

Playbooks enable you to automate many security processes, including handling investigations and managing tickets. You can structure and automate security
responses that were previously handled manually. For example, use playbook tasks to parse the information in the incident, whether it is an email or a PDF
attachment. You can interact with users in your organization using communication tasks, or remediate an incident by interacting with a third-party integration.

Playbooks have different task types for each of the actions you want to take. Manual tasks can be used where an analyst needs to confirm information or
escalate an incident. Conditional tasks can be used with a loop to check if certain information is present, so you can proceed with the investigation. Playbook
tasks can open tickets in a ticketing system, such as Jira, detonate a file using a sandbox, etc.

When building your playbook, keep in mind the following:

What actions do you need to take?

What conditions do you need along the way? Are these conditions manual or automatic?

Do you need to include looping?

Are there any time-sensitive aspects to the playbook?

When is the incident considered remediated?

NOTE:

When creating or updating playbooks, it is recommended to do the following:

Update deprecated automations and integration commands used in playbook tasks to an updated version.

Remove disconnected playbook tasks.

Playbook tasks

Playbook tasks are the building blocks of playbooks. With tasks, you can run automations and sub-playbooks, communicate with end users, set conditions, and
store relevant data. Within each task, you can edit, copy and delete. You can also open a sub-playbook task and click Open sub-playbook and the sub-playbook
opens in a new tab.

NOTE:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 386/1003
5/8/24, 9:18 AM PDF Export

To open multiple playbooks at the same time, edit the first playbook and then click the + symbol next to the playbook name to create a new tab. You can either
create a new playbook, or add an existing one.

Cortex XSIAM supports different task types for the different aspects of the playbook. Each task type requires different information and provides different
capabilities. You should choose your task type based on what you want to accomplish in the task. For example, for enrichment, you might want to run an
enrichment sub-playbook or a command that returns additional information for an indicator. If you are at a fork in your decision tree, you should use a conditional
task to help you determine which path to choose.

Playbooks support the following task types:

Standard tasks

Conditional tasks

Data collection

Section headers

Inputs and outputs

Depending on the task type that you select, and the script that you are running, your playbook task has inputs and outputs.

Inputs are data pieces that are present in the playbook or task. The inputs are often manipulated or enriched and they produce outputs. Outputs are objects
whose entries will serve the tasks throughout the playbook, and they can be derived from the result of a task or command.

Sub-playbooks

Playbooks can be divided into two categories, depending on their use.

Parent playbooks are playbooks that run as the main playbook of an alert.

Sub-playbooks are playbooks that are nested under other playbooks. They appear as tasks in the parent playbook flow and can be identified by .A
sub-playbook can also be a parent playbook in a different use case.

Examples of parent playbooks are Phishing - Generic v3 and Process Email- Generic v2 (an alert starts according to these playbooks). Examples of sub-
playbooks are Detonate File - Generic or Detonate File - Generic (they are part of a bigger investigation).

As sub-playbooks are building blocks that can be used in other playbooks and use cases, you should define generic inputs for them.

Inputs can be passed to sub-playbooks from the parent playbook, used and processed in the sub-playbook, and sent as output to the parent playbook.

NOTE:

Any change made to a sub-playbook impacts the parent playbook in the next run of the parent playbook.

Field mapping

You can map output from a playbook task directly to an alert field. This means that the value for an output key populates the specified field per alert.

Attach and detach playbooks

When installing a playbook from a content pack, by default, the playbook is attached, which means that it is not editable (apart from some input values).

To edit the playbook, you need to detach or make a duplicate. When detached, the playbook is not updated by the content pack, which may be useful when you
want to update the playbook without breaking customization. If you want to update the playbook through content pack updates, you need to reattach the
playbook but any changes are overridden by the content pack updates. If you open an attached playbook in a tab, it can be detached from within the editor
page.

If you want to keep the changes, duplicate the playbook before reattaching it.

Work plan

When an alert is ingested into a playbook is usually attached and runs automatically. You can see which playbook ran in an incident/alert, if any, by going to
Incident Response → Incidents and selecting the incident. You can view or update the playbook by going to the Alerts & Insights tab, selecting the alert, and
then clicking Investigate → Work Plan.

On the left hand side, you can see the name of the playbook. You can select another playbook to run from the dropdown list.

4.10.2 | Search for a playbook

Abstract

Search Cortex XSIAM for playbooks using free text search in the search box.

In the Playbooks page, use free text in the search box to search for playbooks. You can search using part or all of the playbooks's name or description. You can
also search for an exact match of the playbook name by putting quotation marks around the search text. For example, searching for "Block Account -

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 387/1003
5/8/24, 9:18 AM PDF Export

Generic" returns the playbook with that name. You can search for more than one exact match by including the logical operator "or" in between your search
texts in quotation marks. For example, searching for "Block Account - Generic" or "NGFW Scan" returns the two playbooks with those names. Wildcards
are not supported in free text search.

4.10.3 | Manage playbook settings

Abstract

Manage Cortex XSIAM playbook settings, including role access, which alerts type triggers it, and options for Quiet Mode.

You can manage general playbook settings such as the name of the playbook, who can edit and run the playbook, and whether Quiet Mode is turned on.

1. Go to Incident Response → Automation → Playbooks and click the playbook that you want to manage.

2. If it is a content pack playbook, detach or duplicate the playbook by clicking the ellipsis icon.

If you detach the playbook and want to keep any changes, ensure that you duplicate the playbook before reattaching.

3. Click Edit.

4. Click the settings wheel icon.

5. Edit the following settings as required.

a. In the BASIC section, change the name and description.

NOTE:

You cannot change the name of a detached playbook.

b. Add any tags as required by either typing a new tag or selecting from the dropdown list.

Tags help you search for a particular playbook, such as Malware.

c. If you want to disable a playbook, click the Enabled checkbox.

If disabled, you cannot associate it with an alert or an alert type.

d. In the Advanced section, determine whether the playbook runs in quiet mode.

When Quiet Mode is selected, playbook tasks do not display inputs and outputs and do not extract indicators.

Playbook tasks are not indexed so you cannot search on the results of specific tasks. All of the information is still available in the context data, and
errors and warnings are written to the War Room. Quiet Mode is recommended for scenarios that involve a lot of information that might adversely
affect performance, for example, processing indicators from threat intel feeds.

In the War Room (under the Incident War Room tab for incidents, and under the War Room tab for alerts) you can run the
!getInvPlaybookMetadata command to analyze the size of playbook tasks in a specific alert Work Plan to determine whether to implement quiet
mode for playbooks or tasks.

6. Click Save all tabs.

4.10.3.1 | Obtain playbook metadata

Abstract

Analyze Cortex XSIAM playbook metadata for troubleshooting custom playbooks. getInvPlaybookMetaData command

You can analyze playbook metadata such as tasks input and output, the amount of storage each task input/output uses, and the type of task. This is useful when
troubleshooting your custom playbook if your system has slowed down and is using high CPU usage, memory, or storage (disk space).

After an incident has been assigned to a playbook you can analyze it to see its tasks inputs/outputs storage. You can filter the data according to the KB used in
each task input/output.

From the Incidents page, in the Incident War Room , run the following command.

!getInvPlaybookMetaData incidentId=<incident ID> minSize=<size of the data you want to return in KB. Default is 10>

For example, to view the playbook metadata that is used in incident number 964, type !getInvPlaybookMetaData incidentid=”964” minSize=”0”.

4.10.4 | Version control

Abstract

Save versions of your playbook as you are developing it.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 388/1003
5/8/24, 9:18 AM PDF Export

You can save versions of a playbook as you are developing it. When you save a version of a playbook, add a meaningful comment so that you will be able to
recognize the changes you made in that version at a later time. The version is saved with the name of the playbook, your commit message, an indication of what
the change was (modify, insert, etc.), the date the playbook was saved, and the name of the author who last saved it. If necessary, you can access the
playbook’s version history and revert your playbook to a previous version.

1. In a Playbook, after making changes, click the dropdown list next to Save Playbook and then click Save version for current Playbook.

2. Enter a description of the change that was made to the current version.

3. Click Update Playbook.

4. To access a version of a playbook:

a. Click the icon next to New Playbook. The tooltip displays Version history for all Playbooks.

b. Search for the required playbook. The description that was entered when the version was saved should help you locate the version you now require.

c. Click Restore to restore the required version of the playbook.

4.10.5 | Playbook tasks

Abstract

Cortex XSIAM playbook tasks, including conditional tasks and communication tasks.

Tasks are the building blocks of playbooks. Cortex XSIAM supports different task types for the different aspects of the playbook. Each task type requires
different information and provides different capabilities. You should choose your task type based on what you want to accomplish in the task. For example, for
enrichment, you might want to run an enrichment sub-playbook or a command that returns additional information for an indicator.

Task Types

Playbooks support the following task types:

Standard tasks

Standard tasks range from manual tasks like creating an alert or escalating an existing alert, to automated tasks such as parsing a file, or enriching
indicators. Automated tasks are based on scripts that exist in the system. These scripts can be something that was created by you or come pre-packaged
as part of an integration. For example, the !ad-get-user command retrieves detailed information about a user account using the Active Directory Query
V2 integration.

Conditional tasks

are used like a decision tree in your flow chart. For example, a conditional task may ask whether indicators are found. If yes, you can have a task to enrich
them, but if not you can proceed to determine that the incident is not malicious. Alternatively, you can use conditional tasks to check if a certain integration
is available and enabled in your system. If so, you can use that integration to perform an action, but if not, you can continue on a different branch in the
decision tree.

Conditional tasks can also be used to communicate with users through a single question survey, the answer to which determines how a playbook will
proceed.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 389/1003
5/8/24, 9:18 AM PDF Export

Data collection

Data collection tasks are used to interact with users through a survey. The survey resides on an external site that does not require authentication, thereby
allowing survey recipients to respond without restriction.

All responses are collected and recorded in the alerts context data, whether you receive responses from a single user or multiple users. This enables you
to use the survey questions and answers as input for subsequent playbook tasks.

NOTE:

You can collect responses in custom fields, for example, a Grid field.

Section headers

Section Headers are used to manage the flow of your playbook and help you organize your tasks efficiently. You create a Section Header task to group a
number of related tasks under the Section Header, as you would items in a warehouse or topics in a book.

For example, in a phishing playbook, you would have different sections for the investigative aspect of the playbook, such as indicator enrichment, and the
tasks for communication with the user who reported the phishing.

4.10.5.1 | Create a section header

Abstract

Section headers tasks are used to manage the flow of your playbook and help you organize your tasks efficiently.

Section headers tasks are used to manage the flow of your playbook and help you organize your tasks efficiently. You create a Section Header task to group a
number of related tasks under the Section Header, as you would items in a warehouse or topics in a book.

1. In a playbook, click +.

2. Select the Section Header option.

3. Enter a meaningful name for the section header.

4. Click Save.

4.10.5.2 | Playbook task fields

Abstract

All of the fields available when defining a playbook task in Cortex XSIAM. Playbook task fields.

This page lists all of the fields that are available when defining a playbook task. The fields that appear depend on the task type you select.

Manual task settings fields

These fields are relevant for Standard tasks and Conditional Manual tasks.

Name Description

Default assignee Assign an owner to this task.

Only the assignee can complete the task Stop the playbook from proceeding until the task assignee completes the
task. By default, in addition to the task assignee, the default administrator
can also complete the blocked task. You can also block tasks until a user
with an external email address completes the task.

Task SLA Set the SLA in granularity of weeks, days, hours, and minutes.

Set task Reminder at Set a reminder for the task in granularity of weeks, days, hours, and
minutes.

Choose a script to run in the playbook

From a drop down list, select a script for the playbook to run. In the following tabs you can set:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 390/1003
5/8/24, 9:18 AM PDF Export

Inputs

Each script has its own set of input arguments (or none). You can set each argument to a specific value (by typing directly on the line under the argument name)
or you can click the curly brackets to define a source field to populate the argument. You can select from:

Alert details

File details

Modules details

Cheatsheet - The task cheat sheet enables quick access to system and custom fields to populate playbook task inputs and outputs.

Lists

Filters and transformers

Outputs

Each script has its own set of output arguments (or none).

Mapping

Map the output from a playbook task directly to an alert field. You can map when you select a script in a Standard or Conditional task.

NOTE:

The output value is dynamic and is derived from the context at the time that the task is processed. As a result, parallel tasks that are based on the same
output may return inconsistent results.

1. In the Mapping tab, click Add custom output mapping.

2. Under Outputs, select the output parameter whose output you want to map. Click the curly brackets to see a list of the output parameters available from
the automation.

3. Under Field to fill, select the field that you want to populate with the output.

4. Click Save.

Advanced

In this tab, set the following:

Setting Description

Using Which integration instance executes the script/command. Leave empty to use all instances.

Extend Context Which information from the raw JSON you want to add to the Context Data. This must be entered as
contextKey=RawJsonOutputPath.

Ignore outputs When selected, this takes the results from the Extend context field and overwrites existing output.

Execution timeout How long a command waits in seconds before it times out.
(seconds)

Indicator Extraction mode Determines whether ro extract indicators from this task, and if so, using which method. Valid values are:

Use system default: Use the option defined in the system configuration. For more see Indicator Extraction in Indicators.

None: Indicators are not automatically extracted. Use this option when you do not want to automatically extract and
enrich the indicators.

Inline: Indicators are extracted and enriched within the task. Use this option when you need to have the most robust
information available per indicator.

This configuration slows down your system performance.

Out of band: Indicators are enriched in parallel (or asynchronously) to other actions. The enriched data is available
within the incident, however, it is not available for immediate use in task inputs or outputs since the information is not
available in real time.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 391/1003
5/8/24, 9:18 AM PDF Export

Setting Description

Mark results as note Select to make the task results available as a note. Notes are viewable in the War Room.

Run without a worker Select to execute this task without requiring a worker. When cleared, this task will only execute when there is a worker
available.

Skip this branch if this Select to enable the playbook to continue executing if an instance of the script, playbook, or sub-playbook is not available.
script/playbook is
unavailable

Quiet Mode Whether this script uses the playbook default setting for Quiet Mode. When in Quiet Mode, tasks do not display inputs and
outputs, nor do they extract indicators. Errors and Warnings are still documented. You can determine to turn Quiet Mode on or
off for a given task or control Quiet Mode by what is defined at the playbook level.

Details

These fields apply to all tasks.

Name Description

Tag the result with Add a tag to the task result. You can use the tag to filter entries in the War
Room.

Task description (Markdown supported) Provide a description of what this task achieves.

You can enter objects from the context data in the description. For example,
in a communication task, you can use the recipient’s email address.

The value for the object is based on what appears in the context every time
the task runs.

Timers

This field is relevant for a Standard task and a Conditional task.

The configuration option in the Timers tab defines the trigger for starting, stopping, or pausing sending the message and survey to recipients.

Field Description

Timer.start The trigger for starting to send the message and survey to recipients. You
can change this trigger or add a trigger for Timer.stop or Timer.pause.

Select the trigger timer field from the drop down.

On Error

These fields configure how the task behaves if there is an error.

Field Description

Number of retries How many times the task should retry running if there is an error. Default is
0.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 392/1003
5/8/24, 9:18 AM PDF Export

Field Description

Retry interval (seconds) How long to wait between retries. Default is 30 seconds.

Error handling How the task should behave if there is an error. Options are:

Stop

Continue

Continue on error path(s)

This option configures the task to handle potential errors that may
occur when executing the current task's script.

Advanced field

This field is relevant for Standard tasks that use a script and Conditional tasks (Ask tasks and scripts).

Name Description

Quiet Mode Whether this task uses the playbook default setting for Quiet Mode. When in
Quiet Mode, tasks do not display inputs and outputs, nor do they extract
indicators. Errors and Warnings are still documented. You can determine to
turn Quiet Mode on or off for a given task or control Quiet Mode by what is
defined at the playbook level.

Details fields

These fields apply to all tasks.

Name Description

Tag the result with Add a tag to the task result. You can use the tag to filter entries in the War
Room.

Task description (Markdown supported) Provide a description of what this task achieves.

You can enter objects from the context data in the description. For example,
in a communication task, you can use the recipient’s email address.

The value for the object is based on what appears in the context every time
the task runs.

Message body fields

These fields are relevant for Data Collection and Ask tasks.

Field Description

Ask by The method for sending the message and survey. Options are:

Task (can always be completed directly in the workplan)

Generated link (appears in the context data)

Email

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 393/1003
5/8/24, 9:18 AM PDF Export

Field Description

To The message and survey recipients. There are several ways to define the
recipients.

Email address: Manually type email addresses for users and/or external
users.

Context: Click the context icon to define recipients from context data.

CC of the email A CC email address.

Subject of the email The message subject that displays to message recipients. You can make
the survey question the subject, but if you don't write the question here, you
should write the question in the message body field.

Message body The text that displays in the body of the message. Although this field is
optional, if you don't write the survey question in the Subject field, you
should include it in the message body. This is a long-text field.

Questions fields

Relevant for Data Collection tasks.

Stand-alone questions

Field Description

Web Survey Title The title displayed for the web survey.

Short Description A description displayed aboved the questions on the web survey.

Question A question to ask recipients.

Answer Type The field type for the answer field. Options are:

Short text

Long text

Number

Single Select (requires you to define a reply option)

Multi select/Array (requires you to define a reply option)

Date picker

Attachments

Mandatory If this checkbox is selected for a question, survey recipients will not be able
to submit the survey until they answer this question.

Reply Options Survey response options. Default values: Yes, No.

Set First option is default to make that response the default.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 394/1003
5/8/24, 9:18 AM PDF Export

Field Description

Help Message The message that displays when users hover over the question mark help
button for the survey question.

Timers field

This field is relevant for a Standard task and a Conditional task.

The configuration option in the Timers tab defines the trigger for starting, stopping, or pausing sending the message and survey to recipients.

Field Description

Timer.start The trigger for starting to send the message and survey to recipients. You
can change this trigger or add a trigger for Timer.stop or Timer.pause.

Select the trigger timer field from the drop down.

Timing fields

These fields are relevant for a Condition Ask task and a Data Collection task.

The configuration options in the Timing tab define the frequency that the message and survey are resent to recipients before the first response is received.

Field Description

Retry interval (minutes) Determine the wait time between each execution of a command. For
example, the frequency (in minutes) that a message and survey are resent
to recipients before the response is received.

Number of retries Determine how many times a command attempts to run before generating
an error. For example, the maximum number of times a message is sent. If
a reply is received, no additional retry messages will be sent.

Complete and expire automatically if (Data Collection task) Choose to configure either of the following options, so that either one will
trigger a stop to the playbook:

1. Reached task SLA (with or without a reply)

2. Received X number of replies

Complete automatically if SLA passed without a reply (Ask task) Select this checkbox to complete the task if the SLA is breached before a
reply is received. You can select yes or no.

On error

These fields are relevant for Standard tasks that use a script and Conditional tasks (Ask tasks and scripts). They configure how the task behaves if there is an
error.

Field Description

Number of retries How many times the task should retry running if there is an error. Default is
0.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 395/1003
5/8/24, 9:18 AM PDF Export

Field Description

Retry interval (seconds) How long to wait between retries. Default is 30 seconds.

Error handling How the task should behave if there is an error. Options are:

Stop

Continue

Continue on error path(s)

This option configures the task to handle potential errors that may
occur when executing the current task's script.

4.10.5.3 | Create a conditional task

Abstract

Create a conditional task in a playbook.

Conditional tasks are used for determining different paths for your playbook. You can use conditional tasks for something simple like proceeding if a certain
integration exists, or whether a user account has an email address.

Alternatively, you can use conditional tasks for more complex situations. For example, if an indicator was enriched and the verdict was set to malicious, escalate
the incident for managerial approval. However, if the indicator reputation is unknown or benign, proceed down a different route.

If the playbook was installed from a content pack, duplicate or detach the playbook, before creating a conditional task.

1. In a playbook, click + Create Task.

2. Select the Conditional option.

3. In the Task Name field, type a meaningful name for the task that corresponds to the data you are collecting.

4. Select the required option based on the conditional task.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 396/1003
5/8/24, 9:18 AM PDF Export

Option Description

Built-in Creates a logical statement using an entity from within the playbook. For example, in an access investigation
playbook, you can determine that if the Asset ID of the person whose account was being accessed exists in a VIP
list, set the incident severity to High. Otherwise, proceed as normal.

Manual Creates a conditional task that must be manually resolved. For example, a security analyst is prompted to review
and validate a suspicious file. The playbook task might involve instructions for the analyst to analyze the file,
determine if it is malicious, and provide feedback or take specific actions based on their assessment.

Ask Creates an Ask tasks, the answer to which determines how a playbook proceeds.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 397/1003
5/8/24, 9:18 AM PDF Export

Option Description

Choose automation Creates a conditional task based on the result of a script. For example, check if an IP address is internal or external
using the IsIPInRanges automation. When using automation, the Inputs and Outputs are defined by the automation
script.

5. Complete the task configuration in the remaining tabs. Some configurations are required, and some are optional.

6. Click Save.

4.10.5.4 | Communication tasks

Abstract

Communication tasks in playbooks enable you to send surveys and collect data. Ask task, data collection task.

Communication tasks enable you to send surveys to users, both internal and external, to collect data for an alert. The collected data can be used for alert
analysis, and also as input for subsequent playbook tasks. For example, you might want to send a scheduled survey requesting analysts to send specific
incident updates or send a single (stand-alone) question survey to determine how an issue was handled.

Ask tasks

The Ask conditional task is a single-question survey, the answer to which determines how a playbook will proceed. If you send the survey to multiple users, the
first answer received is used, and subsequent responses are disregarded.

Users interact with the survey directly from the message, meaning the question appears in the message and they click an answer from the message.

The survey question and the first response is recorded in the alerts context data. This enables you to use this response as the input for subsequent playbook
tasks.

Since this is a conditional task, you need to create a condition for each of the answers. For example, if the survey answers include, Yes, No, and Maybe, there
should be a corresponding condition (path) in the playbook for each of these answers.

For all Ask conditional tasks, a link is generated for each possible answer the recipient can select. If the survey is sent to more than one user, a unique link is
created for each possible answer for each individual recipient. These links are visible in the context data of the incident's Work Plan. The links appear under
Ask.Links in the context data.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 398/1003
5/8/24, 9:18 AM PDF Export

Data collection tasks

The Data Collection task is a multi-question survey (form) that survey recipients access from a link in the message. Users do not need to log in to access the
survey, which is located on a separate site.

All responses are collected and recorded in the alerts context data, whether you receive responses from a single user or multiple users. This enables you to use
the survey questions and answers as input for subsequent playbook tasks.

The following are examples of integrations that can use Data Collection tasks:

Email (EWS, Mail Sender, etc.)

Microsoft Teams

Slack

NOTE:

You can collect responses in custom fields, for example, a grid field in an alert.

For all Data Collection tasks, a single link is generated for each recipient of the survey. These links are visible in the context data of the incident's Work Plan.
The links appear in the context data under the Links section of that survey.

4.10.5.4.1 | Create an Ask task

Abstract

Create a conditional Ask task in a playbook. An Ask task is a single question survey that determines how the playbook proceeds. Answer is recorded in context.

The Conditional Ask task is a single question survey, the answer to which determines how a playbook proceeds. If you send the survey to multiple users, the first
answer received is used, and subsequent responses are disregarded.

When creating an ask task, there are several tabs where you can enter values. Some configurations are required, and some are optional. Click each tab for
detailed information.

If the playbook was installed from a Content Pack, duplicate or detach the playbook, before creating an ask task.

1. In a playbook, click +.

2. Select the Conditional option.

3. Enter a meaningful name for the task, which corresponds to the data that you are collecting. For example, Was the Alert escalated?.

4. Select the Ask option.

5. Select the communication options you want to use to collect the data.

The Task option is selected by default. The data collection survey can be completed directly in the workplan.

If you select Generated link, a link to the data collection survey is available in the context data of the task.

If you select Email, enter the subject and message of the email and the email addresses of the users who should receive this message or survey.

Some integrations can be used to collect data for Ask Tasks, such as Microsoft Teams and Slack. If any of these integrations are installed, it will
appear as an option.

6. (Optional) To customize the look and feel of your email message, click Preview.

You can change the color scheme and how test in the message header and body appear.

4.10.5.4.1.1 | Ask task examples

Abstract

Examples of a conditional Ask task in a playbook. Send emails to selected users or send a survey.

These examples show you how to implement some common uses of the conditional Ask task.

Send emails to users

In this example, a message and survey are sent by email to all users with the Analyst role. We are not including a message body because the message subject
is the survey question we want recipients to answer. There are three reply options, Yes, No, and Not sure. In the playbook, we will only add conditions for the
Yes and No replies. We require recipient authentication, which first involves setting up authentication. For more details, see Create Communication Task
Authentication.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 399/1003
5/8/24, 9:18 AM PDF Export

Send a survey

In this example, the message and survey will be sent to recipients every hour for six hours, until a reply is received (it is repeated every 60 minutes, 6 times).
The SLA is six hours. If the SLA is breached, the playbook will proceed according to the Yes condition.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 400/1003
5/8/24, 9:18 AM PDF Export

4.10.5.4.2 | Create a data collection task

Abstract

Create a data collection task in a Cortex XSIAM playbook. Multi-question survey (form), responses are recorded in the incident’s context data.

The Data Collection task is a multi-question survey (form), which recipients access from a link in the message.

You can include the following types of questions in the survey.

Stand alone questions. These are presented to users directly in the message, and from which users answer directly in the message (not an external
survey).

Field-based questions. These are based on a specific alert field (either system or custom), for example, an Asset ID field. The response (data) received for
these fields automatically populates the field for this alert. For single select field based questions, the default option is taken from the field’s defined
default.

You can collect responses in custom fields.

NOTE:

If responses are received from multiple users, data for multi-select fields and grid fields are aggregated. For all other field types, the response received most
recently will override previous responses as it displays in the field. All responses are always available in the context data.

If the playbook was installed from a content pack, duplicate or detach the playbook, before creating a data collection task.

1. In a playbook, click +.

2. Select the Data Collection option.

3. Enter a meaningful name in the Task Name field for the task that corresponds to the data you are collecting.

4. Select the communication options you want to use to collect the data.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 401/1003
5/8/24, 9:18 AM PDF Export

The Task option is selected by default. The data collection survey can be completed directly in the workplan.

If you select Generated link, a link to the data collection survey is available in the context data of the task.

If you select Email, enter the subject and message of the email and the email addresses of the users who should receive this message or survey.

Some integrations can be used to collect data for Data Collection tasks, such sa Microsoft Teams and Slack. If any of these integrations are
installed, it will appear as an option.

5. In the Questions tab, type the questions and answer types that the survey will contain.

You can drag and drop questions to rearrange the order in which they display in the survey.

6. (Optional) To customize the look and feel of your email message, click Preview.

You can determine the color scheme and how the text in the message header and body appear, as well as the appearance and text of the button the user
clicks to submit the survey.

7. In the remaining fields, add any timing, details about the task and whether to extract indicators, etc., as required.

4.10.5.4.2.1 | Data Collection Task Examples

Abstract

Example of a data collection task in a Cortex XSOAR playbook. Stand-alone, multi-select answer, field-based used a custom field.

These examples show you how to implement some common uses of the Data Collection task.

Stand-alone question with a single-select answer

In this example, we created a stand-alone question, with a single-select answer. This question is not mandatory. If we selected the First option is default
checkbox, the Reply Option "0" would be the default value in the answer field.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 402/1003
5/8/24, 9:18 AM PDF Export

Field-based using a custom field

In this example, we create a question based on a custom alert field that is marked as mandatory. You can add a question based on a field. To add a field, click
the Add Question based on field.

4.10.5.4.3 | Create Communication Task Authentication

Abstract

Configure user authentication for a communication task.

When sending a form in a communication task, you can configure user authentication to ensure only authorized users gain access to the form.

The authorized users are usually external users not in Cortex XSIAM, and they will not be able to access anything else in Cortex XSIAM

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 403/1003
5/8/24, 9:18 AM PDF Export

Set up playbook communication task authentication

1. Define in your IdP (for example, Okta) a dedicated group of external users who you want to authenticate.

2. Select Settings → Configurations → Access Management → Authentication Settings.

3. In the Communication Task Authentication tab, toggle to Enable Communication task SSO Connection. Set the following parameters using your
organization’s IdP.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 404/1003
5/8/24, 9:18 AM PDF Export

General

Parameter Description

Single Sign-on URL Indicates your SSO URL, which is a fixed, read-only value based on your
tenant's URL using the format https://<name of Cortex-
XSIAM>.paloaltonetworks.com/idp/saml. For example,
https://tenant1.xsoar.paloaltonetworks.com/idp/saml

You need this value when configuring your IdP.

Audience URI (SP Entity ID) Indicates your Service Provider Entity ID, also known as the ACS URL. It is a
fixed, read-only value using the format, https://<name of Cortex-
XSIAM>.xdr.<region>.paloaltonetworks.com. For example
https://tenant1.xdr.us.paloaltonetworks.com.

You need this value when configuring your organization’s IdP.

IdP SSO URL Specify your organization’s SSO URL, which is copied from your organization’s
IdP.

IdP Issuer ID Specify your organization’s IdP Issuer ID, which is copied from your
organization’s IdP.

X.509 Certificate Specify your X.509 digital certificate, which is copied from your organization’s
IdP.

IdP Attribute Mappings

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

Parameter Description

Email Specify the email mapping according to your organization’s IdP.

First Name Specify the first name mapping according to your organization’s IdP.

Last Name Specify the last name mapping according to your organization’s IdP.

Advanced Settings (Optional)

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

Parameter Description

Relay State (Optional) Specify the URL for a specific page that you want users to be
directed to after they’ve been authenticated by your organization’s IdP and
log in to Cortex XSIAM.

IdP Single Logout URL (Optional) Specify your IdP single logout URL provided from your
organization’s IdP to ensure that when a user initiates a logout from Cortex
XSIAM, the identity provider logs the user out of all applications in the current
identity provider login session.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 405/1003
5/8/24, 9:18 AM PDF Export

Parameter Description

SP Logout URL (Optional) Indicates the Service Provider logout URL that you need to provide
when configuring single logout from your organization’s IdP to ensure that
when a user initiates a logout from Cortex XSIAM, the identity provider logs
the user out of all applications in the current identity provider login session.
This field is read-only and uses the following format https://<name of
Cortex-XSIAM>.xdr.<region>paloaltonetworks.com/idp/logout, such
as https://tenant1.xdr.us.paloaltonetworks.com/idp/logout.

Service Provider Public Certificate (Optional) Specify your organization’s IdP service provider public certificate.

Service Provider Private Key (Pem Format) (Optional) Specify your organization’s IdP service provider private key in Pem
Format.

ADFS (Optional) Select this checkbox when you are configuring Microsoft ADFS
services.

Compress encode URL (ADFS) (Optional) Select this checkbox for ADFS encoding.

Only available when the ADFS field is selected.

Service Identifier (ADFS) (Optional) Specify the ADFS service identifier that you are using.

Only available when the ADFS field is selected.

4. In the Task details of your playbook communication task, check Require users to authenticate to have your SAML or AD authenticate the recipient before
allowing them access to the form.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 406/1003
5/8/24, 9:18 AM PDF Export

4.10.5.5 | Add ad-hoc tasks to a Work Plan

Abstract

Add ad-hoc tasks to a Work Plan in Cortex XSIAM , for a specific iteration of a playbook.

Within the Work Plan, you can create tasks for a specific iteration of a playbook. The task type can be an automation or another playbook. For example, within a
manual task, you might need to enrich some data when running an investigation playbook.

When you create a task, add a name, script, and description. The name and description should be meaningful so that the task corresponds to the data that you
are collecting.

1. In the Incidents page, select the incident to update.

2. In the Alerts & Insights tab, click the alert to add the task to and then click Show Workplan.

3. In the playbook, hover over the task where you want to add a new task and click the + sign at the bottom right-hand corner of the task.

The ad-hoc task is added after the task you clicked.

4. Select the task type.

Standard: Runs a single automation.

Playbook: Runs a playbook to enhance the investigation.

The playbook functions as any playbook would and requires you to define the inputs and outputs, as well as any other details.

Click Save.

5. To run the Work Plan again click the Work Plan tab.

An example use case could be where you have a phishing investigation and the initial playbook run has parsed the email and extracted several indicators,
including some email addresses.

As part of the manual investigation, you could use the Email Address Enrichment playbook as an adhoc playbook task to get more information about these email
addresses.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 407/1003
5/8/24, 9:18 AM PDF Export

4.10.6 | Playbook inputs and outputs

Abstract

Cortex XSIAM playbooks and tasks have inputs (data from incident or integration) and outputs that can then be used as input in other tasks.

Playbooks and tasks have inputs, which are data pieces that are present in the playbook or task. The inputs are often manipulated or enriched and they produce
outputs. The inputs might come from the alert itself, such as the role to whom to assign the incident, or an input can be provided by an integration. For example,
when an Active Directory integration is used in a task to extract a user's credentials.

NOTE:

The example below uses alerts context data as the playbook input from the Access Investigation - Generic playbook. Threat Intel playbooks use indicators as
the playbook input.

Click the Playbook Triggered task. We see a playbook that is triggered based on context data, meaning an incident. The first two inputs are the SrcIP, which
comes from the incident.src key, and DstIP, which is retrieved from incident.dst.

In addition, the playbook itself creates an output object whose entries serve the tasks throughout the playbook.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 408/1003
5/8/24, 9:18 AM PDF Export

For example, we create a list of endpoint IP addresses which can later be enriched by an IP enrichment task, or a list of endpoint MAC addresses, which can be
used to get information about the hosts that were affected by the alerts.

Outputs can also be data that was extracted or derived from the inputs. For example, in the following image we received the user's credentials from Active
Directory, and used those credentials to retrieve the user's email address, manager, and any groups to which they belong.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 409/1003
5/8/24, 9:18 AM PDF Export

An output can then serve as input for a subsequent task. For example, the user's manager who was returned as an output in the image above, can be used as
an input to retrieve information from Active Directory.

Notice that the input for this task is Account.Manager, which is the output we highlighted in the playbooks inputs, above.

4.10.6.1 | Task cheat sheet

Abstract

Use the playbook task cheat sheet to quickly access system and custom fields for task inputs and outputs.

The task cheat sheet enables quick access to system and custom fields to populate playbook task inputs and outputs.

1. Click .

The cheat sheet opens displaying incident or alert fields.

2. Select an alert field, it populates the task input with the corresponding context key.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 410/1003
5/8/24, 9:18 AM PDF Export

4.10.7 | Indicator extraction

Abstract

Indicator extraction extracts indicators from Cortex XSIAM alert fields and enriches them with commands and scripts defined for the indicator type.

Indicator extraction identifies indicators from different text sources in the system (such as War Room entries, email content, etc), extracts them (usually based
on regex), and creates indicators in Cortex XSIAM . After extraction, the indicator can be enriched.

Indicator enrichment takes the extracted indicator and provides detailed information about the indicator (from the open ports to WHOIS information). Enrichment
provides a story about the indicator, based on an enrichment feed such as VirusTotal, IPinfo, etc.

In Cortex XSIAM, the indicator extraction feature extracts indicators from alert fields and enriches them using commands and scripts defined for the indicator
type. Provided the indicator extraction is enabled, indicators are extracted according to the alert type.

You can extract indicators in the following scenarios:

When fetching alerts

In a playbook task

Using the command line

Create indicator extraction rules

Indicators are extracted on alert fields when an alert is created. For Content Pack installed alert types, the indicator extraction rules are set out-of-the-box. For
example, in a phishing alert type, in the Destination IP field, IPv6 and IP indicators are extracted. For the Detection URL field, the URL indicator field is extracted,
etc. Provided the indicator extractions settings are enabled and depending on the rules set in the alert type, indicator extraction is automatic. For example, in a
phishing alert, indicator extraction is set to extract the IP indicator (in the alert type). When the alert field updates, the IP indicator field is extracted automatically.
In the War Room, you can check that the IP indicator field has been extracted by typing 1.1.1.1.Cortex XSIAM recognizes the indicator as an IP indicator by
matching it to the IP indicator’s regex. It then extracts and enriches the indicator using an integration that uses the IP command (such as IPinfo).

You create indicator extraction rules:

In a playbook task.

Running a command during an investigation.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 411/1003
5/8/24, 9:18 AM PDF Export

Indicator extraction modes

Indicator extraction supports the following modes:

None: Indicators are not extracted automatically. Use this option when you do not want to further evaluate the indicators.

Inline: Indicators are extracted within the context that indicator extraction runs (synchronously). The findings are added to the context data. For example,
if indicator extraction for the phishing alert type is inline:

For alert creation, the playbook you defined to run by default does not run until the indicators have been extracted.

For an on-field change, extraction occurs before the next playbook tasks run. This option provides the most robust information available per
indicator.

NOTE:

This configuration may delay playbook execution (alert creation).

NOTE:

While indicator creation is asynchronous, indicator extraction and enrichment are run synchronously. Data is placed into the alert context and is
available via the context for subsequent tasks.

Out of band: Indicators are extracted in parallel (asynchronously) to other actions. The extracted data will be available within the alert, however, it is not
available for immediate use in task inputs or outputs since the information is not available in real-time.

For alert creation, out-of-band is used in rare cases where you do not need the indicators extracted for the proceeding flow of the playbook. You still want
to extract them and save them in the system as indicators, so that they can be reviewed at a later stage for manual review. System performance may be
better as the playbook flow does not stop extracting, but if the alert contains indicators that are needed or expected in the proceeding playbook execution
flow, inline should be used, as it will not execute the playbook before all indicators are extracted from the alert.

NOTE:

When using Out of band, the extracted indicators do not appear in the context. If you want the extracted indicators to appear select Inline.

Indicators are extracted according to the following rules:

Incident creation - inline

Incident field change - inline

Tasks - none, can be overridden on a per task basis

CLI - out of band, but can be overridden on a per-command basis

Troubleshoot indicator extraction

If indicators are not extracted, check whether the indicator mode is set to none. Even if you select the relevant alert fields and the indicators to extract, if the
mode is set to none, indicators do not extract.

4.10.7.1 | Create indicator extract rules for a playbook task

Abstract

Create indicator extraction rules for a playbook task in Cortex XSIAM. Auto extract for a playbook task. Edit task. Use case indicator extraction.

When using indicator extraction rules, indicators are extracted from tasks in playbooks.

The default indicator extraction value is inline.

You can use the following commands in a task:

extractIndicators

Reputation commands, such as !ip, !file, etc.

enrichIndicators

For more information, see Run Indicator Extraction in the CLI.

1. Select the playbook where you want to add indicator extraction, and click Edit.

2. In the playbook, click a task to open the Edit Task window.

3. Click the Advanced tab.

4. In the indicator extraction drop-down menu, select the mode you want to use.

5. Click OK.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 412/1003
5/8/24, 9:18 AM PDF Export

Extract indicators from a phishing email

The following scenario shows how indicator extraction is used in the Process Email - Generic v2 playbook to extract and enrich a very specific group of
indicators.

This playbook parses the headers in the original email used in a phishing attack. It is important to parse the original email used in the phishing attack and not the
email that was forwarded to ensure that you only extract the email headers from the malicious email and not the one your organization uses to report phishing
attacks.

1. Navigate to the Playbooks page and search for the Process Email - Generic v2 playbook.

2. Click either Duplicate Playbook or Detach Playbook.

3. Open the Add original email details to context task, click Edit, and for the Choose script drop down, change the script from Set to ParseEmailFilesV2.

Under the Outputs tab, you can see all of the different data that the task extracts.

4. Click the Advanced tab and set Indicator Extraction mode to Inline. This ensures all the outputs are processed before the playbook moves ahead to the
next task.

5. Open the Display email information in layout - Email.Headers task. This task receives the data from the saved attachment tasks and sets the various data
points to context.

6. Click the Advanced tab and set Indicator Extraction mode to None , because the indicators were already extracted earlier in the Extract email artifacts and
attachments task and there is no need to extract them again.

4.10.8 | Extend context

Abstract

Extend context to retrieve specific information from integrations or commands and map to fields.

By design, integrations do not write all of the data returned from a command to the context. This prevents large context size and enables you to store only the
most relevant information.

The Extend Context feature enables you to save additional data from the raw response of the command. For example, when a command runs to retrieve events
from a SIEM, only some of the event fields are written to context, according to the integration design. With Extend Context, you can save additional fields
specific to your use case.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 413/1003
5/8/24, 9:18 AM PDF Export

Extend Context can also be used when the same command is run multiple times in the same playbook, but the outputs need to be saved to different context
keys. For example, you might want to execute the !ad-get-user command twice, once to retrieve the user's information and again to retrieve the user's
manager’s information. By default, an integration command writes the data from the same command to the same context key. By using Extend Context, you can
write the command’s response to a custom context key of your choice.

You can Extend Context either in a playbook task or directly from the command line.

4.10.8.1 | Extend context in a playbook task

Abstract

Extend context to retrieve additional data from integrations or commands and map to fields. Extend context in a playbook task.

You can extend context either in a playbook task or directly from the command line. Whichever method you use, recommends that you first run your command
with the raw-response=true flag. This helps you identify the information that you want to add to your extended data.

1. Go to the Advanced tab of the relevant playbook task, such as a Data Collection task.

2. In the Extend Context field, enter the name of the field in which you want the information to appear and the value you want to return. For example, using
the !ad-get-user command, enter name="john" attributes=displayname to place the user's name in the displayName key.

The following image shows the result of the !IPReuptation ip=20.8.1.5 raw-response=true command.

To include more than one field, separate the fields with a double colon. For example: attributes=displayName::manager=attributes.manager

3. To output only the values for Extend context and ignore the standard output for the command, select the Ignore Outputs checkbox.

While this will improve performance, only the values that you request in the Extend Context field are returned. You cannot use Field Mapping as there is
no output to which to map the fields.

4.10.8.2 | Extend context using the command line

Abstract

Extend context to retrieve additional data from integrations or commands and map to fields. Extend context from the Cortex XSIAM CLI.

You can extend context either in a playbook task or directly from the Incident/Alert War Room command line. Whichever method you use, recommends that you
first run your command with the raw-response=true flag. This will help you identify the information that you want to add to your extended data.

1. Run your command with the extend-context flag !<commandName> <argumentName> <value>extend-context=contextKey=JsonOutputPath.

For example, to add the user and manager fields to context use the ad-get-user command, as follows:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 414/1003
5/8/24, 9:18 AM PDF Export

!ad-get-user=${user.manager.username} extend-context=manager=attributes.manager::attributes=displayName

2. To output only the values that you set as Extend context, run the command with the ignore-ouput flag=true. !ad-get-user=${user.manager.username}
extend-context=manager=attributes.manager::attributes=displayName ignore-output=true

Example

By default, after adding an IBM Qradar v3 integration instance, offenses pulled from QRadar to Cortex XSIAM returns numerous fields, including
event_count, device_count,offense_type, description, etc. You can use extend context to show, which additional information is available. You can
also use that information to map it to a field in Cortex XSIAM.

Run the command !qradar-offenses-list raw-response="true". From the context data, you should see that there are a number of fields that
are returned.

Identify the fields that you want to view and run your command. For example, to retrieve the number of devices affected by a given offense, as well
as the domain in which those devices reside, run the following command:

!qradar-offences-list extend-context=device-count=device_count::domain_id=domain_id

4.10.9 | Filters and transformers

Abstract

Use filters and transformers to manipulate data. Use filters and transformers in playbook tasks or when mapping an instance. transformer mapping

In Cortex XSIAM, data is extracted and collected from various sources, such as playbook tasks, command results, and fetched incidents, and presented in
JSON format. The data can be manipulated by using filters and transformers. You can add filters and transformers in a Playbook task or when mapping an
instance.

Filters

Creating filters enables you to extract relevant data, which you can use elsewhere in Cortex XSIAM. For example, if an alert has several files with varying file
types and extensions, you can filter the files by file extension or file type, and use the filtered files in a detonation playbook.

You can filter as many objects as required. Cortex XSIAM automatically calculates the context root to which to filter. You can change the context root, as
necessary.

Transformers

Creating transformers enables you to take one value and transform or render it to another value. For example, converting a date in non-Unix format to Unix
format. Another example is applying the count transformer, which renders the number of elements.

When you have more than one transformer, they apply in the order that they appear. You can reorder them using click-and-drag.

4.10.9.1 | Create filters and transformers in a playbook

Abstract

Filter transformer playbooks mapping.

You can create filters and transformers when adding or editing a task in a playbook or when mapping an instance.

You can filter as many nested objects as required. automatically calculates the context root to which to filter. For example, if you want to extract all Item names
in EWS, in the Get field, type EWS.Items.Name, calculates that the context root is EWS.items.

WARNING:

You can change the context data root to which to filter, but it is not recommended to select a different root, as it affects the filter results. The drop-down list
displays the filter root for backward compatibility.

1. Create or edit a playbook task.

2. In the field you want to add a filter or transformer, click the curly brackets and then select Filters and Transformers.

3. In the Get field, type or select data you want to filter or transform. For example, EWS.Items.Name.

4. (Optional) To filter the data, do the following.

a. In the Filter section, click Add filter.

When adding a filter, automatically populates the context root to which to filter.

b. Select the data you want to filter.

c. Select the Filter operators.

d. Add the value.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 415/1003
5/8/24, 9:18 AM PDF Export

e. Click the tick box to save the filter.

For an example, see Create a filter example.

5. (Optional) To apply transformers to the field, click Add transformer.

a. Click the transformer and select the relevant transformer.

For example, you may want to change the date format for when incidents occurred.

b. Select the Transformers operators.

c. Click the tick box to save.

6. (Optional) To test the filter or transformation click Test and select the investigation or add it manually.

4.10.9.2 | Create a filter example

Abstract

Example of how to create a filter in Cortex XSIAM. Filter all EWS Item names with a particular extension. filters object transformers playbooks

In this example, we want to filter all EWS Item names that have the extension exe.

1. From the Filters & transformers window, in the Get field, type EWS.Items.Name to extract all Item names in EWS.

calculates that the context root to filter is EWS,Items.

2. In the Filter section, click Add filter.

3. In the left-hand side, add Extension to the filter.

4. Select Equals (String) → ignore case.

5. In the right-hand side add exe.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 416/1003
5/8/24, 9:18 AM PDF Export

6. Click the tick box to save the filter.

7. Click Test.

You should see Item names are filtered with the extension exe.

4.10.9.3 | Filter operators

Abstract

Use filters to extract relevant data for use elsewhere in Cortex XSIAM.

Filters enable you to extract relevant data for use elsewhere. For example, if an alert has several files with varying file types and extensions, you can filter the
files by file extension or file type, and use the filtered files in a detonation playbook.

Note the following:

Filters try to cast the transformed value and arguments to the appropriate type. The task fails if casting fails. For example, “a” Equals {“some”: “object”} =>
Error

If the filter's left-side value expects a single item but receives a list, the filter passes if at least one item meets the requirements. For example, [“a”, “b”, “c”]
Equals “b” => true.

If the filter's left-side value expects a list but receives a single item, it converts it to a list with a single item. For example, “a” Contains “a” => True.

Some filters are implemented as automations, meaning custom transformers, automation with the filter tag. You can find examples in the automation
description. For more information about creating custom filters, Create custom filter and transformer operators.

Filters in conditional tasks do not iterate the items of the root. Instead, they fetch the left-side value and the right-side value and compare them.

Filter categories

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 417/1003
5/8/24, 9:18 AM PDF Export

Boolean: Determines whether a field is true or false, or the string representation is true or false.

Date: Determines whether the left-side time value is earlier than, later than, or the same time as the right-side time value.

Supported time and date formats:

Format Example

ANSIC Tues Jan _2 15:04:05 2019

UnixDate Tues Jan _2 15:04:05 MST 2019

RubyDate Tues Jan 02 15:04:05 -0700 2019

RFC822 02 Jan 19 15:04 MST

RFC822Z 02 Jan 19 15:04 -0700 // RFC822 with numeric zone

RFC850 Tuesday, 02-Jan-19 15:04:05 MST

RFC1123 Tues, 02 Jan 2019 15:04:05 MST

RFC1123Z Tues, 02 Jan 2019 15:04:05 -0700 // RFC1123 with numeric zone

RFC3339 2019-01-02T15:04:05Z07:00

RFC3339Nano 2019-01-02T15:04:05.999999999Z07:00

Kitchen 3.04PM

Stamp Jan _2 15:04:05

StampMilli Jan _2 15:04:05.000

StampMicro Jan _2 15:04:05.000000

StampNano Jan _2 15:04:05.000000000

General: Includes general filters, such as contains, doesn’t contain, In, empty, etc.

String: Determines the relationship between the left-side string value and the right-side string value, such as starts with, includes, in the list, and so on.
The string filter returns partial matches as True.

Number: Determines the relationship between the left-side number value and the right-side number value, such as equals, greater than, less than, etc.

Unknown: Miscellaneous filter category.

4.10.9.3.1 | Built-in Filters

Abstract

Description of the built-in filters available for playbook tasks.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 418/1003
5/8/24, 9:18 AM PDF Export

General filters

Filter Description

Contains Tests whether the value on the left is contained in the value on the right. Can be used for any kind of object (not limited to a string).

Doesn't Tests whether the value on the left is NOT contained in the value on the right. Can be used for any kind of object (not limited to a string).
Contain

Has length of Tests whether a list specified on the left has the number of items specified on the right.

In Tests whether the value on the left is contained in the object on the right.

Is defined Tests whether a key on the left exists in context.

NOTE:

Is defined considers false and empty strings and lists to be defined values. If you don't want those to be included as defined, use Is
not empty.

Is empty Tests whether the value of a key is empty.

Is not empty Tests whether the value of a key is NOT empty.

Not defined Tests whether a key on the left does NOT exist in context.

NOTE:

Not defined considers false and empty strings and lists to be defined values. If you don't want those to be included as defined, use
Is empty.

Not in Tests whether the value on the left is NOT contained in the object on the right.

String filters

Filter Description

Doesn't end with Tests whether the string on the left is NOT the end of the string on the right.

Doesn't equal Tests whether the strings are NOT the same.

Doesn't include Tests whether the string on the right is NOT a substring of the string on the left.

Doesn't start with Tests whether the string on the right is NOT the beginning of the string on the left.

Ends with Tests whether the string on the left is the end of the string on the right.

Equals Tests whether the strings are the same.

Has length Tests whether the two strings have the same length.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 419/1003
5/8/24, 9:18 AM PDF Export

Filter Description

In list Tests whether the string on the left is in the list on the right.

Includes Tests whether the string on the right is a substring of the string on the left.

Matches - regex Tests whether the string on the left matches the regex on the right. Uses Go-style regex.

Not in list Tests whether the string on the left is NOT a substring of the string on the right.

Starts with Tests whether the string on the right is the beginning of the string on the left.

StringContainsArray Tests whether a substring or an array of substrings on the left is within a string array on the right. Supports single strings as well. For
example, for substrings ['a', 'b', 'c'] in string 'a' the script returns true.

Number filters

Filter Description

Doesn't equal Tests whether the number on the left does NOT equal the number on the right.

Equals Tests whether the number on the left equals the number on the right.

Greater or Tests whether the number on the left is greater than or equal to the number on the right.
equal

Greater than Tests whether the number on the left is greater than the number on the right.

InRange Tests whether the number on the left is within a range specified on the right. For example, if the left value is 4, and the range on the right
is 1,8, the condition is true.

Less or equal Tests whether the number on the left is less than or equal to the number on the right.

Less than Tests whether the number on the left is less than the number on the right.

Date filters

Filter Description

After Tests whether the date on the left is after the date on the right.

AfterRelativeDate Tests whether the date on the left occurred after the provided relative time (such as '6 months ago') on the right. Returns True or False.

Before Tests whether the date on the left is before the date on the right.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 420/1003
5/8/24, 9:18 AM PDF Export

Filter Description

Same as Tests whether the two dates are the same.

Boolean filters

Filter Description

Is false Tests whether the value on the left evaluates to false.

Is true Tests whether the value on the left evaluates to true.

Other filters

Filter Description

CheckIfSubdomain Tests whether the value on the left is a subdomain of the value on the right.

CIDRBiggerThanPrefix Tests whether the CIDR prefix on the left is bigger than the defined maximum prefix on the right.

GreaterCidrNumAddresses Tests whether the number of available addresses in IPv4 or IPv6 CIDR on the right is greater than the input given on the left.

IsInCidrRanges Tests whether the IPv4 address on the left is contained in at least one of the comma-delimited CIDR ranges on the right.
Multiple IPv4 addresses can be passed in a comma-delimited list and each address is tested.

IsNotInCidrRanges Tests whether the IPv4 address on the left is NOT contained in at least one of the comma-delimited CIDR ranges on the right.
Multiple IPv4 addresses can be passed in a comma-delimited list and each address is tested.

IsRFC1918Address Tests whether an IPv4 address on the left is in the private RFC-1918 address space (10.0.0.0/8, 172.16.0.0/12,
192.168.0.0/16) on the right.

LowerCidrNumAddresses Tests whether the number of available addresses in IPv4 or IPv6 CIDR on the right is less than the input given on the left.

4.10.9.4 | Transformers operators

Abstract

Transformers enable you to transfer or render one value to another value. Description of system transformer operators.

Transformers enable you to take one value and transform or render it to another value. When you have more than one transformer, you can reorder them using
click-and-drag.

Note the following:

Transformers try to cast the transformed value (and arguments) to the necessary type. Tasks will fail if casting has failed, for example {“some”:
“object”} To upper case => Error.

Some transformers are applied on each item of the result. For example, a, b, c To upper case => A, B, C.

Some transformers operate on the entire list. For example, a, b, c count => 3.

Some transformers are implemented as automations (meaning custom transformers automation with the transformer tag. You can find examples in the
automation description. For more information about creating custom transformers, see Create custom filter and transformer operators.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 421/1003
5/8/24, 9:18 AM PDF Export

Transformer categories

Date: Transforms the date. For example:

Name Description Example

Date to string Converts any date to a specified string format. The date input must be in ISO format. For 2021-10-06T13:44:07 => 06 Oct 21
example, 2021-10-06T13:44:07. The default output format is RFC822. 13:44 EDT

format: The desired string output format. For example, if you want to convert to RFC822
format, enter 02 Jan 06 15:04 MST.

The following are available output format options:

Layout = 01/02 03:04:05PM '06 -0700 // The reference time, in numerical order

RFC3339Nano = 2006-01-02T15:04:05.999999999Z07:00

Kitchen = 3:04PM // Handy time stamps

Stamp = Jan _2 15:04:05

StampMilli = Jan _2 15:04:05.000

StampMicro = Jan _2 15:04:05.000000

StampNano = Jan _2 15:04:05.000000000

This transformer is in GO language.

Date to Unix Converts any date to Unix format. See the Filter operators for a list of supported time and Mon, 02 Jan 2006 15:04:05 MST =>
date formats. 1136214245

General: Includes general transformers, such as sort, splice, stringify, etc. The following table describes the General examples:

Name Description Example

Unique Returns a de-duped version of a list. a, b, a, c, d, a, b => a, b, c, d

Slice Returns part of a specified list in a range of from index (included) through to a, b, c, d from: 1, to: 3 => b, c
index (not included)

from: Zero based index at which to begin extraction (default: 0).

to: Zero based index before which to end extraction (default: list length).

Slice by Returns part of a list specified in a range of from item (included) through to a, b, c, d from: b, to: d => b, c
item item (not included).

from: Item from which to begin the extraction. If not specified, extracts from
the beginning of the list.

to: Item before which to end the extraction. If not specified, extracts from the
end of the list.

Sort Sorts an entire list. Supports strings and numbers. b, c, a => a, b, c

descending: 2.1, 1.2, 3.4 descending: true

true to sort in descending order, default is false. => 3.4, 2.1, 1.2

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 422/1003
5/8/24, 9:18 AM PDF Export

Name Description Example

Get index Get item at the given index. b, c, a index: 0 =>b

index: Index of the item to get. b, c, a index -1 => nil

Splice Adds or removes items to/from an array. a, b, c, d,index: 1 deleteCount: 2=> a, d

index: (required) Zero-based index at which to begin add/remove items. a, b, c, d, index: 2 item: w

deleteCount: Number of elements to remove from ‘index’, default is 0. => a, b, c, w, d

item: Item to add to the array after ‘index’ position.

Index of Returns the first index of the element in the array, or -1 if not found. a, b, a, c, d, a, b, item: b => 1

item: Item to locate in the array. a, b, a, c, d, a, b, item: a fromLast: true => 5

fromLast: true to get the index from last. (default is false). a, b, a, c, d, a, b, item: w => -1

Get field Extracts a given field from the given object. {“name”: “john”, “color”: “white”} field:
“color” “white”
field: (required) The field to extract from the result

Stringify Converts the given item to a string. { “name”:“john”, “color”: “white” }

=>‘{“name”:“john”,“color”:“white”}’

Count Returns the number of elements. b, c, a => 3

null => 0

a => 1

Join Concatenates all elements. b, c, a separator: , => b,c,a

separator: Specifies a string to separate each pair of adjacent elements of b, c, a => bca
the array, default is an empty string.

String: Transforms strings. To make regex case non-sensitive, use the (?i) prefix (for example (?i)yourRegexText. The following table describes string
examples.

Name Description Example

replace Returns a string with some or all matches of a regex pattern, and replaces pluto,is,not,a,planet regex: “,” replaceWith:
match with a specified string. “;” =>“pluto;is;not;a;planet”

regex: A regex pattern to be replaced by the replaceWith argument. “pluto is not a planet” regex .*to replaceWith vega
=> vega is not a planet
replaceWith: The string that replaces the string specified in the toReplace
argument, default is an empty string.Detailed RegEx syntax can be found on
https://github.com/google/re2/wiki/Syntax

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 423/1003
5/8/24, 9:18 AM PDF Export

Name Description Example

Substring Returns a subset of a string between one index and another, or through the pluto is not a planet from: 4 to: 10 => o is n”
end of the string.

from (required): An integer between 0 and the length of the string, specifying
the offset into the string of the first character to include in the returned
substring.

to (optional): An integer between 0 and the length of the string, which

specifies the offset into the string of the first character not to include in the
returned substring.

Split Splits a string into an array of strings, using a specified delimiter string to hello world,bye bye world => hello world, bye bye
determine where to make each split. world

delimiter: Specifies the string which denotes the points at which each split hello world delimiter
should occur, default delimiter is,.
=> hello, world

Split & trim Splits a string into an array of strings and removes whitespace from both hello & world delimiter: & => hello, world
ends of the string, using a specified delimiter string to determine where to
make each split.Argumentsdelimiter: Specifies the string which denotes the
points at which each split should occur (default delimiter is”,”).

From string Returns a subset of a string from the first from string occurrence. pluto is not a planet from: pluto is => not a
planet
from (required): String to substring from.

To string Returns a subset of a string until the first to string occurrence. pluto is not a planet to: a planet => pluto is not

to (required): String to substring until.

concat Returns a string concatenated with given prefix and suffix. night prefix good => good night

prefix: A prefix to concat to the start of the argument. night suffix shift=> night shift

suffix: A suffix to concat to the end of the argument.

Number: Transforms a number. Examples:

Name Description Example

Floor Returns the highest integer less than or equal to the number. 1.2=> 1

Ceil Returns the lowest integer greater than or equal to the number. 1.2 =>2

Round Returns the nearest integer, rounding half way from zero. 7.68 => 8

2.43 => 2

2.5 => 3

Absolute Returns the absolute value of the given number. -2 => 2

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 424/1003
5/8/24, 9:18 AM PDF Export

Name Description Example

Decimal precision Truncates the number of digits after the decimal point, according to 8.6666 by: 2 => 8.66
the by argument.

by: Number of digits to keep after the decimal point, default is 0.

Modulus The modular operator (%) returns the division remainder. 20 by: 3=> 2
(remainder)
by (required): Modulo by, default:0

To percent Converts a number to a percent. 0.22 => 20

withsign: Specify true to include %. Default is false 0.22 withsign: true =>20%

Quadratic equation Returns the result of the Quadratic Formula.b (required): The b 1 b: 3 c: 2=> -1.00, -2.00
number of: ax2 + bx + c = 0, default is 0.c (required): The c number
of: ax2 + bx + c = 0, default is 0. 3 b: 2 c: 4=> (-0.333 +1.106i), (-0.333 -1.106i)

4.10.9.5 | Create custom filter and transformer operators

Abstract

Create a custom filter or transformer in Cortex XSIAM. Custom scripts, filter operator script, transformer operators playbooks mapping automation tags

If you require a filter or transformer operator that is not provided out of the box, you can create your own by creating a script and then adding to the operators
window.

1. Select Incident Response → Automation → Scripts → New Automation.

2. Type a meaningful name for the script, and click Save.

3. To create a filter operator script, do the following:

a. In the Tags field, add the filter tag.

If you want a custom transformer that operates on an entire array rather than on each individual item, you need to add the entirelist tag.

b. In the Arguments section, add the following arguments:

Argument Description

left Mark as mandatory. This argument defines the left-side value of the transformer operation. In this example,
this is the value being checked if it falls within the range specified in the right-side value.

right Mark as mandatory. This argument defines the right-side value of the transformer operation. In this
example, this is the range to check if the left-side value is in.

c. Add the script syntax and save.

4. To create a transformer operator script do the following:

a. In the Tags field, add the transformer tag.

b. In the Arguments section, add the following arguments:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 425/1003
5/8/24, 9:18 AM PDF Export

Argument Description

value Mark as mandatory. The value to transform. In this example, this is the UNIX epoch timestamp to convert to ISO
format.

c. Add the script syntax and save.

5. Go to the filters and transformers window and select the operator.

4.10.10 | Scripts

Abstract

Create and edit a script including detach and attach, automation settings, etc.

Scripts perform specific actions and are comprised of commands, which are used in playbook tasks and when running commands in the War Room.

In the Scripts page (Automation → Scripts), you can view, edit, and create scripts in JavaScript, Python, or PowerShell. When creating a script, you can access
all Cortex XSIAM APIs, including access to alerts, investigations, share data to the War Room, etc. Scripts can receive and access arguments, and can be
password protected.

You can use the Script Helper when creating a script, which provides a list of available commands and scripts, ordered alphabetically.

Detach and Attach Scripts

When installing a script from a content pack, by default, the script is attached, which means that it is not editable. To edit the script, you need to either make a
copy or detach it.

NOTE:

You can enable/disable the script in the Settings, without having to detach or duplicate the script.

While the script is detached, it is not updated by the content pack. This may be useful when you want to update the script without breaking customization. If you
want to update the script through content pack updates, you need to reattach it, but any changes are overridden by the content pack on upgrade. If you want to
keep the changes, make a copy before reattaching.

Search for Scripts

In the Scripts page, use free text in the search box to find a script. You can search using part or all of the scripts's name or tag. You can also search for an exact
match of the script name by putting quotation marks around the search text. For example, searching for "AddEvidence" returns the script with that name. You
can search for more than one exact match by including the logical operator "or" in between your search texts in quotation marks. For example, searching for
"AddEvidence" or "AddKeyToList" returns the two scripts with those names. Wildcards are not supported in free text search.

Script Settings

In Script settings dialog box, you can define the following information:

Basic

Parameter Description

Name An identifying name for the script.

Language type Select the script language type.

Description A meaningful description for the script.

Tags Predefined script identifiers that determine where the script is available. For example, to use this script as
a phishing script, tag it with the phishing tag.

Enabled Whether the script is available for playbook tasks and indicator types.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 426/1003
5/8/24, 9:18 AM PDF Export

Arguments

Parameter Description

Argument An identifying name.

Description A meaningful description for the argument.

Mandatory Makes the argument mandatory.

Initial value The initial default value for the argument.

Sensitive Makes the argument case sensitive.

Is array Specifies that the argument is an array.

List options CSV list of argument values.

You can define the outputs according to string, number, date, boolean, etc. For more information, see Context and Outputs. The Important field is for legacy
compatibility only.

Permissions

Parameter Description

Password Protect Enables you to add a password for the script, which will be required when running the script from the CLI.

Advanced

Parameter Description

Timeout (seconds) Time (in seconds) before the script times out. Default is 180.

Docker image name For Python automation, the name of the Docker image to use to run the script.

Run on a separate container Runs the script on a separate container.

4.10.10.1 | Common scripts to use in other scripts

Topic Not Found

4.10.11 | Configure a sub-playbook loop

Abstract

Configure a sub-playbook to run in a loop. Cortex XSIAM sub-playbook looping

Looping uses sub-playbooks to create loops within a parent playbook. When running the loop, the values are calculated based on the context data for the sub-
playbook and not the parent playbook. Loops are like conditions. If the condition is met, the playbook quits the loop and exits.

In the parent playbook (the task that contains the sub-playbook), configure when to exit the loop by selecting one of the following options:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 427/1003
5/8/24, 9:18 AM PDF Export

For Each Input: The loop exits automatically when the last item in the input is executed.

If the input is a single item, the sub-playbook runs once, but if the input is a list of items (such as a list of alert IDs), the sub-playbook runs as many
times as there are items in the list. Each iteration of the sub-playbook uses the next item in the list as the input.

If there are multiple input lists with the same amount of items, the sub-playbook runs once for each set of inputs.

If there are multiple input lists with different amounts of items, the sub-playbook runs the first set of inputs, followed by the second, third, etc until the
end. For example:

Input Value

Input x 1,2,3,4

Input y a,b,c,d

Input z 9

The first loop: 1, a, 9

The second loop: 2, b

The third loop: 3, c

The fourth loop: 4, d

Built-in or Choose Loop Automation: The loop exits based on a condition. The playbook does not loop through the inputs but takes the inputs as a whole.

NOTE:

Consider the following when adding a loop:

The maximum number of loops (default is 100). A high amount or a high wait time combined with a large number of incidents may affect performance.

Periodically check looping conditions to ensure they are still valid for the data set.

When the task input is an array, it is iterated automatically (no need to define a loop).

1. In the Playbooks page, select the parent playbook that contains the sub-playbook task you want to run the loop.

2. Click Edit.

If the Playbook is installed from a content pack, you need to either detach or duplicate the playbook, before editing.

3. Select the task that contains the sub-playbook for which you want to create the loop.

4. Click the Loop tab.

5. Click one of the following options to define when to exit the loop:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 428/1003
5/8/24, 9:18 AM PDF Export

None: The sub-playbook does not run multiple times.

Built-in: Define the following options for the built-in functions:

Option Description

Exit when Enables you to define when to exit the loop. Click {} and expand the source category. Hover over the required
source and click Filter & Transform to the left of the source to manipulate the data.

Equals (String) Select the operator to define how the values should be evaluated.

Max iterations The number of times the loop should run.

Sleep The number of seconds to wait between iterations.

recommends that you balance between the number of iterations and the number of seconds to wait between
iterations so you don't overload the server.

For each input: Runs the sub-playbook based on defined inputs. Enter the number of seconds to wait between iterations.

Choose Loop automation: Select the automation from the drop-down list to define when to exit the loop. The parameters that appear are applicable
to the selected automation.

6. To save the changes, click OK.

4.10.12 | Playbook polling

Abstract

Generic Polling playbook enables you to periodically poll the status of a process on a remote host.

When working with third party products (such as detonation, scan, search, etc.) you may need to wait for a process to finish on the remote host before
continuing. In these cases, the playbook should stop and wait for the process to complete on the third party product, and continue when it is done. You may not
achieve this via integrations or automations due to hardware limitations.

The GenericPolling playbook is used as a sub-playbook to block the execution of the master playbook until the remote action is complete. There are a number of
playbooks that use the Generic Polling playbook that come out-of-the box, or installed from a content pack such as:

Contex Polling - Generic: Polls a context key to check if a specific value exists.

Field Polling - Generic: Polls a field to check if a specific value exists.

QRadarFullSearch: Runs a QRadar query and return its results to the context.

Scan Assets - Nexpose: Scans according to asset IP addresses or host names from Rapid7 Nexpose, and waits for the scan to finish by polling the scan
status in pre-defined intervals.

Detonate File - JoeSecurity: Detonates one or more files using the Joe Security integration.

Generally polling is used in the following circumstances:

File detonation in a sandbox

URL detonation

Queries that take a long time to complete

Polling prerequisites

You need to use the GenericPolling playbook as a sub-playbook in a master playbook, such as Detonate File - JoeSecurity. The main playbook should follow
this structure:

1. Start Command: The task contains a command that fetches the initial state of the process and saves it to context. This command starts the process that
should be polled. For example:

Detonation: Submits a sample for analysis (detonated as part of the analysis), using the joe-analysis-submit-sample command.

Scan: Starts a scan for specified asset IP addresses and host names using the nexpose-start-assets-scan command.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 429/1003
5/8/24, 9:18 AM PDF Export

Search: Searches in QRadar using AQL using the qradar-searches command.

2. Polling Command: The task contains the GenericPolling sub-playbook that polls for an answer. For example:

Detonation: After the file is submitted to Joe Security, the playbook polls for specific information for analysis, such as ID, status, comments, errors,
SHA-256 hash details.

Scan: After the scan runs in Nexpose, using the playbook polls for scan information such as the scan type, the number of assets found, the scan ID,
etc.

Search: The playbook runs the qradar-get-search to poll for the search ID and status.

3. Results Task: Returns the results of the operation. The task contains the results that were polled, which are added to context. For example, after polling
JoeSecurity, the results are added to context.

For information about the GenericPolling playbook inputs, such as Ids, Interval, and dt, etc., see Playbook inputs.

Generic polling example

This example uses the Detonate File - JoeSecurity playbook from the Joe Security content pack.

The Detonate File - JoeSecurity playbook detonates one or more files using the Joe Security integration and returns relevant reports to the War Room and file
reputations to the context data.

1. If you have not done so, go to Marketplace and download the Joe Security content pack.

2. Go Playbooks and search for Detonate File - JoeSecurity.

3. Open the JoeSecurity Upload File task. This task uses the joe-analysis-submit-sample command, which starts a new analysis of a file in Joe Security.
This is the Start command.

4. Open the GenericPolling task. This is the Polling command.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 430/1003
5/8/24, 9:18 AM PDF Export

Ids: Returns a list of Joe.Analysis.ID’s to poll.

PollingCommandName: The joe-analysis-info command returns information for a specified analysis, such as status, MD5, SHA256, vendor,
etc.

PollingCommandArgName: The webid argument name of the polling command.

dt: The filter for polling. This is defined as Joe.Analysis(val.Status!==’finished’).ID.

Joe.Analysis: The object to return.

(val.Status !==‘finished’).ID Gets the object that has a status other than ‘finished’, and then gets its ID field. The polling is done only once
the result is finished. Once finished, the dt filter returns an empty result, which triggers the playbook to stop running.

You can change the Status to: starting, running, or finished.

5. Open the JoeSecurity Get Info task. The joe-analysis-info command returns details of the IDs that have finished polling. This is the Results task.

6. Open the Set Context task. The context path to store the poll results is Joe.Analysis.

Limitations of generic polling

Global context is not supported.

Does not run from the Playground.

The GenericPolling playbook uses the ScheduleGenericPolling script, which must support a list argument.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 431/1003
5/8/24, 9:18 AM PDF Export

Troubleshoot playbook polling

The playbook is “stuck” on Waiting for polling to complete.

As generic polling schedules tasks are outside the context of the playbook (not visible in the playbook run), errors may appear only in the Alerts War
Room. Go to the War Room of the alert and check for errors or warnings related to GenericPolling tasks.

The GenericPolling task completes but the status has still not "finished".

If the timeout is reached, the playbook successfully finishes even if there are items that did not complete. Try increasing the timeout value for the
GenericPolling task.

The integration returns an ID not found error when running from the GenericPolling sub-playbook, but when running manually, it finishes successfully.

Some products cannot handle consecutive requests to query an action status right after the request to perform the action. After you initiate the action, try
adding a Sleep task before calling the GenericPolling sub-playbook.

4.10.13 | Create alert fields in a playbook

Abstract

Use the setAlert script to set and update all system alert fields.

Creating alert fields is an iterative process in which you create fields as you better understand your needs and the information available in the third-party
integrations you use. You initially define alert fields after the planning stage, with mapping and classification for how the alerts will be ingested from third-party
integrations into Cortex XSIAM. However, during the investigation you can also set and update alert fields using the setAlert script in a playbook task.

NOTE:

The setAlert script includes all available fields; use the scroll bar to see all the fields.

There are many fields already available as part of the Common Type content pack. Before creating a new alert field, check if there is an existing field
that matches your needs.

4.10.14 | Debugger

Abstract

The Playbook Debugger enables you to troubleshoot playbooks and test multiple scenarios.

The playbook debugger enables you to build and troubleshoot playbooks, by helping you find tasks that might fail and by testing different conditions, branches,
and input and output options. Common use cases include:

Playbook development - test and improve playbooks as you build them.

Proof of concept - begin to create and test playbooks even before all integrations are in place, by manually providing inputs and outputs as needed.

Error troubleshooting - use the debugger to find and fix issues if a playbook stops on an error.

Explore Marketplace playbooks - install content packs and use the debugger to see whether the included playbooks are relevant for your use case.

Building a playbook is an iterative process. The debugger provides a test environment where you can make changes to data and playbook logic and view the
results in real-time. You have the opportunity to see exactly what is written to the context at each step and which indicators are extracted.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 432/1003
5/8/24, 9:18 AM PDF Export

Debugger execution

The debugger runs the playbook with the permissions of the logged in user. When the user sets breakpoints, skips tasks, or overrides inputs or outputs, those
changes only apply to the individual user’s session and do not permanently change the playbook. Using an existing alert as test data does not affect the original
alert or change the original context data. When tasks run, however, they execute the same as they would without the debugger. For example, if you run the
debugger and a task adds an item to a list, that item will be in the real list, accessible across for all users with permission to view that list.

Test data

The debugger uses test data to execute the playbook, so you can see what your expected results would be. There are three options for test data.

1. New Mock Alert - by default, the debugger runs using an empty mock alert. An empty mock alert is useful to test simple functionality, such as a playbook
that does simple tasks such as parsing inputs.

2. Playground - you can load the contents of the Playground as test data, enabling you to use uploaded files and custom context data for testing purposes.

3. Existing Alert - you can select an existing alert. For example, when debugging a phishing playbook, you might want to use an existing phishing alert that
came from the mail listener integration. Using an existing incident in the debugger does not change the original incident.

Inputs and outputs

The debugger enables you to temporarily override inputs and outputs for a playbook run and to view the results in real time. When you override an input or
output in the debugger, the change is saved only in the debugger view and only for the user who made the change. If, after testing, you decide to keep the
temporary changes you made, and apply them permanently to the playbook for all users, you need to cancel the override and edit the task. Tasks can be edited
directly in the debugger or outside of the debugger using the standard playbook editing options.

Breakpoints

Breakpoints are used to pause playbook execution before a specific task. When the playbook is paused, the Debugger Panel displays the current state of
context data, indicators, and task information.

At the breakpoint, you can override inputs and outputs to see how changes affect playbook execution.

In addition, conditional breakpoints set conditions for the playbook to proceed. The playbook only pauses if your condition is met, letting you manipulate data to
see how different scenarios impact how the playbook runs. For example, you can set a conditional breakpoint to pause the playbook when a phishing incident
targets a member of a VIP asset list. If there are no VIPs in this incident, the execution does not pause. If there is a VIP in the incident, you can check that the
member was properly identified by the playbook task.

Skip tasks

For testing purposes, you might not want to close a port in a firewall, delete an email, or send a notification to a manager. For this purpose, you can skip a task.
In other cases, you might skip a task where the integration has not yet been configured. By skipping a task and overriding the output, you can provide the data
necessary to complete the playbook run. When you skip a conditional task, you can choose which branch runs after the skipped task, enabling you to test
different outcomes for multiple branches.

4.10.14.1 | Debug a playbook

Abstract

Set breakpoints, conditional breakpoints, skip tasks, and input and output overrides in the playbook debugger

The playbook debugger enables you to build, test, and troubleshoot playbooks. To open a detached system playbook, a copy of a system playbook, or a custom
playbook in the debugger, select the playbook and click Edit. To open an attached playbook in the debugger, select the playbook and click View to access the
debugger. While editing a playbook, sub-playbooks can be opened directly in the debugger by choosing Open sub-playbook in the task pane.

NOTE:

The debugger runs with the permissions of the logged in user. If a user runs potentially harmful commands, they are logged to the audit trail with the user’s
username.

In some cases, you may have a playbook that includes two or more copies of the same sub-playbook. When you set breakpoints, override inputs or outputs, or
skip tasks in sub-playbook A, the same changes apply to the identical sub-playbook B. In addition, if you set a breakpoint, override inputs or outputs, or skip
tasks within a loop in a playbook, that setting will be applied every time the loop executes.

Choose test data

By default, the debugger runs the playbook using an empty mock alert, or loads the contents of an existing alert. Click the Debugger Panel and in the Test data
field, select an existing alert. The last fifty alerts appear in the drop-down, as well as any alerts you own or are a member of, or that you have participated.

NOTE:

Using an existing alert in the debugger does not affect the original alert or change the original context data.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 433/1003
5/8/24, 9:18 AM PDF Export

Start and stop the debugger

To start the debugger, click Run. When you click Stop, the debugger stops, and the context data is reset to the original alert data. In the case of a new mock
incident, the context data is cleared and the context is empty. Any breakpoints, skips, or overrides you applied are still available.

Set a breakpoint

Breakpoints help you understand task results. Breakpoints do not apply to manual tasks, as a manual task will always pause the playbook run unless you skip
the manual task. When the playbook reaches a breakpoint, no new tasks begin, but parallel tasks that have already begun continue. Breakpoints can be set in
both the parent playbook and sub-playbooks.

1. To set a breakpoint, go to a task and click on the breakpoint button. When a breakpoint is set, the breakpoint button changes to orange.

2. Once a breakpoint is reached, click on the task to Override inputs and outputs if needed.

3. When you are finished with the task, run the debugger, and in the task, select an option for the playbook to continue.

For an automated task, you have the options Run automation now or Complete Manually. If you choose Complete Manually, click on Mark Completed for
the playbook to continue.

For a task that is a sub-playbook, click Run playbook now for the playbook to continue.

For a conditional task, choose which branch the playbook should follow and click Mark Completed for the playbook to continue. The default branch is else.

When the playbook reaches a breakpoint, the task has an orange line at the top to indicate the breakpoint.

Breakpoint alerts are also displayed at the top of the playbook, enabling you to navigate between multiple breakpoints that have been reached in the
playbook or sub-playbooks.

Override inputs and outputs

You can override task inputs or outputs before or during a playbook run, to troubleshoot tasks that fail, and test different options for playbook development. If
you override an input or output during a playbook run, the override is applied to the run if the playbook has not yet reached that task. If you edit (permanently
change) inputs during a playbook run, the changes only take effect the next time you run the playbook. You can not use filters or transformers for overrides.

1. To override an input or output, open the task and hover over any existing input or output. Click Override Input.

2. Enter a new input or output that will be used only in the debugger. For output overrides, you can enter a value, an array of values, or JSON. For input
overrides, you can only enter plain text.

3. Click OK to save your changes.

The playbook task card displays a label indicating that the task input or output has been overridden.

Skip tasks

You might need to skip tasks within a playbook:

To check if a particular task is causing an issue.

To avoid performing tasks not relevant for your troubleshooting.

To skip tasks with potentially harmful results such as blocking a user or opening a port in a firewall.

To skip tasks for integrations that are not yet configured.

1. To skip a task, click the ‘skip’ button for the task.

When a task is set to skip, the ‘skip’ button will be orange.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 434/1003
5/8/24, 9:18 AM PDF Export

2. If the output is required for the playbook to proceed, click on the task and Override inputs and outputs.

View context data, indicators, and task information

Within the debugger panel, you can view the context data during the playbook run, as well as the indicators as they are extracted.

Click on any completed task in the playbook, while the debugger is running.

View the results of that task in the debugger panel.

4.10.15 | Playgrounds

Abstract

Non-production environment where you can develop and test scripts.

The Playground is a non-production environment where you can safely develop and test scripts, APIs, commands, and more. It is an investigation area that is
not connected to a live (active) investigation. To erase a playground and create a new one, in the Cortex XSIAM CLI run the /playground_create command.

4.10.16 | Best practices

Abstract

Best practices for working with playbooks.

We recommend the following practices to ensure your playbooks run optimally.

Use quiet mode

Run playbooks in quiet mode to reduce the incident size and execute playbooks faster. For playbooks running in jobs, indicator enrichment should be done in
quiet mode.

Limit indicator extraction

When configuring your integration, set indicator extraction to none and extract indicators only in specific tasks where required.

Break up large playbooks into sub-playbooks

If playbooks have more than thirty tasks, break the tasks into multiple sub playbooks. Sub playbooks can be reused, can be managed easily when upgrading,
and make it easier to follow the main playbook.

Update scripts

Update scripts and integration commands in playbook tasks to their most current version. Scripts that have updates are designated by a yellow triangle.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 435/1003
5/8/24, 9:18 AM PDF Export

NOTE:

When a script is deprecated, it is not removed from Cortex XSIAM or stop playbooks running with an error.

Remove unused playbook tasks

For production playbooks, remove playbook tasks that are not connected to the playbook workflow.

4.11 | Lists
Abstract

Create and manage lists in Cortex XSIAM.

A list is a data container where you can globally store data within Cortex XSIAM. The data can be in any text format, and you can even store files. Use lists to
manage important users in your organization, sensitive endpoints, SOC shifts, and more. These lists can be used dynamically within different investigations to
provide global context to each relevant alert type.

4.11.1 | Work With Lists

Abstract

Manage lists in Cortex XSIAM that can be accessed by automations, playbooks, etc. List commands, lists arrays separators delimiters

The data within lists can be accessed in scripts, playbooks, or any other place where the context button appears (double-curly brackets). In a playbook, you can
access the data in a list via the context button under Lists, or by using the path ${lists.<list_name>}. You can use a list in a playbook to modify, filter, or
transform parts of a list and then update the list with the changes or use the changed data in subsequent playbook tasks. You can also use a playbook task to
iterate over list items.

NOTE:

The maximum list size is 209715 characters.

In the Lists page (Settings → Configurations → Object Setup → Lists) you can do the following

Add a list

When you Create a List, you can select the content type (Text, Markdown, HTML, JSON or CSS).

If a valid JSON is stored within a list, it will automatically be parsed as a JSON object when you access it from within a playbook. Depending on how you
store the data, you may need to Transform a List into an Array.

When you access a list using the built-in list or base pack commands, the data is considered to be comma-separated. When using built-in commands, you
do not need to split the list. However, if you want to use non-built-in commands, such as in an automation or to loop over list items, you need to split the
list using a transformer.

Upload/download a list.

In a content repository, lists can be pushed to a production environment. When the list is pushed to production, you cannot edit the list, but you can
change it from the CLI (such as the addToList command) or in a playbook. If a list has been pushed to production that already exists with the same
name, you can resolve the conflict. You can still create lists in production.

Lists can be included in a content pack and be installed from Marketplace.

Use Cases

These are some common use cases for creating and using lists in Cortex XSIAM.

A list of allowed executable files against which to check potentially malicious executable files.

An HTML template that you can define to use as part of a Communication task.

Store data objects, for example JSON, that you can call as inputs for scripts and playbooks.

Use the getList or addToList commands in a script to take action based on the list data, for example, res = demisto.executeCommand("getList",
{"listName": demisto.args()["listName"]}) returns all list entries in the script.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 436/1003
5/8/24, 9:18 AM PDF Export

List commands

You can use the following list commands in scripts and playbook tasks.

Command Description Arguments

getList Retrieves the contents of the specified list. listName: The name of the list for which to retrieve the
contents.

createList Creates a list with the supplied data. listName: The name of the list to which to add items.

listData: The data to add to the new list.

addToList Appends the supplied items to the specified listName: The name of the list to which to append
list. If you add multiple items, make sure you items.
use the same list separator that the list
currently uses, for example a comma or a listData: The data to add to the specified list. The
semicolon. data will be appended to the existing data in the list.

setList Adds the supplied data to the specified list listName: The name of the list to which to add items.
and overwrites existing list data.
listData: The data to add to the specified list. The
data overwrites the existing data in the list.

removeFromList Removes a single item from the specified listName: The name of the list from which to remove
list. an item.

listData: The item to remove from the specified list.

For example, the ManageOOOUsers script uses the getList, createList, and setList commands.

register_module_line('ManageOOOusers', 'start', __line__())

def _get_current_user():
current_username = demisto.executeCommand("getUsers", {"current": True})
if isError(current_username):
demisto.debug(f"failed to get current username - {get_error(current_username)}")
return
else:
return current_username[0]["Contents"][0]['username']

def main():
# get current time
now = datetime.now()

# args
list_name = demisto.getArg("listname")
username = demisto.getArg("username")

option = demisto.getArg("option")
days_off = now + timedelta(days=int(demisto.getArg("daysoff")))
off_until = days_off.strftime("%Y-%m-%d")

# update list name to start with 'OOO', so we can't overwrite other lists with this
if not list_name.startswith("OOO"):
list_name = f"OOO {list_name}"

current_user = _get_current_user()
if not current_user and not username:
return_error('Failed to get current user. Please set the username argument in the script.')

if not username:
# Current user was found, running script on it.
username = current_user
else:
# check if provided username is a valid user
users = demisto.executeCommand("getUsers", {})
if isError(users):
return_error(f'Failed to get users: {str(get_error(users))}')
users = users[0]['Contents']

users = [x['username'] for x in users]

if username not in users:
return_error(message=f"{username} is not a valid user")

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 437/1003
5/8/24, 9:18 AM PDF Export

# get the out of office list, check if the list exists, if not create it:
ooo_list = demisto.executeCommand("getList", {"listName": list_name})[0]["Contents"]
if isError(ooo_list):
return_error(f'Failed to get users out of office: {str(get_error(ooo_list))}')

if "Item not found" in ooo_list:

demisto.results(demisto.executeCommand("createList", {"listName": list_name, "listData": []}))
ooo_list = demisto.executeCommand("getList", {"listName": list_name})[0]["Contents"]

# check status of the list, and add/remove the user from it.
if not ooo_list:
list_data = []
else:
list_data = json.loads(ooo_list)
if option == "add":
# check if user is already in the list, and remove, to allow updating
list_data = [i for i in list_data if not (i['user'] == username)]
list_data.append({"user": username,
"offuntil": off_until,
"addedby": current_user if current_user else 'DBot'})
else:
# remove the user from the list.
list_data = [i for i in list_data if not (i['user'] == username)]

set_list_res = demisto.executeCommand("setList", {"listName": list_name, "listData": json.dumps(list_data)})

if isError(set_list_res):
return_error(f'Failed to update the list {list_name}: {str(get_error(set_list_res))}')

# welcome back, or see ya later!

if option == "add":
demisto.results(f"Vacation mode engaged until {off_until}, enjoy the time off {username}")
else:
demisto.results(f"Welcome back {username}, it's like you never left!")

if __name__ in ('__builtin__', 'builtins', '__main__'):

main()

register_module_line('ManageOOOusers', 'end', __line__())

4.11.2 | Work with JSON Lists

Abstract

Manage JSON lists inCortex XSIAM that can be accessed by automations, playbooks, etc. List commands, lists arrays separators delimiters

List data can be stored in various structures, including JSON. When you access a valid JSON file from within a playbook, it is automatically parsed as a JSON
object (list). Working with JSON files in playbooks typically involves the following activities:

Extracting the data from a JSON object

Extracting a subset of the data

Filtering extracted data

Applying transformers to extracted data

See Filters and transformers for more details.

Extract the Data from a JSON Object in a List

You can access lists from JSON objects similar to how you access incident context, including using automations or playbook tasks.

In this example, create a JSON list and use the Set automation to extract the data from the list.

1. Create a List

a. Select Settings → Configurations → Object Setup → Lists → Add a List.

b. In the Name field, type Test1.

c. In the Content Type, select JSON.

d. Add the following content.

{
"domain": {
"name": "mwidomain",
"prod_mode": "prod",
"user": "weblogic",
"admin": {
"servername": "AdminServer",
"listenport": "8001"
},
"machines": [
{

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 438/1003
5/8/24, 9:18 AM PDF Export

"refname": "Machine1",
"name": "MWINODE01"
},
{
"refname": "Machine2",
"name": "MWINODE02"
}
],
"clusters": [
{
"refname": "Cluster1",
"name": "App1Cluster",
"machine": "Box1"
},
{
"refname": "Cluster1",
"name": "App2Cluster",
"machine": "Box2"
}
],
"servers": [
{
"name": "ms1",
"port": 9001,
"machine": "Box1",
"clusterrefname": "Cluster1"
},
{
"name": "ms2",
"port": 9002,
"machine": "Box2",
"clusterrefname": "Cluster2"
},
{
"name": "ms3",
"port": 9003,
"machine": "Box1",
"clusterrefname": "Cluster1"
},
{
"name": "ms4",
"port": 9004,
"machine": "Box2",
"clusterrefname": "Cluster2"
}
]
}
}

e. Save the list.

2. Create a playbook task with the Set automation.

a. Go to Incident Response → Automation → Playbooks.

b. Select New Playbook, name the playbook, create a task, and provide a task name.

c. In the Automation field, select the Set automation.

The Set automation script sets a value in context under the key entered.

d. In the key field, define a context key name for the data. For example, JSONData.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 439/1003
5/8/24, 9:18 AM PDF Export

e. In the Value field, set the list you want to extract by clicking the curly brackets.

f. Click Filters And Transformers.

g. In the Get field, click the curly brackets, and in the LISTS section, select the list you created in step 1.

h. Click Test.

i. In the Fetch data field, select an alert to test the data.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 440/1003
5/8/24, 9:18 AM PDF Export

j. Click Test.

In this example, you can see that the test results has found the list data.

k. When the test completes, click Done Testing.

l. Save the task and playbook.

3. Check that all the data is stored in the context key you defined by testing the playbook using the debugger.

1. Click Run.

2. Open the Debugger Panel.

The key you defined (JSONdata) holds all the data in context from the JSON object.

Extract a Subset of the Data

In general, you can extract subsets of context data in a playbook to analyze a specific information set. This also applies to working with lists, for example
extracting a subset of the data from a JSON object. In this example, we want to extract server information from the list created in Extract the Data from a JSON
Object in a List.

1. Go to Incident Response → Automation → Playbooks.

2. Select New Playbook, name the playbook, create a task, and provide a task name.

3. In the Automation field, select the Set automation.

The Set script sets a value in context under the key entered.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 441/1003
5/8/24, 9:18 AM PDF Export

4. In the key field, define a context key name for the data. For example, JSONDataSubset.

5. In the value field, set the list you want to extract by clicking the curly brackets.

6. Click Filters And Transformers.

7. In the Get field, enter lists.Test1.domain.servers.

8. Click Test.

9. In the Fetch data field, select an alert to test the data.

10. Click Test.

11. When the test completes, click Done Testing.

12. Save the task and the playbook.

13. Check that all the data is stored in the context key you defined by testing the playbook using the debugger.

1. Click Run.

2. Open the Debugger Panel.

The key you defined (JSONDataSubset) holds the subset of the data in context from the JSON object.

Filter Extracted Data

You can filter the data subset you extracted to analyze extracted information on a more granular level. In this example, you want to filter Box1 information from
the list created in Extract the Data from a JSON Object in a List.

1. Re-open the task and click the contents of the value field.

2. Under Filter, click + Add Filter.

3. Set the condition you want to filter. In this example, retrieve the list of machines named Box1 from Test1 list by setting the filter
lists.Test1.domain.servers.machine Equals Box1.

4. Click Test.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 442/1003
5/8/24, 9:18 AM PDF Export

5. Check whether the data subset was accessed successfully by selecting the data source from an alert. You can see the results returned machine: Box1.

You can also run the debugger and view the context data.

Apply Transformers to Extracted Data

In general, in a playbook task, you can transform (apply changes) to the data you extracted. This also applies for working with lists, for example, to transform
extracted data from a JSON object. Also, depending on how you store the data, you may need to Transform a List into an Array. In this example you want to
extract the first element in the list and transform the data to upper case from the list created in Extract the Data from a JSON Object in a List.

1. Re-open the task and click the contents of the value field.

2. Keep the filter created in Filter Extracted Data.

3. In Apply transformers on the field, click Add transformer.

4. Set the transformation you want to apply to the extracted data.

1. Add the Get index (General) transformer to extract a specific machine element.

Set index: 0 to extract the first element from the list.

2. Add the To upper case (String) transformer.

The To upper case (String transformer does not work on lists, only on individual elements. Therefore, the Get index (General) transformer
needs to apply first before adding the To upper case (String transformer.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 443/1003
5/8/24, 9:18 AM PDF Export

5. Click Test.

6. Check whether the data subset was accessed successfully by selecting the data source from an alert. You can see the results returned BOX1.

You can also run the debugger and view the context data.

4.11.3 | Create a List

Abstract

Create predefined lists in Cortex XSIAM that can be parsed by and modified by scripts. Indicators exclusion list, internal IP ranges.

Lists can be created and modified to be used in scripts and War Rooms. A list can contain items of the same type in any format that would be useful. These are
later parsed by, and can be modified by, scripts. For example, you might need to create a list of emails, a list of known trusted IPs (allow list), JSON objects, etc.

1. Select Settings → Configurations → Object Setup → Lists.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 444/1003
5/8/24, 9:18 AM PDF Export

2. Type the name of the list.

3. From the dropdown list, select the Content Type.

4. Add content as required, For an example of a JSON list and how to use it, see Work with JSON Lists.

5. Save the list.

4.11.4 | Edit a List from a Content Pack

Abstract

Edit a list from a content pack by duplicating or by detaching it in Cortex XSIAM.

You can edit a list from a content pack (with a ) either by duplicating or by detaching it.

Detaching a list enables you to edit and save without having to duplicate the list. However, a detached list does not receive updated content in future Cortex
XSIAM content releases. If you reattach the list, it will be updated in the following content release and all edits will be deleted. If you need to retain the updated
list, duplicate and save it before reattaching.

To detach and edit a list from a content pack:

1. Select Settings & Info+Settings → Advanced → Lists.

2. Type the name of the system list you want to edit, for example CIDR - Allowedlist.

3. Select and then Detach List. In the confirmation window, click Detach.

4. Edit content as required.

5. Save the list.

6. To reattach, Select and then Reattach List. In the confirmation window, click Reattach.

4.11.5 | Transform a List into an Array

Abstract

Create a transformer to split a list into an array when adding or editing a task in a playbook or when mapping an instance in Cortex XSIAM.

You can create a transformer to split a list into an array when adding or editing a task in a playbook or when mapping an instance.

1. Go to Incident Response → Automation → Playbooks and create or edit a playbook

2. Create a new task.

3. In the Choose automation field, select the Set automation.

4. In the Key field, enter the key name.

5. For the value field, click {}

6. Add a Transformer.

1. Click Filters And Transformers.

2. In the Get field, click {}.

3. Expand the Lists node and select the list you want to transform.

4. In Apply transformers on the field section, click Add transformer.

5. Search for and select Split.

6. (Optional) In the delimiter field, type the delimiter used to separate the items in the string (default is ",").

7. Save the transformer.

7. Save the task and playbook.

For a practical example of using a transformer in a list, see Apply Transformers to Extracted Data.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 445/1003
5/8/24, 9:18 AM PDF Export

4.12 | Jobs
Abstract

Create a time-triggered job or a job triggered by delta in a feed.

Jobs enable you to run playbooks based on certain events or on a specific time and date. A job runs when it is triggered by one of the following jobs:

Time triggered job: Jobs can be time triggered and run at specific times. For example, schedule a time triggered job that runs nightly and removes expired
indicators.

Job triggered by delta in a feed: Jobs can be triggered according to an event and run when there are changes to a feed. For example, you can define an
event triggered job to run a playbook when a specified TIM feed finishes a fetch operation for new indicators. For an example, see Set up a Job to
Process Indicators.

IMPORTANT:

When configuring the playbook a job triggers, make sure the playbook closes the investigation before running a new job.

When you create a job, a job run is executed. One job can have multiple job runs. You can view the job run of a specific job or all jobs through the Jobs page. In
the Jobs page, you can see how many jobs are running, waiting, in error, etc. You can also take action such as creating a new job, edit, run, disable,etc. When
you select the job run, review the details and Work Plan, and take action in the War Room as required.

NOTE:

Administrators can only create jobs and view/edit job runs.

4.12.1 | Create a Time Triggered Job

Abstract

Create a time triggered or feed triggered job in Cortex XSIAM to run a playbook.

Time triggered jobs run at predetermined times. You can schedule the job to run at a recurring time or one time at a specific date and time. For example,
schedule a time triggered job that runs nightly and removes expired indicators.

NOTE:

To view a human readable description of a cron schedule for an existing job, change the table settings by clicking the settings icon and selecting Job
Schedule from the available columns.

1. Select Incident Response → Automation → Jobs → New Job.

2. Select Time triggered.

3. If you want the job to repeat at regular intervals, select Recurring and select the desired interval.

You can choose to run the job every X number of days, on specific days of the week, at a specific time and also choose a start date and an expiration
date. You have the option to configure the recurring job using a cron expression. To do so, after selecting the Recurring checkbox, click Switch to Cron
view and enter the expression. For assistance in defining the cron expression, click Show cron examples after switching to Cron view.

4. If you do not want to the job to repeat, Select date and time the job should run.

5. In the BASIC INFORMATION, section, add the required the following parameters:

Parameter Description

Name Enter a meaningful name for the job.

Owner Assign an owner to the job

Playbook Determine which playbook to run when the job is triggered.

Description Enter a meaningful description for the job.

6. In the QUEUE HANDLING section, select whether to notify the owner of the job if the job is triggered while a previous run of the job is active.

7. Select an option to use if the job is triggered while a previous run of the job is active:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 446/1003
5/8/24, 9:18 AM PDF Export

Don’t trigger a new job run.

Cancel the previous job run and trigger a new job run.

Trigger a new job run and execute concurrently with the previous run.

8. Create new job.

The job is added to the job runs table. Click the job to see details, Work Plan and in the War Room take action as required,

4.12.2 | Create a Job Triggered by delta in a Feed

A job triggered by delta in a feed (event triggered job) runs when a feed has completed an operation and there is a change in the content. You can define a job
to trigger a playbook when the specified feed or feeds finish a fetch operation that included a modification to the feed. The modification can be a new indicator, a
modified indicator, or a removed indicator. For example, you may want to update your firewall every time a URL is added, modified, or removed from the Office
365 feed.

NOTE:

A job triggered by delta in a feed runs only if there is a change in the feed, and does not run on a feed’s initial fetch. If this is the initial fetch, you can run the
playbook manually the first time and then set up an event triggered job for subsequent fetches.

If you want to trigger a job after a feed completes a fetch operation, and the feed does not change frequently, you can select the Reset last seen option in the
feed integration instance. The next time the feed fetches indicators, it will process them as new indicators in the system.

1. Select Incident Response → Automation → Jobs → New Job.

2. Select Triggered by delta in feed.

3. In the TRIGGERS section, select one of the following:

Any feed: The playbook runs when a modification is made to any feed.

Specific feeds: Select the feed instances that triggers the playbook to run when a modification is made to the specified feed instances.

4. In the BASIC INFORMATION section add the following parameters:

Parameter Description

Name Enter a meaningful name for the job.

Owner Assign an owner to the job run.

Playbook Determine which playbook to run when the job is triggered.

Description Enter a meaningful description for the job.

5. Create the new job.

The job is added to the job runs table. Click the job to see details, Work Plan and in the War Room take action as required,

4.12.3 | Set up a Job to Process Indicators

Topic Not Found

5 | Threat Intel Management

Abstract

Learn more about threat intel management capabilities.

The native threat intel management capabilities provide you with the ability to unify the core components of threat intel, including threat intel aggregation,
scoring, and sharing. Cortex XSIAM automates threat intel management by ingesting and processing indicator sources, such as feeds and lists, and exporting
the enriched intelligence data to SIEMs, firewalls, and any other systems that can benefit from the data. These capabilities enable you to sort through millions of
indicators daily and take automated steps to make those indicators actionable in your security posture.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 447/1003
5/8/24, 9:18 AM PDF Export

5.1 | Threat Intel Concepts

Abstract

Learn more about threat intelligence management (TIM) indicators.

Indicators are artifacts associated with alerts and are an essential part of the alert management and remediation process.

Fetch indicators

Cortex XSIAM includes integrations that fetch indicators from either a vendor-specific source, such as AutoFocus, or from a generic source, such as a CSV or
JSON file.

Common indicator data model

When indicators are ingested, regardless of their source, they have a unified, common set of indicator fields, including traffic light protocol (TLP), expiration,
verdict, and tags.

Indicator smart merge

The same indicator can originate from multiple sources and be enriched with multiple methods (integrations, scripts, playbooks, and so on). Cortex XSIAM
implements a smart merge logic to make sure indicators are accurately scored (verdict) and aggregated.

Indicator timeline

The indicator timeline is in table format and displays an indicator’s complete history, including the first seen and last seen timestamp, changes made to indicator
fields, and more.

Indicator expiration

When ingesting and processing millions of indicators on a daily basis, it’s important to control whether or not they are active or expired and to define how and
when indicators are expired.Cortex XSIAM offers multiple options to set indicator expiration.

Export indicators

You can export indicators as a hosted list, an EDL, or a TAXII collection. This enables your SIEM or firewall to ingest or pull the indicator list to update policy
rules. The supported list file types are JSON, CSV, and TXT.

Exclusion list

Indicators added to the exclusion list are disregarded by the system and are not created or involved in automated flows such as indicator extraction.

5.2 | Indicator Verdict

Abstract

Learn more about indicator verdicts and source reliability.

An indicator’s verdict is assigned according to the verdict returned by the source with the highest reliability. In cases where multiple sources with the same
reliability score return a different verdict for the indicator, the worst verdict is taken.

Indicator verdicts

Indicators are assigned a verdict on a scale of 0 to 3.

Score Verdict Color

0 Unknown Gray

1 Benign Green

2 Suspicious Orange

3 Malicious Red

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 448/1003
5/8/24, 9:18 AM PDF Export

Source reliability

The reliability of an intelligence-data source influences the verdict of an indicator and the values for indicator fields when merging indicators.

Indicator fields are merged according to the source reliability hierarchy. This means that when there are two different values for a single indicator field, the field
will be populated with the value provided by the source with the highest reliability score.

In rare cases, two sources with the same reliability score might return different values for the same indicator field. In these cases, the field is populated with the
most recently provided source, unless the field is the verdict. If two sources have the same reliability score and return different values for the verdict field, the
worse verdict is used.

For the field types Tags and Multi-select, all values are appended, and nothing is overridden.

Source Reliability Score Notes

Manual A+++ A user manually updates the verdict of an

indicator.

Reputation script A++ A script with the reputation tag that calculates
the verdict of an indicator. For example, the
DataDomainReputation script evaluates the
verdict of a URL or domain.

3rd-party enrichment A+ An integration or service that evaluates the

verdict of an indicator. For example, the
urlscan.io integration evaluates the verdict of a
URL.

Feed A: Completely reliable The feed reliability is applied at the integration

instance level.

B: Usually reliable

C: Fairly reliable

D: Not usually reliable

E: Unreliable

F: Reliability cannot be judged

Example 1

In this example, two third-party integrations, VirusTotal and AlienVault, return a different verdict for the same indicator. The indicator’s verdict will be Malicious
because VirusTotal’s reliability score is higher than AlienVault.

Integration Reliability Verdict Final Verdict

VirusTotal C - Fairly reliable Malicious Malicious

AlienVault D- Not usually reliable Benign

Example 2

In this example, two sources with the same verdict score return a different verdict for the same indicator. The indicator’s verdict will be Malicious because when
two sources have the same reliability, the worse verdict applies.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 449/1003
5/8/24, 9:18 AM PDF Export

Integration Reliability Verdict Final Verdict

TAXII Feed B - Usually reliable Malicious Malicious

CSV Feed B - Usually reliable Benign

5.3 | Indicator Ingestion

Abstract

Overview of how Cortex XSIAM indicators are detected and ingested.

The following table shows methods by which indicators are detected and ingested in Cortex XSIAM.

Method Description Classification And Mapping

Integration Feed integrations: Fetch indicators from a feed, for Indicator classification and mapping is done in the Feed
example TAXII, Unit 42, Office 365, etc. Integration code and not in the Cortex XSIAM Settings
→ Configurations → Object Setup → Indicators →
Enrichment integrations: Enhance the indicator, giving Classification & Mapping tab. For example, see the Unit
it more context and information, for example Unit 42us, 42 Intel Objects Feed integration.
VirusTotal, and Ipinfo.

Indicator extraction Indicators are extracted from selected incidents that flow into Only the value of an indicator is extracted, so no
Cortex XSIAM, for example from an integration, such as classification or mapping is needed.
EWS.

Manual Command line Data is inserted manually via the UI so no classification

or mapping is needed.
For example, in the Alert War Room, type
!CreateIndicatorsFromSTIX. If importing a STIX file, mapping is done via the STIX
parser code.
STIX file: Manually upload a STIX file on the Threat
Intel (Indicators) page.

5.4 | Indicator Rules

Abstract

Create detection and prevention rules using threat intelligence as a source.

Indicator rules allow you to use utilize indicators in the system for detection and prevention. Indicators can be used for real-time prevention on the agent and
server-side detection.

With the indicator rules, you can create rules based on filters that are applied as either SHA256 and MD5 prevention rules in specific Agent Prevention Profiles
or as file, IP address, and domain detection rules.

Indicator rules marked for detection and prevention will generate alerts that you can then track and investigate.

The Indicator Rules page displays the following fields for each rule:

Field Description

Rule ID Unique identifier for the rule.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 450/1003
5/8/24, 9:18 AM PDF Export

Field Description

Creation Date Timestamp of when the rule was created.

Modification Date Timestamp when the rule was edited.

Name Name of the rule.

Type Whether the rule is a Prevention or Detection type rule.

Target Hash, IP address, File, or domain value associated with the rule.

Severity Level of severity associated with the rule.

# of alerts Number of alerts generated by the rule.

Created by Email address of the user who created the rule.

Description Optional description associated with the rule.

Status Whether the rule is Enabled or Disabled.

Used in profiles Cortex XDR agent Restriction Profile associated with the rule.

1. Create an indicator rule.

Navigate to Detection & Threat Intel → Threat Intel Management → Indicator Rules → + Add Rule.

2. Select whether to create a Prevention or Detection Rule.

A Prevention Rule can be created based on SHA256 and MD5 types.

1. In the Create New Prevention Rule wizard, enter the mandatory Rule Name, Select Profiles For Prevention, and define the level of Severity for the
rule.

2. Filter and select one or more SHA256 and MD5 indicators to which to apply the rule to.

3. Review and Save your rule.

A Detection Rule can be created based on a file, IP address, and domain.

1. In the Create New Detection Rule wizard, enter the mandatory Rule Name and define the level of Severity for the rule.

2. Filter and select one or more files, IP addresses, and domain indicators to which to apply the rule to.

3. Review and Save your rule.

3. Manage your indicator rules.

In the Indicator Rules table, right-click a rule to perform the following actions:

Action Description

View related alerts View alerts generated by the rule.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 451/1003
5/8/24, 9:18 AM PDF Export

Action Description

Disable/Enable Depending on the current status, Disable or Enable the rule.

Edit Rule Modify the rule configurations.

Save as new Create a new rule using the current rule configurations.

Delete Delete the rule.

5.5 | Indicator Customization

Abstract

Learn more about the options available for customizing indicators.

Indicators are artifacts associated with incidents, and are an essential part of the incident management and remediation process.

To customize indicators, such as indicator types, fields, layouts, etc., go to Settings → Configurations → Object Setup → Indicators. You can see the following
tabs:

Types: Indicators are categorized by indicator type, which determines the indicator layout that is displayed and which scripts are run.

Fields: Add indicator fields to the indicator type and layouts. After creating the field, you can map the field to the relevant context data.

Layouts: You can view, import and export indicator layouts. You can add layouts to relevant indicator types. Provided you haven't selected Don't show in
the indicators layout, when creating or editing a field, you can see any custom indicator fields in the layout.

Classification & Mapping: View, map and classify any relevant indicator feeds, such as AWS feed, etc.

Exclusion List: Indicators added to the exclusion list are disregarded by the system and are not created or involved in automated flows such as indicator
extraction.

5.5.1 | Indicator Types

Abstract

Indicator types are determined by searching for predefined regular expressions (regex) in the Cortex XSIAM War Room or by user assignment.

Indicators are categorized by indicator type, which determines the indicator layout (fields) that are displayed and which scripts are run on indicators of that type.
To view and customize indicator types, go to Settings → Configurations → Object Setup → Indicators → Types.

Indicator types include:

IP Address

Domain

URL

File

Email

Host

CIDR

Malware

You can edit, create, export and import indicator types, disable and enable indicator types. For example, you may want to disable the File indicator and enable
separate indicator types for File MD5, File SHA-1, etc. For more information, see File Indicators.

5.5.1.1 | Create an Indicator Type

Abstract

In addition to the system-level indicator types, you can create custom indicator types in Cortex XSIAM.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 452/1003
5/8/24, 9:18 AM PDF Export

When you create a custom indicator type, you configure fields and settings that impact how indicators of that type are enriched, how they are expired, how the
verdict is calculated, etc.

Before you create a custom indicator type, you should familiarize yourself with the indicator type profile.

1. SelectSettings → Configurations → Object Setup → Indicators → New.

2. In the Attributes tab, add the required Indicator Type Profile parameters, such as name, regex, etc.

3. In the Custom Fields tab, map the custom indicator fields, as required.

5.5.1.2 | Indicator Type Profile

Abstract

Create or edit an indicator type, and configure fields that determine how the system interacts with indicators of that type.

Each indicator type has its own 'profile' that allows Cortex XSIAM to recognize it across the platform. Below are the related fields. During the indicator extraction
flow, the order of execution is a regex, formatting script, reputation command, and reputation script.

Field Description

Name A meaningful name for the indicator type.

Regex The regular expression (regex) by which to identify indicators for this indicator type.

Formatting Script Modifies how the indicator displays in Cortex XSIAM .

Formatting scripts must be tagged indicator-format in order to appear in the dropdown for the indicator
type.

Reputation Command Calculates the reputation of indicators of this type. The verdict (reputation) is only associated with the
specific indicator on which it’s run (not the indicator type). The command returns the reputation of the
indicator as an entry with entry context and in some cases also returns context values that can be
mapped to the custom fields of the indicator. The results of the reputation command do not print to the
war room in the indicator extraction flow.

Layout Select the indicator layout to use.

Reputation Script The output of the reputation script is a verdict score, which is used as the basis for the indicator
verdict. Reputation scripts must be tagged reputation in order to appear in the dropdown for the
indicator type.

Reputation scripts are user-created scripts that either:

The results of reputation scripts do not print to the war room in the extraction flow.

Enhancement Script The enhancement script is not part of the indicator extraction flow, but can be run manually or from
the Indicator Quick View page. Examples of enhancement scripts include an enrichment script, a
script that runs a search in a SIEM for the indicator, etc.

After indicators are identified, you can go to the indicator quick view, click the Actions button and run
an enhancement script directly on an indicator. In order for these scripts to be available in the drop-
down menu, they need the enhancement tag.

When you run an enhancement script, it is the equivalent of running the script at the CLI in the Alerts
War Room. The script can write to context, return an entry, etc.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 453/1003
5/8/24, 9:18 AM PDF Export

Field Description

Excluded these Integrations for the reputation Integrations to exclude when calculating the verdict, evaluating, and enriching indicators of this
command indicator type. Only applies to the indicator extraction and enrichment mechanism, does not apply
when directly running reputation commands such as !ip, !url, !domain, etc.

Indicator Expiration Method The method by which to expire indicators of this type. The expiration method that you select is the
default expiration method for indicators of this indicator type.

The expiration can also be assigned when configuring a feed integration instance, which overrides the
default method.

Never Expire: indicators of this type never expire.

Time Interval: indicators of this type expire after the specified number of days or hours.

Context path for verdict value (Advanced) When an indicator is extracted, the entry data from the command is mapped to the alert context. This
path defines where in context the data is mapped.

Context value of verdict (Advanced) The value of this field defines the actual data that is mapped to the context path.

Cache expiration in minutes (Advanced) The amount of time (in minutes) after which the cache for indicators of this type expire. The default is
4,320 minutes (three days). The cache enables you to limit API requests by only updating indicators
after a specific time period has passed. The cache can not be cleared manually.

NOTE:

Indicator cache expiration rules only apply to automatic enrichment, triggered by

the enrichIndicators command. If you run reputation commands, such as !ip, the commands
will execute and the indicator will be updated if there is new information, even if the cache has not
expired.

5.5.1.3 | File Indicators

Abstract

You can have a single file indicator for file objects in Cortex XSIAM or each file can have a hash as its own indicator.

Cortex XSIAM uses a single File indicator for file objects. As a result, files appear with their SHA256 hash, and all other hashes associated with the file, (MD5,
SHA1, and SSDeep) are listed as properties of the same indicator. In addition, when ingesting an alert through an integration, all file information is presented as
one object.

For example, when investigating an alert, in the Indicators field (Investigation or Case info tabs), click on a File indicator. You can see additional information for
that indicator, including:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 454/1003
5/8/24, 9:18 AM PDF Export

SHA256 - The SHA256 hash associated with this file.

MD5 - The SHA256 hash associated with this file.

SHA1 - The SHA1 hash associated with this file.

SHA512 - The SHA512 hash associated with this file.

Imphash - The imphash associated with this file.

SSDeep - The SSDeep hash associated with this file.

Size - The file size.

File Type - The file type.

File Extension - The file extension.

Associated File Names - The File.Name values associated with the indicator hash, based on File context objects created in (automatically populated).

Path - The file path.

Quarantined - Whether the file is quarantined.

Signed - Whether the file is signed.

Signature Copyright - The file signature copyright.

Signature Description - The file signature description.

Download URL - The file download URL.

Modified - The date and time the File indicator was last modified.

First Seen - The date and time the file was first seen in Cortex XSIAM .

If the file appears in a different alert with a different name and has any of the same hash values, it automatically associates with the original indicator.

NOTE:

A new File indicator only affects new indicators ingested to the Cortex XSIAM platform. Indicators that were already in continue to appear as their respective
hash-related indicators.

If you want to have each file hash appear as its own indicator, do the following:

1. Go to Settings → Configurations → Object Setup → Indicators → Types.

2. Select the File indicator and click Disable.

3. Select the following required hashes:

File SHA-256

File SHA-1

File MD5

SSDeep

4. Click Enable.

5.5.1.4 | Formatting Script

Abstract

Add a formatting script to an indicator type using OOTB examples or by specifying your own the script input and output.

A formatting script has the following main functions:

Validating the input (for example, checking that the Top Level Domain (TLD) is valid).

Modifying how the indicator appears in Cortex such as the War Room, Reports, etc.

After indicators are extracted according to the defined regex, the defined regex finds the indicator value and the formatting script modifies the string value, so it
can be used in Cortex XSIAM. For example the IP indicator uses the UnEscapeIPs formatting script, which removes any defanged characters from an IP
address, such as 127[.]0[.]0[.]1 to 127.0.0.1. In the Alert War Room, you can click on the IP address to view the extracted IP address. This extracted
indicator using the formatting script is added to the Threat Intel database.

To apply a formatting script to an indicator type: .

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 455/1003
5/8/24, 9:18 AM PDF Export

1. Go toSettings → Configurations → Object Setup → Indicators → Types.

2. Select the indicator type, and click Edit.

3. Select the desired formatting script.

Formatting scripts must have the indicator-format tag applied to appear in the list.

NOTE:

Formatting scripts for out-of-the-box indicator types are system level. This means that the formatting scripts for these indicator types are not configurable. To
create a formatting script for an out-of-the-box indicator type, you need to disable the existing indicator type and create a new (custom) indicator type. If you
configured a formatting script before this change and updated your content, this configuration will revert to content settings (empty).

Out-of-the-box Formatting Script Examples

In the Scripts page, there several out-of-the-box formatting scripts, including:

UnEscapeIPs

ExtractDomainAndFQDNFromUrlAndEmail

This script is used by the Domain indicator, extracts domains and FQDN from URLs and emails. It removes prefixes such as proofpoint or safelinks,
removes escaped URLs, and extracts the FQDN, etc.

ExtractEmailV2

CLI Execution Examples

!UnEscapeIPs input=127.0.0[.]1

!UnEscapeIPs input=127.0.0[.]1,8.8.8[.]8

!UnEscapeIPs input=${contextdata.indicators} (where the key contextdata.indicators in the context object, is an array)

Formatting Script Input

The formatting script requires a single input argument named input that accepts a single indicator value or an array of indicator values. The input argument
should be an array to accept multiple inputs and return an entry-result per input.

Argument Description

input Accepts a string or array of strings representing the indicator value(s) to be formatted. Will be accessed within the script using
demisto.args().get(‘input’, []).

In the script settings, the Is Array checkbox must be checked (see screenshot below).The script code must be able to handle a single indicator
value (as string), multiple indicator values in CSV format (as string) and an array of single indicator values (array).

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 456/1003
5/8/24, 9:18 AM PDF Export

Formatting Script Outputs

The indicators appear as a human readable format in Cortex XSIAM. The output should be an array of formatted indicators or an array of entry results (an entry
result per indicator to be created). The entry result per input can be a JSON array to create multiple indicators. If the entry result is an empty string, it is ignored
and no indicator is created.

Use the return_results function to generate the script output. For more information, see https://xsoar.pan.dev/docs/integrations/code-
conventions#return_results.

Output Code Examples

Single-value result:

results = CommandResults(
outputs_prefix='VirusTotal.IP',
outputs_key_field='Address',
outputs={
'Address': '8.8.8.8',
'ASN': 12345
}
)
return_results(results)

Multiple-value results:

results = [
CommandResults(
outputs_prefix='VirusTotal.IP',
outputs_key_field='Address',
outputs={
'Address': '8.8.8.8',
'ASN': 12345
}
),
CommandResults(
outputs_prefix='VirusTotal.IP',
outputs_key_field='Address',
outputs={
'Address': '1.1.1.1',
'ASN': 67890
}
)]
return_results(results)

Complete Formatting Script Example

In the following example, the RemoveEmpty script removes empty items, entries, or nodes from an array.

// pack version: 1.2.30

const EMPTY_TOKENS = argToList(args.empty_values);

function toBoolean(value) {
if (typeof(value) === 'string') {
if (['yes', 'true'].indexOf(value.toLowerCase()) != -1) {
return true;
} else if (['no', 'false'].indexOf(value.toLowerCase()) != -1) {
return false;
}
throw 'Argument does not contain a valid boolean-like value';
}
return value ? true : false;
}

function isObject(o) {
return o instanceof Object && !(o instanceof Array);
}

function isEmpty(v) {
return (v === undefined) ||
(v === null) ||
(typeof(v) == 'string' && (!v || EMPTY_TOKENS.indexOf(v) !== -1)) ||
(Array.isArray(v) && v.filter(x => !isEmpty(x)).length === 0) ||
(isObject(v) && Object.keys(v).length === 0);
}

function removeEmptyProperties(obj) {
Object.keys(obj).forEach(k => {
var ov = obj[k];
if (isObject(ov)) {
removeEmptyProperties(ov);
} else if (Array.isArray(ov)) {
ov.forEach(av => isObject(av) && removeEmptyProperties(av));
obj[k] = ov.filter(x => !isEmpty(x));
}
if (isEmpty(ov)) {
delete obj[k];
}
});
}

var vals = Array.isArray(args.value) ? args.value : [args.value];

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 457/1003
5/8/24, 9:18 AM PDF Export

if (toBoolean(args.remove_keys)) {
vals.forEach(v => isObject(v) && removeEmptyProperties(v));
}
return vals.filter(x => !isEmpty(x));

5.5.1.5 | Enhancement Scripts

Topic Not Found

5.5.1.6 | Reputation Scripts

Abstract

Apply reputation scripts to an indicator type for indicator enrichment.

Reputation scripts are user-created scripts that return the verdict of an indicator as a number. The number overrides the verdict returned from the reputation
command. The reliability of the score from a reputation script is by default A++ - Reputation script.

To apply a reputation script to an indicator type:

1. Go to Settings → Configurations → Object Setup → Indicators → Types.

2. Select the indicator type and click Edit.

3. Select the desired reputation script.

Reputation scripts must have the reputation tag applied to appear in the list.

NOTE:

The Reputation script overrides any default settings for the indicator that relates to the verdict.

Out-of-the-box Reputation Script Examples

In the Scripts page, there are several out-of-the-box reputation scripts, including:

CertificateReputation

cveReputation

MaliciousRatioReputation

SSDeepReputation

CLI Execution Examples

!CertificateReputation input=<value of the indicator>

!MalicioiusRationReputation input=<value of the indicator>

Reputation Script Input

The reputation requires a single input argument named input that accepts an indicator value.

Argument Description

input The indicator value.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 458/1003
5/8/24, 9:18 AM PDF Export

Reputation Script Outputs

Either a number or a dbotScore. It can either be a raw number which is the score, or a full entry with DBotScore.

from CommonServerPython import *

def main():
url_list = argToList(demisto.args().get('input'))
entry_list = []

for url in url_list:

entry_list.append({
'Type': entryTypes['note'],
'ContentsFormat': formats['json'],
'Contents': 2,
'EntryContext': {
'DBotScore': {
'Indicator': url,
'Type': 'Onion URL',
'Score': 2, # suspicious
'Vendor': 'DBot'
}
}
})

demisto.results(entry_list)

if __name__ in ('__main__', 'builtin', 'builtins'):

main()

Values for Common.DbotScore

Constant Value

Common.DbotScore.NONE NONE = 0

Common.DbotScore.GOOD GOOD = 1

Common.DbotScore.SUSPICIOUS SUSPICIOUS = 2

Common.DbotScore.BAD BAD = 3

5.5.1.7 | Reputation Commands

Abstract

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 459/1003
5/8/24, 9:18 AM PDF Export

Learn more about running reputation commands.

Reputation commands run on indicators based on the indicator type to get the indicator verdict. The command uses integrations such as Unit 42, etc.

The command returns the verdict of the indicator as an entry with entry context and may also return context values that can be mapped to the custom fields of
the indicator.

For example, you can run commands such as !ip, which runs a reputation on an IP address or !url to run reputation commands on an URL. For more
information about these commands and how to create your own commands, see Generic Reputation Commands.

NOTE:

Running a reputation command directly (such as !ip) might not apply the result to the indicator, nor does it use the enrichment cache. To ensure the indicator
is enriched, and to take advantage of caching, use the enrichIndicators command or the Enrich button in the UI. This runs the appropriate reputation
command/script based on the indicator type settings. Note that extracted indicators are enriched in the same way.

CLI Reputation Command Examples

There are several out-of-the-box reputation commands, including:

!ip ip=<value of the indicator>

!domain domain=<value of the indicator>

!file file=<value of the indicator>

Reputation Command Input

The reputation command uses the indicator value as the input argument.

Arguments Description

The value of the For example ip, email, url. Inputs are based on different integrations. Basic inputs are common to all reputation commands. For
indicator example the !ip command has the following basic inputs:

- name: ip
arguments:
- name: ip
default: true
description: List of IPs.
isArray: true

In this example, the ip script uses ip, as the input, with the is array field checked.

Reputation Command Outputs

Outputs return a dbotScore.

5.5.2 | Indicator Fields

Abstract

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 460/1003
5/8/24, 9:18 AM PDF Export

Learn about using custom indicator fields.

When you create a custom indicator field, you can add it to the indicator type and to the indicator layout for the required indicator type. In this section, you can:

Create a Custom Indicator Field

Map Custom Indicator Fields

Create Indicator Field Trigger Scripts

NOTE:

Cortex XSIAM IOC fields are based on the STIX 2.1 specifications. For more information, see Indicator Fields Structure.

5.5.2.1 | Create a Custom Indicator Field

Abstract

Create a custom indicator field in the Fields tab in Cortex XSIAM. Add specific indicator information to indicator layouts and types.

Indicator fields are used to add specific indicator information to indicator types and layouts. When you create an indicator field, you can associate the field to a
specific indicator type or to all indicator types.

1. Go to Settings → Configurations → Object Setup → Indicators → Fields.

2. Click New Field.

3. In the Basic Settings tab, add the following:

Field Description

Field Type Determines the acceptable values for the field. You can add the following field types:

Boolean (checkbox)

Date picker

Grid (table): Include an interactive, editable grid.

HTML: Create and view HTML content, which can be used in any type of indicator.
By default, HTML fields do not use theme styles.

Long text: The long text is analyzed and tokenized, and entries are indexed as
individual words, enabling you to perform advanced searches and use wildcards.
Long text fields cannot be sorted and cannot be used in graphical dashboard
widgets. While editing a long text field, pressing enter will create a new line. Case
insensitive.

Markdown: Add markdown formatted text as a Template which will be displayed to

users in the field after the indicator is created. Markdown lets you add basic
formatting to text to provide a better end-user experience.

Multi-select / Array: Includes two options:

Multi-select from a pre-filled list

An empty array field for the user to add one or more values as a comma-
separated list

Number: Can contain any number. The default is 0.

Short text: Short text is treated as a single unit of text, and is not indexed by word.
Advanced search, including wildcards, is not supported. Short text fields are case
sensitive by default but can be changed to case insensitive when creating the field.
While editing a short text field, pressing enter will save the change. Maximum length
60,000 characters. Recommended use is one-word entries. Examples: username,
email address, etc.

Single select

Tags

URL

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 461/1003
5/8/24, 9:18 AM PDF Export

Field Description

Mandatory If selected, this field is mandatory when used in a form.

Field Name A meaningful display name for the field. After you type a name, you will see below the field
that the Machine name is automatically populated. The field’s machine name is applicable
for searching and the War Room CLI.

Tooltip An optional tooltip for the field.

Placeholder Optional text to display in the field when it is empty. This text will appear in the layout, but
not in the created indicator. Available for Short text, Long text, Multi-select / Array, and
Tags.

4. Configure the attributes.

Field Description

Script to run when field value changes The script that dynamically changes the field value when script conditions are met. For a
script to be available, it must have the field-change-triggered-indicator tag, when defining
a script. For more information, see Indicator field trigger scripts.

Add to all indicator types Selected by default, which means this field will be available to use in all indicator types.

Clear the check box to select the indicator types to add the field.

5. Save the field.

The indicator field appears in the layout(s) of the indicator type(s) you add it to.

6. You can now Map Custom Indicator Fields.

5.5.2.2 | Map Custom Indicator Fields

Abstract

Learn more about mapping custom indicator fields.

The value of the custom incident field is determined by the value of the key in Context data to which the field is mapped in Cortex XSIAM.

When you start ingesting indicators, the indicator fields are automatically mapped to the relevant indicator fields. Sometimes you may want to change the default
settings, or map custom indicator fields to the relevant context data. Before you map custom indicator fields, you need to create the indicator field, add it to the
required indicator type layout.

Mapping enables you to automatically update the indicator without having to manually change it. For example, the IP indicator automatically maps the Geo
Country. Without it being mapped, every time the IP address changes country, the analyst would have to update the country every time that indicator type is
ingested.

To map custom fields to the indicator type, you need to enrich the indicator either by using the !enrichindicators command in the Alert Room CLI, in a
playbook, or open an indicator and click Enrich indicator. Enrichment returns an entry, with the EntryContext property as the source of the mapping process.
When editing an indicator type, in the Custom Fields tab, type the name of the indicator exactly how it appears (in the Threat Intel page) and click Load.

For the enrichment data to be considered valid, EntryContext must include a DBotScore with the fields: Indicator, Score, Vendor and Type. If DBotScore
has those fields, all the data of EntryContext is used as the source for the mapping, and not only the data under EntryContext.DBotScore.

1. Go to Settings → Configurations → Object Setup → Indicators → Types.

2. Select the indicator type and click Edit.

3. Click the Custom Fields tab.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 462/1003
5/8/24, 9:18 AM PDF Export

The custom fields associated with this indicator type are listed in the table. If you do not see a custom field in the list, verify that you associated the custom
field to this indicator type.

4. (Optional) In the Indicator Sample panel, enter an indicator relevant to the indicator type to load sample data.

5. Click Choose data path to map the custom field to a data path.

a. (Optional) Click the curly brackets to map the field to a context path.

b. (Optional) From the Indicator Sample panel, select a context key to map to the field.

6. Save the indicator type.

5.5.2.3 | Indicator field trigger scripts

Abstract

Associate Cortex XSIAM indicator fields with scripts that are triggered when the field changes.

You can associate indicator fields with trigger scripts that check for field changes, and then take actions based on them. These scripts can perform any action
when the conditions are met. Indicator field trigger scripts allow indicators to become a proactive force within Cortex XSIAM. For example, you can:

Define a script that will run when the Verdict field of an indicator has changed. For example, the script will fetch all incidents related to that indicator, and
take any action that is configured (reopen, change severity, etc.).

Define a script that will run when the Expiration Status field has changed. For example, you can define a script that will immediately update the relevant
allow/block list (and not wait for the next iteration) as seen in the following script example:

indicators = demisto.args().get('indicators')
new_value = demisto.args().get('new')

indicator_values = []
for indicator in indicators:
current_value = indicator.get('value')
indicator_values.append(current_value)

if new_value == "Expired":
# update allow/block list regarding expired indicators
else:
# update allow/block list regarding active indicators

Scripts can be created in Python, PowerShell, or JavaScript in the Script page. To use a field trigger script, you need to add the field-change-triggered-
indicator tag when creating the script. You can then add the script in the Attributes tab, when you edit or Create a Custom Indicator Field. If you did not add
the tag when creating the script, the script is not available for use.

Trigger Script Arguments - Related Information

When a script is triggered on a field, it has the following triggered field information available as arguments (args):

Argument Description

associatedToAll If the field is associated to all or some incidents. Value: true or false.

associatedTypes An array of the incident types, with which the field is associated.

cliName The name of the field when called from the command line.

description The description of the field.

indicators A list of indicators that had the current change.

isReadOnly Specifies whether the field is non editable. Value: true or false.

name The name of the field.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 463/1003
5/8/24, 9:18 AM PDF Export

Argument Description

new The new value of the field.

old The old value of the field.

ownerOnly Specifies that only the creator of the field can edit. Value: true or false.

placeholder The placeholder text.

required Specifies whether this is a mandatory field. Value: true or false.

selectValues If this is a multi-select type field, these are the values the field can take.

system Whether it is a Cortex XSIAM defined field.

type The field type.

user The username of the user who triggered the script.

Script Limitations and Best Practices

Indicator field trigger scripts can be configured on: Verdict, Related Incidents, Expiration Status, Indicator Type, and all custom indicator fields in the
system.

Indicator field trigger scripts work in all TIM (Threat Intelligence Management) scenarios and workflows, except for feed ingestion.

Fields that may hold a list (related incidents, multi-select/tag/role type custom fields) will provide an array of the delta. For example, if a multi-select field
value has changed from ["a"] to ["a", "b"], the new argument of the script will get a value of ["b"].

Indicator field trigger scripts run as a batch. This means that if multiple indicators were changed in the same way and are set to trigger the same action, it
will happen in one batch. For example:

1. There's a configured indicator field trigger script named myTriggerScript on the Verdict indicator field.

2. The Threat Intel Library has two existing Malicious indicators: 1.1.1.1, 2.2.2.2.

3. The user runs the following command !setIndicators indicatorsValues="1.1.1.1,2.2.2.2" verdict=Benign.

4. The myTriggerScript script will run just once, with the following parameters:

new - "Benign"

old - "Malicious"

indicators - "[{<indicator_1.1.1.1>},{<indicator_2.2.2.2}]"

When writing indicator field trigger scripts, it's crucial to avoid scenarios that call the scripts endlessly (for example, a change in field A triggers script X,
which changes field B's value, and in turn calls script Y that changes field A's value).

5.5.2.4 | Indicator Fields Structure

Abstract

Indicator fields structure aligned with STIX standards to more easily share and work with IOCs.

Cortex XSIAM IOC fields are based on the STIX 2.1 specifications. These fields provide a guideline for the fields we recommend you maintain within an IOC.
None of the fields are mandatory, except the value field. Maintaining this field structure enables you to share and export IOCs to additional threat intel based
systems as well as to other cybersecurity devices.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 464/1003
5/8/24, 9:18 AM PDF Export

Like STIX, Cortex XSIAM indicators are divided into two categories, STIX Domain Objects (SDOs) and STIX Cyber-observable Objects (SCOs). The category
determines which fields are presented in the layout of that specific IOC. In Cortex XSIAM, all SCOs can be used in a relationship with either SDOs or SCOs.

Each IOC table of fields is separated into three parts:

System fields - Fields created and managed by Cortex XSIAM.

Custom core fields - Custom fields shared by all IOCs of the same time (SDO or SCO). Fields may be empty.

Custom unique fields - Fields unique to a specific type of IOC. If a user associates more fields with the IOC, the additional fields are also treated as
unique.

STIX Cyber-observable Objects (SCO)

Account

Similar to STIX User Account Object, this indicator type represents a user account in various platforms such as operating system, social media accounts, and
Active Directory. The value for the object is usually the username for logging in.

System Fields Description

Value Defines the indicator on Cortex XSIAM. The value is the main key for the object in the system.

Verdict Malicious, Suspicious, Benign, or Unknown.

Expiration The expiration date of the object.

Source Time Stamp When the object was created in the system.

Modified When the object was last modified.

Custom Fields - Core Description

Blocked A Boolean switch to mark the object as blocked in the user environment.

Community Notes Comments and free form notes regarding the indicator.

Description The description of the object.

STIX ID The STIX ID for the object in the format of account--<UUID>.

Tags Tags attached to the object.

Traffic Light Protocol Red, Amber, Green, or White.

Custom Fields - Unique Description

Account Type Specifies the type of the account, comes from account-type-ov by STIX.

Creation Date The date the account was created (not the date the indicator was created).

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 465/1003
5/8/24, 9:18 AM PDF Export

Custom Fields - Unique Description

Display Name The display name of the account as it is shown in the UI.

Groups The groups the account is a member of.

User ID The account's unique ID according to the system it was taken from.

Domain / DomainGlob

Network domain name, similar to the STIX Domain Name object. The value is the domain address.

System Fields Description

Value Defines the indicator on Cortex XSIAM. The value is the main key for the object in the system.

Verdict Malicious, Suspicious, Benign, or Unknown.

Expiration The expiration date of the object.

Source Time Stamp When the object was created in the system.

Modified When the object was last modified.

Custom Fields - Core Description

Blocked A Boolean switch to mark the object as blocked in the user environment.

Community Notes Comments and free form notes regarding the indicator.

Description The description of the object.

STIX ID The STIX ID for the object in the format of domain--<UUID>.

Tags Tags attached to the object.

Traffic Light Protocol Red, Amber, Green, or White.

Custom Fields - Unique Description

Creation Date The date the domain was created.

DNS Records All types of DNS records with a timestamp and their values (GRID).

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 466/1003
5/8/24, 9:18 AM PDF Export

Custom Fields - Unique Description

Expiration Date The domain expiration date.

Certificates Any certificates issued for the domain.

WHOIS Records Any records from WHOIS about the domain (GRID).

Email

A single user email address.

System Fields Description

Value Defines the indicator on Cortex XSIAM. The value is the main key for the object in the system.

Verdict Malicious, Suspicious, Benign, or Unknown.

Expiration The expiration date of the object.

Source Time Stamp When the object was created in the system.

Modified When the object was last modified.

Custom Fields - Core Description

Blocked A Boolean switch to mark the object as blocked in the user environment.

Community Notes Comments and free form notes regarding the indicator.

Description The description of the object.

STIX ID The STIX ID for the object in the format of email--<UUID>.

Tags Tags attached to the object.

Traffic Light Protocol Red, Amber, Green, or White.

Custom Fields - Unique

None

File

Represents a single file. For backward compatibility, the indicator has multiple fields for different types of hashes. New hashes, however, should be stored under
the Hashes grid field. The file value should be its hash (either MD5, SHA-1, SHA-256, or SHA-512, in that order).

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 467/1003
5/8/24, 9:18 AM PDF Export

System Fields Description

Value Defines the indicator on Cortex XSIAM. The value is the main key for the object in the system.

Verdict Malicious, Suspicious, Benign, or Unknown.

Expiration The expiration date of the object.

Source Time Stamp When the object was created in the system.

Modified When the object was last modified.

Custom Fields - Core Description

Blocked A Boolean switch to mark the object as blocked in the user environment.

Community Notes Comments and free form notes regarding the indicator.

Description The description of the object.

STIX ID The STIX ID for the object in the format of file--<UUID>.

Tags Tags attached to the object.

Traffic Light Protocol Red, Amber, Green, or White.

Custom Fields - Unique Description

Creation Date The file creation date.

File Extension The file extension.

Associated File Names Names the file is associated with.

File Type The type of the file.

Hashes Any hashes not specified in a separate field.

imphash The imphash.

MD5 The MD5 hash.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 468/1003
5/8/24, 9:18 AM PDF Export

Custom Fields - Unique Description

Modified Date When the file was modified on the origin.

Path The path to the file.

Quarantined Was the file quarantined?

SHA1 The SHA1 hash.

SHA256 The SHA256 hash.

SHA512 The SHA512 hash.

Size The file size.

SSDeep The SSDeep hash.

IPv4 / IPv6 / CIDR / IPv6CIDR

Represents an IP address and its subnet (CIDR). If no subnet is provided, the address is treated as a single IP (same as a /32 subnet).

System Fields Description

Value Defines the indicator on Cortex XSIAM. The value is the main key for the object in the system.

Verdict Malicious, Suspicious, Benign, or Unknown.

Expiration The expiration date of the object.

Source Time Stamp When the object was created in the system.

Modified When the object was last modified.

Custom Fields - Core Description

Blocked A Boolean switch to mark the object as blocked in the user environment.

Community Notes Comments and free form notes regarding the indicator.

Description The description of the object.

STIX ID The STIX ID for the object in the format of type--<UUID>.

Tags Tags attached to the object.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 469/1003
5/8/24, 9:18 AM PDF Export

Custom Fields - Core Description

Traffic Light Protocol Red, Amber, Green, or White.

Custom Fields - Unique Description

Geo Country The country where the object is located.

Geo Location A set of geographic coordinates for the object.

WHOIS records Any records from WHOIS about the domain (GRID).

URL

Represents the properties of a uniform resource locator.

System Fields Description

Value Defines the indicator on Cortex XSIAM. The value is the main key for the object in the system.

Verdict Malicious, Suspicious, Benign, or Unknown.

Expiration The expiration date of the object.

Source Time Stamp When the object was created in the system.

Modified When the object was last modified.

Custom Fields - Core Description

Blocked A Boolean switch to mark the object as blocked in the user environment.

Community Notes Comments and free form notes regarding the indicator.

Description The description of the object.

STIX ID The STIX ID for the object in the format of url--<UUID>.

Tags Tags attached to the object.

Traffic Light Protocol Red, Amber, Green, or White.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 470/1003
5/8/24, 9:18 AM PDF Export

Custom Fields - Unique Description

Certificates Any certificates issued for the domain.

STIX Domain Objects (SDO)

Attack Pattern

Attack patterns are a type of TTP (Tactics, Techniques and Procedures) that describe ways adversaries attempt to compromise targets. Attack patterns help
categorize attacks, generalize specific attacks to the patterns that they follow, and provide detailed information about how attacks are performed. An example of
an attack pattern is spear phishing, where an attacker sends a carefully crafted email message with the intent of getting the target to click a link or open an
attachment that delivers malware. Attack patterns can also be more specific, such as spear phishing by a particular threat actor (for example, an email saying
the target won a contest).

System Fields Description

Value Defines the indicator on Cortex XSIAM. The value is the main key for the object in the system.

Verdict Malicious, Suspicious, Benign, or Unknown.

Expiration The expiration date of the object.

Source Time Stamp When the object was created in the system.

Modified When the object was last modified.

Custom Fields - Core Description

Community Notes Comments and free form notes regarding the indicator.

Description The description of the object.

STIX ID The STIX ID for the object in the format of attack-pattern--<UUID>.

Tags Tags attached to the object.

Traffic Light Protocol Red, Amber, Green, or White.

Custom Fields - Unique Description

Kill Chain Phases The list of kill chain phases this Attack Pattern is used for.

External References List of external references consisting of a source and ID. For example, {source: mitere, id: T1189}

Campaign

A campaign is a grouping of adversarial behaviors that describes a set of malicious activities or attacks (sometimes called waves) that occur over a period of
time against a specific set of targets. Campaigns usually have well defined objectives and may be part of an intrusion set.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 471/1003
5/8/24, 9:18 AM PDF Export

Campaigns are often attributed to an intrusion set and threat actors. The threat actors may reuse known infrastructure from the intrusion set or may set up new
infrastructure specifically for conducting that campaign.

Campaigns can be characterized by their objectives and the incidents they cause, people or resources they target, and the resources (infrastructure,
intelligence, malware, tools, etc.) they use.

For example, a campaign can describe a crime syndicate's attack using a specific variant of malware and new C2 servers against the executives of ACME Bank
during the summer of 2020 to gain secret information about an upcoming merger with another bank.

System Fields Description

Value Defines the indicator on Cortex XSIAM. The value is the main key for the object in the system.

Verdict Malicious, Suspicious, Benign, or Unknown.

Expiration The expiration date of the object.

Source Time Stamp When the object was created in the system.

Modified When the object was last modified.

Custom Fields - Core Description

Community Notes Comments and free form notes regarding the indicator.

Description The description of the object.

STIX ID The STIX ID for the object in the format of campaign--<UUID>.

Tags Tags attached to the object.

Traffic Light Protocol Red, Amber, Green, or White.

Custom Fields - Unique Description

Aliases Alternative names used to identify this campaign.

Objective The campaign’s primary goal, objective, desired outcome, or intended effect.

Course of action

A course of action is an action taken either to prevent an attack or to respond to an attack that is in progress. It may describe technical, automatable responses
(applying patches, reconfiguring firewalls), but can also describe higher level actions such as employee training or policy changes. For example, a course of
action to mitigate a vulnerability could describe applying the patch that fixes it.

System Fields Description

Value Defines the indicator on Cortex XSIAM. The value is the main key for the object in the system.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 472/1003
5/8/24, 9:18 AM PDF Export

System Fields Description

Verdict Malicious, Suspicious, Benign, or Unknown.

Expiration The expiration date of the object.

Source Time Stamp When the object was created in the system.

Modified When the object was last modified.

Custom Fields - Core Description

Community Notes Comments and free form notes regarding the indicator.

Description The description of the object.

STIX ID The STIX ID for the object in the format of course-of-action--<UUID>.

Tags Tags attached to the object.

Traffic Light Protocol Red, Amber, Green, or White.

Custom Fields - Unique Description

Action Reserved to capture structured/automated courses of action.

CVE

To preserve backward compatibility, our vulnerability indicator is referred to as CVE, but it is equivalent to the Vulnerability object defined by STIX. Unlike STIX,
in TIM the object is identified by its CVE number. A vulnerability is a weakness or defect in the requirements, designs, or implementations of the computational
logic (code) found in software and some hardware components (firmware) that can be directly exploited to negatively impact the confidentiality, integrity, or
availability of that system.

System Fields Description

Value Defines the indicator on Cortex XSIAM. The value is the main key for the object in the system.

Verdict Malicious, Suspicious, Benign, or Unknown.

Expiration The expiration date of the object.

Source Time Stamp When the object was created in the system.

Modified When the object was last modified.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 473/1003
5/8/24, 9:18 AM PDF Export

Custom Fields - Core Description

Community Notes Comments and free form notes regarding the indicator.

Description The description of the object.

STIX ID The STIX ID for the object in the format of vulnerability--<UUID>.

Tags Tags attached to the object.

Traffic Light Protocol Red, Amber, Green, or White.

Custom Fields - Unique Description

CVSS Version The version of the CVSS scoring system.

CVSS Score The score given to the CVE.

CVSS Vector The full CVSS vector.

CVSS Table All CVSS data by Metric - Value pairs.

Infrastructure

The Infrastructure SDO represents a type of TTP and describes any systems, software services and any associated physical or virtual resources that support
some purpose (for example, C2 servers used as part of an attack, a device or server that is part of a defense, and database servers targeted by an attack).
While elements of an attack can be represented by other SDOs or SCOs, the Infrastructure SDO represents a named group of related data that constitutes the
infrastructure.

System Fields Description

Value Defines the indicator on Cortex XSIAM. The value is the main key for the object in the system.

Verdict Malicious, Suspicious, Benign, or Unknown.

Expiration The expiration date of the object.

Source Time Stamp When the object was created in the system.

Modified When the object was last modified.

Custom Fields - Core Description

Community Notes Comments and free form notes regarding the indicator.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 474/1003
5/8/24, 9:18 AM PDF Export

Custom Fields - Core Description

Description The description of the object.

STIX ID The STIX ID for the object in the format of infrastructure--<UUID>.

Tags Tags attached to the object.

Traffic Light Protocol Red, Amber, Green, or White.

Custom Fields - Unique Description

Aliases Alternative names used to identify this infrastructure.

Infrastructure types The type of infrastructure being described. Values should come from STIX infrastructure-type-ov open vocabulary.

Intrusion set

An intrusion set is a grouped set of adversarial behaviors and resources with common properties that is believed to be orchestrated by a single organization. An
intrusion set may capture multiple campaigns or other activities that are all tied together by shared attributes indicating a commonly known or unknown threat
actor. New activity can be attributed to an intrusion set even if the threat actors behind the attack are not known. Threat actors can move from supporting one
intrusion set to supporting another, or they may support multiple intrusion sets.

Whereas a campaign is a set of attacks over a period of time against a specific set of targets to achieve an objective, an intrusion set is the entire attack
package and may be used over a very long period of time in multiple campaigns to achieve potentially multiple purposes.

System Fields Description

Value Defines the indicator on Cortex XSIAM. The value is the main key for the object in the system.

Verdict Malicious, Suspicious, Benign, or Unknown.

Expiration The expiration date of the object.

Source Time Stamp When the object was created in the system.

Modified When the object was last modified.

Custom Fields - Core Description

Community Notes Comments and free form notes regarding the indicator.

Description The description of the object.

STIX ID The STIX ID for the object in the format of intrusion-set--<UUID>.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 475/1003
5/8/24, 9:18 AM PDF Export

Custom Fields - Core Description

Tags Tags attached to the object.

Traffic Light Protocol Red, Amber, Green, or White.

Custom Fields - Unique Description

Aliases Alternative names used to identify this intrusion set.

Goals The high-level goals of this intrusion set, what it is trying to do.

Primary Motivation The primary reason, motivation, or purpose behind this intrusion set. Values should come from STIX attack-motivation-
ov open vocabulary.

Secondary Motivation The secondary reason, motivation, or purpose behind this intrusion set. Values should come from STIX attack-motivation-
ov open vocabulary.

Resource level Specifies the organizational level at which this intrusion set typically works. Values should come from STIX attack-resource-
level-ov open vocabulary.

Malware

Malware is a type of TTP that represents malicious code. It generally refers to a program that is inserted into a system, usually covertly. The intent is to
compromise the confidentiality, integrity, or availability of the victim's data, applications, or operating system (OS) or otherwise annoy or disrupt the victim.

System Fields Description

Value Defines the indicator on Cortex XSIAM. The value is the main key for the object in the system.

Verdict Malicious, Suspicious, Benign, or Unknown.

Expiration The expiration date of the object.

Source Time Stamp When the object was created in the system.

Modified When the object was last modified.

Custom Fields - Core Description

Community Notes Comments and free form notes regarding the indicator.

Description The description of the object.

STIX ID The STIX ID for the object in the format of malware--<UUID>.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 476/1003
5/8/24, 9:18 AM PDF Export

Custom Fields - Core Description

Tags Tags attached to the object.

Traffic Light Protocol Red, Amber, Green, or White.

Custom Fields - Unique Description

Aliases A list of other names the malware is known as.

Architecture The processor architectures (for exmple, x86, ARM) that the malware instance or family is executable on. The values should
come from the STIX processor-architecture-ov open vocabulary.

Capabilities Any of the capabilities identified for the malware instance or family. The values should come from STIX malware-
capabilities-ov open vocabulary.

Implementation The programming language(s) used to implement the malware instance or family. The values should come from the
Languages STIX implementation-language-ov open vocabulary.

Is Malware Family Whether the object represents a malware family (if true) or a malware instance (if false).

Malware Types Which type of malware. Values should come from STIX malware-type-ov open vocabulary.

Operating System Refs Identifier of a software object.

Report

Reports are collections of threat intelligence focused on one or more topics, such as a description of a threat actor, malware, or attack technique, including
context and related details. They are used to group related threat intelligence together so that it can be published as a comprehensive cyber threat story.

System Fields Description

Value Defines the indicator on Cortex XSIAM. The value is the main key for the object in the system.

Verdict Malicious, Suspicious, Benign, or Unknown.

Expiration The expiration date of the object.

Source Time Stamp When the object was created in the system.

Modified When the object was last modified.

Custom Fields - Core Description

Community Notes Comments and free form notes regarding the indicator.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 477/1003
5/8/24, 9:18 AM PDF Export

Custom Fields - Core Description

Description The description of the object.

STIX ID The STIX ID for the object in the format of report--<UUID>.

Tags Tags attached to the object.

Traffic Light Protocol Red, Amber, Green, or White.

Custom Fields - Unique Description

Publications Links to publications of the report.

Threat actor

Threat actors are individuals, groups, or organizations believed to be operating with malicious intent. A threat actor is not an intrusion set but may support or be
affiliated with various intrusion sets, groups, or organizations over time.

System Fields Description

Value Defines the indicator on Cortex XSIAM. The value is the main key for the object in the system.

Verdict Malicious, Suspicious, Benign, or Unknown.

Expiration The expiration date of the object.

Source Time Stamp When the object was created in the system.

Modified When the object was last modified.

Custom Fields - Core Description

Community Notes Comments and free form notes regarding the indicator.

Description The description of the object.

STIX ID The STIX ID for the object in the format of threat-actor--<UUID>.

Tags Tags attached to the object.

Traffic Light Protocol Red, Amber, Green, or White.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 478/1003
5/8/24, 9:18 AM PDF Export

Custom Fields - Unique Description

Alias A list of other names the threat actor is known as.

Geo country The country the threat actor is associated with.

Goals The high-level goals of this threat actor, what it is trying to do.

Resource Level The organizational level at which this threat actor typically works. Values for this property should come from STIX attack-
resource-level-ov open vocabulary.

Primary Motivation The primary reason, motivation, or purpose behind this threat actor. Values for this property should come from STIX attack-
motivation-ov open vocabulary.

Secondary Motivation The secondary reasons, motivations, or purposes behind this threat actor. Values for this property should come from
STIX attack-motivation-ov open vocabulary.

Sophistication The skill, specific knowledge, special training, or expertise a threat actor must have to perform the attack. Values for this
property should come from STIX threat-actor-sophistication-ov open vocabulary.

Threat actor type The type(s) of this threat actor. Values should come from STIX threat-actor-type-ov open vocabulary.

Tool

Tools are legitimate software used by threat actors to perform attacks. Knowing how and when threat actors use such tools can help understand how campaigns
are executed. Unlike malware, these tools or software packages are often found on a system and have legitimate purposes for power users, system
administrators, network administrators, or even regular users. Remote access tools such as RDP and network scanning tools such as Nmap are examples of
tools that may be used by a threat actor during an attack.

System Fields Description

Value Defines the indicator on Cortex XSIAM. The value is the main key for the object in the system.

Verdict Malicious, Suspicious, Benign, or Unknown.

Expiration The expiration date of the object.

Source Time Stamp When the object was created in the system.

Modified When the object was last modified.

Custom Fields - Core Description

Community Notes Comments and free form notes regarding the indicator.

Description The description of the object.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 479/1003
5/8/24, 9:18 AM PDF Export

Custom Fields - Core Description

STIX ID The STIX ID for the object in the format of tool--<UUID>.

Tags Tags attached to the object.

Traffic Light Protocol Red, Amber, Green, or White.

Custom Fields - Unique Description

Alias Alternative names used to identify this tool.

Tool Types The kind(s) of tool(s) being described. Values for this property should come from STIX tool-type-ov open vocabulary.

Tool Version The version identifier associated with the tool.

Kill Chain Phases The list of kill chain phases this attack pattern is used for.

5.5.3 | Indicators Classification and Mapping

Abstract

Learn about the classification and mapping feature.

The classification and mapping feature enables you to take the data that Cortex XSIAM ingests from integrations, and classify and map the data to indicator
types and indicator fields. By classifying the data as different indicator types, you can process them with different playbooks suited to their respective
requirements.

Classification determines the type of indicator that is created for data ingested from a specific integration. You create a classifier and define that classifier in an
integration.

You can map the fields from your third party integration to the fields in your indicator layouts. You can do the following:

Map your fields to indicator types irrespective of the integration or classifier. This means that you can create a mapping before defining an instance and
ingesting indicators. By doing so, when you do define an instance and apply a mapper, the data that comes in is already mapped.

Create default mapping for all of the fields that are common to all indicator types, and then map only those fields that are specific to each alert type
individually. You can still overwrite the contents of a field in the specific indicator type.

5.5.3.1 | Classify Attributes for Indicator Types

Abstract

Classify events using a classification key in an integration ingestion.

When an integration fetches indicators, it populates the rawJSON object in the indicator object. When classifying data, you want to select an attribute that can
determine the indicator.

You can use this procedure for creating a classifier or duplicating an existing classifier.

1. Under Get data, select from where you want to pull the information based on which you will classify the incident types.

Pull from instance: Select an existing integration instance.

Select schema: When supported by the integration, this will pull all the fields for the integration from the database from which you can select by
which to classify the events.

Upload JSON: Upload a formatted JSON file which includes the field by which you want to classify.

2. Select Settings → Configurations → Object Setup → Indicators → Classification & Mapping → New → Indicator Classifier.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 480/1003
5/8/24, 9:18 AM PDF Export

If you want to duplicate the classifier, select the relevant classifier and then duplicate it.

3. In the Get data field, select how to retrieve the data to classify the events.

4. In the Select Instance field, select the instance or JSON file from where you want to choose the value.

5. Save the classifier.

6. Go to Settings → Automation & Feed Integrations.

a. Select the integration to which you want to apply the classifier.

b. In the integration settings, under Classifier, select the classifier you created and click Save.

5.5.3.2 | Map Attributes to Indicator Types

Abstract

Create independent mappers that map attributes from incoming data to indicator types.

Mappers enable you to map the information from incoming data to the indicator that you have in your system.

Mapping data takes place in two stages. Firstly, map all of the fields that are common to all indicators in the default mapping. Secondly map the additional fields
that are specific for each indicator type, or overwrite the mapping that you used in the default mapping.

NOTE:

In the Classification & Mapping page, the mapping does not indicate for which indicator types they are configured. When creating a mapper, it is best practice
to add to the mapper name, the alert types the mapper is for. For example, Mail Listener - Phishing.

When mapping a list, we recommend you map to a multi select field. Short text fields do not support lists. If you do need to map a list to a short text field, add
a transformer in the relevant playbook task, to split the data back into a list.

You can use this procedure for creating a classifier or duplicating an existing mapper for alert types.

1. Select Settings → Configurations → Indicator → Classification & Mapping → New.

2. Indicator Mapping (Incoming) - maps all of the indicator fields to their indicator layout.

3. Under Get data, select from where you want to pull the information based on where you want to map the indicator type.

Pull from instance - select an existing integration instance.

Select schema - when supported by the integration, this will pull all of the fields for the integration from the database. This enables you to see all of
the fields for each given event type that the integration supports.

Upload JSON - upload a formatted JSON file which includes the field you want to map.

4. Under Indicator Type, start by mapping out the Common Mapping. This mapping includes the fields that are common to all of the indicator types and
saves you time having to define these fields individually in each indicator type.

5. Click the attribute to which you want to map. You can further manipulate the field using filters and transformers.

6. Repeat this process for the other indicator types for which this mapping is relevant.

7. Save the mapper.

8. Go to Settings → Automation & Feed Integrations.

a. Select the integration to which you want to apply the classifier.

b. In the integration settings, under Mapper select the mapper you created and click Save.

5.5.4 | Exclusion List

Abstract

When adding to an exclusion list, indicators are disregarded by the system. Add indicators to an exclusion list in Cortex XSIAM.

Indicators added to the exclusion list are disregarded by the system and are not created or involved in automated flows such as indicator extraction. You can still
manually enrich IP addresses and URLs that are on the exclusion list, but the results are not posted to the War Room.

There are several methods by which to add indicators to the exclusion list.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 481/1003
5/8/24, 9:18 AM PDF Export

Delete and exclude Indicators

You can select one or more indicators from the Indicators table and click the Delete and Exclude button. The indicators are deleted from the Indicators table and
added to the exclusion list. You can associate these indicators with one or more indicator types.

If you delete the indicator it is removed from Cortex XSIAM . This option should be used mainly for correcting errors in ingestion, and not as part of your regular
workflow.

Manually add indicators to the exclusion list

From the Exclusion List page, you can manually add a single indicator or define indicators using a regular expression (regex) or CIDR. To view or edit the
Exclusion List, go to Settings → Configurations → Object Setup → Indicators → Exclusion List.

CAUTION:

Ensure you are using the correct syntax when defining the values for your exclusion lists.

Regex

A regular expression enables you to identify a sequence of characters in an unknown string. The following example would identify www.demisto.com: [A-Za-
z0-9!@#$%\.&]*demisto[A-Za-z0-9!@#$%\.&]*.

CIDR

Classless inter-domain routing (CIDR) enables you to define a range of IP addresses. For example, the IPv4 block 192.168.100.0/22 represents the 1024 IPv4
addresses from 192.168.100.0 to 192.168.103.255.

Exclusion List Examples

Exclusion Description Settings

Domain, URLs, and subdomains Excludes a specific domain, and all Define two entries to cover all URLs and subdomains associated with a
subdomains and URLs associated with specific domain.
the domain.
Entry one:

Value: Subdomains and URLs. Example: \.example\.com

Select Use Regex.

Do not select any indicator types.

Entry two:

Value: The specific domain. Example: example.com

Do NOT select Use Regex.

Do not select any indicator types.

Subdomain (and URLs) Excludes any subdomains and URLs of Value: Subdomains and URLs. Example: \.example\.com
specifically a domain, but the domain is still
extracted. Select Use Regex.

Do not select any indicator types.

Specific domain only Excludes a specific domain. Subdomains Value: The specific domain. Example: example.com
and URLs are still extracted.
Do NOT select Use Regex.

Select indicator type: Domain.

URL with wildcards Excludes any indicators of type URL Value: The URL with wildcard added at the end. Example:
matching the regex. Indicators http://examplesub.example.com
example.com and
examplesub.example.com of type Select Use Regex.
Domain would still be extracted. Start the
Select indicator type: URL.
regex with https?:// to exclude both
HTTP and HTTPS URLs.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 482/1003
5/8/24, 9:18 AM PDF Export

Exclusion Description Settings

Specific URL Excludes a specific URL, but the domain Value: The specific URL. Example:
and subdomains are still extracted. http://examplesub.example.com/myexample

Do NOT select Use Regex.

Select indicator type: URL.

URLs, domain, and subdomains, Excludes domain example.com, its Value: Domain, subdomains and URLs, case insensitive and
case-insensitive, anchored to start subdomains, and its URLs. Case- anchored to the start of the indicator. Example: (?
insensitive. Anchors regex match to the i)^(https?://)?(([a-zA-Z0-9\-]+\.)+)?example\.com
start of the indicator value, so indicators
that contain but do not start with a match Select Use Regex.
(e.g., example.net?
Select indicator types: URL, Domain.
param=example.com) are not excluded.

All URLs Excludes all URLs for a specific domain Value: URLs with or without a path. Example: example\.com/
that have a path (even an empty path),
but the domain and subdomains are still Select Use Regex.
extracted.
Do not select any indicator types.

5.6 | Indicator Expiration

Abstract

Learn how to set a default expiration method for indicators.

Indicators can have the Expiration Status field set to Active or Expired, which is determined by the Expiration field. When indicators expire, they still exist in
Cortex XSIAM , meaning they are still displayed and you can still search for them. A job that runs every week checks for newly expired indicators and updates
the Expiration Status field.

NOTE:

If an indicator is marked for expiration, the status does not change to expired until the weekly job runs.

You can set the default expiration method for indicators either to never expire or to expire after a specific period of time. The default expiration method is set by
the indicator type. For more information see Indicator Type Profile.

This is the hierarchy by which indicators are expired.

Method Description

Manual A user manually expires the indicator or sets it to never expire. This method overrides all other methods.

Automation script Use the expireIndicators command to change the expiration status to Expired for one or more indicators. This
script accepts a comma-separated list of indicator values and supports multiple indicator types. For example, an IP
address, domain, and file hash: !expireIndicators
value=1.1.1.1,safeurl.com,45356A9DB614ED7161A3B9192E2F318D0AB5AD10

(Same in the indicator expiration hierarchy as manual.)

Use the !setIndicators command to reset the indicators' expiration value. The value can also be set to Never, so
that the indicators never expire. For example, !setIndicators indicatorsValues=watson.com
expiration=Never

Feed integration Some integrations support setting the expiration method on an integration instance level, which overrides the method
defined for the indicator type.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 483/1003
5/8/24, 9:18 AM PDF Export

Method Description

Indicator type The expiration method (interval or never) is defined according to indicator type, which applies to all indicators of this
type. This is the default expiration method for an indicator.

5.7 | Indicator Management

Abstract

Perform actions (create, edit, export, delete) and search for indicators on the Cortex XSIAM Threat Intel page.

After you have customized indicators and started ingesting indicators into Cortex XSIAM, you can create indicators, add indicators, extract indicators, export
indicators, etc. The Cortex XSIAM Indicators page displays a table or summary view of all indicators, and enables you to perform several indicator actions.

You can perform the following actions on the Indicators page.

Action Description

View and take action on an Click on an indicator to view and take action on indicator. You can view in detail the verdict, relationships, timeline,
indicator enrich indicators, etc.

Create a new indicator Manually create a new indicator in the system.

Edit Edit a single indicator or select multiple indicators to perform a bulk edit.

Delete and Exclude Delete and exclude one or more indicators from all indicator types or from a subset of indicator types.

If you select the Do not add to exclusion list check box, the selected indicators are only deleted.

Export Export the selected indicators to a CSV file.

Export (STIX) Export the selected indicators to a STIX file.

Upload a STIX file Upload a STIX file and add the indicators from the file to the system.

Indicator Query

You can search for indicators using any of the available search fields. There are several search fields specific to indicators.

Field Description

Value Search for the value of an indicator. If used with Contains, performs wildcard search. If used with =,
performs exact lookup and searches Unit 42 as well.

Status Whether the indicator is Active or Expired.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 484/1003
5/8/24, 9:18 AM PDF Export

Field Description

Verdict The reputation of the indicator:

Malicious

Suspicious

Benign

Unknown

Has Related Alerts Whether the indicator has related alerts

Detectable Whether an iIndicator has a detection rule associated with it.

Preventable Whether an indicator has a prevention rule associated with it.

Campaign Whether the indicator is part of an existing campaign.

Tags Tags applied to indicators.

Aggregated Reliability Searches for indicators based on a reliability score such as A - Completely reliable.

Feed The source (script, manual, etc.) which last set the indicator's expiration status.

Type The type of the indicator, such as File, Email, etc.

You can use a wildcard query, which finds indicators containing terms that match the specified wildcard. For example, the * pattern matches any sequence of 0
or more characters, and ? matches any single character. For a regex query, use the following value:

"/.*\\?.*/"

5.7.1 | Export Indicators

Abstract

You can export indicators from Cortex XSOAR as a list, external dynamic list, or file, which can then be sent to or pulled by a SIEM, firewall, and so on.

5.7.1.1 | Manually Export Indicators

Abstract

Manually export indicators to a file directly as a CVS or STIX file.

You can select one or more indicators from the Indicators table and export them as a CSV file or STIX file. The file can then be sent to or pulled by a SIEM or
firewall or can be used as the input for a playbook that processes indicators.

1. Go to the Indicators page.

2. Select the check box for one or more indicators that you want to export to a file.

3. Export the selected indicators.

(Optional) Click the Export button to export the indicators to a CSV file.

(Optional) Click the Export (STIX) button to export the indicators to a STIX file.

The CSV file is generated in UTF8 format.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 485/1003
5/8/24, 9:18 AM PDF Export

5.7.1.2 | Export Indicators Integrations

Abstract

There are several outbound-feed integrations that exports indicators to a file or list from Cortex XSIAM.

You can export indicators by using the Generic Export Indicators Service integration. Exported indicators can be used for firewall block lists, allow lists,
monitoring, and analysis in Splunk, etc.

The Generic Export Indicators Service can be configured to export specific fields in different output formats. Multiple instances of the integration can be
configured for different indicator queries, and the output can be customized to work with a variety of third-party services.

Additional information can be found here:

Manage External Dynamic Lists

Forward Requests to Long Running Integrations

5.7.1.3 | Export Indicators Playbooks

Abstract

There are several generic playbooks and several vendor-specific playbooks you can use to process indicators in Cortex XSIAM.

We provide numerous out-of-the-box playbooks for TIM, including playbooks that enable you to export indicators. All TIM-related playbooks have the 'TIM' prefix.
There are some that are generic (for example, TIM - Process Indicators - Fully Automated), and some that are dedicated to a specific vendor, like QRadar (for
example, TIM - QRadar Add Domain Indicators) and ArcSight (for example, TIM- Arcsight Add IP Indicators).

If you define a playbook task input that pulls from indicators, the entire playbook runs in Quiet Mode. This means the task or playbook information is not written
to the War Room, and inputs and outputs are not displayed in the playbook. However, errors and warnings are still written to the War Room.

CAUTION:

You should not run a query on a field that you might change in the playbook flow. For example, you shouldn’t have a playbook with the query
Verdict:Malicious and then change the indicator verdict as a part of the playbook.

5.7.2 | Indicator Relationships

Topic Not Found

5.7.2.1 | Create Indicator Relationships

Abstract

Create relationships between indicators to enhance your investigations.

Indicator relationships are used to enrich investigations with information from indicators that are connected in various ways to other indicators. These
relationships can help you pivot from what might be a false positive to a full-fledged campaign.

You can create relationships automatically through specific integration feeds.

To enable the automatic creation of relationships, ensure that the Create relationships checkbox is selected in the integration settings.

In addition, you can create relationships manually.

1. Navigate to the Indicators page.

2. Click on an indicator.

3. Under Relationships, click +Add.

A window with all of the indicators in your system appears.

4. Enter a query by which to search for the relevant indicators. You can optionally limit the time range by which you are searching.

5. Select the indicator(s) to which you want to create the relationship.

6. Set the relationship types. By default, the types that are presented are related-to.

For example, IP address x.x.x.x is related-to IP address y.y.y.y.

7. Click Save.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 486/1003
5/8/24, 9:18 AM PDF Export

5.8 | Threat Intel Feeds

Abstract

Learn more about Threat Intelligence Management (TIM) feeds and playbooks.

5.8.1 | Feed Integrations

Abstract

Learn more about OOTB feed integrations, common feed integration parameters, and feed triggered jobs.

Feed integrations fetch indicators from a threat intelligence feed and add them to Cortex XSIAM for processing and handling.

Cortex XSIAM has out-of-the-box threat intelligence feed integrations, including:

MITRE ATT&CK

Unit 42 ATOMs

Unit 42 Intel Objects

TAXII (1, 2.0/1)

Microsoft Office 365

Abuse.ch SSL Blacklist

Feodo Tracker IP Blocklist

Spamhaus

AlienVault

TOR Exit Addresses

AWS

Recorded Future

Proofpoint

Common feed integration parameters

This is a non-exhaustive list of the most common feed integration parameters. Each feed integration might have parameters unique to that integration. Ensure to
read the documentation for specific feed integrations.

Parameter Description

Name A meaningful name for the integration instance. For example, if you have separate instances to fetch
indicator types, you can include the name of the indicator type that the instance fetches.

Fetches indicators Select this option for the integration instance to fetch indicators.

Some integrations can fetch indicators or alerts. Make sure you select the relevant option for what you need
to fetch in the instance.

URL The URL of the feed.

Feed Fetch Interval How often the integration instance should fetch indicators from the feed.

Indicator Reputation The Indicator Verdict to apply to all indicators fetched from this integration instance.

Source Reliability The reliability of the source providing the threat intelligence data.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 487/1003
5/8/24, 9:18 AM PDF Export

Parameter Description

Indicator Expiration Method The method by which to expire indicators from this integration instance. The default expiration method is the
interval configured for the indicator type to which this indicator belongs.

Indicator Type: the expiration method defined for the indicator type to which this indicator belongs
(interval or never).

Time Interval: expires indicators from this instance after the specified time interval, in days or hours.

Never Expire: indicators from this instance never expire.

When removed from the feed: when the indicators are removed from the feed they are expired in the
system.

Bypass exclusion list When selected, the exclusion list is ignored for indicators from this feed. This means that if an indicator from
this feed is on the exclusion list, the indicator might still be added to the system.

Trust any certificate When selected, certificates are not checked.

Use system proxy settings Runs the integration instance using the proxy server (HTTP or HTTPS) that you defined in the server
configuration.

Do not use by default Excludes this integration instance when running a generic command that uses all available integrations.

Feed Triggered Jobs

You can define a job triggered by delta in a feed to run a playbook when the specified feed or feeds finish a fetch operation that included a modification to the
feed. The modification can be a new indicator, a modified indicator, or a removed indicator. For example, you want to update your firewall every time a URL is
added to, modified, or removed from the Office 365 feed.

You can run an indicator search query and take action by configuring Threat Intelligence Management Playbooks. For example, the TIM-Process Indicators -
Manual Review playbook, tags indicators and creates an incident of those indicators that require review. For an example, see Set up a Job to Process
Indicators.

5.8.2 | Threat Intelligence Management Playbooks

Abstract

Learn about TIM playbook configuration and settings.

TIM (Threat Intelligence Management) playbooks run based on an indicator search query. In most cases, the following workflow applies:

1. Indicators are added to Cortex XSIAM through feed ingestion. You can configure your integration to automatically tag all new/updated indicators from a
particular instance. For example, you can tag them from-feed.

2. Create a Job Triggered by delta in a Feed to run the TIM playbook.

3. The TIM playbook performs an indicator query. In this case, the query might be for all indicators that have the tag from-feed, and that were added or
modified since the last time the playbook was run.

4. The TIM playbook runs using the indicators matching the query as input.

Indicators and Feed Ingestion

Indicators include IP addresses, CIDRs, domains, URLs, file hashes, etc. Feed integrations enable you to ingest indicators from external sources into Cortex
XSIAM . Once indicators are in Cortex XSIAM, they can be enriched and assigned a verdict. Enriched indicators can be used for alert investigations in Cortex
XSIAM and can also be pushed to a SIEM or other external system.

Playbook Queries

When configuring your TIM Playbook to use an indicator query, we recommend you first run your query on the main Threat Intel page. This enables you to view
the list of indicators returned and verify you have the results you need for your playbook. You can copy and paste the query to the playbook or you can save the
query you run on the Threat Intel page and access that saved query from the playbook. When you type in a query, auto-complete options are displayed.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 488/1003
5/8/24, 9:18 AM PDF Export

NOTE:

By default, a query run on the Threat Intel page will be limited to the last 7 days, unless otherwise specified. This same limit does not apply when you enter
the query in Playbook Inputs and Outputs, but you can add your required time filter to the query.

Large Batches of Indicators

If more than 1000 indicators are returned, the indicators are processed in batches of 1000. For example, if there are 4500 indicators returned, the playbook runs
the first time on the first 1000. Each task receives 1000 indicators as a list or, if the task does not support lists, loops over the 1000 indicators. When the
playbook reaches the end, it runs again with the next batch of 1000 indicators and repeats until all indicators have been processed. The playbook loops
automatically through batches of indicators, you do not need to configure the playbook to loop. After all, indicators have been processed, the playbook
automatically closes the alert. You do not need to include a close alert task.

Quiet Mode

TIM playbooks often process thousands of indicators. By default, the quiet mode is enabled for TIM Playbooks. In quiet mode, entries are not written to the War
Room, and inputs and outputs are not presented for Work Plan tasks. For troubleshooting purposes, you can temporarily disable quiet mode during playbook
development. Quiet mode can be disabled in the playbook settings or on a per-task basis.

We strongly recommend that you have quiet mode enabled for any playbook that is in production, to prevent possible performance issues.

NOTE:

While the quiet mode is disabled, any changes you make to the playbook indicators query will turn quiet mode back on.

TIM Playbook Tasks

The Playbook search query returns all of the indicators that match a particular search, including all fields for each indicator. Individual tasks, however, may only
require a subset of that data. If you need to run different tasks for different types of indicators, you can use a conditional task and set the input to check for
indicator type. In the TIM - Indicator Auto Processing playbook, for example, Are there IP results? is a conditional task that searches the indicators returned by
the original playbook query. If the task finds any indicators with playbookQuery.indicator_type equal to IP, the condition is met. If no IP type indicators are found,
the condition is not met and the playbook proceeds to the else branch. Note that you only see Indicator Details as an option for input, after the playbook has
been configured to run an indicator search query.

You can also use filters based on indicator attributes. For example, you can limit a task to only run on indicators where the type is IP.

Note that using playbookQuery.value as input returns the indicators themselves, such as the IP addresses. Using playbookQuery as input returns all of the
indicator attributes, not only the indicator value.

5.9 | Unit 42 Intel

Abstract

Learn more about Unit 42 Intel data and indicator queries.

5.9.1 | Unit 42 Intel Overview

Abstract

Cortex XSIAM provides Unit 42 Intel data for additional indicator information, sample analysis, and sessions & submissions analysis.

Cortex XSIAM Threat Intel includes access to the Unit 42 Intel service, enabling you to identify threats in your network and discover and contextualize trends.
Unit 42 Intel provides data from WildFire (Palo Alto Networks’ cloud-based malware sandbox), the PAN-DB URL Filtering database, Palo Alto Networks’ Unit 42
threat intelligence team, and from third-party feeds (including both closed and open-source intelligence). Unit 42 Intel data is continually updated to include the
most recent threat samples analyzed by Palo Alto Networks, enabling you to keep up with threat trends and take a proactive approach to secure your network.

Unit 42 Intel data is cloud-based and remotely maintained, so that you can view data from Unit 42 Intel and add only the information you need to your Cortex
XSIAM threat intel library. When you search for an IP address, domain, URL, or file in the Threat Intel page, you are able to view the indicator as well as the
additional information provided by Unit 42 Intel. When an indicator does not yet exist in Cortex XSIAM, but does exist in Unit 42 Intel, you are able to add the
indicator into the Cortex XSIAM threat intel library. You have the option to add the indicator and enrich it with your existing integrations or add the indicator
without enrichment. When the indicator already exists in Cortex XSIAM, but there is additional information available from Unit 42 Intel, you can update your
indicator with the most recent data from Unit 42 Intel.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 489/1003
5/8/24, 9:18 AM PDF Export

For IP addresses, domains, URLs, and files, the following information is available:

Indicator Type Layout Sections

IP address Verdict

Source

Relationships

PAN-DB Categorization

Passive DNS

URL Verdict

Source

Relationships

PAN-DB Categorization

WHOIS

Domain Verdict

Source

Relationships

PAN-DB Categorization

Passive DNS

WHOIS

File Verdict

Source

Relationships

Summary

WildFire Analysis

Related Sessions & Submissions

Sample Analysis

For files, Unit 42 Intel also provides sample analysis that helps you conduct in-depth investigations, find links between attacks, and analyze threat patterns. If the
file indicator is in the Unit 42 Intel service, you have access to a full report on activities, properties, and behaviors associated with the file. In addition, you can
see how many other malicious, suspicious, or unknown file samples included the same activities, properties, and behaviors, and also build queries to find related
samples.

Sessions & Submissions

Cortex XSIAM customers can use their Sessions & Submissions data for investigation and analysis in Cortex XSIAM. Sessions & Submissions data is available
for customers with Cortex XSIAM and one or more of the following products:

Firewall - Samples that a Palo Alto Networks firewall forwarded to WildFire.

WF Appliance - Samples that a WildFire appliance submitted to the WildFire public cloud.

Prisma SaaS - Samples submitted through Prisma SaaS.

Prisma Access - Samples submitted through Prisma Access.

While the Sample Analysis tab provides information on what a file did, the Sessions & Subscriptions tab provides in-depth information on communication
between devices. For example, you have a file indicator that has been determined to be malicious, and you have a Palo Alto Networks Firewall and Cortex
XSIAM. In the Sessions & Submissions tab, you can see where this file came from and where it has gone in your network by viewing the firewall sessions this

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 490/1003
5/8/24, 9:18 AM PDF Export

file passed through. You can see which XDR agents in your system reported the file, which tells you which machines might be infected. You can block the
external IP address with your firewall, and, if needed, isolate the affected machines to contain the attack. If the source is internal, you can investigate that
endpoint.

Relationships

The Threat Intel Management system in Cortex XSIAM includes a feed that brings in a collection of threat intel objects as indicators. These indicators are stored
in the Cortex XSIAM threat intel library and include Malware, Attack Patterns, Campaigns, and Threat Actors.

When you add or update an indicator from Unit 42 Intel, a relationship is formed in the database between the relevant threat intel object and the new or updated,
indicator.

5.9.2 | Understanding Indicator Queries

Abstract

Query indicators in the Cortex XSIAM threat intel library and in Unit 42 Intel.

There are two ways to access Threat Intel data.

When investigating an alert, you can click on an extracted indicator. The Quick View shows basic information about the indicator in Cortex XSIAM and Unit
42 (if available). Clicking on Full view shows the full Cortex XSIAM indicator summary. If the indicator also exists in Unit 42 Intel, the Unit 42 Intel tab is
available.

You can query for an indicator, which may or may not already be in the Cortex XSIAM threat intel library, from the search box on the Threat Intel page.

NOTE:

"Search" and "lookup" are different actions with different results. A search, which can include wildcards and complex queries, can return multiple results.
Searches are only performed in Cortex XSIAM . Lookups are exact values, are performed in both Cortex XSIAM and Unit 42 Intel data, and can only return
one result.

When querying directly on the Threat Intel page, the following considerations apply:

Querying for an IP address, domain, URL, or SHA256 file hash using the value contains option will query both the Cortex XSIAM threat intel library and
Unit 42 Intel, with no date range limit.

If you enter an indicator type that is not an IP address, domain, URL, or SHA256 file hash, or you enter a wildcard (contains) or complex option (Boolean
search, type:file, etc.), no lookup is performed in Unit 42. In Cortex XSIAM , a search is performed. By default, the search is for the last 7 days, but you
can adjust the date range.

Value Contains searches can only be performed in the local Cortex XSIAM threat intel library, and not in Unit 42 Intel data. Example: xample.com returns
example.com using the value contains option.

Complex searches are only conducted in the local Cortex XSIAM threat intel library, and not in Unit 42 Intel data. Example: type:URL and verdict:Malicious

For files, only the SHA256 hash returns Unit 42 Intel data.

For a query to include Unit 42 Intel results, it must be a lookup for an exact match. To perform a lookup, use value = with the exact value of the indicator.

When a query is performed in Unit 42 Intel, there are four possible results:

The indicator exists in Cortex XSIAM but does not exist in Unit 42 Intel.

The Cortex XSIAM search result is displayed in a table. Click on the value to reach the Summary tab. The Summary tab presents information about the
indicator stored in Cortex XSIAM . The Unit 42 Intel tab is greyed out.

The indicator exists in Unit 42 Intel, but does not exist in the Cortex XSIAM threat intel library.

To view the Unit 42 Intel data for this indicator, click on the indicator search term.

From the Unit 42 Intel tab, you have the option to Add the indicator to Cortex XSIAM or to Add & Enrich.

The indicator exists in Cortex XSIAM and in Unit 42 Intel.

Click on the value to reach the Summary tab. The Summary tab presents information about the indicator stored in Cortex XSIAM . Click on the Unit 42
Intel tab to view Unit 42 data. From the Unit 42 Intel tab, you have the option to Update the indicator in Cortex XSIAM with additional information from Unit
42 Intel, or to Update & Enrich.

The indicator does not exist in Cortex XSIAM or in Unit 42 Intel.

If the query was for an indicator type that is not an IP address, domain, URL, or SHA256 file hash OR if the query included a wildcard or a complex
search, the search was performed on Cortex XSIAM data from the last 7 days. You can extend the date range to see if the indicator is in Cortex XSIAM
but is older than 7 days.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 491/1003
5/8/24, 9:18 AM PDF Export

5.9.3 | Add Unit 42 Intel Data

Abstract

Add indicator data from Unit 42 Intel into Cortex XSIAM.

When you add indicators to the Cortex XSIAM threat intel library from Unit 42 Intel, the indicators are available for use in automations and playbooks.

Unit 42 Intel data is not automatically added to the Cortex XSIAM indicator database. When you query for an indicator on the Threat Intel page, in some cases
the indicator is not in the Cortex XSIAM threat intel library, but exists in Unit 42 Intel. In other cases, the indicator may already be in the Cortex XSIAM threat
intel library, but more in-depth information is available from Unit 42 Intel.

If the indicator does not exist in Cortex XSIAM, there are two options when adding the data from Unit 42 Intel.

Click on Add to XSIAM

The indicator is added to Cortex XSIAM . If the indicator is related to one or more Unit 42 threat intel objects already in (brought in through the Unit
42 Feed integration), relationships are created in the database between the Unit 42 threat intel objects and the file indicator. No third-party
enrichments are run on the indicator. We recommend using this option if, for security reasons, you do not want to expose the indicator to any third-
party services.

Click on Add to XSIAM & Enrich

The indicator is added to Cortex XSIAM . If the indicator is related to one or more Unit 42 threat intel objects already in Cortex XSIAM (brought in
through the Unit 42 Feed integration), relationships are created in the database between the Unit 42 threat intel objects and the file indicator. Your
configured third-party enrichments are run on the indicator.

Update Indicator with Unit 42 Intel

If the indicator already exists in Cortex XSIAM , but more information is available from Unit 42 Intel, the following options are available:

Click on Update

Updated Unit 42 Intel for the indicator is added to Cortex XSIAM . If the indicator is related to one or more Unit 42 threat intel objects already in
Cortex XSIAM (brought in through the Unit 42 Feed integration), relationships are created in the database between the Unit 42 threat intel objects
and the file indicator. No third-party enrichments are run on the indicator. We recommend using this option if, for security reasons, you do not want
to expose the indicator to any third-party services.

Click on Update & Enrich

Updated Unit 42 Intel for the indicator is added to Cortex XSIAM . If the indicator is related to one or more Unit 42 threat intel objects already in
Cortex XSIAM (brought in through the Unit 42 Feed integration), relationships are created in the database between the Unit 42 threat intel objects
and the file indicator. Your configured third-party enrichments are run on the indicator.

5.9.4 | Sample Analysis

Abstract

View static and dynamic analysis of file samples to identify malware, investigate trends, and create reports.

Cortex XSIAM Sample Analysis tools enable you to conduct in-depth investigations and analyses of file samples. File samples are run and analyzed using Palo
Alto Networks’ WildFire cloud-based threat analysis service, and you can view dynamic analysis of observed behavior, static analysis of the file contents, and
related sessions and submissions.

For example, you have an alert with an extracted file indicator. The Unit 42 Intel tab shows the file’s behavior. You scroll through the sample's behavior and see
a suspicious behavior: Powershell.exe wrote to a file in the Administrator's User folder, named 443.exe. You want to find other samples with the same behavior,
and to determine if they are related to a known adversary or malware - so you add that specific behavior to your search. When you run the search, you see that
this behavior is associated with Emotet, a known banking trojan (malware). You have identified your original file sample as part of a larger threat campaign and
you can now take steps to remediate.

The Unit 42 Intel tab for a file sample includes:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 492/1003
5/8/24, 9:18 AM PDF Export

WildFire Dynamic Analysis - Observed Behavior

A high-level overview of the behavior observed when the file was run in the WildFire sandbox. Examples might include potentially malicious behaviors
such as connecting to a potentially vulnerable port or creating an executable file in the Windows folder, as well as behaviors frequently performed by
legitimate software, such as scheduling a task in Windows Task Scheduler.

WildFire Dynamic Analysis - Sections

The dynamic analysis provides a granular view of file activity, process activity, registry activity, connection activity, etc. Files run in a custom-built, evasion-
resistant virtual environment in which previously unknown submissions are detonated to determine real-world effects and behavior. Behavior can be
observed in one or more operating system environments.

WildFire Static Analysis

The WildFire Static analysis detects known threats by analyzing the characteristics of a sample prior to execution in the sandbox. Static analysis can
provide instant identification of malware variants and includes dynamic unpacking to analyze threats attempting to evade detection using packer tools.

Related Sessions & Submissions

Shows any related sessions and submissions where the file was seen. Related sessions and submissions data is available if you have one of the
following products: Palo Alto Networks Firewall, WildFire, Prisma SaaS, or Prisma Access.

In addition to viewing the file activities, properties, and behaviors within the Cortex XSIAM Threat Intel page, you can also download a PDF with a full report.

Sample Analysis Search

You can use Unit 42 Intel data to build complex searches for file samples with similar characteristics. For example, in WildFire Dynamic Analysis - Sections, you
can add Parent Process, Action, or Parameters or all characteristics of the file activity to a search. In WildFire Static Analysis, you can add Behavior,
Description, or both characteristics to a search.

WildFire Dynamic Analysis - Sections shows not only the observed behavior of the file sample, but also how many times the behavior was observed in other Unit
42 samples - malicious samples, suspicious samples, and unknown samples. For example, you see that the parent process sample.exe wrote to file
data1.tmp. The same behavior occurred in 75 samples that had a verdict of malicious. To investigate further you can build a new search that contains this
specific behavior and view the relevant samples. To add an entire row to a new Sample Analysis search, hover the cursor over the last column on the right, in
the row that you want to add.

A drill-down button appears when you hover over the empty column. Click on the button to see the two options:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 493/1003
5/8/24, 9:18 AM PDF Export

Add to Sample Analysis Search

Adds selected information from the row to a Sample Analysis search. After choosing Add to Sample Analysis search, a pop-up appears at the bottom of
the screen: Your selected terms were added to Sample Analysis Search. Go to Sample Analysis tab to apply the added terms.. If you click on the link, you
go to the Sample Analysis tab where you can edit or run your search for samples that exhibited the same behavior. You can also Add to Saved Queries. If
you do not click the link, the popup will disappear and you can continue to add additional items to the search. To run the search without clicking on the
popup link, go to the Threat Intel page and click on the Sample Analysis tab.

Instead of adding the entire row, you can also add one or more items in the row to a search. For example, in Wildfire Dynamic Analysis - Sections - File
Activity, you can add the parent process and the action, without including the parameters, by clicking the drill-down search button to the right of each
option you want to add.

Create New Sample Analysis Search

Clears any search characteristics you have already added and starts a new Sample Analysis search with the selected characteristic(s). After choosing this
option, a pop-up appears at the bottom of the screen: Your selected terms were added to Sample Analysis Search. Go to Sample Analysis tab to apply the
added terms.. If you click on the link, you go to the Sample Analysis tab where you can edit or run your search for samples that exhibited the same
behavior. You can also Add to Saved Queries. If you do not click the link, the popup will disappear and you can continue to add additional items to the
search. To run the search without clicking on the popup link, go to the Threat Intel page and click on the Sample Analysis tab.

NOTE:

The Sample Analysis search page includes a drop-down for Sample Type. Options include All Samples, Public Samples, and My Samples. The My Samples
option is only available for customers with a Palo Alto Networks Firewall, WildFire, Cortex XDR, Prisma SaaS, or Prisma Access.

NOTE:

Known limitation: When searching on the Sample Analysis page for relationships -relationships"", some results may appear without their specific
relationships listed, due to internal relationship permissions.

5.9.5 | Sessions and Submissions

Abstract

Use firewall sessions and submissions to products such as XDR and Prisma Cloud, with Cortex XSIAM, to find threats and protect your network.

The Sessions & Submissions tab enables you to use your sessions and submissions data for investigation and analysis. Sessions and submissions data are
available for customers with Cortex XSIAM and at least one of the following products:

Palo Alto Networks Firewall

WildFire

Prisma SaaS

Prisma Access

Sessions refer to firewall sessions, while Submissions refer to logs of samples reported to Wildfire from other Palo Alto Networks products. Sessions data show
you connections from one endpoint to another, and submissions data show you if a file was found on a specific endpoint.

With Sessions & Submissions data, you can take steps to block external IP addresses that are the sources of malicious files and threat campaigns. You can also
find compromised machines within your network, isolate them as needed, and take remediation steps.

For example, you can search for a file hash in the Sessions & Submissions tab. If the file appeared in one or more sessions or submissions, you can see when
and where that occurred. Firewall session data enables you to view the source IP and the destination IP for each session that included the file. If you have
Cortex XDR, you can see which XDR agent(s) reported the file and which computer(s) are affected.

NOTE:

Known limitation: When searching on the Sessions & Submissions page for relationships -relationships"", some results may appear without their specific
relationships listed, due to internal relationship permissions.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 494/1003
5/8/24, 9:18 AM PDF Export

Sessions & Submissions Search

You can use Unit 42 Intel data to build complex searches for sessions and submissions with similar characteristics. From within the Session Summary page, any
of the items listed in the Basic Information, Sample Information, or Metadata sections can be used to create a new search for similar sessions and submissions.
For example, you can create a new search that includes a specific destination IP and a specific file name that you found together in a session.

To build a new search, hover your cursor over the end of the desired row. A drill-down button appears. When you click the button, two search options are
displayed.

Add to Sessions & Submissions Search

Adds selected information to a Sessions & Submissions search. After choosing Add to Sessions & Submissions search, a pop-up appears at the bottom of
the screen: Your selected terms were added to Sessions Analysis Search. Go to Sessions Analysis tab to apply the added terms. If you click on the link,
you go to the Sessions & Submissions tab where you can edit or run your search for sessions and submissions that exhibited the same behavior. You can
also Add to Saved Queries. If you do not click the link, the popup will disappear and you can continue to add additional items to the search. To run the
search without clicking on the popup link, go to the Threat Intel page and click on the Sessions & Submissions tab.

Create New Sessions & Submissions Search

Clears any search characteristics you have already added and starts a new Sessions & Submissions search with the selected characteristic(s). After
choosing this option, a pop-up appears at the bottom of the screen: Your selected terms were added to Sessions Analysis Search. Go to Sessions
Analysis tab to apply the added terms. If you click on the link, you go to the Sessions & Submissions tab where you can edit or run your search for
sessions and submissions that exhibited the same behavior. You can also Add to Saved Queries. If you do not click the link, the popup will disappear and
you can continue to add additional items to the search. To run the search without clicking on the popup link, go to the Threat Intel page and click on the
Sessions & Submissions tab.

6 | Broker VM
Abstract

Learn about the Cortex XSIAM Broker virtual machine (VM).

6.1 | Broker VM
Abstract

Learn about the Cortex XSIAM Broker virtual machine (VM).

6.1.1 | Broker VM Overview

Abstract

Learn about the Cortex XSIAM Broker virtual machine (VM) and why use it in your network configuration.

The Palo Alto Networks Broker is a secured virtual machine (VM), integrated with Cortex XSIAM, that bridges your network and Cortex XSIAM. By setting up the
broker, you establish a secure connection in which you can route your endpoints, and collect and forward logs and files for analysis.

The Broker can be leveraged for running different services separately on the VM using the same Palo Alto Networks authentication. Once installed, the Broker
VM automatically receives updates and enhancements from Cortex XSIAM, providing you with new capabilities without having to install a new VM.

6.1.2 | Set up Broker VM

Abstract

Learn more about setting up the broker VM to establish a secure connection.

The Palo Alto Networks Broker VM is a secured virtual machine (VM), integrated with Cortex XSIAM, that bridges your network and the Cortex XSIAM app. By
setting up the Broker VM, you establish a secure connection in which you can route your endpoints, collect logs, and forward logs and files for analysis.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 495/1003
5/8/24, 9:18 AM PDF Export

Cortex XSIAM can leverage the Broker VM to run different services separately using the same Palo Alto Networks authentication. After you complete the initial
setup, the Broker VM automatically receives updates and enhancements from Cortex XSIAM, providing you with new capabilities without having to install a new
VM or manually update the existing VM.

You can set up a standalone Broker VM or add a Broker VM to a High Availabilty (HA) cluster to prevent a single point of failure.

6.1.2.1 | Configure the Broker VM

Abstract

Configure any Cortex XSIAM Broker virtual machine (VM) as necessary.

To set up the Broker virtual machine (VM), you need to deploy an image created by Palo Alto Networks on your network or supported cloud infrastructure and
activate the available applications. You can set up several Broker VMs for the same tenant to support larger environments. Ensure each environment matches
the necessary requirements.

Requirements

Before you set up the Broker VM, verify you meet the following requirements.

Hardware

For standard installation, use a minimum of a 4-core processor, 8 GB RAM, and 512 GB disk. If you only intend to use the Broker VM for agent proxy, you can
use a 2-core processor. If you intend to use the Broker VM for agent installer and content caching, you must use an 8-core processor.

NOTE:

The Broker VM comes with a 512 GB disk. Therefore, deploy the Broker VM with thin provisioning, meaning the hard disk can grow up to 512 GB but will do
so only if needed.

Bandwidth

Bandwidth is higher than 10 mbit/s.

When the Broker VM is collecting data, the optimal outgoing bandwidth into the Cortex XSIAM server should be about 25% of the incoming data traffic into the
Broker VM applets.

IMPORTANT:

There can be cases in which the Broker VM requires up to 50% of the incoming bandwidth as outgoing. Such cases can be, network instability between the
Broker VM and Cortex XSIAM, or data that is being collected, but not well compressed.

Virtual machine compatibility

Ensure that your virtual machine (VM) is compatible with one of the following options and install the applicable broker image according to the installation steps
provided:

Infrastructure Image Type Additional Requirements

Amazon Web Services (AWS) VMDK Create a Broker VM Amazon Machine Image
(AMI)

Google Cloud Platform VMDK Set up the Broker VM on Google Cloud Platform
(GCP)

Microsoft Azure VHD (Azure) Create a Broker VM Azure Image

Microsoft Hyper-V 2012 VHD Hyper-V 2012 or later

Create a Broker VM Image for Microsoft Hyper-V

Alibaba Cloud QCOW2 Create a Broker VM Image for Alibaba Cloud

Nutanix Hypervisor QCOW2 Nutanix AHV 2021

Create a Broker VM Image for a Nutanix

Hypervisor

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 496/1003
5/8/24, 9:18 AM PDF Export

Infrastructure Image Type Additional Requirements

KVM QCOW2 Create a Broker VM Image for a KVM using

Ubuntu

VMware ESXi OVA VMware ESXi 6.5 or later

Set up Broker VM on VMware ESXi using

vSphere Client

Communication between services and applications

Enable communication between the Broker Service, and other Palo Alto Networks services and applications.

FQDN, Protocol, And Port Description

(Default) Broker's NTP server used for broker registration and communication
encryption. The Broker VM provides default servers you can use, or you can
time.google.com define an NTP server of your choice.

pool.ntp.org

UDP port 123

br-<XDR tenant>.xdr.<region>.paloaltonetworks.com Broker Service server depending on the region of your deployment, such as
us or eu.
HTTPS over TCP port 443

distributions.traps.paloaltonetworks.com Information needed to communicate with your Cortex XSIAM tenant. Used
by tenants deployed in all regions.
HTTPS over TCP port 443

br-<xdr-tenant>.xdr.federal.paloaltonetworks.com Broker Service server for Federal (US Government) deployment.

HTTPS over TCP port 443

distributions-prod-fed.traps.paloaltonetworks.com Used by tenants with Federal (US Government) deployment

HTTPS over TCP port 443

Enable access to Cortex XSIAM

Enable Access to Cortex XSIAM from the Broker VM to allow communication between agents and collectors and Cortex XSIAM.

NOTE:

If you use SSL decryption in your firewalls, you need to add a trusted self-signed certificate authority on the Broker VM to prevent any difficulties with SSL
decryption. If adding a CA certificate to the broker is not possible, ensure that you’ve added the Broker Service FQDNs to the SSL Decryption Exclusion list on
your firewalls.

Initial Setup

Perform the following procedures in the order listed below.

Task 1. Generate a token for your broker

1. Select Settings → Configurations → Data Broker → Broker VMs.

2. Click Add Broker → Generate Token, and copy to your clipboard. The token is valid for 24 hours. A new token is generated each time you select Generate
Token.

Task 2. Open the Broker VM URL

Depending on the Broker VM version, navigate to either of the following URLs:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 497/1003
5/8/24, 9:18 AM PDF Export

From Broker VM version 19.x.x and later: https://<broker_vm_ip_address>.:4443

From Broker VM version 18.x.x and earlier: https://<broker_vm_ip_address>/

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.

Task 3. Log in and set a new password

Log in with the default password !nitialPassw0rd, and then define your own unique password. The password must contain a minimum of eight characters,
contain letters and numbers, and at least one capital letter and one special character.

How to configure Broker VM settings

Perform the following procedures in the order listed below.

Task 1. Configure the Broker VM settings

1. Define the network interfaces settings.

Network Interfaces section

Review the pre-configured Name, IP address, and MAC Address, and select the Address Allocation: DHCP (default) or Static. If you choose Static, define
the static IP address, Netmask, Default Gateway, and DNS Server settings, and then save your configurations.

IMPORTANT:

When configuring more than one network interface, ensure that only one Default Gateway is defined. The rest must be set to 0.0.0.0, which
configures them as undefined.

You can also specify which of the network interfaces is designated as the Admin and can be used to access the Broker VM web interface. Only one
interface can be assigned for this purpose from all of the available network interface on the Broker VM, and the rest should be set to Disable.

2. (Optional) Set the internal network settings (Requires Broker VM 14.0.42 and later).

Internal Network

Specify a network subnet to avoid the Broker VM dockers colliding with your internal network. By default, the Network Subnet is set to 172.17.0.1/16.

IMPORTANT:

Internal IP must be:

Formatted as prefix/mask, for example 192.0.2.1/24.

Must be within /8 to /24 range.

Cannot be configured to end with a zero.

For Broker VM version 9.0 and lower, Cortex XSIAM accepts only 172.17.0.0/16.

3. (Optional) Configure a proxy server address and other related details to route Broker VM communication.

Proxy Server

1. Select the proxy Type as HTTP, SOCKS4, or SOCKS5.

NOTE:

You can configure another Broker VM as a proxy server for this Broker VM by selecting the HTTP type. When selecting HTTP to route Broker VM
communication, you need to add the IP Address and Port number (set when activating the Agent Proxy) for another Broker VM registered in your
tenant. This designates the other Broker VM as a proxy for this Broker VM.

2. Specify the proxy Address (IP or FQDN), Port, and an optional User and Password. Select the pencil icon to specify the password. Avoid using
special characters in the proxy username and password.

3. Save your configurations.

4. (Optional) Configure your NTP servers (Requires Broker VM 8.0 and later).

Specify the required server addresses using the FQDN or IP address of the server.

5. (Optional) Allow SSH connections to the Broker VM (Requires Broker VM 8.0 and later).

SSH Access section

Enable or disable SSH connections to the Broker VM. SSH access is authenticated using a public key, provided by the user. Using a public key grants
remote access to colleagues and Cortex XSIAM support who need the private key. You must have Instance Administrator role permissions to configure
SSH access.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 498/1003
5/8/24, 9:18 AM PDF Export

To enable connection, generate an RSA Key Pair, and enter the public key in the SSH Public Key section. Once one SSH public key is added, you can
Add Another. When you are finished, Save your configuration.

When using PuTTYgen to create your public and private key pairs, you need to copy the public key generated in the Public key for pasting into OpenSSH
authorized_keys file box, and paste it in the Broker VM SSH Public Key section as explained above. This public key is only available when the PuTTYgen
console is open after the public key is generated. If you close the PuTTYgen console before pasting the public key, you will need to generate a new public
key.

When you SSH the Broker VM using PuTTY or a command prompt, you need to use the admin username. For example:

ssh -i [/path/to/private.key] admin@[broker_vm_address]

IMPORTANT:

We strongly recommend disabling SSH connectivity when it's not being used. Therefore, activate SSH connectivity when it's needed and disable it right
afterwards.

6. (Optional) Update the SSL Server certificates for the Broker VM (Requires Broker VM 10.1.9 and later).

SSL Server Certificates section

Upload your signed server certificate and key to establish a validated secure SSL connection between your endpoints and the Broker VM. When you
configure the server certificate and the key files in the Broker VM UI, Cortex XSIAM automatically updates them in the tenant UI. Cortex XSIAM validates
that the certificate and key match, but does not validate the Certificate Authority (CA).

NOTE:

The Palo Alto Networks Broker supports only strong cipher SHA256-based certificates. MD5/SHA1-based certificates are not supported.

7. Update the Trusted CA Certificate for the Broker VM.

Trusted CA Certificate section

Upload your signed Certificate Authority (CA) certificate or Certificate Authority chain file in a PEM format with the associated key, and click Save. If you
use SSL decryption in your firewalls, you need to add a trusted self-signed CA certificate on the Broker VM to prevent any difficulties with SSL decryption.
For example, when configuring Palo Alto Networks NGFW to decrypt SSL using a self-signed certificate, you need to ensure the Broker VM can validate a
self-signed CA by uploading the cert_ssl-decrypt.crt file on the Broker VM.

NOTE:

If adding a CA certificate to the Broker VM is not possible, ensure that you’ve added the Broker Service FQDNs to the SSL Decryption Exclusion list on
your firewalls. See Enable Access to Cortex XDR.

8. (Optional) Collect and Generate New Logs (Requires Broker VM 8.0 and later). Your Cortex XSIAM logs will download automatically after approximately
30 seconds.

Task 2. Register your Broker VM

Register and enter your unique Token, created in the Broker VMs page. This can take up to 30 seconds.

After a successful registration, Cortex XSIAM displays a notification.

You are directed to Settings → Configurations → Data Broker → Broker VMs. The Broker VMs page displays your Broker VM details and allows you to edit the
defined configurations.

6.1.2.1.1 | Create a Broker VM Amazon Machine Image (AMI)

Abstract

Learn how to create an Amazon Machine Image (AMI) file of your Cortex XSIAM Broker virtual machine (VM).

After you download your Cortex XSIAM Broker VMDK image, you can convert the image to an Amazon Web Services (AWS) Amazon Machine Image (AMI)
using the AWS CLI. The task below explains how to do this on Ubuntu Linux.

PREREQUISITE:

Download a Cortex XSIAM Broker VM VMDK image. For more information, see the virtual machine compatability requirements in Configure the Broker
VM.

You need to set up an AWS VM Import role (vmimport) before you continue with the steps to convert the image as it is required for the import-image
CLI command. You can use a different role, if the role vmimport doesn't exist or doesn't have the required permissions. For more information on setting
up an AWS VM Import role and the permissions required, see Required service role.

To convert the image to AWS, perform the following procedures in the order listed below.

Task 1. Create an IAM User with Proper Permissions

You need to log in using an AWS Identity and Access Management (IAM) user, where the permissions are defined in the IAM policy to use the virtual machine
Import and export.

1. Log in to the AWS IAM Console, and in the navigation pane, select Access Management → Users → Add Users.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 499/1003
5/8/24, 9:18 AM PDF Export

2. Select Access key - Programmatic access as the AWS credential type, and click Next: Permissions.

3. Select Attach Existing Policies directly → Create Policy,

4. In the JSON tab, copy and paste the following syntax to define the policy:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetBucketLocation",
"s3:GetObject",
"s3:PutObject"
],
"Resource": ["arn:aws:s3:::mys3bucket","arn:aws:s3:::mys3bucket/*"]
},
{
"Effect": "Allow",
"Action": [
"ec2:CancelConversionTask",
"ec2:CancelExportTask",
"ec2:CreateImage",
"ec2:CreateInstanceExportTask",
"ec2:CreateTags",
"ec2:DescribeConversionTasks",
"ec2:DescribeExportTasks",
"ec2:DescribeExportImageTasks",
"ec2:DescribeImages",
"ec2:DescribeInstanceStatus",
"ec2:DescribeInstances",
"ec2:DescribeSnapshots",
"ec2:DescribeTags",
"ec2:ExportImage",
"ec2:ImportInstance",
"ec2:ImportVolume",
"ec2:StartInstances",
"ec2:StopInstances",
"ec2:TerminateInstances",
"ec2:ImportImage",
"ec2:ImportSnapshot",
"ec2:DescribeImportImageTasks",
"ec2:DescribeImportSnapshotTasks",
"ec2:CancelImportTask"
],
"Resource": "*"
}
]
}

5. Click Next until you can specify the Policy name, and then click Create Policy.

6. Select the policy that you created above based on the syntax you added.

7. Complete the user creation process.

8. After confirmation that the user is created, record the following user information, which you will need later.

User name

Access key ID

Secret access key

Task 2. Setup AWS CLI in Ubuntu 18

Install the AWS CLI and configure it with the IAM user that you created.

1. Login to the server with admin privilege and install the AWS CLI.

# sudo bash
# apt install awscli

2. Run the following command to configure the AWS CLI:

# aws configure

You need to specify the proper configurations for the following:

AWS Access Key ID—The Access key ID for the IAM user you created.

AWS Secret Access Key—The Secret access key for the IAM user you created.

Default region name—The Region where you've defined the IAM user you created.

You are now ready to implement commands in the AWS CLI.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 500/1003
5/8/24, 9:18 AM PDF Export

Task 3. Create an AMI Image

To create an AMI image, you need to download Broker VM VMDK file from the Cortex XSIAM Web Console, import this file to your S3 bucket, and then convert
the VMDK file in the S3 bucket into an AMI Image.

1. In the Cortex XSIAM Web Console , select Settings → Configurations → Data Broker → Broker VMs → Add Broker → VMDK.

2. Download the VMDK file, such as broker-vm-<broker-vm-version>.vmdk, to you ubuntu computer.

3. Navigate and log in to your AWS account.

4. In the AWS Console, navigate to Services → Storage → S3 → Buckets.

5. In the S3 buckets page, + Create bucket to upload your Broker VM image to this bucket.

Specify a unique name for the S3 bucket and use the default configurations.

6. Upload the Broker VM VMDK you downloaded from Cortex XSIAM to the AWS S3 bucket.

Run

# aws s3 cp ~/<path/to/broker-vm-version.vmdk> s3://<your_bucket/broker-vm-version.vmdk>

7. Prepare the following configurations files on your hard drive.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 501/1003
5/8/24, 9:18 AM PDF Export

configuration.json

Read more...

1. Run the following command in Ubuntu:

# vi configuration.json

2. Copy and paste the following syntax into the json file.

In S3Bucket, replace <your_bucket> with the Bucket Name and not its ARN Name. S3Key is the VMDK filename, which you should replace
instead of <broker-vm-version.vmdk>.

[
{
"Description":"Cortex XSIAM Broker VM <version>",
"Format":"vmdk",
"UserBucket":{
"S3Bucket":"<your_bucket>",
"S3Key":"<broker-vm-version.vmdk>"
}
}
]

trust-policy.json

Read more...

1. Run the following command in ubuntu:

# vi trust-policy.json

2. Copy and paste the following syntax into the json file.

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": { "Service": "vmie.amazonaws.com" },
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals":{
"sts:Externalid": "vmimport"
}
}
}
]
}

role-policy.json

Read more...

1. Run the following command in Ubuntu:

# vi role-policy.json

2. Copy and paste the following syntax into the json file. Replace the <disk-image-file-bucket> and <export-bucket> with the correct bucket
name. You can specify * to configure access to all your S3 buckets.

{
"Version":"2012-10-17",
"Statement":[
{
"Effect": "Allow",
"Action": [
"s3:GetBucketLocation",
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::<disk-image-file-bucket>",
"arn:aws:s3:::<disk-image-file-bucket>/*"
]
},
{
"Effect": "Allow",
"Action": [
"s3:GetBucketLocation",
"s3:GetObject",
"s3:ListBucket",
"s3:PutObject",
"s3:GetBucketAcl"
],
"Resource": [
"arn:aws:s3:::<export-bucket>",
"arn:aws:s3:::<export-bucket>/*"
]
},

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 502/1003
5/8/24, 9:18 AM PDF Export

{
"Effect": "Allow",
"Action": [
"ec2:ModifySnapshotAttribute",
"ec2:CopySnapshot",
"ec2:RegisterImage",
"ec2:Describe*"
],
"Resource": "*"
}
]
}

8. Use the create-role command to create a role named vmimport and grant VM import and export access to the trust-policy.json file.

# aws iam create-role --role-name vmimport --assume-role-policy-document "file://trust-policy.json"

9. Use the put-role-policy command to attach the policy to the vmimport role created above.

# aws iam put-role-policy --role-name vmimport --policy-name vmimport --policy-document "file:// role-policy.json"

10. Create an AMI image from the VMDK file.

Run

# aws ec2 import-image --description "Cortex XSIAM Broker VM <Version>" --disk-containers "file://configuration.json"

NOTE:

Creating an AMI image can take up to 60 minutes to complete.

To track the progress, use the task id value from the output and run:

# aws ec2 describe-import-image-tasks --import-task-ids import-ami-<task-id>

Completed status output example:

{ "ImportImageTasks":[ { "...", "SnapshotDetails":[ { "Description":"Broker VM version", "DeviceName":"/dev/<name>",

"DiskImageSize":2976817664.0, "Format":"VMDK", "SnapshotId":"snap-1234567890", "Status":"completed", "UserBucket":{
"S3Bucket":"broker-vm", "S3Key":"broker-vm-<version>.vmdk" } } ], "Status":"completed", "..." } ]}

Once the task is complete, the AMI Image is ready for use.

11. (Optional) After the AMI image has been created, you can define a new name for the image.

Select Services → EC2 → IMAGES → AMIs and locate your AMI image using the task ID. Select the pencil icon to specify a new name.

Task 4. Launch a Broker VM Instance in AWS EC2

You can launch the a Broker VM instance in AWS EC2 using the AMI Image created.

IMPORTANT:

A t2.medium (4GB RAM) is the lowest machine type that can be used as an instance type.

1. To view the AMI image that you added, select Services → EC2 → Images → AMIs.

2. Select EC2 → Instances, search for your AMI image, and Launch the file.

3. In the Launch Instance Wizard define the instance according to your company requirements and Launch.

4. (Optional) In the Instances page, locate your instance and use the pencil icon to rename the instance Name.

5. Define HTTPS and SSH access to your instance.

Right-click your instance, and select Networking → Change Security Groups.

In the Change Security Groups pop-up, select HTTPS to be able to access the Broker VM Web UI, and SSH to allow for remote access when
troubleshooting. Make sure to allow these connections to the Broker VM from secure networks only.

NOTE:

Assigning security groups can take up to 15 minutes.

6. Verify the Broker VM has started correctly.

Locate your instance, right-click, and select Instance Settings → Get Instance Screenshot.

You are directed to your Broker VM console listing your Broker details.

Task 5. Register the Broker VM

Registration of the Broker VM to Cortex XSIAM is performed from the Broker VM Web Console.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 503/1003
5/8/24, 9:18 AM PDF Export

1. Obtain a registration token from the Cortex XSIAM Web Console by selecting Settings → Configurations → Data Broker → Broker VMs → Add Broker →
Generate Token.

2. Determine the IP Address of the EC2 instance and use it to open the Broker VM Web Console, such as https://<ip_address>.

3. Complete the registration process by entering the token information.

6.1.2.1.2 | Create a Broker VM Azure Image

Abstract

Learn how to create a Microsoft Azure image file of your Cortex XSIAM Broker virtual machine (VM).

After you download your Cortex XSIAM Broker VHD (Azure) image, you need to upload it to Azure as a storage blob.

PREREQUISITE:

Download a Cortex XSIAM Broker VM VHD (Azure) image. For more information, see the virtual machine compatability requirements in Configure the Broker
VM.

Perform the following procedures in the order listed below.

Task 1. Decompress the downloaded VHD (Azure) image

Make sure you decompress the zipped hard disk file on a server that has more then 512GB of free space.

NOTE:

Decompression can take up to a few hours.

Task 2. Create a new storage blob on your Azure account by uploading the VHD file

You can use to upload either from Microsoft Windows or Ubuntu.

Microsoft Windows

1. Verify you have:

Windows PowerShell version 5.1 or later.

.NET Framework 4.7.2 or later.

2. Open PowerShell and execute Set-ExecutionPolicy unrestricted.

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201-Force

3. Install azure cmdlets.

Install-Module -Name Az -AllowClobber

4. Connect to your Azure account.

Connect-AzAccount

5. Start the upload.

az storage blob upload -f <vhd to upload> -n <vhd name> -c <container name> --account-name <account name>.

NOTE:

Upload can take up to a few hours.

Ubuntu 18.04

1. Install Azure util.

curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash

2. Connect to Azure.

az login

3. Start the upload.

az storage blob upload -f <vhd to upload> -n <vhd name> -c <container name> --account-name <account name>

Task 3. Add and configure a new disk in Azure

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 504/1003
5/8/24, 9:18 AM PDF Export

1. In the Azure home page, navigate to Azure services → Disks and Add a new disk.

2. Navigate to the Create a managed disk → Basics page, and define the following information:

Project details

Resource group: Select your resource group.

Disk details

Disk name: Enter a name for the disk object.

Region: Select your preferred region.

Source type: Select Storage Blob.

Additional fields are displayed, which you can define as follows:

Source blob:

Read more...

1. Select Browse. You are directed to the Storage accounts page.

2. From the navigation panel, select the bucket and then container to which you uploaded the Cortex XSIAM VHD image.

3. In the Container page, Select your VHD image.

OS type: Select Linux

VM generation: Select Gen 1

3. Check you settings by clicking Review + create.

Task 4. Create the Broker VM disk

1. Create your Broker VM disk, and after deployment is complete, click Go to resource.

2. In your created Disks page, click Create VM.

3. In the Create a virtual machine page, define the following:

Instance details

(Optional) Virtual machine name—Enter the same name as the disk name you defined.

Size—Select the size according to your company guidelines.

Select Next to navigate to the Networking tab.

Network interface

NIC network security group—Select Advanced.

Configure network security group—Select HTTPS to be able to access the Broker VM Web UI, and SSH to allow for remote access when
troubleshooting. Make sure to allow these connection to the Broker VM from secure networks only.

4. To check your settings, click Review + create.

5. Create your VM.

After deployment is complete, click Go to resource. You are directed to your VM page.

NOTE:

Creating the VM can take up to 15 minutes. The Broker VM Web UI is not accessible during this time.

6.1.2.1.3 | Create a Broker VM Image for Microsoft Hyper-V

Abstract

Learn how to create an image file of your Cortex XSIAM Broker virtual machine (VM) for Microsoft Hyper-V.

To create a Broker virtual machine (VM) image for Microsoft Hyper-V, you need to download a Cortex XSIAM Broker VM VHD image, and then upload it to your
newly created Microsoft Hyper-V VM. Microsoft Hyper-V 2012 or later is supported.

PREREQUISITE:

Download a Cortex XSIAM Broker VM VHD image. For more information, see the virtual machine compatability requirements in Configure the Broker VM.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 505/1003
5/8/24, 9:18 AM PDF Export

Perform the following procedures in the order listed below.

Task 1. Create a new VM in the Hyper-V Manager and upload the VHD image

1. In the Hyper-V Manager, select New → Virtual Machine to open the New Virtual Machine Wizard.

2. In the Specify Name and Location screen, specify a Name for your VM, and click Next.

3. In the Specify Generation screen, select Generation 1, and click Next.

4. In the Assign Memory screen, set the Startup memory to 8192 MB, and click Next.

5. In the Configuring Networking screen, select the network adapter for the Connection, and click Next.

6. In the Connect Virtual Hard Disk screen, select Use an existing virtual hard disk, Browse to the downloaded VHD image file, and click Next.

7. In the Completing the New Virtual Machine Wizard screen, click Finish.

Task 2. Start the VM that you created for Microsoft Hyper-V

1. From the Virtual Machines list, right-click the VM that you created, and select Start.

2. When the State of the VM updates to Running, right-click the VM, and select Connect.

The Broker VM console now displays.

6.1.2.1.4 | Set up the Broker VM on Google Cloud Platform (GCP)

Abstract

Learn more about how to set up your Cortex XSIAM Broker VM on Google Cloud Platform.

You can deploy the Broker VM on Google Cloud Platform. The Broker VM allows communication with external services through the installation and setup of
applets such as the syslog collector applet.

To set up the Broker VM on the Google Cloud Platform, install the VMDK image provided in Cortex XSIAM.

PREREQUISITE:

Download a Cortex XSIAM Broker VM VMDK image. For more information, see the virtual machine compatability requirements in Configure the Broker
VM.

To complete the set up, you must have G Cloud installed and have an authenticated user account.

Perform the following procedures in the order listed below.

Task 1. Create a Google Cloud Storage bucket in G Cloud

From G Cloud, create a Google Cloud Storage bucket to store the Broker VM image.

1. Create a project in GCP and enable Google Cloud Storage, for example: brokers-project. Make sure you have defined a Default Network.

2. Create a bucket to store the image, such as broker-vms.

Task 2. Set up the GCP project

Open a command prompt and run the following:

gcloud config set project <project-name>

Task 3. Upload the VMDK image to the Google Cloud Storage bucket

Upload the VMDK image to the bucket, run the following:

gsutil cp </path/to/broker.vmdk> gs://<bucket-name>

Task 4. Import the GCP image

You can import the GCP image using either G Cloud CLI or Google Cloud console.

NOTE:

The import tool uses Cloud Build API, which must be enabled in your project. For image import to work, Cloud Build service account must have
compute.admin and iam.serviceAccountUser roles. When using the Google Cloud console to import the image, you will be prompted to add these
permissions automatically.

gcloud CLI
PREREQUISITE:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 506/1003
5/8/24, 9:18 AM PDF Export

Before importing a GCP image using the gcloud CLI, ensure that you update the Google Cloud components to version 371.0.0 and above using the following
command:
gcloud components update

The following command uses the minimum required parameters. For more information on permissions and available parameters, refer to the Google Cloud
SDK.

Open a command prompt and run the following:

gcloud compute images import <VMDK image> --data-disk --source-file="gs://<image path>" --network=<network_name> --subnet=<subnet_name> --zone=<region> --async
Google Cloud Console

Task 5. Create a new instance of the image

When the Google Compute completes the image creation, create a new instance.

1. From the Google Cloud Platform, select Compute Engine → VM instances.

2. Click Create instance.

3. In the Boot disk option, choose Custom images and select the image you created.

4. Set up the instance according to your needs.

If you are using the Broker VM to facilitate only Agent Proxy, use e2-startdard-2. If you are using the Broker VM for multiple applets, use e2-standard-4.

Task 6. Allow the 4443 port in your firewall configuration by creating a firewall rule

1. From the Google Cloud menu, select VPC network → Firewall, and click CREATE FIREWALL RULE.

2. Set the following parameters for the rule:

Name: Name of the rule.

Network: Select the applicable network where the Broker VM resides.

Direction of traffic: Select Ingress (default).

Targets: Select All instances in the network.

Source IPv4 ranges: Enter the IP network of computers that will be connecting to the Broker VM. To include all machines, enter 0.0.0.0/0.

TCP: Enter port 4443.

3. Click CREATE.

The rule is listed under VPC firewall rules.

Task 7. Verify that the firewall rule is assigned to the Broker VM

1. From the Google Cloud menu, select Compute Engine → VM instances.

2. For the particular Broker VM containing the rule, select the ellipse to display More actions, and select View network details.

3. In the Firewall and routes details section, select the FIREWALLS tab.

4. Verify that the firewall rule is listed.

You can now connect to the Broker VM web console using the Broker VM IP address. Connect via https over port 4443 using the format https://<ip
address>:4443.

6.1.2.1.5 | Create a Broker VM Image for Alibaba Cloud

Abstract

Learn how to create an image file of your Cortex XSIAM Broker virtual machine (VM) for Alibaba Cloud.

After you download your Cortex XSIAM Broker virtual machine (VM) QCOW2 image, you need to upload it to Alibaba Cloud. Since the image file is larger than
5G, you need to download the ossutil utility file provided by Alibaba Cloud to upload the image.

PREREQUISITE:

Download a Cortex XSIAM Broker VM QCOW2 image. For more information, see the virtual machine compatability requirements in Configure the Broker VM.

Perform the following procedures in the order listed below.

Task 1. Download the ossutil utility file provided by Alibaba Cloud

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 507/1003
5/8/24, 9:18 AM PDF Export

The download is dependent on the operating system and infrastructure you are using.

Alibaba Cloud supports using the following operating systems for the utility file: Windows, Linux, and macOS.

Supported architectures: x86 (32-bit and 64-bit) and ARM (32-bit and 64-bit)

For more information on downloading the utility, see the Alibaba Cloud documentation.

Task 2. Upload the image file to Alibaba Cloud using the utility file you downloaded

The command is dependent on the operating system and architecture you are using. Below are a few examples of the commands to use based on the different
operating systems and architectures, which you may need to modify based on your system requirements.

Linux (using CLI)

Format

./ossutil64 cp Downloads/<name of Broker VM QCOW2 image> oss://<directory name>/<file name for uploaded image>

Example

./ossutil64 cp Downloads/QCOW2_broker-vm-14.0.1.qcow2 oss://kvm-images-qcow2/Cortex XSIAM

-broker-vm-14.0.1.qcow2

macOS (using CLI)

Format

./ossutilmac64 cp Downloads/<name of Broker VM QCOW2 image oss://<directory name>/<file name for uploaded image>

Example

./ossutilmac64 cp Downloads/QCOW2_broker-vm-14.0.1.qcow2 oss://kvm-images-qcow2/Cortex XSIAM

-broker-vm-14.0.1.qcow2

Windows (using CMD)

Format for 64-bit

D:\ossutil>ossutil64.exe cp Downloads\<name of Broker VM QCOW2 image> oss://<directory name>/<file name for uploaded image>

Example for 64-bit

D:\ossutil>ossutil64.exe cp Downloads\QCOW2_broker-vm-14.0.1.qcow2 oss://kvm-images-qcow2/Cortex XSIAM

-broker-vm-14.0.1.qcow2

NOTE:

For Linux and Windows uploads, you can use Alibaba Cloud’s graphical management tool called ossbrowser.

Task 3. Create the image file in the Alibaba Cloud format

1. Open the Alibaba Cloud console.

2. Select Hamburger menu → Object Storage Service → <directory name>, where the <directory name> is the directory you configured when uploading the
image. For example, in the step above the <directory name> used in the examples provided is kvm-images-qcow2.

NOTE:

The Object Storage Service must be created in the same Region as the image of the virtual machine.

3. From the list of images displayed, find the row for the Broker VM QCOW2 image that you uploaded, and click View Details.

4. In the URL field of the View Details right-pane displayed, copy the internal link for the image in Alibaba cloud. The URL that you copy ends with .com and
you should not include any of the text displayed after this.

5. Select Hamburger menu → Elastic Compute Service → Instances & Images → Images.

6. In the Import Images area on the Images page, click Import Images.

7. In the Import Images window, set the following parameters:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 508/1003
5/8/24, 9:18 AM PDF Export

OSS Object Address—This field is a combination of the internal link that you copied for the Broker VM image and the file name for the uploaded
image, using this format <internal link>/<file name for uploaded image>. Paste the internal link for the Broker VM QCOW2 image in Alibaba Cloud
that you copied, and add the following text after the .com: /<file name for uploaded image>.

Image Name—Specify a name for the image.

Operating System/Platform—Leave Linux configured and change CentOS to Ubuntu.

System Architecture—Leave the default x86_64 selected.

Leave the rest of the fields as defined by the default or change them according to your system requirements.

8. Click OK.

A notification is displayed indicating that image was imported successfully. Once the Status for the imported image in the Images page changes to
Available, you will know the process is complete. This can take a few minutes.

Task 4. Create a new VM in Alibaba Cloud

1. Select Hamburger menu → Elastic Compute Service → Instances & Images → Instances.

2. Create Instance to open a wizard to define the VM machine.

3. Define the Basic Configurations screen by setting these parameters:

Read more...

Billing Method: Select the applicable billing method according to your system requirements.

Region: Ensure the Region selected is the same as the OSS Object Address.

Instance Type: Set these settings according to your system requirements.

Selected Instance Type Quantity: Set these settings according to your system requirements.

Image: Select Custom Image, and in the field select the image that you imported to Alibaba Cloud.

Storage (Optional): Set these settings according to your system requirements.

Snapshot (Optional): Set these settings according to your system requirements.

4. Click Next.

5. Define the Networking screen by setting these parameters:

Read more...

Network Type: Select the applicable Network Type and update the field according to your system configuration.

Public IP Address (Optional): Enable the instance to access the public network.

Security Group: You must select a Security Group for setting network access controls for the instance. Ensure that port 22 and port 443 are allowed
in the security group rules to access the Broker VM.

Elastic Network Interface (Optional): Add an ENI according to you system requirements.

6. Click Next.

7. Define the System Configurations screen by setting these parameters:

Read more...

Logon Credentials: Select Inherit Password From Image.

Instance Name: You can either leave the default instance name or specify a new name for the VM instance.

Description (Optional): Specify a description for the VM instance.

The rest of the fields are optional to configure.

8. Click Next.

9. (Optional) Define the Grouping screen according to your system requirements.

10. Click Next.

11. Review the Preview screen settings, select ECS Terms of Service and Product Terms of Service, and click Create Instance.

A dialog box is displayed indicating that the VM instance has been created. Click Console to bring you back to the Instances page, where you can see the
IP Address listed to connect to the VM instance.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 509/1003
5/8/24, 9:18 AM PDF Export

Task 5. Reboot the Broker VM

Reboot the Broker VM before logging in for the first time.

6.1.2.1.6 | Create a Broker VM Image for a Nutanix Hypervisor

Abstract

Learn how to create an image file of your Cortex XSIAM Broker virtual machine (VM) for a Nutanix Hypervisor.

After you download your Cortex XSIAM Broker virtual machine (VM) QCOW2 image, you need to upload it to a Nutanix hypervisor. The Nutanix AHV 2021
version is supported.

PREREQUISITE:

Download a Cortex XSIAM Broker VM QCOW2 image. For more information, see the virtual machine compatability requirements in Configure the Broker VM.

Perform the following procedures in the order listed below.

Task 1. Upload the downloaded QCOW2 image file to a Nutanix hypervisor

1. Select Compute & Storage → Images, and click Add Image.

2. In the Add Images page, ensure the Image Source is set to Image File, and click Add File.

3. Select the downloaded QCOW2 file and click Open. Additional fields related to the QCOW2 file are automatically displayed in the Add Image page, where
the Name and Type of file are automatically populated.

4. (Optional) Define the rest of the fields displayed for the QCOW2 file.

5. Click Next.

6. Select the location by defining the Placement Method and Select Clusters settings.

7. Click Save.

The image is now listed in the list of images.

NOTE:

Saving the image to Nutanix hypervisor can take time as it’s a large file.

Task 2. Create a new VM

1. Select Hamburger menu → Compute & Storage → VMs, and click Create VM.

2. In the Create VM screen, set the following Configuration fields:

Read more...

Name: Specify a name for the new VM.

Description (Optional): Specify a description to identify the VM.

Number of VMs: Select the number of VMs you want to create. The default is set to 1.

VM Properties

CPU: Select 4 CPUs.

Cores per CPU: Select the number of cores to create for each CPU. The default number is 1.

Memory: Select 8GB as the allotted memory for the VM.

3. Click Next.

4. Set the Resources fields:

Disks

Attach Disk and set the following field settings:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 510/1003
5/8/24, 9:18 AM PDF Export

Type: Leave the default Disk type.

Operation: Select Clone from Image.

Image: Select the QCOW2 image file that you uploaded.

Capacity: Specify the capacity of the image file as 512 GB.

Bus Type—Leave the default SCUI selected.

When you finish, click Save.

Networks

Attach to Subnet and set the following field settings.

Subnet: Select the subnet from the list.

Network Connection State: Leave the default Connected option selected.

When you finish, click Save.

Boot Configuration

Leave the default Legacy BIOS Mode selected.

5. Click Next.

6. Set the Management fields, where you can leave the default settings for the various fields.

7. Click Next.

8. Click Create VM.

The VM is now listed in the list of VMs.

NOTE:

Creating the VM can take up to 15 minutes. The Broker VM Web user interface is not accessible during this time.

Task 3. Review the VM details for connecting to the VM

Select Summary and you can use the IP Addresses and Host IP listed to connect to the VM.

6.1.2.1.7 | Create a Broker VM Image for a KVM using Ubuntu

Abstract

Learn how to create an image file of your Cortex XSIAM Broker virtual machine (VM) for a KVM using Ubuntu.

After you download your Cortex XSIAM Broker virtual machine (VM) QCOW2 image, you need to upload it to a kernel-based Virtual Machine (KVM). The
instructions below provide an example of doing this using Ubuntu 18.04 LTS.

PREREQUISITE:

Download a Cortex XSIAM Broker VM QCOW2 image. For more information, see the virtual machine compatability requirements in Configure the Broker VM.

1. Open your kernel-based Virtual Machine (KVM) on Ubuntu.

2. Click the New VM icon ( ) to open the Create a new virtual machine wizard.

3. In the Step 1 screen of the wizard, select Import existing disk image, and click Forward.

4. Define the Step 2 screen of the wizard:

Provide the existing storage path

1. Browse to the downloaded QCOW2 image file.

2. Click Browse Local, select the QCOW2 image file that you downloaded, and click Open.

OS type

Leave the Generic option selected.

Version

Leave the Generic option selected.

5. Click Forward.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 511/1003
5/8/24, 9:18 AM PDF Export

6. Define the Step 3 screen of the wizard:

Memory (RAM)

Specify 4096 (4GB) of memory

CPUs

Specify 2 CPUs.

7. Click Forward.

8. In the Step 4 screen of the wizard, set a Name for your new VM.

9. Click Finish.

You new VM is now listed and available to use.

6.1.2.1.8 | Set up Broker VM on VMware ESXi using vSphere Client

Abstract

Learn how to set up your Cortex XSIAM Broker VM on VMware ESXi.

To set up the Broker VM on VMware ESXi, you deploy the OVA image provided in Cortex XSIAM. VMware ESXi 6.5 or later is supported. The instructions below
provide an example of doing this using vSphere Client 7.0.3.01400.

PREREQUISITE:

Ensure you have a virtualization platform installed that is compatible with an OVA image, and have an authenticated user account.

Download a Cortex XSIAM Broker VM OVA image. For more information, see the virtual machine compatability requirements in Configure the Broker
VM).

Deploy the Broker VM OVA image on vShpere Client

1. From vSphere Client, right-click an inventory object for the virtual machine of your broker, and select Deploy OVF Template.

2. In the Select an OVF template page of the wizard, select Local file, click UPLOAD FILES to select the OVA image file that you downloaded, and click
NEXT.

3. In the Select a name and folder page, enter a unique name for the virtual machine, select a deployment location, and click NEXT.

4. In the Select a compute resource page, select a resource where to run the deployed VM template, and click NEXT.

5. In the Review details page, verify the OVA template details, and click NEXT.

6. In the Select storage page, define where and how to store the files for the deployed OVA template, and click NEXT. For more information on the options
available, see the VMware vSphere documentation.

7. In the Select networks page, select a source network and map it to a destination network, and click NEXT.

The Source Network column lists all networks that are defined in the OVA template.

8. In the Ready to complete page, review the details and click FINISH.

A new task for creating the virtual machine is displayed in the Recent Tasks pane. When the Status of the task reaches 100%, the task is complete, and
the new virtual machine is created on the selected resource.

9. Navigate to the resource where the new virual machine is created, right-click the resource, and select Power → Power On.

6.1.2.2 | Activate the Local Agent Settings

Abstract

Learn more about activating your Local Agent Settings applet on a broker VM.

The Local Agent Settings applet on the Palo Alto Networks Broker VM enables you to:

Deploy the Broker VM proxy

To deploy Cortex XSIAM in restricted networks where endpoints do not have a direct connection to the internet, setup the Broker VM to act as a proxy that
routes all the traffic between the Cortex XSIAM management server and XDR agents/XDR Collectors via a centralized and controlled access point. This enables
your agents and XDR Collectors to receive security policy updates, upgrades, and send logs and files to Cortex XSIAM without a direct internet connection. The
Broker VM acts like a transparent proxy and doesn’t decrypt the secure connection between the server and the XDR agent/XDR Collectors, and hides the XDR

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 512/1003
5/8/24, 9:18 AM PDF Export

agent’s/XDR Collector's original IP addresses. If your network topology includes SSL decryption in an upstream proxy/firewall, the Broker VM does not
participate in the trust relationship as it is not initiating the connection to the server to be fully transparent.
Enable broker caching

To reduce your external network bandwidth loads, you can cache XDR agent installations, upgrades, and content updates on your Cortex XSIAM Broker VM.
The Broker VM retrieves from Cortex XSIAM the latest installers and content files every 15 minutes and stores them for a 30-days retention period since an
agent last asked for them. If the files were not available on the Broker VM at the time of the ask, the agent proceeds to download the files directly from the
Cortex XSIAM server. If asked by an agent, the Broker VM can also cache a specific installer that is not on the list of latest installers.

Requirements

Before you activate the Local Agent Settings applet, verify the following prerequisites and limitations listed by the main features.

General

Each local setting on the Broker VM can support up to 50,000 agents.

NOTE:

This is assuming a standard hardware setup with 2vCPU 8GB memory.

Agent Proxy

Supported with Traps agent version 5.0.9 and Traps agent version 6.1.2 and later releases.

Broker VM supports forwarding the XDR Collectors request URLs on all Broker VM versions.

Supported with all XDR Collector versions.

NOTE:

Broker VMs can act as as a proxy for routing XDR Collector traffic to the Cortex XSIAM tenant. The Broker VM does not cache XDR Collector installers.

Agent Installer and Content Caching

Supported with XDR agent version 7.4 and later releases and Broker VM 12.0 and later.

Requires a Broker VM with an 8-core processor to support caching for 10K endpoints.

For the agent installer and content caching to work properly, you must configure different settings where the instructions differ depending on whether you
are configuring a standalone Broker VM or High Availability (HA) cluster:

Standalone broker

FQDN: A FQDN must be configured for the standalone broker as configured in your local DNS server. This is to ensure that XDR agents know who
to access to receive agent installer and content caching data.

SSL certificates: Ensure you upload strong cipher SHA256-based SSL certificates when you setup the Broker VM.

Download source: Requires adding the Broker VM as a download source in your Agent Settings Profile. For more information, see Add a New Agent
Settings Profile.

HA cluster

FQDN: A FQDN must be configured in the cluster settings as configured in your local DNS server, which points to a Load Balancer. This ensures
that the XDR agents turn to the load balancer to route the requests for the agent installer and content caching data to the correct broker. For more
information on configuring the Load Balancer FQDN in a HA cluster, see Configure a High Availability Cluster.

SSL certificates: In each broker in the cluster, ensure you upload strong cipher SHA256-based SSL certificates when you setup the Broker VM.

Download source: Requires adding the cluster as a download source in your Agent Settings Profile. For more information, see Add a New Agent
Settings Profile.

Agent communication with Broker VM

Agents communicate with the Broker VM using Hypertext Transfer Protocol Secure (https) over port 443. You must ensure this port is open so that the Broker
VM is accessible to all agents that are configured to use its cache.

Broker communication with cloud manager

The broker needs to communicate with the same URLs that the agents communicate with to avoid receiving any inaccessible URLs errors. For a complete list of
the URLs that you need to allow access, see Resources Required to Enable Access.

How to activate the Local Agent Settings applet

After you configure and register your Palo Alto Networks Broker VM, proceed to set up your Local Agent Settings applet.

1. Select Settings → Configurations → Data Broker → Broker VMs.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 513/1003
5/8/24, 9:18 AM PDF Export

2. In either the Brokers tab or the Clusters tab, locate your Broker VM.

3. (Optional) To set up the Agent Proxy:

a. Right-click the Broker VM, select Configure.

Ensure your proxy server is configured. If not, proceed to add it as described in Configure the Broker VM.

b. You can either right-click the Broker VM and select Add App → Local Agent Settings, or in the APPS column, left-click Add → Local Agent Settings.

c. In the Activate Local Agent configuration, enable Agent Proxy by setting the Proxy to Enabled, and specify the Port. You can also configure the
Listening Interface, where the default is set to All.

NOTE:

When you install your XDR agents, you must configure the IP address of the Broker VM and a port number during the installation. You can use
the default 8888 port or set a custom port. You are not permitted to configure port numbers between 0-1024 and 63000-65000, or port numbers
4369, 5671, 5672, 5986, 6379, 8000, 9100, 15672, 25672. Additionally, you are not permitted to reuse port numbers you already assigned to the
Syslog Collector applet.

4. (Optional) To setup up Agent Installer and Content Caching:

a. Ensure you uploaded your SHA256-based certificates.

If not, upload them as described in Configure the Broker VM and Save.

b. Specify the Broker VM FQDN.

Right-click the Broker VM, select Configure. Under Device Name, enter your Broker VM FQDN. This FQDN record must be configured in your local
DNS server.

IMPORTANT:

A FQDN must be configured for WEC and Agent Installer and Content Caching to function properly.

c. Activate the Local Agent Settings applet on the Broker VM.

You can either right-click the Broker VM and select Add App → Local Agent Settings, or in the APPS column, select Add → Local Agent Settings.

d. Activate installer and content caching.

In the Activate Local Agent configuration, enable Agent Installer and Content Caching by setting Caching to Enabled.

IMPORTANT:

You can only enable Agent Installer and Content Caching, when in the Broker VM Configuration, you've uploaded your signed SSL Server
Certificate and key and set the FQDN. For more information, see the Agent Installer and Content Caching requirements explained above.

e. To enable agents to start using Broker VM caching, you must add the Broker VM as a download source in your Agent Settings profile and select
which Broker VMs to use, as described in Add a New Agent Settings Profile. Then, ensure the profile is associated with a policy for your target
agents.

5. After a successful activation, the APPS field displays Local Agent Settings with a green dot indicating a successful connection. Left-click the Local Agent
Settings connection to view the applet status and resource usage.

To help you easily troubleshoot connectivity issues for a Local Agent Settings applet on the Palo Alto Networks Broker VM, Cortex XSIAM displays a list of
Denied URLs. These URLs are displayed when you left-click the Local Agent Settings applet to view the Connectivity Status. As a result, in a situation
where the Local Agent Settings applet is reported as activated with a failed connection, you can easily determine the URLs that need to be allowed in your
network environment.

6. Manage the local agent settings. After the local agent settings have been activated, left-click the Local Agent Settings connection in the APPS column to
display the settings, and select:

Configure to change your settings.

Deactivate to disable the local agent settings altogether.

6.1.2.3 | Activate the Syslog Collector

Abstract

Learn how to set up and activate the Syslog Collector applet on a Broker VM within your network.

To receive Syslog data from an external source, you must first set up the Syslog Collector applet on a Broker VM within your network. The Syslog Collector
supports a log ingestion rate of 90,000 logs per second (lps) with the recommended Broker VM setup.

To increase the log ingestion rate, you can add additional CPUs to the Broker VM. The Syslog Collector listens for logs on specific ports and from any or specific
IP addresses.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 514/1003
5/8/24, 9:18 AM PDF Export

PREREQUISITE:

Configure the Broker VM

Perform the following procedures in the order listed below.

Task 1. Add a Syslog Collector

1. Select Settings → Configurations → Data Broker → Broker VMs.

2. In either the Brokers tab or the Clusters tab, locate your Broker VM.

3. You can either right-click the Broker VM and select Add App → Syslog Collector, or in the APPS column, left-click Add → Syslog Collector.

Task 2. Configure the Syslog Collector

Cortex XSIAM supports multiple sources over a single port on a single Syslog Collector. The following options are available:

Edit the Optional Settings of the default PORT/PROTOCOL: 514/UDP. See Task 3.

NOTE:

Once configured, you cannot change the Port/PROTOCOL. If you don’t want to use a data source, ensure to remove the data source from the list as
explained in Task 5.

Add a new Syslog Collector data source. See Task 4.

Task 3. Edit the default 514/UDP Syslog Collector data source

1. Right-click the 514/UDP PORT/PROTOCOL, and select Edit.

2. Configure these Optional Settings:

Format

Select the Syslog format you want to send to the UDP 514 protocol and port on the Syslog Collector: Auto-Detect (default), CEF, LEEF, CISCO,
CORELIGHT, or RAW.

NOTE:

The Vendor and Product defaults to Auto-Detect when the Log Format is set to CEF or LEEF.

For a Log Format set to CEF or LEEF, Cortex XSIAM reads events row by row to look for the Vendor and Product configured in the logs. When
the values are populated in the event log row, Cortex XSIAM uses these values even if you specified a value in the Vendor and Product fields in
the Syslog Collector settings. Yet, when the values are blank in the event log row, Cortex XSIAM uses the Vendor and Product that you specified
in the Syslog Collector settings. If you did not specify a Vendor or Product in the Syslog Collector settings and the values are blank in the event
log row, the values for both fields are set to unknown.

Vendor and Product

Specify a particular vendor and product for the Syslog format defined or leave the default Auto-Detect setting.

Source Network

Specify the IP address or Classless Inter-Domain Routing (CIDR). If you leave this blank, Cortex XSIAM will allow receipt of logs from any source IP
address or CIDR that transmits over the specified protocol and port. When you specify overlapping addresses in the Source Network field in multiple rows,
such as 10.0.0.10 in the first row and 10.0.0.0/24 in the second row, the order of the addresses matter. In this example, the IP address 10.0.0.10 is only
captured from the first row definition. For more information on prioritizing the order of the syslog formats, see Task 5.

After each configuration, select to save the changes and then Done to update the Syslog Collector with your settings.

Task 4. Add a new Syslog Collector data source

1. Select Add New.

2. Configure these mandatory General settings:

Protocol

Choose a protocol over which the Syslog will be sent: UDP, TCP, or Secure TCP.

Secure TCP

When configuring the Protocol as Secure TCP, these additional General Settings are available:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 515/1003
5/8/24, 9:18 AM PDF Export

Server Certificate: Browse to your server certificate to configure server authentication.

Private Key: Browse to your private key for the server certificate.

Optional CA Certificate: (Optional) Browse to your CA certificate for mutual authentication.

The log forwarder (for example, a firewall) authenticates the Broker VM by default. The Broker VM does not authenticate the log forwarder by
default, but you can use this option to set set up such authentication. If you use this option, ensure that you have a client certificate on the log
forwarding side that matches the CA certificate on the Broker VM side.

Minimal TLS Version: Select either 1.0 or 1.2 (default) as the minimum TLS version allowed.

NOTE:

Cortex XSIAM will notify notify you when your certificates are about to expire.
Port

Choose a port on which the Syslog Collector will listen for logs.

NOTE:

Because some port numbers are reserved by Cortex XSIAM , you must choose a port number that is not:

In the range of 0-1024 (except for 514)

In the range of 63000-65000

Values of 4369, 5671, 5672, 5986, 6379, 8000, 8888, 9100, 15672, or 28672

3. Configure these Optional Settings:

Format

Select the Syslog format you want to send to the UDP/514 protocol and port on the Syslog Collector: Auto-Detect (default), CEF, LEEF, CISCO,
CORELIGHT, or RAW.

Vendor and Product

Enter a particular vendor and product for the Syslog format defined or leave the default Auto-Detect setting.

Source Network

Specify the IP address or Classless Inter-Domain Routing (CIDR). If you leave this blank, Cortex XSIAM will allow receipt of logs from any source IP
address or CIDR that transmits over the specified protocol and port. When you specify overlapping addresses in the Source Network field in multiple rows,
such as 10.0.0.10 in the first row and 10.0.0.0/24 in the second row, the order of the addresses matter. In this example, the IP address 10.0.0.10 is only
captured from the first row definition. For more information on prioritizing the order of the syslog formats, see Task 5.

After each configuration, select to save the changes and then Done to update the Syslog Collector with your settings.

Task 5. Make additional changes to the Syslog Collector data sources configured

To remove a Syslog Collector data source, right-click the row after the Port/Protocol entry, and select Remove.

To prioritize the order of the Syslog formats listed for the protocols and ports configured, drag and drop the rows to the order you require.

Task 6. Save the Syslog Collector settings

Click Save. After a successful activation, the APPS field displays Syslog with a green dot indicating a successful connection.

Task 7. (optional) View metrics about the Syslog Collector

To view metrics about the Syslog Collector, left-click the Syslog connection in the APPS field for your Broker VM. Cortex XSIAM displays the following
information:

Connectivity Status

Whether the applet is connected to Cortex XSIAM.

Logs Received and Logs Sent

Number of logs received and sent by the applet per second over the last 24 hours. If the number of incoming logs received is larger than the number of logs
sent, it could indicate a connectivity issue.

Resources

Displays the amount of CPU, Memory, and Disk space the applet is using.

Step 8. Manage the Syslog Collector

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 516/1003
5/8/24, 9:18 AM PDF Export

After the Syslog Collector has been activated, you can make additional changes to your configuration if needed. To modify a configuration, left-click the Syslog
connection in the APPS column to display the Syslog Collector settings, and select:

Configure to redefine the Syslog configurations.

Deactivate to disable the Syslog Collector.

6.1.2.4 | Activate the Apache Kafka Collector

Abstract

Learn more about activating the broker VM with an Apache Kafka Collector applet.

Apache Kafka is an open-source distributed event streaming platform for high-performance data pipelines, streaming analytics and data integration. Kafka
records are organized into Topics. The partitions for each Topic are spread across the bootstrap servers in the Kafka cluster. The bootstrap servers are
responsible for transferring data from Producers to Consumer Groups, which enable the Kafka server to save offsets of each partition in the Topic consumed by
each group.

The Broker VM provides a Kafka Collector applet that enables you to monitor and collect events from Topics on self-managed on-prem Kafka clusters directly to
your log repository for query and visualization purposes. The applet supports Kafka setups with no authentication, with SSL authentication, and SASL SSL
authentication.

After you activate the Kafka Collector applet, you can collect events as datasets (<Vendor>_<Product>_raw) by defining the following.

Kafka connection details including the Bootstrap Server List and Authentication Method.

Topics Collection configuration for the Kafka topics that you want to collect.

PREREQUISITE:

Before activating the Kafka Collector applet, review and perform the following:

Apache Kafka version 2.5.1 and above.

Kafka cluster set up on premises, from which the data will be ingested.

Privileges to manage Broker Service configuration, such as Instance Administrator privileges.

Create a user in the Kafka cluster with the necessary permissions and the following authentication details:

Broker Certificate and Private Key for an SSL connection.

Username and Password for an SASL SSL connection.

Configure the Broker VM

How to activate the Kafka Collector

1. Select Settings → Configurations → Data Broker → Broker VMs.

2. In either the Brokers tab or the Clusters tab, locate your Broker VM.

3. You can either right-click the Broker VM and select Add App → Kafka Collector, or in the APPS column, left-click Add → Kafka Collector.

4. Configure the Kafka Connection.

a. Specify the Bootstrap Server List, which is the <hostname/ip>:<port> of the bootstrap server (or servers). You can specify multiple servers,
separated with a comma. For example, hostname1:9092,1.1.1.1:9092.

b. Select one of the Authentication Methods:

No Authentication

Default connection method for a new Kafka setup, which doesn’t require authentication. With a standard Kafka setup, any user or application can
write messages to any topic, as well as read data from any topic.

SSL Authentication

Authenticate your connection to Kafka using an SSL certificate. Use this authentication method when the connection to the Kafka server is a secure
TCP, and upload the following:

Broker Certificate: Signed certificate used for the applet to authenticate to the Kafka server.

Private Key: Private key for the applet used for decrypting the SSL messages coming from the Kafka server.

(Optional) CA Certificate: CA certificate that was used to sign the server and private certificates. This CA certificate is also used to
authenticate the Kafka server identity.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 517/1003
5/8/24, 9:18 AM PDF Export

SASL SSL (SCRAM-SHA-256)

Authenticate your connection to the Kafka server with your Username, Password, and optionally, your CA Certificate.

c. Test Connection to verify that you can connect to the Kafka server. An error message is displayed for each server connection test that fails.

5. Configure the Topics Collection parameters.

Topic Subscription Method

Select the Topic Subscription Method for subscribing to Kafka topics. Use List Topics to specify a list of topics. Use Regex Pattern Matching to specify a
regular expression to search available topics.

Topic(s)

Specify Topic(s) from the Kafka server. For the List Topics subscription method, use a comma separated list of topics to subscribe to. For the Regex
Pattern Matching subscription method, use a regular expression to match the Topic(s) to subscribe to.

(optional) Consumer Group

Specify a Consumer Group, a unique string or label that identifies the consumer group this log source belongs to. Each record that is published to a Kafka
topic is delivered to one consumer instance within each subscribing consumer group. Kafka uses these labels to load balance the records over all
consumer instances in a group. When specified, the Kafka collector uses the given consumer group. When not specified, Cortex XSIAM assigns the Kafka
applet collector to a new automatically generated consumer group which is automatically generated for this log source with the name PAN-<Broker VM
device name>-<topic name>.

Log Format

Select the Log Format from the list as either RAW (default), JSON, CEF, LEEF, CISCO, or CORELIGHT. This setting defines the parser used to parse all
the processed event types defined in the Topics field, regardless of the file names and extension. For example, if the Topics field is set to * and the Log
Format is JSON, all files (even those named file.log) in the cluster are processed by the collector as JSON, and any entry that does not comply with
the JSON format are dropped.

Vendor and Product

Specify the Vendor and Product which will be associated with each entry in the dataset. The vendor and product are used to define the name of your
Cortex Query Language (XQL) dataset (<Vendor>_<Product>_raw).

NOTE:

For CEF and LEEF logs, Cortex XSIAM takes the vendor and product names from the log itself, regardless of what you configure on this page.

(optional) Add Query

Add Query to create another Topic Collection. Each topic can be added for a server only once.

(optional) Other available options for Topic Collection

As needed, you can manage your Topic Collection settings. Here are the actions available to you.

Edit the Topics Collection details.

Disable/Enable a Topics Collection by hovering over the top area of the Topics Collection section, on the opposite side of the Topics Collection
name, and selecting the applicable button.

Rename a Topics Collection by hovering over the top area of the Topics Collection section, on the opposite side of the Topics Collection name, and
selecting the pen icon.

Delete a Topics Collection by hovering over the top area of the Topics Collection section, on the opposite side of the Topics Collection name, and
selecting the delete icon.

6. (Optional)Add Connection to create another Kafka Connection for collecting data.

7. (Optional) Other available options for Connections.

As needed, you can return to your Kafka Collector settings to manage your connections.

Here are the actions available to you.

Edit the Connection details.

Rename a connection by hovering over the default Collection name, and selecting the edit icon to edit the text.

Delete a connection by hovering over the top area of the connection section, on the opposite side of the connection name, and selecting the delete
icon. You can only delete a connection when you have more than one connection configured. Otherwise, this icon is not displayed.

8. Activate the Kafka Collector applet. Activate is enabled when all the mandatory fields are filled in.

After a successful activation, the APPS field displays Kafka with a green dot indicating a successful connection.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 518/1003
5/8/24, 9:18 AM PDF Export

9. (optional) To view metrics about the Kafka Collector, in the Broker VMs page, left-click the Kafka connection displayed in the APPS field for your Broker
VM.

Cortex XSIAM displays Resources, including the amount of CPU, Memory, and Disk space the applet is using.

10. Manage the Kafka Collector.

After you activate the Kafka Collector, you can make additional changes as needed. To modify a configuration, left-click the Kafka connection in the APPS
column to display the Kafka Collector settings, and select the following.

Configure to redefine the Kafka Collector configurations.

Deactivate to disable the Kafka Collector.

Ensure that you Save your changes, which is enabled when all mandatory fields are filled in.

You can also Ingest Apache Kafka Events as Datasets.

6.1.2.5 | Activate the CSV Collector

Abstract

Learn more about activating the broker VM with a CSV Collector applet.

The Broker VM provides a CSV Collector applet that enables you to monitor and collect CSV (comma-separated values) log files from a shared Windows
directory directly to your log repository for query and visualization purposes. After you activate the CSV Collector applet on a Broker VM in your network, you
can ingest CSV files as datasets by defining the list of folders mounted to the Broker VM and setting the list of CSV files to monitor and upload to Cortex XSIAM
using a username and password.

PREREQUISITE:

Before activating the CSV Collector applet, review and perform the following:

Configure the Broker VM.

Ensure that you share the applicable CSV files.

Know the complete file path for the Windows directory.

How to activate the CSV Collector

1. Select Settings → Configurations → Data Broker → Broker VMs.

2. In either the Brokers tab or the Clusters tab, locate your Broker VM.

3. You can either right-click the Broker VM and select Add App → CSV Collector, or in the APPS column, left-click Add → CSV Collector.

4. Configure your CSV Collector by defining the list of folders mounted to the Broker VM and specifying the list of CSV files to monitor and upload to Cortex
XSIAM. You must also specify a username and password.

Mounted Folders

Define the folders mounted onto the Broker VM:

Folder Path

Specify the complete file path to the Windows directory containing the shared CSV files using the format: //host/<folder_path>. For example,
//testenv1pc10/CSVFiles.

Username

Specify the username for accessing the Windows directory.

Password

Specify the password for accessing the Windows directory.

After you configure the mounted folder details, Add ( ) details to the applet.

Mounted CSV Files

Folder Path + Name

Select the monitored Windows directory and specify the name of the CSV file. Use a wildcard file search using these characters in the name of the
directory, CSV file name, and Path Exclusion.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 519/1003
5/8/24, 9:18 AM PDF Export

?: Matches a single char, such as 202?-report.csv.

*: Matches either multiple characters, such as 2021-report*.csv, or all CSV files with *.csv.

**: Searches all directories and subdirectories. For example, if you want to include all the CSV files in the directory and any subdirectories, use the
syntax //host/<folder_path>/**/*.csv.

NOTE:

When you implement a wildcard file search, ensure that the CSV files share the same columns and header rows as all other logs that are collected from
the CSV files to create a single dataset.
(Optional) Path Exclusion

Specify the complete file path for any files from the Windows directory that you do not want included. The same wildcard file search characters are
allowed in this field as explained above for the FOLDER PATH +NAME field. For example, if you want to exclude any CSV file prefixed with 'exclude_' in
the directory and subdirectories of //host/<folder_path>, use the syntax //host/<folder_path>/**/exclude_*.csv.

(Optional) Tags

To easily query the CSV data in the database, you can add a tag to the collected CSV data. This tag is appended to the data using the format
<data>_<tag>.

Target Dataset

Either select the target dataset for the CSV data or create a new dataset by specifying the name for the new dataset.

5. Activate the CSV Collector applet.

After a successful activation, the APPS field displays CSV with a green dot indicating a successful connection.

NOTE:

The CSV Collector checks for new CSV files every 10 minutes.

6. (Optional) To view metrics about the CSV Collector, left-click the CSV connection in the APPS field for your Broker VM.

Cortex XSIAM displays Resources, including the amount of CPU, Memory, and Disk space the applet is using.

7. Manage the CSV Collector.

After you activate the CSV Collector, you can make additional changes as needed. To modify a configuration, left-click the CSV connection in the APPS
column to display the CSV settings, and select:

Configure to redefine the CSV Collector configurations.

Deactivate to disable the CSV Collector.

You can also Ingest CSV Files as Datasets.

6.1.2.6 | Activate the Database Collector

Abstract

Learn more about activating a broker VM with a Database Collector applet.

The Broker VM provides a Database Collector applet that enables you to collect data from a client relational database directly to your log repository for query
and visualization purposes. After you activate the Database Collector applet on a Broker VM in your network, you can collect records as datasets
(<Vendor>_<Product>_raw) by defining the following.

Database connection details, where the connection type can be MySQL, PostgreSQL, MSSQL, and Oracle. Cortex XSIAM uses Open Database
Connectivity (ODBC) to access the databases.

Settings related to the query details for collecting the data from the database to monitor and upload to Cortex XSIAM .

PREREQUISITE:

Before activating the Database Collector applet, review and perform the following:

Configure the Broker VM

How to activate the Database Collector

1. Select Settings → Configurations → Data Broker → Broker VMs.

2. In either the Brokers tab or the Clusters tab, locate your Broker VM.

3. You can either right-click the Broker VM and select Add App → DB Collector, or in the APPS column, left-click Add → DB Collector.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 520/1003
5/8/24, 9:18 AM PDF Export

4. Configure your Database Collector settings.

Database Connection
Connection

Select the type of database connection as MySQL, PostegreSQL, MSSQL, or Oracle.

Host

Specify the hostname or IP address of the database.

Port

Specify the port number of the database.

Database

Specify the database name for the type of database configured. This field is relevant when configuring a Connection Type for MySQL, PostegreSQL, and
MSSQL.

When configuring an Oracle connection, this field is called Service Name, so you can specify the name of the service.

Enable SSL

Select whether to Enable SSL (default) to encrypt the data while in transit between the database and the Broker VM.

Username

Specify the username to access the database.

Password

Specify the password to access the database.

Test Connection

Select to validate the database connection.

Database Query
Rising Column

Specify a column for the Database Collector applet to keep track of new rows from one input execution to the next. This column must be included in the
query results.

Retrieval Value

Specify a Retrieval Value for the Database Collector applet to determine which rows are new from one input execution to the next. Cortex XSIAM supports
configuring this value as an integer or a string that contains a timestamp. The following string timestamp formats are supported: ISO 8601 format, RFC
2822 format, date strings with month names spelled out, such as “January 1, 2022”, date strings with abbreviated month names, such as “Jan 1, 2022",
and date strings with two-digit years- MM/DD/YY.

The first time the input is run, the Database Collector applet only selects those rows that contain a value higher than the value you specified in this field.
Each time the input finishes running, the Database Collector applet updates the input's Retrieval Value with the value in the last row of the Rising Column.

(Optional) Unique IDs

Specify the column name(s) to match against when multiple records have the same value in the Rising Column. This column must be included in the
query results. This is a comma separated field that supports multiple values. In addition, when specifying a Unique IDs, the query should use the greater
than equal to sign (>=) in relation to the Retrieval Value. If the Unique IDs is left empty, the user should use the greater than sign (>).

Collect Every

Specify the execution frequency of collection by designating a number and then selecting the unit as either Seconds, Minutes, Hours, or Days.

Vendor and Product

Specify the Vendor and Product for the type of data being collected. The vendor and product are used to define the name of your Cortex Query Language
(XQL) dataset (<Vendor>_<Product>_raw).

SQL Query

Specify the SQL Query to run and collect data from the database by replacing the example query provided in the editor box. The question mark (?) in the
query is a checkpoint placeholder for the Retrieval Value. Every time the input is run, the Database Collector applet replaces the question mark with the
latest checkpoint value (i.e. start value) for the Retrieval Value.

Generate Preview

Select Generate Preview to display up to 10 rows from the SQL Query and Preview the results. The Preview works based on the Database Collector
settings, which means that if after running the query no results are returned, then the Preview returns no records.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 521/1003
5/8/24, 9:18 AM PDF Export

(optional) Add Query

To define another Query for data collection on the configured database connection, select Add Query. Another Query section is displayed for you to
configure.

5. (optional) Add Connection to define another database connection to collect data from another client relational database.

6. (optional) Other available options.

As needed, you can return to your Database Collector settings to manage your connections. Here are the actions available to you.

Edit the connection name by hovering over the default Collection name, and selecting the edit icon to edit the text.

Edit the query name by hovering over the default Query name, and selecting the edit icon to edit the text.

Disable/Enable a query by hovering over the top area of the query section, on the opposite side of the query name, and selecting the applicable
button.

Delete a connection by hovering over the top area of the connection section, on the opposite side of the connection name, and selecting the delete
icon. You can only delete a connection when you have more than one connection configured. Otherwise, this icon is not displayed.

Delete a query by hovering over the top area of the query section, on the opposite side of the query name, and selecting the delete icon. You can
only delete a query when you have more than one query configured. Otherwise, this icon is not displayed.

7. Activate the Database Collector applet.

After a successful activation, the APPS field displays DB with a green dot indicating a successful connection.

8. (Optional) To view metrics about the Database Collector, left-click the DB connection in the APPS field for your Broker VM.

Cortex XSIAM displays Resources, including the amount of CPU, Memory, and Disk space the applet is using.

9. Manage the Database Collector.

After you activate the Database Collector, you can make additional changes as needed. To modify a configuration, left-click the DB connection in the
APPS column to display the Database Collector settings, and select:

Configure to redefine the Database Collector configurations.

Deactivate to disable the Database Collector.

You can also Ingest Database Data as Datasets.

6.1.2.7 | Activate the Files and Folders Collector

Abstract

Learn more about activating a broker VM with a Files and Folders Collector applet.

The Broker VM provides a Files and Folders Collector applet that enables you to monitor and collect logs from files and folders in a network share for a Windows
or Linux directory, directly to your log repository for query and visualization purposes. The Files and Folders collector applet only starts to collect files that are
more than 256 bytes and is only supported with a Network File System version 4 (NFSv4). After you activate the Files and Folders Collector applet, you can
collect files as datasets (<Vendor>_<Product>_raw) by defining the following.

Details of the folder path on the network share containing the files that you want to monitor and upload to Cortex XSIAM.

Settings related to the list of files to monitor and upload to Cortex XSIAM, where the log format is either Raw (default), JSON, CSV, TSV, PSV, CEF, LEEF,
Corelight, or Cisco.

PREREQUISITE:

Before activating the Files and Folders Collector applet, review and perform the following:

Configure the Broker VM.

Know the complete path to the files and folders that you want Cortex XSIAM to monitor.

Ensure that the user permissions for the network share include the ability to rename and delete files in the folder that you want to configure collection.

How to activate the Files and Folders Collector

1. Select Settings → Configurations → Data Broker → Broker VMs.

2. In either the Brokers tab or the Clusters tab, locate your Broker VM.

3. You can either right-click the Broker VM and select Add App → Files and Folder Collector, or in the APPS column, left-click Add → Files and Folder
Collector.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 522/1003
5/8/24, 9:18 AM PDF Export

4. Configure the Files and Folders Collector settings.

Shared Folder Connection

Folder Path

Specify the path to the files and folders that you want Cortex XSIAM to monitor continuously to collect the files. The following formats are available based
on the type of machine you are using.

Windows: \\<hostname>\<shared_folder> or smb://<hostname>/<shared_folder>

Linux: /<srv>/<shared_folder> or nfs://<srv>/<shared_folder>

NOTE:

When using the Linux file share, including the Linux share with nfs, a Username and Password is not required, so these fields are grayed out in
the screen.

Recursive

Select this checkbox to configure the Files and Folders Collector applet to recursively examine any subfolders for new files as long as the folders are
readable. This is not configured by default.

Username

Specify the username to access the shared resource using a User Principal Name (UPN) format.

Password

Specify the password to access the shared resource.

Test Connection

Select to validate the connection and permissions.

File and Folder Settings

Mode

Select the mode to use for collecting data. The settings displayed change depending on your selection.

Tail: Continuously monitors the files for new data (default). The collector adds the new data from the files to the dataset.

Batch: Reads the files automatically at user determined intervals, updates the lookup datasets, and then renames or deletes the uploaded source
files. Renaming or deleting the read source files ensures that the collector always reads the most up-to-date file. Depending on the Storage Method,
the collector can Append the new data from the files to the dataset or completely Replace the data in the dataset.

NOTE:

In Batch mode, the Files and Folders Collector supports collecting logs from a network share for a maximum file size of 500 MB.

Collect Every

This option is only displayed in Batch Mode. Specify the execution frequency of collection by designating a number and then selecting the unit as either
Minutes, Hours, or Days.

After Files Uploaded

This option is only displayed in Batch Mode. Select what to do with the files after they are uploaded to the Cortex XSIAM server. You can Rename files
with a suffix (default) or you can Delete files. When renaming, the suffix is added to the end of the original file name using the format <file name>.
<suffix>, which becomes the new name of the file.

Include

Specify the files and folders that must match to be monitored by Cortex XSIAM. Multiple values are allowed with commas separating the values and are
case-sensitive.

Allowed wildcard:

'?' matches a single alphabet character in a specific position.

'*' matches any character or set of characters, including no character.

Example: log*.jsonlog*.json includes any JSON file starting with 'log'.

(optional) Exclude

Specify the files and folders that must match to not be monitored by Cortex XSIAM . Multiple values are allowed with commas separating the values.

Allowed wildcard:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 523/1003
5/8/24, 9:18 AM PDF Export

'?' matches a single alphabet character in a specific position.

'*' matches any character or set of characters, including no character.

Example: *.backup excludes any file ending with '.backup'.

Log Format

Select the Log Format from the list as either Raw (default), JSON, CSV, TSV, PSV, CEF, LEEF, Corelight, or Cisco. This setting defines the parser used to
parse all the processed files as defined in the Include and Exclude fields, regardless of the file names and extension. For example, if the Include field is
set * and the Log Format is JSON, all files (even those named file.log) in the specified folder are processed by the Files and Folders Collector as
JSON, and any entry that does not comply with the JSON format are dropped.

NOTE:

When uploading JSON files, Cortex XSIAM only parses the first level of nesting and only supports single line JSON format, such that every new line
means a separate entry.

(optional) # of Lines to Skip

Specify the number of lines to skip at the beginning of the file. This is set to 0 by default.

NOTE:

Use this option only in cases where your files contain some sort of "header" lines, such as a general description, an introduction, a disclaimer, or similar,
and you want to skip ingesting them.
Data Source Mapping
Storage Method

This option is only displayed in Batch Mode. Specify whether to Append the read data to the dataset, or to Replace all the data in the dataset with the
newly read data.

Append: This mode is useful for log files where you want to keep all the log info from before.

Replace: This mode is useful for adding inventory data from CSV and JSON files which include properties, for example, a list of machines, a list of
users, or a mapping of endpoints to users to create a lookup dataset. In each data collection cycle, the new data completely replaces the existing
data in the dataset. You can use the records from the lookup datasets for correlation and enrichment through parsing rules, correlation rules, and
queries.

NOTE:

When the storing method is Replace, the maximum size for the total data to be imported into a lookup dataset is 30 MB each time the data
is fetched.

The inventory data ingested using the Files and Folders collector is counted towards license utilization.

When you use a JOINT function with a lookup table in a query or correlation rule, make sure you configure the conflict strategy to point to
the raw dataset. This ensures that the system fields are taken from the raw dataset and not from the lookup table.

Target Dataset

This option is only displayed in Batch Mode when the storing method is Replace. Select the name of an existing Lookup dataset or create a new Lookup
dataset by specifying the name.

When you create a new target dataset name, specify a name that will be more meaningful for your users when they query the dataset. For example, if the
original file name is accssusr.csv, you can save the dataset as access_per_users.

Dataset names can contain special characters from different languages, numbers (0-9) and underscores (_). You can create dataset names using
uppercase characters, but in queries, dataset names are always treated as if they are lowercase.

NOTE:

You can't specify a file name that's the same as a system file name.

The name of a dataset created from a tsv file must always include the extension. If the original file name is mrkdptusrsnov23.tsv, you can name
save the dataset with the name marketing_dept_users_Nov_2023.tsv.

Vendor and Product

Specify the Vendor and Product for the type of data being collected. The vendor and product are used to define the name of your Cortex Query Language
(XQL) dataset (<Vendor>_<Product>_raw).

NOTE:

The Vendor and Product defaults to Auto-Detect when the Log Format is set to CEF or LEEF.

Generate Preview

Select Generate Preview to display up to 10 rows from the first file and Preview the results. The Preview works based on the Files and Folders Collector
settings, which means that if all the files that were configured to be monitored were already processed, then the Preview returns no records.

5. (optional) Add Connection to define another Files and Folders connection for collecting logs from files and folders in a shared resource.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 524/1003
5/8/24, 9:18 AM PDF Export

6. (optional) Other available options.

As needed, you can return to your Files and Folders Collector settings to manage your connections. Here are the actions available to you.

Edit the connection name by hovering over the default Collection name, and selecting the edit icon to edit the text.

Disable/Enable a connection by hovering over the top area of the connection section, on the opposite side of the connection name, and selecting
the applicable button.

Delete a connection by hovering over the top area of the connection section, on the opposite side of the connection name, and selecting the delete
icon. You can only delete a connection when you have more than one connection configured. Otherwise, this icon is not displayed.

7. Activate the Files and Folders Collector applet.

After a successful activation, the APPS field displays File with a green dot indicating a successful connection.

8. (Optional) To view metrics about the Files and Folders, left-click the File connection in the APPS field for your Broker VM.

Cortex XSIAM displays Resources, including the amount of CPU, Memory, and Disk space the applet is using.

9. Manage the Files and Folders Collector.

After you activate the Files and Folders Collector, you can make additional changes as needed. To modify a configuration, left-click the File connection in
the APPS column to display the Files and Folder Collector settings, and select:

Configure to redefine the Files and Folders Collector configurations.

Deactivate to disable the Files and Folders Collector.

You can also Ingest Logs in a Network Share as Datasets.

6.1.2.8 | Activate the FTP Collector

Abstract

Learn more about activating a broker VM with a FTP Collector applet.

The Broker VM provides a FTP Collector applet that enables you to monitor and collect logs from files and folders via FTP, FTPS, and SFTP directly to your log
repository for query and visualization purposes. A maximum file size of 500 MB is supported. After you activate the FTP Collector applet on a Broker VM in your
network, you can collect files as datasets (<Vendor>_<Product>_raw) by defining the following.

FTP, FTPS, or SFTP (default) connection details with the path to the folder containing the files that you want to monitor and upload to Cortex XSIAM .

Settings related to the list of files to monitor and upload to Cortex XSIAM , where the log format is either Raw (default), JSON, CSV, TSV, PSV, CEF,
LEEF, Corelight, or Cisco. Once the files are uploaded to Cortex XSIAM , you can define whether in the source directory the files are renamed or deleted.

PREREQUISITE:

Before activating the FTP Collector applet, review and perform the following:

Configure the Broker VM.

Ensure that the user permissions for the FTP, SFTP, or FTPS include the ability to rename and delete files in the folder that you want to configure
collection.

When setting up an FTPS Collector with a server using a Self-signed certificate, you must upload the certificate first to the Broker VM as a Trusted CA
certificate.

How to activate the FTP Collector

1. Select Settings → Configurations → Data Broker → Broker VMs.

2. In either the Brokers tab or the Clusters tab, locate your Broker VM.

3. You can either right-click the Broker VM and select Add App → FTP Collector, or in the APPS column, left-click Add → FTP Collector.

4. Configure the FTP Collector settings.

FTP Connection
Type

Select the type of FTP connection as FTP, SFTP, or FTPS.

Host

Specify the hostname, IP address, or FQDN of the FTP server. When configuring a FTPS Collector, you must specify the FQDN.

Port

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 525/1003
5/8/24, 9:18 AM PDF Export

Specify the FTP port number.

Username

Specify the username to login to the FTP server.

Password

Specify the password to login to the FTP server.

SSH Key-Based Authentication

This checkbox is only displayed when setting a SFTP Collector, which works with both Username and Password authentication or SSH Key-Based
Authentication. You can either leave this checkbox clear and set a Username and Password (default) or select SSH Key-Based Authentication to Browse
to a Private Key. When this connection is established with a server using a Self-signed certificate, you must upload it first to the Broker VM as a Trusted
CA Certificate.

NOTE:

When configuring an SFTP connection, Cortex XSIAM expects the private key to be in the RSA format that is included in the -----BEGIN RSA
PRIVATE KEY----- tag. Cortex XSIAM does not support providing the private key in the OpenSSH format from the -----BEGIN OPENSSH PRIVATE
KEY----- tag.

When using ssh-keygen using a Mac, you get the OpenSSH format by default. The command for getting the RSA format is:

ssh-keygen -t rsa -b 4096 -C <email address> -m PEM

Folder Path

Specify the path to the folder on the FTP site where the files are located that you want to collect.

Recursive

Select this checkbox to configure the FTP Collector applet to recursively examine any subfolders for new files as long as the folders are readable. This is
not configured by default.

Test Connection

Select to validate the FTP connection.

FTP Settings
Collect Every

Specify the execution frequency of collection by designating a number and then selecting the unit as either Minutes, Hours, or Days.

After Files Uploaded

Select what to do with the files after they are uploaded to the Cortex XSIAM server. You can either select Rename files with a suffix (default) and then you
must specify the Suffix or Delete files. When adding a suffix, the suffix is added at the end of the original file name using the format <file name>.
<suffix>, which becomes the new name of the file.

Include

Specify the files and folders that must match to be monitored by Cortex XSIAM . Multiple values are allowed with commas separating the values.

Allowed wildcard:

'?' matches a single alphabet character in a specific position.

'*' matches any character or set of characters, including no character.

Example: log*.json includes any JSON file starting with 'log'.

(optional) Exclude

Specify the files and folders that must match to not be monitored by Cortex XSIAM . Multiple values are allowed with commas separating the values.

Allowed wildcard:

'?' matches a single alphabet character in a specific position.

'*' matches any character or set of characters, including no character.

Example: *.backup excludes any file ending with '.backup'.

Log Format

Select the Log Format from the list as either Raw (default), JSON, CSV, TSV, PSV, CEF, LEEF, Corelight, or Cisco, which indicates to Cortex XSIAM how
to parse the data in the file. This setting defines the parser used to parse all the processed files as defined in the Include and Exclude fields, regardless of
the file names and extension. For example, if the Include field is set * and the Log Format is JSON, all files (even those named file.log) in the specified
folder are processed by the FTP Collector as JSON, and any entry that does not comply with the JSON format are dropped.

NOTE:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 526/1003
5/8/24, 9:18 AM PDF Export

When uploading JSON files, Cortex XSIAM only parses the first level of nesting and only supports single line JSON format, such that every new line
means a separate entry.
(optional) # of Lines to Skip

Specify the number of lines to skip at the beginning of the file. This is set to 0 by default.

NOTE:

Use this option only in cases where your files contain some sort of "header" lines, such as a general description, an introduction, a disclaimer, or similar,
and you want to skip ingesting them.
Data Source Mapping
Vendor and Product

Specify the Vendor and Product for the type of data being collected. The vendor and product are used to define the name of your Cortex Query Language
(XQL) dataset (<Vendor>_<Product>_raw).

NOTE:

The Vendor and Product defaults to Auto-Detect when the Log Format is set to CEF or LEEF.

Preview
Generate Preview

Select Generate Preview to display up to 10 rows from the first file and Preview the results. The Preview works based on the FTP Collector settings, which
means that if all the files that were configured to be monitored were already processed, then the Preview returns no records.

5. (Optional) Add Connection to define another FTP connection for collecting logs from files and folders via FTP, FTPS, or SFTP.

6. (Optional) Other available options.

As needed, you can return to your FTP Collector settings to manage your connections. Here are the actions available to you.

Edit the connection name by hovering over the default Collection name, and selecting the edit icon to edit the text.

Disable/Enable a connection by hovering over the top area of the connection section, on the opposite side of the connection name, and selecting
the applicable button.

Delete a connection by hovering over the top area of the connection section, on the opposite side of the connection name, and selecting the delete
icon. You can only delete a connection when you have more than one connection configured. Otherwise, this icon is not displayed.

7. Activate the FTP Collector applet.

After a successful activation, the APPS field displays FTP with a green dot indicating a successful connection.

8. (Optional) To view metrics about the FTP Collector, left-click the FTP connection in the APPS field for your Broker VM.

Cortex XSIAM displays Resources, including the amount of CPU, Memory, and Disk space the applet is using.

9. Manage the FTP Collector.

After you activate the FTP Collector, you can make additional changes as needed. To modify a configuration, left-click the FTP connection in the APPS
column to display the FTP Collector settings, and select:

Configure to redefine the FTP Collector configurations.

Deactivate to disable the FTP Collector.

You can also Ingest FTP Files as Datasets.

6.1.2.9 | Activate the NetFlow Collector

Abstract

Learn more about activating a broker VM with a NetflFlow Collector applet.

To receive NetFlow flow records from an external source, you must first set up the NetFlow Collector applet on a Broker VM within your network. NetFlow
versions 5, 9, and IPFIX are supported.

To increase the log ingestion rate, you can add additional CPUs to the Broker VM. The NetFlow Collector listens for flow records on specific ports either from
any, or from specific IP addresses.

After the NetFlow Collector is activated, the NetFlow Exporter sends flow records to the NetFlow Collector, which receives, stores, and pre-processes that data
for later analysis.

Performance Requirements

The following setups are required to meet your performance needs:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 527/1003
5/8/24, 9:18 AM PDF Export

4 CPUs for up to 50K flows per second (FPS).

8 CPUs for up to 100K FPS.

NOTE:

Since multiple network devices can send data to a single NetFlow Collector, we recommend that you configure a maximum of 50 NetFlow Collectors per
Broker VM applet, with a maximum aggregated rate of approximately 50K flows per second (FPS) to maintain system performance.
PREREQUISITE:

Configure the Broker VM

How to activate the NetFlow Collector

1. Select Settings → Configurations → Data Broker → Broker VMs.

2. In either the Brokers tab or the Clusters tab, locate your Broker VM.

3. You can either right-click the Broker VM and select Add App → NetFlow Collector, or in the APPS column, left-click Add → NetFlow Collector.

4. Click +Add New.

5. Configure your NetFlow Collector.

General Settings
UDP Port

Specify the number of the UDP port on which the NetFlow Collector listens for flow records (default 2055).

This port number must match the UDP port number in the NetFlow exporter device. The rules for each port are evaluated, line by line, on a first match
basis. Cortex XSIAM discards logs for non-configured flow records without an “Any” rule.

NOTE:

Since Cortex XSIAM reserves some port numbers, it is best to select a port number that is not in the range of 0-1024 (except for 514), in the range of
63000-65000 or has one of the following values: 4369, 5671, 5672, 5986, 6379, 8000, 8888, 9100, 15672, or 28672.

Custom Settings
Source Network

Specify the IP address or a Classless Inter-Domain Routing (CIDR) of the source network device that sends the flow records to Cortex XSIAM . Leave the
field empty to receive data from any device on the specified port (default). If you do not specify an IP address or a CIDR, Cortex XSIAM can receive data
from any source IP address or CIDR that transmits via the specified port. If IP addresses overlap in multiple rows in the Source Network field, such as
10.0.0.10 in the first row and 10.0.0.0/24 in the second row, the NetFlow Collector captures the IP address in the first row.

Vendor and Product

Specify a particular vendor and product to be associated with each dataset entry or leave the default IP Flow setting.

The Vendor and Product values are used to define the name of your Cortex Query Language (XQL) dataset <Vendor>_<Product>_raw. If you do not
define a vendor or product, Cortex XSIAM uses the default values with the resulting dataset name ip_flow_ip_flow_raw. Consider changing the default
values in order to uniquely identify the source network device.

After each configuration, select to save your changes and then select Done to update the NetFlow Collector with your settings.

6. (Optional) Make additional changes to the NetFlow Collector data sources.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 528/1003
5/8/24, 9:18 AM PDF Export

You can make additional changes to the Port by right-clicking the applicable UDP port and selecting the following.

Edit

To change the UDP Port, Source Network, Vendor, or Product defined.

Remove

To delete a Port.

You can make additional changes to the Source Network by right-clicking on the Source Network value.

NOTE:

The options available change, according to the set Source Network value.

Edit

To change the UDP Port, Source Network, Vendor, or Product defined.

Remove

To delete a Port.

Copy entire row

To copy the Source Network, Product, and Vendor information.

Open IP View

To view network operations and to view any open incidents on this IP within a defined period. This option is only available when the Source Network
value is a specific IP address or CIDR.

Open in Quick Launcher

To search for information using the Quick Launcher shortcut . This option is only available when the Source Network value is a specific IP address
or CIDR.

To prioritize the order of the NetFlow formats listed for the configured data source, drag and drop the rows to change their order.

7. Activate the NetFlow collector applet.

After successful activation, the APPS field displays NetFlow with a green dot indicating a successful connection.

8. (Optional) To view NetFlow Collector metrics, left-click the NetFlow connection in the APPS field for your Broker VM.

Cortex XSIAM displays the following information:

Connectivity Status

Whether the applet is connected to Cortex XSIAM.

Logs Received and Logs Sent

Number of logs that the applet received and sent per second over the last 24 hours. If there are more logs received than sent, this can indicate a
connectivity issue.

Resources

Displays the amount of CPU, Memory, and Disk space the applet uses.

9. Manage the NetFlow Collector.

After you activate the NetFlow Collector, you can make additional changes. To modify a configuration, left-click the NetFlow connection in the APPS
column to display the NetFlow Collector settings, and select:

Configure to redefine the NetFlow Collector configurations.

Deactivate to disable the NetFlow Collector.

You can also Ingest NetFlow Flow Records as Datasets.

6.1.2.10 | Activate the Network Mapper

Abstract

Learn more about activating the Network Mapper to scan your network.

PREREQUISITE:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 529/1003
5/8/24, 9:18 AM PDF Export

After you have configured and registered your Broker VM, you can choose to activate the Network Mapper application.

The Network Mapper allows you to scan your network to detect and identify unmanaged hosts in your environment according to defined IP address ranges. The
Network Mapper configurations are used to locate unmanaged assets that appear in the Assets table.

1. Select Settings → Configurations → Data Broker → Broker VMs.

2. In either the Brokers tab or the Clusters tab, locate your Broker VM.

3. You can either right-click the Broker VM and select Add App → Network Mapper, or in the APPS column, left-click Add → Network Mapper.

4. In the Activate Network Mapper window, define the following parameters:

Scan Method

Select the either ICMP echo or TCP SYN scan method to identify your network hosts. When selecting TCP SYN you can enter single ports and ranges
together, for example 80-83, 443.

Scan Requests per Second

Define the maximum number of scan requests you want to send on your network per second. By default, the number of scan requests are defined as
1000.

NOTE:

Each IP address range can receive multiple scan requests based on it's availability.

Scanning Scheduler

Define when you want to run the network mapper scan. You can select either daily, weekly, or monthly at a specific time.

Scanned Ranges

Select from the list of exiting IP address ranges to scan. Make sure to after each selection.

NOTE:

IP address ranges are displayed according to what you defined as your Network Parameters.

5. Activate the applet.

After a successful activation, the APPS field displays Network Mapper with a green dot indicating a successful connection.

6. In the APPS field, left-click the Network Mapper connection to view the following scan and applet metrics:

Scan Details
Connectivity Status

Whether the applet is connected to Cortex XSIAM .

Scan Status

State of the scan.

Scan Start Time

Timestamp of when the scan started.

Scan Duration

Period of time in minutes and seconds the scan is running.

Scan Progress

How much of the scan has been completed in percentage and IP address ratio.

Detected Hosts

Number of hosts identified from within the IP address ranges.

Scan Rate

Number of IP addresses scanned per second.

Applet Metrics
Resources

Displays the amount of CPU, Memory, and Disk space the applet is using.

7. Manage the Network Mapper.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 530/1003
5/8/24, 9:18 AM PDF Export

After the network mapper has been activated, left-click the Network Mapper connection in the APPS column to display the Network Mapper settings, and
select:

Configure to redefine the network mapper configurations.

Scan Now to initiate a scan.

Deactivate to disable the network mapper.

6.1.2.11 | Activate Pathfinder

Topic Not Found

6.1.2.12 | Activate the Windows Event Collector

Abstract

Set up your Windrows Event Collector to connect with the Cortex XSIAM Broker VM and collect events.

After you have configured and registered your Broker VM, activate your Windows Event Collector application.

The Windows Event Collector (WEC) runs on the Broker VM collecting event logs from Windows Servers, including Domain Controllers (DCs). The Windows
Event Collector can be deployed in multiple setups, and can be connected directly to multiple event generators (DCs or Windows Servers) or routed using one
or more Windows Event Collectors. Behind each Windows event collector there may be multiple generating sources.

To enable the collection of the event logs, you need to configure and establish trust between the Windows Event Forwarding (WEF) collectors and the WEC.
Establishing trust between the WEFs and the WEC is achieved by mutual authentication over TLS using server and client certificates. The WEF, a WinRM
plugin, runs under the Network Service account. Therefore, you need to provide the WEFs with the relevant certificates and grant the account access
permissions to the private key used for client authentication, for example, authenticate with WEC.

NOTE:

You can also activate the Windows Event Collector on Windows Core. For more information, see Activate the Windows Event Collector on Windows Core.

Ensure you meet the following prerequisites before activating the collector.

Cortex XDR Pro per GB license

Broker VM version 8.0 and later

You have knowledge of Windows Active Directory and Domain Controllers.

You must configure different settings related to the FQDN where the instructions differ depending on whether you are configuring a standalone Broker VM
or High Availability (HA) cluster.

Standalone broker: A FQDN must be configured for the standalone broker as configured in your local DNS server. Therefore, the Broker VM is
registered in the DNS, its FQDN is resolvable from the events forwarder (Windows server), and the Broker VM FQDN is configured. For more
information, see Edit Your Broker VM Configuration.

HA cluster: A FQDN must be configured in the cluster settings as configured in your local DNS server, which points to a Load Balancer. For more
information, see Configure a High Availability Cluster.

Windows Server 2012 r2 or later.

After ingestion, Cortex XSIAM normalizes and saves the Windows event logs in the dataset xdr_data. The normalized logs are also saved in a unified format in
microsoft_windows_raw. This enables you to search the data using Cortex Query Language (XQL) queries, build correlation rules, and generate dashboards
based on the data.

1. Select Settings → Configurations → Data Broker → Broker VM.

2. In either the Brokers tab or the Clusters tab, locate your Broker VM.

3. You can either right-click the Broker VM and select Add App → Windows Event Collector, or in the APPS column, left-click Add → Windows Event
Collector.

4. In the Activate Windows Event Collector window, define the Collected Events.

Configure the events collected by the applet. This lists event sources from which you want to collect events.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 531/1003
5/8/24, 9:18 AM PDF Export

Source—Select from the pre-populated list with the most common event sources on Windows Servers. The event source is the name of the
software that logs the events.

A source provider can only appear once in your list. When selecting event sources, depending on the type event you want to forward, ensure the
event source is enabled, for example auditing security events. If the source is not enabled, the source configuration in the given row will fail.

Min. Event Level—Minimum severity level of events that are collected.

Event IDs Group—Whether to Include, Exclude, or collect All event ID groups.

Event IDs—(Optional) Define specific event IDs or event ID ranges you want to collect.

Make sure to select after each entry.

Minimal TLS Version—Select either 1.0 or 1.2 (default) as the minimum TLS version allowed. Ensure that you verify that all Windows event
forwarders are supporting the minimal defined TLS version.

For example, to forward all the Windows Event Collector events to the Broker VM, define as follows:

Source—ForwardedEvents

Min. Event Level—Verbose

Event IDs Group—All

NOTE:

By default, Cortex XSIAM collects Palo Alto Networks predefined Security events that are used by the Cortex XSIAM detectors. Removing the Security
collector interferes with the Cortex XSIAM detection functionality. Restore to Default to reinstate the Security event collection.

5. Activate your configurations.

After a successful activation, the APPS field displays WEC with a green dot indicating a successful connection.

6. Left-click the WEC connection in the APPS column to display the Windows Event Collector settings, and select Configure.

In the Windows Event Forwarder Configuration window, perform the following tasks.

a. (copy) the Subscription Manager URL. This will be used when you configure the subscription manager in the GPO (Global Policy Object) on your
domain controller.

b. Define Client Certificate Export Password used to secure the downloaded WEF certificate used to establish the connection between your DC/WEF
and the WEC. You will need this password when the certificate is imported to the events forwarder.

c. Download the WEF certificate in a PFX format to your local machine.

To view your Windows Event Forwarding configuration details at any time, select your Broker VM, right-click and navigate to Windows Event
Collector → Configure.

Cortex XSIAM monitors the certificate and triggers a Certificate Expiration notification 30 days prior to the expiration date. The notification is sent daily
specifying the number of days left on the certificate, or if the certificate has already expired.

7. Install your WEF Certificate on the WEF to establish connection.

NOTE:

You must install the WEF certificate on every Windows Server, whether DC or not, for the WEFs that are supposed to forward logs to the Windows
Event Collector applet on the Broker VM.

a. Locate the PFX file you downloaded from the Cortex XSIAM console and double-click to open the Certificate Import Wizard.

b. In the Certificate Import Wizard:

1. Select Local Machine followed by Next.

2. Verify the File name field displays the PFX certificate file you downloaded and select Next.

3. In the Passwords field, specify the Client Certificate Export Password you defined in the Cortex XSIAM console followed by Next.

4. Select Automatically select the certificate store based on the type of certificate followed by Next and Finish.

c. From a command prompt, run certlm.msc.

d. In the file explorer, navigate to Certificates and verify the following for each of the folders.

In the Personal → Certificates folder, ensure the certificate forwarder.wec.paloaltonetworks.com appears.

In the Trusted Root Certification Authorities → Certificates folder, ensure the CA ca.wec.paloaltonetworks.com appears.

e. Navigate to Certificates → Personal → Certificates.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 532/1003
5/8/24, 9:18 AM PDF Export

f. Right-click the certificate and navigate to All tasks → Manage Private Keys.

g. In the Permissions window, select Add and in the Enter the object name section, specify NETWORK SERVICE followed by Check Names to verify the
object name. The object name is displayed with an underline when valid. and then OK.

h. Select OK, verify the Group or user names appear, and then Apply Permissions for private keys.

8. Add the Network Service account to the domain controller Event Log Readers group.

NOTE:

You must install the WEF certificate on every Windows Server, whether DC or not, for the WEFs that are supposed to forward logs to the Windows
Event Collector applet on the Broker VM.

a. To enable events forwarders to forward events, the Network Service account must be a member of the Active Directory Event Log Readers group.
In PowerShell, execute the following command on the domain controller that is acting as the event forwarder:

PS C:\> net localgroup "Event Log Readers" "NT Authority\Network Service" /add

Make sure you see The command completed successfully message.

b. Grant access to view the security event logs.

1. Run wevtutil gl security and take note of your channelAccess value.

For example:

`PS C:\Users\Administrator> wevtutil gl security

name: security
enabled: true
type: Admin
owningPublisher:
isolation: Custom
channelAccess: O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 533/1003
5/8/24, 9:18 AM PDF Export

logging:
logFileName: %SystemRoot%\System32\Winevt\Logs\security.evtx
retention: false
autoBackup: false
maxSize: 134217728
publishing:
fileMax: 1

Take note of value: channelAccess: O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)

2. Run wevtutil sl security "/ca:<channelAccess value>(A;;0x1;;;S-1-5-20)"

For example:

PS C:\Users\Administrator> wevtutil sl security "/ca:O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)(A;;0x1;;;S-1-5-20)"

Make sure you grant access on each of your domain controller hosts.

9. Create a WEF Group Policy that applies to every Windows server you want to configure as a WEF.

a. In a command prompt, open gpmc.msc.

b. In the Group Policy Management window, navigate to Domains → your domain name → Group Policy Object, right-click and select New.

c. In the New GPO window, enter your group policy Name: Windows Event Forwarding followed by OK.

d. Navigate to Domains → your domain name → Group Policy Objects → Windows Event Forwarding, right-click and select Edit.

e. In the Group Policy Management Editor:

Set the Windows Remote Management Service for automatic startup.

Select Computer Configuration → Policies → Windows Settings → Security Settings → System Services, and in the view panel locate
and double-click Windows Remote Management (WS-Management).

Mark Define this policy setting and select Automatic followed by Apply and OK.

At a minimum for your WEC configuration, you must enable logging of the same events that you have configured to be collected in your WEC
configuration on your domain controller. Otherwise, you will not be able to view these events as the WEC only controls querying not logging.
For example, if you have configured authentication events to be collected by your WEC using an authentication protocol, such as Kerberos,
you should ensure all relevant audit events for authentication are configured on your domain controller. In addition, you should ensure that all
relevant audit events that you want collected, such as the success and failure of account logins for Windows Event ID 4625, are properly
configured, particularly for those that you want Cortex XSIAM to apply grouping and analytics inspection.

NOTE:

This step overrides any local policy settings.

Here is an example of how to configure the WEC to collect authentication events using Kerberos as the authentication protocol to enable the
collection of Broker VM supported Kerberos events, Kerberos pre-authentication, authentication, request, and renewal tickets.

Select Computer Configuration → Policies → Windows Settings → Security Settings → Advanced Audit Policy Configuration → Audit
Policies → Account Logon.

In the view pane, right-click Audit Kerberos Authentication Service and select Properties. In the Audit Kerberos Authentication Service
window, mark Configure the following audit events:, select to Success and Failure followed by Apply and OK.

Repeat for Audit Kerberos Service Ticket Operations.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 534/1003
5/8/24, 9:18 AM PDF Export

f. Configure the subscription manager.

Navigate to Computer Configuration → Policies → Administrative Templates: Policy definitions → Windows Components → Event Forwarding, right-
click Configure target Subscription Manager and select Edit.

In the Configure target Subscription Manager window.

1. Mark Configure target Subscription Manager as Enabled.

2. In the Options section, select Show and in the Show Contents window, paste the Subscription Manage URL you copied from the Cortex
XSIAM console followed by OK.

3. Select Apply and OK to save your changes.

g. Add Network Service to Event Log Readers group.

Select Computer Configuration → Preferences → Control Panel Settings → Local Users and Groups, right-click and select New → Local Group.

In the New Local Group Properties window.

In the Group name field, select Event Log Readers (built-in).

In the Members section, select Add and enter in the Name filed Network Service followed by OK.

NOTE:

You must type out the name, do not select the name from the browse button.

Select Apply and OK to save your changes, and close the Group Policy Management Editor window.

h. Configure the Windows Firewall.

NOTE:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 535/1003
5/8/24, 9:18 AM PDF Export

If Windows Firewall is enabled on your event forwarders, you will have to define an outbound rule to enable the WEF to reach port 5986 on the
WEC.

In the Group Policy Management window, select Computer Configuration → Policies → Windows Settings → Security Settings → Windows Firewall
with Advanced Security → Outbound Rules, right-click and select New Rule.

In the New Outbound Rule Wizard define the following Steps.

1. Rule Type—Select Port followed by Next.

2. Protocols and Ports— Select TCP and in the Specific Remote Ports field enter 5986 followed by Next.

3. Action—Select Allow the connection followed by Next.

4. Profile—Select Domain and disable Private and Public followed by Next.

5. Name—Specify Windows Event Forwarding.

6. Select Finish to save your configurations.

10. Apply the WEF Group Policy.

Link the policy to the OU or the group of Windows servers you would like to configure as event forwarders. In the following flow, the domain controllers are
configured as an event forwarder.

a. Select Group Policy Management → <your domain name> → Domain Controllers, right-click and select Link an existing GPO....

b. In the Select GPO window, select Windows Event Forwarding followed by OK.

c. In an administrative PowerShell console, execute the following commands.

1. PS C:\Users\Administrator> gpupdate /force

Verify Computer Policy update has completed successfully. User Policy update has completed successfully. confirmation
message appears.

2. PS C:\Users\Administrator> Restart-Service WinRM

11. Verify Windows Event Forwarding.

a. In an administrative PowerShell console, run the following command.

PS C:\Users\Administrator> Get-WinEvent Microsoft-windows-WinRM/operational -MaxEvents 10

b. Look for WSMan operation EventDelivery completed successfully confirmation messages. These indicate events forwarded successfully.

12. (Optional) Manage the Window Event Collector.

After the Windows Event Collector has been activated in the Cortex XSIAM Management Console, left-click the WEC connection in the APPS column to
display the Windows Event Collector settings, and select:

Configure to define the event configuration information.

Collection Configuration to view or edit existing or add new events to collect.

Deactivate to disable the Windows Event Collector.

13. (Optional) To view metrics about the Windows Event Collector, left-click the WEC connection in the APPS field for your Broker VM, and you'll see the
following metrics:

Connectivity Status—Whether the applet is connected to Cortex XSIAM.

Logs Received and Logs Sent—Number of logs received and sent by the applet per second over the last 24 hours. If the number of incoming logs
received is larger than the number of logs sent, it could indicate a connectivity issue.

Resources—Displays the amount of CPU, Memory, and Disk space the applet is using.

6.1.2.12.1 | Activate the Windows Event Collector on Windows Core

Abstract

Learn more about activating the Windrows Event Collector on Windows Core OS to connect with the broker VM.

After you have configured and registered your Broker VM, you can activate your Windows Event Collector application on Windows Core OS (WCOS). WCOS is
a stripped-down, lightweight version of Windows that can be adapted to run on a wide variety of devices with minimal work compared to the previous way
explained in Activate the Windows Event Collector.

The Windows Event Collector (WEC) runs on the Broker VM collecting event logs from Windows Servers, including Domain Controllers (DCs). The Windows
Event Collector can be deployed in multiple setups, and can be connected directly to multiple event generators (DCs or Windows Servers) or routed using one
or more Windows Event Collectors. Behind each Windows event collector there may be multiple generating sources.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 536/1003
5/8/24, 9:18 AM PDF Export

To enable the collection of the event logs, you are configuring and establishing trust between the Windows Event Forwarding (WEF) collectors and the WEC.
Establishing trust between the WEFs and the WEC is achieved by mutual authentication over TLS using server and client certificates. The WEF, a WinRM
plugin, runs under the Network Service account. Therefore, you need to provide the WEFs with the relevant certificates and grant the account access
permissions to the private key used for client authentication, for example, authenticate with WEC.

Ensure you meet the following prerequisites before activating the collector.

Cortex XDR Pro per GB license

Broker VM version 8.0 and later

You have knowledge of Windows Active Directory and Domain Controllers.

You must configure different settings related to the FQDN where the instructions differ depending on whether you are configuring a standalone Broker VM
or High Availability (HA) cluster.

Standalone broker: A FQDN must be configured for the standalone broker as configured in your local DNS server. Therefore, the Broker VM is
registered in the DNS, its FQDN is resolvable from the events forwarder (Windows server), and the Broker VM FQDN is configured. For more
information, see Edit Your Broker VM Configuration.

HA cluster: A FQDN must be configured in the cluster settings as configured in your local DNS server, which points to a Load Balancer. For more
information, see Configure a High Availability Cluster.

Windows Server 2012 r2 or later.

After ingestion, Cortex XSIAM normalizes and saves the Windows event logs in the dataset xdr_data. The normalized logs are also saved in a unified format in
microsoft_windows_raw. This enables you to search the data using XQL queries, build correlation rules, and generate dashboards based on the data.

1. Select Settings → Configurations → Data Broker → Broker VM.

2. In either the Brokers tab or the Clusters tab, locate your Broker VM.

3. You can either right-click the Broker VM and select Add App → Windows Event Collector, or in the APPS column, left-click Add → Windows Event
Collector.

4. In the Activate Windows Event Collector window, define the Collected Events.

Configure the events collected by the applet. This lists event sources from which you want to collect events.

Source—Select from the pre-populated list with the most common event sources on Windows Servers. The event source is the name of the
software that logs the events.

A source provider can only appear once in your list. When selecting event sources, depending on the type event you want to forward, ensure the
event source is enabled, for example auditing security events. If the source is not enabled, the source configuration in the given row will fail.

Min. Event Level—Minimum severity level of events that are collected.

Event IDs Group—Whether to Include, Exclude, or collect All event ID groups.

Event IDs—(Optional) Define specific event IDs or event ID ranges you want to collect.

Make sure to select after each entry.

Minimal TLS Version—Select either 1.0 or 1.2 (default) as the minimum TLS version allowed. Ensure that you verify that all Windows event
forwarders are supporting the minimal defined TLS version.

For example, to forward all the Windows Event Collector events to the Broker VM, define as follows:

Source—ForwardedEvents

Min. Event Level—Verbose

Event IDs Group—All

NOTE:

By default, Cortex XSIAM collects Palo Alto Networks predefined Security events that are used by the Cortex XSIAM detectors. Removing the Security
collector interferes with the Cortex XSIAM detection functionality. Restore to Default to reinstate the Security event collection.

5. Activate your configurations.

After a successful activation, the APPS field displays WEC with a green dot indicating a successful connection.

6. Left-click the WEC connection in the APPS column to display the Windows Event Collector settings, and select Configure.

In the Windows Event Forwarder Configuration window, perform the following tasks.

a. (copy) the Subscription Manager URL. This will be used when you configure the subscription manager in the GPO (Global Policy Object) on your
domain controller.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 537/1003
5/8/24, 9:18 AM PDF Export

b. Define Client Certificate Export Password used to secure the downloaded WEF certificate used to establish the connection between your DC/WEF
and the WEC. You will need this password when the certificate is imported to the events forwarder.

c. Download the WEF certificate in a PFX format to your local machine.

To view your Windows Event Forwarding configuration details at any time, select your Broker VM, right-click and navigate to Windows Event
Collector → Configure.

Cortex XSIAM monitors the certificate and triggers a Certificate Expiration notification 30 days prior to the expiration date. The notification is sent daily
specifying the number of days left on the certificate, or if the certificate has already expired.

7. Install your WEF Certificate on the WEF to establish connection.

a. Start PowerShell with elevated privileges.

1. Run PowerShell with the following command.

PowerShell

2. From inside a PowerShell command run the following command.

Start-Process -Verb RunAs PowerShell

b. Copy the PFX file that you downloaded to the local Core machine in one of the following ways.

If you're able to RDP to your server, open Notepad, and select File → Open to copy and paste files from your local machine directly to the
server. If you have any local drives mapped through the RDP options, the local drives are also displayed. We recommend this method as it's
the simplest.

If you have enabled WinRM for remote PowerShell execution, you can copy over PowerShell using this command.

$session = New-PSSession –ComputerName <computer name>

Copy-Item –Path <path to PFX certificate file> –Destination '<temporary file path>' –ToSession $session

For example.

$session = New-PSSession –ComputerName SERVER1

Copy-Item –Path C:\Downloads\forwarder.wec.paloaltonetworks.com.pfx –Destination 'C:\temp\forwarder.wec.paloaltonetworks.com.pfx' –ToSession $session

To enable WinRM, use this command.

Execute "Start-Service winRM"

Execute "WinRM quickconfig"

Use SSH on server core. This includes enabling SSH on server core and using winscp to drag and drop the PFX file.

Use SMB to open the file share c$ on the \\server1\c$ server. You can only use this option if you are an administrator and the firewall on
your network isn't set to block file sharing.

You can also launch PowerShell and run the following command to tell the remote server to copy a file from your local computer using SMB.

Copy-Item –Path <path to PFX certificate file> –Destination '\\<computer name>\c$\<path to PFX file>

For example.

Copy-Item –Path C:\Downloads\forwarder.wec.paloaltonetworks.com.pfx –Destination '\\windows-core-server\c$\forwarder.wec.paloaltonetworks.com.pfx

c. Import the PFX file from PowerShell.

Use the following command to import the PFX file.

certutil -f -importpfx '<path to PFX file from Destination>'

For example.

certutil -f -importpfx '.\forwarder.wec.paloaltonetworks.com.pfx'

You will need to enter the Client Certificate Export Password you defined in the Cortex XSIAM console.

When the import is complete, the following message is displayed.

CertUtil: -importPFX command completed successfully.

d. Verify that the certificates are in the correct locations.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 538/1003
5/8/24, 9:18 AM PDF Export

Ensure the client certificate appears in "My" (Personal) store by running the following command.

certutil -store My

Ensure the CA appears in Trusted Root Certification Authorities by running the following command.

certutil -store root

e. Manage the private key of the forwarder.wec.paloaltonetworks.com.pfx certificate.

This entails applying permissions for the NETWORK SERVICE user.

1. Retrieve the Thumbprint of the forwarder.wec.paloaltonetworks.com.pfx certificate by running the following script.

$store = New-Object System.Security.Cryptography.X509Certificates.X509Store("My","LocalMachine")

$store.Open("ReadWrite")
echo $store.Certificates

After the script runs, copy the relevant thumbprint.

2. Grant NT AUTHORITY\NETWORK SERVICE with read permissions by running the following script with the $thumbprint set to the value you
copied in the previous step by replacing <Thumbprint retrieved value>.

$thumbprint = '<Thumbprint retrieved value>'

$account = 'NT AUTHORITY\NETWORK SERVICE'
#Open Certificate store and locate certificate based on provided thumbprint
$store = New-Object System.Security.Cryptography.X509Certificates.X509Store("My","LocalMachine")
$store.Open("ReadWrite")
$cert = $store.Certificates | where {$_.Thumbprint -eq $thumbprint}

#Create new CSP object based on existing certificate provider and key name
#Note: Ensure this command is pasted to the same row and doesn’t break to multiple rows.
#Otherwise, the command will fail with errors.
$csp = New-Object System.Security.Cryptography.CspParameters($cert.PrivateKey.CspKeyContainerInfo.ProviderType,
$cert.PrivateKey.CspKeyContainerInfo.ProviderName,
$cert.PrivateKey.CspKeyContainerInfo.KeyContainerName)

# Set flags and key security based on existing cert

$csp.Flags = "UseExistingKey","UseMachineKeyStore"
$csp.CryptoKeySecurity = $cert.PrivateKey.CspKeyContainerInfo.CryptoKeySecurity
$csp.KeyNumber = $cert.PrivateKey.CspKeyContainerInfo.KeyNumber

# Create new access rule - could use parameters for permissions, but I only needed GenericRead
$access = New-Object System.Security.AccessControl.CryptoKeyAccessRule($account,"GenericRead","Allow")
# Add access rule to CSP object

$csp.CryptoKeySecurity.AddAccessRule($access)

#Create new CryptoServiceProvider object which updates Key with CSP information created/modified above
$rsa2 = New-Object System.Security.Cryptography.RSACryptoServiceProvider($csp)

#Close certificate store

$store.Close()
echo $csp.CryptoKeySecurity

3. After the script runs, validate the permissions are now set correctly.

8. Add the Network Service account to the domain controller Event Log Readers group.

NOTE:

You must install the WEF certificate on every Windows Server, whether DC or not, for the WEFs that are supposed to forward logs to the Windows
Event Collector applet on the Broker VM.

a. To enable events forwarders to forward events, the Network Service account must be a member of the Active Directory Event Log Readers group.
In PowerShell, execute the following command on the domain controller that is acting as the event forwarder:

PS C:\> net localgroup "Event Log Readers" "NT Authority\Network Service" /add

Make sure you see the following message.

The command completed successfully.

b. Grant access to view the security event logs.

1. Run wevtutil gl security and take note of your channelAccess value.

For example:

`PS C:\Users\Administrator> wevtutil gl security

name: security
enabled: true
type: Admin
owningPublisher:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 539/1003
5/8/24, 9:18 AM PDF Export

isolation: Custom
channelAccess: O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)
logging:
logFileName: %SystemRoot%\System32\Winevt\Logs\security.evtx
retention: false
autoBackup: false
maxSize: 134217728
publishing:
fileMax: 1

Take note of value: channelAccess: O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)

2. Run wevtutil sl security "/ca:<channelAccess value>(A;;0x1;;;S-1-5-20)"

For example:

PS C:\Users\Administrator> wevtutil sl security "/ca:O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)(A;;0x1;;;S-1-5-20)"

Make sure you grant access on each of your domain controller hosts.

9. Create a WEF Group Policy that applies to every Windows server you want to configure as a WEF.

As a Group Policy Management Console is not available on Core servers, it’s not possible to fully edit a Group Policy Object (GPO) either with
PowerShell or using a web solution. As a result, follow this alternative method, which is based on configuring a group policy from another Windows DC by
remotely configuring the group policy.

a. Use any DC that has the Group Policy Management Console available in the same domain as the Core server, and verify the connection between
the servers with a simple ping.

b. Run cmd as an administrator.

c. Run the following command.

gpmc.msc /gpcomputer: <computer name.Domain>

For example.

gpmc.msc /gpcomputer: WIN-SI2SVDOKIMV.ENV21.LOCAL

d. In the Group Policy Management window, navigate to Domains → your domain name → Group Policy Object, right-click and select New.

e. In the New GPO window, enter your group policy Name: Windows Event Forwarding followed by OK.

f. Navigate to Domains → your domain name → Group Policy Objects → Windows Event Forwarding, right-click and select Edit.

g. In the Group Policy Management Editor:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 540/1003
5/8/24, 9:18 AM PDF Export

Set the Windows Remote Management Service for automatic startup.

Select Computer Configuration → Policies → Windows Settings → Security Settings → System Services, and in the view panel locate
and double-click Windows Remote Management (WS-Management).

Mark Define this policy setting and select Automatic followed by Apply and OK.

At a minimum for your WEC configuration, you must enable logging of the same events that you have configured to be collected in your WEC
configuration on your domain controller. Otherwise, you will not be able to view these events as the WEC only controls querying not logging.
For example, if you have configured authentication events to be collected by your WEC using an authentication protocol, such as Kerberos,
you should ensure all relevant audit events for authentication are configured on your domain controller. In addition, you should ensure that all
relevant audit events that you want collected, such as the success and failure of account logins for Windows Event ID 4625, are properly
configured, particularly for those that you want Cortex XSIAM to apply grouping and analytics inspection.

NOTE:

This step overrides any local policy settings.

Here is an example of how to configure the WEC to collect authentication events using Kerberos as the authentication protocol to enable the
collection of Broker VM supported Kerberos events, Kerberos pre-authentication, authentication, request, and renewal tickets.

Select Computer Configuration → Policies → Windows Settings → Security Settings → Advanced Audit Policy Configuration → Audit
Policies → Account Logon.

In the view pane, right-click Audit Kerberos Authentication Service and select Properties. In the Audit Kerberos Authentication Service
window, mark Configure the following audit events:, select to Success and Failure followed by Apply and OK.

Repeat for Audit Kerberos Service Ticket Operations.

h. Configure the subscription manager.

Navigate to Computer Configuration → Policies → Administrative Templates: Policy definitions → Windows Components → Event Forwarding, right-
click Configure target Subscription Manager and select Edit.

In the Configure target Subscription Manager window.

1. Mark Configure target Subscription Manager as Enabled.

2. In the Options section, select Show and in the Show Contents window, paste the Subsription Manage URL you copied from the Cortex XSIAM
console followed by OK.

3. Select Apply and OK to save your changes.

i. Add Network Service to Event Log Readers group.

Select Computer Configuration → Preferences → Control Panel Settings → Local Users and Groups, right-click and select New → Local Group.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 541/1003
5/8/24, 9:18 AM PDF Export

In the New Local Group Properties window.

In the Group name field, select Event Log Readers (built-in).

In the Members section, select Add and enter in the Name filed Network Service followed by OK.

NOTE:

You must type out the name, do not select the name from the browse button.

Select Apply and OK to save your changes, and close the Group Policy Management Editor window.

j. Configure the Windows Firewall.

NOTE:

If Windows Firewall is enabled on your event forwarders, you will have to define an outbound rule to enable the WEF to reach port 5986 on the
WEC.

In the Group Policy Management window, select Computer Configuration → Policies → Windows Settings → Security Settings → Windows Firewall
with Advanced Security → Outbound Rules, right-click and select New Rule.

In the New Outbound Rule Wizard define the following Steps.

1. Rule Type—Select Port followed by Next.

2. Protocols and Ports— Select TCP and in the Specific Remote Ports field enter 5986 followed by Next.

3. Action—Select Allow the connection followed by Next.

4. Profile—Select Domain and disable Private and Public followed by Next.

5. Name—Specify Windows Event Forwarding.

6. Select Finish to save your configurations.

10. Apply the WEF Group Policy.

Link the policy to the OU or the group of Windows servers you would like to configure as event forwarders. In the following flow, the domain controllers are
configured as an event forwarder.

a. Select Group Policy Management → <your domain name> → Domain Controllers, right-click and select Link an existing GPO....

b. In the Select GPO window, select Windows Event Forwarding followed by OK.

c. In an administrative PowerShell console, execute the following commands.

1. PS C:\Users\Administrator> gpupdate /force

Verify Computer Policy update has completed successfully. User Policy update has completed successfully. confirmation
message appears.

2. PS C:\Users\Administrator> Restart-Service WinRM

11. Verify Windows Event Forwarding.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 542/1003
5/8/24, 9:18 AM PDF Export

a. In an administrative PowerShell console, run the following command.

PS C:\Users\Administrator> Get-WinEvent Microsoft-windows-WinRM/operational -MaxEvents 10

b. Look for WSMan operation EventDelivery completed successfully confirmation messages. These indicate events forwarded successfully.

12. (Optional) Manage the Window Event Collector.

After the Windows Event Collector has been activated in the Cortex XSIAM Management Console, left-click the WEC connection in the APPS column to
display the Windows Event Collector settings, and select:

Configure to define the event configuration information.

Collection Configuration to view or edit existing or add new events to collect.

Deactivate to disable the Windows Event Collector.

13. (Optional) To view metrics about the Windows Event Collector, left-click the WEC connection in the APPS field for your Broker VM, and you'll see the
following metrics:

Connectivity Status—Whether the applet is connected to Cortex XSIAM .

Logs Received and Logs Sent—Number of logs received and sent by the applet per second over the last 24 hours. If the number of incoming logs
received is larger than the number of logs sent, it could indicate a connectivity issue.

Resources—Displays the amount of CPU, Memory, and Disk space the applet is using.

6.1.2.12.2 | Renew WEC Certificates

Abstract

Learn more about renewing your WEC certificates in Cortex XSIAM.

Renewing your WEC certificates in Cortex XSIAM includes renewing your Windows Event Forwarding (WEF) client certificate and your WEC server certificate.
You must install the WEF certificate on every Windows server, whether a Domain Controller (DC) or not, for the WEFs that are supposed to forward logs to the
Windows Event Collector applet on the Broker VM.

IMPORTANT:

After you receive a notification for renewing your WEC CA certificate, we recommend that you do not add any new WEF clients until the WEC certification
renewal process is complete. Events from these WEF clients that are added afterwards will not be collected by the server until the WEC certificates are
renewed.

In addition, Cortex XSIAM manages the renewal of your WEC certificates by implementing the following time limits.

The WEC CA certificate is increased for an extended period of time for a maximum of 20 years.

The Broker VM applet includes an automatic renewal mechanism for a WEC server certificate, which has a lifespan of 12 months.

The WEC client certificate after the renewal is issued with a lifespan of 5 years.

To renew your WEC certificates:

1. Renew your WEF client certificate in Cortex XSIAM .

a. Select Settings → Configurations → Data Broker → Broker VMs.

b. In either the Brokers tab or the Clusters tab, locate your Broker VM.

c. Left-click the WEC connection in the APPS column to display the Windows Event Collector settings, and select Configure.

d. In the Windows Event Forwarder Configuration window:

1. (copy) the Subscription Manager URL. This will be used when you Renew WEC Certificates in the GPO (Global Policy Object) on your
domain controller.

2. Define Client Certificate Export Password used to secure the downloaded WEF certificate used to establish the connection between your
DC/WEF and the WEC. You will need this password when the certificate is imported to the events forwarder.

3. Download the WEF certificate in a PFX format to your local machine.

e. Install your WEF Certificate on the WEF to establish connection.

NOTE:

You must install the WEF certificate on every Windows Server, whether DC or not, for the WEFs that are supposed to forward logs to the
Windows Event Collector applet on the Broker VM.

1. Locate the PFX file you downloaded from the Cortex XSIAM console and double-click to open the Certificate Import Wizard.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 543/1003
5/8/24, 9:18 AM PDF Export

2. In the Certificate Import Wizard:

a. Select Local Machine followed by Next.

b. Verify the File name field displays the PFX certificate file you downloaded and select Next.

c. In the Passwords field, enter the Client Certificate Export Password you defined in the Cortex XSIAM console followed by Next.

d. Select Automatically select the certificate store based on the type of certificate followed by Next and Finish.

3. From a command prompt, run certlm.msc.

4. In the file explorer, navigate to Certificates and verify the following for each of the folders:

In the Personal → Certificates folder, ensure the certificate forwarder.wec.paloaltonetworks.com appears.

In the Trusted Root Certification Authorities → Certificates folder, ensure the CA ca.wec.paloaltonetworks.com appears.

NOTE:

You can see more than one ca.wec.paloaltonetworks.com and forwarder.wec.paloaltonetworks.com file from a previous
installation in the directory, so select the file with the most extended Expiration Date. You can verify that you are using the correct
certificate:

To verify the client certificate in the Personal → Certificates folder is related to the CA, you can select your
forwarder.wec.paloaltonetworks.com file and from the Certification Path tab, double-click ca.wec.paloaltonetworks.com. In the
Details tab, Show: Properties only, and verify the Thumbprint matches the ca.wec.paloaltonetworks.com file Thumbprint.

For the Trusted Root Certificate (i.e. CA certificate), you can verify the Thumbprint of your ca.wec.paloaltonetworks.com file
matches the Subscription Manager URL by double-clicking the file and from the Details tab verifying the Thumbprint.

5. Navigate to Certificates → Personal → Certificates.

6. Right-click the certificate and navigate to All tasks → Manage Private Keys.

7. In the Permissions window, select Add and in the Enter the object name section, enter NETWORK SERVICE followed by Check Names to verify
the object name. The object name is displayed with an underline when valid. and then OK.

8. Select OK, verify the Group or user names appear, and then Apply Permissions for private keys.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 544/1003
5/8/24, 9:18 AM PDF Export

f. Configure the subscription manager.

Navigate to Computer Configuration → Policies → Administrative Templates: Policy definitions → Windows Components → Event Forwarding, right-
click Configure target Subscription Manager and select Edit.

In the Configure target Subscription Manager window:

1. Mark Configure target Subscription Manager as Enabled.

2. In the Options section, select Show, and in the Show Contents window, paste the Subscription Manager URL that you copied from the Cortex
XSIAM console followed by OK.

3. Select Apply and OK to save your changes.

g. Complete the WEF Client certificate renewal.

On every WEF DC, perform the following from a command prompt.

1. Run gpupdate /force to update the group policy.

2. Restart-Service WinRM to apply the configurations.

2. Renew your WEC server certificate in Cortex XSIAM .

NOTE:

Only perform this step under the following conditions.

You have completed the WEF certification renewal process for ALL clients in your environment. Otherwise, events from the WEFs that you did not
install the new client certificate will not be collected by the WEC.

You are approaching the WEC server CA certificate expiration date, which is 2 years after the Windows Event Collector applet activation, and
receive a notification in the Cortex XSIAM console.

a. Select Settings → Configurations → Data Broker → Broker VMs.

b. In either the Brokers tab or the Clusters tab, locate your Broker VM.

c. Left-click the WEC connection in the APPS column to display the Windows Event Collector settings, and select Renew WEC Server Certificate.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 545/1003
5/8/24, 9:18 AM PDF Export

d. Click Renew.

Once Cortex XSIAM renews the WEC server certificate, the status of the WEC in the APPS field on the Broker VMs machine is Connected
indicating the applet is running. In addition, the health status of the Windows Event Collector applet is now green instead of yellow and the warning
message that appeared when you hovered over the health status no longer appears. Your WEC server certificate is issued with a lifespan of 12
months.

We also suggest that in XQL Search that you run the following query to verify that your event logs are being captured.

dataset = Cortex XSIAM

_data
| filter _product = "Windows"
| fields _vendor,_product,action_evtlog_level,action_evtlog_event_id
| sort desc _time | limit 20

NOTE:

If this query does not display results with a timestamp from after the renewal process, it could indicate that the renewal process is not complete,
so wait a few minutes before running another query. If you are still having a problem, contact Technical Support.

6.1.3 | Manage Your Broker VMs

Abstract

Learn more about managing your broker VMs from the management console.

After you configure the Broker VMs, you can manage your Broker VMs from the Cortex XSIAM management console in the Broker VMs page.

When managing a Broker VM, the options differ for a standalone Broker VM versus a Broker VM node that is added to a high availability (HA) cluster. Certain
configuration options that are only relevant for a Broker VM cluster node, such as Remove from Cluster, are only displayed when the Broker VM is a cluster
peer.

NOTE:

Cortex XSIAM updates and enhances the Broker VM automatically through maintenance releases. The Broker VM version release process uses several
security measures and tools to ensure that every released version is highly secure. These include the following.

CIS Server Level 1 and 2 benchmarks (using a 3rd party product)

Vulnerability scanning for containers running on the Broker VM

Vulnerability scanning for the host kernel

Periodic 3rd party penetration testing

6.1.3.1 | View Broker VM Details

Abstract

Learn more about viewing the details of any particular Broker VM.

In Cortex XSIAM , select Settings → Configurations → Data Broker → Broker VMs to view detailed information regarding your registered Broker VMs in the
Brokers tab.

The Broker VMs table enables you to monitor and mange your Broker VM and applet connectivity status, version management, device details, and usage
metrics.

The following table describes both the default fields and additional optional fields that you can add to the Brokers table using the column manager and lists the
fields in alphabetical order.

Read more...
NOTE:

Certain fields are also exposed in the Clusters tab, when a Broker VM node is added to a High Availability (HA) cluster, and each cluster node is expanded to
view the Broker VM nodes table. An asterisk (*) is beside every field that is also included in the Broker VM nodes table for each HA cluster.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 546/1003
5/8/24, 9:18 AM PDF Export

Field Description

Status Indicator ( Identifies in the following columns:

Device Name

Whether the Broker machine is registered and connected to Cortex XSIAM.

)*
Version

Whether the Broker VM is running the latest version.

APPS

Whether the available applications are connected to Cortex XSIAM.

Colors depict the following statuses:

Black

Disconnected to Cortex XSIAM

Red

Disconnected from Cortex XSIAM

Orange

Past Version

Green

Connected, Current Version

Check box to select one or more Broker devices on which to perform actions.

ALL interfaces All IP addresses of the different interfaces on the device.

APPS* List of active or inactive applets and the connectivity status for each.

CLUSTER NAME* Indicates the name of the HA cluster that the Broker VM has been added to. For a
standalone Broker VM, which isn't added to any HA cluster, this field is empty.

CPU USAGE* CPU usage of the Broker device in percentage synced every 5 minutes.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 547/1003
5/8/24, 9:18 AM PDF Export

Field Description

CONFIGURATION STATUS* Broker VM configuration status. Status is defined by the following according to
changes made to any of the Broker VM configurations.

up to date

Broker VM configuration changes made through the Cortex XSIAM console have
been applied.

in progress

Broker VM configuration changes made through the Cortex XSIAM console are
being applied.

submitted

Broker VM configuration changes made through the Cortex XSIAM console have
reached the Broker VM and awaiting implementation.

failed

Broker VM configuration changes made through the Cortex XSIAM console have
failed. Need to open a Palo Alto Networks support ticket.

DEVICE ID Device ID allocated to the Broker VM by Cortex XSIAM after registration.

DEVICE NAME* Same as the Device ID.

A icon notifies of an expired Broker VM. To reconnect, generate a new token and
re-register your Broker VM as described in steps 1 through 7 of Configure the
Broker VM. Once registered, all previous Broker VM configurations are reinstated.

DISK USAGE* Disk usage of the Broker VM in portion of computer storage that is currently in use.

Notification about low disk space appear in the Notification Center.

EXTERNAL INTERFACE The IP interface the Broker VM is using to communicate with the server.

For AWS and Azure cloud environments, the field displays the Internal IP value.

LAST SEEN Indicates when the Broker VM was last seen on the network.

MEMORY USAGE* Memory usage of the Broker VM in percentage synced every 5 minutes.

STATUS* Connection status of the Broker VM. Status is defined by either Connected or
Disconnected.

Disconnected Broker VMs do not display CPU Usage, Memory Usage, and Disk
Usage information.

Notifications about the Broker VM losing connectivity to Cortex XSIAM appear in

the Notification Center.

UPGRADE TIME Timestamp of when the Broker VM was upgraded.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 548/1003
5/8/24, 9:18 AM PDF Export

Field Description

VERSION* Version number of the Broker VM. If the status indicator is not green, then the
Broker VM is not running the latest version.

Notifications about the available new Broker VM version appear in the Notification
Center.

6.1.3.2 | Edit Your Broker VM Configuration

Abstract

Learn more about editing the configuration of a Broker VM.

After configuring and registering your Broker VM, you can edit existing configurations and define additional settings in the Broker VMs page in the Brokers tab.
When you have a high availability (HA) cluster configured, you can also edit any Broker VM nodes configurations in the Clusters tab from the Broker VMs table
under the Cluster.

Perform the following procedures in the order listed below.

Task 1. Open the Configurations page for the Broker VM

1. Select Settings → Configurations → Data Broker → Broker VMs.

2. In the Broker VMs table, locate your Broker VM, right-click, and select Configure.

If the Broker VM is disconnected, you can only View the configurations.

NOTE:

For all Broker VM nodes added to a HA cluster, you can also Configure the Broker VM nodes from the Clusters tab.

Task 2. Define the settings in the Configurations page

Network Interfaces, Proxy Server, NTP Server, and SSH Access

Edit the existing Network Interfaces, Proxy Server, NTP Server, and SSH Access configurations.

Device Name (Requires Broker VM 8.0 and later)

Device Name

Change the name of your Broker VM device name by selecting the pencil icon. The new name will appear in the Brokers table.

FQDN

Set your Broker VM FQDN as it will be defined in your Domain Name System (DNS). This enables connection between the WEF and WEC, acting as the
subscription manager. The Broker VM FQDN settings affect the WEC and Agent Installer and Content Caching.

(Optional) Internal Network (Requires Broker VM 8.0 and later)

Specify a network subnet to avoid the Broker VM dockers colliding with your internal network. By default, the Network Subnet is set to 172.17.0.1/16.

NOTE:

Internal IP must be:

Formatted as prefix/mask, for example 192.0.2.1/24.

Must be within /8 to /24 range.

Cannot be configured to end with a zero.

For Broker VM version 9.0 and lower, Cortex XSIAM accepts only 172.17.0.0/16.

Auto Upgrade

Enable or Disable automatic upgrade of the Broker VM. By default, auto upgrade is enabled at Any time for all 7 days of the week, but you can also set the Days
in Week and Specific time for the automatic upgrades. If you disable auto-upgrade, new features and improvements will require manual upgrade.

Monitoring

Enable or Disable of local monitoring of the Broker VM usage statistics in Prometheus metrics format, allowing you to tap in and export data by navigating to
http://<broker_vm_address>:9100/metrics/. By default, monitoring your Broker VM is disabled. For more information with an example of how to set up
Prometheus and Grafana to monitor the Broker VM, see Monitor the Broker VM using Prometheus.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 549/1003
5/8/24, 9:18 AM PDF Export

(Optional) SSH Access

Broker VM 7.4.5 and earlier

Enable/Disable ssh Palo Alto Networks support team SSH access by using a Cortex XSIAM token.

Enabling allows Palo Alto Networks support team to connect to the Broker VM remotely, not the customer, with the generated password. If you use SSL
decryption in your firewalls, you need to add a trusted self-signed CA certificate on the Broker VM to prevent any difficulties with SSL decryption. For example,
when configuring Palo Alto Networks NGFW to decrypt SSL using a self-signed certificate, you need to ensure the Broker VM can validate a self-signed CA by
uploading the cert_ssl-decrypt.crt file on the Broker VM.

NOTE:

Make sure you save the password before closing the window. The only way to re-generate a password is to disable ssh and re-enable.

Broker VM 14.0.42 and later

Customize the login banner displayed, when logging into SSH sessions on the Broker VM in the Welcome Message field by overwriting the default welcome
message with a new one added in the field. When the field is empty, the default message is used.

Broker UI Password

Reset your current Broker VM Web UI password. Define and Confirm your new password. Password must be at least 8 characters.

(Optional) SSL Server Certificate section (Requires Broker VM 10.1.9 and later)

Upload your signed server certificate and key to establish a validated secure SSL connection between your endpoints and the Broker VM. When you configure
the server certificate and the key files in the tenant UI, Cortex XSIAM automatically updates them in the Broker VM UI, even when the Broker VM UI is disabled.

Cortex XSIAM validates that the certificate and key match, but does not validate the Certificate Authority (CA).

When you are done, Save your changes.

6.1.3.3 | Monitor the Broker VM using Prometheus

Abstract

Learn more on monitoring the Broker VM using Prometheus.

You can enable local monitoring of the Broker VM to provide usage statistics in a Prometheus metrics format. You can tap in and export data by navigating to
http://<broker_vm_address>:9100/metrics/. By default, monitoring is disabled.

Prerequisite

To monitor the Broker VM using Prometheus, ensure that you enable monitoring on the Broker VM. This is performed after configuring and registering your
Broker VM, when you can edit existing configurations and define additional settings in the Broker VMs page.

1. Select Settings → Configurations → Data Broker → Broker VMs.

2. In the Broker VMs table, locate your Broker VM, right-click, and select Configure.

NOTE:

For all Broker VM nodes added to a HA cluster, you can also Configure the Broker VM nodes from the Clusters tab.

3. In the Broker VM Configurations page, select Monitoring from the left pane.

4. Clear the Use Default (Disabled) checkbox.

5. In the Montoring menu, select Enabled.

6. Click Save.

How to set up Prometheus and Grafana to monitor the Broker VM

Below is an example of how to set up Prometheus and Grafana to monitor the Broker VM. This is set up using a docker compose on an Ubuntu machine to
monitor the CPU usage.

Perform the following procedures in the order listed below.

Task 1. Install Docker and Docker Compose

1. Update your Ubuntu system:

sudo apt update

2. Install Docker:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 550/1003
5/8/24, 9:18 AM PDF Export

NOTE:

For more information on Docker, see the Docker website.

sudo apt install docker.io

3. Start the Docker service:

sudo systemctl start docker

4. Enable Docker to start on boot:

sudo systemctl enable docker

5. Install Docker Compose:

sudo curl -L "https://github.com/docker/compose/releases/latest/download/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose

sudo chmod +x /usr/local/bin/docker-compose

Task 2. Create a Docker Compose file

This task includes setting up Prometheus and Grafana.

1. Create a file named docker-compose.yml, and open it for editing:

vim docker-compose.yml

2. Add the following content to the file:

version: '3.8'
services:
prometheus:
image: prom/prometheus:latest
container_name: prometheus
restart: unless-stopped
volumes:
- ./prometheus.yml:/etc/prometheus/prometheus.yml
- prometheus_data:/prometheus
command:
- '--config.file=/etc/prometheus/prometheus.yml'
- '--storage.tsdb.path=/prometheus'
- '--web.console.libraries=/etc/prometheus/console_libraries'
- '--web.console.templates=/etc/prometheus/consoles'
- '--web.enable-lifecycle'
- '--log.level=debug'
ports:
- '9090:9090'
grafana:
image: grafana/grafana-enterprise
container_name: grafana
restart: unless-stopped
ports:
- '3000:3000'
volumes:
- grafana_data:/var/lib/grafana
volumes:
grafana_data: {}
prometheus_data: {}

3. Save and close the file.

Task 3. Create a Prometheus configuration file

You need to configure Prometheus to scrape the Broker VM metrics by creating a Prometheus configuration file.

1. Create a Prometheus configuration file named prometheus.yml in the same directory as the docker-compose.yml file that you created above.

2. Open the prometheus.yml file for editing:

vim prometheus.yml

3. Add the following content to the file:

global:
scrape_interval: 15s
scrape_timeout: 10s
scrape_configs:
- job_name: 'prometheus'
static_configs:
- targets: ['<your server IP address>:9090']
- job_name: 'node'
static_configs:
- targets: ['<Broker VM IP address>:9100']

4. Save and close the file.

Task 4. Run Docker Compose

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 551/1003
5/8/24, 9:18 AM PDF Export

1. In the terminal, run the following command from the project directory:

docker-compose up -d

2. Verify that Prometheus is running correctly:

docker-compose logs -f prometheus

Task 5. Access Grafana and Set Up Prometheus as a Data Source

1. Open a web browser and go to http://<your server>:3000.

2. Log in to Grafana using the default credentials.

Username: admin

Password: admin

3. Set up Prometheus as a data source:

a. In the left pane, select Administation → Data sources.

b. Click Add data source, and select Prometheus.

c. Under HTTP, set the URL to http://<your server IP address>:9090.

d. To verify the connection, click Save & Test.

Task 6. Create Dashboards in Grafana

You can now create dashboards in Grafana to visualize the data from Prometheus.

1. In Grafana, on the left pane, click Dashboards.

2. Select New and create a new dashboard.

3. Add a panel to the dashboard and configure the dashboard to display the Prometheus metrics that you want.

4. To monitor CPU usage, use the following metric:

100 - (avg by (instance) (rate(node_cpu_seconds_total{job="node",mode="idle"}[1m])) * 100)

6.1.3.4 | Collect Broker VM Logs

Abstract

Learn more about collecting logs from a Broker VM to review them as part of an investigation.

Cortex XSIAM enables you to collect your Broker VM logs directly from the Cortex XSIAM management console.

You can collect logs by either regenerating the most up-to-date logs and downloading them once they are ready, or downloading the current logs from the last
creation date reflected in the TIMESTAMP.

1. Select Settings → Configurations → Data Broker → Broker VMs to view the Broker VMs table in the Brokers tab.

2. Locate your Broker VM, right-click and select one of these options depending on the type of logs you want to download.

Generate New Logs

Regenerates the most up-to-date logs and downloads them once they are ready.

Download Logs (<TIMESTAMP>)

Downloads the logs from the last creation date reflected in the <TIMESTAMP> displayed. This option is only displayed when you’ve downloaded your logs
previously using Generate New Logs.

Logs are generated automatically, but can take up to a few minutes depending on the size of the logs.

6.1.3.5 | Reboot a Broker VM

Abstract

You can manually reboot a Broker VM when needed.

Cortex XSIAM enables you to reboot your Broker VM directly from the Cortex XSIAM management console in the Broker VMs page.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 552/1003
5/8/24, 9:18 AM PDF Export

1. Select Settings → Configurations → Data Broker → Broker VMs.

2. From either the Brokers or Clusters tab, locate your Broker VM, right-click and select Reboot VM.

6.1.3.6 | Shut Down a Broker VM

Abstract

Learn more about gracefully shutting down the broker VM directly from the Cortex XSIAM Broker VMs table.

Cortex XSIAM enables you to gracefully shutdown the Broker VM directly from the Broker VMs page in both the Brokers and Clusters tab.

1. Select Settings → Configurations → Data Broker → Broker VMs.

2. In either the Brokers or Clusters tab, locate your Broker VM, right-click, and select Shutdown VM.

6.1.3.7 | Upgrade a Broker VM

Abstract

You can upgrade a Broker VM from the Cortex XSIAM management console.

You can upgrade any Broker VM directly from the Cortex XSIAM management console in the Broker VMs page from both the Brokers and Clusters tab.

IMPORTANT:

For all brokers that were deployed with a Broker VM image, downloaded prior to July 9th, 2023 (installed with Ubuntu 18.04 or earlier), the Broker VM must be
reinstalled with a new image (installed with Ubuntu 20.04 or later) before upgrading to the latest version. For more information on upgrading to a new Broker
VM image, see Migrating to a New Broker VM Image.

1. Select Settings → Configurations → Data Broker → Broker VMs.

2. In either the Brokers or Clusters tab, locate your Broker VM, right-click, and select Upgrade Broker version.

Upgrading your Broker VM takes approximately 5 minutes.

IMPORTANT:

After a Broker VM upgrade, your broker may require a reboot to finish installing important updates. A notification about this will be sent to your Cortex
XSIAM console Notification Center.

6.1.3.8 | Import Broker VM Configuration

Abstract

Learn more about importing one Broker VM configuration to another.

IMPORTANT:

This option can only be used on Broker VMs with version 20.0 and later.

Importing Broker VM configurations allows you to copy, including applet settings, the configuration of one Broker VM to another Broker VM. The import
completely overrides the Broker VM settings and applet settings in the target Broker VM.

1. Right-click the Broker VM whose configurations you want to replace, and click Import Configuration.

2. Select the Broker VM whose configurations you want copied to this Broker VM.

3. (Optional) You can shutdown the Broker VM, whose configurations are being copied to avoid conflicts in data collection and applets operation, once the
import is complete and the new configurations are applied to the target Broker VM (default configuration).

4. Select the confirmation checkbox.

5. Click Import.

After a successful import, the new configurations are immediately applied to the target Broker VM.

IMPORTANT:

If your source Broker VM configuration includes a WEC applet, you'll need to ensure that you update the DNS record of this Broker VM's FQDN to point
to the target Broker VM IP address.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 553/1003
5/8/24, 9:18 AM PDF Export

6.1.3.9 | Open a Live Terminal

Abstract

Learn more about remotely connecting to a Cortex XSIAM Broker VM.

Cortex XSIAM enables you to remotely connect to a Broker VM directly from the Cortex XSIAM console.

1. In Cortex XSIAM, select Settings → Configurations → Data Broker → Broker VMs table.

2. Locate the Broker VM you want to connect to, right-click and select Open Live Terminal.

Cortex XSIAM opens a CLI window where you can perform the following commands:

Logs

Broker VM logs located are located in /data/logs/ folder and contain the applet name in file name. For example, folder /data/logs/[applet
name]/data/logs/[applet name], containing c

Ubuntu commands

Cortex XSIAM Broker VM supports all Ubuntu commands. For example, telnet 10.0.0.10 80 or ifconfig -a.

Sudo commands

Broker VM supports the command listed in the following table. All the commands are located in the /home/admin/sbin/home/admin/sbin folder.

Cortex XSIAM requires you use the following values when running commands:

Applet Names

CSV Collector—file_collector

Database Collector—db_collector

Files and Folders Collector—log_collector

FTP Collector— ftp_collector

Kafka Collector—kafka_collector

Local Agent Settings—tms_proxy

NetFlow Collector—netflow_collector

Network Mapper—network_mapper

Pathfinder—odysseus

Syslog Collector—anubis

Windows Event Collector—wec

Services

Upgrade—zenith_upgrade

Frontend service—webui

Sync with Cortex XSIAM —cloud_sync

Internal messaging service (RabbitMQ)—rabbitmq-server

Upload metrics to Cortex XSIAM —metrics_uploader

Prometheus node exporter—node_exporter

Backend service—backend

The following table displays the available commands in alphabetical order.

Read more...

Command Description Example

applets_restart Restarts one or more applets. sudo ./applets_restart wec

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 554/1003
5/8/24, 9:18 AM PDF Export

Command Description Example

applets_start Start one or more applets. sudo ./applets_start wec

applets_status Check the status of one or more applets. sudo ./applets_status wec

applets_stop Stop one or more applets. sudo ./applets_stop wec

hostnamectl Check and update the machine hostname on a sudo ./hostnamectl set-hostname
Linux operating system. <new_host_name>

Restart machine after running command.

kill Linux kill command. sudo ./kill [some pid]

restart_routes Invoke a restart of the routing service after sudo ./restart_routes

updating your static network route configuration
file, /etc/network/routes. NOTE:

You can either restart_routes or reboot

The /etc/network/routes configuration file is the Broker VM for the changes in the
a standard Ubuntu routes configuration file and /etc/network/routes file to take affect.
can be edited directly. The admin user that you
logged in with, when using the remote terminal
or via SSH, has read/write permissions to this
file.

route Modify your IP address routing. sudo ./route

services_restart Restarts one or more services. OS services are sudo ./services_restart cloud_sync
not supported.

services_start Start one or more services sudo ./services_start cloud_sync

services_status Check the status of one or more services. sudo ./services_status cloud_sync

services_stop Stop one or more services. sudo ./services_restart cloud_sync

set_ui_password.sh Change the password of the Broker VM Web sudo ./set_ui_password.sh

UI.

Run the command, enter the new password

followed by Ctrl+D.

squid_tail Display the Proxy applet Squid log file in real- sudo ./squid_tail
time.

tcpdump Linux capture network traffic command. sudo ./tcpdump -i eth0 -w

/tmp/packets.pcap
You must use -w flag in order to print output to
file.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 555/1003
5/8/24, 9:18 AM PDF Export

6.1.3.10 | Remove a Broker VM

Abstract

You can remove any Broker VM that is no longer needed.

Cortex XSIAM allows you to remove a Broker VM directly from both the Brokers tab and Clusters tab of the Broker VMs page.

When you remove a Broker VM node that is added to high availability (HA) cluster, the Broker VM is also removed from the cluster on the tenant.

1. Select Settings → Configurations → Data Broker → Broker VMs.

2. In either the Brokers tab or Clusters tab, locate your Broker VM, right-click, and select Remove Broker.

6.1.3.11 | Add Broker VM to Cluster

Abstract

Learn more about adding a Broker VM to a high availability cluster.

You can add standalone Broker VMs to a high availability (HA) cluster from both the Brokers tab and Clusters tab of the Broker VMs page.

You can only add a Broker VM to a cluster, when the Broker VM version is 19.0 and later, the STATUS is Connected, and the Broker VM version isn't older than
the cluster version.

Once you add a Broker VM to a cluster, the Broker VM becomes a cluster node and is added to the cluster folder in the Clusters tab. If it is the only peer Broker
VM in the cluster, it is designated as the Primary node; otherwise, it is designated as a standby node.

1. Select Settings → Configurations → Data Broker → Broker VMs.

2. Determine from which tab on the Broker VMs page that you want to add a Broker VM to a cluster:

Brokers tab

1. Right-click a standalone Broker VM, and select Add Broker to Cluster.

2. In the Select Cluster field, choose the cluster that you want this Broker VM to be added to.

Clusters tab

1. Right-click a cluster node, and select Add Broker to Cluster.

2. In the Select broker field, choose the standalone Broker VM that you want to add to this cluster.

3. Click Add Broker.

Adding a Broker VM to a cluster overrides all previous Broker VM settings and disables all active applets on this Broker VM. When the Broker VM is
added to a cluster, the cluster configuration and cluster applet settings propogate to the Broker VM. The state of the applets on the Broker VM is
dependent on the applet mode and Broker VM node role in the cluster. When the operation completes, a notification is added to the Notification Center.

6.1.3.12 | Switchover Primary Node in Cluster

Abstract

Learning more about changing the role of the current Primary node in a HA cluster.

You can manually change the role of the current Primary node in a high availability (HA) cluster from both the Brokers tab and Clusters tab of the Broker VMs
page.

There are various reasons for changing the role of the current Primary node to another node in the HA cluster, for example, to perform maintenance, by initiating
a manual switchover.

The option is only available for a Primary node, and only if there is another available standby node that is connected in the cluster.

1. Select Settings → Configurations → Data Broker → Broker VMs.

2. In either the Brokers tab or Clusters tab, right-click a Primary Broker VM node, and select Switchover.

3. If multiple standby nodes are connected in the cluster, select the node that you want to change to Primary in the Select broker menu. When only one
standby node is configured, skip this step.

4. Click Switchover.

When the switchover is completed, the roles of the node are switched. The new node is designated as Primary and the old node becomes a standby
node. In addition, a notification is added to the Notification Center.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 556/1003
5/8/24, 9:18 AM PDF Export

6.1.3.13 | Remove from Cluster

Abstract

Learn more about removing a Broker VM node from a high availability cluster.

You can remove a Broker VM node from a high availability (HA) cluster in either the Brokers tab or Clusters tab of the Broker VMs page. This option is only
available if the Broker VM is currently a member of a cluster.

When a Broker VM node is removed from a HA cluster, it becomes a standalone Broker VM. All its configuration settings, including applet settings, are reset to
default like a newly created Broker VM. If you remove a Primary node, an automatic failover occurs.

You can remove a Broker VM node from a cluster if the current node STATUS is Connected.

1. Select Settings → Configurations → Data Broker → Broker VMs.

2. In either the Brokers tab or Clusters tab, right-click a Broker VM node, and select Remove from Cluster.

3. Follow the instructions in the dialog box, and click Remove.

When removing the last node in the cluster, all applets in this cluster become Inactive, and the cluster becomes Unavailable.

When the Broker VM receives the new configuration, the Broker VM becomes a standalone Broker VM with settings reset to default.

NOTE:

If you've enabled a Load Balancer Health-Check on the cluster, you need to exclude this Broker VM from your Load Balancer settings.

6.1.4 | Broker VM High Availability Cluster

Abstract

Learn more about creating Broker VMs in a High Availability Cluster

High availability (HA) is a deployment in which at least two Broker VMs are placed in a Broker VM cluster and their configuration is synchronized to prevent a
single point of failure on your network at the hardware and application level. A heartbeat connection between the Broker VM nodes and the Cortex XSIAM
Server ensures seamless failover if a node fails. Setting up a HA cluster provides redundancy and enables data collection continuity.

Cluster Architecture

The Clusters tab on the Broker VMs page enables you to view your cluster configurations, which displays the associated nodes, node statuses, applets
configured, and applet statuses. You can add as many clusters as you want in a tenant. Each Cortex XSIAM cluster can include as many nodes as you need.
The cluster operation is fully managed from the tenant, and there is no need to install additional components. There is no need for cluster nodes to communicate
with one another on the network. In each cluster, one Broker VM is designated as the Primary cluster node and the rest of the nodes are designated as standby
nodes. The cluster architecture is dependent on the type of applets configured in the cluster. Applets on cluster nodes run either in the active/active mode or in
the active/passive mode and exhibit different behaviors as detailed in the table below.

NOTE:

With Cortex XDR Prevent, it's only relevant to configure a HA cluster with a Local Agent Settings applet as this is the only applet supported for this product
license. The other applets are collector applets, which are only available in Cortex XDR Pro or Cortex XSIAM.

Read more...

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 557/1003
5/8/24, 9:18 AM PDF Export

Applet Mode Applet Behavior Applets

active/active The applets that operate in the active/active mode run simultaneously on all the nodes in the cluster to achieve The active/active
High Availability and Load Balancing. Failure of an applet on a particular node causes all traffic to be redistributed applets are:
to the remaining nodes in the HA cluster.
Syslog
NOTE: Collector

For load balancing, you must install a Load Balancer in your network which will distribute the incoming data Netflow
between the nodes.
Collector

Windows
Event
Collector

Local Agent
Settings

active/passive The applets that operate in the active/passive mode run only on the Primary node designated in the cluster. The The active/passive
other nodes are synchronized and ready to transition from standby to the active Primary node should there be a applets are:
failover. In this mode, all nodes share the same configuration settings, while only 1 operates at a given time.
Kafka
Collector

Network
Mapper

CSV Collector

FTP Collector

Files and
Folders
Collector

DB Collector

NOTE:

The Pathfinder applet isn't supported when configuring Broker VMs in HA clusters.

Automatic Failover

In each cluster, whenever there's a failure on the Primary node, Cortex XSIAM automatically switches to one of the standby nodes, initiates the applets on the
new Primary node, and continues data collection on that node. Any successful or unsuccessful failover attempt displays an alert in the notification area and is
logged in the Management Audit Logs table.

The following conditions can trigger a failover for the Primary node:

Connectivity issues between a Primary node and the Cortex XSIAM server.

Application failure, such as failing to start an applet or an applet crashes.

Any failure of one of the internal components, such as MariaDB, Redis, RabbitMQ, or Docker engine.

Hardware failure, including:

Running out of disk space

CPU usage of more than 95% for more than 10 minutes

Memory usage of more than 95% for more than 10 minutes

Manual Switchover

At any time, you can change the role of the current Primary node in the cluster to another node in the HA cluster, for example, to perform maintenance, by
initiating a manual switchover.

Automatic Upgrades

You can configure automatic upgrades within Broker VM HA cluster nodes to update cluster nodes without noticeable down-time or other disruption of the HA
cluster service by implementing the rolling upgrade mechanism. An automatic upgrade is performed in the following order:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 558/1003
5/8/24, 9:18 AM PDF Export

1. Standby nodes are upgraded one by one.

2. The Primary node is switched over to one of the upgraded standby nodes.

3. The previous Primary node, now a standby node, is upgraded.

6.1.4.1 | Configure a High Availability Cluster

Abstract

Learn how to configure a High Availablity Cluster.

You can create a High Availability (HA) cluster by either creating a new cluster from scratch and then adding applets and Broker VM nodes to the cluster, or by
creating a new cluster from an existing standalone Broker VM. There is no limit to the number of clusters and nodes that you can add.

There are a number of different ways that you can configure the HA cluster to acheive fault tolerance depending on your system requirements. For example,
once a cluster is created from scratch, you can start by configuring the applets that you want the cluster to maintain and then adding the Broker VM nodes that
will be managed by the cluster to maintain this configuration, or vise versa. When you create a new cluster from an existing Broker VM, the cluster inherits the
applets already configured, which can help save time with your cluster configuration.

For the cluster to start working and provide services, you need at least one operational node. Until this node is added, the cluster is unavailable. Once a node is
added, the cluster begins operating, but it's not considered healthy. For the cluster to be healthy and maintain HA and redundancy, you need at least two
working nodes in the cluster.

For "active/active" applets that require load balancing, you must install a Load Balancer in your network to distribute the incoming data between the nodes.

PREREQUISITE:

Be sure you do the following tasks before creating a cluster from an existing Broker VM:

Since the Pathfinder applet isn't supported when configuring HA clusters, you must ensure Pathfinder is deactivated on the Broker VM.

If the Broker VM is explicitly specified in some Agent Settings profile, which mean Cortex XSIAM agents retrieve release upgrades and content updates
from this Broker VM, you must change the Broker VM's current designated role. To do this, you need to modify the Agent Settings profile by removing
the specific selection of this broker as a Download Source for XDR agents (Endpoints → Policy Management → Prevention → Profiles → Edit Profile →
Download Source → Broker Selection). After you create the cluster for this broker, you can go back the Agent Settings profile and select the cluster that
you created from this broker to be used as a Download Source for XDR agents.

Perform the following procedures in the order listed below.

Task 1. Open the Broker VMs page in Cortex XSIAM

Select Settings → Configurations → Data Broker → Broker VMs.

Task 2. Determine how you want to create an HA cluster

To create a cluster and then add Broker VMs to the cluster, click Add Cluster.

To create a new cluster from an existing Broker VM in the Brokers tab, right-click a standalone Broker VM, and click Create a Cluster from this Broker.

IMPORTANT:

You can only create a new custer from an existing Broker VM, when the Broker VM version is 19.0 and later, and the STATUS is Connected.

The Create a Cluster from this Broker option is only listed if the Broker VM is not already added to a cluster.

Task 3. Set the applicable parameters

Define the following parameters:

Load Balancer FQDN

Specify the domain name of your Load Balancer FQDN as configured in your local DNS server. The Load Balancer FQDN settings affect the Windows Event
Collector and Local Agent Settings applets.

When creating a cluster from an existing Broker VM and either a WEC or Local Agent Settings applet are enabled in the Broker VM, the Load Balancer FQDN is
mandatory to configure, and is automatically populated based on the Broker VM settings.

Load Balancer Health Check options

Implementing a Load Balancer requires exposing a health check API that is called by the Load Balancer at regular intervals. You can access the health check
page by sending an HTTP request to http[s]://<Broker VM IP>:<port>/health/. A successful HTTP response of 200 OK as the status code indicates the
Broker VM’s readiness to receive logs.

Disabled/Enabled toggle

When Disabled the Load Balancer Health Check listening port is blocked. When Enabled (default), the listening port is opened, and you must define the Port
number (default 8088) and Protocol (default HTTP).

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 559/1003
5/8/24, 9:18 AM PDF Export

IMPORTANT:

When the Protocol is set to HTTPS, you may need to perform a few follow-up steps to establish a validated secure SSL connection with the Broker VM.

If you're using your own Certificate Authority (CA) to sign the certificates, you'll need to place the CA in the client, such as the Load Balancer, and
upload the certificates to the Broker VM.

If you're using a Trusted CA Signed SSL Certificate, you'll only need to upload it to the Broker VM.

If the SSL Server Certificates of the Broker VM are self-signed certificates, no further steps are necessary.
Auto Upgrade options

You can configure automatic upgrades within Broker VM HA cluster nodes to update cluster nodes without noticeable down-time or other disruption of the HA
cluster service by implementing the rolling upgrade mechanism. Setting automatic upgrades includes these parameters:

Auto Upgrade

In a HA cluster configuration, the rolling upgrades process is automatically performed by default whenever a new version of the Broker VM is available.

If you want to upgrade the Broker VM nodes manually, clear the Use Default (Enabled) checkbox, and set Auto Upgrade to Disabled. You can manually upgrade
the Broker VM nodes individually by right-clicking the Broker VM and selecting Upgrade Broker version.

Days In Week

You can configure the days in the week that the rolling upgrades are performed. By default, the upgrades are configured to run every day.

Schedule

You can configure whether the rolling upgrades are performed at any time during the day or at a specific time by setting a time range of at least 4 hours.

Once configured, the rolling upgrades are only performed when the cluster STATUS is Healthy. An automatic upgrade is performed in the following order:

Read more...

1. Standby nodes are upgraded one by one.

2. The Primary node is switched over to one of the upgraded standby nodes.

3. The previous Primary node, now a standby node, is upgraded.

Task 4. Save your changes

Click Save.

The cluster is now listed in the Clusters tab of the Broker VMs page, whose output differs depending on how the cluster was created:

New cluster added

When the cluster is added from scratch, the cluster is listed as an empty folder, and you can start to add Broker VM nodes and applets to this cluster. While the
cluster doesn’t have any peer nodes, the STATUS is Unavailable.

Cluster added from an existing Broker VM

When the cluster is added from an existing Broker VM, the cluster inherits all applet settings from the Broker VM. You can leave the configuration as is or
add/remove additional applets as desired. This node automatically becomes the first node (Primary) in the cluster. You can now add other Broker VM nodes to
this HA cluster. While the cluster contains only one Broker VM node, the STATUS is Warning.

Task 5. Add Broker VMs to your cluster as you require to achieve fault tolerance and high availability

For the cluster to be healthy and maintain HA and redundancy, you need at least two working nodes in the cluster.

To add Broker VM, see Add Broker VM to Cluster.

To add applets, see Add an Applet to a Cluster.

6.1.4.2 | Manage Broker VM Clusters

Abstract

Learn more about managing your broker VM clusters from the Clusters tab of the Broker VMs page.

After you've configured a cluster, you can manage all your Broker VM clusters from the Clusters tab on the Broker VMs page (Settings → Configurations →
Data Broker → Broker VMs → Clusters) .

The Clusters tab displays in a heirarchical view the clusters with their nodes, performance stats, applets configured, and the state of each applet. You can right-
click any cluster to open a menu listing the tasks available management options.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 560/1003
5/8/24, 9:18 AM PDF Export

6.1.4.2.1 | View Cluster Details

Abstract

Learn more about viewing the details of any particular cluster.

The Clusters tab of the Broker VMs page (Settings → Configurations → Data Broker → Broker VMs) enables you to view detailed information regarding your
High Availablilty (HA) cluster.

The Clusters table enables you to monitor and mange your cluster nodes and applets, and view stats.

In addition, when each cluster is expanded, a table is displayed, which enables you to view detailed information regarding the various Broker VM nodes that are
currently added to your cluster. If you haven't added any Broker VM nodes to a particular cluster, the table is empty.

Clusters Table

The following table describes all the fields that are available in the Clusters table. You can hide any field column using the column manager.

Clusters Table Columns

Fields Description

CLUSTER Beside the full name of each cluster, a status indicator is displayed with one of the following colors:
NAME
Green

Healthy, the Primary node and all available standby nodes are connected and operating with no warnings, and all activated applets are
running without a problem.

Orange

Warning as the system has detected errors in the cluster, but the applets can still be running. For example, all applets are running normally
in the Primary Broker VM, but no available standby nodes are detected, or the Primary node is operating fine, but there is an applet that
failed to start in one of the standby nodes. The errors must be addressed as soon as possible.

Red

Critical as the system has detected one or more critical errors in the cluster, and nodes are not able to run some applets. For example, an
error was detected in some Primary applet and no standby node is available for failover. All errors must be addressed as soon as possible.

Black

Unavailable as the cluster doesn’t have any peer nodes configured.

STATUS Connection status of the cluster according to the statuses and colors explained in the CLUSTER NAME field above.

Unavailable clusters do not display CPU USAGE, MEMORY USAGE, and DISK USAGE information.

Notifications about the cluster losing connection between applets and Broker VM nodes appear in the Notification Center.

CPU USAGE Average CPU utilization between all nodes in the cluster as a percentage.

MEMORY Sum of all memory in use out of the sum of the total memory on all nodes in the cluster as a percentage.
USAGE

DISK Sum of all disk space in use out of the sum of the total disk space on all nodes in the cluster as a percentage.
USAGE

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 561/1003
5/8/24, 9:18 AM PDF Export

Fields Description

APPS List of active applets and the connectivity status for each.

Colors depict the following statuses:

Green

Connected

Red

Connection Failed or Error

White

Inactive

Cluster Broker VM Nodes Table

The fields that are available in the Broker VM nodes table for each cluster are similar to many of the fields that are displayed in the table for the Broker VMs in
the Brokers tab. For more information on these fields, see View Broker VM Details.

6.1.4.2.2 | Edit a Cluster

Abstract

Learn how to edit a High Availability cluster.

After configuring a high availability (HA) cluster, you can always edit the cluster configurations from the Clusters tab of the Broker VMs page.

A HA cluster is always configurable no matter what the status of the cluster or whether it has any Broker VM nodes added or not.

1. Select Settings → Configurations → Data Broker → Broker VMs, and select the Clusters tab.

2. In the Clusters table, locate the cluster, right-click, and select Configure.

3. In the Cluster Configurations window, you can edit the parameters based on your previous settings when you configured the HA cluster. For more
information on each of these settings, see Configure a High Availability Cluster.

4. Update the cluster with your changes.

The Cluster table is updated with the changes.

6.1.4.2.3 | Add an Applet to a Cluster

Abstract

Learn more about adding an applet to a High Availability cluster.

You can add an applet to a high availability (HA) cluster from the Clusters tab of the Brokers VM page.

You can always add an applet to a cluster, even if the cluster status is Unavailable or Error. When an applet is added to a cluster without any Broker VM nodes,
the cluster status is Unavailable and the cluster APPS status displays as Inactive.

1. Select Settings → Configurations → Data Broker → Broker VMs, and select the Clusters tab.

2. In the Clusters table, locate the cluster that you want to add an applet.

3. You can either right-click the cluster, and select Add App → <name of applet>, or in the APPS column, left-click Add → <name of applet>.

The applet is only available for you to add to the cluster if it hasn't already been added.

NOTE:

With Cortex XDR Prevent, it's only relevant to configure a HA cluster with a Local Agent Settings applet as this is the only applet supported for this
product license. The other applets are collector applets, which are only available in Cortex XDR Pro or Cortex XSIAM.

4. Configure your applet.

The various applets that you can configure are the same as when configuring a standalone Broker VM. For more information on a particular applet
configuration, locate the applet in the Set up Broker VM section, and follow the applicable instructions for configuring the applet parameters.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 562/1003
5/8/24, 9:18 AM PDF Export

The applet is listed with a status indicator in the APPS column, where the colors depict the following statuses.

Green

Connected

Red

Connection Failed or Error

White

Inactive

Once the applet configuration is changed in a cluster, the changes are automatically applied to the cluster nodes depending on the applet and cluster
node role. For example, if you add the Kafka Collector, which is an "active/passive" applet, the applet is automatically initiated and enters an active state
on the Primary node and is on standby on the standby nodes. While if you add the Syslog Collector "active/active" applet, the changes automatically
propogate so that the applet is active on all cluster nodes, including Primary and standby.

6.1.4.2.4 | Add Broker VM to Cluster

Abstract

Learn more about adding a Broker VM to a high availability cluster.

You can add standalone Broker VMs to a high availability (HA) cluster from both the Brokers tab and Clusters tab of the Broker VMs page.

You can only add a Broker VM to a cluster, when the Broker VM version is 19.0 and later, the STATUS is Connected, and the Broker VM version isn't older than
the cluster version.

Once you add a Broker VM to a cluster, the Broker VM becomes a cluster node and is added to the cluster folder in the Clusters tab. If it is the only peer Broker
VM in the cluster, it is designated as the Primary node; otherwise, it is designated as a standby node.

1. Select Settings → Configurations → Data Broker → Broker VMs.

2. Determine from which tab on the Broker VMs page that you want to add a Broker VM to a cluster:

Brokers tab

1. Right-click a standalone Broker VM, and select Add Broker to Cluster.

2. In the Select Cluster field, choose the cluster that you want this Broker VM to be added to.

Clusters tab

1. Right-click a cluster node, and select Add Broker to Cluster.

2. In the Select broker field, choose the standalone Broker VM that you want to add to this cluster.

3. Click Add Broker.

Adding a Broker VM to a cluster overrides all previous Broker VM settings and disables all active applets on this Broker VM. When the Broker VM is
added to a cluster, the cluster configuration and cluster applet settings propogate to the Broker VM. The state of the applets on the Broker VM is
dependent on the applet mode and Broker VM node role in the cluster. When the operation completes, a notification is added to the Notification Center.

6.1.4.2.5 | Remove a Cluster

Abstract

Learn more about removing a high availability cluster.

You can remove a high availability (HA) cluster in the Clusters tab of the Broker VMs page.

When removing a cluster, the cluster is disassembled and the cluster object is deleted. All nodes in the cluster are reverted back to standalone Broker VMs with
their settings reset to default as a newly created Broker VMs.

If you've configured load balancing for any "active/active" applets configured, you need to update your Load Balancer configuration settings to stop sending logs
to these Broker VM nodes.

You cannot remove a cluster that is used as a download source from which the Cortex XSIAM agents retrieve release upgrades and content updates. You'll
need to change the cluster's current designated role before removing a cluster.

1. Select Settings → Configurations → Data Broker → Broker VMs.

2. In the Clusters tab, right-click a cluster, and select Remove Cluster.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 563/1003
5/8/24, 9:18 AM PDF Export

3. Follow the instructions in the REMOVE CLUSTER window, whose instructions differ depending on the type of cluster you are trying to remove, and
Remove the cluster.

6.1.5 | Broker VM Notifications

Abstract

Learn about the notifications that are relevant to Cortex XSIAM Broker VMs.

To help you monitor effectively your Broker VM version, connectivity, and high availability clusters, Cortex XSIAM sends notifications to your Cortex XSIAM
console Notification Center.

Cortex XSIAM sends the following notifications:

Add Cluster

Notifies when a cluster was added.

Applet Activated

Notifies when an applet is activated on a cluster.

Applet configuration

Notifies when an applet on a cluster configuration was updated.

Applet Deactivated

Notifies when an applet is deactivates on a cluster.

Broker VM Connectivity

Notifies when the Broker VM has lost connectivity to Cortex XSIAM .

Broker VM Disk Usage

Notifies when the Broker VM is utilizing over 90% of the allocated disk space.

Cluster Configuration

Notifies when a Broker VM node was added to a cluster.

Notifies when a Broker VM node was removed from a cluster.

Notifies when the configuration for the cluster needs to be set.

Cluster failover

Notifies when a failover is initiated in the cluster from one Broker VM node to another.

Notifies when a failover completed successfully. The Broker VM is now Primary in the cluster.

Notifies when a failover in the cluster completed with errors and error message.

Notifies when couldn't perform a failover in the cluster as there is no available standby node with sufficient redundancy.

Cluster health declined

Notifies when failed to detect an available standby Broker VM node in the cluster.

Notifies when critical errors detected in the cluster and there is no available standby Broker VM node for failover.

Cluster health recovered

Notifies when detected an available standby Broker VM node in the cluster.

<name of broker> Broker VM requires a reboot

Notifies after a Broker VM update whether a broker needs a reboot to finish installing important updates.

New Broker VM Version

Notifies when a new Broker VM version has been released.

If the Broker VM Auto Upgrade is disabled, the notification includes a link to the latest release information. It is recommend you upgrade to the latest
version.

If the Broker VM Auto Upgrade is enabled, 12 hours after the release you are notified of the latest upgrade, or you are notified that the upgrade failed. In
such a case, open a Palo Alto Networks Support Ticket.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 564/1003
5/8/24, 9:18 AM PDF Export

Reinstall Broker VM <Broker VM name> with a new image

For all brokers that were deployed with an old Broker VM image, downloaded prior to July 9th, 2023 (installed with Ubuntu 18.04 or earlier), the Broker VM must
be reinstalled with a new image (installed with Ubuntu 20.04 or later) before upgrading to the latest version. The name of the Broker VM to upgrade is indicated
with a link to the instructions.

NOTE:

For more information on upgrading to a new Broker VM image, see Migrating to a New Broker VM Image.

Remove Cluster

Notifies when a cluster was removed.

To ensure you and your colleagues stay informed about Broker VM activity, you can also Configure Notification Forwarding to forward your Broker audit logs to
an email distribution list or Syslog server. For more information about the Broker VM audit logs, see Monitor Broker VM Activity.

7 | XDR Collectors
Abstract

Learn how XDR Collectors can be used for on-premise data collection on Windows and Linux machines.

NOTE:

Ingestion of logs larger than 5 MB is not supported.

Cortex XSIAM provides an XDR Collectors configuration that is dedicated for on-premise data collection on Windows and Linux machines. The XDR collector
includes a dedicated installer, a collector upgrade configuration, content updates, and policy management.

7.1 | XDR Collector Audit Logs

Abstract

Learn more about XDR Collector audit logs.

Cortex XSIAM logs entries for events related to the XDR Collector monitored activities. Cortex XSIAM stores the logs for 365 days. To view the XDR Collector
audit logs, select Settings → XDR Collector Audit Logs.

7.2 | XDR Collector Machine Requirements and Supported Operating Systems

Abstract

Lists the supported operating systems and requirements for the collector machines for configuring the Cortex XDR Collectors.

You can configure XDR Collectors that are dedicated for on-premise data collection on Windows and Linux machines. The following hardware and software
specifications are required for the collector machines.

Machine Operating System Requirement Specifications

Linux Processor 2.3 GHz dual-core

RAM 4GB; 8GB recommended

Hard disk space 10GB

Architecture x86 64-bit

Kernel version 2.6.32

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 565/1003
5/8/24, 9:18 AM PDF Export

Machine Operating System Requirement Specifications

Supported operating system versions Red Hat Enterprise Linux 6 (6.7 and later)

Red Hat Enterprise Linux 7

Red Hat Enterprise Linux 8

Red Hat Enterprise Linux 9

SUSE Linux Enterprise Server 12

SUSE Linux Enterprise Server 15 SP0

SUSE Linux Enterprise Server 15 SP1

SUSE Linux Enterprise Server 15 SP2

Ubuntu Server 12

Ubuntu Server 14

Ubuntu Server 16

Ubuntu Server 18

Ubuntu Server 20

Ubuntu Server 22

Oracle Linux 6 (6.7 and later)

Oracle Linux 7

Oracle Linux 8

Oracle Linux 9

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 566/1003
5/8/24, 9:18 AM PDF Export

Machine Operating System Requirement Specifications

Software packages Verify you have standard Unix programs

installed.

ca-certificates

openssl 1.0.0 or a later release

Distributions with SELinux in enforcing or

permissive mode:

Red Hat Enterprise Linux 6, CentOS

6, and Oracle Linux 6—
policycoreutils-python

Red Hat Enterprise Linux 7, CentOS

7, and Oracle Linux 7—
policycoreutils-python and selinux-
policy-devel

SUSE—policycoreutils-python and
selinux-policy-devel

Debian and Ubuntu—policycoreutils

and selinux-policy-dev

CentOS 6.10—Enable the dynamic CA

instead of the legacy CA:

1. Enable the dynamic CA

configuration: update-ca-trust
force-enable

2. Import the certificates: cp XDR-

certificate.crt /etc/pki/ca-
trust/source/anchors/.

3. Rebuild the certificate database:

update-ca-trust extract

Networking Allow communication from the XDR

Collector TCP port to the server (the
default is port 443).

Windows Processor Intel Pentium 4 or later with SSE2

instruction set support

AMD Opteron/Athlon 64 or later with SSE2

instruction set support

Dual core processor (minimum)

RAM 2GB minimum

Hard disk space 200MB minimum; 20GB recommended

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 567/1003
5/8/24, 9:18 AM PDF Export

Machine Operating System Requirement Specifications

Supported operating system versions Windows Azure Virtual Desktop (WVD or

AVD)

Windows 7

Windows 7 SP1 (All editions except

Home)

Embedded Standard 7 SP1

Embedded POSReady 7 (Based on

Windows 7 SP1)

Windows 8

8.1 (and with FIPS mode)

Embedded 8.1 Professional

(Supported until January 2023)

Windows 10

Education

Pro (CB and CBB)

Enterprise (CB, CBB, and LTSB)

Updates 21H2, 21H1, 20H2, 2004,

1709, 1909, 1903, 1809, 1803
(Enterprise and Professional)

Updates 22H2, 22H1

Enterprise 2019 LTSC

Windows 10 IoT Core

Windows 10 IoT Enterprise

Windows 11

Windows 11

Updates 22H2, 22H1

Pro/Pro Education/Pro Workstations

Enterprise

Education/Home

IoT Enterprise

Windows Server

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 568/1003
5/8/24, 9:18 AM PDF Export

Machine Operating System Requirement Specifications

Datacenter

2008 R2 SP1

2012 (Supported until October 2026),

2012 R2 (Supported until January
2026), All editions; FIPS mode

2016 (Standard edition; Server with

Desktop experience, previously
known as Server with a GUI)

2016 Datacenter edition

2019

Core option (Windows Server 2012,

2012 R2, and 2016 only)

2019 Standard (Server Core)

2022

Networking Allow communication from the XDR

Collector TCP port to the server (the
default is port 443).

Applications and utilities Windows Accessories (Notepad) to view

logs

7.3 | Resources Required to Enable Access to XDR Collectors

Abstract

Depending on your network environment settings, you should enable network access to the Cortex XDR Collectors resources.

To enable access to XDR Collectors components, you must allow access to various Palo Alto Networks resources. If you use the specific Palo Alto Networks
App-IDs indicated in the table, you do not need to explicitly allow access to the resource. A dash (—) indicates there is no App-ID coverage for a resource.

NOTE:

Some of the IP addresses required for access are registered in the United States. As a result, some GeoIP databases do not correctly pinpoint the location in
which IP addresses are used. All customer data is stored in your deployment region, regardless of the IP address registration and restricts data transmission
through any infrastructure to that region. For considerations, see Plan Your Deployment.

NOTE:

Throughout this topic, <xsiam-tenant> refers to the chosen subdomain of your Cortex XSIAM tenant and <region> is the region in which your Strata
Logging Service is deployed.

Refer to the following tables for the FQDNs, IP addresses, ports, and App-ID coverage for your deployment.

For IP address ranges in GCP, refer to the following tables for IP address coverage for your deployment.

https://www.gstatic.com/ipranges/goog.json—Refer to this list to look up and allow access to the IP address ranges subnets.

https://www.gstatic.com/ipranges/cloud.json—Refer to this list to look up and allow access to the IP address ranges associated with your region.

Table 3. Required Resources by Region

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 569/1003
5/8/24, 9:18 AM PDF Export

FQDN IP Addresses And Port App-ID Coverage

<xsiam-tenant>.xsiam. IP address by region: cortex-xdr

<region>.paloaltonetworks.com
US (United States)—35.244.250.18
Used to connect to the Cortex XSIAM management
EU (Europe)— 35.227.237.180
console.
CA (Canada)—34.120.31.199

UK (United Kingdom)— 34.120.87.77

JP (Japan)—35.241.28.254

SG (Singapore)— 34.117.211.129

AU (Australia)—34.120.229.65

DE (Germany)—34.98.68.183

IN (India)—35.186.207.80

CH (Switzerland)—34.111.6.153

PL (Poland)—34.117.240.208

TW (Taiwan)—34.160.28.41

QT (Qatar)—35.190.0.180

FA (France)—34.111.134.57

IL (Israel)—34.111.129.144

SA (Saudi Arabia)—35.244.157.127

ID (Indonesia)—34.111.58.152

Port—443

distributions.traps.paloaltonetworks.com IP address—35.223.6.69 traps-management-service

Used for the first request in registration flow where Port—443

the agent passes the distribution id and obtains the
ch- <xsiam-
tenant>.traps.paloaltonetworks.com of its
tenant

panw-xdr-installers-prod- IP ranges in GCP cortex-xdr

us.storage.googleapis.com
Port—443
Used to download installers for upgrade actions
from the server.

This storage bucket is used for all regions.

global-content-profiles- IP ranges in GCP cortex-xdr

policy.storage.googleapis.com
Port—443
Used to download content updates.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 570/1003
5/8/24, 9:18 AM PDF Export

FQDN IP Addresses And Port App-ID Coverage

ch- <xsiam- IP address by region: traps-management-service

tenant>.traps.paloaltonetworks.com
US (United States)—34.98.77.231
Used for all other requests between the agent and
EU (Europe)—34.102.140.103
its tenant server including heartbeat, uploads, action
results, and scan reports. CA (Canada)— 34.96.120.25

UK (United Kingdom)—35.244.133.254

JP (Japan)—34.95.66.187

SG (Singapore)—34.120.142.18

AU (Australia)—34.102.237.151

DE (Germany)—34.107.161.143

IN (India)—34.120.213.188

CH (Switzerland)—34.149.180.250

PL (Poland)—35.190.13.237

TW (Taiwan)—34.149.248.76

QT (Qatar)—34.107.129.254

FA (France)—34.36.155.211

IL (Israel)—34.128.157.130

SA (Saudi Arabia)—34.107.213.85

ID (Indonesia)—34.128.156.84

Port—443

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 571/1003
5/8/24, 9:18 AM PDF Export

FQDN IP Addresses And Port App-ID Coverage

api-<xdr-tenant>.xdr. IP address by region: —

<region>.paloaltonetworks.com
US (United States)—35.222.81.194
Used for API requests and responses.
EU (Europe)— 34.90.67.58

CA (Canada)—35.203.82.121

UK (United Kingdom)— 34.89.56.78

JP (Japan)—34.84.125.129

SG (Singapore)—34.87.83.144

AU (Australia)—35.189.18.208

DE (Germany)—34.107.57.23

IN (India)—35.200.158.164

CH (Switzerland)—34.65.248.119

PL (Poland)—34.116.216.55

TW (Taiwan)—35.234.8.249

QT (Qatar)—34.18.46.240

FA (France)—34.155.222.152

IL (Israel)—34.165.156.139

SA (Saudi Arabia)—34.166.58.79

ID (Indonesia)—34.128.115.238

Port—443

Log Forwarding to a Syslog Receiver

See Integrate a Syslog Receiver.

Table 4. Required Resources for Federal (United States - Government)

FQDN IP Addresses And Port App-ID Coverage Required For XDR Collectors

distributions-prod- IP address— traps-management-service

fed.traps.paloaltonetworks.com 104.198.132.24

Used for the first request in registration flow Port—443

where the agent passes the distribution ID and
obtains the ch- <xsiam-
tenant>.traps.paloaltonetworks.com of its
tenant

panw-xdr-installers-prod- IP ranges in GCP cortex-xdr

fr.storage.googleapis.com
Port—443
Used to download installers for upgrade actions
from the server.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 572/1003
5/8/24, 9:18 AM PDF Export

FQDN IP Addresses And Port App-ID Coverage Required For XDR Collectors

global-content-profiles-policy-prod- IP ranges in GCP cortex-xdr

fr.storage.googleapis.com
Port—443
Used to download content updates.

ch- <xsiam- IP address— traps-management-service

tenant>.traps.paloaltonetworks.com 130.211.195.231

Used for all other requests between the agent Port—443

and its tenant server including heartbeat,
uploads, action results, and scan reports.

api-<xdr- IP address— —
tenant>.xdr.federal.paloaltonetworks.com 130.211.195.231

Used for API requests and responses. Port—443

Log Forwarding to a Syslog Receiver

See Integrate a Syslog Receiver.

7.4 | Configure the XDR Collector Upgrade Scheduler

Abstract

You can configure the Cortex XDR Collector upgrade scheduler and the number of parallel upgrades.

You can configure the Cortex XDR Collector upgrade scheduler and the number of parallel upgrades. There can be a maximum of 500 parallel upgrades
scheduled in a week, which is the default configuration at any time of day.

To define the XDR Collector upgrade scheduler and number of parallel upgrades.

1. In Cortex XSIAM , select Settings → Configurations → XDR Collectors → Configurations.

2. Set the XDR Collectors Configurations settings.

Amount of Parallel Upgrades—Specify the number of parallel upgrades, where the maximum number is 500 (default).

Days in Week—Select the specific days in the week that you want the upgrade to occur, where the default is configured as every day in the week.

Schedule—Select whether you want the upgrade to be at Any time (default) or at a Specific time. When setting a specific time, you can set the From
and To times.

3. Click Save.

7.5 | Manage XDR Collectors

Abstract

Manage Cortex XSIAM collectors.

On the XDR Collectors Administration page, you can view the list of collectors and perform additional tasks such as, change the alias of the collector, upgrade
the collector version, and set a proxy address and port for the collector.

7.5.1 | Create an XDR Collector Installation Package

Abstract

Learn how to create an XDR Collector installation package for a Windows or Linux collector machine.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 573/1003
5/8/24, 9:18 AM PDF Export

To install a Cortex XDR Collector for the first time, you must first create an XDR Collector installation package. After you create and download an installation
package, you can then install it directly on the collector machine or you can use a software deployment tool of your choice to distribute the software to multiple
collector machines.

To install the XDR Collector software, you must use a valid installation package that exists in your XDR Collectors console. If you delete an installation package,
any XDR Collectors installed from this package are not able to register to Cortex XSIAM .

NOTE:

To move existing XDR Collectors between Cortex XSIAM managing servers, you need to first Uninstall the XDR Collector from the collector machine and then
for the new XDR Collector create a new installation package.

To create a new installation package.

1. In Cortex XSIAM, select Settings → Configurations → XDR Collectors → Installers.

2. Create a new installation package.

3. Enter a unique Name and an optional Description to identify the installation package.

The package Name must be no more than 100 characters and can contain letters, numbers, hyphens, underscores, commas, and spaces.

4. Select the Platform for which you want to create the installation package as either Windows or Linux.

5. Select the Version.

6. Create the installation package.

Cortex XSIAM prepares your installation package and makes it available in the XDR Collectors Installations page.

7. Download your installation package.

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

For a Windows installation, select between the architecture type for the msi file to download. You can Download 64 bit installer or Download 32 bit
installer.

For a Linux installation, you can Download Linux RPM installer or Download Linux DEB installer (according to your Linux collector machine
distribution), and deploy the installers on the on-premise collector machines using the Linux package manager. Alternatively, you can Download
Linux SH installer and deploy it manually on the Linux collector machine.

Once the applicable installation package is downloaded, you can install the package.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 574/1003
5/8/24, 9:18 AM PDF Export

Install the XDR Collector Installation Package for Windows.

Install the XDR Collector Installation Package for Linux.

8. Other available options.

As needed, you can return to the XDR Collectors Installations page to manage your XDR Collectors installation packages. To manage a specific package,
right click the Collector Version, and select the desired action:

Edit the package name or description.

Delete the installation package. Deleting an installation package does not uninstall the XDR Collector software from any on-premise collector
machines.

NOTE:

Since Cortex XSIAM relies on the installation package ID to approve XDR Collector registration during install, it is not recommended to delete the
installation package for any active on-premise collector machines. Hiding the installation package will remove it from the default list of available
installation packages, and can be useful to eliminate confusion in the XDR Collectors console main view. These hidden installation can be viewed
by removing the default filter.

Copy text to clipboard to copy the text from a specific field in the row of an installation package.

Hide installation packages. Using the Hide option provides a quick method to filter out results based on a specific value in the table. You can also
use the filters at the top of the page to build a filter from scratch. To create a persistent filter, save ( ) it.

7.5.2 | Install the XDR Collector Installation Package for Windows

Abstract

Learn about the Cortex XDR Collector installation options on Windows collector machines.

A standard XDR Collector installation for Windows is intended for standard physical collector machines or persistent virtual collector machines. You can perform
the Windows installation for the XDR Collectors using the MSI or Msiexec.

7.5.2.1 | Install the XDR Collector on Windows Using the MSI

Topic Not Found

7.5.2.2 | Install the XDR Collector on Windows Using Msiexec

Abstract

Learn how to install the Cortex XDR Collectors on Windows using the Msiexec.

Msiexec provides full control over the installation process and allows you to install, modify, and perform operations on a Windows Installer from the command
line interface (CLI). You can also use Msiexec to log any issues encountered during installation.

You can also use Msiexec in conjunction with a System Center Configuration Manager (SCCM), Altiris, Group Policy Object (GPO), or other MSI deployment
software to install the XDR Collector on multiple collector machines for the first time.

When you install the XDR Collector with Msiexec, you must install the XDR Collector per-machine and not per-user.

Although Msiexec supports additional options, the XDR Collectors installers support only the options listed here. For example, with Msiexec, the option to install
the software in a non-standard directory is not supported—you must use the default path.

The following parameters apply to the initial installation of the XDR Collector on the collector machine.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 575/1003
5/8/24, 9:18 AM PDF Export

/i <installer path>\<installer file name>.msi DATA_PATH=<Path> PROXY_LIST=<address or list> /quiet /l*v <installation log
path>—Installs a package quietly, changes data path, adds proxies, and creates an installation log.

For example, msiexec /i c:\install\XDRCollector-Win_x64.msi DATA_PATH=c:\data PROXY_LIST=2.2.2.2:8888,1.1.1.1:8080 /quiet

/l*v c:\installlog.txt

Where

LOG_LEVEL—Sets the level of logging for the XDR Collector log (INFO, DEBUG, ERROR, and TRACE).

LOG_MAX_BYTES—Sets the maximum log size in bytes.

LOG_BACKUP_COUNT—Number of cycling logs for the XDR Collector.

PROXY_LIST—Proxy address or name, where you can add a comma separated list, such as 2.2.2.2:8888,1.1.1.1:8080.

LOG_PATH—The path to save the XDR Collector, Filebeat, and Winlogbeat logs.

DATA_PATH—The path for persistence, content, Filebeat application data, Winlogbeat application data, and transaction data.

PROVISIONING_SERVER—Provisioning server address.

DISTRIBUTION_ID

ELB_ADDRESS—Load balancer for fresh XDR Collector installation.

Before completing this task, ensure that you create and download a Cortex XDR Collector installation package in Cortex XSIAM .

To install XDR Collectors using Msiexec:

1. Use one of the following methods to open a command prompt as an administrator.

Select Start → All Programs → Accessories. Right-click Command prompt and Run as administrator.

Select Start. In the Start Search box, type cmd. Then, to open the command prompt as an administrator, press CTRL+SHIFT+ENTER.

2. Run the msiexec command followed by one or more supported options and properties.

For example:

msiexec /i XDRCollector-Win_x64.msi DATA_PATH=c:\data PROXY_LIST=2.2.2.2:8888,1.1.1.1:8080 /quiet /l*v c:\installlog.txt

7.5.3 | Install the XDR Collector Installation Package for Linux

Abstract

Learn how to install the Cortex XDR Collector on Linux collector machines.

You can install the XDR Collector using three available packages for a Linux installation—Linux RPM, Linux DEB, and Linux SH. You can install the XDR
Collector package on any Linux server, including a physical or virtual machine, and as temporary sessions.

You can install XDR Collectors in any Linux server period, whether its a physical or virtual machine. Temporary sessions can be in either of them.

NOTE:

We recommend that you perform a Linux RPM or Linux DEB installation.

Before completing this task, ensure that you create and download a Cortex XDR Collector installation package, and then upload these installation files to your
Linux environment.

To install the XDR Collectors installation package for Linux.

1. Log on to the Linux server.

For example:

user@local ~
$
ssh [email protected]
Welcome to Ubuntu 16.04.3 LTS (GNU/Linux 4.4.0-1041-aws x86_64)

* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage

Get cloud support with Ubuntu Advantage Cloud Guest:

http://www.ubuntu.com/business/services/cloud

0 packages can be updated.

0 updates are security updates.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 576/1003
5/8/24, 9:18 AM PDF Export

Last login: Tue Aug 26 22:14:15 2021 from 192.168.1.100

2. Extract the installation files you uploaded using one of the following commands, which is dependent on the Linux package you downloaded:

Linux Package Extract Command

Linux RPM tar xvf <installation_package_name>.rpm

Linux DEB tar xvf <installation_package_name>.deb

Linux SH tar xvf <installation_package_name>.sh

3. Create a directory and copy the collector.conf installation file to the /etc/panw/ directory.

sudo mkdir -p /etc/panw

sudo cp ./collector.conf /etc/panw/

4. Install the XDR Collectors software.

You can install the XDR Collectors on the collector machine manually using the shell installer or using the Linux package manager for .rpm and .deb
installers.

To deploy using package manager:

1. Depending on your Linux distribution, install the XDR Collectors using one of the following commands, where the <file name> is taken from the
files provided in the downloaded Linux installation package:

Distribution Install Command

RHEL, CentOS, or Oracle yum install ./<file_name>.rpm

rpm -i ./<file_name>.rpm

Ubuntu or Debian apt-get install ./<file_name>.deb

dpkg -i ./<file_name>.deb

SUSE zypper install ./<file_name>.rpm

rpm -i ./<file_name>.rpm

2. Verify the XDR Collectors was installed on the collector machine.

Enter the following command on the collector machine:

dpkg -l | grep xdr-collector or rpm -qa | grep xdr-collector.

To deploy the shell installer:

a. Enable execution of the script using the chmod +x <file_name>.sh command, where the <file name> is taken from the file provided in the
downloaded Linux installation package.

b. Run the install script as root or with root permissions.

For example:

root@ubuntu:/home# chmod +x linux.sh

root@ubuntu:/home# ./linux.sh

Verifying archive integrity... All good.

Uncompressing XDR-Collector version 1.0.0.467 100%
Systemd: starting xdr-collector service
Synchronizing state of xdr-collector.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable xdr-collector

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 577/1003
5/8/24, 9:18 AM PDF Export

Created symlink /etc/systemd/system/multi-user.target.wants/xdr-collector.service→ /lib/systemd/system/xdr-collector.service.

Additional options are available to help you customize your installation if needed. The following table describes common options and parameters.

If you are using rpm or deb installers, you must also add these parameters to the /etc/panw/collector.conf file prior to installation.

Option Description

--proxy-list ”<proxyserver>:<port>” Proxy Communication

Configure the XDR Collector to communicate through an intermediary

such as a proxy.

To enable the XDR Collector to direct communication to an intermediary,

you use this installation option to assign the IP address and port number
you want the XDR Collector to use. You can also configure the proxy by
entering the FQDN and port number. When you enter the FQDN, you can
use both lowercase and uppercase letters. Avoid using special characters
or spaces.

Use commas to separate multiple addresses. For example:

--proxy-list "My.Network.Name:808, 10.196.20.244:8080"

After the initial installation, you can change the proxy settings from using
the configuration XML.

NOTE:

The XDR Collector does not support proxy communication in

environments where proxy authentication is required.

--data-path <directory path> Directory Path

The path for persistence, content, Filebeat application data, and

transaction data.

--data–path=/tmp/xdrLog

NOTE:

If the XDR Collector does not connect to Cortex XSIAM , verify your Internet connection on the collector machine. If the XDR Collector still does not
connect, verify the installation package has not been removed from the Cortex XSIAM management console.

7.5.4 | XDR Collectors Installation Resource for Windows and Linux

Abstract

Cortex XDR Collectors installation resource for Windows and Linux.

The following table provides valuable information about the XDR Collectors installation for Windows and Linux.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 578/1003
5/8/24, 9:18 AM PDF Export

Installation Component Default Path Description Related Files/Services

Installation folder Windows— The default installation path for the Windows
XDR Collector. Contains all Program
%PROGRAMFILES%\Palo Alto Service name—XDR
Core files and executables.
Networks\XDR Collector Collector

Linux— Process name—

xdrcollectorsvc.exe
/opt/paloaltonetworks/xdr-
collector Linux

Service name—xcd

Process name—xdr-
collector.service

Logs Windows— Windows—Contains the XDR Windows

Collector application Log, the
%PROGRAMDATA%\XDR Filebeat application log, and the scouter.log
Collector\logs Winlogbeat application log.
filebeat
Indicates information, warnings,
Linux—
and errors related to the XDR winlogbeat
/opt/paloaltonetworks/xdr- Collector application.
collector/logs Linux
Linux—Contains the XDR
Collector application Log as well scouter.log
as the Filebeat application log.
filebeat
Indicates information, warnings,
and errors related to the XDR
Collector application.

Contains the XDR Collector

application Log as well as the Filebeat
application log. Indicates information,
warnings, and errors related to the
XDR Collector application.

Configuration Windows— Contains the configuration file of the For both Windows and Linux, the file
XDR Collector for both Windows and name is XDR_Collector.xml.
%PROGRAMFILES%\Palo Alto Linux.
Networks\XDR Collector\config

Linux—

/opt/paloaltonetworks/xdr-
collector/config

Persistence Windows— Contains the Operating System For both Windows and Linux, the file
persistence file for the XDR Collector, name is .scouter.json.
%PROGRAMDATA%\XDR which issued as part of the registration
Collector\OSPersistence process.

Linux—

/etc/panw/OSPersistence/

7.5.5 | Set an Application Proxy for XDR Collectors

Abstract

You can set an application-specific proxy for a Cortex XDR Collector without affecting the communication of other applications on the collector machine.

In environments where Cortex XDR Collectors communicate with the Cortex XSIAM server through a wide system proxy you can set an application-specific
proxy for the XDR Collector without affecting the communication of other applications on the collector machine. You can set the proxy after installation from the

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 579/1003
5/8/24, 9:18 AM PDF Export

XDR Collectors Administration page in Cortex XSIAM as described in this topic. You can assign up to ten different proxy servers per XDR Collector. The proxy
server the agent uses is selected randomly and with equal probability. If the communication between the XDR Collector and the Cortex XSIAM sever through the
app-specific proxies fails, the XDR Collector resumes communication through the system-wide proxy defined on the collector machine. If that fails as well, the
XDR Collector resumes communication with Cortex XSIAM directly.

1. In Cortex XSIAM, select Settings → Configurations → XDR Collectors → Administration.

2. If needed, filter the list of on-premise collector machines.

3. Set an agent proxy.

a. Select the row of the on-premise collector machine that you want to set a proxy.

b. Right-click the collector machine and select Set Collector proxy.

c. You can assign up to ten different proxies per XDR Collector. For each proxy, specify the IP address and port number. After each Proxy Address and
Port added, select to add the values to a list underneath these fields. Broker VM's in the same tenant can also be configured to use as a proxy,
by enabling Agent proxy in the Broker VMs.

d. Set when you’re done.

e. If necessary, you can later Disable Collector Proxy from the right-click menu.

When you disable the proxy configuration, all proxies associated with that XDR Collector are removed. The XDR Collector resumes communication
with the Cortex XSIAM sever through the wide-system proxy if defined, otherwise if a wide-system is not defined the XDR Collector resumes
communicating directly with the Cortex XSIAM server. If neither a wide-system proxy nor direct communication exist and you disable the proxy, the
XDR Collector disconnects from Cortex XSIAM .

7.5.6 | Upgrade XDR Collectors

Abstract

You can upgrade the Cortex XDR Collector software by using the appropriate method for the collector machine operating system.

After you install the Cortex XDR Collector and the XDR Collector registers with Cortex XSIAM, you can upgrade the XDR Collector software for on-premise
Windows or Linux collector machine. You need to create a new installation packages and push the XDR Collector package to up to 500 collector machines from
Cortex XSIAM.

Upgrades are supported using actions which you can initiate from the Incident Response → Response → Action Center or Settings → XDR Collectors →
Administration page as described in this workflow.

1. Create an XDR Collector Installation Package for each operating system version that you want to upgrade the XDR Collector.

Note the installation package names.

2. Select Settings → XDR Collectors → Administration.

If needed, filter the list of on-premise collector machines. To reduce the number of results, use the collector machine name search and filters at the top of
the page.

3. Select the collector machines you want to upgrade.

You can also select collector machines running different operating systems to upgrade the XDR Collectors at the same time.

4. Right-click your selection and select Upgrade Collector version.

For each platform, select the name of the installation package you want to push to the selected on-premise collector machines.

NOTE:

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

5. Upgrade.

XDR distributes the installation package to the selected collector machine at the next heartbeat communication with the XDR Collector. To monitor the
status of the upgrades, go to Response → Action Center. From the Action Center you can also view additional information about the upgrade (right-click
the action and select Additional data) or cancel the upgrade (right-click the action and select Cancel Collector Upgrade).

7.5.7 | Uninstall the XDR Collector

Abstract

You can uninstall the Cortex XDR Collector from one or more Windows or Linux collector machines at any time.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 580/1003
5/8/24, 9:18 AM PDF Export

If you want to uninstall the XDR Collector from the on-premise collector machine, you can do so from the XDR Collectors console at any time. You can uninstall
the XDR Collector from an unlimited number of collector machines in a single bulk action. Uninstalling a collector machine triggers the following lifespan flow:

Once you uninstall the XDR Collector from the on-premise collector machine, Cortex XSIAM distributes the uninstall to the selected collector machine at
the next heartbeat communication with the XDR Collector. All XDR Collector files are removed from the collector machine.

The collector machine status changes to Uninstalled. After a retention period of 7 days, the XDR Collector is deleted from the database and is displayed
in XDR as Collector Machine Name - N/A (Uninstalled).

Data associated with the deleted on-premise collector machine is displayed in the Action Center tables for the standard 90 days retention period.

The following workflow describes how to uninstall the XDR Collector from one or more Windows or Linux on-premise collector machines.

1. Select Settings → Configurations → XDR Collectors → Administration.

2. Select the collector machines you want to uninstall.

You can also select collector machines running different operating systems to uninstall the XDR Collectors at the same time.

3. Right-click your selection and select Uninstall Collector.

4. To proceed, select I agree to confirm that you understand this action uninstalls the XDR Collector on all selected collector machines.

5. Click OK.

To monitor the status of the uninstall process, go to Response → Action Center.

7.5.8 | Set an Alias for a Collector Machine

Abstract

Configure an alias to identify one or more collector machines by a name that is different from the collector machine hostname.

To identify one or more collector machines by a name that is different from the collector machine hostname, you can configure an alias. You can set an alias for
a single collector machine or you can set an alias for multiple collector machines in bulk. To quickly search for the collector machines during investigation and
when you need to take action, you can use the either the collector machine hostname or the alias.

1. Select Settings → Configurations → XDR Collectors → Administration.

2. Select one or more collector machines.

3. Right-click anywhere in the collector machine rows, and select Change Collector Alias.

4. Specify the alias name and Update.

5. Use the Quick Launcher to search the collector machines by alias across the XDR Collectors console.

7.6 | Define Collector Machine Groups

Abstract

To easily apply policy rules and manage specific collector machines, you can define a collector machine group.

To easily apply policy rules and manage specific collector machines, you can define a collector machine group. If you set up Directory Sync, you can also
leverage your Active Directory user, group, and computer information in collector machine groups.

There are two methods you can use to define a collector machine group:

Create a dynamic group by allowing Cortex XSIAM to populate your collector machine group dynamically using collector machine characteristics, such as
a partial hostname or alias; full or partial domain name; IP address, range or subnet; XDR Collector version; or operating system version.

Create a static group by selecting a list of specific collector machines.

After you define a collector machine group, you can then use it to target policy and actions to specific recipients. The XDR Collectors Groups page displays all
collector machine groups along with the number of collector machines and policy rules linked to the collector machine group.

To define a collector machine static or dynamic group.

1. In Cortex XSIAM , select Settings → Configurations → XDR Collectors → Groups.

2. Select +Add Group to create a new collector machine group.

3. Specify a Group Name and optional Description to identify the collector machine group. The name you assign to the group will be visible when you assign
endpoint security profiles to endpoints.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 581/1003
5/8/24, 9:18 AM PDF Export

4. Determine the collector machine properties for creating a collector machine group:

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

NOTE:

XDR Collectors supports only IPv4 addresses.

Static—Select specific registered collector machines that you want to include in the collector machine group. Use the filters, as needed, to reduce
the number of results.

When you create a static collector machine group from a file, the IP address, hostname, or alias of the collector machine must match an existing
Cortex XSIAM that has registered with Cortex XSIAM .

NOTE:

Disconnecting Directory Sync in your Cortex XSIAM deployment can affect existing collector machine groups and policy rules based on Active
Directory properties.

5. Create the collector machine group.

After you save your collector machine group, it is ready for use to assign in policies for your collector machines and in other places where you can use
collector machine groups.

6. Manage a collector machine group, as needed.

At any time, you can return to the XDR Collectors Endpoints page to view and manage your collector machine groups. To manage a group, right-click the
group and select the desired action.

Edit—View the collector machines that match the group definition, and optionally refine the membership criteria using filters.

Delete the collector machine group.

Save as new—Duplicate the collector machine group and save it as a new group.

View collectors—Pivot from an collector machine group to a filtered list of collector machines on the Administration page where you can quickly view
and initiate actions on the collector machines within the group.

Copy text to clipboard to copy the text from a specific field in the row of a group.

Copy entire row to copy the text from all the fields in a row of a group.

Show rows with ‘<Group name>’ to filter the group list to only display the groups with a specific group name.

Hide rows with ‘<Group name>’ to filter the group list to hide the groups for a specific group name.

7.7 | About Cortex XDR Collector Content Updates

Abstract

To quickly resolve any issues in policy, Palo Alto Networks can seamlessly deliver software packages called content updates.

To quickly resolve any issues in policy, Palo Alto Networks can seamlessly deliver software packages for Cortex XSIAM called content updates. Content updates
for XDR Collectors contain changes or updates to the Elasticsearch Filebeat infrastructure or the Elasticsearch* Winlogbeat infrastructure.

When a new update is available, Cortex XSIAM notifies the XDR Collectors. The XDR Collectors then randomly choose a time within a six-hour window during
which it retrieves the content update from Cortex XSIAM.

7.8 | XDR Collector Profiles

Abstract

Add an XDR collector profile to define the type of data to collect from a Linux or Windows platform.

You can add XDR collector profiles that define the type of data that is collected from Linux or Windows platforms.

7.9 | Add an XDR Collector Profile for Windows

Abstract

Add a Cortex XDR Collector profile which defines the data that is collected from a Windows collector machine.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 582/1003
5/8/24, 9:18 AM PDF Export

NOTE:

Ingestion of logs larger than 5 MB is not supported.

An XDR Collector Windows profile defines the data that is collected from a Windows collector machine. For Windows, you can configure a Filebeat profile, A
Winlogbeat profile, or a Settings profile.

An XDR Collector Windows Filebeat profile enables you to collect file and log data using the Elasticsearch Filebeat default configuration file called
filebeat.yml.

Cortex XSIAM supports using Filebeat version 8.8.1 with the different operating systems listed in the Elasticsearch Support Matrix that conform to the
collector machine operating systems supported by Cortex XDR. Cortex XSIAM supports the various input types and modules available in Elasticsearch
Filebeat. For more information on the input types supported, see Configure Filebeat Inputs in Elasticsearch. For more information on the modules
supported, see Configure Filebeat Modules in Elasticsearch.

NOTE:

Fileset validation is enforced. You must enable at least one fileset in the module as filesets are disabled by default.

An XDR Collector Windows Winlogbeat profile enables you to collect event log data using the Elasticsearch Winlogbeat default configuration file called
winlogbeat.yml.

Cortex XSIAM supports using Winlogbeat version 8.8.1 with the different Windows versions listed in the Elasticsearch Winlogbeat Support Matrix that
conform to the collector machine operating systems supported by Cortex XDR. Cortex XSIAM supports the modules available in Elasticsearch
Winlogbeat. For more information on the modules supported, see Winlogbeat Modules in ElasticSearch.

An XDR Collector Settings profile enables you to configure whether to implement an automatic upgrade for the XDR Collector release.

After you add an XDR Collector profile, to associate it with a collector machine, you must use a policy.

NOTE:

For more information on Elasticsearch Filebeat, see the Elasticsearch Filebeat Overview Documentation.

For more information on Elasticsearch Winlogbeat, see the Elasticsearch Winlogbeat Overview Documentation.

1. In Cortex XSIAM, select Settings → Configurations → XDR Collectors → Profiles → +Add Profile → Windows.

2. Select Filebeat profile, Winlogbeat profile, or Settings profile, then click Next.

3. Configure the General Information parameters.

Profile Name—Specify a unique Profile Name to identify the profile. The name can contain only letters, numbers, or spaces, and must be no more
than 30 characters. The name you choose will be visible from the list of profiles when you configure a policy.

Add description here—(Optional) To provide additional context for the purpose or business reason that explains why you are creating the profile,
specify a profile description.

4. Configure the settings for the profile selected in Step 2.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 583/1003
5/8/24, 9:18 AM PDF Export

For an XDR Collector Filebeat profile, configure the Filebeat configuration file. In the Filebeat Configuration File editor, you can define the data
collection for your Elasticsearch Filebeat configuration file called filebeat.yml. Cortex XSIAM supports the various input types and modules
available in Elasticsearch Filebeat. For more information on the input types supported, see Configure Filebeat Inputs in Elasticsearch. For more
information on the modules supported, see Configure Filebeat Modules in Elasticsearch.

To facilitate the configuration of the YAML file, you can use out-of-the-box collection templates and templates added by the content packs installed
from the XSIAM Marketplace. Using the templates saves you time and doesn't require previous knowledge of configuration file generation. You can
edit and combine the provided templates, and you can add your own collection settings to the configuration file.

Cortex XSIAM provides YAML templates for DHCP, DNS, IIS, XDR Collector Logs, NGINX, and any templates added by the content packs installed
from the XSIAM Marketplace. To add a template, select it and click Add.

Cortex XSIAM also supports all sections in the filebeat.yml configuration file, such as support for Filebeat fields and tags. This enables you to
use the add_fields processor to identify the product/vendor for the data collected by the XDR Collectors so the collected events go through the
ingestion flow (Parsing Rules). To configure the product/vendor ensure that you use the default fields attribute, as opposed to the target attribute,
as shown in the following example.

processors:
- add_fields:
fields:
vendor: <Vendor>
product: <Product>

You can configure the Filebeat configuration file to collect Windows DHCP logs and Windows DNS Debug logs.

NOTE:

Cortex XSIAM collects all logs in either a JSON or text format that are uncompressed. Compressed files, such as in a gzip format, are
unsupported.

Cortex XSIAM supports logs in single line format or multiline format. For more information on handling messages that span multiple lines of text in
Elasticsearch Filebeat, see Manage Multiline Messages.

For an XDR Collector Winlogbeat profile, configure the Winlogbeat configuration file. In the Winlogbeat Configuration File editor, you can define the
data collection for your Elasticsearch Winlogbeat configuration file called winlogbeat.yml. Cortex XSIAM supports the various modules available
in Elasticsearch Winlogbeat. For more information on the modules supported, see Winlogbeat Modules in ElasticSearch.

To facilitate the configuration of the YAML file, you can use out-of-the-box collection templates and templates added by the content packs installed
from the XSIAM Marketplace. Using the templates saves you time and doesn't require previous knowledge of configuration file generation. You can
edit and combine the provided templates, and you can add your own collection settings to the configuration file.

Cortex XSIAM provides YAML templates for Windows Security and any templates added by the content packs installed from the XSIAM
Marketplace. To add a template, select it and click Add.

Cortex XSIAM also supports all sections in the winlogbeat.yml configuration file, such as support for Winlogbeat fields and tags. This enables you
to use the add_fields processor to identify the product/vendor for the data collected by the XDR Collectors so the collected events go through the
ingestion flow (Parsing Rules). To configure the product/vendor ensure that you use the default fields attribute, as opposed to the target attribute,
as shown in the following example.

processors:
- add_fields:
fields:
vendor: <Vendor>
product: <Product>

After ingestion, Cortex XSIAM normalizes and saves the Windows event logs collected by the Winlogbeat profile in the dataset xdr_data. The
normalized logs are also saved in a unified format in <vendor>_<product>_raw if the product and vendor are defined, and in
microsoft_windows_raw otherwise. This enables you to search the data using Cortex Query Language XQL queries, build correlation rules, and
generate dashboards based on the data.

For an XDR Collector Windows Settings profile, configure the Collector Upgrade parameters. You can configure an automatic upgrade for the XDR
Collector release. By default, this is disabled and the Use Default (Disabled) is selected. To implement an automatic upgrade, follow these steps.

1. Clear the Use Default (Disabled) checkbox.

2. For the Collector Auto-Upgrade field, select Enabled.

When configuring this field, the following additional fields are displayed for defining the scope of the automatic upgrade.

3. You can configure the scope of the automatic upgrade to whenever a new XDR Collector release is available including maintenance releases
and new features.

To ensure the latest XDR Collector release is used, leave the Use Default (Latest collector release) checkbox selected.

To configure only a particular scope, perform the following steps.

a. Clear the Use Default (Latest collector release) checkbox.

b. For the Auto Upgrade Scope, select one of the following options.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 584/1003
5/8/24, 9:18 AM PDF Export

-Latest collector release—Configures the scope of the automatic upgrade to whenever a new XDR Collector release is available including
maintenance releases and new features.

-Only maintenance release—Configures the scope of the automatic upgrade to whenever a new XDR Collector maintenance release is
available.

-Only maintenance releases in a specific version—Configures the scope of the automatic upgrade to whenever a new XDR Collector
maintenance release is available for a specific version. When this option is selected, you can select the specific Release Version.

5. Create your new profile, which is listed under the applicable platform in the XDR Collectors Profiles page.

6. Apply Profiles to Collection Machine Policies.

You can do this in two ways. You can Create a new policy rule using this profile from the right-click menu or you can launch the new policy wizard from
XDR Collectors → Policies → XDR Collectors Policies page.

7. Other available options.

As needed, you can return to the XDR Collectors Profiles page to manage your Collectors profiles. To manage a specific profile, right click anywhere in the
XDR Collector profile row, and select the desired action:

Edit the XDR Collector profile settings.

Save As New—Enables you to copy the existing profile with its current settings, make any modifications, and save it as a new profile by adding a
unique name.

Delete the XDR Collector profile.

View Collector Policies—Opens a new tab with the XDR Collectors Policies page displayed, so you can easily see the current policies that are
associated to your XDR Collector profiles.

Copy text to clipboard to copy the text from a specific field in the row of a XDR Collector profile.

Copy entire row to copy the text from the entire row of a XDR Collector profile.

7.9.1 | Ingest Logs from Windows DHCP using Elasticsearch Filebeat

Abstract

Learn how to configure Cortex XSIAM to receive Windows DHCP logs.

You can configure Cortex XSIAM to receive Windows DHCP logs using Elasticsearch Filebeat with the following data collectors.

XDR Collectors (recommended)

Windows DHCP

Ingest Windows DHCP Logs with an XDR Collector Profile

Abstract

Extend Cortex XSIAM visibility into logs from Windows DHCP using an XDR Collector Windows Filebeat profile.

Extend Cortex XSIAM visibility into logs from Windows DHCP using an XDR Collector Windows Filebeat profile.

You can enrich network logs with Windows DHCP data when defining data collection in an XDR Collector Windows Filebeat profile. When you add a XDR
Collector Windows Filebeat profile using the Elasticsearch Filebeat default configuration file called filebeat.yml, you can define whether the collected data
undergoes follow-up processing in the backend for Windows DHCP data. Cortex XSIAM uses Windows DHCP logs to enrich your network logs with hostnames
and MAC addresses that are searchable in XQL Search using the Windows DHCP Cortex Query Language (XQL) dataset (microsoft_dhcp_raw).

While this enrichment is also available when configuring a Windows DHCP Collector for a cloud data collection integration, we recommend configuring Cortex
XSIAM to receive Windows DHCP logs with an XDR Collector Windows Filebeat profile as it’s the ideal setup configuration.

Configure Cortex XSIAM to receive logs from Windows DHCP using an XDR Collector Windows Filebeat profile.

1. Add an XDR Collector Profile for Windows.

Follow the steps for creating a Windows Filebeat profile as described in Add an XDR Collector Profile for Windows, and in the Filebeat Configuration File
area, ensure that you select and Add the DHCP template. The template's content will be displayed here, and is editable.

2. To configure collection of Windows DHCP data, edit the template text as necessary for your system.

You can enrich network logs with Windows DHCP data when defining data collection by setting the vendor to “microsoft” , and product to “dhcp” in
the filebeat.yml file, which you can then query in the microsoft_dhcp_raw dataset.

NOTE:

To avoid formatting issues in filebeat.yml, we recommend that you edit the text file inside the user interface, instead of copying it and editing it
elsewhere. Validate the syntax of the YML file before you finish creating the profile.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 585/1003
5/8/24, 9:18 AM PDF Export

Ingest Windows DHCP Logs with the Windows DHCP Collector

Abstract

Extend Cortex XSIAM visibility into logs from Windows DHCP using Elasticsearch Filebeat with the Windows DHCP data collector.

Extend Cortex XSIAM visibility into logs from Windows DHCP using Elasticsearch Filebeat with the Windows DHCP data collector.

To receive Windows DHCP logs, you must configure data collection from Windows DHCP via Elasticsearch Filebeat. This is configured by setting up a Windows
DHCP Collector in Cortex XSIAM and installing and configuring an Elasticsearch Filebeat agent on your Windows DHCP Server. Cortex XSIAM supports using
Filebeat up to version 8.0.1 with the Windows DHCP Collector.

Certain settings in the Elasticsearch Filebeat default configuration file called filebeat.yml must be populated with values provided when you configure the
Data Sources settings in Cortex XSIAM for the Windows DHCP Collector. To help you configure the filebeat.yml correctly, Cortex XSIAM provides an
example file that you can download and customize. After you set up collection integration, Cortex XSIAM begins receiving new logs and data from the source.

NOTE:

For more information on configuring the filebeat.yml file, see the Elastic Filebeat Documentation.

Windows DHCP logs are stored as CSV (comma-separated values) log files. The logs rotate by days (DhcpSrvLog-<day>.log), and each file contains two
sections - Event ID Meaning and the events list.

As soon as Cortex XSIAM begins receiving logs, the app automatically creates a Windows DHCP XQL dataset (microsoft_dhcp_raw). Cortex XSIAM uses
Windows DHCP logs to enrich your network logs with hostnames and MAC addresses that are searchable in XQL Search using the Windows DHCP Cortex
Query Language (XQL) dataset.

Configure Cortex XSIAM to receive logs from Windows DHCP via Elasticsearch Filebeat with the Windows DHCP collector.

1. Configure the Windows DHCP Collector in Cortex XSIAM.

a. Select Settings → Data Sources.

b. In the Windows DHCP Collector configuration, click Add Instance to begin a new configuration.

The Enable Windows DHCP Log Collection dialog box is displayed.

c. (Optional) Download example filebeat.yml file.

To help you configure your filebeat.yml file correctly, Cortex XSIAM provides an example filebeat.yml file that you can download and customize.
To download this file, use the link provided in this dialog box.

NOTE:

To avoid formatting issues in your filebeat.yml, we recommend that you use the download example file to make your customizations. Do not
copy and paste the code syntax examples provided later in this procedure into your file.

d. Specify a descriptive Name for your log collection configuration.

e. Save & Generate Token. The token is displayed in a blue box, which is blurred out in the image below.

Click the copy icon next to the key and record it somewhere safe. You will need to provide this key when you set the api_key value in the
Elasticsearch Output section in the filebeat.yml file as explained in Step #2. If you forget to record the key and close the window you will need
to generate a new key and repeat this process.

f. Select Done to close the window.

g. In the Integrations page for the Windows DHCP Collector that you created, select Copy api url and record it somewhere safe. You will need to
provide this URL when you set the hosts value in the Elasticsearch Output section in the filebeat.yml file as explained in Step #2.

2. Configure an Elasticsearch Filebeat agent on your Windows DHCP Server.

a. Navigate to the Elasticsearch Filebeat installation directory, and open the filebeat.yml file to configure data collection with Cortex XSIAM. We
recommend that you use the download example file provided by Cortex XSIAM.

b. Update the following sections and tags in the filebeat.yml file. The example code below details the specific sections to make these changes in
the file.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 586/1003
5/8/24, 9:18 AM PDF Export

Filebeat inputs—Define the paths to crawl and fetch. The code below provides an example of how to configure the Filebeat inputs section
in the filebeat.yml file with these paths configured.

# ============================== Filebeat inputs ===============================

filebeat.inputs:
# Each - is an input. Most options can be set at the input level, so
# you can use different inputs for various configurations.
# Below are the input specific configurations.
- type: log
# Change to true to enable this input configuration.
enabled: true
# Paths that should be crawled and fetched. Glob based paths.
paths:
- c:\Windows\System32\dhcp\DhcpSrvLog*.log

Elasticsearch Output—Set the hosts and api_key, where both of these values are obtained when you configured the Windows DHCP
Collector in Cortex XSIAM as explained in Step #1. The code below provides an example of how to configure the Elasticsearch Output
section in the filebeat.yml file and indicates which settings need to be obtained from Cortex XSIAM.

# ---------------------------- Elasticsearch Output ----------------------------

output.elasticsearch:
enabled: true
# Array of hosts to connect to.
hosts: ["OBTAIN THIS URL FROM CORTEX XDR"]
# Protocol - either `http` (default) or `https`.
protocol: "https"
compression_level: 5
# Authentication credentials - either API key or username/password.
api_key: "OBTAIN THIS KEY FROM CORTEX XDR"

Processors—Set the tokenizer and add a drop_event processor to drop all events that do not start with an event ID. The code below
provides an example of how to configure the Processors section in the filebeat.yml file and indicates which settings need to be obtained
from Cortex XSIAM.

NOTE:

The tokenizer definition is dependent on the Windows server version that you are using as the log format differs.

-For platforms earlier than Windows Server 2008, use "%{id},%{date},%{time},%{description},%{ipAddress},%{hostName},%

{macAddress}"

-For Windows Server 2008 and 2008 R2, use "%{id},%{date},%{time},%{description},%{ipAddress},%{hostName},%

{macAddress},%{userName},%{transactionID},%{qResult},%{probationTime},%{correlationID}"

For Windows Server 2012 and above, use "%{id},%{date},%{time},%{description},%{ipAddress},%{hostName},%

{macAddress},%{userName},%{transactionID},%{qResult},%{probationTime},%{correlationID},%{dhcid},%
{vendorClassHex},%{vendorClassASCII},%{userClassHex},%{userClassASCII},%{relayAgentInformation},%{dnsRegError}"

# ================================= Processors =================================

processors:
- add_host_metadata:
when.not.contains.tags: forwarded
- drop_event.when.not.regexp.message: "^[0-9]+,.*"
- dissect:
tokenizer: "%{id},%{date},%{time},%{description},%{ipAddress},%{hostName},%{macAddress},%{userName},%{transactionID},%{qResult},%{probationTime},%
{correlationID},%{dhcid},%{vendorClassHex},%{vendorClassASCII},%{userClassHex},%{userClassASCII},%{relayAgentInformation},%{dnsRegError}"
- drop_fields:
fields: ["message"]
- add_locale: ~
- rename:
fields:
- from: "event.timezone"
to: "dissect.timezone"
ignore_missing: true
fail_on_error: false
- add_cloud_metadata: ~
- add_docker_metadata: ~
- add_kubernetes_metadata: ~

3. Verify the status of the integration.

Return to the Integrations page and view the statistics for the log collection configuration.

4. After Cortex XSIAM begins receiving logs from Windows DHCP via Elasticsearch Filebeat, you can use the XQL Search to search for logs in the new
dataset (microsoft_dhcp_raw).

7.9.2 | Ingest Windows DNS Debug logs using Elasticsearch Filebeat

Topic Not Found

7.10 | Add an XDR Collector Profile for Linux

Abstract

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 587/1003
5/8/24, 9:18 AM PDF Export

Add a Cortex XDR Collector profile which defines the data that is collected from a Linux collector machine.
NOTE:

Ingestion of logs larger than 5 MB is not supported.

An XDR Collector Linux profile defines the data that is collected from a Linux collector machine. For Linux, you can configure a Filebeat profile or a Settings
profile.

An XDR Collector Linux Filebeat profile enables you to collect file and log data using the Elasticsearch Filebeat default configuration file called
filebeat.yml. Cortex XSIAM supports using Filebeat version 8.8.1 with the different operating systems listed in the Elasticsearch Support Matrix that
conform to the collector machine operating systems supported by Cortex XDR. Cortex XSIAM supports the various input types and modules available in
Elasticsearch Filebeat. For more information on the input types supported, see Configure Filebeat Inputs in Elasticsearch. For more information on the
modules supported, see Configure Filebeat Modules in Elasticsearch.

NOTE:

Fileset validation is enforced. You must enable at least one fileset in the module as filesets are disabled by default.

An XDR Collector Linux Settings profile enables you to configure whether to implement an automatic upgrade for the XDR Collector release.

After you add an XDR Collector profile, to associate it with a collector machine, you must use a policy.

NOTE:

For more information on Elasticsearch Filebeat, see the Elasticsearch Filebeat Overview Documentation.

1. In Cortex XSIAM , select Settings → Configurations → XDR Collectors → Profiles → +Add Profile → Linux.

2. Select Filebeat profile or Settings profile, then click Next.

3. Configure the General Information parameters.

Profile Name—Specify a unique Profile Name to identify the profile. The name can contain only letters, numbers, or spaces, and must be no more
than 30 characters. The name you choose will be visible from the list of profiles when you configure a policy.

Add description here—(Optional) To provide additional context for the purpose or business reason that explains why you are creating the profile,
specify a profile description.

4. Configure the settings for the profile selected in Step 2.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 588/1003
5/8/24, 9:18 AM PDF Export

For an XDR Collector Filebeat profile, configure the Filebeat configuration file. In the Filebeat Configuration File editor, define the data collection for
your Elasticsearch Filebeat configuration file called filebeat.yml. Cortex XSIAM supports the various input types and modules available in
Elasticsearch Filebeat. For more information on the input types supported, see Configure Filebeat Inputs in Elasticsearch. For more information on
the modules supported, see Configure Filebeat Modules in Elasticsearch.

To facilitate the configuration of the YAML file, you can use out-of-the-box collection templates and templates added by the content packs installed
from the XSIAM Marketplace. Using the templates saves you time and doesn't require previous knowledge of configuration file generation. You can
edit and combine the provided templates, and you can add your own collection settings to the configuration file.

Cortex XSIAM provides YAML templates for XDR Collector Logs, RHEL/CentOS, MySQL, NGINX, Debian/Ubuntu, and any templates added by the
content packs installed from the XSIAM Marketplace. To add a template, select it and click Add.

Cortex XSIAM supports all sections in the filebeat.yml configuration file, such as support for Filebeat fields and tags. This enables you to use the
add_fields processor to identify the product/vendor for the data collected by the XDR Collectors so the collected events go through the ingestion
flow (Parsing Rules). To identify the product/vendor ensure that you use the default fields attribute, as opposed to the target attribute, as shown in
the following example.

processors:
- add_fields:
fields:
vendor: <Vendor>
product: <Product>

NOTE:

Cortex XSIAM collects all logs in either a JSON or text format that are uncompressed. Compressed files, such as in a gzip format, are
unsupported.

Cortex XSIAM supports logs in single line format or multiline format. For more information on handling messages that span multiple lines of text in
Elasticsearch Filebeat, see Manage Multiline Messages.

For an XDR Collector Linux Settings profile, configure the Collector Upgrade parameters. You can configure an automatic upgrade for the XDR
Collector release. By default, this is disabled and the Use Default (Disabled) is selected. To implement an automatic upgrade, follow these steps.

1. Clear the Use Default (Disabled) checkbox.

2. For the Collector Auto-Upgrade field, select Enabled.

When configuring this field, the following additional fields are displayed for defining the scope of the automatic upgrade.

3. You can configure the scope of the automatic upgrade to whenever a new XDR Collector release is available including maintenance releases
and new features.

To ensure the latest XDR Collector release is used, leave the Use Default (Latest collector release) checkbox selected.

To configure only a particular scope, perform the following steps.

a. Clear the Use Default (Latest collector release) checkbox.

b. For the Auto Upgrade Scope, select one of the following options.

-Latest collector release—Configures the scope of the automatic upgrade to whenever a new XDR Collector release is available including
maintenance releases and new features.

-Only maintenance release—Configures the scope of the automatic upgrade to whenever a new XDR Collector maintenance release is
available.

-Only maintenance releases in a specific version—Configures the scope of the automatic upgrade to whenever a new XDR Collector
maintenance release is available for a specific version. When this option is selected, you can select the specific Release Version.

5. Create your new profile, which appears under the applicable platform in the XDR Collectors Profiles page.

6. Apply Profiles to Collection Machine Policies.

You can do this in two ways. You can Create a new policy rule using this profile from the right-click menu or you can launch the new policy wizard from
XDR Collectors → Policies → XDR Collectors Policies page.

7. Other available options.

As needed, you can return to the XDR Collectors Profiles page to manage your XDR Collectors profiles. To manage a specific profile, right click anywhere
in the XDR Collector profile row, and select the desired action:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 589/1003
5/8/24, 9:18 AM PDF Export

Edit the XDR Collector profile settings.

Save As New—Enables you to copy the existing profile with its current settings, make any modifications, and save it as a new profile by adding a
unique name.

Delete the XDR Collector profile.

View Collector Policies—Opens a new tab with the XDR Collectors Policies page displayed, so you can easily see the current policies that are
associated to your XDR Collector profiles.

Copy text to clipboard to copy the text from a specific field in the row of an XDR Collector profile.

Copy entire row to copy the text from the entire row of an XDR Collector profile.

7.11 | Apply Profiles to Collection Machine Policies

Abstract

Once a Cortex XDR Collector profile is configured, you must attach the profile to a policy.

Once a Cortex XDR Collector profile is configured, you must attach the profile to a policy. Each policy that you create must apply to one or more collector
machines or collector machine groups.

1. In Cortex XSIAM , create a policy.

Do either of the following:

Select Settings → Configurations → XDR Collectors → Policies → +Add Policy to create a policy from scratch in the XDR Collectors Policies page.

Select Settings → Configurations → XDR Collectors → Profiles, right-click the profile you want to assign and Create a new policy rule using this
profile in the XDR Collectors Profiles page.

2. Set the General settings for the policy.

Policy Name—Specify a unique name for the policy.

Description—(Optional) Specify a description that describes the purpose or intent of the policy.

Platform—Select the Platform as either Windows or Linux that you want to create the new policy.

Collector Profile—Select the applicable Collector Profile from the list available for the Platform designated that you want to apply to the policy. If you
do not specify a profile, the XDR Collector uses the Default profile.

3. Click Next.

4. Set the Target settings in the XDR Collectors Endpoints screen.

Use the filters to assign the policy to one or more collector machines (endpoints) or collector machine (endpoint) groups.

Cortex XSIAM automatically applies a filter for the platform you selected. To change the platform, go Back to the general policy settings.

5. Click Next.

6. Review the Summary for the new policy.

If everything looks fine, click Done. Otherwise, click Back to make your changes.

7. In the XDR Collectors Policies table, change the policy position, if needed, to order the policy relative to other policies.

The XDR Collector evaluates policies from top to bottom. When the XDR Collector finds the first match it applies that policy as the active policy. To move
the policy order, select the arrows and drag the policy to the desired location in the policy hierarchy.

8. Other available options.

As needed, you can return to the XDR Collectors Policies page to manage your XDR Collectors policies. To manage a specific policy, right click anywhere
in the XDR Collector policy row, and select the desired action:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 590/1003
5/8/24, 9:18 AM PDF Export

Disable the XDR Collector policy.

Delete the XDR Collector policy.

View Policy Details—Opens a new window with the details of the current profile configured for this policy, so you can easily see the Collector
Upgrade and Filebeat configuration file details for the profile associated to this policy.

Save As New—Enables you to copy the existing policy with its current settings, make any modifications, and save it as a new policy by adding a
unique name.

Edit the XDR Collector policy settings.

Copy text to clipboard to copy the text from a specific field in the row of a XDR Collector policy.

Copy entire row to copy the text from the entire row of a XDR Collector policy.

7.12 | XDR Collector Datasets

Abstract

After Cortex XSIAM begins receiving data from your XDR Collectors configuration, the app automatically creates an XQL dataset.

After Cortex XSIAM begins receiving data from your XDR Collectors configuration that are dedicated for on-premise data collection on Windows and Linux
machines.

For Filebeat, the app automatically creates an Cortex Query Language (XQL) dataset of event logs using the vendor name and the product name
specified in the configuration file section of the Filebeat profile. The dataset name follows the format <vendor>_<product>_raw. If not specified, Cortex
XSIAM automatically creates a new default dataset in the format <module>_<module>_raw or <input>_<input>_raw. For example, if you are using the
NGINX module, the dataset is called nginx_nginx_raw.

For Winlogbeat, the app automatically creates an XQL dataset of event logs using the vendor name and the product name specified in the configuration
file section of the Winlogbeat profile. The dataset name follows the format <vendor>_<product>_raw. If not specified, Cortex XSIAM automatically
creates a new default dataset, microsoft_windows_raw, for event log collection. Winlogbeat data is also normalized to xdr_data (and thus the
xdr_event_log preset).

After Cortex XSIAM creates the dataset, you can search for your XDR Collector data using XQL Search.

8 | Data Ingestion
Abstract

Learn about the types of data that can be ingested into your system, vendor support, and how to configure ingestion.

Learn about the types of data that can be ingested into your system, vendor support, and how to configure ingestion.

8.1 | Visibility of Logs and Alerts from External Sources

Abstract

Cortex XSIAM provides visibility into your external logs. The availability of logs and alerts varies by the data source.

The following table describes the visibility of each vendor and device type, and where you can view information ingested from external sources, depending on
the data source.

A indicates support and a dash (—) indicates the feature is not supported.

Network connections

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 591/1003
5/8/24, 9:18 AM PDF Export

Vendor And Device Type Raw Data Visibility Normalized Log Visibility Cortex XSIAM Alert Visibility Vendor Alert Visibility

Amazon S3 (flow logs) —

Raw data is Option to ingest network Cortex XSIAM can raise Cortex
searchable in XQL flow logs as Cortex XSIAM alerts (Analytics, IOC, BIOC, and
Search. XSIAM network connection Correlation Rules) when relevant from
stories that are searchable logs.
in the Query Builder and in
NOTE:
XQL Search.
While Correlation Rules alerts are
raised on non-normalized and
normalized logs, Analytics, IOC and
BIOC alerts are only raised on
normalized logs.

Amazon S3 (Route 53 —
logs) Raw data is Option to ingest network Cortex XSIAM can raise Cortex
searchable in XQL Route 53 DNS logs XSIAM alerts (Analytics, IOC, BIOC, and
Search. as Cortex XSIAM network Correlation Rules) when relevant from
connection stories that are logs.
searchable in the Query
Builder and in XQL NOTE:
Search. While Correlation Rules alerts are
raised on non-normalized and
normalized logs, Analytics, IOC and
BIOC alerts are only raised on
normalized logs.

Azure Event Hub — —

Raw data is Cortex XSIAM can raise Cortex
searchable in XQL XSIAM alerts (Correlation Rules only)
Search. when relevant from flow logs.

Azure Network Watcher —

(flow logs) Raw data is Option to ingest network Cortex XSIAM can raise Cortex
searchable in XQL flow logs as Cortex XSIAM alerts (Analytics, IOC, BIOC, and
Search. XSIAM network connection Correlation Rules) when relevant from
stories that are searchable flow logs.
in the Query Builder and in
XQL Search. NOTE:

While Correlation Rules alerts are

raised on non-normalized and
normalized logs, Analytics, IOC and
BIOC alerts are only raised on
normalized logs.

Check Point FW1/VPN1

Raw data is Network stories that Cortex XSIAM can raise Cortex Alerts from Check Point
searchable in XQL include Check Point XSIAM alerts (Analytics, IOC, BIOC, and firewalls are raised
Search. network connection logs Correlation Rules) when relevant from throughout Cortex
are searchable in the logs. XSIAM when relevant.
NOTE: Query Builder and in XQL
Search. NOTE:
Logs
with sessionid = While Correlation Rules alerts are
0 are dropped. NOTE: raised on non-normalized and
normalized logs, Analytics, IOC and
Logs with sessionid = BIOC alerts are only raised on
0 are dropped. normalized logs.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 592/1003
5/8/24, 9:18 AM PDF Export

Vendor And Device Type Raw Data Visibility Normalized Log Visibility Cortex XSIAM Alert Visibility Vendor Alert Visibility

Corelight Zeek —
Raw data is Network stories that Cortex XSIAM can raise Cortex
searchable in XQL include Corelight Zeek XSIAM alerts (Analytics, IOC, BIOC, and
Search. network connection logs Correlation Rules) when relevant from
are searchable in the logs.
Query Builder and in XQL
NOTE:
Search.
While Correlation Rules alerts are
raised on non-normalized and
normalized logs, Analytics, IOC and
BIOC alerts are only raised on
normalized logs.

Cisco ASA and Cisco —

AnyConnect VPN Raw data is Network stories that Cortex XSIAM can raise Cortex
searchable in XQL include Cisco network XSIAM alerts (Analytics, IOC, BIOC, and
Search. connection logs are Correlation Rules) when relevant from
searchable in the Query logs.
Builder and in XQL
Search. NOTE:

While Correlation Rules alerts are

raised on non-normalized and
normalized logs, Analytics, IOC and
BIOC alerts are only raised on
normalized logs.

Fortinet Fortigate
Raw data is Network stories that Cortex XSIAM can raise Cortex Alerts from Fortinet
searchable in XQL include Fortinet network XSIAM alerts (Analytics, IOC, BIOC, and firewalls are raised
Search. connection logs are Correlation Rules) when relevant from throughout Cortex
searchable in the Query logs. XSIAM when relevant.
Builder and in XQL
Search. NOTE:

While Correlation Rules alerts are

raised on non-normalized and
normalized logs, Analytics, IOC and
BIOC alerts are only raised on
normalized logs.

Google Cloud Platform —

(flow logs, DNS logs) Raw data is Option to ingest network Cortex XSIAM can raise Cortex
searchable in XQL flow logs as Cortex XSIAM alerts (Analytics, IOC, BIOC, and
Search. XSIAM network connection Correlation Rules) when relevant from
stories and Google Cloud logs.
DNS logs that are
NOTE:
searchable in the Query
Builder and in XQL While Correlation Rules alerts are
Search. raised on non-normalized and
normalized logs, Analytics, IOC and
BIOC alerts are only raised on
normalized logs.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 593/1003
5/8/24, 9:18 AM PDF Export

Vendor And Device Type Raw Data Visibility Normalized Log Visibility Cortex XSIAM Alert Visibility Vendor Alert Visibility

Okta — —
Raw data is Cortex XSIAM can raise Cortex
searchable in XQL XSIAM alerts (Analytics, IOC, BIOC, and
Search. Correlation Rules) when relevant from
logs.

NOTE:

While Correlation Rules alerts

are raised on non-normalized
and normalized logs, Analytics,
IOC and BIOC alerts are only
raised on normalized logs.

IOCs and BIOCs are only

raised for these event
types: sso and session_start.

Windows DHCP via — —

Elasticsearch Filebeat Raw data is Cortex XSIAM uses
searchable in XQL Windows DHCP logs to
Search. enrich your network logs
with hostnames and MAC
addresses that are
searchable in XQL Search.

Zscaler Internet Access —

(ZIA) Raw data is Network stories that Cortex XSIAM can raise Cortex
searchable in XQL include ZIA network XSIAM alerts (Analytics, IOC, BIOC, and
Search. connection and firewall Correlation Rules) when relevant from
logs are searchable in the logs.
Query Builder and in XQL
Search. NOTE:

While Correlation Rules alerts

are raised on non-normalized
and normalized logs, Analytics,
IOC and BIOC alerts are only
raised on normalized logs.

Analytics, IOCs and BIOCs are

only raised on the Firewall data.

The Zscaler Nanolog Streaming

Service (NSS) feed for web logs
is only used for Correlation
Rules and threat hunting.

Zscaler Private Access —

(ZPA) Raw data is Network stories that Cortex XSIAM can raise Cortex
searchable in XQL include ZPA network XSIAM alerts (Analytics, IOC, BIOC, and
Search. connection logs are Correlation Rules) when relevant from
searchable in the Query logs.
Builder and in XQL
Search. NOTE:

While Correlation Rules alerts

are raised on non-normalized
and normalized logs, Analytics,
IOC and BIOC alerts are only
raised on normalized logs.

The Zscaler Nanolog Streaming

Service (NSS) feed for web logs
is only used for Correlation
Rules and threat hunting.

Authentication services/Audit logs

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 594/1003
5/8/24, 9:18 AM PDF Export

Vendor And Device Type Raw Data Visibility Normalized Log Visibility Cortex XSIAM Alert Visibility Vendor Alert Visibility

Amazon S3 (audit logs) —

Logs and stories are Option to stitch audit logs Cortex XSIAM can raise Cortex
searchable in XQL with authentication stories XSIAM alerts (Analytics, IOC, BIOC, and
Search that are searchable in the Correlation Rules) when relevant from
Query Builder and XQL logs.
Search.
NOTE:

While Correlation Rules alerts are

raised on non-normalized and
normalized logs, Analytics, IOC and
BIOC alerts are only raised on
normalized logs.

Azure Event Hub (audit —

logs, AKS logs) Logs and stories are Option to stitch audit logs Cortex XSIAM can raise Cortex
searchable in XQL with authentication stories XSIAM alerts (Analytics, IOC, BIOC, and
Search that are searchable in the Correlation Rules) when relevant from
Query Builder and XQL logs.
Search.
NOTE:

While Correlation Rules alerts are

raised on non-normalized and
normalized logs, Analytics, IOC and
BIOC alerts are only raised on
normalized logs.

Google Cloud Platform —

(audit logs, GKE logs) Raw data is Option to stitch audit logs Cortex XSIAM can raise Cortex
searchable in XQL with authentication stories XSIAM alerts (Analytics, IOC, BIOC, and
Search. that are searchable in the Correlation Rules) when relevant from
Query Builder and XQL logs.
Search.
NOTE:

While Correlation Rules alerts are

raised on non-normalized and
normalized logs, Analytics, IOC and
BIOC alerts are only raised on
normalized logs.

Google Workspace —
Raw data is Relevant Login, Token, For all logs, Cortex XSIAM can
searchable in XQL Google drive, SAML, raise Cortex XSIAM alerts (Analytics and
Search. Admin Console, Enterprise Correlation Rules) when relevant from
Groups, and Rules audit logs.
logs normalized into
authentication stories. All
are searchable in the
Query Builder.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 595/1003
5/8/24, 9:18 AM PDF Export

Vendor And Device Type Raw Data Visibility Normalized Log Visibility Cortex XSIAM Alert Visibility Vendor Alert Visibility

Microsoft Office 365 —

Logs and stories Azure AD authentication For all Microsoft Office 365 logs, Cortex
(Azure AD logs and Azure AD Sign-in XSIAM can also raise Cortex
authentication and logs normalized into XSIAM alerts (Analytics, IOC, BIOC, and
audit logs only) are authentication stories. Correlation Rules) when relevant from
searchable in XQL Azure AD audit logs Office 365 logs.
Search normalized to cloud audit
NOTE:
logs stories. Exchange
Online, SharePoint Online, While Correlation Rules alerts are
and General audit logs raised on non-normalized and
normalized logs, Analytics, IOC and
normalized into stories. All
BIOC alerts are only raised on
are searchable in the normalized logs.
Query Builder.

Okta —
Logs and stories are Logs stitched with Cortex XSIAM can raise Cortex
searchable in XQL authentication stories are XSIAM alerts (Analytics, IOC, BIOC, and
Search searchable in the Query Correlation Rules only) when relevant
Builder. from logs.

NOTE:

While Correlation Rules alerts

are raised on non-normalized
and normalized logs, Analytics,
IOC and BIOC alerts are only
raised on normalized logs.

IOCs and BIOCs are only

raised for these event
types: sso and session_start.

OneLogin —
Raw data is All log types are Cortex XSIAM can raise Cortex
searchable in XQL normalized into XSIAM alerts (Analytics, IOC, BIOC, and
Search. authentication stories, and Correlation Rules) when relevant from
are searchable in the logs.
Query Builder.
NOTE:

While Correlation Rules alerts are

raised on non-normalized and
normalized logs, Analytics, IOC and
BIOC alerts are only raised on
normalized logs.

PingFederate —
Logs and stories are Logs stitched with Cortex XSIAM can raise Cortex
searchable in XQL authentication stories are XSIAM alerts (Analytics, IOC, BIOC, and
Search searchable in the Query Correlation Rules) when relevant from
Builder. logs.

NOTE:

While Correlation Rules alerts are

raised on non-normalized and
normalized logs, Analytics, IOC and
BIOC alerts are only raised on
normalized logs.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 596/1003
5/8/24, 9:18 AM PDF Export

Vendor And Device Type Raw Data Visibility Normalized Log Visibility Cortex XSIAM Alert Visibility Vendor Alert Visibility

PingOne for Enterprise —

Raw data is Logs stitched with Cortex XSIAM can raise Cortex
searchable in XQL authentication stories are XSIAM alerts (Analytics, IOC, BIOC, and
Search searchable in the Query Correlation Rules) when relevant from
Builder. logs.

NOTE:

While Correlation Rules alerts are

raised on non-normalized and
normalized logs, Analytics, IOC and
BIOC alerts are only raised on
normalized logs.

Operation and system logs from cloud providers

Vendor And Device Type Raw Data Visibility Normalized Log Visibility Cortex XSIAM Alert Visibility Vendor Alert Visibility

Amazon S3 (generic logs) — —

Raw data is searchable in Cortex XSIAM can
XQL Search. raise Cortex XSIAM alerts
(Correlation Rules only) when
relevant from logs.

Amazon CloudWatch —
(generic logs, EKS logs) Raw data is searchable in Cortex XSIAM can
XQL Search. raise Cortex XSIAM alerts
(Analytics, IOC, BIOC, and
Correlation Rules) when
relevant from logs.

NOTE:

While Correlation Rules

alerts are raised on non-
normalized and normalized
logs, Analytics, IOC and
BIOC alerts are only raised
on normalized logs.

Azure Event Hub — —

Raw data is searchable in Cortex XSIAM can
XQL Search. raise Cortex XSIAM alerts
(Correlation Rules only) when
relevant from logs.

Google Cloud Platform — —

Raw data is searchable in Cortex XSIAM can
XQL Search. raise Cortex XSIAM alerts
(Correlation Rules only) when
relevant from logs.

Google Kubernetes Engine — —

Raw data is searchable in Cortex XSIAM can
XQL Search. raise Cortex XSIAM alerts
(Correlation Rules only) when
relevant from logs.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 597/1003
5/8/24, 9:18 AM PDF Export

Vendor And Device Type Raw Data Visibility Normalized Log Visibility Cortex XSIAM Alert Visibility Vendor Alert Visibility

Okta — —
Raw data is searchable in Cortex XSIAM can
XQL Search. raise Cortex XSIAM alerts
(Analytics, IOC, BIOC, and
Correlation Rules) when
relevant from logs.

NOTE:

While Correlation Rules

alerts are raised on non-
normalized and normalized
logs, Analytics, IOC and
BIOC alerts are only raised
on normalized logs.

Prisma Cloud
Raw data is searchable in Prisma Cloud alerts and Cortex XSIAM can Alerts from Prisma Cloud
XQL Search. assets are stitched with raise Cortex XSIAM alerts are raised
Cloud Provider logs when (Correlation Rules only) when throughout Cortex
relevant. relevant from logs. XSIAM when relevant.

Prisma Cloud Compute —

(alerts) Raw data is searchable in Cortex XSIAM can Alerts from Prisma Cloud
XQL Search. raise Cortex XSIAM alerts Compute are raised
(Correlation Rules only) when throughout Cortex
relevant from logs. XSIAM when relevant.

Endpoint logs

Vendor And Device Type Raw Data Visibility Normalized Log Visibility Cortex XSIAM Alert Visibility Vendor Alert Visibility

Windows Event Collector —

Windows event logs are Windows event logs are stitched Cortex XSIAM can
available with agent EDR data with agent EDR data and are raise Cortex XSIAM alerts
and are searchable in XQL searchable in the Query Builder. (Analytics, IOC, BIOC, and
Search. Correlation Rules) when
The Windows event logs are
relevant from logs.
The normalized Windows event also normalized into the
log data is also available common Cortex Windows event NOTE:
in microsoft_windows_raw and format
While Correlation Rules
is searchable in XQL Search. in microsoft_windows_raw and alerts are raised on non-
are searchable using the Query normalized and normalized
Builder. logs, Analytics, IOC and
BIOC alerts are only raised
on normalized logs.

Cloud assets

Vendor And Device Type Raw Data Visibility Normalized Log Visibility Cortex XSIAM Alert Visibility Vendor Alert Visibility

AWS — N/A N/A N/A

Google Cloud Platform — N/A N/A N/A

Microsoft Azure — N/A N/A N/A

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 598/1003
5/8/24, 9:18 AM PDF Export

Custom external sources

Vendor And Device Type Raw Data Visibility Normalized Log Visibility Cortex XSIAM Alert Visibility Vendor Alert Visibility

Any Vendor Sending CEF, —

LEEF, CISCO, Raw data is searchable in Cortex XSIAM can To enable Cortex XSIAM to
CORELIGHT, or RAW XQL Search. raise Cortex XSIAM alerts display alerts from other
formatted Syslog (Analytics, IOC, BIOC, and vendors, you must map
Correlation Rules) when your alert fields to
relevant from logs. the Cortex XSIAM field
format (see Ingest External
NOTE: Alerts).
While Correlation Rules
alerts are raised on non-
normalized and normalized
logs, Analytics, IOC and
BIOC alerts are only raised
on normalized logs.

Any vendor CSV files on a — —

shared Windows directory Raw data is searchable in Cortex XSIAM can
XQL Search. raise Cortex XSIAM alerts
(Correlation Rules only) when
relevant from logs.

Any vendor logs stored in a — —

database Raw data is searchable in Cortex XSIAM can
XQL Search. raise Cortex XSIAM alerts
(Correlation Rules only) when
relevant from logs.

Any vendor logs stored in — —

files on a network share Raw data is searchable in Cortex XSIAM can
XQL Search. raise Cortex XSIAM alerts
(Correlation Rules only) when
relevant from logs.

Any vendor logs from a — —

third party source over FTP, Raw data is searchable in Cortex XSIAM can
FTPS, or SFTP XQL Search. raise Cortex XSIAM alerts
(Correlation Rules only) when
relevant from logs.

Any vendor sending —

NetFlow flow records Raw data is searchable in NetFlow events are stitched Cortex XSIAM can
XQL Search. with the Agent’s EDR data raise Cortex XSIAM alerts
and other Network products (Analytics, IOC, BIOC, and
to a Session Story, and are Correlation Rules) when
searchable in the Query relevant from logs.
Builder and in XQL.
NOTE:

While Correlation Rules

alerts are raised on non-
normalized and normalized
logs, Analytics, IOC and
BIOC alerts are only raised
on normalized logs.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 599/1003
5/8/24, 9:18 AM PDF Export

Vendor And Device Type Raw Data Visibility Normalized Log Visibility Cortex XSIAM Alert Visibility Vendor Alert Visibility

Any vendor sending logs —

over HTTP Raw data is searchable in Cortex XSIAM can To enable Cortex XSIAM to
XQL Search. raise Cortex XSIAM alerts display alerts from other
(Correlation Rules only) when vendors, you must map
relevant from logs. your alert fields to
the Cortex XSIAM field
format (see Ingest External
Alerts).

Apache Kafka — —
Raw data is searchable in Cortex XSIAM can
XQL Search. raise Cortex XSIAM alerts
(Analytics, IOC, BIOC, and
Correlation Rules) when
relevant from logs.

NOTE:

While Correlation Rules

alerts are raised on non-
normalized and normalized
logs, Analytics, IOC and
BIOC alerts are only raised
on normalized logs.

BeyondTrust Privilege — —
Management Cloud Raw data is searchable in Cortex XSIAM can
XQL Search. raise Cortex XSIAM alerts
(Correlation Rules only) when
relevant from logs.

Box —
Raw data is searchable in Selected Box audit event Cortex XSIAM can
XQL Search. logs are normalized into raise Cortex XSIAM alerts
stories and are searchable (Analytics, IOC, BIOC, and
in the Query Builder and in Correlation Rules) when
XQL. relevant from logs.

NOTE:

While Correlation Rules

alerts are raised on non-
normalized and normalized
logs, Analytics, IOC and
BIOC alerts are only raised
on normalized logs.

Dropbox —
Raw data is searchable in Selected Box audit event Cortex XSIAM can
XQL Search. logs are normalized into raise Cortex XSIAM alerts
stories and are searchable (Analytics, IOC, BIOC, and
in the Query Builder and in Correlation Rules) when
XQL. relevant from logs.

NOTE:

While Correlation Rules

alerts are raised on non-
normalized and normalized
logs, Analytics, IOC and
BIOC alerts are only raised
on normalized logs.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 600/1003
5/8/24, 9:18 AM PDF Export

Vendor And Device Type Raw Data Visibility Normalized Log Visibility Cortex XSIAM Alert Visibility Vendor Alert Visibility

Elasticsearch Filebeat — —
Raw data is searchable in Cortex XSIAM can
XQL Search. raise Cortex XSIAM alerts
(Correlation Rules only) when
relevant from logs.

Forcepoint DLP — —
Raw data is searchable in Cortex XSIAM can
XQL Search. raise Cortex XSIAM alerts
(Correlation Rules only) when
relevant from logs.

IoT Security —
Raw data is searchable in Cortex XSIAM uses IoT Cortex XSIAM can
XQL Search. Security information to raise Cortex XSIAM alerts
improve analytics detection (Analytics, IOC, BIOC, and
and assets management Correlation Rules) when
information. relevant from logs.

NOTE:

While Correlation Rules

alerts are raised on non-
normalized and normalized
logs, Analytics, IOC and
BIOC alerts are only raised
on normalized logs.

Proofpoint Targeted Attack — —

Protection Raw data is searchable in Cortex XSIAMCortex XSIAM
XQL Search. alerts (Correlation Rules only)
when relevant from logs.

Salesforce.com — —
Raw data is searchable in Cortex XSIAM can
XQL Search. raise Cortex XSIAM alerts
(Correlation Rules only) when
relevant from logs.

ServiceNow CMDB — —
Raw data is searchable in Cortex XSIAMCortex XSIAM
XQL Search. alerts (Correlation Rules only)
when relevant from logs.

Strata Logging Service

Raw data is searchable in Detection events are Cortex XSIAM can Alerts from NGFW are
XQL Search. stitched with other Palo Alto raise Cortex XSIAM alerts raised throughout Cortex
Networks product logs to (Analytics, IOC, BIOC, and XSIAM when relevant.
stories, and are searchable Correlation Rules) when
in the Query Builder and in relevant from logs.
XQL.
NOTE:

While Correlation Rules

alerts are raised on non-
normalized and normalized
logs, Analytics, IOC and
BIOC alerts are only raised
on normalized logs.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 601/1003
5/8/24, 9:18 AM PDF Export

Vendor And Device Type Raw Data Visibility Normalized Log Visibility Cortex XSIAM Alert Visibility Vendor Alert Visibility

Workday — —
Raw data is searchable in Cortex XSIAMCortex XSIAM
XQL Search. alerts (Correlation Rules only)
when relevant from logs.

Any vendor sending alerts — — —

Alerts are surfaced
throughout Cortex XSIAM
when relevant. To
enable Cortex XSIAM to
display your alerts, you
must map your alert fields
to the Cortex XSIAM field
format (see Ingest External
Alerts).

Datasets created from ingesting data

When ingesting data from an external source, Cortex XSIAM creates a dataset that you can query using Cortex Query Language (XQL). Datasets created in this
way use the following naming convention.

<vendor_name>_<product_name>_raw

For example: cisco_asa_raw

The datatypes used for the fields in an imported dataset are automatically assigned based on the input content. Fields can have a datatype
of string, int, float, array, time, or boolean. All other fields are ingested as a JSON object.

For CEF type files, when extension values are quoted, the CEF parser automatically removes the quotes from the values. In addition, files containing invalid
UTF-8 are parsed under XQL mapping field _invalid_utf8.

8.2 | External Data Ingestion Vendor Support

Abstract

To augment your Cortex XSIAM data, you can set up Cortex XSIAM to ingest data from a variety of external third-party sources.

To provide you with a more complete and detailed picture of the activity involved in an incident, you can ingest data from a variety of external, third-party sources
into Cortex XSIAM.

Cortex XSIAM can receive logs, or both logs and alerts, from the source. Depending on the data source, Cortex XSIAM can provide visibility into your external
data in the form of:

Log stitching with other logs in order to create network or authentication stories.

Raw data in queries from XQL Search.

Alerts reported by the vendor throughout Cortex XSIAM, such as in the alerts table, incidents, and views.

Alerts raised by Cortex XSIAM on log data, such as analytics alerts.

To ingest data, you must set up the Syslog Collector applet on a Broker VM within your network.

The following table summarizes the vendor data that can be ingested, according to log or data type.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 602/1003
5/8/24, 9:18 AM PDF Export

Log/Data Type Vendor Support

Network Connections Amazon S3 (flow logs)

Amazon S3 (Route 53 logs)

Azure Event Hub

Azure Network Watcher (flow logs)

Check Point FW1/VPN1

Cisco ASA and Cisco AnyConnect VPN

Corelight Zeek

Fortinet Fortigate

Google Cloud Platform (flow logs, DNS logs)

Okta

Windows DHCP using Elasticsearch Filebeat

Zscaler Internet Access (ZIA)

Zscaler Private Access (ZPA)

Authentication Services/Audit Logs Amazon S3 (audit logs)

Azure Event Hub (audit logs, AKS)

Google Cloud Platform (audit logs, GKE)

Google Workspace

Microsoft Office 365

Okta

OneLogin

PingFederate

PingOne for Enterprise

Operation and System Logs from Cloud Providers Amazon S3 (generic logs)

Amazon CloudWatch (generic logs, EKS logs)

Azure Event Hub

Google Kubernetes Engine

Google Cloud Platform

Okta

Prisma Cloud (alerts and assets)

Prisma Cloud Compute (alerts)

Cloud Assets AWS

Google Cloud Platform

Microsoft Azure

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 603/1003
5/8/24, 9:18 AM PDF Export

Log/Data Type Vendor Support

Custom External Sources Any vendor sending CEF, LEEF, CISCO, CORELIGHT, or RAW
formatted Syslog

Any vendor CSV files on a shared Windows directory

Any vendor logs stored in a database

Any vendor logs stored in files on a network share

Any vendor logs from a third party source over FTP, FTPS, or SFTP

Any vendor sending NetFlow flow records

Any vendor sending logs over HTTP

Apache Kafka

BeyondTrust Privilege Management Cloud

Box

Dropbox

ElasticSearch Filebeat

Forcepoint DLP

IoT Security

Proofpoint Targeted Attack Protection

Salesforce.com

ServiceNow CMDB

Strata Logging Service

Workday

Any vendor sending alerts

8.3 | Palo Alto Networks Integrations

Abstract

Cortex XSIAM supports Palo Alto Networks data ingestion.

Cortex XSIAM supports streaming data directly from Prisma Access accounts, New-Generation Firewalls (NGFW), and Panorama devices to your Cortex
XSIAM tenants using the Cortex Native Data Lake.

Ensure you have deployed Panorama and NGFW, and hold Super User permissions to your Customer Support Account (CSP).

Once your tenant has been activated, navigate to the Data Sources page to configure your integrations. All devices and accounts allocated to your CSP
accounts are available to integrate.

NOTE:

For Palo Alto Networks Integrations there is an option to turn on or off the collection of URL and File log types. For more information, see Collecting URL and
File log types.

For tenants where a Strata Logging Service license exists, the configured integrations, such as Next-Generation Firewall and Prisma Access, can be migrated to
Cortex XSIAM in either of the following ways before the license expires:

More than two weeks before the license for existing integrations with Strata Logging Service expires, manually migrate the integrations, using the
corresponding Migrate Devices buttons on the Data Sources page. Make sure you select all your devices to connect directly to Cortex XSIAM.

Two weeks prior to the end of your Strata Logging Service license, Cortex XSIAM will automatically migrate your integrations to your Cortex Native Data
Lake.

NOTE:

Roll-back of Strata Logging Service integration migration is not supported.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 604/1003
5/8/24, 9:18 AM PDF Export

8.3.1 | Ingest Data from Next-Generation Firewall

Abstract

Learn how to ingest detection data from Next-Generation Firewall and Panorama.

You can forward firewall data from your Next-Generation Firewall (NGFW) and Panorama devices to Cortex XSIAM.

For tenants where a Strata Logging Service license exists, the configured integrations, such as Next-Generation Firewall and Prisma Access, can be migrated to
Cortex XSIAM in either of the following ways before the license expires:

More than two weeks before the license for existing integrations with Strata Logging Service expires, manually migrate the integrations, using the
corresponding Migrate Devices buttons on the Data Sources page. Make sure you select all your devices to connect directly to Cortex XSIAM.

Two weeks prior to the end of your Strata Logging Service license, Cortex XSIAM will automatically migrate your integrations to your Cortex Native Data
Lake.

NOTE:

Roll-back of Strata Logging Service integration migration is not supported.

Make sure you have completed the following on the NGFW or Panorama side:

Retrieve (CDL/LGS) license keys and push to devices.

For Panorama only, ensure that the Panorama Cloud Services plugin is installed.

In the user interface for setting up devices, for Strata Logging Service/Cloud Logging, enable the following options directly, or using device templates.

Enable Strata Logging Service

Enable Enhanced Application Logging

(Optional, depending on your organization's requirements) Enable Duplicate Logging (Cloud and On-Premise)

Enable log forwarding profiles on firewall rules.

NOTE:

Ingesting data Next-Generation Firewall requires a Cortex XSIAM license.

You can only stream data from firewalls allocated to the same Customer Support Account (CSP). Firewalls can only be paired to a Strata Logging Service
instance operating in the same region as the Cortex XSIAM tenant.

As soon as Cortex XSIAM begins receiving detection data, the console begins stitching logs with other Palo Alto Network-generated logs to form stories. Use the
XQL Search dataset panw_ngfw_*_raw to query your data, where the following logs are supported:

Authentication Logs—panw_ngfw_auth_raw

File Data Logs—panw_ngfw_filedata_raw

Global Protect Logs—panw_ngfw_globalprotect_raw

Hipmatch Logs—panw_ngfw_hipmatch_raw*

System Logs—panw_ngfw_system_raw

Threat Logs—panw_ngfw_threat_raw*

Traffic Logs—panw_ngfw_traffic_raw*

URL Logs—panw_ngfw_url_raw*

User ID Logs—panw_ngfw_userid_raw

*These datasets use the query field names as described in the Cortex schema documentation.

For stitched raw data, you can query the xdr_data dataset or use any preset designated for stitched data, such as network_story. For query examples, refer
to the in-app XQL Library. When relevant, Cortex XSIAM can also raise Cortex XSIAM alerts (Analytics, Correlation Rules, IOC, and BIOC only) from Strata
Logging Service detection data. While Correlation Rules alerts are raised on non-normalized and normalized logs, Analytics, IOC, and BIOC alerts are only
raised on normalized logs.

NOTE:

IOC and BIOC alerts are applicable on stitched data only and are not available on raw data.

To ingest detection data from NGFW or Panorama:

1. Select Settings → Data Sources.

2. On the Data Sources page, select Add Data Source, search for NGFW , and select Connect to begin a new connection.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 605/1003
5/8/24, 9:18 AM PDF Export

3. Select Add NGFW Device or Add Panorama Device.

A list of all available devices allocated to your account is displayed.

Devices already connected are listed at the end. A device may be connected via Strata Logging Service, or via Cortex XSIAM. Depending on the type of
connection, you can rectify any streaming issues that may arise.

4. Depending on your PAN-OS or Panorama version, generate either a certificate or PSK.

For PAN-OS and Panorama versions 10.1 and later, each firewall requires a separate certificate. Certificates need to be requested through the Customer
Support portal. To sign in to the portal, click here. For PAN-OS and Panorama versions 10.0 and earlier, you are only required to generate one global PSK
for all the firewall devices.

NOTE:

Cortex XSIAM does not validate your firewall credentials, you must ensure the certificates or PSK details have been updated in your firewalls in order
for data to stream.

5. Connect to establish the instance.

Connection is established regardless of the firewall credential status and can take up to several minutes, select Sync now to refresh your instances.

6. Validate that your data is streaming. It might be necessary to create traffic before you verify data streaming.

To ensure the data is streaming into your tenant:

In your NGFW Standalone Firewall Devices, track the Last communication timestamp.

Run XQL Query: dataset = panw_ngfw_system_raw| filter log_source_id = "[NGFW device SN]"

7. (Optional) Manage your Instance.

After you create the NGFW instance, on the Data Sources page, expand the NGFW to track the status of your Standalone Firewall Devices and
Panorama Devices.

Select the ellipses to Request Certificate, if required, or Delete the instance.

NOTE:

It might take an hour or longer after connecting the firewall in Cortex XSIAM until you start seeing notifications that the certificate has been approved, and that
the logging service license has appeared on the firewall.

TIP:

You can see an overview of ingestion status for all log types, and a breakdown of each log type and its daily consumption quota on the NGFW Ingestion
Dashboard.

8.3.2 | Ingest Data from Prisma Access

Abstract

Learn how to ingest detection data from Prisma Access.

You can forward data from Prisma Access to Cortex XSIAM. As soon as your Cortex XSIAM tenant begins receiving detection data, it begins stitching logs with
other Palo Alto Networks-generated logs to form stories. Use the XQL Search to query the data.

For tenants where a Strata Logging Service license exists, the configured integrations, such as Next-Generation Firewall and Prisma Access, can be migrated to
Cortex XSIAM in either of the following ways before the license expires:

More than two weeks before the license for existing integrations with Strata Logging Service expires, manually migrate the integrations, using the
corresponding Migrate Devices buttons on the Data Sources page. Make sure you select all your devices to connect directly to Cortex XSIAM.

Two weeks prior to the end of your Strata Logging Service license, Cortex XSIAM will automatically migrate your integrations to your Cortex Native Data
Lake.

NOTE:

Roll-back of Strata Logging Service integration migration is not supported.

NOTE:

Ingesting data Prisma Access requires a Cortex XSIAM license.

You can only stream data from firewalls allocated to the same Customer Support Account (CSP) in the same region.

To ingest detection data from Prisma Access.

1. Select Settings → Data Sources.

2. On the Data Sources page, select Add Data Source, search for Prisma Access, and select Connect to begin a new configuration.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 606/1003
5/8/24, 9:18 AM PDF Export

NOTE:

Cortex XSIAM does not validate your Prisma Access account credentials. You must ensure the account has been deployed in order for data to stream.

3. In the Connect Prisma Access dialog box, click Connect to establish the instance.

Connection can take up to several minutes.

On the Data Sources page, expand Prisma Access to track the status of your instance.

4. Validate that your data is streaming.

To ensure the data is streaming into your tenant, using XQL, query by: is_prisma_mobile.

5. (Optional) Manage your Instance.

After you create the Prisma Access instance, on the Data Sources page, expand the Prisma Access integration to track the connection, or, if you want, to
Delete the instance.

8.3.3 | Ingest Alerts from Prisma Cloud Compute

Abstract

Configure Data Collection Settings to receive alerts from Prisma Cloud Compute.

To receive alerts from Prisma Cloud Compute, first configure the Data Sources settings in Cortex XSIAM. In Prisma Cloud, you then must create a webhook,
which provides the mechanism to interface Prisma Cloud’s alert system with Cortex XSIAM . After you set up your webhook, Cortex XSIAM begins receiving
alerts from Prisma Cloud Compute.

Cortex XSIAM then groups these alerts into incidents and adds them to the Alerts table. When Cortex XSIAM begins receiving the alerts, it creates a new Cortex
Query Language (XQL) dataset (prisma_cloud_compute_raw), which you can use to initiate XQL Search queries and to create Correlation Rules. The in-app
XQL Library contain sample search queries.

Configure Cortex XSIAM to receive alerts from Prisma Cloud Compute.

1. Select Settings → Data Sources.

2. In the Prisma Cloud Compute Collector configuration, click Add Instance to begin a new alerts integration.

3. Specify the Name for the Prisma Cloud Compute Collector displayed in Cortex XSIAM.

4. Save & Generate Token. The token is displayed in a blue box, which is blurred in the image below.

Click the Copy icon next to the Username and Password, and record them in a safe place, as you will need to provide them when you configure the
Prisma Cloud Compute Collector for alerts integration. If you forget to record the key and close the window, you will need to generate a new key and
repeat this process. When you are finished, click Done to close the window.

5. Copy api url.

In the Data Sources page for the Prisma Cloud Compute Collector that you created, select Copy api url, and record it somewhere safe. You will need to
provide this API URL when you set the Incoming Webhook URL as part of the configuration in Prisma Cloud Compute.

NOTE:

The URL format for the tenant is https://api-<tenant name>.xdr.us.paloaltonetworks.com/logs/v1/prisma.

6. Create a webhook as explained in the Webhook Alerts section of the [Prisma Cloud Administrator’s Guide (Compute)].

a. Use the Webhook option to configure the webhook.

b. In Incoming Webhook URL, paste the API URL that you copied and recorded from Copy api url.

c. In Credential Options, select Basic Authentication, and use the Username and Password that you saved when you generated the token.

d. Select Container Runtime.

e. Click Save.

In Cortex XSIAM, once alerts start to come in, a green check mark appears underneath the Prisma Cloud Compute Collector configuration with the
amount of data received.

7. (Optional) Manage your Prisma Cloud Compute Collector.

After you enable the Prisma Cloud Compute Collector, you can make additional changes, as needed.

To modify a configuration, select any of the following options.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 607/1003
5/8/24, 9:18 AM PDF Export

Edit the Prisma Cloud Compute Collector settings.

Disable the Prisma Cloud Compute Collector.

Delete the Prisma Cloud Compute Collector.

8. After Cortex XSIAM begins receiving data from Prisma Cloud Compute, you can use XQL Search to search for specific data using the
prisma_cloud_compute_raw dataset and view alerts in the Alerts table. In the Cortex XSIAM Alerts table, the Prisma Cloud Compute alerts are listed as
Prisma Cloud Compute in the ALERT SOURCE column and are classified as Medium in the SEVERITY column.

8.3.4 | Ingest Alerts and Assets from Prisma Cloud

Abstract

Configure Data Collection Settings in Cortex XSIAM to receive alerts and assets from Prisma Cloud.

To receive alerts and assets from Prisma Cloud, first configure the Data Sources settings in Cortex XSIAM. After you set up collection integration, Cortex XSIAM
begins to receive alerts and assets from Prisma Cloud every 30 seconds.

Cortex XSIAM then groups these alerts and assets into incidents and adds them to the Alerts table and the Unified Asset Inventory table. When Cortex XSIAM
begins receiving the alerts, it creates a new Cortex Query Language (XQL) dataset (prisma_cloud_raw), which you can use to initiate XQL Search queries and
create Correlation Rules. The in-app XQL Library contains sample search queries.

You can also configure Cortex XSIAM to collect data directly from other cloud providers using an applicable collector. For more information on the cloud
collectors, see External Data Ingestion Vendor Support. The Prisma Cloud alerts are stitched to this data.

Complete the following tasks before you begin configuring Cortex XSIAM to receive alerts from Prisma Cloud.

Create an Access Key and Secret Key as explained in the Create and Manage Access Keys section of the [Prisma Cloud Administrator’s Guide].

Copy or download the Access Key ID and Secret Key as you will need them when configuring the Prisma Cloud Collector in Cortex XSIAM.

Configure Cortex XSIAM to receive alerts and assets from Prisma Cloud.

1. Select Settings → Data Sources.

2. In the Prisma Cloud Collector configuration, click Add Instance to begin a new configuration.

3. Set the following parameters.

Specify a Name to identify the connection.

Specify the Domain URL for Prisma Cloud.

NOTE:

You can find your default Prisma Cloud domain in the Prisma Cloud API URL table.

Specify the Prisma Cloud Access Key Id that you received when you created an Access Key.

Specify the Prisma Cloud Secret Key that you received when you created an Access Key.

4. To collect Prisma Cloud alerts, select Fetches alerts.

5. To collect Prisma Cloud assets and vulnerabilities, select Fetch assets and vulnerabilities.

6. Click Test to validate the connection, and then click Enable.

In Cortex XSIAM, once alerts start to come in, a green check mark appears underneath the Prisma Cloud Collector configuration with the amount of data
received.

7. (Optional) Manage your Prisma Cloud Collector.

After you enable the Prisma Cloud Collector, you can make additional changes, as needed.

To modify a configuration, select any of the following options.

Edit the Prisma Cloud Collector settings.

Disable the Prisma Cloud Collector.

Delete the Prisma Cloud Collector.

8. After Cortex XSIAM begins receiving data from Prisma Cloud, you can use XQL Search to search for specific data, using the prisma_cloud_raw dataset
and to view alerts in the Alerts table. In the Cortex XSIAM Alerts table, the Prisma Cloud alerts are listed as Prisma Cloud in the ALERT SOURCE column.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 608/1003
5/8/24, 9:18 AM PDF Export

8.3.5 | Ingest Detection Data from Strata Logging Service

Abstract

Learn how to ingest detection data from Strata Logging Service.

NOTE:

Ingesting logs from Strata Logging Service requires an XSIAM license.

NOTE:

This topic is only relevant for tenants that have a Strata Logging Service license. If you do not have a Strata Logging Service license, this option is not
available, and you need to configure each Palo Alto Networks integration, such as New Generation Firewalls (NGFW) and Prisma Access, separately.

Existing Strata Logging Service integrations can be migrated to the Cortex Native Data Lake up to two weeks before your Strata Logging Service license
expires, using the Migrate Devices buttons on the Data Sources page. Make sure you select all your devices to connect directly to Cortex XSIAM.

If you do not manually migrate your Strata Logging Service integrations, they will be migrated automatically two weeks before the end of the Strata Logging
Service contract.

Roll-back of Strata Logging Service is not supported.

To streamline the connection and management of all Palo Alto Networks generated logs across products in Cortex XSIAM with a Strata Logging Service license,
Cortex XSIAM can ingest detection data from Strata Logging Service using the Strata Logging Service data collector.

You can configure the Strata Logging Service data collector to take logs from other Palo Alto Networks products already logging to one or more existing Strata
Logging Service instance.

For stitched raw data, use the XQL query xdr_data dataset or any preset designated for stitched data, such as network_story. For query examples, refer to
the in-app XQL Library. Cortex XSIAM can also raise Cortex XSIAM alerts (Analytics, Correlation Rules, IOC, and BIOC only), when relevant, from Strata
Logging Service detection data. While Correlation Rules alerts are raised on non-normalized and normalized logs, Analytics, IOC, and BIOC alerts are only
raised on normalized logs.

NOTE:

IOC and BIOC alerts are applicable on stitched data only and are not available on raw data.

To ingest detection data from Strata Logging Service.

1. Activate Strata Logging Service.

You can configure Cortex XSIAM to take Palo Alto generated firewall logs from other Palo Alto Networks products already logging to an existing Strata
Logging Service instance.

2. Select Settings → Data Sources.

3. In the Strata Logging Service configuration, click Add Instance to begin a new configuration.

4. Select Strata Logging Service Instance.

Select one or more existing Strata Logging Service instances that you want to connect to this Strata Logging Service instance.

5. Save your Strata Logging Service configuration.

Once events start to come in, a green check mark appears underneath the Strata Logging Service configuration.

6. (Optional) Manage your Strata Logging Service Collector.

After you create the Strata Logging Service Collector, you can make additional changes, as needed.

Delete the Strata Logging Service Collector.

7. After Cortex XSIAM begins receiving data from a Strata Logging Service instance, you can use XQL Search to search for specific data, using the
xdr_data dataset.

8.3.6 | Ingest Alerts and Assets from IoT Security

Abstract

Ingest alerts and device data from IoT Security.

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.

To receive data, configure the Data Sources settings in Cortex XSIAM for the IoT Security data collector in Settings → Data Sources.

As soon as data collection begins, Cortex XSIAM displays the IoT Security alerts in the Cortex XSIAM Alerts table and groups them into Incidents. The IoT
Security alerts are updated every 15 minutes. IoT security alerts which were resolved before the integration aren’t added to the Cortex XSIAM table. Cortex

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 609/1003
5/8/24, 9:18 AM PDF Export

XSIAM adds device activities detected by IoT Security into the Cortex XDRCortex XSIAM Assets table. Device activities are updated every five minutes.

Cortex XSIAM automatically creates a new dataset for device activities (panw_iot_security_devices_raw) and a new dataset for alerts
(panw_iot_security_alerts_raw), which you can use to initiate XQL Search queries and create Correlation Rules.

Before you configure the IoT Security 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.

Configure the IoT Security alerts and assets collection in Cortex XSIAM.

1. Select Settings → Configurations → Data Collection → Data Sources.

2. In the IoT Security Collector configuration, click Add Instance to begin a new configuration.

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 Collectorconfiguration with the data and time that the data was
last synced.

5. (Optional) Manage your IOT Security Collector.

After you enable the IOT Security Collector, you can make additional changes as needed. To modify a configuration, select any of the following options.

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

8.3.7 | Collecting URL and File log types

Abstract

Learn about the implications of turning off or on collection of URL and File logs.

For Palo Alto Networks integrations, you can choose whether to collect URL and File type logs. These logs enhance your cyber analytics, correlation rules and
visibility for investigation. However, if you want to reduce ingestion charges, you can globally turn off collection of URL and File log types for all PALO ALTO
NETWORKS INTEGRATIONS.

When collection is turned off, some detectors won’t detect cyber attacks or provide full context, and correlation rules won’t be able to detect cyber events. For a
full list of affected detectors, see Detectors connected to URL and File log types.

You can also calculate the amount of ingestion that URL and File log types are consuming by looking at the NGFW dashboard. This dashboard provides an
overview of the PAN-NGFW ingestion status of all log types (including URL and File log types) and their daily consumption quota. For more information, see
NGFW Ingestion Dashboard.

You can turn on or off URL and File log types collection on the Data Sources page.

8.3.7.1 | Detectors connected to URL and File log types

Abstract

A list of detectors connected to URL and File log types.

If you turn off URL and File log types collection, some detectors are unable to detect cyber attacks or provide full context, and correlation rules are unable to
detect cyber events.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 610/1003
5/8/24, 9:18 AM PDF Export

The following detectors are affected by URL logs:

Read more...

A non-browser process accessed a website UI

Reverse SSH tunnel to external domain/IP

Uncommon network tunnel creation

Suspicious domain fronting behavior

Possible watering hole SMB credential theft

Rare connection to external IP address or host by an application using RMI-IIOP or LDAP protocol

Uncommon JA3 SSL fingerprint communication to an instant messaging server

PowerShell Initiates a Network Connection to GitHub

Non-browser failed access to a pastebin-like site

Non-browser access to a pastebin-like site

C2 from contextual causality signal

Massive upload to a rare storage or mail domain

DNS Tunneling

The following detectors are affected by File logs:

Read more...

Rare AppID usage to a rare destination

Abnormal network communication through TOR using an uncommon port

Recurring access to rare IP

Possible network connection to a TOR relay server

A user accessed an uncommon AppID

Large Upload (Generic)

Large Upload (FTP)

Large Upload (SMTP)

Possible network connection to a TOR relay server

A user accessed a resource for the first time via SSO - silent

Access to a domain that is categorized as malicious - silent

Recurring access to rare domain categorized as malicious - silent

Cloud Large Upload (Generic) - disabled

8.4 | External Data Ingestion

Abstract

Cortex XSIAM supports external data ingestion for a variety of service types and vendors.

Cortex XSIAM supports external data ingestion for a variety of service types and vendors.

To ensure complete and uninterrupted data ingestion, Cortex XSIAM collects granular data ingestion metrics and creates ingestion alerts if disruption is
identified in data collection. For more information, see Monitoring Data Ingestion Health.

8.4.1 | External Applications

Abstract

Learn more about integrating Slack and a Syslog Receiver to Cortex XSIAM.

You can integrate the following external applications to manage notifications:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 611/1003
5/8/24, 9:18 AM PDF Export

Slack: To send outbound notifications to Slack. For more information, see Integrate Slack for Outbound Notifications.

Syslog server: To send Cortex XSIAM notifications to your Syslog server. For more information, see Integrate a Syslog Receiver.

8.4.2 | Onboarding data sources

Abstract

Explains how to onboard data sources and instances from the Data Source page.

On this page you can see all data sources with configured instances, grouped by integration. Data sources are categorized into PALO ALTO NETWORKS
INTEGRATIONS and 3RD PARTY INTEGRATIONS.

Click on a data source name to see information about its configured instances and their status. You can filter the list of data sources, or search by integration,
content pack, or instance name. You can also onboard new data sources and instances.

Access the Data Source page from Settings → Data Sources or Settings → Configurations → Data Collection → Data Sources.

From this page you can:

+ Add Data Source with the Data Source Onboarder.

The Onboarder provides a simplified integration setup page that automatically installs the required Marketplace packs and recommends additional
content, such as playbooks and dashboards, that are relevant to the selected data source.

+ Add New Instance for an integrated data source.

Review and take actions on existing instances.

You can refresh log data, edit, delete, enable, or disable the instance.

Globally turn on or off URL and File log types collection for Palo Alto Networks integrations.

For more information, see the following topics:

Adding a new data source or instance

Managing Instances

Palo Alto Networks Integrations

Collecting URL and File log types

8.4.2.1 | Adding a new data source or instance

You can add a new data source with the Data Source Onboarder. The Onboarder installs the data source, sets up an instance, configures playbooks and scripts,
and other recommended content. The Onboarder offers default (customizable) options, and displays all configured content in a summary screen at the end of
the process.

1. Select Settings → Data Sources.

2. Select one of the following options:

+ Add Data Source

+ Add New Instance for an integrated data source by clicking the menu in the right corner of an existing data source. Then skip to Step 4.

3. Select a data source to onboard and click Connect.

Hovering over a data source displays information about the data source and its integrations. Data sources that are already integrated are highlighted
green and show Connect Another Instance. To see details of existing integrations, click on the number of integrations.

The data sources are drawn from the Marketplace, Custom Collectors, and integrations. If you search for a data source and No Data Sources Found, click
Try searching the Marketplace, to view the marketplace page prefiltered for your search. If there are no available options in the Marketplace, you can use
one of the Custom Collectors to build your own.

NOTE:

Only data sources with a single integration are listed.

Not all Content packs are supported.

When adding XDR data sources the Data Source Onboarder is not available, however, you can still enable the data source. Cortex XSIAM then
creates an instance and lists it on the Data Sources page.

4. In the New Data Source window, complete the mandatory fields in the Connect section.

For more information about the fields, click the question mark icon.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 612/1003
5/8/24, 9:18 AM PDF Export

5. (Optional) Under Collect, select Fetched alerts and complete the fields.

6. Under Recommended Content, review and customize the options.

The items in this section are content specific. Some options are view only and others are customizable. Click on each option for more information:

Classifiers & Mappers

Data Normalization: Parsing rules and data models

Correlations: Correlation rules included in the pack

Automation: Playbooks and Scripts included in the pack.

You can select the Playbooks and Scripts that you want to enable. By default, recommended options are selected. Any unselected content is added
as disabled content. Depending on the selected playbook, some scripts are mandatory.

Dashboards & Reports: Recommended dashboards, widgets, and reports

NOTE:

If you are adding a new instance to an existing data source, these options are View only.

You can adjust the view only options on the relevant page in the system, for example Correlations, Playbooks, or Scripts.

Cortex XSIAM automatically installs content packs with required dependencies and updates any pre-installed optional content packs. You can
also Select additional content packs with optional dependencies to be configured during connection.

7. Test the configuration.

If the test fails, you can Run Test & Download Debug Log to debug the error.

8. Connect the data source.

9. Review the configuration in the summary screen.

If errors occurred during the test, you can click See Details and Back to Edit to revise your configuration. For advanced configuration, click on an items to
open a new window to the relevant page in the system (for example, Correlations or Playbooks) filtered by the configuration.

10. Click Finish to return to the Data Sources page.

8.4.2.2 | Managing Instances

You can manage the Instances configured for a Data Source on the Data Sources page. You can edit, delete, enable, or disable instances, and refresh log data.

1. Select Settings → Data Sources.

2. Find an instance by clicking on a Data Source name or using the Search field.

3. In the row for the instance name, take the required action:

Action Instructions

Enable or disable an Select or deselect the Enable checkbox.

Instance

Refresh log data Click the Refresh icon.

Edit an Instance a. Click the Edit icon.

b. In Edit Data Source, you can update the values in the Connect and Collect sections. The options under
Recommended Content are view only.

c. Test the configuration.

d. Connect the updated Instance.

Delete an Instance Click the Delete icon.

If you delete all the instances for a Data Source, the Data Source is not listed on the Data Sources page.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 613/1003
5/8/24, 9:18 AM PDF Export

8.4.3 | Ingest Network Connection Logs

Abstract

Cortex XSIAM can ingest network connection logs from different third-party sources.

You can ingest network connection logs from different third-party sources.

8.4.3.1 | Ingest Network Flow Logs from Amazon S3

Abstract

Take advantage of Cortex XSIAM investigation capabilities and set up network flow log ingestion for your Amazon S3 logs using an AWS CloudFormation Script.

You can forward network flow logs to Cortex XSIAM from Amazon Simple Storage Service (Amazon S3).

To receive network flow logs from Amazon S3, you must first configure data collection from Amazon S3. You can then configure the Data Sources settings in
Cortex XSIAM for Amazon S3. After you set up collection integration, Cortex XSIAM begins receiving new logs and data from the source.

You can either configure Amazon S3 with SQS notification manually on your own or use the AWS CloudFormation Script that we have created for you to make
the process easier. The instructions below explain how to configure Cortex XSIAM to receive network flow logs from Amazon S3 using SQS. To perform these
steps manually, see Configure Data Collection from Amazon S3 Manually.

NOTE:

For more information on configuring data collection from Amazon S3, see the Amazon S3 Documentation.

As soon as Cortex XSIAM begins receiving logs, the app automatically creates an Amazon S3 Cortex Query Language (XQL) dataset (aws_s3_raw). This
enables you to search the logs with XQL Search using the dataset. For example, queries refer to the in-app XQL Library. For enhanced cloud protection, you
can also configure Cortex XSIAM to ingest network flow logs as Cortex XSIAM network connection stories, which you can query with XQL Search using the
xdr_data dataset with the preset called network_story. Cortex XSIAM can also raise Cortex XSIAM alerts (Analytics, Correlation Rules, IOC, and BIOC) when
relevant from Amazon S3 logs. While Correlation Rules alerts are raised on non-normalized and normalized logs, Analytics, IOC, and BIOC alerts are only
raised on normalized logs.

Enhanced cloud protection provides the following:

Normalization of cloud logs

Cloud logs stitching

Enrichment with cloud data

Detection based on cloud analytics

Cloud-tailored investigations

Be sure you do the following tasks before you begin configuring data collection from Amazon S3 using the AWS CloudFormation Script.

Ensure that you have the proper permissions to run AWS CloudFormation with the script provided in Cortex XSIAM. You need at a minimum the following
permissions in AWS for an Amazon S3 bucket and Amazon Simple Queue Service (SQS):

Amazon S3 bucket—GetObject

SQS—ChangeMessageVisibility, ReceiveMessage, and DeleteMessage.

Ensure that you can access your Amazon Virtual Private Cloud (VPC) and have the necessary permissions to create flow logs.

Determine how you want to provide access to Cortex XSIAM to your logs and perform API operations. You have the following options:

Designate an AWS IAM user, where you will need to know the Account ID for the user and have the relevant permissions to create an access key/id
for the relevant IAM user. This is the default option as explained in Configure the Amazon S3 Collection in Cortex XSIAM by selecting Access Key.

Create an assumed role in AWS to delegate permissions to a Cortex XSIAM AWS service. This role grants Cortex XSIAM access to your flow logs.
For more information, see Creating a role to delegate permissions to an AWS service. This is the Assumed Role option as described in the
Configure the Amazon S3 collection in Cortex XSIAM. For more information on creating an assumed role for Cortex XSIAM, see Create an
Assumed Role.

To collect Amazon S3 logs that use server-side encryption (SSE), the user role must have an IAM policy that states that Cortex XSIAM has kms:Decrypt
permissions. With this permission, Amazon S3 automatically detects if a bucket is encrypted and decrypts it. If you want to collect encrypted logs from
different accounts, you must have the decrypt permissions for the user role also in the key policy for the master account Key Management Service (KMS).
For more information, see Allowing users in other accounts to use a KMS key.

Configure Cortex XSIAM to receive network flow logs from Amazon S3 using the CloudFormation Script.

1. Download the CloudFormation Script in Cortex XSIAM .

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 614/1003
5/8/24, 9:18 AM PDF Export

a. Select Settings → Configurations → Data Collection → Data Sources.

b. In the Amazon S3 configuration, click Add Instance to begin a new configuration.

c. To provide access to Cortex XSIAM to your logs and to perform API operations using a designated AWS IAM user, leave the Access Key option
selected. Otherwise, select Assumed Role, and ensure that you Create an Assumed Role for before continuing with these instructions.

d. For the Log Type, select Flow Logs to configure your log collection to receive network flow logs from Amazon S3, and the following text is displayed
under the field Download CloudFormation Script. See instructions here.

e. Click the Download CloudFormation Script. link to download the script to your computer.

2. Create a new Stack in the CloudFormation Console with the script you downloaded from Cortex XSIAM.

For more information on creating a Stack, see Creating a stack on the AWS CloudFormation console.

a. Log in to the CloudFormation Console.

b. From the CloudFormation → Stacks page, ensure that you have selected the correct region for your configuration.

c. Select Create Stack → With new resources (standard).

d. Specify the template that you want AWS CloudFormation to use to create your stack. This template is the script that you downloaded from Cortex
XSIAM , which will create an Amazon S3 bucket, Amazon Simple Queue Service (SQS) queue, and Queue Policy. Configure the following settings
in the Specify template page.

Prerequisite - Prepare template → Prepare template—Select Template is ready.

Specify Template

Template source—Select Upload a template file.

Upload a template file—Choose file, and select the cortex-xdr-create-s3-with-sqs-flow-logs.json file that you downloaded
from Cortex XDR.

e. Click Next.

f. In the Specify stack details page, configure the following stack details.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 615/1003
5/8/24, 9:18 AM PDF Export

Stack name—Specify a descriptive name for your stack.

Parameters → Cortex XDR Flow Logs Integration

Bucket Name—Specify the name of the S3 bucket to create, where you can leave the default populated name as xdr-flow-logs or
create a new one. The name must be unique.

Publisher Account ID—Specify the AWS IAM user account ID with whom you are sharing access.

Queue Name—Specify the name for your Amazon SQS queue to create, where you can leave the default populated name as xdr-flow
or create a new one. The name must be unique.

g. Click Next.

h. In the Configure stack options page, there is nothing to configure, so click Next.

i. In the Review page, look over the stack configurations settings that you have configured and if they are correct, click Create stack. If you need to
make a change, click Edit beside the particular step that you want to update.

The stack is created and is opened with the Events tab displayed. It can take a few minutes for the new Amazon S3 bucket, SQS queue, and Queue
Policy to be created. Click Refresh to get updates. Once everything is created, leave the stack opened in the current browser as you will need to
access information in the stack for other steps detailed below.

NOTE:

For the Amazon S3 bucket created using CloudFormation, it is the customer’s responsibility to define a retention policy by creating a Lifecycle
rule in the Management tab. We recommend setting the retention policy to at least 7 days to ensure that the data is retrieved under all
circumstances.

3. Configure your Amazon Virtual Private Cloud (VPC) with flow logs:

1. Open the Amazon VPC Console, and in the Resources by Region listed, select VPCs to view the VPCs configured for the current region selected.
To select another VPC from another region, select See all regions, and select one of them.

NOTE:

To create a new VPC, click Launch VPC Wizard. For more information, see AWS VPC Flow Logs.

2. From the list of Your VPCs, select the checkbox beside the VPC that you want to configure to create flow logs, and then select Actions → Create
flow log.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 616/1003
5/8/24, 9:18 AM PDF Export

3. Configure the following Flow log settings:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 617/1003
5/8/24, 9:18 AM PDF Export

Name - optional—(Optional) Specify a descriptive name for your VPC flow log.

Filter—Select All types of traffic to capture.

Maximum aggregation interval—If you anticipate a heavy flow of traffic, select 1 minute. Otherwise, leave the default setting as 10 minutes.

Destination—Select Send to an Amazon S3 bucket as the destination to publish the flow log data.

S3 bucket ARN—Specify the Amazon Resource Name (ARN) for your Amazon S3 bucket.

You can retrieve your bucket’s ARN by opening another instance of the AWS Management Console in a browser window and opening the
Amazon S3 console. In the Buckets section, select the bucket that you created for collecting the Amazon S3 flow logs when you created your
stack, click Copy ARN, and paste the ARN in this field.

Log record format—Select Custom Format, and in the Log Format field, specify the following fields to include in the flow log record, which you
can select from the list displayed:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 618/1003
5/8/24, 9:18 AM PDF Export

account-id

action

az-id

bytes

dstaddr

dstport

end

flow-direction

instance-id

interface-id

packets

log-status

pkt-srcaddr

pkt-dstaddr

protocol

region

srcaddr

srcport

start

sublocation-id

sublocation-type

subnet-id

tcp-flags

type

vpc-id

version

4. Click Create flow log.

Once the flow log is created, a message indicating that the flow log was successfully created is displayed at the top of the Your VPCs page.

In addition, if you open your Amazon S3 bucket configurations, by selecting the bucket from the Amazon S3 console, the Objects tab contains a
folder called AWSLogs/ to collect the flow logs.

4. Configure access keys for the AWS IAM user that Cortex XSIAM uses for API operations.

NOTE:

It is the responsibility of the customer’s organization to ensure that the user who performs this task of creating the access key is designated with
the relevant permissions. Otherwise, this can cause the process to fail with errors.

Skip this step if you are using an Assumed Role for Cortex XSIAM.

1. Open the AWS IAM Console, and in the navigation pane, select Access management → Users.

2. Select the User name of the AWS IAM user.

3. Select the Security credentials tab, scroll down to the Access keys section, and click Create access key.

4. Click the copy icon next to the Access key ID and Secret access key keys, where you must click Show secret access key to see the secret key and
record them somewhere safe before closing the window. You will need to provide these keys when you edit the Access policy of the SQS queue and
when setting the AWS Client ID and AWS Client Secret in Cortex XSIAM. If you forget to record the keys and close the window, you will need to
generate new keys and repeat this process.

NOTE:

For more information, see Managing access keys for IAM users.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 619/1003
5/8/24, 9:18 AM PDF Export

5. When you create an Assumed Role in Cortex XSIAM, ensure that you edit the policy that defines the permissions for the role with the S3 Bucket ARN and
SQS ARN, which is taken from the Stack you created.

NOTE:

Skip this step if you are using an Access Key to provide access to Cortex XSIAM.

6. Configure the Amazon S3 collection in Cortex XSIAM.

a. Select Settings → Configurations → Data Collection → Data Sources.

b. In the Amazon S3 configuration, click Add Instance to begin a new configuration.

c. Set these parameters, where the parameters change depending on whether you configured an Access Key or Assumed Role.

SQS URL—Specify the SQS URL, which is taken from the stack you created. In the browser you left open after creating the stack, open the
Outputs tab, copy the Value of the QueueURL and paste it in this field.

Name—Specify a descriptive name for your log collection configuration.

When setting an Access Key, set these parameters.

AWS Client ID—Specify the Access key ID, which you received when you created access keys for the AWS IAM user in AWS.

AWS Client Secret—Specify the Secret access key you received when you created access keys for the AWS IAM user in AWS.

When setting an Assumed Role, set these parameters.

Role ARN—Specify the Role ARN for the Assumed Role you created for in AWS.

External Id—Specify the External Id for the Assumed Role you created for in AWS.

Log Type—Select Flow Logs to configure your log collection to receive network flow logs from Amazon S3. When configuring network flow log
collection, the following additional field is displayed for Enhanced Cloud Protection.

You can Normalize and enrich flow logs by selecting the checkbox. If selected, Cortex XSIAM ingests the network flow logs as XDR network
connection stories, which you can query using XQL Search from the xdr_data dataset using the preset called network_story.

d. Click Test to validate access, and then click Enable.

Once events start to come in, a green check mark appears underneath the Amazon S3 configuration with the number of logs received.

8.4.3.1.1 | Create an Assumed Role

Topic Not Found

8.4.3.1.2 | Configure Data Collection from Amazon S3 Manually

Abstract

Set up network flow log ingestion for your Amazon S3 logs manually (without a script).

There are various reasons why you may need to configure data collection from Amazon S3 manually, as opposed to using the CloudFormation Script provided in
Cortex XSIAM. For example, if your organization does not use CloudFormation scripts, you will need to follow the instructions below, which explain at a high-
level how to perform these steps manually with a link to the relevant topic in the Amazon S3 documentation with the detailed steps to follow.

As soon as Cortex XSIAM begins receiving logs, the app automatically creates an Amazon S3 Cortex Query Language (XQL) dataset (aws_s3_raw). This
enables you to search the logs with XQL Search using the dataset. For example queries, refer to the in-app XQL Library. For enhanced cloud protection, you
can also configure Cortex XSIAM to ingest network flow logs as Cortex XSIAM network connection stories, which you can query with XQL Search using the
xdr_dataset dataset with the preset called network_story. Cortex XSIAM can also raise Cortex XSIAM alerts (Analytics, Correlations, IOC, and BIOC) when
relevant from Amazon S3 logs. While Correlation Rules alerts are raised on non-normalized and normalized logs, Analytics, IOC, and BIOC alerts are only
raised on normalized logs.

Enhanced cloud protection provides:

Normalization of cloud logs

Cloud logs stitching

Enrichment with cloud data

Detection based on cloud analytics

Cloud-tailored investigations

Be sure you do the following tasks before you begin configuring data collection manually from Amazon CloudWatch to Amazon S3.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 620/1003
5/8/24, 9:18 AM PDF Export

NOTE:

If you already have an Amazon S3 bucket configured with VPC flow logs that you want to use for this configuration, you do not need to perform the
prerequisite steps detailed in the first two bullets.

Ensure that you have at a minimum the following permissions in AWS for an Amazon S3 bucket and Amazon Simple Queue Service (SQS).

Amazon S3 bucket—GetObject

SQS—ChangeMessageVisibility, ReceiveMessage, and DeleteMessage.

Create a dedicated Amazon S3 bucket for collecting network flow logs with the default settings. For more information, see Creating a bucket using the
Amazon S3 Console.

NOTE:

It is the customer’s responsibility to define a retention policy for your Amazon S3 bucket by creating a Lifecycle rule in the Management tab. We
recommend setting the retention policy to at least 7 days to ensure that the data is retrieved under all circumstances.

Ensure that you can access your Amazon Virtual Private Cloud (VPC) and have the necessary permissions to create flow logs.

Determine how you want to provide access to Cortex XSIAM to your logs and perform API operations. You have the following options.

Designate an AWS IAM user, where you will need to know the Account ID for the user and have the relevant permissions to create an access key/id
for the relevant IAM user. This is the default option as explained in Configure the Amazon S3 collection by selecting Access Key.

Create an assumed role in AWS to delegate permissions to a Cortex XSIAM AWS service. This role grants Cortex XSIAM access to your flow logs.
For more information, see Creating a role to delegate permissions to an AWS service. This is the Assumed Role option as described in the
Configure the Amazon S3 collection. For more information on creating an assumed role for Cortex XSIAM , see Create an Assumed Role.

To collect Amazon S3 logs that use server-side encryption (SSE), the user role must have an IAM policy that states that Cortex XSIAM has kms:Decrypt
permissions. With this permission, Amazon S3 automatically detects if a bucket is encrypted and decrypts it. If you want to collect encrypted logs from
different accounts, you must have the decrypt permissions for the user role also in the key policy for the master account Key Management Service (KMS).
For more information, see Allowing users in other accounts to use a KMS key.

Configure Cortex XSIAM to receive network flow logs from Amazon S3 manually.

1. Log in to the AWS Management Console.

2. From the menu bar, ensure that you have selected the correct region for your configuration.

3. Configure your Amazon Virtual Private Cloud (VPC) with flow logs. For more information, see AWS VPC Flow Logs.

NOTE:

If you already have an Amazon S3 bucket configured with VPC flow logs, skip this step and go to Configure an Amazon Simple Queue Service (SQS).

4. Configure an Amazon Simple Queue Service (SQS). For more information, see Configuring Amazon SQS queues (console).

NOTE:

Ensure that you create your Amazon S3 bucket and Amazon SQS queue in the same region.

5. Configure an event notification to your Amazon SQS whenever a file is written to your Amazon S3 bucket. For more information, see Amazon S3 Event
Notifications.

6. Configure access keys for the AWS IAM user that Cortex XSIAM uses for API operations. For more information, see Managing access keys for IAM users.

NOTE:

It is the responsibility of the customer’s organization to ensure that the user who performs this task of creating the access key is designated with
the relevant permissions. Otherwise, this can cause the process to fail with errors.

Skip this step if you are using an Assumed Role for Cortex XSIAM.

7. Update the Access Policy of your SQS queue and grant the required permissions mentioned above to the relevant IAM user. For more information, see
Granting permissions to publish event notification messages to a destination.

NOTE:

Skip this step if you are using an Assumed Role for Cortex XSIAM.

8. Configure the Amazon S3 collection in Cortex XSIAM.

a. Select Settings → Configurations → Data Collection → Data Sources.

b. In the Amazon S3 configuration, click Add Instance to begin a new configuration.

c. Set these parameters, where the parameters change depending on whether you configured an Access Key or Assumed Role.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 621/1003
5/8/24, 9:18 AM PDF Export

To provide access to Cortex XSIAM to your logs and perform API operations using a designated AWS IAM user, leave the Access Key option
selected. Otherwise, select Assumed Role, and ensure that you Create an Assumed Role for Cortex XSIAM before continuing with these
instructions. In addition, when you create an Assumed Role for Cortex XSIAM, ensure that you edit the policy that defines the permissions for
the role with the Amazon S3 Bucket ARN and SQS ARN.

SQS URL—Specify the SQS URL, which is the ARN of the Amazon SQS that you configured in the AWS Management Console. For more
information on how to retrieve your Amazon SQS ARN, see the Specify SQS queue field when you configure an event notification to your
Amazon SQS whenever a file is written to your Amazon S3 bucket.

Name—Specify a descriptive name for your log collection configuration.

When setting an Access Key, set these parameters.

AWS Client ID—Specify the Access key ID, which you received when you created access keys for the AWS IAM user in AWS.

AWS Client Secret—Specify the Secret access key you received when you created access keys for the AWS IAM user in AWS.

When setting an Assumed Role, set these parameters.

Role ARN—Specify the Role ARN for the Assumed Role for Cortex XSIAM in AWS.

External Id—Specify the External Id for the Assumed Role for Cortex XSIAM in AWS.

Log Type—Select Flow Logs to configure your log collection to receive network flow logs from Amazon S3. When configuring network flow log
collection, the following additional field is displayed for Enhanced Cloud Protection.

You can Normalize and enrich flow logs by selecting the checkbox. When selected, Cortex XSIAM ingests the network flow logs as Cortex
XSIAM network connection stories, which you can query using XQL Search from the xdr_dataset dataset using the preset called
network_story.

d. Click Test to validate access, and then click Enable.

Once events start to come in, a green check mark appears underneath the Amazon S3 configuration with the number of logs received.

8.4.3.2 | Ingest Network Route 53 Logs from Amazon S3

Abstract

Take advantage of Cortex XSIAM investigation capabilities and set up network Route 53 ingestion for your Amazon S3 logs using an AWS CloudFormation
Script.

You can forward network AWS Route 53 DNS logs to Cortex XSIAM from Amazon Simple Storage Service (Amazon S3).

To receive network Route 53 DNS logs from Amazon S3, you must first configure data collection from Amazon S3. You can then configure the Collection
Integrations settings in Cortex XSIAM for Amazon S3. After you set up collection integration, Cortex XSIAM begins receiving new logs and data from the source.

You can configure Amazon S3 with SQS notification using the AWS CloudFormation Script that we have created for you to make the process easier. The
instructions below explain how to configure Cortex XSIAM to receive network Route 53 DNS logs from Amazon S3 using SQS.

NOTE:

For more information on configuring data collection from Amazon S3 for Route 53 DNS logs, see the AWS Documentation.

As soon as Cortex XSIAM begins receiving logs, the app automatically creates an Amazon Route 53 Cortex Query Language (XQL) dataset
(amazon_route53_raw). This enables you to search the logs with XQL Search using the dataset. For example, queries refer to the in-app XQL Library. For
enhanced cloud protection, you can also configure Cortex XSIAM to ingest network Route 53 DNS logs as Cortex XSIAM network connection stories, which you
can query with XQL Search using the xdr_data dataset with the preset called network_story. Cortex XSIAM can also raise Cortex XSIAM alerts (Analytics,
Correlation Rules, IOC, and BIOC) when relevant from Amazon Route 53 DNS logs. While Correlation Rules alerts are raised on non-normalized and
normalized logs, Analytics, IOC, and BIOC alerts are only raised on normalized logs.

Enhanced cloud protection provides:

Normalization of cloud logs

Cloud logs stitching

Enrichment with cloud data

Detection based on cloud analytics

Cloud-tailored investigations

Be sure you do the following tasks before you begin configuring data collection from Amazon S3 using the AWS CloudFormation Script.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 622/1003
5/8/24, 9:18 AM PDF Export

Ensure that you have the proper permissions to run AWS CloudFormation with the script provided in Cortex XSIAM . You need at a minimum the following
permissions in AWS for an Amazon S3 bucket and Amazon Simple Queue Service (SQS):

Amazon S3 bucket—GetObject

SQS—ChangeMessageVisibility, ReceiveMessage, and DeleteMessage.

Ensure that you can access your Amazon Virtual Private Cloud (VPC) and have the necessary permissions to create Route 53 Resolver Query logs.

Determine how you want to provide access to Cortex XSIAM to your logs and perform API operations. You have the following options.

Designate an AWS IAM user, where you will need to know the Account ID for the user and have the relevant permissions to create an access key/id
for the relevant IAM user. This is the default option when you configure the Amazon S3 collection by selecting Access Key.

Create an assumed role in AWS to delegate permissions to a Cortex XSIAM AWS service. This role grants Cortex XSIAM access to your flow logs.
For more information, see Creating a role to delegate permissions to an AWS service. This is the Assumed Role option when you configure the
Amazon S3 collection in Cortex XSIAM. For more information on creating an assumed role for Cortex XSIAM, see Create an Assumed Role.

To collect Amazon S3 logs that use server-side encryption (SSE), the user role must have an IAM policy that states that Cortex XSIAM has kms:Decrypt
permissions. With this permission, Amazon S3 automatically detects if a bucket is encrypted and decrypts it. If you want to collect encrypted logs from
different accounts, you must have the decrypt permissions for the user role also in the key policy for the master account Key Management Service (KMS).
For more information, see Allowing users in other accounts to use a KMS key.

Configure Cortex XSIAM to receive network Route 53 DNS logs from Amazon S3 using the CloudFormation Script.

1. Download the CloudFormation Script in Cortex XSIAM .

a. Select Settings → Configurations → Data Collection → Data Sources.

b. In the Amazon S3 configuration, click Add Instance link to begin a new configuration.

c. To provide access to Cortex XSIAM to your logs and to perform API operations using a designated AWS IAM user, leave the Access Key option
selected. Otherwise, select Assumed Role, and ensure that you Create an Assumed Role for before continuing with these instructions.

d. For the Log Type, select Route 53 to configure your log collection to receive network Route 53 DNS logs from Amazon S3, and the following text is
displayed under the field Download CloudFormation Script. See instructions here.

e. Click the Download CloudFormation Script. link to download the script to your computer.

2. Create a new Stack in the CloudFormation Console with the script you downloaded from Cortex XSIAM .

NOTE:

For more information on creating a Stack, see Creating a stack on the AWS CloudFormation console.

a. Log in to the CloudFormation Console.

b. From the CloudFormation → Stacks page, ensure that you have selected the correct region for your configuration.

c. Select Create Slack → With new resources (standard).

d. Specify the template that you want AWS CloudFormation to use to create your stack. This template is the script that you downloaded from Cortex
XSIAM , which will create an Amazon S3 bucket, Amazon Simple Queue Service (SQS) queue, and Queue Policy. Configure the following settings
in the Specify template page.

Prerequisite - Prepare template → Prepare template—Select Template is ready.

Specify Template

Template source—Select Upload a template file.

Upload a template file—Choose file, and select the CloudFormation-Script.json file that you downloaded.

e. Click Next.

f. In the Specify stack details page, configure the following stack details.

Stack name—Specify a descriptive name for your stack.

Parameters → Cortex XDR Flow Logs Integration

Bucket Name—Specify the name of the S3 bucket to create, where you can leave the default populated name as xdr-route53-logs or
create a new one. The name must be unique.

Publisher Account ID—Specify the AWS IAM user account ID with whom you are sharing access.

Queue Name—Specify the name for your Amazon SQS queue to create, where you can leave the default populated name as xdr-
route53 or create a new one. The name must be unique.

g. Click Next.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 623/1003
5/8/24, 9:18 AM PDF Export

h. In the Configure stack options page, there is nothing to configure, so click Next.

i. In the Review page, look over the stack configurations settings that you have configured and if they are correct, click Create stack. If you need to
make a change, click Edit beside the particular step that you want to update.

The stack is created and is opened with the Events tab displayed. It can take a few minutes for the new Amazon S3 bucket, SQS queue, and Queue
Policy to be created. Click Refresh to get updates. Once everything is created, leave the stack opened in the current browser as you will need to
access information in the stack for other steps detailed below.

NOTE:

For the Amazon S3 bucket created using CloudFormation, it is the customer’s responsibility to define a retention policy by creating a Lifecycle
rule in the Management tab. We recommend setting the retention policy to at least 7 days to ensure that the data is retrieved under all
circumstances.

3. Configure Route 53 Query Logging in AWS.

a. Log in to the AWS Management Console.

b. From the menu bar, ensure that you have selected the correct region for your configuration.

c. Search for Route 53 and select Resolver → Query Logging.

d. Configure query logging.

e. Set the following parameters in the different sections on the Configure query logging page.

Query logging configuration name

Name—Specify a name for your Resolver query logging configuration.

Query logs destination

Destination for query logs—Select S3 bucket as the place where you want Resolver to publish query logs.

Amazon S3 bucket—Browse S3 to select the Amazon S3 bucket created after running the CloudFormation script, which is by default
called xdr-route53-logs or select the one that you created.

VPCs to log queries for

Add VPC—Clicking the Add VPC button opens the Add VPC page, where you can choose the VPCs that you want to log queries for.
When you are done, click Add.

f. Click Configure query logging.

4. Configure access keys for the AWS IAM user that Cortex XSIAM uses for API operations.

NOTE:

It is the responsibility of the customer’s organization to ensure that the user who performs this task of creating the access key is designated with
the relevant permissions. Otherwise, this can cause the process to fail with errors.

Skip this step if you are using an Assumed Role for Cortex XSIAM.

1. Open the AWS IAM Console, and in the navigation pane, select Access management → Users.

2. Select the User name of the AWS IAM user.

3. Select the Security credentials tab, scroll down to the Access keys section, and click Create access key.

4. Click the copy icon next to the Access key ID and Secret access key keys, where you must click Show secret access key to see the secret key and
record them somewhere safe before closing the window. You will need to provide these keys when you edit the Access policy of the SQS queue and
when setting the AWS Client ID and AWS Client Secret in Cortex XSIAM. If you forget to record the keys and close the window, you will need to
generate new keys and repeat this process.

NOTE:

For more information, see Managing access keys for IAM users.

5. When you create an Assumed Role, ensure that you edit the policy that defines the permissions for the role with the S3 Bucket ARN and SQS ARN, which
is taken from the stack you created.

NOTE:

Skip this step if you are using an Access Key to provide access to Cortex XSIAM.

6. Configure the Amazon S3 collection in Cortex XSIAM .

a. Select Settings → Configurations → Data Collection → Data Sources.

b. In the Amazon S3 configuration, click Add Instance to begin a new configuration.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 624/1003
5/8/24, 9:18 AM PDF Export

c. Set these parameters, where the parameters change depending on whether you configured an Access Key or Assumed Role.

SQS URL—Specify the SQS URL, which is taken from the stack you created. In the browser you left open after creating the stack, open the
Outputs tab, copy the Value of the QueueURL and paste it in this field.

Name—Specify a descriptive name for your log collection configuration.

When setting an Access Key, set these parameters.

AWS Client ID—Specify the Access key ID, which you received when you created access keys for the AWS IAM user in AWS.

AWS Client Secret—Specify the Secret access key you received when you created access keys for the AWS IAM user in AWS.

When setting an Assumed Role, set these parameters.

Role ARN—Specify the Role ARN for the Assumed Role you created for Cortex XSIAMin AWS.

External Id—Specify the External Id for the Assumed Role you created for Cortex XSIAM in AWS.

Log Type—Select Route 53 to configure your log collection to receive network Route 53 DNS logs from Amazon S3. When configuring
network Route 53 log collection, the following additional field is displayed for Enhanced Cloud Protection.

You can Normalize DNS logs by selecting the checkbox (default configuration). When selected, Cortex XSIAM ingests the network Route 53
DNS logs as XDR network connection stories, which you can query using XQL Search from the xdr_data dataset using the preset called
network_story.

d. Click Test to validate access, and then click Enable.

Once events start to come in, a green check mark appears underneath the Amazon S3 configuration with the number of logs received.

8.4.3.3 | Ingest Logs from Check Point Firewalls

Abstract

To take advantage of Cortex XSIAM investigation and detection capabilities while using Check Point firewalls, forward your firewall logs to Cortex XSIAM.

If you use Check Point FW1/VPN1 firewalls, you can still take advantage of Cortex XSIAM investigation and detection capabilities by forwarding your Check
Point firewall logs to Cortex XSIAM. Check Point firewall logs can be used as the sole data source, however, you can also use Check Point firewall logs in
conjunction with Palo Alto Networks firewall logs and additional data sources.

Cortex XSIAM can stitch data from Check Point firewalls with other logs to make up network stories searchable in the Query Builder and in Cortex Query
Language (XQL) queries. Cortex XSIAM can also return raw data from Check Point firewalls in XQL queries.

NOTE:

Logs with sessionid = 0 are dropped.

Destination Port data is available only in the raw logs.

In terms of alerts, Cortex XSIAM can both surface native Check Point firewall alerts and raise its own alerts on network activity. Alerts are displayed throughout
Cortex XSIAM alert, incident, and investigation views.

To integrate your logs, you first need to set up an applet in a Broker VM within your network to act as a Syslog Collector. You then configure your Check Point
firewall policy to log all traffic and set up the Log Exporter on your Check Point Log Server to forward logs to the Syslog Collector in a CEF format.

As soon as Cortex XSIAM starts to receive logs, the app can begin stitching network connection logs with other logs to form network stories. Cortex XSIAM can
also analyze your logs to raise Analytics alerts and can apply IOC, BIOC, and Correlation Rule matching. You can also use queries to search your network
connection logs.

1. Ensure that your Check Point firewalls meet the following requirements.

Check Point software version—R77.30, R80.10, R80.20, R80.30, or R80.40

2. Increase log storage for Check Point firewall logs.

As an estimate for initial sizing, note that the average Check Point log size is roughly 700 bytes. For proper sizing calculations, test the log sizes and log
rates produced by your Check Point firewalls. For more information, see Manage Your Log Storage within Cortex XSIAM.

3. Activate the Syslog Collector.

4. Configure the Check Point firewall to forward Syslog events in CEF format to the Syslog Collector.

Configure your firewall policy to log all traffic and set up the Log Exporter to forward logs to the Syslog Collector. For more information on setting up Log
Exporter, see the Check Point documentation.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 625/1003
5/8/24, 9:18 AM PDF Export

8.4.3.4 | Ingest Logs from Cisco ASA Firewalls and AnyConnect

Abstract

Extend Cortex XSIAM visibility into logs from Cisco ASA firewalls and Cisco AnyConnect VPN.

If you use Cisco ASA firewalls or Cisco AnyConnect VPN, you can take advantage of Cortex XSIAM investigation and detection capabilities by forwarding your
firewall and AnyConnect VPN logs to Cortex XSIAM . This enables Cortex XSIAM to examine your network traffic to detect anomalous behavior. Cortex XSIAM
can use Cisco ASA firewall logs and AnyConnect VPN logs as the sole data source, but can also use Cisco ASA firewall logs in conjunction with Palo Alto
Networks firewall logs. For additional endpoint context, you can also use Cortex XSIAM to collect and alert on endpoint data.

As soon as Cortex XSIAM starts to receive logs, the app can begin stitching network connection logs with other logs to form network stories. Cortex XSIAM can
also analyze your logs to raise Analytics alerts and can apply IOC, BIOC, and Correlation Rules matching. You can also use queries to search your network
connection logs using the Cisco Cortex Query Language (XQL) dataset (cisco_asa_raw).

To integrate your logs, you first need to set up an applet in a Broker VM within your network to act as a Syslog Collector. You then configure forwarding on your
log devices to send logs to the Syslog Collector in a CISCO format.

1. Verify that your Cisco ASA firewall and Cisco AnyConnect VPN logs meet the following requirements.

Syslog in Cisco-ASA format

Must include timestamps

Only supports the following messages.

For Cisco ASA firewall: 302013, 302014, 302015, 302016

For Cisco AnyConnect VPN: 113039, 716001, 722022, 722033, 722034, 722051, 722055, 722053, 113019, 716002, 722023, 722037

2. Activate the Syslog Collector.

3. Increase log storage for Cisco ASA firewall and Cisco AnyConnect VPN logs.

As an estimate for initial sizing, note that the average Cisco ASA log size is roughly 180 bytes. For proper sizing calculations, test the log sizes and log
rates produced by your Cisco ASA firewalls and Cisco AnyConnect VPN logs. For more information, see Manage Your Log Storage within Cortex XSIAM.

4. Configure the Cisco ASA firewall and Cisco AnyConnect VPN, or the log devices forwarding logs from Cisco, to log to the Syslog Collector in a CISCO
format.

Configure your firewall and AnyConnect VPN policies to log all traffic and forward the traffic logs to the Syslog Collector in a CISCO format. By logging all
traffic, you enable Cortex XSIAM to detect anomalous behavior from Cisco ASA firewall logs and Cisco AnyConnect VPN logs. For more information on
setting up Log Forwarding on Cisco ASA firewalls or Cisco AnyConnect VPN, see the Cisco ASA Series documentation.

8.4.3.5 | Ingest Logs from Corelight Zeek

Abstract

Extend Cortex XSIAM visibility into logs from Corelight Zeek.

If you use Corelight Zeek sensors for network monitoring, you can still take advantage of Cortex XSIAM investigation and detection capabilities by forwarding
your network connection logs to Cortex XSIAM . This enables Cortex XSIAM to examine your network traffic to detect anomalous behavior. Cortex XSIAM can
use Corelight Zeek logs as the sole data source, but can also use logs in conjunction with Palo Alto Networks or third-party firewall logs. For additional endpoint
context, you can also use Cortex XSIAM to collect and alert on endpoint data.

As soon as Cortex XSIAM starts to receive logs, the app can begin stitching network connection logs with other logs to form network stories. Cortex XSIAM can
also analyze your logs to raise Analytics alerts and can apply IOC, BIOC, and Correlation Rule matching. You can also use queries to search your network
connection logs.

To integrate your logs, you first need to set up an applet in a Broker VM within your network to act as a Syslog Collector. You then configure forwarding on your
Corelight Zeek sensors (using the default Syslog export option of RFC5424 over TCP) to send logs to the Syslog Collector.

1. Activate the Syslog Collector.

During activation, you define the Listening Port over which you want the Syslog Collector to receive logs. You must also set TCP as the transport Protocol
and Corelight as the Syslog Format.

2. Increase log storage for Corelight Zeek logs.

For proper sizing calculations, test the log sizes and log rates produced by your Corelight Zeek Sensors. Then adjust your Cortex XSIAM log storage. For
more information, see Manage Your Log Storage within Cortex XSIAM.

3. Forward logs to the Syslog Collector.

Cortex XSIAM can receive logs from Corelight Zeek sensors that use the Syslog export option of RFC5424 over TCP.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 626/1003
5/8/24, 9:18 AM PDF Export

a. In the Syslog configuration of Corelight Zeek (Sensor → Export), specify the details for your Syslog Collector including the hostname or IP address
of the Broker VM and corresponding listening port that you defined during activation of the Syslog Collector, default Syslog format (RFC5424), and
any log exclusions or filters.

b. Save your Syslog configuration to apply the configuration to your Corelight Zeek Sensors.

For full setup instructions, see the Corelight Zeek documentation.

8.4.3.6 | Ingest Logs from Fortinet Fortigate Firewalls

Abstract

Extend Cortex XSIAM visibility into logs from Fortinet Fortigate firewalls.

If you use Fortinet Fortigate firewalls, you can still take advantage of Cortex XSIAM investigation and detection capabilities by forwarding your firewall logs to
Cortex XSIAM . This enables Cortex XSIAM to examine your network traffic to detect anomalous behavior. Cortex XSIAM can use Fortinet Fortigate firewall logs
as the sole data source, but can also use Fortinet Fortigate firewall logs in conjunction with Palo Alto Networks firewall logs. For additional endpoint context, you
can also use Cortex XSIAM to collect and alert on endpoint data.

As soon as Cortex XSIAM starts to receive logs, the app can begin stitching network connection logs with other logs to form network stories. Cortex XSIAM can
also analyze your logs to raise Analytics alerts and can apply IOC, BIOC, and Correlation Rule matching. You can also use queries to search your network
connection logs.

To integrate your logs, you first need to set up an applet in a Broker VM within your network to act as a Syslog collector. You then configure forwarding on your
log devices to send logs to the Syslog collector in a CEF format.

1. Verify that your Fortinet Fortigate firewalls meet the following requirements.

Must use FortiOS 6.2.1 or a later release

timestamp must be in nanoseconds

2. Activate the Syslog Collector.

3. Increase log storage for Fortinet Fortigate firewall logs.

As an estimate for initial sizing, note that the average Fortinet Fortigate log size is roughly 1,070 bytes. For proper sizing calculations, test the log sizes
and log rates produced by your Fortinet Fortigate firewalls. For more information, see Manage Your Log Storage within Cortex XSIAM.

4. Configure the log device that receives Fortinet Fortigate firewall logs to forward Syslog events to the Syslog collector in a CEF format.

Configure your firewall policy to log all traffic and forward the traffic logs to the Syslog collector in a CEF format. By logging all traffic, you enable Cortex
XSIAM to detect anomalous behavior from Fortinet Fortigate firewall logs. For more information on setting up Log Forwarding on Fortinet Fortigate
firewalls, see the Fortinet FortiOS documentation.

8.4.3.7 | Ingest Logs and Data from a GCP Pub/Sub

Abstract

If you use the Pub/Sub messaging service from Global Cloud Platform (GCP), you can send logs and data from GCP to Cortex XSIAM.

If you use the Pub/Sub messaging service from Global Cloud Platform (GCP), you can send logs and data from your GCP instance to Cortex XSIAM. Data from
GCP is then searchable in Cortex XSIAM to provide additional information and context to your investigations using the GCP Cortex Query Language (XQL)
dataset, which is dependent on the type of GCP logs collected. For example queries, refer to the in-app XQL Library. You can configure a Google Cloud Platform
collector to receive generic, flow, audit, or Google Cloud DNS logs. When configuring generic logs, you can receive logs in a Raw, JSON, CEF, LEEF, Cisco, or
Corelight format.

You can also configure Cortex XSIAM to normalize different GCP logs as part of the enhanced cloud protection, which you can query with XQL Search using the
applicable dataset. Cortex XSIAM can also raise Cortex XSIAM alerts (Analytics, IOC, BIOC, and Correlation Rules) when relevant from GCP logs. While
Correlation Rules alerts are raised on non-normalized and normalized logs, Analytics, IOC, and BIOC alerts are only raised on normalized logs.

Enhanced cloud protection provides the following:

Normalization of cloud logs

Cloud logs stitching

Enrichment with cloud data

Detection based on cloud analytics

Cloud-tailored investigations

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 627/1003
5/8/24, 9:18 AM PDF Export

The following table lists the various GCP log types the XQL datasets you can use to query in XQL Search:

GCP Log Type Dataset Dataset With Normalized Data

Audit logs, including google_cloud_logging_raw cloud_audit_logs

Google Kubernetes
Engine (GKE) audit logs

Generic logs Log Format types: N/A

CEF or LEEF: Automatically detected from

either the logs or the user's input in the User
Interface.

Cisco: cisco_asa_raw

Corelight: corelight_zeek_raw

JSON or Raw:
google_cloud_logging_raw

Google Cloud DNS logs google_dns_raw xdr_data: Once configured, Cortex XSIAM ingests Google Cloud DNS
logs as XDR network connection stories, which you can query with XQL
Search using the xdr_data dataset with the preset called
network_story.

Network flow logs google_cloud_logging_raw xdr_data: Once configured, Cortex XSIAM ingests network flow logs as
XDR network connection stories, which you can query with XQL Search
using the xdr_data dataset with the preset called network_story.

NOTE:

When collecting flow logs, we recommend that you include GKE annotations in your logs, which enable you to view the names of the containers that
communicated with each other. GKE annotations are only included in logs if appended manually using the custom metadata configuration in GCP. For more
information, see VPC Flow Logs Overview. In addition, to customize metadata fields, you must use the gcloud command-line interface or the API. For more
information, see Using VPC Flow Logs.

To receive logs and data from GCP, you must first set up log forwarding using a Pub/Sub topic in GCP. You can configure GCP settings using either the GCP
web interface or a GCP cloud shell terminal. After you set up your service account in GCP, you configure the Data Collection settings in Cortex XSIAM. The
setup process requires the subscription name and authentication key from your GCP instance.

After you set up log collection, Cortex XSIAM immediately begins receiving new logs and data from GCP.

Set up Log Forwarding Using the GCP Web Interface

1. Log in to your GCP account.

2. Set up log forwarding from GCP to Cortex XSIAM.

a. Select Logging → Logs Router.

b. Select Create Sink → Cloud Pub/Sub topic, and then click Next.

c. To filter only specific types of data, select the filter or desired resource.

d. In the Edit Sink configuration, define a descriptive Sink Name.

e. Select Sink Destination → Create new Cloud Pub/Sub topic.

f. Enter a descriptive Name that identifies the sink purpose for Cortex XSIAM, and then Create.

g. Create Sink and then Close when finished.

3. Create a subscription for your Pub/Sub topic.

a. Select the hamburger menu in G Cloud and then select Pub/Sub → Topics.

b. Select the name of the topic you created in the previous steps. Use the filters if necessary.

c. Create Subscription → Create subscription.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 628/1003
5/8/24, 9:18 AM PDF Export

d. Enter a unique Subscription ID.

e. Choose Pull as the Delivery Type.

f. Create the subscription.

After the subscription is set up, G Cloud displays statistics and settings for the service.

g. In the subscription details, identify and note your Subscription Name.

Optionally, use the copy button to copy the name to the clipboard. You will need the name when you configure Collection in Cortex XSIAM.

4. Create a service account and authentication key.

You will use the key to enable Cortex XSIAM to authenticate with the subscription service.

a. Select the hamburger menu and then select IAM & Admin → Service Accounts.

b. Create Service Account.

c. Enter a Service account name and then Create.

d. Select a role for the account: Pub/Sub → Pub/Sub Subscriber.

e. Click Continue → Done.

f. Locate the service account by name, using the filters to refine the results, if needed.

g. Click the Actions menu identified by the three dots in the row for the service account and then Create Key.

h. Select JSON as the key type, and then Create.

After you create the service account key, G Cloud automatically downloads it.

5. In Cortex XSIAM, set up Data Collection.

a. Select Settings → Configurations → Data Collection → Data Sources.

b. In the Google Cloud Platform configuration, click Add Instance.

c. Specify the Subscription Name that you previously noted or copied.

d. Browse to the JSON file containing your authentication key for the service account.

e. Select the Log Type as one of the following, where your selection changes the options displayed.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 629/1003
5/8/24, 9:18 AM PDF Export

Flow or Audit Logs—When selecting this log type, you can decide whether to normalize and enrich the logs as part of the enhanced cloud
protection.

(Optional) You can Normalize and enrich flow and audit logs by selecting the checkbox (default). If selected, Cortex XSIAM ingests the
network flow logs as Cortex XSIAM network connection stories, which you can query using XQL Search from the xdr_dataset dataset
with the preset called network_story. In addition, you can configure Cortex XSIAM to normalize GCP audit logs, which you can query
with XQL Search using the cloud_audit_logs dataset.

The Vendor is automatically set to Google and Product to Cloud Logging , which is not configurable. This means that all GCP data for
the flow and audit logs, whether it's normalized or not, can be queried in XQL Search using the google_cloud_logging_raw dataset.

Generic—When selecting this log type, you can configure the following settings.

Log Format—Select the log format type as Raw, JSON, CEF, LEEF, Cisco, or Corelight.

CEF or LEEF: The Vendor and Product defaults to Auto-Detect.

NOTE:

For a Log Format set to CEF or LEEF, Cortex XSIAM reads events row by row to look for the Vendor and Product configured in
the logs. When the values are populated in the event log row, Cortex XSIAM uses these values even if you specified a value in
the Vendor and Product fields in the GCP data collector settings. Yet, when the values are blank in the event log row, Cortex
XSIAM uses the Vendor and Product that you specified in the GCP data collector settings. If you did not specify a Vendor or
Product in the GCP data collector settings, and the values are blank in the event log row, the values for both fields are set to
unknown.

Cisco: The following fields are automatically set and not configurable.

Vendor—Cisco

Product—ASA

Cisco data can be queried in XQL Search using the cisco_asa_raw dataset.

Corelight: The following fields are automatically set and not configurable.

Vendor—Corelight

Product—Zeek

Corelight data can be queried in XQL Search using the corelight_zeek_raw dataset.

Raw or JSON: The following fields are automatically set and are configurable.

Vendor—Google

Product—Cloud Logging

Raw or JSON data can be queried in XQL Search using the google_cloud_logging_raw dataset.

Cortex XSIAM supports logs in single line format or multiline format. For a JSON format, multiline logs are collected automatically
when the Log Format is configured as JSON. When configuring a Raw format, you must also define the Multiline Parsing Regex
as explained below.

Vendor—(Optional) Specify a particular vendor name for the GCP generic data collection, which is used in the GCP XQL dataset
<Vendor>_<Product>_raw that Cortex XSIAM creates as soon as it begins receiving logs.

Product—(Optional) Specify a particular product name for the GCP generic data collection, which is used in the GCP XQL dataset
name <Vendor>_<Product>_raw that Cortex XSIAM creates as soon as it begins receiving logs.

Multiline Parsing Regex—(Optional) This option is only displayed when the Log Format is set to Raw, where you can set the regular
expression that identifies when the multiline event starts in logs with multilines. It is assumed that when a new event begins, the
previous one has ended.

Google Cloud DNS—When selecting this log type, you can configure whether to normalize the logs as part of the enhanced cloud protection.

Optional) You can Normalize DNS logs by selecting the checkbox (default). If selected, Cortex XSIAM ingests the Google Cloud DNS
logs as Cortex XSIAM network connection stories, which you can query using XQL Search from the xdr_dataset dataset with the
preset called network_story.

The Vendor is automatically set to Google and Product to DNS , which is not configurable. This means that all Google Cloud DNS logs,
whether it's normalized or not, can be queried in XQL Search using the google_dns_raw dataset.

f. Test the provided settings and, if successful, proceed to Enable log collection.

6. After Cortex XSIAM begins receiving information from the GCP Pub/Sub service, you can use the XQL Query language to search for specific data.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 630/1003
5/8/24, 9:18 AM PDF Export

Set up Log Forwarding Using the GCP Cloud Shell Terminal

1. Launch the GCP cloud shell terminal or use your preferred shell with gcloud installed.

2. Define your project ID.

gcloud config set project <PROJECT_ID>

3. Create a Pub/Sub topic.

gcloud pubsub topics create <TOPIC_NAME>

4. Create a subscription for this topic.

gcloud pubsub subscriptions create <SUBSCRIPTION_NAME> --topic=<TOPIC_NAME>

Note the subscription name you define in this step as you will need it to set up log ingestion from Cortex XSIAM.

5. Create a logging sink.

During the logging sink creation, you can also define additional log filters to exclude specific logs. To filter logs, supply the optional parameter --log-
filter=<LOG_FILTER>

gcloud logging sinks create <SINK_NAME> pubsub.googleapis.com/projects/<PROJECT_ID>/topics/<TOPIC_NAME> --log-filter=<LOG_FILTER>

If setup is successful, the console displays a summary of your log sink settings:

Created [https://logging.googleapis.com/v2/projects/PROJECT_ID/sinks/SINK_NAME]. Please remember to grant `serviceAccount:LOGS_SINK_SERVICE_ACCOUNT` \ the Pub/Sub

Publisher role on the topic. More information about sinks can be found at /logging/docs/export/configure_export

6. Grant log sink service account to publish to the new topic.

Note the serviceAccount name from the previous step and use it to define the service for which you want to grant publish access.

gcloud pubsub topics add-iam-policy-binding <TOPIC_NAME> --member serviceAccount:<LOGS_SINK_SERVICE_ACCOUNT> --role=roles/pubsub.publisher

7. Create a service account.

For example, use cortex-xdr-sa as the service account name and Cortex XSIAM Service Account as the display name.

gcloud iam service-accounts create <SERVICE_ACCOUNT> --description="<DESCRIPTION>" --display-name="<DISPLAY_NAME>"

8. Grant the IAM role to the service account.

gcloud pubsub subscriptions add-iam-policy-binding <SUBSCRIPTION_NAME> --member serviceAccount:<SERVICE_ACCOUNT>@<PROJECT_ID>.iam.gserviceaccount.com --

role=roles/pubsub.subscriber

9. Create a JSON key for the service account.

You will need the JSON file to enable Cortex XSIAM to authenticate with the GCP service. Specify the file destination and filename using a .json
extension.

gcloud iam service-accounts keys create <OUTPUT_FILE> --iam-account <SERVICE_ACCOUNT>@<PROJECT_ID>.iam.gserviceaccount.com

10. In Cortex XSIAM, set up Data Collection.

a. Select Settings → Configurations → Data Collection → Data Sources.

b. In the Google Cloud Platform configuration, click Add Instance.

c. Specify the Subscription Name that you previously noted or copied.

d. Browse to the JSON file containing your authentication key for the service account.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 631/1003
5/8/24, 9:18 AM PDF Export

e. Select the Log Type as one of the following, where your selection changes the options displayed.

Flow or Audit Logs—When selecting this log type, you can decide whether to normalize and enrich the logs as part of the enhanced cloud
protection.

(Optional) You can Normalize and enrich flow and audit logs by selecting the checkbox (default). If selected, Cortex XSIAM ingests the
network flow logs as Cortex XSIAM network connection stories, which you can query using XQL Search from the xdr_dataset dataset
with the preset called network_story. In addition, you can configure Cortex XSIAM to normalize GCP audit logs, which you can query
with XQL Search using the cloud_audit_logs dataset.

The Vendor is automatically set to Google and Product to Cloud Logging , which is not configurable. This means that all GCP data for
the flow and audit logs, whether it's normalized or not, can be queried in XQL Search using the google_cloud_logging_raw dataset.

Generic—When selecting this log type, you can configure the following settings.

Log Format—Select the log format type as Raw, JSON, CEF, LEEF, Cisco, or Corelight.

CEF or LEEF: The Vendor and Product defaults to Auto-Detect.

NOTE:

For a Log Format set to CEF or LEEF, Cortex XSIAM reads events row by row to look for the Vendor and Product configured in
the logs. When the values are populated in the event log row, Cortex XSIAM uses these values even if you specified a value in
the Vendor and Product fields in the GCP data collector settings. Yet, when the values are blank in the event log row, Cortex
XSIAM uses the Vendor and Product that you specified in the GCP data collector settings. If you did not specify a Vendor or
Product in the GCP data collector settings, and the values are blank in the event log row, the values for both fields are set to
unknown.

Cisco: The following fields are automatically set and not configurable.

Vendor—Cisco

Product—ASA

Cisco data can be queried in XQL Search using the cisco_asa_raw dataset.

Corelight: The following fields are automatically set and not configurable.

Vendor—Corelight

Product—Zeek

Corelight data can be queried in XQL Search using the corelight_zeek_raw dataset.

Raw or JSON: The following fields are automatically set and are configurable.

Vendor—Google

Product—Cloud Logging

Raw or JSON data can be queried in XQL Search using the google_cloud_logging_raw dataset.

Cortex XSIAM supports logs in single line format or multiline format. For a JSON format, multiline logs are collected automatically
when the Log Format is configured as JSON. When configuring a Raw format, you must also define the Multiline Parsing Regex
as explained below.

Vendor—(Optional) Specify a particular vendor name for the GCP generic data collection, which is used in the GCP XQL dataset
<Vendor>_<Product>_raw that Cortex XSIAM creates as soon as it begins receiving logs.

Product—(Optional) Specify a particular product name for the GCP generic data collection, which is used in the GCP XQL dataset
name <Vendor>_<Product>_raw that Cortex XSIAM creates as soon as it begins receiving logs.

Multiline Parsing Regex—(Optional) This option is only displayed when the Log Format is set to Raw, where you can set the regular
expression that identifies when the multiline event starts in logs with multilines. It is assumed that when a new event begins, the
previous one has ended.

Google Cloud DNS—When selecting this log type, you can configure whether to normalize the logs as part of the enhanced cloud protection.

Optional) You can Normalize DNS logs by selecting the checkbox (default). If selected, Cortex XSIAM ingests the Google Cloud DNS
logs as Cortex XSIAM network connection stories, which you can query using XQL Search from the xdr_dataset dataset with the
preset called network_story.

The Vendor is automatically set to Google and Product to DNS , which is not configurable. This means that all Google Cloud DNS logs,
whether it's normalized or not, can be queried in XQL Search using the google_dns_raw dataset.

f. Test the provided settings and, if successful, proceed to Enable log collection.

11. After Cortex XSIAM begins receiving information from the GCP Pub/Sub service, you can use the XQL Query language to search for specific data.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 632/1003
5/8/24, 9:18 AM PDF Export

8.4.3.8 | Ingest Logs from Microsoft Azure Event Hub

Abstract

Ingest logs from Microsoft Azure Event Hub with an option to ingest audit logs to use in Cortex XSIAM authentication stories.

Cortex XSIAM can ingest different types of data from Microsoft Azure Event Hub using the Microsoft Azure Event Hub data collector. To receive logs from Azure
Event Hub, you must configure the Data Sources settings in Cortex XSIAM based on your Microsoft Azure Event Hub configuration. After you set up data
collection, Cortex XSIAM begins receiving new logs and data from the source.

When Cortex XSIAM begins receiving logs, the app creates a new dataset (MSFT_Azure_raw) that you can use to initiate XQL Search queries. For example,
queries refer to the in-app XQL Library. For enhanced cloud protection, you can also configure Cortex XSIAM to normalize Azure Event Hub audit logs, including
Azure Kubernetes Service (AKS) audit logs, with other Cortex XSIAM authentication stories across all cloud providers using the same format, which you can
query with XQL Search using the cloud_audit_logs dataset. For logs that you do not configure Cortex XSIAM to normalize, you can change the default
dataset. Cortex XSIAM can also raise Cortex XSIAM alerts (Analytics, IOC, BIOC, and Correlation Rules) when relevant from Azure Event Hub logs. While
Correlation Rules alerts are raised on non-normalized and normalized logs, Analytics, IOC, and BIOC alerts are only raised on normalized logs.

Enhanced cloud protection provides:

Normalization of cloud logs

Cloud logs stitching

Enrichment with cloud data

Detection based on cloud analytics

Cloud-tailored investigations

The following table provides a brief description of the different types of Azure audit logs you can collect.

NOTE:

For more information on Azure Event Hub audit logs, see Overview of Azure platform logs.

Type Of Data Description

Activity logs Retrieves events related to the operations on each Azure resource in the subscription from the outside in addition to
updates on Service Health events.

NOTE:

These logs are from the management plane.

Azure Active Directory (AD) Contain the history of sign-in activity and audit trail of changes made in Azure AD for a particular tenant.
Activity logs and Azure Sign-
NOTE:
in logs
Even though you can collect Azure AD Activity logs and Azure Sign-in logs using the Azure Event Hub data collector, we
recommend using the Office 365 data collector as it's easier to configure. In addition, ensure that you don't configure
both collectors to collect the same types of logs as you'll be creating duplicate data in Cortex XSIAM.

Resource logs, including AKS Retrieves events related to operations that were performed within an Azure resource.
audit logs
NOTE:

These logs are from the data plane.

Prerequisite Steps

Be sure you do the following tasks before you begin configuring data collection from Azure Event Hub.

Create an Azure Event Hub. For more information, see Quickstart: Create an event hub using Azure portal.

Ensure the format for the logs you want collected from the Azure Event Hub is either JSON or raw.

Configure the Azure Event Hub collection in Cortex XSIAM.

1. In the Microsoft Azure Console, open the Event Hubs page, and select the Azure Event Hub that you created for collection in Cortex XSIAM.

2. Record the following parameters from your configured event hub, which you will need when configuring data collection in Cortex XSIAM.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 633/1003
5/8/24, 9:18 AM PDF Export

Your event hub’s consumer group.

1. Select Entities → Event Hubs, and select your event hub.

2. Select Entities → Consumer groups, and select your event hub.

3. In the Consumer group table, copy the applicable value listed in the Name column for your Cortex XSIAM data collection configuration.

Your event hub’s connection string for the designated policy.

1. Select Settings → Shared access policies.

2. In the Shared access policies table, select the applicable policy.

3. Copy the Connection string-primary key.

Your storage account connection string required for partitions lease management and checkpointing in Cortex XSIAM.

1. Open the Storage accounts page, and either create a new storage account or select an existing one, which will contain the storage account
connection string.

2. Select Security + networking → Access keys, and click Show keys.

3. Copy the applicable Connection string.

3. Configure diagnostic settings for the relevant log types you want to collect and then direct these diagnostic settings to the designated Azure Event Hub.

a. Open the Microsoft Azure Console.

b. Your navigation is dependent on the type of logs you want to configure.

Log Type Navigation Path

Activity logs Select Azure services → Activity log → Export Activity Logs, and +Add diagnostic setting.

Azure AD Activity logs and Azure 1. Select Azure services → Azure Active Directory.
Sign-in logs
2. Select Monitoring → Diagnostic settings, and +Add diagnostic setting.

Resource logs, including AKS 1. Search for Monitor, and select Settings → Diagnostic settings.
audit logs
2. From your list of available resources, select the resource that you want to configure for log
collection, and then select +Add diagnostic setting.

NOTE:

For every resource that you want to confiure, you'll have to repeat this step, or use Azure policy
for a general configuration.

c. Set the following parameters:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 634/1003
5/8/24, 9:18 AM PDF Export

Diagnostic setting name—Specify a name for your Diagnostic setting.

Logs Categories/Metrics—The options listed are dependent on the type of logs you want to configure. For Activity logs and Azure AD logs and
Azure Sign-in logs, the option is called Logs Categories, and for Resource logs it's called Metrics.

Log Type Log Categories/Metrics

Activity logs Select from the list of applicable Activity log categories, the ones that you want to configure your designated
resource to collect. We recommend selecting all of the options.

Administrative

Security

ServiceHealth

Alert

Recommendation

Policy

Autoscale

ResourceHealth

Azure AD Activity logs Select from the list of applicable Azure AD Activity and Azure Sign-in Logs Categories, the ones that you want to
and Azure Sign-in configure your designated resource to collect. You can select any of the following categories to collect these
logs types of Azure logs.

Azure AD Activity logs:

AuditLogs

Azure Sign-in logs:

SignInLogs

NonInteractiveUserSignInLogs

ServicePrincipalSignInLogs

ManagedIdentitySignInLogs

ADFSSignInLogs

NOTE:

There are additional log categories displayed. We recommend selecting all the available options.

Resource logs, The list displayed is dependent on the resource that you selected. We recommend selecting all the options
including AKS audit available for the resource.
logs

Destination details—Select Stream to event hub, where additional parameters are displayed that you need to configure. Ensure that you set
the following parameters using the same settings for the Azure Event Hub that you created for the collection.

Subscription—Select the applicable Subscription for the Azure Event Hub.

Event hub namespace—Select the applicable Subscription for the Azure Event Hub.

(Optional) Event hub name—Specify the name of your Azure Event Hub.

Event hub policy—Select the applicable Event hub policy for your Azure Event Hub.

d. Save your settings.

4. Configure the Azure Event Hub collection in Cortex XSIAM.

a. Select Settings → Configurations → Data Collection → Data Sources.

b. In the Azure Event Hub configuration, click Add Instance to begin a new configuration.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 635/1003
5/8/24, 9:18 AM PDF Export

c. Set these parameters.

Name—Specify a descriptive name for your log collection configuration.

Event Hub Connection String—Specify your event hub’s connection string for the designated policy.

Storage Account Connection String—Specify your event hub’s connection string for the designated policy.

Consumer Group—Specify your event hub’s consumer group.

Log Format—Select the log format for the logs collected from the Azure Event Hub as Raw, JSON, CEF, LEEF, Cisco-asa, or Corelight.

NOTE:

When you Normalize and enrich audit logs, the log format is automatically configured. As a result, the Log Format option is removed and is
no longer available to configure (default).

CEF or LEEF: The Vendor and Product defaults to Auto-Detect.

NOTE:

For a Log Format set to CEF or LEEF, Cortex XSIAM reads events row by row to look for the Vendor and Product configured in the
logs. When the values are populated in the event log row, Cortex XSIAM uses these values even if you specified a value in the
Vendor and Product fields in the Azure Event Hub data collector settings. Yet, when the values are blank in the event log row, Cortex
XSIAM uses the Vendor and Product that you specified in the Azure Event Hub data collector settings. If you did not specify a Vendor
or Product in the Azure Event Hub data collector settings, and the values are blank in the event log row, the values for both fields are
set to unknown.

Cisco-asa: The following fields are automatically set and not configurable.

Vendor—Cisco

Product—ASA

Cisco data can be queried in XQL Search using the cisco_asa_raw dataset.

Corelight: The following fields are automatically set and not configurable.

Vendor—Corelight

Product—Zeek

Corelight data can be queried in XQL Search using the corelight_zeek_raw dataset.

Raw or JSON: The following fields are automatically set and are configurable.

Vendor—Msft

Product—Azure

Raw or JSON data can be queried in XQL Search using the msft_azure_raw dataset.

Vendor and Product—Specify the Vendor and Product for the type of logs you are ingesting.

The Vendor and Product are used to define the name of your Cortex Query Language (XQL) dataset (<vendor>_<product>_raw). The
Vendor and Product values vary depending on the Log Format selected. To uniquely identify the log source, consider changing the values if
the values are configurable.

NOTE:

When you Normalize and enrich audit logs, the Vendor and Product fields are automatically configured, so these fields are removed as
available options (default).

Normalize and enrich audit logs—(Optional) For enhanced cloud protection, you can Normalize and enrich audit logs by selecting the
checkbox (default). If selected, Cortex XSIAM normalizes and enriches Azure Event Hub audit logs with other Cortex XSIAM authentication
stories across all cloud providers using the same format. You can query this normalized data with XQL Search using the cloud_audit_logs
dataset.

d. Click Test to validate access, and then click Enable.

Once events start to come in, a green check mark appears underneath the Azure Event Hub configuration with the amount of data received.

8.4.3.9 | Ingest Network Flow Logs from Microsoft Azure Network Watcher

Abstract

Ingest network security group (NSG) flow logs from Microsoft Azure Network Watcher for use in Cortex XSIAM network stories.

To receive network security group (NSG) flow logs from Azure Network Watcher, you must configure data collection from Microsoft Azure Network Watcher using
an Azure Function provided by Cortex XSIAM. This Azure Function requires a token that is generated when you configure your Azure Network Watcher Collector

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 636/1003
5/8/24, 9:18 AM PDF Export

in the Collection Integration settings in Cortex XSIAM . After you set up data collection, Cortex XSIAM begins receiving new logs and data from the source.

When Cortex XSIAM begins receiving logs, the app creates a new dataset (MSFT_Azure_raw) that you can use to initiate XQL Search queries. For example
queries, refer to the in-app XQL Library. For enhanced cloud protection, you can also configure Cortex XSIAM to ingest network flow logs as Cortex XSIAM
network connection stories, which you can query with XQL Search using the xdr_dataset dataset with the preset called network_story. Cortex XSIAM can
also raise Cortex XSIAM alerts (Analytics, Correlation Rules, IOC, and BIOC) when relevant from Azure Network Watcher flow logs. While Correlation Rules
alerts are raised on non-normalized and normalized logs, Analytics, IOC, and BIOC alerts are only raised on normalized logs.

Enhanced cloud protection provides:

Normalization of cloud logs

Cloud logs stitching

Enrichment with cloud data

Detection based on cloud analytics

Cloud-tailored investigations

Be sure you do the following tasks before you begin configuring data collection from Azure Network Watcher.

Ensure that your NSG flow logs in Azure Network Watcher, conform to the requirements as outlined in the Microsoft documentation. For more information,
see Introduction to flow logging for network security groups.

Enable NSG flow logs in the Microsoft Azure Portal.

Configure the Azure Network Watcher collection in Cortex XSIAM.

1. Configure the Azure Network Watcher collection in Cortex XSIAM.

a. Select Settings → Configurations → Data Collection → Data Sources.

b. In the Azure Network Watcher configuration, click Add Instance to begin a new configuration.

c. Set these parameters.

Name—Specify a descriptive name for your log collection configuration.

Normalize and enrich flow logs—(Optional) For enhanced cloud protection, you can Normalize and enrich flow logs by selecting the
checkbox. If selected, Cortex XSIAM ingests network flow logs as Cortex XSIAM network connection stories, which you can query with XQL
Search using the xdr_dataset dataset with the preset called network_story.

d. Save & Generate Token. The token is displayed in a blue box, which is blurred out in the image below.

Click the copy icon next to the key and record it somewhere safe. You will need to provide this key when you configure the Azure Function and set
the XDR Token value. If you forget to record the key and close the window, you will need to generate a new key and repeat this process. When you
are finished, click Done to close the window.

e. In the Integrations page for the Azure Network Watch Collector that you created, select Copy api url and record it somewhere safe. you will need to
provide this URL when you configure the Azure Function and set the XDR Host value.

2. Configure the Azure Function provided by Cortex XSIAM.

a. Open the Azure Function provided by Cortex XSIAM.

b. Click Deploy to Azure.

c. Set these parameters, where some fields are mandatory to set and others are already populated for you.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 637/1003
5/8/24, 9:18 AM PDF Export

Subscription—Specify the Azure subscription that you want to use for the App Configuration. If your account has only one subscription, it is
automatically selected.

Resource group—Specify or create a resource group for your App Configuration store resource.

Region—Specify the Azure region that you want to use.

App Name—Specify the name of the function app. In the Azure Portal, this will be the name that appears in the list of resources.

App Service Plan—Select the applicable service plan. If you select Service Plan (default), an App Service plan is created and you are billed
accordingly. If you select Consumption, you are billed based on the Consumption Plan.

App Service Plan Tier—When setting a Service Plan, you must select the applicable App Service Plan Tier from the list of options (Free
(default), Shared, Basic, Standard, Premium, and PremiumV2). Otherwise, leave the default option configured.

App Service Plan Name—When setting a Service Plan, you must set the App Service Plan Name, which must match the Service Plan Tier.

App Service Plan Capacity—When setting a Service Plan, specify how many instances do you want to set for the upper limit or leave the
default as 2. For example, when configuring an Standard Tier Service Plan, S2, set a value from 1 to 10.

Github Repo URL—Specify the URL of the repo that contains the function app source. Leave the default as
https://github.com/PaloAltoNetworks/AzureNetworkWatcherNSGFlowLogsConnector.git or specify your fork's address here.

Github Repo Branch—Specify the name of the branch containing the code you want to deploy. Leave the default as master or specify the
applicable branch.

Nsg Source Data Connection—Specify your storage account connection string for your Azure Network Watcher.

1. From the Microsoft Azure Console, open the Storage accounts page, and select the storage account that contains the connection string
for the Azure Network Watcher you have configured for data collection by Cortex XSIAM .

2. Select Security + networking → Access keys, and click Show keys.

3. Copy the applicable Connection string and paste it in the Nsg Source Data Connection field.

Output Binding—Select where you want to send you logs to either xdr (default) or eventhub.

XDR Host—Specify the API URL that you recorded when you configured the Azure Network Watcher collection in Cortex XSIAM.

XDR Token—Specify the token you received.

d. Click Review + Create to confirm your settings for the Azure Function.

e. Click Create. It can take a few minutes for the deployment to complete.

Once events start to come in, a green check mark appears underneath the Azure Network Watcher configuration that you created in Cortex XSIAM with
the amount of data received.

8.4.3.10 | Ingest Logs and Data from Okta

Abstract

Ingest authentication logs and data from Okta for use in Cortex XSIAM authentication stories.

To receive logs and data from Okta, you must configure the Data Sources settings in Cortex XSIAM. After you set up data collection, Cortex XSIAM immediately
begins receiving new logs and data from the source. The information from Okta is then searchable in XQL Search using the okta_sso_raw dataset. In addition,
depending on the event type, data is normalized to either xdr_data or saas_audit_logs datasets.

You can collect all types of events from Okta. When setting up the Okta data collector in Cortex XSIAM , a field called Okta Filter is available to configure
collection for events of your choosing. All events are collected by default unless you define an Okta API Filter expression for collecting the data, such as
filter=eventType eq “user.session.start”.\n. For Okta information to be weaved into authentication stories, “user.authentication.sso” events
must be collected.

Since the Okta API enforces concurrent rate limits, the Okta data collector is built with a mechanism to reduce the amount of requests whenever an error is
received from the Okta API indicating that too many requests have already been sent. In addition, to ensure you are properly notified about this, an alert is
displayed in the Notification Area and a record is added to the Management Audit Logs.

Before you begin configuring data collection from Okta, ensure your Okta user has administrator privileges with a role that can create API tokens, such as the
read-only administrator, Super administrator, and Organization administrator. For more information, see the Okta Administrators Documentation.

To configure the Okta collection in Cortex XSIAM:

1. Identify the domain name of your Okta service.

From the Dashboard of your Okta console, note your Org URL.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 638/1003
5/8/24, 9:18 AM PDF Export

For more information, see the Okta Documentation.

2. Obtain your authentication token in Okta.

a. Select API → Tokens.

b. Create Token and record the token value.

This is your only opportunity to record the value.

3. Select Settings → Configurations → Data Collection → Data Sources.

4. Integrate the Okta authentication service with Cortex XSIAM .

a. Specify the OKTA DOMAIN (Org URL) that you identified on your Okta console.

b. Specify the TOKEN used to authenticate with Okta.

c. Specify the Okta Filter to configure collection for events of your choosing. All events are collected by default unless you define an Okta API Filter
expression for collecting the data, such as filter=eventType eq “user.session.start”.\n. For Okta information to be weaved into
authentication stories, “user.authentication.sso” events must be collected.

d. Test the connection settings.

e. If successful, Enable Okta log collection.

Once events start to come in, a green check mark appears underneath the Okta configuration with the amount of data received.

5. After Cortex XSIAM begins receiving information from the service, you can Create an XQL Query to search for specific data. When including
authentication events, you can also Create an Authentication Query to search for specific authentication data.

8.4.3.11 | Ingest Logs from Windows DHCP using Elasticsearch Filebeat

Abstract

Learn how to configure Cortex XSIAM to receive Windows DHCP logs.

You can configure Cortex XSIAM to receive Windows DHCP logs using Elasticsearch Filebeat with the following data collectors.

XDR Collectors (recommended)

Windows DHCP

Ingest Windows DHCP Logs with an XDR Collector Profile

Abstract

Extend Cortex XSIAM visibility into logs from Windows DHCP using an XDR Collector Windows Filebeat profile.

Extend Cortex XSIAM visibility into logs from Windows DHCP using an XDR Collector Windows Filebeat profile.

You can enrich network logs with Windows DHCP data when defining data collection in an XDR Collector Windows Filebeat profile. When you add a XDR
Collector Windows Filebeat profile using the Elasticsearch Filebeat default configuration file called filebeat.yml, you can define whether the collected data
undergoes follow-up processing in the backend for Windows DHCP data. Cortex XSIAM uses Windows DHCP logs to enrich your network logs with hostnames
and MAC addresses that are searchable in XQL Search using the Windows DHCP Cortex Query Language (XQL) dataset (microsoft_dhcp_raw).

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 639/1003
5/8/24, 9:18 AM PDF Export

While this enrichment is also available when configuring a Windows DHCP Collector for a cloud data collection integration, we recommend configuring Cortex
XSIAM to receive Windows DHCP logs with an XDR Collector Windows Filebeat profile as it’s the ideal setup configuration.

Configure Cortex XSIAM to receive logs from Windows DHCP using an XDR Collector Windows Filebeat profile.

1. Add an XDR Collector Profile for Windows.

Follow the steps for creating a Windows Filebeat profile as described in Add an XDR Collector Profile for Windows, and in the Filebeat Configuration File
area, ensure that you select and Add the DHCP template. The template's content will be displayed here, and is editable.

2. To configure collection of Windows DHCP data, edit the template text as necessary for your system.

You can enrich network logs with Windows DHCP data when defining data collection by setting the vendor to “microsoft” , and product to “dhcp” in
the filebeat.yml file, which you can then query in the microsoft_dhcp_raw dataset.

NOTE:

To avoid formatting issues in filebeat.yml, we recommend that you edit the text file inside the user interface, instead of copying it and editing it
elsewhere. Validate the syntax of the YML file before you finish creating the profile.

Ingest Windows DHCP Logs with the Windows DHCP Collector

Abstract

Extend Cortex XSIAM visibility into logs from Windows DHCP using Elasticsearch Filebeat with the Windows DHCP data collector.

Extend Cortex XSIAM visibility into logs from Windows DHCP using Elasticsearch Filebeat with the Windows DHCP data collector.

To receive Windows DHCP logs, you must configure data collection from Windows DHCP via Elasticsearch Filebeat. This is configured by setting up a Windows
DHCP Collector in Cortex XSIAM and installing and configuring an Elasticsearch Filebeat agent on your Windows DHCP Server. Cortex XSIAM supports using
Filebeat up to version 8.0.1 with the Windows DHCP Collector.

Certain settings in the Elasticsearch Filebeat default configuration file called filebeat.yml must be populated with values provided when you configure the
Data Sources settings in Cortex XSIAM for the Windows DHCP Collector. To help you configure the filebeat.yml correctly, Cortex XSIAM provides an
example file that you can download and customize. After you set up collection integration, Cortex XSIAM begins receiving new logs and data from the source.

NOTE:

For more information on configuring the filebeat.yml file, see the Elastic Filebeat Documentation.

Windows DHCP logs are stored as CSV (comma-separated values) log files. The logs rotate by days (DhcpSrvLog-<day>.log), and each file contains two
sections - Event ID Meaning and the events list.

As soon as Cortex XSIAM begins receiving logs, the app automatically creates a Windows DHCP XQL dataset (microsoft_dhcp_raw). Cortex XSIAM uses
Windows DHCP logs to enrich your network logs with hostnames and MAC addresses that are searchable in XQL Search using the Windows DHCP Cortex
Query Language (XQL) dataset.

Configure Cortex XSIAM to receive logs from Windows DHCP via Elasticsearch Filebeat with the Windows DHCP collector.

1. Configure the Windows DHCP Collector in Cortex XSIAM.

a. Select Settings → Data Sources.

b. In the Windows DHCP Collector configuration, click Add Instance to begin a new configuration.

The Enable Windows DHCP Log Collection dialog box is displayed.

c. (Optional) Download example filebeat.yml file.

To help you configure your filebeat.yml file correctly, Cortex XSIAM provides an example filebeat.yml file that you can download and customize.
To download this file, use the link provided in this dialog box.

NOTE:

To avoid formatting issues in your filebeat.yml, we recommend that you use the download example file to make your customizations. Do not
copy and paste the code syntax examples provided later in this procedure into your file.

d. Specify a descriptive Name for your log collection configuration.

e. Save & Generate Token. The token is displayed in a blue box, which is blurred out in the image below.

Click the copy icon next to the key and record it somewhere safe. You will need to provide this key when you set the api_key value in the
Elasticsearch Output section in the filebeat.yml file as explained in Step #2. If you forget to record the key and close the window you will need
to generate a new key and repeat this process.

f. Select Done to close the window.

g. In the Integrations page for the Windows DHCP Collector that you created, select Copy api url and record it somewhere safe. You will need to
provide this URL when you set the hosts value in the Elasticsearch Output section in the filebeat.yml file as explained in Step #2.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 640/1003
5/8/24, 9:18 AM PDF Export

2. Configure an Elasticsearch Filebeat agent on your Windows DHCP Server.

a. Navigate to the Elasticsearch Filebeat installation directory, and open the filebeat.yml file to configure data collection with Cortex XSIAM. We
recommend that you use the download example file provided by Cortex XSIAM.

b. Update the following sections and tags in the filebeat.yml file. The example code below details the specific sections to make these changes in
the file.

Filebeat inputs—Define the paths to crawl and fetch. The code below provides an example of how to configure the Filebeat inputs section
in the filebeat.yml file with these paths configured.

# ============================== Filebeat inputs ===============================

filebeat.inputs:
# Each - is an input. Most options can be set at the input level, so
# you can use different inputs for various configurations.
# Below are the input specific configurations.
- type: log
# Change to true to enable this input configuration.
enabled: true
# Paths that should be crawled and fetched. Glob based paths.
paths:
- c:\Windows\System32\dhcp\DhcpSrvLog*.log

Elasticsearch Output—Set the hosts and api_key, where both of these values are obtained when you configured the Windows DHCP
Collector in Cortex XSIAM as explained in Step #1. The code below provides an example of how to configure the Elasticsearch Output
section in the filebeat.yml file and indicates which settings need to be obtained from Cortex XSIAM.

# ---------------------------- Elasticsearch Output ----------------------------

output.elasticsearch:
enabled: true
# Array of hosts to connect to.
hosts: ["OBTAIN THIS URL FROM CORTEX XDR"]
# Protocol - either `http` (default) or `https`.
protocol: "https"
compression_level: 5
# Authentication credentials - either API key or username/password.
api_key: "OBTAIN THIS KEY FROM CORTEX XDR"

Processors—Set the tokenizer and add a drop_event processor to drop all events that do not start with an event ID. The code below
provides an example of how to configure the Processors section in the filebeat.yml file and indicates which settings need to be obtained
from Cortex XSIAM.

NOTE:

The tokenizer definition is dependent on the Windows server version that you are using as the log format differs.

-For platforms earlier than Windows Server 2008, use "%{id},%{date},%{time},%{description},%{ipAddress},%{hostName},%

{macAddress}"

-For Windows Server 2008 and 2008 R2, use "%{id},%{date},%{time},%{description},%{ipAddress},%{hostName},%

{macAddress},%{userName},%{transactionID},%{qResult},%{probationTime},%{correlationID}"

For Windows Server 2012 and above, use "%{id},%{date},%{time},%{description},%{ipAddress},%{hostName},%

{macAddress},%{userName},%{transactionID},%{qResult},%{probationTime},%{correlationID},%{dhcid},%
{vendorClassHex},%{vendorClassASCII},%{userClassHex},%{userClassASCII},%{relayAgentInformation},%{dnsRegError}"

# ================================= Processors =================================

processors:
- add_host_metadata:
when.not.contains.tags: forwarded
- drop_event.when.not.regexp.message: "^[0-9]+,.*"
- dissect:
tokenizer: "%{id},%{date},%{time},%{description},%{ipAddress},%{hostName},%{macAddress},%{userName},%{transactionID},%{qResult},%{probationTime},%
{correlationID},%{dhcid},%{vendorClassHex},%{vendorClassASCII},%{userClassHex},%{userClassASCII},%{relayAgentInformation},%{dnsRegError}"
- drop_fields:
fields: ["message"]
- add_locale: ~
- rename:
fields:
- from: "event.timezone"
to: "dissect.timezone"
ignore_missing: true
fail_on_error: false
- add_cloud_metadata: ~
- add_docker_metadata: ~
- add_kubernetes_metadata: ~

3. Verify the status of the integration.

Return to the Integrations page and view the statistics for the log collection configuration.

4. After Cortex XSIAM begins receiving logs from Windows DHCP via Elasticsearch Filebeat, you can use the XQL Search to search for logs in the new
dataset (microsoft_dhcp_raw).

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 641/1003
5/8/24, 9:18 AM PDF Export

8.4.3.12 | Ingest Logs from Zscaler Internet Access

Abstract

Extend Cortex XSIAM visibility into logs from Zscaler Internet Access (ZIA).

If you use Zscaler Internet Access (ZIA) in your network, you can forward your firewall and network logs to Cortex XSIAM for analysis. This enables you to take
advantage of Cortex XSIAM anomalous behavior detection and investigation capabilities. Cortex XSIAM can use the firewall and network logs from ZIA as the
sole data source, and can also use these firewall and network logs from ZIA in conjunction with Palo Alto Networks firewall and network logs. For additional
endpoint context, you can also use Cortex XSIAM to collect and alert on endpoint data.

To integrate your logs, you first need to set up an applet in a broker VM within your network to act as a Syslog Collector. You then configure forwarding on your
log devices to send logs to the Syslog collector in a CEF format. To provide seamless log ingestion, Cortex XSIAM automatically maps the fields in your traffic
logs to the Cortex XSIAM log format.

As soon as Cortex XSIAM starts to receive logs, the app performs these actions.

Begins stitching network connection and firewall logs with other logs to form network stories. Cortex XSIAM can also analyze your logs to raise Analytics
alerts and can apply IOC, BIOC, and Correlation Rule matching. You can also use queries to search your network connection logs.

Creates a Zscaler Cortex Query Language (XQL) dataset, which enables you to search the logs using XQL Search. The Zscaler XQL datasets are
dependent on the ZIA NSS Feed that you've configured for the types of logs you want to collect.

Firewall logs: zscaler_nssfwlog_raw

Web logs: zscalar_nssweblog_raw

To ingest logs from Zscaler Internet Access (ZIA):

1. Activate the Syslog Collector.

2. Increase log storage for ZIA logs. For more information, see Manage Your Log Storage.

3. Configure NSS log forwarding in Zscaler Internet Access to the Syslog Collector in a CEF format.

a. In the Zscaler Internet Access application, select Administration → Nanolog Streaming Service.

b. In the NSS Feeds tab, Add NSS Feed.

c. In the Add NSS Feed screen, configure the fields for the Cortex XSIAM Syslog Collector.

The steps below differ depending on the type of NSS Feed you are configuring to collect either firewall logs or web logs. For more information on all
the configurations available on the screen, see the ZIA documentation:

Firewall logs: See Adding NSS Feeds for Firewall Logs.

Web logs: See Adding NSS Feeds for Web Logs.

The following image displays the fields required to add an NSS feed.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 642/1003
5/8/24, 9:18 AM PDF Export

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 643/1003
5/8/24, 9:18 AM PDF Export

NSS Type—Select either NSS for Web (default) to collect web logs or NSS for Firewall to collect firewall logs.

SIEM TCP Port—Specify the port that you set when activating the Syslog Collector in Cortex XSIAM . See Activate the Syslog Collector.

SIEM IP Address—Specify the IP that you set when activating the Syslog Collector in Cortex XSIAM . See Activate the Syslog Collector.

Feed Escape Character—Specify the feed escape character as =.

Feed Output Type—Select Custom.

Feed Output Format—Specify the output format, which is dependent on the type of logs you are collecting as defined in the NSS Type field:

Log Type Feed Output Format

Firewall %s{mon} %02d{dd} %02d{hh}:%02d{mm}:%02d{ss} zscaler-nss-fw

logs CEF:0|Zscaler|NSSFWlog|5.7|%s{action}|%s{rulelabel}|3|act=%s{action} suser=%s{login} src=%s{csip}
spt=%d{csport} dst=%s{cdip} dpt=%d{cdport} deviceTranslatedAddress=%s{ssip}
deviceTranslatedPort=%d{ssport} destinationTranslatedAddress=%s{sdip}
destinationTranslatedPort=%d{sdport} sourceTranslatedAddress=%s{tsip}
sourceTranslatedPort=%d{tsport} proto=%s{ipproto} tunnelType=%s{ttype} dnat=%s{dnat}
stateful=%s{stateful} spriv=%s{location} reason=%s{rulelabel} in=%ld{inbytes} out=%ld{outbytes}
rt=%s{mon} %02d{dd} %02d{hh}:%02d{mm}:%02d{ss} deviceDirection=1 cs1=%s{dept} cs1Label=dept
cs2=%s{nwsvc} cs2Label=nwService cs3=%s{nwapp} cs3Label=nwApp cs4=%s{aggregate} cs4Label=aggregated
cs6=%s{threatname} cs6label=threatname cn1=%d{durationms} cn1Label=durationms cn2=%d{numsessions}
cn2Label=numsessions cs5Label=ipCat cs5=%s{ipcat} cat=%s{threatcat} destCountry=%s{destcountry}
avgduration=%d{avgduration}

Web logs %s{mon} %02d{dd} %02d{hh}:%02d{mm}:%02d{ss} zscaler-nss

CEF:0|Zscaler|NSSWeblog|5.0|%s{action}|%s{reason}|3|act=%s{action} app=%s{proto} cat=%s{urlcat}
dhost=%s{ehost} dst=%s{sip} src=%s{cip} in=%d{respsize} outcome=%s{respcode} out=%d{reqsize}
request=%s{eurl} rt=%s{mon} %02d{dd} %d{yy} %02d{hh}:%02d{mm}:%02d{ss}
sourceTranslatedAddress=%s{cintip} requestClientApplication=%s{ua} requestMethod=%s{reqmethod}
suser=%s{login} spriv=%s{location} externalId=%d{recordid} fileType=%s{filetype} reason=%s{reason}
destinationServiceName=%s{appname} cn1=%d{riskscore} cn1Label=riskscore cs1=%s{dept} cs1Label=dept
cs2=%s{urlsupercat} cs2Label=urlsupercat cs3=%s{appclass} cs3Label=appclass cs4=%s{malwarecat}
cs4Label=malwarecat cs5=%s{threatname} cs5Label=threatname cs6=%s{dlpeng} cs6Label=dlpeng
ZscalerNSSWeblogURLClass=%s{urlclass} ZscalerNSSWeblogDLPDictionaries=%s{dlpdict}
requestContext=%s{ereferer} contenttype=%s{contenttype} unscannabletype=%s{unscannabletype}
deviceowner=%s{deviceowner} devicehostname=%s{devicehostname}\n

d. Click Save.

e. Click Save and activate the change according to the Zscaler Internet Access (ZIA) documentation.

8.4.3.13 | Ingest Logs from Zscaler Private Access

Abstract

Extend Cortex XSIAM visibility into logs from Zscaler Private Access (ZPA).

If you use Zscaler Private Access (ZPA) in your network as an alternative to VPNs, you can forward your network logs to Cortex XSIAM for analysis. This
enables you to take advantage of Cortex XSIAM anomalous behavior detection and investigation capabilities. Cortex XSIAM can use the network logs from ZPA
as the sole data source, and can also use these network logs from ZPA in conjunction with Palo Alto Networks network logs.

As soon as Cortex XSIAM starts to receive logs, the following actions are performed:

Stitching network connection logs with other logs to form network stories. Cortex XSIAM can also analyze your logs to apply IOC, BIOC, and Correlation
Rules matching. You can also use queries to search your network connection logs.

Creates a Zscaler Cortex Query Language (XQL) dataset (zscaler_zpa_raw), which enables you to search the logs using XQL Search.

To integrate your logs, you first need to set up an applet in a Broker VM within your network to act as a Syslog Collector. You then configure forwarding on your
log devices to send logs to the Syslog collector in a LEEF format. To provide seamless log ingestion, Cortex XSIAM automatically maps the fields in your traffic
logs to the Cortex XSIAM log format.

Prerequisite Step

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 644/1003
5/8/24, 9:18 AM PDF Export

Before you can add a log receiver in Zscaler Private Access, as explained in the task below, you must first deploy your App Connectors. For more information,
see App Connector Deployment Guides for Supported Platforms.

To ingest logs from Zscaler Private Access (ZPA):

1. Activate the Syslog Collector.

2. Increase log storage for ZPA logs. For more information, see Manage Your Log Storage.

3. Configure ZPA log forwarding in Zscaler Private Access to the Syslog Collector in a LEEF format.

a. In the Zscaler Private Access application, select Administration → Log Receivers.

b. Click Add Log Receiver.

NOTE:

For more information on configuring the parameters on the screen, see the Zscaler Private Access (ZPA) documentation for Configuring a Log
Receiver.

c. In the Add Log Receiver window, configure the following fields in Log Receiver tab:

Name—Specify a name for the log receiver. The name cannot contain special characters, with the exception of periods (.), hyphens (-), and
underscores ( _ ).

Description—(Optional) Specify a log receiver description.

Domain or IP Address—Specify the fully qualified domain name (FQDN) or IP address for the log receiver that you set when activating the
Syslog Collector in Cortex XSIAM . See Activate the Syslog Collector.

TCP Port—Specify the TCP port number used by the log receiver that you set when activating the Syslog Collector in Cortex XSIAM . See
Activate the Syslog Collector.

TLS Encryption—Toggle to Enabled to encrypt traffic between the log receiver and your Syslog Collector in Cortex XSIAMusing mutually
authenticated TLS communication. To use this setting, the log receiver must support TLS communication. For more information, see About the
Log Streaming Service.

App Connector Groups—(Optional) Select the App Connector groups that can forward logs to the receiver, and click Done. You can search for
a specific group, click Select All to apply all groups, or click Clear Selection to remove all selections.

d. Click Next.

e. Configure the following fields in the Log Stream tab:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 645/1003
5/8/24, 9:18 AM PDF Export

Log Type—Select the log type you want to collect, where only the following logs types are currently supported to collect with your Syslog
Collector in Cortex XSIAM:

NOTE:

You can only configure a ZPA log receiver to collect one type of log with your Syslog Collector in Cortex XSIAM. To configure more that one
log type, you'll need to add another log receiver.

User Activity—Information on end user requests to applications. For more information, see User Activity Log Fields.

User Status—Information related to an end user's availability and connection to ZPA. For more information, see User Status Log Fields.

App Connector Status—Information related to an App Connector's availability and connection to ZPA. For more information, see About
App Connector Status Log Fields.

Audit Logs—Session information for all admins accessing the ZPA Admin Portal. For more information, See About Audit Log
Fields and About Audit Logs.

Log Template—Select a Custom template.

Log Stream Content—From the table below, copy the applicable log template according to the Log Type you've selected and paste it into the
Log Stream Content field.

Log Type Log Template

LEEF:1.0|Zscaler|ZPA|4.1|%s{ConnectionStatus}%s{InternalReason}|cat=ZPA User
User Activity Activity\tdevTime=%s{LogTimestamp:epoch}\tCustomer=%s{Customer}\tSessionID=%s
{SessionID}\tConnectionID=%s{ConnectionID}\tInternalReason=%s{InternalReason}
\tConnectionStatus=%s{ConnectionStatus}\tproto=%d{IPProtocol}
\tDoubleEncryption=%d{DoubleEncryption}\tusrName=%s{Username}
\tdstPort=%d{ServicePort}\tsrc=%s{ClientPublicIP}\tsrcPreNAT=%s{ClientPrivateIP}
\tClientLatitude=%f{ClientLatitude}\tClientLongitude=%f{ClientLongitude}
\tClientCountryCode=%s{ClientCountryCode}\tClientZEN=%s{ClientZEN}
\tpolicy=%s{Policy}\tConnector=%s{Connector}\tConnectorZEN=%s{ConnectorZEN}
\tConnectorIP=%s{ConnectorIP}\tConnectorPort=%d{ConnectorPort}
\tApplicationName=%s{Host}\tApplicationSegment=%s{Application}\tAppGroup=%s{AppGroup}
\tServer=%s{Server}\tdst=%s{ServerIP}\tServerPort=%d{ServerPort}
\tPolicyProcessingTime=%d{PolicyProcessingTime}\tServerSetupTime=%d{ServerSetupTime}
\tTimestampConnectionStart:iso8601=%s{TimestampConnectionStart:iso8601}
\tTimestampConnectionEnd:iso8601=%s{TimestampConnectionEnd:iso8601}
\tTimestampCATx:iso8601=%s{TimestampCATx:iso8601}
\tTimestampCARx:iso8601=%s{TimestampCARx:iso8601}
\tTimestampAppLearnStart:iso8601=%s{TimestampAppLearnStart:iso8601}
\tTimestampZENFirstRxClient:iso8601=%s{TimestampZENFirstRxClient:iso8601}
\tTimestampZENFirstTxClient:iso8601=%s{TimestampZENFirstTxClient:iso8601}
\tTimestampZENLastRxClient:iso8601=%s{TimestampZENLastRxClient:iso8601}
\tTimestampZENLastTxClient:iso8601=%s{TimestampZENLastTxClient:iso8601}
\tTimestampConnectorZENSetupComplete:iso8601=%s{TimestampConnectorZENSetupComplete:iso8601}
\tTimestampZENFirstRxConnector:iso8601=%s{TimestampZENFirstRxConnector:iso8601}
\tTimestampZENFirstTxConnector:iso8601=%s{TimestampZENFirstTxConnector:iso8601}
\tTimestampZENLastRxConnector:iso8601=%s{TimestampZENLastRxConnector:iso8601}
\tTimestampZENLastTxConnector:iso8601=%s{TimestampZENLastTxConnector:iso8601}
\tZENTotalBytesRxClient=%d{ZENTotalBytesRxClient}\tZENBytesRxClient=%d{ZENBytesRxClient}
\tZENTotalBytesTxClient=%d{ZENTotalBytesTxClient}\tZENBytesTxClient=%d{ZENBytesTxClient}
\tZENTotalBytesRxConnector=%d{ZENTotalBytesRxConnector}
\tZENBytesRxConnector=%d{ZENBytesRxConnector}
\tZENTotalBytesTxConnector=%d{ZENTotalBytesTxConnector}
\tZENBytesTxConnector=%d{ZENBytesTxConnector}\tIdp=%s{Idp}\n

LEEF:1.0|Zscaler|ZPA|4.1|%s{SessionStatus}|cat=ZPA User Status

User Status \tdevTime=%s{LogTimestamp:epoch}\tCustomer=%s{Customer}
\tusrName=%s{Username}\tSessionID=%s{SessionID}\tSessionStatus=%s{SessionStatus}
\tVersion=%s{Version}\tZEN=%s{ZEN}\tCertificateCN=%s{CertificateCN}
\tsrcPreNAT=%s{PrivateIP}\tsrc=%s{PublicIP}\tLatitude=%f{Latitude}
\tLongitude=%f{Longitude}\tCountryCode=%s{CountryCode}
\tTimestampAuthentication:iso8601=%s{TimestampAuthentication:iso8601}
\tTimestampUnAuthentication:iso8601=%s{TimestampUnAuthentication:iso8601}
\tdstBytes=%d{TotalBytesRx}\tsrcBytes=%d{TotalBytesTx}\tIdp=%s{Idp}
\tidentHostName=%s{Hostname}\tPlatform=%s{Platform}\tClientType=%s{ClientType}
\tTrustedNetworks=%s(,){TrustedNetworks}\tTrustedNetworksNames=%s(,){TrustedNetworksNames}
\tSAMLAttributes=%s{SAMLAttributes}\tPosturesHit=%s(,){PosturesHit}
\tPosturesMiss=%s(,){PosturesMiss}\tZENLatitude=%f{ZENLatitude}
\tZENLongitude=%f{ZENLongitude}\tZENCountryCode=%s{ZENCountryCode}\n

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 646/1003
5/8/24, 9:18 AM PDF Export

Log Type Log Template

LEEF:1.0|Zscaler|ZPA|4.1|%s{SessionStatus}|cat=Connector Status
App Connector Status \tdevTime=%s{LogTimestamp:epoch}\tCustomer=%s{Customer}\tSessionID=%s{SessionID}
\tSessionType=%s{SessionType}\tVersion=%s{Version}\tPlatform=%s{Platform}
\tZEN=%s{ZEN}\tConnector=%s{Connector}\tConnectorGroup=%s{ConnectorGroup}
\tsrcPreNAT=%s{PrivateIP}\tsrc=%s{PublicIP}\tLatitude=%f{Latitude}
\tLongitude=%f{Longitude}\tCountryCode=%s{CountryCode}
\tTimestampAuthentication:iso8601=%s{TimestampAuthentication:iso8601}
\tTimestampUnAuthentication:iso8601=%s{TimestampUnAuthentication:iso8601}
\tCPUUtilization=%d{CPUUtilization}\tMemUtilization=%d{MemUtilization}
\tServiceCount=%d{ServiceCount}\tInterfaceDefRoute=%s{InterfaceDefRoute}
\tDefRouteGW=%s{DefRouteGW}\tPrimaryDNSResolver=%s{PrimaryDNSResolver}
\tHostStartTime=%s{HostStartTime}\tConnectorStartTime=%s{ConnectorStartTime}
\tNumOfInterfaces=%d{NumOfInterfaces}\tBytesRxInterface=%d{BytesRxInterface}
\tPacketsRxInterface=%d{PacketsRxInterface}\tErrorsRxInterface=%d{ErrorsRxInterface}
\tDiscardsRxInterface=%d{DiscardsRxInterface}\tBytesTxInterface=%d{BytesTxInterface}
\tPacketsTxInterface=%d{PacketsTxInterface}\tErrorsTxInterface=%d{ErrorsTxInterface}
\tDiscardsTxInterface=%d{DiscardsTxInterface}\tTotalBytesRx=%d{TotalBytesRx}
\tTotalBytesTx=%d{TotalBytesTx}

LEEF:1.0|Zscaler|ZPA|4.1|%s{auditOperationType}|cat=ZPA_Audit_Log
Audit Logs \tdevTime=%s{LogTimestamp:epoch}\tcreationTime=%s{creationTime:iso8601}
\trequestId=%s{requestId}\tsessionId=%s{sessionId}\tauditOldValue=%s{auditOldValue}
\tauditNewValue=%s{auditNewValue}\tauditOperationType=%s{auditOperationType}
\tobjectType=%s{objectType}\tobjectName=%s{objectName}\tobjectId=%d{objectId}
\taccountName=%d{customerId}\tusrName=%s{modifiedByUser}\n

(Optional) You can define a streaming Policy for the log receiver. This entails configuring the SAML Attributes, Application Segments,
Segment Groups, Client Types, and Session Statuses. For more information on configuring these settings, see the Log Stream instructions.

f. Click Next.

g. In the Review tab, verify your log receiver configuration.

h. Click Save.

8.4.4 | Ingest Authentication Logs and Data

Abstract

Ingest authentication logs from external authentication services—such as Okta and Azure AD—into authentication stories with Cortex XSIAM.

When you ingest authentication logs and data from an external source, Cortex XSIAM can weave that information into authentication stories. An authentication
story unites logs and data regardless of the information source (for example, from an on-premise KDC or from a cloud-based authentication service) into a
uniform schema. To search authentication stories, you can use the Query Builder or XQL Search.

Cortex XSIAM can ingest authentication logs and data from various authentication services.

8.4.4.1 | Ingest Audit Logs from AWS Cloud Trail

Abstract

Take advantage of Cortex XSIAM investigation capabilities and set up audit log ingestion for your AWS CloudTrail logs.

You can forward audit logs for the relative service to Cortex XSIAM from AWS CloudTrail.

To receive audit logs from Amazon Simple Storage Service (Amazon S3) via AWS CloudTrail, you must first configure data collection from Amazon S3. You can
then configure the Data Sources settings in Cortex XSIAM for Amazon S3. After you set up collection integration, Cortex XSIAM begins receiving new logs and
data from the source.

NOTE:

For more information on configuring data collection from Amazon S3 using AWS CloudTrail, see the AWS CloudTrail Documentation.

As soon as Cortex XSIAM begins receiving logs, the app automatically creates an Amazon S3 Cortex Query Language (XQL) dataset (aws_s3_raw). This
enables you to search the logs with XQL Search using the dataset. For example queries, refer to the in-app XQL Library. As part of the enhanced cloud
protection,

For enhanced cloud protection, you can also configure Cortex XSIAM to stitch Amazon S3 audit logs with other Cortex XSIAM authentication stories across all
cloud providers using the same format, which you can query with XQL Search using the cloud_audit_logs dataset. Cortex XSIAM can also raise Cortex
XSIAM alerts (Analytics, IOC, BIOC, and Correlation Rules) when relevant from Amazon S3 logs. While Correlation Rules alerts are raised on non-normalized
and normalized logs, Analytics, IOC, and BIOC alerts are only raised on normalized logs.

Enhanced cloud protection provides the following:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 647/1003
5/8/24, 9:18 AM PDF Export

Normalization of cloud logs

Cloud logs stitching

Enrichment with cloud data

Detection based on cloud analytics

Cloud-tailored investigations

Prerequisite Steps

Be sure you do the following tasks before you begin configuring data collection from Amazon S3 via AWS CloudTrail.

Ensure that you have the proper permissions to access AWS CloudTrail and have the necessary permissions to create audit logs. You need at a minimum
the following permissions in AWS for an Amazon S3 bucket and Amazon Simple Queue Service (SQS).

Amazon S3 bucket—GetObject

SQS—ChangeMessageVisibility, ReceiveMessage, and DeleteMessage.

Determine how you want to provide access to Cortex XSIAM to your logs and to perform API operations. You have the following options.

Designate an AWS IAM user, where you will need to know the Account ID for the user and have the relevant permissions to create an access key/id
for the relevant IAM user. This is the default option as explained in Configure the Amazon S3 collection by selecting Access Key.

Create an assumed role in AWS to delegate permissions to a Cortex XSIAM AWS service. This role grants Cortex XSIAM access to your flow logs.
For more information, see Creating a role to delegate permissions to an AWS service. This is the Assumed Role option described in the Amazon S3
collection configuration.

To collect Amazon S3 logs that use server-side encryption (SSE), the user role must have an IAM policy that states that Cortex XSIAM has kms:Decrypt
permissions. With this permission, Amazon S3 automatically detects if a bucket is encrypted and decrypts it. If you want to collect encrypted logs from
different accounts, you must have the decrypt permissions for the user role also in the key policy for the master account Key Management Service (KMS).
For more information, see Allowing users in other accounts to use a KMS key.

To configure Cortex XSIAM to receive audit logs from Amazon S3 via AWS Cloudtrail:

1. Log in to the AWS Management Console.

2. From the menu bar, ensure that you have selected the correct region for your configuration.

3. Configure an AWS CloudTrail trail with audit logs.

NOTE:

For more information on creating an AWS CloudTrail trail, see Create a trail.

If you already have an Amazon S3 bucket configured with AWS CloudTrail audit logs, skip this step and go to Configure an Amazon Simple
Queue Service (SQS).

a. Open the CloudTrail Console, and click Create trail.

b. Configure the following settings for your CloudTrail trail, where the default settings should be configured unless otherwise indicated.

Trail name—Specify a descriptive name for your CloudTrail trail.

Storage location—Select Create new S3 bucket to configure a new Amazon S3 bucket, and specify a unique name in the Trail log bucket and
folder field, or select Use existing S3 bucket and Browse to the S3 bucket you already created. If you select an existing Amazon S3 bucket,
the bucket policy must grant CloudTrail permission to write to it. For information about manually editing the bucket policy, see Amazon S3
Bucket Policy for CloudTrail.

NOTE:

It is the customer’s responsibility to define a retention policy for your Amazon S3 bucket by creating a Lifecycle rule in the Management tab.
We recommend setting the retention policy to at least 7 days to ensure that the data is retrieved under all circumstances.

Customer managed AWS KMS key—You can either select a New key and specify the AWS KMS alias, or select an Existing key, and select
the AWS KMS alias. The KMS key and S3 bucket must be in the same region.

SNS notification delivery—(Optional) If you want to be notified whenever CloudTrail publishes a new log to your Amazon S3 bucket, click
Enabled. Amazon Simple Notification Service (Amazon SNS) manages these notifications, which are sent for every log file delivery to your S3
bucket, as opposed to every event. When you enable this option, you can either Create a new SNS topic by selecting New and the SNS topic
is displayed in the field, or use an Existing topic and select the SNS topic. For more information, see Configure SNS Notifications for
CloudTrail.

NOTE:

The CloudWatch Logs - optional settings are not supported and should be left disabled.

c. Click Next, and configure the following Choose log events settings.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 648/1003
5/8/24, 9:18 AM PDF Export

Event type—Leave the default Management events checkbox selected to capture audit logs. Depending on your system requirements, you
can also select Data events to log the resource operations performed on or within a resource, or Insights events to identify unusual activity,
errors, or user behavior in your account. Based on your selection, additional fields are displayed on the screen to configure under section
headings with the same name as the event type.

Management events section—Configure the following settings.

-API activity—For Management events, select the API activities you want to log. By default, the Read and Write activities are logged.

-Exclude AWS KMS events—(Optional) If you want to filter AWS Key Management Service (AWS KMS) events out of your trail, select the
checkbox. By default, all AWS KMS events are included.

Data events section—(Optional) This section is displayed when you configure the Event type to include Data events, which relate to resource
operations performed on or within a resource, such as reading and writing to a S3 bucket. For more information on configuring these optional
settings in AWS CloudTrail, see Creating a trail.

Insights events section—(Optional) This section is displayed when you configure the Event type to include Insight events, which relate to
unusual activities, errors, or user behavior on your account. For more information on configuring these optional settings in AWS CloudTrail,
see Creating a trail.

d. Click Next.

e. In the Review and create page, look over the trail configurations settings that you have configured and if they are correct, click Create trail. If you
need to make a change, click Edit beside the particular step that you want to update.

The new trail is listed in the Trails page, which lists the trails in your account from all Regions. It can take up to 15 minutes for CloudTrail to begin
publishing log files. You can see the log files in the S3 bucket that you specified. For more information, see Creating a trail.

4. Configure an Amazon Simple Queue Service (SQS).

NOTE:

Ensure that you create your Amazon S3 bucket and Amazon SQS queue in the same region.

a. In the Amazon SQS Console, click Create Queue.

b. Configure the following settings, where the default settings should be configured unless otherwise indicated.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 649/1003
5/8/24, 9:18 AM PDF Export

Type—Select Standard queue (default).

Name—Specify a descriptive name for your SQS queue.

Configuration section—Leave the default settings for the various fields.

Access policy → Choose method—Select Advanced and update the Access policy code in the editor window to enable your Amazon S3
bucket to publish event notification messages to your SQS queue. Use this sample code as a guide for defining the “Statement” with the
following definitions:

-“Resource”—Leave the automatically generated ARN for the SQS queue that is set in the code, which uses the format
“arn:sns:Region:account-id:topic-name”.

You can retrieve your bucket’s ARN by opening the Amazon S3 Console in a browser window. In the Buckets section, select the bucket that
you created for collecting the Amazon S3 flow logs, click Copy ARN, and paste the ARN in the field.

NOTE:

For more information on granting permissions to publish messages to an SQS queue, see Granting permissions to publish event
notification messages to a destination.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "s3.amazonaws.com"
},
"Action": "SQS:SendMessage",
"Resource": "[Leave automatically generated ARN for the SQS queue defined by AWS]",
"Condition": {
"ArnLike": {
"aws:SourceArn": "[ARN of your Amazon S3 bucket]"
}
}
},
]
}

Dead-letter queue section—We recommend that you configure a queue for sending undeliverable messages by selecting Enabled, and then
in the Choose queue field selecting the queue to send the messages. You may need to create a new queue for this, if you do not already have
one set up. For more information, see Amazon SQS dead-letter queues.

c. Click Create queue.

Once the SQS is created, a message indicating that the queue was successfully configured is displayed at the top of the page.

5. Configure an event notification to your Amazon SQS whenever a file is written to your Amazon S3 bucket.

a. Open the Amazon S3 Console and in the Properties tab of your Amazon S3 bucket, scroll down to the Event notifications section, and click Create
event notification.

b. Configure the following settings.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 650/1003
5/8/24, 9:18 AM PDF Export

Event name—Specify a descriptive name for your event notification containing up to 255 characters.

Prefix—Do not set a prefix as the Amazon S3 bucket is meant to be a dedicated bucket for collecting audit logs.

Event types—Select All object create events for the type of event notifications that you want to receive.

Destination—Select SQS queue to send notifications to an SQS queue to be read by a server.

Specify SQS queue—You can either select Choose from your SQS queues and then select the SQS queue, or select Enter SQS queue ARN
and specify the ARN in the SQS queue field.

You can retrieve your SQS queue ARN by opening another instance of the AWS Management Console in a browser window, and opening the
Amazon SQS Console, and selecting the Amazon SQS that you created. In the Details section, under ARN, click the copy icon ( )), and
paste the ARN in the field.

c. Click Save changes.

Once the event notification is created, a message indicating that the event notification was successfully created is displayed at the top of the page.

NOTE:

If your receive an error when trying to save your changes, you should ensure that the permissions are set up correctly.

6. Configure access keys for the AWS IAM user that Cortex XSIAM uses for API operations.

NOTE:

It is the responsibility of the customer’s organization to ensure that the user who performs this task of creating the access key is designated with
the relevant permissions. Otherwise, this can cause the process to fail with errors.

Skip this step if you are using an Assumed Role for Cortex XSIAM.

a. Open the AWS IAM Console, and in the navigation pane, select Access management → Users.

b. Select the User name of the AWS IAM user.

c. Select the Security credentials tab, scroll down to the Access keys section, and click Create access key.

d. Click the copy icon next to the Access key ID and Secret access key keys, where you must click Show secret access key to see the secret key and
record them somewhere safe before closing the window. You will need to provide these keys when you edit the Access policy of the SQS queue and
when setting the AWS Client ID and AWS Client Secret in Cortex XSIAM. If you forget to record the keys and close the window, you will need to
generate new keys and repeat this process.

NOTE:

For more information, see Managing access keys for IAM users.

7. Update the Access policy of your Amazon SQS queue.

NOTE:

Skip this step if you are using an Assumed Role for Cortex XSIAM.

a. In the Amazon SQS Console, select the SQS queue that you created in Configure an Amazon Simple Queue Service (SQS).

b. Select the Access policy tab, and Edit the Access policy code in the editor window to enable the IAM user to perform operations on the Amazon
SQS with permissions to SQS:ChangeMessageVisibility, SQS:DeleteMessage, and SQS:ReceiveMessage. Use this sample code as a guide for
defining the “Sid”: “__receiver_statement” with the following definitions.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 651/1003
5/8/24, 9:18 AM PDF Export

“aws:SourceArn”—Specify the ARN of the AWS IAM user. You can retrieve the User ARN from the Security credentials tab, which you
accessed when configuring access keys for the AWS API user.

“Resource”—Leave the automatically generated ARN for the SQS queue that is set in the code, which uses the format
“arn:sns:Region:account-id:topic-name”.

NOTE:

For more information on granting permissions to publish messages to an SQS queue, see Granting permissions to publish event
notification messages to a destination.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "s3.amazonaws.com"
},
"Action": "SQS:SendMessage",
"Resource": "[Leave automatically generated ARN for the SQS queue defined by AWS]",
"Condition": {
"ArnLike": {
"aws:SourceArn": "[ARN of your Amazon S3 bucket]"
}
}
},
{
"Sid": "__receiver_statement",
"Effect": "Allow",
"Principal": {
"AWS": "[Add the ARN for the AWS IAM user]"
},
"Action": [
"SQS:ChangeMessageVisibility",
"SQS:DeleteMessage",
"SQS:ReceiveMessage"
],
"Resource": "[Leave automatically generated ARN for the SQS queue defined by AWS]"
}
]
}

8. Configure the Amazon S3 collection in Cortex XSIAM .

a. Select Settings → Configurations → Data Collection → Data Sources.

b. In the Amazon S3 configuration, click Add Instance to begin a new configuration.

c. Set these parameters, where the parameters change depending on whether you configured an Access Key or Assumed Role.

To provide access to Cortex XSIAM to your logs and perform API operations using a designated AWS IAM user, leave the Access Key option
selected. Otherwise, select Assumed Role, and ensure that you Create an Assumed Role for Cortex XSIAM before continuing with these
instructions. In addition, when you create an Assumed Role for Cortex XSIAM, ensure that you edit the policy that defines the permissions for
the role with the Amazon S3 Bucket ARN and SQS ARN.

SQS URL—Specify the SQS URL, which is the ARN of the Amazon SQS that you configured in the AWS Management Console.

Name—Specify a descriptive name for your log collection configuration.

When setting an Access Key, set these parameters.

AWS Client ID—Specify the Access key ID, which you received when you configured access keys for the AWS IAM user in AWS.

AWS Client Secret—Specify the Secret access key you received when you configured access keys for the AWS IAM user in AWS.

When setting an Assumed Role, set these parameters.

Role ARN—Specify the Role ARN for the Assumed Role you created for in AWS.

External Id—Specify the External Id for the Assumed Role you created for in AWS.

Log Type—Select Audit Logs to configure your log collection to receive audit logs from Amazon S3 via AWS CloudTrail. When configuring
audit log collection, the following additional field is displayed for Enhanced Cloud Protection.

You can Normalize and enrich audit logs by selecting the checkbox. If selected, Cortex XSIAM stitches Amazon S3 audit logs with other
Cortex XSIAM authentication stories across all cloud providers using the same format, which you can query with XQL Search using the
cloud_audit_logs dataset.

d. Click Test to validate access, and then click Enable.

Once events start to come in, a green check mark appears underneath the Amazon S3 configuration with the number of logs received.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 652/1003
5/8/24, 9:18 AM PDF Export

8.4.4.2 | Ingest Logs from Microsoft Azure Event Hub

Abstract

Ingest logs from Microsoft Azure Event Hub with an option to ingest audit logs to use in Cortex XSIAM authentication stories.

Cortex XSIAM can ingest different types of data from Microsoft Azure Event Hub using the Microsoft Azure Event Hub data collector. To receive logs from Azure
Event Hub, you must configure the Data Sources settings in Cortex XSIAM based on your Microsoft Azure Event Hub configuration. After you set up data
collection, Cortex XSIAM begins receiving new logs and data from the source.

When Cortex XSIAM begins receiving logs, the app creates a new dataset (MSFT_Azure_raw) that you can use to initiate XQL Search queries. For example,
queries refer to the in-app XQL Library. For enhanced cloud protection, you can also configure Cortex XSIAM to normalize Azure Event Hub audit logs, including
Azure Kubernetes Service (AKS) audit logs, with other Cortex XSIAM authentication stories across all cloud providers using the same format, which you can
query with XQL Search using the cloud_audit_logs dataset. For logs that you do not configure Cortex XSIAM to normalize, you can change the default
dataset. Cortex XSIAM can also raise Cortex XSIAM alerts (Analytics, IOC, BIOC, and Correlation Rules) when relevant from Azure Event Hub logs. While
Correlation Rules alerts are raised on non-normalized and normalized logs, Analytics, IOC, and BIOC alerts are only raised on normalized logs.

Enhanced cloud protection provides:

Normalization of cloud logs

Cloud logs stitching

Enrichment with cloud data

Detection based on cloud analytics

Cloud-tailored investigations

The following table provides a brief description of the different types of Azure audit logs you can collect.

NOTE:

For more information on Azure Event Hub audit logs, see Overview of Azure platform logs.

Type Of Data Description

Activity logs Retrieves events related to the operations on each Azure resource in the subscription from the outside in addition to
updates on Service Health events.

NOTE:

These logs are from the management plane.

Azure Active Directory (AD) Contain the history of sign-in activity and audit trail of changes made in Azure AD for a particular tenant.
Activity logs and Azure Sign-
NOTE:
in logs
Even though you can collect Azure AD Activity logs and Azure Sign-in logs using the Azure Event Hub data collector, we
recommend using the Office 365 data collector as it's easier to configure. In addition, ensure that you don't configure
both collectors to collect the same types of logs as you'll be creating duplicate data in Cortex XSIAM.

Resource logs, including AKS Retrieves events related to operations that were performed within an Azure resource.
audit logs
NOTE:

These logs are from the data plane.

Prerequisite Steps

Be sure you do the following tasks before you begin configuring data collection from Azure Event Hub.

Create an Azure Event Hub. For more information, see Quickstart: Create an event hub using Azure portal.

Ensure the format for the logs you want collected from the Azure Event Hub is either JSON or raw.

Configure the Azure Event Hub collection in Cortex XSIAM.

1. In the Microsoft Azure Console, open the Event Hubs page, and select the Azure Event Hub that you created for collection in Cortex XSIAM.

2. Record the following parameters from your configured event hub, which you will need when configuring data collection in Cortex XSIAM.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 653/1003
5/8/24, 9:18 AM PDF Export

Your event hub’s consumer group.

1. Select Entities → Event Hubs, and select your event hub.

2. Select Entities → Consumer groups, and select your event hub.

3. In the Consumer group table, copy the applicable value listed in the Name column for your Cortex XSIAM data collection configuration.

Your event hub’s connection string for the designated policy.

1. Select Settings → Shared access policies.

2. In the Shared access policies table, select the applicable policy.

3. Copy the Connection string-primary key.

Your storage account connection string required for partitions lease management and checkpointing in Cortex XSIAM.

1. Open the Storage accounts page, and either create a new storage account or select an existing one, which will contain the storage account
connection string.

2. Select Security + networking → Access keys, and click Show keys.

3. Copy the applicable Connection string.

3. Configure diagnostic settings for the relevant log types you want to collect and then direct these diagnostic settings to the designated Azure Event Hub.

a. Open the Microsoft Azure Console.

b. Your navigation is dependent on the type of logs you want to configure.

Log Type Navigation Path

Activity logs Select Azure services → Activity log → Export Activity Logs, and +Add diagnostic setting.

Azure AD Activity logs and Azure 1. Select Azure services → Azure Active Directory.
Sign-in logs
2. Select Monitoring → Diagnostic settings, and +Add diagnostic setting.

Resource logs, including AKS 1. Search for Monitor, and select Settings → Diagnostic settings.
audit logs
2. From your list of available resources, select the resource that you want to configure for log
collection, and then select +Add diagnostic setting.

NOTE:

For every resource that you want to confiure, you'll have to repeat this step, or use Azure policy
for a general configuration.

c. Set the following parameters:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 654/1003
5/8/24, 9:18 AM PDF Export

Diagnostic setting name—Specify a name for your Diagnostic setting.

Logs Categories/Metrics—The options listed are dependent on the type of logs you want to configure. For Activity logs and Azure AD logs and
Azure Sign-in logs, the option is called Logs Categories, and for Resource logs it's called Metrics.

Log Type Log Categories/Metrics

Activity logs Select from the list of applicable Activity log categories, the ones that you want to configure your designated
resource to collect. We recommend selecting all of the options.

Administrative

Security

ServiceHealth

Alert

Recommendation

Policy

Autoscale

ResourceHealth

Azure AD Activity logs Select from the list of applicable Azure AD Activity and Azure Sign-in Logs Categories, the ones that you want to
and Azure Sign-in configure your designated resource to collect. You can select any of the following categories to collect these
logs types of Azure logs.

Azure AD Activity logs:

AuditLogs

Azure Sign-in logs:

SignInLogs

NonInteractiveUserSignInLogs

ServicePrincipalSignInLogs

ManagedIdentitySignInLogs

ADFSSignInLogs

NOTE:

There are additional log categories displayed. We recommend selecting all the available options.

Resource logs, The list displayed is dependent on the resource that you selected. We recommend selecting all the options
including AKS audit available for the resource.
logs

Destination details—Select Stream to event hub, where additional parameters are displayed that you need to configure. Ensure that you set
the following parameters using the same settings for the Azure Event Hub that you created for the collection.

Subscription—Select the applicable Subscription for the Azure Event Hub.

Event hub namespace—Select the applicable Subscription for the Azure Event Hub.

(Optional) Event hub name—Specify the name of your Azure Event Hub.

Event hub policy—Select the applicable Event hub policy for your Azure Event Hub.

d. Save your settings.

4. Configure the Azure Event Hub collection in Cortex XSIAM.

a. Select Settings → Configurations → Data Collection → Data Sources.

b. In the Azure Event Hub configuration, click Add Instance to begin a new configuration.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 655/1003
5/8/24, 9:18 AM PDF Export

c. Set these parameters.

Name—Specify a descriptive name for your log collection configuration.

Event Hub Connection String—Specify your event hub’s connection string for the designated policy.

Storage Account Connection String—Specify your event hub’s connection string for the designated policy.

Consumer Group—Specify your event hub’s consumer group.

Log Format—Select the log format for the logs collected from the Azure Event Hub as Raw, JSON, CEF, LEEF, Cisco-asa, or Corelight.

NOTE:

When you Normalize and enrich audit logs, the log format is automatically configured. As a result, the Log Format option is removed and is
no longer available to configure (default).

CEF or LEEF: The Vendor and Product defaults to Auto-Detect.

NOTE:

For a Log Format set to CEF or LEEF, Cortex XSIAM reads events row by row to look for the Vendor and Product configured in the
logs. When the values are populated in the event log row, Cortex XSIAM uses these values even if you specified a value in the
Vendor and Product fields in the Azure Event Hub data collector settings. Yet, when the values are blank in the event log row, Cortex
XSIAM uses the Vendor and Product that you specified in the Azure Event Hub data collector settings. If you did not specify a Vendor
or Product in the Azure Event Hub data collector settings, and the values are blank in the event log row, the values for both fields are
set to unknown.

Cisco-asa: The following fields are automatically set and not configurable.

Vendor—Cisco

Product—ASA

Cisco data can be queried in XQL Search using the cisco_asa_raw dataset.

Corelight: The following fields are automatically set and not configurable.

Vendor—Corelight

Product—Zeek

Corelight data can be queried in XQL Search using the corelight_zeek_raw dataset.

Raw or JSON: The following fields are automatically set and are configurable.

Vendor—Msft

Product—Azure

Raw or JSON data can be queried in XQL Search using the msft_azure_raw dataset.

Vendor and Product—Specify the Vendor and Product for the type of logs you are ingesting.

The Vendor and Product are used to define the name of your Cortex Query Language (XQL) dataset (<vendor>_<product>_raw). The
Vendor and Product values vary depending on the Log Format selected. To uniquely identify the log source, consider changing the values if
the values are configurable.

NOTE:

When you Normalize and enrich audit logs, the Vendor and Product fields are automatically configured, so these fields are removed as
available options (default).

Normalize and enrich audit logs—(Optional) For enhanced cloud protection, you can Normalize and enrich audit logs by selecting the
checkbox (default). If selected, Cortex XSIAM normalizes and enriches Azure Event Hub audit logs with other Cortex XSIAM authentication
stories across all cloud providers using the same format. You can query this normalized data with XQL Search using the cloud_audit_logs
dataset.

d. Click Test to validate access, and then click Enable.

Once events start to come in, a green check mark appears underneath the Azure Event Hub configuration with the amount of data received.

8.4.4.3 | Ingest Logs and Data from a GCP Pub/Sub

Abstract

If you use the Pub/Sub messaging service from Global Cloud Platform (GCP), you can send logs and data from GCP to Cortex XSIAM.

If you use the Pub/Sub messaging service from Global Cloud Platform (GCP), you can send logs and data from your GCP instance to Cortex XSIAM. Data from
GCP is then searchable in Cortex XSIAM to provide additional information and context to your investigations using the GCP Cortex Query Language (XQL)

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 656/1003
5/8/24, 9:18 AM PDF Export

dataset, which is dependent on the type of GCP logs collected. For example queries, refer to the in-app XQL Library. You can configure a Google Cloud Platform
collector to receive generic, flow, audit, or Google Cloud DNS logs. When configuring generic logs, you can receive logs in a Raw, JSON, CEF, LEEF, Cisco, or
Corelight format.

You can also configure Cortex XSIAM to normalize different GCP logs as part of the enhanced cloud protection, which you can query with XQL Search using the
applicable dataset. Cortex XSIAM can also raise Cortex XSIAM alerts (Analytics, IOC, BIOC, and Correlation Rules) when relevant from GCP logs. While
Correlation Rules alerts are raised on non-normalized and normalized logs, Analytics, IOC, and BIOC alerts are only raised on normalized logs.

Enhanced cloud protection provides the following:

Normalization of cloud logs

Cloud logs stitching

Enrichment with cloud data

Detection based on cloud analytics

Cloud-tailored investigations

The following table lists the various GCP log types the XQL datasets you can use to query in XQL Search:

GCP Log Type Dataset Dataset With Normalized Data

Audit logs, including google_cloud_logging_raw cloud_audit_logs

Google Kubernetes
Engine (GKE) audit logs

Generic logs Log Format types: N/A

CEF or LEEF: Automatically detected from

either the logs or the user's input in the User
Interface.

Cisco: cisco_asa_raw

Corelight: corelight_zeek_raw

JSON or Raw:
google_cloud_logging_raw

Google Cloud DNS logs google_dns_raw xdr_data: Once configured, Cortex XSIAM ingests Google Cloud DNS
logs as XDR network connection stories, which you can query with XQL
Search using the xdr_data dataset with the preset called
network_story.

Network flow logs google_cloud_logging_raw xdr_data: Once configured, Cortex XSIAM ingests network flow logs as
XDR network connection stories, which you can query with XQL Search
using the xdr_data dataset with the preset called network_story.

NOTE:

When collecting flow logs, we recommend that you include GKE annotations in your logs, which enable you to view the names of the containers that
communicated with each other. GKE annotations are only included in logs if appended manually using the custom metadata configuration in GCP. For more
information, see VPC Flow Logs Overview. In addition, to customize metadata fields, you must use the gcloud command-line interface or the API. For more
information, see Using VPC Flow Logs.

To receive logs and data from GCP, you must first set up log forwarding using a Pub/Sub topic in GCP. You can configure GCP settings using either the GCP
web interface or a GCP cloud shell terminal. After you set up your service account in GCP, you configure the Data Collection settings in Cortex XSIAM. The
setup process requires the subscription name and authentication key from your GCP instance.

After you set up log collection, Cortex XSIAM immediately begins receiving new logs and data from GCP.

Set up Log Forwarding Using the GCP Web Interface

1. Log in to your GCP account.

2. Set up log forwarding from GCP to Cortex XSIAM.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 657/1003
5/8/24, 9:18 AM PDF Export

a. Select Logging → Logs Router.

b. Select Create Sink → Cloud Pub/Sub topic, and then click Next.

c. To filter only specific types of data, select the filter or desired resource.

d. In the Edit Sink configuration, define a descriptive Sink Name.

e. Select Sink Destination → Create new Cloud Pub/Sub topic.

f. Enter a descriptive Name that identifies the sink purpose for Cortex XSIAM, and then Create.

g. Create Sink and then Close when finished.

3. Create a subscription for your Pub/Sub topic.

a. Select the hamburger menu in G Cloud and then select Pub/Sub → Topics.

b. Select the name of the topic you created in the previous steps. Use the filters if necessary.

c. Create Subscription → Create subscription.

d. Enter a unique Subscription ID.

e. Choose Pull as the Delivery Type.

f. Create the subscription.

After the subscription is set up, G Cloud displays statistics and settings for the service.

g. In the subscription details, identify and note your Subscription Name.

Optionally, use the copy button to copy the name to the clipboard. You will need the name when you configure Collection in Cortex XSIAM.

4. Create a service account and authentication key.

You will use the key to enable Cortex XSIAM to authenticate with the subscription service.

a. Select the hamburger menu and then select IAM & Admin → Service Accounts.

b. Create Service Account.

c. Enter a Service account name and then Create.

d. Select a role for the account: Pub/Sub → Pub/Sub Subscriber.

e. Click Continue → Done.

f. Locate the service account by name, using the filters to refine the results, if needed.

g. Click the Actions menu identified by the three dots in the row for the service account and then Create Key.

h. Select JSON as the key type, and then Create.

After you create the service account key, G Cloud automatically downloads it.

5. In Cortex XSIAM, set up Data Collection.

a. Select Settings → Configurations → Data Collection → Data Sources.

b. In the Google Cloud Platform configuration, click Add Instance.

c. Specify the Subscription Name that you previously noted or copied.

d. Browse to the JSON file containing your authentication key for the service account.

e. Select the Log Type as one of the following, where your selection changes the options displayed.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 658/1003
5/8/24, 9:18 AM PDF Export

Flow or Audit Logs—When selecting this log type, you can decide whether to normalize and enrich the logs as part of the enhanced cloud
protection.

(Optional) You can Normalize and enrich flow and audit logs by selecting the checkbox (default). If selected, Cortex XSIAM ingests the
network flow logs as Cortex XSIAM network connection stories, which you can query using XQL Search from the xdr_dataset dataset
with the preset called network_story. In addition, you can configure Cortex XSIAM to normalize GCP audit logs, which you can query
with XQL Search using the cloud_audit_logs dataset.

The Vendor is automatically set to Google and Product to Cloud Logging , which is not configurable. This means that all GCP data for
the flow and audit logs, whether it's normalized or not, can be queried in XQL Search using the google_cloud_logging_raw dataset.

Generic—When selecting this log type, you can configure the following settings.

Log Format—Select the log format type as Raw, JSON, CEF, LEEF, Cisco, or Corelight.

CEF or LEEF: The Vendor and Product defaults to Auto-Detect.

NOTE:

For a Log Format set to CEF or LEEF, Cortex XSIAM reads events row by row to look for the Vendor and Product configured in
the logs. When the values are populated in the event log row, Cortex XSIAM uses these values even if you specified a value in
the Vendor and Product fields in the GCP data collector settings. Yet, when the values are blank in the event log row, Cortex
XSIAM uses the Vendor and Product that you specified in the GCP data collector settings. If you did not specify a Vendor or
Product in the GCP data collector settings, and the values are blank in the event log row, the values for both fields are set to
unknown.

Cisco: The following fields are automatically set and not configurable.

Vendor—Cisco

Product—ASA

Cisco data can be queried in XQL Search using the cisco_asa_raw dataset.

Corelight: The following fields are automatically set and not configurable.

Vendor—Corelight

Product—Zeek

Corelight data can be queried in XQL Search using the corelight_zeek_raw dataset.

Raw or JSON: The following fields are automatically set and are configurable.

Vendor—Google

Product—Cloud Logging

Raw or JSON data can be queried in XQL Search using the google_cloud_logging_raw dataset.

Cortex XSIAM supports logs in single line format or multiline format. For a JSON format, multiline logs are collected automatically
when the Log Format is configured as JSON. When configuring a Raw format, you must also define the Multiline Parsing Regex
as explained below.

Vendor—(Optional) Specify a particular vendor name for the GCP generic data collection, which is used in the GCP XQL dataset
<Vendor>_<Product>_raw that Cortex XSIAM creates as soon as it begins receiving logs.

Product—(Optional) Specify a particular product name for the GCP generic data collection, which is used in the GCP XQL dataset
name <Vendor>_<Product>_raw that Cortex XSIAM creates as soon as it begins receiving logs.

Multiline Parsing Regex—(Optional) This option is only displayed when the Log Format is set to Raw, where you can set the regular
expression that identifies when the multiline event starts in logs with multilines. It is assumed that when a new event begins, the
previous one has ended.

Google Cloud DNS—When selecting this log type, you can configure whether to normalize the logs as part of the enhanced cloud protection.

Optional) You can Normalize DNS logs by selecting the checkbox (default). If selected, Cortex XSIAM ingests the Google Cloud DNS
logs as Cortex XSIAM network connection stories, which you can query using XQL Search from the xdr_dataset dataset with the
preset called network_story.

The Vendor is automatically set to Google and Product to DNS , which is not configurable. This means that all Google Cloud DNS logs,
whether it's normalized or not, can be queried in XQL Search using the google_dns_raw dataset.

f. Test the provided settings and, if successful, proceed to Enable log collection.

6. After Cortex XSIAM begins receiving information from the GCP Pub/Sub service, you can use the XQL Query language to search for specific data.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 659/1003
5/8/24, 9:18 AM PDF Export

Set up Log Forwarding Using the GCP Cloud Shell Terminal

1. Launch the GCP cloud shell terminal or use your preferred shell with gcloud installed.

2. Define your project ID.

gcloud config set project <PROJECT_ID>

3. Create a Pub/Sub topic.

gcloud pubsub topics create <TOPIC_NAME>

4. Create a subscription for this topic.

gcloud pubsub subscriptions create <SUBSCRIPTION_NAME> --topic=<TOPIC_NAME>

Note the subscription name you define in this step as you will need it to set up log ingestion from Cortex XSIAM.

5. Create a logging sink.

During the logging sink creation, you can also define additional log filters to exclude specific logs. To filter logs, supply the optional parameter --log-
filter=<LOG_FILTER>

gcloud logging sinks create <SINK_NAME> pubsub.googleapis.com/projects/<PROJECT_ID>/topics/<TOPIC_NAME> --log-filter=<LOG_FILTER>

If setup is successful, the console displays a summary of your log sink settings:

Created [https://logging.googleapis.com/v2/projects/PROJECT_ID/sinks/SINK_NAME]. Please remember to grant `serviceAccount:LOGS_SINK_SERVICE_ACCOUNT` \ the Pub/Sub

Publisher role on the topic. More information about sinks can be found at /logging/docs/export/configure_export

6. Grant log sink service account to publish to the new topic.

Note the serviceAccount name from the previous step and use it to define the service for which you want to grant publish access.

gcloud pubsub topics add-iam-policy-binding <TOPIC_NAME> --member serviceAccount:<LOGS_SINK_SERVICE_ACCOUNT> --role=roles/pubsub.publisher

7. Create a service account.

For example, use cortex-xdr-sa as the service account name and Cortex XSIAM Service Account as the display name.

gcloud iam service-accounts create <SERVICE_ACCOUNT> --description="<DESCRIPTION>" --display-name="<DISPLAY_NAME>"

8. Grant the IAM role to the service account.

gcloud pubsub subscriptions add-iam-policy-binding <SUBSCRIPTION_NAME> --member serviceAccount:<SERVICE_ACCOUNT>@<PROJECT_ID>.iam.gserviceaccount.com --

role=roles/pubsub.subscriber

9. Create a JSON key for the service account.

You will need the JSON file to enable Cortex XSIAM to authenticate with the GCP service. Specify the file destination and filename using a .json
extension.

gcloud iam service-accounts keys create <OUTPUT_FILE> --iam-account <SERVICE_ACCOUNT>@<PROJECT_ID>.iam.gserviceaccount.com

10. In Cortex XSIAM, set up Data Collection.

a. Select Settings → Configurations → Data Collection → Data Sources.

b. In the Google Cloud Platform configuration, click Add Instance.

c. Specify the Subscription Name that you previously noted or copied.

d. Browse to the JSON file containing your authentication key for the service account.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 660/1003
5/8/24, 9:18 AM PDF Export

e. Select the Log Type as one of the following, where your selection changes the options displayed.

Flow or Audit Logs—When selecting this log type, you can decide whether to normalize and enrich the logs as part of the enhanced cloud
protection.

(Optional) You can Normalize and enrich flow and audit logs by selecting the checkbox (default). If selected, Cortex XSIAM ingests the
network flow logs as Cortex XSIAM network connection stories, which you can query using XQL Search from the xdr_dataset dataset
with the preset called network_story. In addition, you can configure Cortex XSIAM to normalize GCP audit logs, which you can query
with XQL Search using the cloud_audit_logs dataset.

The Vendor is automatically set to Google and Product to Cloud Logging , which is not configurable. This means that all GCP data for
the flow and audit logs, whether it's normalized or not, can be queried in XQL Search using the google_cloud_logging_raw dataset.

Generic—When selecting this log type, you can configure the following settings.

Log Format—Select the log format type as Raw, JSON, CEF, LEEF, Cisco, or Corelight.

CEF or LEEF: The Vendor and Product defaults to Auto-Detect.

NOTE:

For a Log Format set to CEF or LEEF, Cortex XSIAM reads events row by row to look for the Vendor and Product configured in
the logs. When the values are populated in the event log row, Cortex XSIAM uses these values even if you specified a value in
the Vendor and Product fields in the GCP data collector settings. Yet, when the values are blank in the event log row, Cortex
XSIAM uses the Vendor and Product that you specified in the GCP data collector settings. If you did not specify a Vendor or
Product in the GCP data collector settings, and the values are blank in the event log row, the values for both fields are set to
unknown.

Cisco: The following fields are automatically set and not configurable.

Vendor—Cisco

Product—ASA

Cisco data can be queried in XQL Search using the cisco_asa_raw dataset.

Corelight: The following fields are automatically set and not configurable.

Vendor—Corelight

Product—Zeek

Corelight data can be queried in XQL Search using the corelight_zeek_raw dataset.

Raw or JSON: The following fields are automatically set and are configurable.

Vendor—Google

Product—Cloud Logging

Raw or JSON data can be queried in XQL Search using the google_cloud_logging_raw dataset.

Cortex XSIAM supports logs in single line format or multiline format. For a JSON format, multiline logs are collected automatically
when the Log Format is configured as JSON. When configuring a Raw format, you must also define the Multiline Parsing Regex
as explained below.

Vendor—(Optional) Specify a particular vendor name for the GCP generic data collection, which is used in the GCP XQL dataset
<Vendor>_<Product>_raw that Cortex XSIAM creates as soon as it begins receiving logs.

Product—(Optional) Specify a particular product name for the GCP generic data collection, which is used in the GCP XQL dataset
name <Vendor>_<Product>_raw that Cortex XSIAM creates as soon as it begins receiving logs.

Multiline Parsing Regex—(Optional) This option is only displayed when the Log Format is set to Raw, where you can set the regular
expression that identifies when the multiline event starts in logs with multilines. It is assumed that when a new event begins, the
previous one has ended.

Google Cloud DNS—When selecting this log type, you can configure whether to normalize the logs as part of the enhanced cloud protection.

Optional) You can Normalize DNS logs by selecting the checkbox (default). If selected, Cortex XSIAM ingests the Google Cloud DNS
logs as Cortex XSIAM network connection stories, which you can query using XQL Search from the xdr_dataset dataset with the
preset called network_story.

The Vendor is automatically set to Google and Product to DNS , which is not configurable. This means that all Google Cloud DNS logs,
whether it's normalized or not, can be queried in XQL Search using the google_dns_raw dataset.

f. Test the provided settings and, if successful, proceed to Enable log collection.

11. After Cortex XSIAM begins receiving information from the GCP Pub/Sub service, you can use the XQL Query language to search for specific data.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 661/1003
5/8/24, 9:18 AM PDF Export

8.4.4.4 | Ingest Logs and Data from Google Workspace

Abstract

Ingest logs and data from Google Workspace for use in Cortex XSIAM.

Cortex XSIAM can ingest the following types of data from Google Workspace, where most of the data is collected as audit events from various Google reports,
using the Google Workspace data collector.

Google Chrome

Admin Console

Google Chat

Enterprise Groups

Login

Rules

Google drive

Token

User Accounts

SAML

Alerts

Emails—Requires a compliance mailbox to ingest email data (not email reports).

All message details except email headers and email content (payload.body, payload.parts, and snippet).

Attachment details, when Get Attachment Info is selected, includes file name, size, and hash calculation.

The following Google APIs are required to collect the different types of data from Google Workspace.

For all data types, except emails—Admin SDK API.

For all data types, except alerts and emails—Admin Reports API (part of Admin SDK API).

NOTE:

For all types of data collected via the Admin Reports API, except alerts and emails, the log events are collected with a preset lag time as reported by
Google Workspace. For more information on these lag times for the different types of data, see Google Workspace Data retention and lag times.

Alerts require implementing an additional API—Alert Center API (part of Admin SDK API).

Emails require implementing the Gmail API.

To receive logs from Google Workspace for any of the data types except emails, you must first enable the Google Workspace Admin SDK API with a user with
access to the Admin SDK Reports API. For emails, you must set up a compliance email account as explained in the prerequisite step below and then enable the
Google Workspace Gmail API. Once implemented, you can then configure the Data Sources settings in Cortex XSIAM . After you set up data collection, Cortex
XSIAM begins receiving new logs and data from the source.

When Cortex XSIAM begins receiving logs, the app creates a new dataset for the different types of data that you are collecting, which you can use to initiate
XQL Search queries. For example queries, refer to the in-app XQL Library. For all logs, Cortex XSIAM can raise Cortex XSIAM alerts for Correlation Rules only,
when relevant from Google Workspace logs.

For the different types of data you can collect using the Google Workspace data collector, the following table lists the different datasets, vendors, and products
automatically configured, and whether the data is normalized.

Data Type Dataset Vendor Product Normalized Data

Google google_workspace_chrome_raw Google Workspace —

Chrome Chrome

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 662/1003
5/8/24, 9:18 AM PDF Export

Data Type Dataset Vendor Product Normalized Data

Admin google_workspace_admin_console_raw Google Workspace When relevant, Cortex XSIAM normalizes Admin Console
Console Admin audit logs into authentication stories. All SaaS audit logs are
Console collected in a dataset called saas_audit_logs and specific
relevant events are collected in the authentication_story
preset for the xdr_data dataset.

Google google_workspace_chat_raw Google Workspace —

Chat Chat

Enterprise google_workspace_enterprise_groups_raw Google Workspace When relevant, Cortex XSIAM normalizes Enterprise Group
Groups Enterprise audit logs into authentication stories. All SaaS audit logs are
Groups collected in a dataset called saas_audit_logs and specific
relevant events are collected in the authentication_story
preset for the xdr_data dataset.

Login google_workspace_login_raw Google Workspace When relevant, Cortex XSIAM normalizes Login audit logs
Login into authentication stories. All SaaS audit logs are collected
in a dataset called saas_audit_logs and specific relevant
events are collected in the authentication_story preset
for the xdr_data dataset.

Rules google_workspace_rules_raw Google Workspace When relevant, Cortex XSIAM normalizes Rules audit logs
Rules into authentication stories. All SaaS audit logs are collected
in a dataset called saas_audit_logs and specific relevant
events are collected in the authentication_story preset
for the xdr_data dataset.

Google google_workspace_drive_raw Google Workspace When relevant, Cortex XSIAM normalizes Google drive audit
drive Drive logs into authentication stories. All SaaS audit logs are
collected in a dataset called saas_audit_logs and specific
relevant events are collected in the authentication_story
preset for the xdr_data dataset.

Token google_workspace_token_raw Google Workspace When relevant, Cortex XSIAM normalizes Token audit logs
Token into authentication stories. All SaaS audit logs are collected
in a dataset called saas_audit_logs and specific relevant
events are collected in the authentication_story preset
for the xdr_data dataset.

User google_workspace_user_accounts_raw Google Workspace —

Accounts User
Accounts

SAML google_workspace_saml_raw Google Workspace When relevant, Cortex XSIAM normalizes SAML audit logs
SAML into authentication stories. All SaaS audit logs are collected
in a dataset called saas_audit_logs and specific relevant
events are collected in the authentication_story preset
for the xdr_data dataset.

Alerts google_workspace_alerts_raw Google Workspace —

Alerts

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 663/1003
5/8/24, 9:18 AM PDF Export

Data Type Dataset Vendor Product Normalized Data

Emails google_gmail_raw Google Gmail —

Prerequisite Steps

Be sure you do the following tasks before you begin configuring data collection from Google Workspace using the instructions detailed below.

When configuring data collection for all data types except emails, you need to complete the Google Workspace Reports API Prerequisites to set up the
Google Workspace Admin SDK environment. This entails completing the instructions for Set up the basics and Set up a Google API Console project
without activating the Reports API service as this will be explained in greater detail in the task below. For more information on these Google Workspace
prerequisite steps, see Reports API Prerequisites.

When you only want to collect Google Workspace alerts without configuring any other data types, you need to set up a Cloud Platform project.

Before you can collect Google emails, you need to set up the following.

1. A compliance email account.

2. The organization’s Google Workspace account administrator can now set up a BCC to this compliance email account for all incoming and outgoing
emails of any user in the organization.

a. Login to the Admin direct routing URL in Google Workspace for the user account that you want to configure.

b. Double-click Routing, and set the following parameters in the Add setting dialog.

Routing–Configure the compliance email account that you want to receive a BCC for emails from this user account using the format BCC
TO <compliance email>. For example, BCC TO [email protected].

Select Inbound and Outbound to ensure all incoming and outgoing emails are sent.

(Optional) To configure another email address to receive a BCC for emails from this account, select Add more recipients in the Also
deliver to section, and then click Add.

Click Show options, and from the list displayed select Account types to affect → Users.

Save your changes.

This configuration ensures to forward every message sent to a user account to a defined compliance mailbox. After the Google Workspace data collector
ingests the emails, they are deleted from the compliance mailbox to prevent email from building up over time (nothing touches the actual users’
mailboxes).

NOTE:

Spam emails from the compliance email account, and from all other monitored email accounts, are not collected.

Any draft emails written in the compliance email account are collected by the Google Workspace data collector, and are then deleted even if the
email was never sent.

To set up the Google Workspace integration:

1. Complete the applicable prerequisite steps for the types of data you want to collect from Google Workspace.

2. Log in to your GCP account.

3. Perform Google Workspace Domain-Wide Delegation of Authority when collecting any type of data from Google Workspace except Google Emails.

When collecting any type of data from Google Workspace except emails, you need to set up Google Workspace enterprise applications to access users’
data without any manual authorization. This is performed by following these steps.

NOTE:

For more information on the entire process, see Perform Google Workspace Domain-Wide Delegation of Authority.

a. Enable the Admin SDK API to create a service account and set credentials for this service account.

As you complete this step, you need to gather information related to your service account, including the Client ID, Private key file, and Email
address, which you will need to use later on in this task.

1. Select the Hamburger menu → APIs & Services → Library.

2. Search for the Admin SDK API, and select the API from the results list.

3. Enable the Admin SDK API.

4. Select APIs & Services → Credentials.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 664/1003
5/8/24, 9:18 AM PDF Export

5. Select + CREATE CREDENTIALS → Service account.

6. Set the following Service account details in the applicable fields.

Specify a service account name. This name is automatically used to populate the following field as the service account ID, where the
name is changed to lowercase letters and all spaces are changed to hyphens.

Specify the service account ID, where you can either leave the default service account ID or add a new one. This service account ID is
used to set the service account email using the following format: <id>@<project name>.iam.gserviceaccount.com.

(Optional) Specify a service account description.

7. CREATE AND CONTINUE.

8. (Optional) Decide whether you want to Grant this service account access to project or Grant users access to this service account.

9. Click Done.

10. Select your newly created Service Account from the list.

11. Create a service account private key and download the private key file as a JSON file.

In the Keys tab, select ADD KEY → Create new key, leave the default Key type set to JSON, and CREATE the private key. Once you’ve
downloaded the new private key pair to your machine, ensure that you store it in a secure location as it’s the only copy of this key. You will
need to browse to this JSON file when configuring the Google Workplace data collector in Cortex XSIAM .

b. When collecting alerts, enable the Alert Center API to create a service account and set credentials for this service account.

NOTE:

When collecting Google Workspace alerts with other types of data, except emails, you need to configure a service account in Google with the
applicable permissions to collect events from the Google Reports API and alerts from the Alert Center API. If you prefer to use different service
accounts to collect events and alerts separately, you'll need to create 2 service accounts with different instances of the Google Workspace data
collector. One instance to collect events with a certain service account, and another instance to collect alerts using another service account. The
instructions below explain how to set up one Google Workspace instance to collect both event and alerts.

1. Select the Hamburger menu → APIs & Services → Library.

2. Search for the Alert Center API, and select the API from the results list.

3. Enable the Alert Center API.

4. Select APIs & Services → Credentials.

5. Select the same service account in the Service Accounts section that you created for the Admin SDK API above.

c. Delegate domain-wide authority to your service account with the Admin Reports API and Alert Center API scopes.

1. Open the Google Admin Console.

2. Select Security → Access and data control → API controls.

3. Scroll down to the Domain wide delegation section, and select MANAGE DOMAIN WIDE DELEGATION.

4. Click Add new.

5. Set the following settings to define permissions for the Admin SDK API.

Client ID—Specify the service account’s Unique ID, which you can obtain from the Service accounts page by clicking the email of the
service account to view further details. When creating a single Google Workspace data collector instance to collect both events and
alert data, provide the same service account ID as the Admin SDK API.

In the OAuth scopes (comma-delimited) field, paste in the first of the two Admin Reports API scopes—
https://www.googleapis.com/auth/admin.reports.audit.readonly

In the following OAuth scopes (comma-delimited) field, paste in the second Admin Reports API scope—
https://www.googleapis.com/auth/admin.reports.usage.readonly

NOTE:

For more information on the Admin Reports API scopes, see OAuth 2.0 Scopes for Google APIs.

When collecting alerts, add the following Alert Center API scope—https://www.googleapis.com/auth/apps.alerts

6. Authorize the domain-wide authority to your service account.

This ensures that your service account now has domain-wide access to the Google Admin SDK Reports API and Google Workspace Alert
Center API, if configured, for all of the users of your domain.

4. Enable the Gmail API to collect Google emails.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 665/1003
5/8/24, 9:18 AM PDF Export

When you are configuring the Google Workspace data collector to collect Google emails, the instruction differ depending on whether you are configuring
the collection along with other types of data with the Admin SDK API already set up or you are configuring the collection to only include emails using only
the Gmail API. The steps below explain both scenarios.

a. Select the Hamburger menu → APIs & Services → Library.

b. Search for the Gmail API, and select the API from the results list.

c. Enable the Gmail API.

d. Select APIs & Services → Credentials.

The instructions for setting up credentials differ depending on whether you are setting up the Gmail API together with the Admin SDK API as you are
collecting other data types, or you are configuring collection for emails only with the Gmail API.

When you’ve already set up the Admin SDK API, verify that the same Service Account that you configured for the Admin SDK API is listed,
and continue on to the next step.

When you’re only collecting Google emails without the Admin SDK API, complete these steps.

1. Select + CREATE CREDENTIALS → Service account.

2. Set the following Service account details in the applicable fields.

-Specify a service account name. This name is automatically used to populate the following field as the service account ID, where the
name is changed to lowercase letters and all spaces are changed to hyphens.

-Specify the service account ID, where you can either leave the default service account ID or add a new one. This service account ID is
used to set the service account email using the following format: <id>@<project name>.iam.gserviceaccount.com.

-(Optional) Specify a service account description.

3. CREATE AND CONTINUE.

4. (Optional) Decide whether you want to Grant this service account access to project or Grant users access to this service account.

5. Click Done.

6. Select your newly created Service Account from the list.

7. Create a service account private key and download the private key file as a JSON file.

In the Keys tab, select ADD KEY → Create new key, leave the default Key type set to JSON, and CREATE the private key. Once you’ve
downloaded the new private key pair to your machine, ensure that you store it in a secure location as it’s the only copy of this key. You
will need to browse to this JSON file when configuring the Google Workplace data collector in Cortex XSIAM .

e. Delegate domain-wide authority to your service account with the Gmail API scopes.

1. Open the Google Admin Console.

2. Select Security → Access and data control → API controls.

3. Scroll down to the Domain wide delegation section, and select MANAGE DOMAIN WIDE DELEGATION.

This step explains how the following Gmail API scopes are added.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 666/1003
5/8/24, 9:18 AM PDF Export

https://mail.google.com/

https://www.googleapis.com/auth/gmail.addons.current.action.compose

https://www.googleapis.com/auth/gmail.addons.current.message.action

https://www.googleapis.com/auth/gmail.addons.current.message.metadata

https://www.googleapis.com/auth/gmail.addons.current.message.readonly

https://www.googleapis.com/auth/gmail.compose

https://www.googleapis.com/auth/gmail.insert

https://www.googleapis.com/auth/gmail.labels

https://www.googleapis.com/auth/gmail.metadata

https://www.googleapis.com/auth/gmail.modify

https://www.googleapis.com/auth/gmail.readonly

https://www.googleapis.com/auth/gmail.send

https://www.googleapis.com/auth/gmail.settings.basic

https://www.googleapis.com/auth/gmail.settings.sharing

NOTE:

For more information on the Gmail API scopes, see OAuth 2.0 Scopes for Google APIs.

The instructions differ depending on whether you are setting up the Gmail API together with the Admin SDK API as you are collecting other
data types, or you are configuring collection for emails only with the Gmail API.

When you’ve already set up the Admin SDK API, Edit the same Service Account that you configured for the Admin SDK API, and add
the Gmail API scopes listed above.

When you’re only collecting Google emails without the Admin SDK API, click Add New, and set the following settings to define
permissions for the Admin SDK API.

-Client ID—Specify the service account’s Unique ID, which you can obtain from the Service accounts page by clicking the email of the
service account to view further details.

In the OAuth scopes (comma-delimited) field, paste in the first of the Gmail API scopes listed above, and continue adding in the rest of
the scopes.

Authorize the domain-wide authority to your service account.

This ensures that your service account now has domain-wide access to the Google Gmail API for all of the users of your domain.

5. Prepare your service account to impersonate a user with access to the Admin SDK Reports API when collecting any type of data from Google Workspace
except Google emails.

Only users with access to the Admin APIs can access the Admin SDK Reports API. Therefore, your service account needs to be set up to impersonate
one of these users to access the Admin SDK Reports API. This means that when collecting any type of data from Google Workspace except Google
emails, you need to designate a user whose Roles permissions are set to access reports, where Security → Reports is selected. This user’s email will be
required when configuring the Google Workspace data collector in Cortex XSIAM .

a. In the Google Admin Console, select Directory → Users.

b. From the list of users listed, select the user configured with the necessary permissions in Admin roles and privileges to view reports, such as a
Super Admin, that you want to set up your service account to impersonate.

c. Record the email of this user as you will need it in Cortex XSIAM .

6. In Cortex XSIAM, select Settings → Configurations → Data Collection → Data Sources.

7. In the Google Workspace configuration, click Add Instance to begin a new configuration.

8. Integrate the applicable Google Workspace service with Cortex XSIAM .

a. Specify a descriptive Name for your log collection integration.

b. Browse to the JSON file containing your service account key Credentials for the Google Workspace Admin SDK API that you enabled. If you’re only
collecting Google emails, ensure that you Browse to the JSON file containing your service account private key Credentials for the Gmail API that
you enabled.

c. Select the types of data that you want to Collect from Google Workspace.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 667/1003
5/8/24, 9:18 AM PDF Export

Google Chrome—Chrome browser and Chrome OS events included in the Chrome activity reports.

Admin Console—Account information about different types of administrator activity events included in the Admin console application's activity
reports.

Google Chat—Chat activity events included in the Chat activity reports.

Enterprise Groups —Enterprise group activity events included in the Enterprise Groups activity reports.

Login—Account information about different types of login activity events included in the Login application's activity reports.

Rules—Rules activity events included in the Rules activity report.

Google drive—Google Drive activity events included in the Google Drive application's activity reports.

Token—Token activity events included in the Token application's activity reports.

User Accounts—Account information about different types of User Accounts activity events included in the User Accounts application's activity
reports.

SAML—SAML activity events included in the SAML activity report.

Alerts—Alerts from the Alert Center API beta version, which is still subject to change.

Emails—Collects email data (not emails reports). All message details except email headers and email content (payload.body,
payload.parts, and snippet).

NOTE:

For more information about the events collected from the various Google Reports, see Google Workspace Reports API Documentation.

For all options selected, except Emails, you must specify the Service Account Email. This is the email account of the user with access to the Admin
SDK Reports API that you prepared your service account to impersonate.

When selecting Emails, configure the following.

Audit Email Account—Specify the email address for the compliance mailbox that you set up.

Get Attachment Info from the ingested email, which includes file name, size, and hash calculation.

d. Test the connection settings.

To test the connection, you must select one or more log types. Cortex XSIAM then tests the connection settings for the selected log types.

e. If successful, Enable Google Workspace log collection.

8.4.4.5 | Ingest Logs from Microsoft Office 365

Topic Not Found

8.4.4.6 | Ingest Logs and Data from Okta

Abstract

Ingest authentication logs and data from Okta for use in Cortex XSIAM authentication stories.

To receive logs and data from Okta, you must configure the Data Sources settings in Cortex XSIAM. After you set up data collection, Cortex XSIAM immediately
begins receiving new logs and data from the source. The information from Okta is then searchable in XQL Search using the okta_sso_raw dataset. In addition,
depending on the event type, data is normalized to either xdr_data or saas_audit_logs datasets.

You can collect all types of events from Okta. When setting up the Okta data collector in Cortex XSIAM , a field called Okta Filter is available to configure
collection for events of your choosing. All events are collected by default unless you define an Okta API Filter expression for collecting the data, such as
filter=eventType eq “user.session.start”.\n. For Okta information to be weaved into authentication stories, “user.authentication.sso” events
must be collected.

Since the Okta API enforces concurrent rate limits, the Okta data collector is built with a mechanism to reduce the amount of requests whenever an error is
received from the Okta API indicating that too many requests have already been sent. In addition, to ensure you are properly notified about this, an alert is
displayed in the Notification Area and a record is added to the Management Audit Logs.

Before you begin configuring data collection from Okta, ensure your Okta user has administrator privileges with a role that can create API tokens, such as the
read-only administrator, Super administrator, and Organization administrator. For more information, see the Okta Administrators Documentation.

To configure the Okta collection in Cortex XSIAM:

1. Identify the domain name of your Okta service.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 668/1003
5/8/24, 9:18 AM PDF Export

From the Dashboard of your Okta console, note your Org URL.

For more information, see the Okta Documentation.

2. Obtain your authentication token in Okta.

a. Select API → Tokens.

b. Create Token and record the token value.

This is your only opportunity to record the value.

3. Select Settings → Configurations → Data Collection → Data Sources.

4. Integrate the Okta authentication service with Cortex XSIAM .

a. Specify the OKTA DOMAIN (Org URL) that you identified on your Okta console.

b. Specify the TOKEN used to authenticate with Okta.

c. Specify the Okta Filter to configure collection for events of your choosing. All events are collected by default unless you define an Okta API Filter
expression for collecting the data, such as filter=eventType eq “user.session.start”.\n. For Okta information to be weaved into
authentication stories, “user.authentication.sso” events must be collected.

d. Test the connection settings.

e. If successful, Enable Okta log collection.

Once events start to come in, a green check mark appears underneath the Okta configuration with the amount of data received.

5. After Cortex XSIAM begins receiving information from the service, you can Create an XQL Query to search for specific data. When including
authentication events, you can also Create an Authentication Query to search for specific authentication data.

8.4.4.7 | Ingest Logs and Data from OneLogin

Abstract

Learn how to ingest different types of logs and data from OneLogin.

Cortex XSIAM can ingest different types of data from OneLogin accounts using the OneLogin data collector.

To receive logs and data from OneLogin via the OneLogin REST APIs, you must configure the Data Sources settings in Cortex XSIAM based on your OneLogin
credentials. After you set up data collection, Cortex XSIAM begins receiving new logs and data from the source.

When Cortex XSIAM begins receiving logs, the app creates a new dataset for the different types of data collected and normalizes the ingested data into
authentication stories, where specific relevant events are collected in the authentication_story preset for the xdr_data dataset. You can search these
datasets using XQL Search queries. For all logs, Cortex XSIAM can raise Cortex XSIAM alerts (Analytics, Correlation Rules, IOC, and BIOC), when relevant
from OneLogin logs. While Correlation Rules alerts are raised on non-normalized and normalized logs, Analytics, IOC, and BIOC alerts are only raised on
normalized logs.

The following table provides a description of the different types of data you can collect, the collection method and fetch interval for the data collected, and the
name of the dataset to use in Cortex Query Language (XQL) queries.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 669/1003
5/8/24, 9:18 AM PDF Export

Data Type Description Collection Method Fetch Interval Dataset Name

Log Collection

Events User logins, administrative Appends data 30 seconds onelogin_events_raw

operations, provisioning,
and a list of all OneLogin
event types

Directory

Users Lists of users Overwrites data 10 minutes onelogin_users_raw

Groups Lists of groups Overwrites data 10 minutes onelogin_groups_raw

Apps Lists of apps Overwrites data 10 minutes onelogin_apps_raw

Before you configure Cortex XSIAM data collection from OneLogin, make sure you have the following.

An Advanced OneLogin account.

Owner or administrator permissions in your OneLogin account which enable Cortex XSIAM to access the OneLogin account and generate the OAuth 2.0
access token.

A Cortex XSIAM user account with permissions to Read Log Collections, for example an Instance Administrator.

Configure Cortex XSIAM to receive logs and data from OneLogin.

1. Log in to OneLogin as an account owner or administrator.

2. Under Administration → Developers → API Credentials, Create a New Credential with scope Read All.

3. In the credential details page, copy the Client ID and the Client Secret, and save them somewhere safe. You will need to provide these keys when you
configure the OneLogin data collector in Cortex XSIAM .

4. Select Settings → Data Sources.

5. In the OneLogin configuration, click Add Instance to generate a new configuration.

6. Configure the following parameters.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 670/1003
5/8/24, 9:18 AM PDF Export

Domain—Specify the domain of the OneLogin instance. The domain name must be in the format https://<subdomain-name>.onelogin.com.

Name—Specify a descriptive and unique name for the configuration.

Client ID—Specify the Client ID for the OneLogin API credential pair.

Secret—Specify the Client Secret for the OneLogin API credential pair.

Collect—Select the types of data to collect. By default, all the options are selected.

Log Collection

Events—Retrieves user logins, administrative operations, provisioning, and OneLogin event types. After normalization, the event types
are enriched with the event name and description.

NOTE:

Event data is collected every 30 seconds.

Directory

Users—Retrieves lists of users.

Groups—Retrieves lists of groups.

Apps—Retrieves lists of apps.

NOTE:

Inventory data snapshots are collected every 10 minutes.

7. Test the connection settings. If successful, Enable the OneLogin log collection.

When events start to come in, a green check mark appears underneath the OneLogin configuration.

8.4.4.8 | Ingest Authentication Logs from PingFederate

Abstract

Ingest authentication logs and data from PingFederate for use in Cortex XSIAM authentication stories.

To receive authentication logs from PingFederate, you must first write Audit and Provisioner Audit Logs to CEF in PingFederate and then set up a Syslog
Collector in Cortex XSIAM to receive the logs. After you set up log collection, Cortex XSIAM immediately begins receiving new authentication logs from the
source. Cortex XSIAM creates a dataset named ping_identity_pingfederate_raw. Logs from PingFederate are searchable in Cortex Query Language
(XQL) queries using the dataset and surfaced, when relevant, in authentication stories.

1. Activate the Syslog Collector.

2. Set up PingFederate to write logs in CEF.

To set up the integration, you must have an account for the PingFederate management dashboard and access to create a subscription for SSO logs.

In your PingFederate deployment, write audit logs in CEF. During this set up you will need the IP address and port you configured in the Syslog Collector.

3. To search for specific authentication logs or data, you can Create an Authentication Query or use the XQL Search.

8.4.4.9 | Ingest Authentication Logs and Data from PingOne

Abstract

Ingest authentication logs and data from PingOne for Enterprise for use in Cortex XSIAM authentication stories.

To receive authentication logs and data from PingOne for Enterprise, you must first set up a Poll subscription in PingOne and then configure the Collection
Integrations settings in Cortex XSIAM. After you set up collection integration, Cortex XSIAM immediately begins receiving new authentication logs and data from
the source. These logs and data are then searchable in Cortex XSIAM.

1. Set up PingOne for Enterprise to send logs and data.

To set up the integration, you must have an account for the PingOne management dashboard and access to create a subscription for SSO logs.

From the PingOne Dashboard:

a. Set up a Poll subscription.

1. Select Reporting → Subscriptions → Add Subscription.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 671/1003
5/8/24, 9:18 AM PDF Export

2. Enter a NAME for the subscription.

3. Select Poll as the subscription type.

4. Leave the remaining defaults and select Done.

b. Identify your account ID and subscription ID.

1. Select the subscription you just set up and note the part of the poll URL between /reports/ and /poll-subscriptions. This is your PingOne
account ID.

For example:

https://admin-api.pingone.com/v3/reports/1234567890asdfghjk-123456-zxcvbn/poll-subscriptions/***-0912348765-4567-
98012***/events

In this URL, the account ID is 1234567890asdfghjk-123456-zxcvbn.

2. Next, note the part of the poll URL between /poll-subscriptions/ and /events. This is your subscription ID.

In the example above, the subscription ID is ***-0912348765-4567-98012***.

2. Select Settings → Configurations → Data Collection → Data Sources.

3. Connect Cortex XSIAM to your PingOne for Enterprise authentication service.

a. Enter your PingOne ACCOUNT ID.

b. Enter your PingOne SUBSCRIPTION ID.

c. Enter your PingOne USER NAME.

d. Enter your PingOne PASSWORD.

e. Test the connection settings.

f. If successful, Enable PingOne authentication log collection.

After configuration is complete, Cortex XSIAM begins receiving information from the authentication service. From the Integrations page, you can view the
log collection summary.

4. To search for specific authentication logs or data, you can Create an Authentication Query or Create an XQL Query.

8.4.5 | Ingest Operation and System Logs from Cloud Providers

Abstract

Learn how to ingest operation and system logs from supported cloud providers in Cortex XSIAM.

You can ingest operation and system logs from supported cloud providers in Cortex XSIAM.

8.4.5.1 | Ingest Generic Logs from Amazon S3

Abstract

Take advantage of Cortex XSIAM investigation capabilities and set up generic log ingestion for your Amazon S3 logs.

You can forward generic logs for the relative service to Cortex XSIAM from Amazon S3.

To receive generic data from Amazon Simple Storage Service (Amazon S3), you must first configure data collection from Amazon S3. You can then configure
the Data Sources settings in Cortex XSIAM for Amazon S3. After you set up collection integration, Cortex XSIAM begins receiving new logs and data from the
source.

NOTE:

For more information on configuring data collection from Amazon S3, see the Amazon S3 Documentation.

As soon as Cortex XSIAM begins receiving logs, the app automatically creates an Amazon S3 Cortex Query Language (XQL) dataset
(<Vendor>_<Product>_raw). This enables you to search the logs using XQL Search with the dataset. For example queries, refer to the in-app XQL Library.
Cortex XSIAM can also raise Cortex XSIAM alerts (Correlation Rules only) when relevant from Amazon S3 logs.

NOTE:

You need to set up an Amazon S3 data collector to receive generic logs when collecting logs from BeyondTrust Privilege Management Cloud. For more
information, see Ingest Logs from BeyondTrust Privilege Management Cloud.

Be sure you do the following tasks before you begin configuring data collection from Amazon S3.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 672/1003
5/8/24, 9:18 AM PDF Export

Create a dedicated Amazon S3 bucket, which collects the generic logs that you want capture. For more information, see Creating a bucket using the
Amazon S3 Console.

NOTE:

It is the customer’s responsibility to define a retention policy for your Amazon S3 bucket by creating a Lifecycle rule in the Management tab. We
recommend setting the retention policy to at least 7 days to ensure that the data is retrieved under all circumstances.

The logs collected by your dedicated Amazon S3 bucket must adhere to the following guidelines.

Each log file must use the 1 log per line format as multi-line format is not supported.

The log format must be compressed as gzip or uncompressed.

For best performance, we recommend limiting each file size to up to 50 MB (compressed).

Ensure that you have at a minimum the following permissions in AWS for an Amazon S3 bucket and Amazon Simple Queue Service (SQS).

Amazon S3 bucket—GetObject

SQS—ChangeMessageVisibility, ReceiveMessage, and DeleteMessage.

Determine how you want to provide access to Cortex XSIAM to your logs and perform API operations. You have the following options:

Designate an AWS IAM user, where you will need to know the Account ID for the user and have the relevant permissions to create an access key/id
for the relevant IAM user.

Create an assumed role in AWS to delegate permissions to a Cortex XSIAM AWS service. This role grants Cortex XSIAM access to your flow logs.
For more information, see Creating a role to delegate permissions to an AWS service. This is the Assumed Role option described in the configure
the Amazon S3 collection in Cortex XSIAM. For more information on creating an assumed role for Cortex XSIAM, see Create an Assumed Role.

To collect Amazon S3 logs that use server-side encryption (SSE), the user role must have an IAM policy that states that Cortex XSIAM has kms:Decrypt
permissions. With this permission, Amazon S3 automatically detects if a bucket is encrypted and decrypts it. If you want to collect encrypted logs from
different accounts, you must have the decrypt permissions for the user role also in the key policy for the master account Key Management Service (KMS).
For more information, see Allowing users in other accounts to use a KMS key.

Configure Cortex XSIAM to receive generic logs from Amazon S3.

1. Log in to the AWS Management Console.

2. From the menu bar, ensure that you have selected the correct region for your configuration.

3. Configure an Amazon Simple Queue Service (SQS).

NOTE:

Ensure that you create your Amazon S3 bucket and Amazon SQS queue in the same region.

a. In the Amazon SQS Console, click Create Queue.

b. Configure the following settings, where the default settings should be configured unless otherwise indicated.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 673/1003
5/8/24, 9:18 AM PDF Export

Type—Select Standard queue (default).

Name—Specify a descriptive name for your SQS queue.

Configuration section—Leave the default settings for the various fields.

Access policy → Choose method—Select Advanced and update the Access policy code in the editor window to enable your Amazon S3
bucket to publish event notification messages to your SQS queue. Use this sample code as a guide for defining the “Statement” with the
following definitions.

-“Resource”—Leave the automatically generated ARN for the SQS queue that is set in the code, which uses the format
“arn:sns:Region:account-id:topic-name”.

You can retrieve your bucket’s ARN by opening the Amazon S3 Console in a browser window. In the Buckets section, select the bucket that
you created for collecting the Amazon S3 flow logs, click Copy ARN, and paste the ARN in the field.

NOTE:

For more information on granting permissions to publish messages to an SQS queue, see Granting permissions to publish event
notification messages to a destination.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "s3.amazonaws.com"
},
"Action": "SQS:SendMessage",
"Resource": "[Leave automatically generated ARN for the SQS queue defined by AWS]",
"Condition": {
"ArnLike": {
"aws:SourceArn": "[ARN of your Amazon S3 bucket]"
}
}
}
]
}

Dead-letter queue section—We recommend that you configure a queue for sending undeliverable messages by selecting Enabled, and then
in the Choose queue field selecting the queue to send the messages. You may need to create a new queue for this, if you do not already have
one set up. For more information, see Amazon SQS dead-letter queues.

c. Click Create queue.

Once the SQS is created, a message indicating that the queue was successfully configured is displayed at the top of the page.

4. Configure an event notification to your Amazon SQS whenever a file is written to your Amazon S3 bucket.

a. Open the Amazon S3 Console and in the Properties tab of your Amazon S3 bucket, scroll down to the Event notifications section, and click Create
event notification.

b. Configure the following settings:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 674/1003
5/8/24, 9:18 AM PDF Export

Event name—Specify a descriptive name for your event notification containing up to 255 characters.

Prefix—Do not set a prefix as the Amazon S3 bucket is meant to be a dedicated bucket for collecting only network flow logs.

Event types—Select All object create events for the type of event notifications that you want to receive.

Destination—Select SQS queue to send notifications to an SQS queue to be read by a server.

Specify SQS queue—You can either select Choose from your SQS queues and then select the SQS queue, or select Enter SQS queue ARN
and specify the ARN in the SQS queue field.

You can retrieve your SQS queue ARN by opening another instance of the AWS Management Console in a browser window, and opening the
Amazon SQS Console, and selecting the Amazon SQS that you created. In the Details section, under ARN, click the copy icon ( )), and
paste the ARN in the field.

c. Click Save changes.

Once the event notification is created, a message indicating that the event notification was successfully created is displayed at the top of the page.

NOTE:

If your receive an error when trying to save your changes, you should ensure that the permissions are set up correctly.

5. Configure access keys for the AWS IAM user.

NOTE:

It is the responsibility of your organization to ensure that the user who performs this task of creating the access key is assigned the relevant
permissions. Otherwise, this can cause the process to fail with errors.

Skip this step if you are using an Assumed Role for Cortex XSIAM.

a. Open the AWS IAM Console, and in the navigation pane, select Access management → Users.

b. Select the User name of the AWS IAM user.

c. Select the Security credentials tab, and scroll down to the Access keys section, and click Create access key.

d. Click the copy icon () next to the Access key ID and Secret access key keys, where you must click Show secret access key to see the secret key,
and record them somewhere safe before closing the window. You will need to provide these keys when you edit the Access policy of the SQS queue
and when setting the AWS Client ID and AWS Client Secret in Cortex XSIAM. If you forget to record the keys and close the window, you will need to
generate new keys and repeat this process.

NOTE:

For more information, see Managing access keys for IAM users.

6. Update the Access policy of your Amazon SQS queue.

NOTE:

Skip this step if you are using an Assumed Role for Cortex XSIAM.

a. In the Amazon SQS Console, select the SQS queue that you created when you configured an Amazon Simple Queue Service (SQS).

b. Select the Access policy tab, and Edit the Access policy code in the editor window to enable the IAM user to perform operations on the Amazon
SQS with permissions to SQS:ChangeMessageVisibility, SQS:DeleteMessage, and SQS:ReceiveMessage. Use this sample code as a guide for
defining the “Sid”: “__receiver_statement” with the following definitions.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 675/1003
5/8/24, 9:18 AM PDF Export

“aws:SourceArn”—Specify the ARN of the AWS IAM user. You can retrieve the User ARN from the Security credentials tab, which you
accessed when you configured access keys for the AWS API user.

“Resource”—Leave the automatically generated ARN for the SQS queue that is set in the code, which uses the format
“arn:sns:Region:account-id:topic-name”.

NOTE:

For more information on granting permissions to publish messages to an SQS queue, see Granting permissions to publish event
notification messages to a destination.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "s3.amazonaws.com"
},
"Action": "SQS:SendMessage",
"Resource": "[Leave automatically generated ARN for the SQS queue defined by AWS]",
"Condition": {
"ArnLike": {
"aws:SourceArn": "[ARN of your Amazon S3 bucket]"
}
}
},
{
"Sid": "__receiver_statement",
"Effect": "Allow",
"Principal": {
"AWS": "[Add the ARN for the AWS IAM user]"
},
"Action": [
"SQS:ChangeMessageVisibility",
"SQS:DeleteMessage",
"SQS:ReceiveMessage"
],
"Resource": "[Leave automatically generated ARN for the SQS queue defined by AWS]"
}
]
}

7. Configure the Amazon S3 collection in Cortex XSIAM .

a. Select Settings → Data Sources.

b. In the Amazon S3 configuration, click Add Instance to begin a new configuration.

c. Set these parameters, where the parameters change depending on whether you configured an Access Key or Assumed Role.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 676/1003
5/8/24, 9:18 AM PDF Export

To provide access to Cortex XSIAM to your logs and perform API operations using a designated AWS IAM user, leave the Access Key option
selected. Otherwise, select Assumed Role, and ensure that you create an Assumed Role for Cortex XSIAM before continuing with these
instructions. In addition, when you create an Assumed Role for Cortex XSIAM, ensure that you edit the policy that defines the permissions for
the role with the Amazon S3 Bucket ARN and SQS ARN.

SQS URL—Specify the SQS URL, which is the ARN of the Amazon SQS that you configured in the AWS Management Console.

Name—Specify a descriptive name for your log collection configuration.

When setting an Access Key, set these parameters.

AWS Client ID—Specify the Access key ID, which you received when you configured access keys for the AWS IAM user in AWS.

AWS Client Secret—Specify the Secret access key you received when you configured access keys for the AWS IAM user in AWS.

When setting an Assumed Role, set these parameters.

Role ARN—Specify the Role ARN for the Assumed Role you created for Cortex XSIAM in AWS.

External Id—Specify the External Id for the Assumed Role you created for Cortex XSIAM in AWS.

Log Type—Select Generic to configure your log collection to receive generic logs from Amazon S3, which can include different types of data,
such as file and metadata. When selecting this option, the following additional fields are displayed.

Log Format—Select the log format type as Raw, JSON, CEF, LEEF, Cisco, Corelight, or Beyondtrust Cloud ECS.

NOTE:

-The Vendor and Product defaults to Auto-Detect when the Log Format is set to CEF or LEEF.

-For a Log Format set to CEF or LEEF, Cortex XSIAM reads events row by row to look for the Vendor and Product configured in the
logs. When the values are populated in the event log row, Cortex XSIAM uses these values even if you specified a value in the
Vendor and Product fields in the Amazon S3 data collector settings. Yet, when the values are blank in the event log row, Cortex
XSIAM uses the Vendor and Product that you specified in these fields in the Amazon S3 data collector settings. If you did not specify
a Vendor or Product in the Amazon S3 data collector settings, and the values are blank in the event log row, the values for both fields
are set to unknown.

For a Log Format set to Beyondtrust Cloud ECS, the following fields are automatically set and not configurable.

-Vendor—Beyondtrust

-Product—Privilege Management

-Compression—Uncompressed

For more information, see Ingest Logs from BeyondTrust Privilege Management Cloud.

For a Log Format set to Cisco, the following fields are automatically set and not configurable.

-Vendor—Cisco

-Product—ASA

For a Log Format set to Corelight, the following fields are automatically set and not configurable.

-Vendor—Corelight

-Product—Zeek

For a Log Format set to Raw or JSON, the following fields are automatically set and are configurable.

-Vendor—AMAZON

-Product—AWS

Cortex XSIAM supports logs in single line format or multiline format. For a JSON format, multiline logs are collected automatically when
the Log Format is configured as JSON. When configuring a Raw format, you must also define the Multiline Parsing Regex as explained
below.

Vendor—(Optional) Specify a particular vendor name for the Amazon S3 generic data collection, which is used in the Amazon S3 XQL
dataset <Vendor>_<Product>_raw that Cortex XSIAM creates as soon as it begins receiving logs.

Product—(Optional) Specify a particular product name for the Amazon S3 generic data collection, which is used in the Amazon S3 XQL
dataset name <Vendor>_<Product>_raw that Cortex XSIAM creates as soon as it begins receiving logs.

Compression—Select whether the logs are compressed into a gzip file or are uncompressed.

Multiline Parsing Regex—(Optional) This option is only displayed when the Log Format is set to Raw, where you can set the regular
expression that identifies when the multiline event starts in logs with multilines. It is assumed that when a new event begins, the
previous one has ended.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 677/1003
5/8/24, 9:18 AM PDF Export

d. Click Test to validate access, and then click Enable.

Once events start to come in, a green check mark appears underneath the Amazon S3 configuration with the number of logs received.

8.4.5.2 | Ingest Logs from Amazon CloudWatch

Abstract

Take advantage of Cortex XSIAM investigation capabilities and set up generic or EKS log ingestion for your Amazon CloudWatch logs.

You can forward generic and Elastic Kubernetes Service (EKS) logs to Cortex XSIAM from Amazon CloudWatch. When forwarding EKS logs, the following log
types are included:

API Server—Logs pertaining to API requests to the cluster.

Audit—Logs pertaining to cluster access via the Kubernetes API.

Authenticator—Logs pertaining to authentication requests into the cluster.

Scheduler—Logs pertaining to scheduling decisions.

Controller Manager—Logs pertaining to the state of cluster controllers.

You can ingest generic logs of the raw data or in a JSON format from Amazon Kinesis Firehose. EKS logs are automatically ingested in a JSON format from
Amazon Kinesis Firehose. To enable log forwarding, you set up Amazon Kinesis Firehose and then add that to your Amazon CloudWatch configuration. After
you complete the set up process, logs from the respective service are then searchable in Cortex XSIAM to provide additional information and context to your
investigations.

As soon as Cortex XSIAM begins receiving logs, the application automatically creates one of the following Cortex Query Language (XQL) datasets depending
on the type of logs you've configured:

Generic: <Vendor>_<Product>_raw

EKS: amazon_eks_raw

These datasets enable you to search the logs in XQL Search. For example, queries refer to the in-app XQL Library. For enhanced cloud protection, you can also
configure Cortex XSIAM to normalize EKS audit logs, which you can query with XQL Search using the cloud_audit_logs dataset. Cortex XSIAM can also
raise Cortex XSIAM alerts (Analytics, IOC, BIOC, and Correlation Rules) when relevant from AWS logs. While Correlation Rules alerts are raised on non-
normalized and normalized logs, Analytics, IOC, and BIOC alerts are only raised on normalized logs.

Enhanced cloud protection provides the following:

Normalization of cloud logs

Cloud logs stitching

Enrichment with cloud data

Detection based on cloud analytics

Cloud-tailored investigations

To set up Amazon CloudWatch integration, you require certain permissions in AWS. You need a role that enables access to configuring Amazon Kinesis
Firehose.

1. Set up the Amazon CloudWatch integration in Cortex XSIAM.

a. Select Settings → Configurations → Data Collection → Data Sources.

b. In the Amazon CloudWatch configuration, click Add Instance to begin a new configuration.

c. Specify a descriptive Name for your log collection configuration.

d. Select the Log Type as one of the following, where your selection changes the options displayed.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 678/1003
5/8/24, 9:18 AM PDF Export

Generic—When selecting this log type, you can configure the following settings:

Log Format—Choose the format of the data input source (CloudWatch) that you'll export to Cortex XSIAM , either JSON or Raw.

Specify the Vendor and Product for the type of generic logs you are ingesting.

The vendor and product are used to define the name of your XQL dataset (<Vendor>_<Product>_raw). If you do not define a vendor or
product, Cortex XSIAM uses the default values of Amazon and AWS with the resulting dataset name as amazon_aws_raw. To uniquely
identify the log source, consider changing the values.

EKS—When selecting this log type, the following options are displayed:

The Vendor is automatically set to Amazon and Product to EKS , and is non-configurable. This means that all data for the EKS logs,
whether it's normalized or not, can be queried in XQL Search using the amazon_eks_raw dataset.

(Optional) You can decide whether to Normalize and enrich audit logs as part of the enhanced cloud protection by selecting the
checkbox (default). If selected, Cortex XSIAM is configured to normalize EKS audit logs, which you can query with XQL Search using
the cloud_audit_logs dataset.

e. Save & Generate Token.

Click the copy icon next to the key and record it somewhere safe. You will need to provide this key when you set up output settings in AWS Kinesis
Firehose. If you forget to record the key and close the window you will need to generate a new key and repeat this process.

f. Select Done to close the window.

2. Create a Kinesis Data Firehose delivery stream to your chosen destination.

a. Log in to the AWS Management Console, and open the Kinesis console.

b. Select Data Firehose → Create delivery stream.

c. Define the name and source for your stream.

Delivery stream name—Enter a descriptive name for your stream configuration.

Source—Select Direct PUT or other sources.

Server-side encryption for source records in the delivery stream—Ensure this option is disabled.

Click Next to proceed to the process record configuration.

d. Define the process records.

Transform source records with AWS Lambda—Set the Data Transformation as Disabled.

Convert record format—Set Record format conversion as Disabled.

Click Next to proceed to the destination configuration.

e. Choose a destination for the logs.

Choose HTTP Endpoint as the destination and configure the HTTP endpoint configuration settings:

HTTP endpoint name—Specify the name you used to identify your AWS log collection configuration in Cortex XSIAM.

HTTP endpoint URL—Copy the API URL associated with your log collection from the Cortex XSIAM management console. The URL will
include your tenant name (https://api-<tenant external URL>/logs/v1/aws).

Access key—Paste in the token key you recorded earlier during the configuration of your Cortex XSIAM log collection settings.

Content encoding—Select GZIP. Disabling content encoding may result in high egress costs.

Retry duration—Enter 300 seconds.

S3 bucket—Set the S3 backup mode as Failed data only. For the S3 bucket, we recommend that you create a dedicated bucket for Cortex
XSIAM integration.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 679/1003
5/8/24, 9:18 AM PDF Export

Click Next to proceed to the settings configuration.

f. Configure additional settings.

HTTP endpoint buffer conditions—Set the Buffer size as 1 MiB and the Buffer interval as 60 seconds.

S3 buffer conditions—Use the default settings for Buffer size as 5 MiB and Buffer interval as 300 seconds unless you have alternative sizing
preferences.

S3 compression and encryption—Choose your desired compression and encryption settings.

Error logging—Select Enabled.

Permissions—Create or update IAM role option.

Select Next.

g. Review your configuration and Create delivery stream.

When your delivery stream is ready, the status changes from Creating to Active.

3. To begin forwarding logs, add the Kinesis Firehose instance to your Amazon CloudWatch configuration.

To do this, add a subscription filter for Amazon Kinesis Firehose.

4. Verify the status of the integration.

Return to the Integrations page and view the statistics for the log collection configuration.

5. After Cortex XSIAM begins receiving logs from your Amazon services, you can use the XQL Search to search for logs in the new dataset.

8.4.5.3 | Ingest Logs and Data from a GCP Pub/Sub

Abstract

If you use the Pub/Sub messaging service from Global Cloud Platform (GCP), you can send logs and data from GCP to Cortex XSIAM.

If you use the Pub/Sub messaging service from Global Cloud Platform (GCP), you can send logs and data from your GCP instance to Cortex XSIAM. Data from
GCP is then searchable in Cortex XSIAM to provide additional information and context to your investigations using the GCP Cortex Query Language (XQL)
dataset, which is dependent on the type of GCP logs collected. For example queries, refer to the in-app XQL Library. You can configure a Google Cloud Platform
collector to receive generic, flow, audit, or Google Cloud DNS logs. When configuring generic logs, you can receive logs in a Raw, JSON, CEF, LEEF, Cisco, or
Corelight format.

You can also configure Cortex XSIAM to normalize different GCP logs as part of the enhanced cloud protection, which you can query with XQL Search using the
applicable dataset. Cortex XSIAM can also raise Cortex XSIAM alerts (Analytics, IOC, BIOC, and Correlation Rules) when relevant from GCP logs. While
Correlation Rules alerts are raised on non-normalized and normalized logs, Analytics, IOC, and BIOC alerts are only raised on normalized logs.

Enhanced cloud protection provides the following:

Normalization of cloud logs

Cloud logs stitching

Enrichment with cloud data

Detection based on cloud analytics

Cloud-tailored investigations

The following table lists the various GCP log types the XQL datasets you can use to query in XQL Search:

GCP Log Type Dataset Dataset With Normalized Data

Audit logs, including google_cloud_logging_raw cloud_audit_logs

Google Kubernetes
Engine (GKE) audit logs

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 680/1003
5/8/24, 9:18 AM PDF Export

GCP Log Type Dataset Dataset With Normalized Data

Generic logs Log Format types: N/A

CEF or LEEF: Automatically detected from

either the logs or the user's input in the User
Interface.

Cisco: cisco_asa_raw

Corelight: corelight_zeek_raw

JSON or Raw:
google_cloud_logging_raw

Google Cloud DNS logs google_dns_raw xdr_data: Once configured, Cortex XSIAM ingests Google Cloud DNS
logs as XDR network connection stories, which you can query with XQL
Search using the xdr_data dataset with the preset called
network_story.

Network flow logs google_cloud_logging_raw xdr_data: Once configured, Cortex XSIAM ingests network flow logs as
XDR network connection stories, which you can query with XQL Search
using the xdr_data dataset with the preset called network_story.

NOTE:

When collecting flow logs, we recommend that you include GKE annotations in your logs, which enable you to view the names of the containers that
communicated with each other. GKE annotations are only included in logs if appended manually using the custom metadata configuration in GCP. For more
information, see VPC Flow Logs Overview. In addition, to customize metadata fields, you must use the gcloud command-line interface or the API. For more
information, see Using VPC Flow Logs.

To receive logs and data from GCP, you must first set up log forwarding using a Pub/Sub topic in GCP. You can configure GCP settings using either the GCP
web interface or a GCP cloud shell terminal. After you set up your service account in GCP, you configure the Data Collection settings in Cortex XSIAM. The
setup process requires the subscription name and authentication key from your GCP instance.

After you set up log collection, Cortex XSIAM immediately begins receiving new logs and data from GCP.

Set up Log Forwarding Using the GCP Web Interface

1. Log in to your GCP account.

2. Set up log forwarding from GCP to Cortex XSIAM.

a. Select Logging → Logs Router.

b. Select Create Sink → Cloud Pub/Sub topic, and then click Next.

c. To filter only specific types of data, select the filter or desired resource.

d. In the Edit Sink configuration, define a descriptive Sink Name.

e. Select Sink Destination → Create new Cloud Pub/Sub topic.

f. Enter a descriptive Name that identifies the sink purpose for Cortex XSIAM, and then Create.

g. Create Sink and then Close when finished.

3. Create a subscription for your Pub/Sub topic.

a. Select the hamburger menu in G Cloud and then select Pub/Sub → Topics.

b. Select the name of the topic you created in the previous steps. Use the filters if necessary.

c. Create Subscription → Create subscription.

d. Enter a unique Subscription ID.

e. Choose Pull as the Delivery Type.

f. Create the subscription.

After the subscription is set up, G Cloud displays statistics and settings for the service.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 681/1003
5/8/24, 9:18 AM PDF Export

g. In the subscription details, identify and note your Subscription Name.

Optionally, use the copy button to copy the name to the clipboard. You will need the name when you configure Collection in Cortex XSIAM.

4. Create a service account and authentication key.

You will use the key to enable Cortex XSIAM to authenticate with the subscription service.

a. Select the hamburger menu and then select IAM & Admin → Service Accounts.

b. Create Service Account.

c. Enter a Service account name and then Create.

d. Select a role for the account: Pub/Sub → Pub/Sub Subscriber.

e. Click Continue → Done.

f. Locate the service account by name, using the filters to refine the results, if needed.

g. Click the Actions menu identified by the three dots in the row for the service account and then Create Key.

h. Select JSON as the key type, and then Create.

After you create the service account key, G Cloud automatically downloads it.

5. In Cortex XSIAM, set up Data Collection.

a. Select Settings → Configurations → Data Collection → Data Sources.

b. In the Google Cloud Platform configuration, click Add Instance.

c. Specify the Subscription Name that you previously noted or copied.

d. Browse to the JSON file containing your authentication key for the service account.

e. Select the Log Type as one of the following, where your selection changes the options displayed.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 682/1003
5/8/24, 9:18 AM PDF Export

Flow or Audit Logs—When selecting this log type, you can decide whether to normalize and enrich the logs as part of the enhanced cloud
protection.

(Optional) You can Normalize and enrich flow and audit logs by selecting the checkbox (default). If selected, Cortex XSIAM ingests the
network flow logs as Cortex XSIAM network connection stories, which you can query using XQL Search from the xdr_dataset dataset
with the preset called network_story. In addition, you can configure Cortex XSIAM to normalize GCP audit logs, which you can query
with XQL Search using the cloud_audit_logs dataset.

The Vendor is automatically set to Google and Product to Cloud Logging , which is not configurable. This means that all GCP data for
the flow and audit logs, whether it's normalized or not, can be queried in XQL Search using the google_cloud_logging_raw dataset.

Generic—When selecting this log type, you can configure the following settings.

Log Format—Select the log format type as Raw, JSON, CEF, LEEF, Cisco, or Corelight.

CEF or LEEF: The Vendor and Product defaults to Auto-Detect.

NOTE:

For a Log Format set to CEF or LEEF, Cortex XSIAM reads events row by row to look for the Vendor and Product configured in
the logs. When the values are populated in the event log row, Cortex XSIAM uses these values even if you specified a value in
the Vendor and Product fields in the GCP data collector settings. Yet, when the values are blank in the event log row, Cortex
XSIAM uses the Vendor and Product that you specified in the GCP data collector settings. If you did not specify a Vendor or
Product in the GCP data collector settings, and the values are blank in the event log row, the values for both fields are set to
unknown.

Cisco: The following fields are automatically set and not configurable.

Vendor—Cisco

Product—ASA

Cisco data can be queried in XQL Search using the cisco_asa_raw dataset.

Corelight: The following fields are automatically set and not configurable.

Vendor—Corelight

Product—Zeek

Corelight data can be queried in XQL Search using the corelight_zeek_raw dataset.

Raw or JSON: The following fields are automatically set and are configurable.

Vendor—Google

Product—Cloud Logging

Raw or JSON data can be queried in XQL Search using the google_cloud_logging_raw dataset.

Cortex XSIAM supports logs in single line format or multiline format. For a JSON format, multiline logs are collected automatically
when the Log Format is configured as JSON. When configuring a Raw format, you must also define the Multiline Parsing Regex
as explained below.

Vendor—(Optional) Specify a particular vendor name for the GCP generic data collection, which is used in the GCP XQL dataset
<Vendor>_<Product>_raw that Cortex XSIAM creates as soon as it begins receiving logs.

Product—(Optional) Specify a particular product name for the GCP generic data collection, which is used in the GCP XQL dataset
name <Vendor>_<Product>_raw that Cortex XSIAM creates as soon as it begins receiving logs.

Multiline Parsing Regex—(Optional) This option is only displayed when the Log Format is set to Raw, where you can set the regular
expression that identifies when the multiline event starts in logs with multilines. It is assumed that when a new event begins, the
previous one has ended.

Google Cloud DNS—When selecting this log type, you can configure whether to normalize the logs as part of the enhanced cloud protection.

Optional) You can Normalize DNS logs by selecting the checkbox (default). If selected, Cortex XSIAM ingests the Google Cloud DNS
logs as Cortex XSIAM network connection stories, which you can query using XQL Search from the xdr_dataset dataset with the
preset called network_story.

The Vendor is automatically set to Google and Product to DNS , which is not configurable. This means that all Google Cloud DNS logs,
whether it's normalized or not, can be queried in XQL Search using the google_dns_raw dataset.

f. Test the provided settings and, if successful, proceed to Enable log collection.

6. After Cortex XSIAM begins receiving information from the GCP Pub/Sub service, you can use the XQL Query language to search for specific data.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 683/1003
5/8/24, 9:18 AM PDF Export

Set up Log Forwarding Using the GCP Cloud Shell Terminal

1. Launch the GCP cloud shell terminal or use your preferred shell with gcloud installed.

2. Define your project ID.

gcloud config set project <PROJECT_ID>

3. Create a Pub/Sub topic.

gcloud pubsub topics create <TOPIC_NAME>

4. Create a subscription for this topic.

gcloud pubsub subscriptions create <SUBSCRIPTION_NAME> --topic=<TOPIC_NAME>

Note the subscription name you define in this step as you will need it to set up log ingestion from Cortex XSIAM.

5. Create a logging sink.

During the logging sink creation, you can also define additional log filters to exclude specific logs. To filter logs, supply the optional parameter --log-
filter=<LOG_FILTER>

gcloud logging sinks create <SINK_NAME> pubsub.googleapis.com/projects/<PROJECT_ID>/topics/<TOPIC_NAME> --log-filter=<LOG_FILTER>

If setup is successful, the console displays a summary of your log sink settings:

Created [https://logging.googleapis.com/v2/projects/PROJECT_ID/sinks/SINK_NAME]. Please remember to grant `serviceAccount:LOGS_SINK_SERVICE_ACCOUNT` \ the Pub/Sub

Publisher role on the topic. More information about sinks can be found at /logging/docs/export/configure_export

6. Grant log sink service account to publish to the new topic.

Note the serviceAccount name from the previous step and use it to define the service for which you want to grant publish access.

gcloud pubsub topics add-iam-policy-binding <TOPIC_NAME> --member serviceAccount:<LOGS_SINK_SERVICE_ACCOUNT> --role=roles/pubsub.publisher

7. Create a service account.

For example, use cortex-xdr-sa as the service account name and Cortex XSIAM Service Account as the display name.

gcloud iam service-accounts create <SERVICE_ACCOUNT> --description="<DESCRIPTION>" --display-name="<DISPLAY_NAME>"

8. Grant the IAM role to the service account.

gcloud pubsub subscriptions add-iam-policy-binding <SUBSCRIPTION_NAME> --member serviceAccount:<SERVICE_ACCOUNT>@<PROJECT_ID>.iam.gserviceaccount.com --

role=roles/pubsub.subscriber

9. Create a JSON key for the service account.

You will need the JSON file to enable Cortex XSIAM to authenticate with the GCP service. Specify the file destination and filename using a .json
extension.

gcloud iam service-accounts keys create <OUTPUT_FILE> --iam-account <SERVICE_ACCOUNT>@<PROJECT_ID>.iam.gserviceaccount.com

10. In Cortex XSIAM, set up Data Collection.

a. Select Settings → Configurations → Data Collection → Data Sources.

b. In the Google Cloud Platform configuration, click Add Instance.

c. Specify the Subscription Name that you previously noted or copied.

d. Browse to the JSON file containing your authentication key for the service account.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 684/1003
5/8/24, 9:18 AM PDF Export

e. Select the Log Type as one of the following, where your selection changes the options displayed.

Flow or Audit Logs—When selecting this log type, you can decide whether to normalize and enrich the logs as part of the enhanced cloud
protection.

(Optional) You can Normalize and enrich flow and audit logs by selecting the checkbox (default). If selected, Cortex XSIAM ingests the
network flow logs as Cortex XSIAM network connection stories, which you can query using XQL Search from the xdr_dataset dataset
with the preset called network_story. In addition, you can configure Cortex XSIAM to normalize GCP audit logs, which you can query
with XQL Search using the cloud_audit_logs dataset.

The Vendor is automatically set to Google and Product to Cloud Logging , which is not configurable. This means that all GCP data for
the flow and audit logs, whether it's normalized or not, can be queried in XQL Search using the google_cloud_logging_raw dataset.

Generic—When selecting this log type, you can configure the following settings.

Log Format—Select the log format type as Raw, JSON, CEF, LEEF, Cisco, or Corelight.

CEF or LEEF: The Vendor and Product defaults to Auto-Detect.

NOTE:

For a Log Format set to CEF or LEEF, Cortex XSIAM reads events row by row to look for the Vendor and Product configured in
the logs. When the values are populated in the event log row, Cortex XSIAM uses these values even if you specified a value in
the Vendor and Product fields in the GCP data collector settings. Yet, when the values are blank in the event log row, Cortex
XSIAM uses the Vendor and Product that you specified in the GCP data collector settings. If you did not specify a Vendor or
Product in the GCP data collector settings, and the values are blank in the event log row, the values for both fields are set to
unknown.

Cisco: The following fields are automatically set and not configurable.

Vendor—Cisco

Product—ASA

Cisco data can be queried in XQL Search using the cisco_asa_raw dataset.

Corelight: The following fields are automatically set and not configurable.

Vendor—Corelight

Product—Zeek

Corelight data can be queried in XQL Search using the corelight_zeek_raw dataset.

Raw or JSON: The following fields are automatically set and are configurable.

Vendor—Google

Product—Cloud Logging

Raw or JSON data can be queried in XQL Search using the google_cloud_logging_raw dataset.

Cortex XSIAM supports logs in single line format or multiline format. For a JSON format, multiline logs are collected automatically
when the Log Format is configured as JSON. When configuring a Raw format, you must also define the Multiline Parsing Regex
as explained below.

Vendor—(Optional) Specify a particular vendor name for the GCP generic data collection, which is used in the GCP XQL dataset
<Vendor>_<Product>_raw that Cortex XSIAM creates as soon as it begins receiving logs.

Product—(Optional) Specify a particular product name for the GCP generic data collection, which is used in the GCP XQL dataset
name <Vendor>_<Product>_raw that Cortex XSIAM creates as soon as it begins receiving logs.

Multiline Parsing Regex—(Optional) This option is only displayed when the Log Format is set to Raw, where you can set the regular
expression that identifies when the multiline event starts in logs with multilines. It is assumed that when a new event begins, the
previous one has ended.

Google Cloud DNS—When selecting this log type, you can configure whether to normalize the logs as part of the enhanced cloud protection.

Optional) You can Normalize DNS logs by selecting the checkbox (default). If selected, Cortex XSIAM ingests the Google Cloud DNS
logs as Cortex XSIAM network connection stories, which you can query using XQL Search from the xdr_dataset dataset with the
preset called network_story.

The Vendor is automatically set to Google and Product to DNS , which is not configurable. This means that all Google Cloud DNS logs,
whether it's normalized or not, can be queried in XQL Search using the google_dns_raw dataset.

f. Test the provided settings and, if successful, proceed to Enable log collection.

11. After Cortex XSIAM begins receiving information from the GCP Pub/Sub service, you can use the XQL Query language to search for specific data.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 685/1003
5/8/24, 9:18 AM PDF Export

8.4.5.4 | Ingest Logs from Google Kubernetes Engine

Abstract

Forward your Google Kubernetes Engine (GKE) logs directly to Cortex XSIAM using Elasticsearch Filebeat.

Instead of forwarding Google Kubernetes Engine (GKE) logs directly to Google StackDrive, Cortex XSIAM can ingest container logs from GKE using
Elasticsearch Filebeat. To receive logs, you must install Filebeat on your containers and enable Data Collection settings for Filebeat.

After Cortex XSIAM begins receiving logs, the app automatically creates an Cortex Query Language (XQL) dataset using the vendor and product name that you
specify during Filebeat setup. It is recommended to specify a descriptive name. For example, if you specify google as the vendor and kubernetes as the
product, the dataset name will be google_kubernetes_raw. If you leave the product and vendor blank, Cortex XSIAM assigns the dataset a name of
container_container_raw.

After Cortex XSIAM creates the dataset, you can search your GKE logs using XQL Search.

1. Install Filebeat on your containers.

For more information, see https://www.elastic.co/guide/en/beats/filebeat/current/running-on-kubernetes.html.

2. Ingest Logs from Elasticsearch FilebeatIngest Logs from Elasticsearch Filebeat.

Record your token key and API URL for the Filebeat Collector instance as you will need these later in this workflow.

3. Deploy a Filebeat as a DaemonSet on Kubernetes.

This ensures there is a running instance of Filebeat on each node of the cluster.

a. Download the manifest file to a location where you can edit it.

curl -L -O https://raw.githubusercontent.com/elastic/beats/7.10/deploy/kubernetes/filebeat-kubernetes.yaml

b. Open the YAML file in your preferred text editor.

c. Remove the cloud.id and cloud.auth lines.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 686/1003
5/8/24, 9:18 AM PDF Export

d. For the output.elasticsearch configuration, replace the hosts, username, and password with environment variable references for hosts and
api_key, and add a field and value for compression_level and bulk_max_size.

e. In the DaemonSet configuration, locate the env configuration and replace ELASTIC_CLOUD_AUTH, ELASTIC_CLOUD_ID, ELASTICSEARCH_USERNAME,
ELASTICSEARCH_PASSWORD, ELASTICSEARCH_HOST, ELASTICSEARCH_PORT and their relative values with the following.

ELASTICSEARCH_ENDPOINT—Specify the API URL for your Cortex XSIAM tenant. You can copy the URL from the Filebeat Collector instance

you set up for GKE in the Cortex XSIAM management console (Settings ( ) → Configurations → Data Collection → Custom Collectors →
Copy API URL. The URL will include your tenant name (https://api-tenant external URL:443/logs/v1/filebeat)

ELASTICSEARCH_API_KEY—Specify the token key you recorded earlier during the configuration of your Filebeat Collector instance.

After you configure these settings your configuration should look like the following image.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 687/1003
5/8/24, 9:18 AM PDF Export

f. Save your changes.

4. If you use RedHat OpenShift, you must also specify additional settings.

See https://www.elastic.co/guide/en/beats/filebeat/7.10/running-on-kubernetes.html.

5. Deploy Filebeat on your Kubernetes.

kubectl create -f filebeat-kubernetes.yaml

This deploys Filebeat in the kube-system namespace. If you want to deploy the Filebeat configuration in other namespaces, change the namespace
values in the YAML file (in any YAML inside this file) and add -n <your_namespace>.

After you deploy your configuration, the Filebeat DameonSet runs throughout your containers to forward logs to Cortex XSIAM. You can review the
configuration from the Kubernetes Engine console: Workloads → Filebeat → YAML.

NOTE:

Cortex XSIAM supports logs in single line format or multiline format. For more information on handling messages that span multiple lines of text in
Elasticsearch Filebeat, see Manage Multiline Messages.

6. After Cortex XSIAM begins receiving logs from GKE, you can use the XQL Search to search for logs in the new dataset.

8.4.5.5 | Ingest Logs from Microsoft Azure Event Hub

Abstract

Ingest logs from Microsoft Azure Event Hub with an option to ingest audit logs to use in Cortex XSIAM authentication stories.

Cortex XSIAM can ingest different types of data from Microsoft Azure Event Hub using the Microsoft Azure Event Hub data collector. To receive logs from Azure
Event Hub, you must configure the Data Sources settings in Cortex XSIAM based on your Microsoft Azure Event Hub configuration. After you set up data
collection, Cortex XSIAM begins receiving new logs and data from the source.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 688/1003
5/8/24, 9:18 AM PDF Export

When Cortex XSIAM begins receiving logs, the app creates a new dataset (MSFT_Azure_raw) that you can use to initiate XQL Search queries. For example,
queries refer to the in-app XQL Library. For enhanced cloud protection, you can also configure Cortex XSIAM to normalize Azure Event Hub audit logs, including
Azure Kubernetes Service (AKS) audit logs, with other Cortex XSIAM authentication stories across all cloud providers using the same format, which you can
query with XQL Search using the cloud_audit_logs dataset. For logs that you do not configure Cortex XSIAM to normalize, you can change the default
dataset. Cortex XSIAM can also raise Cortex XSIAM alerts (Analytics, IOC, BIOC, and Correlation Rules) when relevant from Azure Event Hub logs. While
Correlation Rules alerts are raised on non-normalized and normalized logs, Analytics, IOC, and BIOC alerts are only raised on normalized logs.

Enhanced cloud protection provides:

Normalization of cloud logs

Cloud logs stitching

Enrichment with cloud data

Detection based on cloud analytics

Cloud-tailored investigations

The following table provides a brief description of the different types of Azure audit logs you can collect.

NOTE:

For more information on Azure Event Hub audit logs, see Overview of Azure platform logs.

Type Of Data Description

Activity logs Retrieves events related to the operations on each Azure resource in the subscription from the outside in addition to
updates on Service Health events.

NOTE:

These logs are from the management plane.

Azure Active Directory (AD) Contain the history of sign-in activity and audit trail of changes made in Azure AD for a particular tenant.
Activity logs and Azure Sign-
in logs NOTE:

Even though you can collect Azure AD Activity logs and Azure Sign-in logs using the Azure Event Hub data collector, we
recommend using the Office 365 data collector as it's easier to configure. In addition, ensure that you don't configure
both collectors to collect the same types of logs as you'll be creating duplicate data in Cortex XSIAM.

Resource logs, including AKS Retrieves events related to operations that were performed within an Azure resource.
audit logs
NOTE:

These logs are from the data plane.

Prerequisite Steps

Be sure you do the following tasks before you begin configuring data collection from Azure Event Hub.

Create an Azure Event Hub. For more information, see Quickstart: Create an event hub using Azure portal.

Ensure the format for the logs you want collected from the Azure Event Hub is either JSON or raw.

Configure the Azure Event Hub collection in Cortex XSIAM.

1. In the Microsoft Azure Console, open the Event Hubs page, and select the Azure Event Hub that you created for collection in Cortex XSIAM.

2. Record the following parameters from your configured event hub, which you will need when configuring data collection in Cortex XSIAM.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 689/1003
5/8/24, 9:18 AM PDF Export

Your event hub’s consumer group.

1. Select Entities → Event Hubs, and select your event hub.

2. Select Entities → Consumer groups, and select your event hub.

3. In the Consumer group table, copy the applicable value listed in the Name column for your Cortex XSIAM data collection configuration.

Your event hub’s connection string for the designated policy.

1. Select Settings → Shared access policies.

2. In the Shared access policies table, select the applicable policy.

3. Copy the Connection string-primary key.

Your storage account connection string required for partitions lease management and checkpointing in Cortex XSIAM.

1. Open the Storage accounts page, and either create a new storage account or select an existing one, which will contain the storage account
connection string.

2. Select Security + networking → Access keys, and click Show keys.

3. Copy the applicable Connection string.

3. Configure diagnostic settings for the relevant log types you want to collect and then direct these diagnostic settings to the designated Azure Event Hub.

a. Open the Microsoft Azure Console.

b. Your navigation is dependent on the type of logs you want to configure.

Log Type Navigation Path

Activity logs Select Azure services → Activity log → Export Activity Logs, and +Add diagnostic setting.

Azure AD Activity logs and Azure 1. Select Azure services → Azure Active Directory.
Sign-in logs
2. Select Monitoring → Diagnostic settings, and +Add diagnostic setting.

Resource logs, including AKS 1. Search for Monitor, and select Settings → Diagnostic settings.
audit logs
2. From your list of available resources, select the resource that you want to configure for log
collection, and then select +Add diagnostic setting.

NOTE:

For every resource that you want to confiure, you'll have to repeat this step, or use Azure policy
for a general configuration.

c. Set the following parameters:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 690/1003
5/8/24, 9:18 AM PDF Export

Diagnostic setting name—Specify a name for your Diagnostic setting.

Logs Categories/Metrics—The options listed are dependent on the type of logs you want to configure. For Activity logs and Azure AD logs and
Azure Sign-in logs, the option is called Logs Categories, and for Resource logs it's called Metrics.

Log Type Log Categories/Metrics

Activity logs Select from the list of applicable Activity log categories, the ones that you want to configure your designated
resource to collect. We recommend selecting all of the options.

Administrative

Security

ServiceHealth

Alert

Recommendation

Policy

Autoscale

ResourceHealth

Azure AD Activity logs Select from the list of applicable Azure AD Activity and Azure Sign-in Logs Categories, the ones that you want to
and Azure Sign-in configure your designated resource to collect. You can select any of the following categories to collect these
logs types of Azure logs.

Azure AD Activity logs:

AuditLogs

Azure Sign-in logs:

SignInLogs

NonInteractiveUserSignInLogs

ServicePrincipalSignInLogs

ManagedIdentitySignInLogs

ADFSSignInLogs

NOTE:

There are additional log categories displayed. We recommend selecting all the available options.

Resource logs, The list displayed is dependent on the resource that you selected. We recommend selecting all the options
including AKS audit available for the resource.
logs

Destination details—Select Stream to event hub, where additional parameters are displayed that you need to configure. Ensure that you set
the following parameters using the same settings for the Azure Event Hub that you created for the collection.

Subscription—Select the applicable Subscription for the Azure Event Hub.

Event hub namespace—Select the applicable Subscription for the Azure Event Hub.

(Optional) Event hub name—Specify the name of your Azure Event Hub.

Event hub policy—Select the applicable Event hub policy for your Azure Event Hub.

d. Save your settings.

4. Configure the Azure Event Hub collection in Cortex XSIAM.

a. Select Settings → Configurations → Data Collection → Data Sources.

b. In the Azure Event Hub configuration, click Add Instance to begin a new configuration.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 691/1003
5/8/24, 9:18 AM PDF Export

c. Set these parameters.

Name—Specify a descriptive name for your log collection configuration.

Event Hub Connection String—Specify your event hub’s connection string for the designated policy.

Storage Account Connection String—Specify your event hub’s connection string for the designated policy.

Consumer Group—Specify your event hub’s consumer group.

Log Format—Select the log format for the logs collected from the Azure Event Hub as Raw, JSON, CEF, LEEF, Cisco-asa, or Corelight.

NOTE:

When you Normalize and enrich audit logs, the log format is automatically configured. As a result, the Log Format option is removed and is
no longer available to configure (default).

CEF or LEEF: The Vendor and Product defaults to Auto-Detect.

NOTE:

For a Log Format set to CEF or LEEF, Cortex XSIAM reads events row by row to look for the Vendor and Product configured in the
logs. When the values are populated in the event log row, Cortex XSIAM uses these values even if you specified a value in the
Vendor and Product fields in the Azure Event Hub data collector settings. Yet, when the values are blank in the event log row, Cortex
XSIAM uses the Vendor and Product that you specified in the Azure Event Hub data collector settings. If you did not specify a Vendor
or Product in the Azure Event Hub data collector settings, and the values are blank in the event log row, the values for both fields are
set to unknown.

Cisco-asa: The following fields are automatically set and not configurable.

Vendor—Cisco

Product—ASA

Cisco data can be queried in XQL Search using the cisco_asa_raw dataset.

Corelight: The following fields are automatically set and not configurable.

Vendor—Corelight

Product—Zeek

Corelight data can be queried in XQL Search using the corelight_zeek_raw dataset.

Raw or JSON: The following fields are automatically set and are configurable.

Vendor—Msft

Product—Azure

Raw or JSON data can be queried in XQL Search using the msft_azure_raw dataset.

Vendor and Product—Specify the Vendor and Product for the type of logs you are ingesting.

The Vendor and Product are used to define the name of your Cortex Query Language (XQL) dataset (<vendor>_<product>_raw). The
Vendor and Product values vary depending on the Log Format selected. To uniquely identify the log source, consider changing the values if
the values are configurable.

NOTE:

When you Normalize and enrich audit logs, the Vendor and Product fields are automatically configured, so these fields are removed as
available options (default).

Normalize and enrich audit logs—(Optional) For enhanced cloud protection, you can Normalize and enrich audit logs by selecting the
checkbox (default). If selected, Cortex XSIAM normalizes and enriches Azure Event Hub audit logs with other Cortex XSIAM authentication
stories across all cloud providers using the same format. You can query this normalized data with XQL Search using the cloud_audit_logs
dataset.

d. Click Test to validate access, and then click Enable.

Once events start to come in, a green check mark appears underneath the Azure Event Hub configuration with the amount of data received.

8.4.5.6 | Ingest Logs and Data from Okta

Abstract

Ingest authentication logs and data from Okta for use in Cortex XSIAM authentication stories.

To receive logs and data from Okta, you must configure the Data Sources settings in Cortex XSIAM. After you set up data collection, Cortex XSIAM immediately
begins receiving new logs and data from the source. The information from Okta is then searchable in XQL Search using the okta_sso_raw dataset. In addition,

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 692/1003
5/8/24, 9:18 AM PDF Export

depending on the event type, data is normalized to either xdr_data or saas_audit_logs datasets.

You can collect all types of events from Okta. When setting up the Okta data collector in Cortex XSIAM , a field called Okta Filter is available to configure
collection for events of your choosing. All events are collected by default unless you define an Okta API Filter expression for collecting the data, such as
filter=eventType eq “user.session.start”.\n. For Okta information to be weaved into authentication stories, “user.authentication.sso” events
must be collected.

Since the Okta API enforces concurrent rate limits, the Okta data collector is built with a mechanism to reduce the amount of requests whenever an error is
received from the Okta API indicating that too many requests have already been sent. In addition, to ensure you are properly notified about this, an alert is
displayed in the Notification Area and a record is added to the Management Audit Logs.

Before you begin configuring data collection from Okta, ensure your Okta user has administrator privileges with a role that can create API tokens, such as the
read-only administrator, Super administrator, and Organization administrator. For more information, see the Okta Administrators Documentation.

To configure the Okta collection in Cortex XSIAM:

1. Identify the domain name of your Okta service.

From the Dashboard of your Okta console, note your Org URL.

For more information, see the Okta Documentation.

2. Obtain your authentication token in Okta.

a. Select API → Tokens.

b. Create Token and record the token value.

This is your only opportunity to record the value.

3. Select Settings → Configurations → Data Collection → Data Sources.

4. Integrate the Okta authentication service with Cortex XSIAM .

a. Specify the OKTA DOMAIN (Org URL) that you identified on your Okta console.

b. Specify the TOKEN used to authenticate with Okta.

c. Specify the Okta Filter to configure collection for events of your choosing. All events are collected by default unless you define an Okta API Filter
expression for collecting the data, such as filter=eventType eq “user.session.start”.\n. For Okta information to be weaved into
authentication stories, “user.authentication.sso” events must be collected.

d. Test the connection settings.

e. If successful, Enable Okta log collection.

Once events start to come in, a green check mark appears underneath the Okta configuration with the amount of data received.

5. After Cortex XSIAM begins receiving information from the service, you can Create an XQL Query to search for specific data. When including
authentication events, you can also Create an Authentication Query to search for specific authentication data.

8.4.6 | Ingest Cloud Assets

Abstract

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 693/1003
5/8/24, 9:18 AM PDF Export

Cortex XSIAM enables you to ingest cloud assets from different third-party sources.

You can ingest cloud assets from different third-party sources.

8.4.6.1 | Ingest Cloud Assets from AWS

Abstract

Extend Cortex XSIAM visibility into cloud assets from AWS.

Cortex XSIAM provides a unified, normalized asset inventory for cloud assets in AWS. This capability provides deeper visibility to all the assets and superior
context for incident investigation.

To receive cloud assets from AWS, you must configure the Data Sources settings in Cortex XSIAM using the Cloud Inventory data collector to configure the
AWS wizard. The AWS wizard includes instructions to be completed both in AWS and the AWS wizard screens. After you set up data collection, Cortex XSIAM
begins receiving new data from the source.

As soon as Cortex XSIAM begins receiving cloud assets, you can view the data in Assets → Cloud Inventory, where All Assets and Specific Cloud Assets pages
display the data in a table format.

To configure the AWS cloud assets collection in Cortex XSIAM.

1. Open the AWS wizard in Cortex XSIAM.

a. Select Settings → Data Sources.

b. In the Cloud Inventory configuration, click Add Instance to begin a new configuration.

c. Click AWS.

2. Define the Account Details screen of the wizard.

Setting the connection parameters on the right-side of the screen is dependent on certain configurations in AWS as explained below.

a. Select the Organization Level as either Account (default), Organization, or Organization Unit. The Organization Level that you select changes the
instructions and fields displayed on the screen.

b. Sign in to your AWS master account.

c. Create a stack called XDRCloudApp using the preset Cortex XSIAM template in AWS.

The following details are automatically filled in for you in the AWS CloudFormation stack template.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 694/1003
5/8/24, 9:18 AM PDF Export

Stack Name—The default name for the stack is XDRCloudApp.

CortexXDRRoleName—The name of the role that will be used by Cortex XSIAM to authenticate and access the resources in your AWS
account.

External ID—The Cortex XSIAM Cloud ID, a randomly generated UUID that is used to enable the trust relationship in the role's trust policy.

To create the stack, accept the IAM acknowledgment for resource creation by selecting the I acknowledge that AWS CloudFormation might create
IAM resources with custom names checkbox, and click Create Stack.

d. Wait for the Status to update to CREATE_COMPLETE in the Stacks page that is displayed, and select the XDRCloudAPP stack under the Stack
name column in the table.

e. Select the Outputs tab and copy the Value of the Role ARN.

f. Paste the Role ARN value in one of the following fields in the Account Details screen in Cortex XSIAM. The field name is dependent on the
Organization Level that you selected.

Account—Paste the value in the Account Role ARN field.

Organization—Paste the value in the Master Role ARN field.

Organization Unit—Paste the value in the Master Role ARN field.

g. Set the Root ID in Cortex XSIAM.

NOTE:

This step is only relevant if you’ve configured the Organization Level as Organization in the Account Details screen in Cortex XSIAM. Otherwise,
you can skip this step if the Organization Level is set to Account or Organization Unit.

1. From the main menu of the AWS Console, select <your username> → My Organization.

2. Copy the Root ID displayed under the Root directory and paste it in the Root ID field in the Account Details screen in Cortex XSIAM.

h. Set the Organization Unit ID in Cortex XSIAM.

NOTE:

This step is only relevant if you’ve configured the Organization Level as Organization Unit in the Account Details screen in Cortex XSIAM.
Otherwise, you can skip this step if the Organization Level is set to Account or Organization.

1. On the main menu of the AWS Console, select your username, and then My Organization.

2. Select the Organization Unit with an icon-ou ( ) beside it in the organizational structure that you want to configure.

3. Copy the ID and paste it in the Organization Unit ID field in the Account Details screen in Cortex XSIAM.

i. Define the following remaining connection parameters in the Account Details screen in Cortex XSIAM.

Account Role External ID / Master External ID—The name of this field is dependent on the Organization Level configured. This field is
automatically populated with a value. You can either leave this value or replace it with another value.

Cortex XDR Collection Name—Specify a name for your Cortex XSIAM collection that is displayed underneath the Cloud Inventory
configuration for this AWS collection.

j. Click Next.

3. Define the Configure Member Accounts screen of the wizard.

NOTE:

This wizard screen is only displayed if you’ve configured the Organization Level as Organization or Organization Unit in the Account Details screen in
Cortex XSIAM. Otherwise, you can skip this step when the Organization Level is set to Account.

Configuring member accounts is dependent on creating a stack set and configuring stack instances in AWS, which can be performed using either the
Amazon Command Line Interface (CLI) or Cloud Formation template via the AWS Console. Both of these methods are explained in the instructions below.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 695/1003
5/8/24, 9:18 AM PDF Export

Define the account credentials using Amazon CLI.

1. Select the Amazon CLI tab, which is displayed by default.

2. Open the Amazon CLI.

NOTE:

For more information on how to set up the AWS CLI tool, see the AWS Command Line Interface Documentation.

3. Run the following command to create a stack set, which you can copy from the Configure Member Accounts screen by selecting the copy icon
( ), and paste in the Amazon CLI. This command includes the Role Name and External ID field values configured from the wizard screen.

aws cloudformation create-stack-set --stack-set-name StackSetCortexXdr01 --template-url https://cortex-xdr-xcloud-onboarding-scripts-dev.s3.us-east-

2.amazonaws.com/cortex-xdr-xcloud-master-dev-1.0.0.template --permission-model SERVICE_MANAGED --auto-deployment
Enabled=true,RetainStacksOnAccountRemoval=true --parameters ParameterKey=ExternalID,ParameterValue=c9a7024c-3f07-40ed-a4fb-c3a5eba778e2 --capabilities
CAPABILITY_NAMED_IAM

4. Run the following command to add stack instances to your stack set, which you can copy from the Configure Member Accounts screen by
selecting the copy icon ( ), and paste in the Amazon CLI. For the --deployment-targets parameter, specify the organization root ID to
deploy to all accounts in your organization, or specify Organization Unit IDs to deploy to all accounts in these Organization Units. In this
parameter, you will need to replace <Org_OU_ID1>, <Org_OU_ID2>, and <Region> according to your AWS settings.

aws cloudformation create-stack-instances --stack-set-name StackSetCortexXdr01 --deployment-targets OrganizationalUnitIds='["<Org_OU_ID1>", "<Org_OU_ID2>"]'

--regions '["<Region>"]'

In this example, the Organization Units are populated with ou-rcuk-1x5j1lwo and ou-rcuk-slr5lh0a IDs.

aws cloudformation create-stack-instances --stack-set-name StackSet_myApp --deployment-targets OrganizationalUnitIds='["ou-rcuk-1x5j1lwo", "ou-rcuk-

slr5lh0a"]' --regions '["eu-west-1"]'

Once completed, in the AWS Console, select Services → CloudFormation → StackSets, and you can see the StackSet is now listed in the
table.

Define the account credentials using AWS CloudFormation.

1. Select the Cloud Formation tab.

2. Download the CloudFormation template. The name of the file downloaded is called cortex-xdr-aws-master-ro-1.0.0.template.

3. Sign in to your AWS Master Account using the AWS console, select Services → CloudFormation → StackSets, and click Create StackSet.

4. Define the following settings.

-Select Template is ready.

-Select Upload a template file, Choose file, and select the CloudFormation template that you downloaded.

5. Click Next.

6. Define the following settings.

-StackSet name—Specify a name for the StackSet.

ExternalID—The ExternalID value specified here must be copied from the one populated in the External ID field on the right-side of the
Configure Member Accounts screen in Cortex XSIAM .

7. Click Next.

8. Select Service-managed permissions, and click Next.

9. Define the following settings.

Deployment targets

-Select Deploy to the organization.

-Select Enabled for Automatic deployments.

-Select Delete stacks for Account removal behavior.

Specify regions

-Select one region only. (It can be any region.)

Deployment options

-For the Maximum concurrent accounts, select Percentage, and in the field specify 100.

-For the Failure tolerance, select Percentage, and in the field specify 100.

10. Click Next.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 696/1003
5/8/24, 9:18 AM PDF Export

11. To create the StackSet, accept the IAM acknowledgment for resource creation by selecting the I acknowledge that AWS CloudFormation
might create IAM resources with custom names checkbox, and click Submit.

When the process completes, the Status of the StackSet is SUCCEEDED in the StackSet details page.

4. Review the Summary screen of the wizard.

If something needs to be corrected, you can go Back to correct it.

5. Click Create.

Once cloud assets from AWS start to come in, a green check mark appears underneath the Cloud Inventory configuration with the Last collection time
displayed. It can take a few minutes for the Last Collection time to display as the processing completes.

NOTE:

Whenever the Cloud Inventory data collector integrations are modified by using the Edit, Disable, or Delete options, it can take up to 10 minutes for
these changes to be reflected in Cortex XSIAM.

6. After Cortex XSIAM begins receiving AWS cloud assets, you can view the data in Assets → Cloud Inventory, where All Assets and Specific Cloud Assets
pages display the data in a table format. For more information, see Cloud Inventory Assets.

8.4.6.2 | Ingest Cloud Assets from Google Cloud Platform

Abstract

Extend Cortex XSIAM visibility into cloud assets from Google Cloud Platform.

Cortex XSIAM provides a unified, normalized asset inventory for cloud assets in Google Cloud Platform (GCP). This capability provides deeper visibility to all the
assets and superior context for incident investigation.

To receive cloud assets from GCP, you must configure the Data Sources settings in Cortex XSIAM using the Cloud Inventory data collector to configure the GCP
wizard. The GCP wizard includes instructions to be completed both in GCP and the GCP wizard screens. After you set up data collection, Cortex XSIAM begins
receiving new data from the source.

As soon as Cortex XSIAM begins receiving cloud assets, you can view the data in Assets → Cloud Inventory, where All Assets and Specific Cloud Assets pages
display the data in a table format.

To configure the GCP cloud assets collection in Cortex XSIAM.

1. Open the GCP wizard in Cortex XSIAM.

a. Select Settings → Data Sources.

b. In the Cloud Inventory configuration, click Add Instance to begin a new configuration.

c. Click Google Cloud Platform.

2. Define the Configure Account screen of the wizard.

Setting the connection parameters on the right-side of the screen is dependent on certain configurations in GCP as explained below.

a. Select the Organization Level as either Project (default), Folder, or Organization. The Organization Level that you select changes the instructions.

b. Register your application for Cloud Asset API in Google Cloud Platform, Select a project where your application will be registered, and click
Continue.

The Cloud Asset API is enabled.

c. Click Continue to open the GCP Cloud Console.

d. On the main menu, select the project menu.

e. In the window that opens, perform the following.

1. From the Select from menu, select the organization that you want.

2. The next steps to perform in Google Cloud Platform are dependent on the Organizational Level you selected in Cortex XSIAM - Project,
Folder, or Organization.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 697/1003
5/8/24, 9:18 AM PDF Export

Project or Folder Organization Level—In the table, copy one of the following IDs that you want to configure and paste it in the
designated field in the Configure Account screen in Cortex XSIAM . The field in Cortex XSIAM is dependent on the Organizational Level
you selected.

-Project—Contains a project icon ( ) beside it, and the ID should be pasted in the Project ID field in Cortex XSIAM.

-Folder—Contains a folder icon ( ) beside it, and the ID should be pasted in the Folder ID field in Cortex XSIAM.

When you are finished, click CANCEL to close the window.

Organization is the Organization Level—Select the ellipsis icon ( ) → Settings. In the Settings page, copy the Organization ID for
the applicable organization that you want to configure and paste it in the Organization Id field in the Configure Account screen in Cortex
XSIAM.

f. Select the Hamburger menu → Storage → Cloud Storage → Browser.

g. You can either use an existing bucket from the list or create a new bucket. Copy the Name of the bucket and paste it in the Bucket Name field in the
Configure Account screen in Cortex XSIAM.

h. Define the following remaining connection parameters in the Configure Account screen in Cortex XSIAM.

Bucket Directory Name—You can either leave the default directory as Exported-Assets or define a new directory name that will be created for
the exported assets collected for the bucket configured in GCP.

Cortex XDR Collection Name—Specify a name for your Cortex XSIAM collection that is displayed underneath the Cloud Inventory
configuration for this GCP collection.

i. Click Next.

3. Define the Account Details screen of the wizard.

a. Download the Terraform script. The name of the file downloaded is dependent on the Organizational Level that you configured in the Configure
Account screen of the wizard.

Folder—cortex-xdr-gcp-folder-ro.tf

Project—cortex-xdr-gcp-project-ro.tf

Organization—cortex-xdr-gcp-organization-ro.tf

b. Login to the Google Cloud Shell.

c. Click Continue to open the Cloud Shell Editor.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 698/1003
5/8/24, 9:18 AM PDF Export

d. Select File → Open, and Open the Terraform script that you downloaded from Cortex XSIAM.

e. Use the following commands to upload the Terraform script, which you can copy from the Account Details screen in Cortex XSIAM using the copy
icon ( ).

1. terraform init—Initializes the Terraform script. You need to wait until the initialization is complete before running the next command as
indicated in the image below.

2. terraform apply—When running this command, you are asked to enter the following values.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 699/1003
5/8/24, 9:18 AM PDF Export

var.assets_bucket_name—Specify the GCP storage Bucket Name that you configured in the Configure Account screen of the wizard
to contain GCP cloud asset data.

var.host_project_id—Specify the GCP Project ID to host the XDR service account and bucket, which you registered your
application. Ensure that you use a permanent project.

var.project_id—Specify the Project ID, Folder ID, or Organization ID that you configured in the Configure Account screen of the
wizard from GCP.

After specifying all the values, you need to Authorize gcloud to use your credentials to make this GCP API call in the Authorize Cloud
Shell dialog box that is displayed.

Before the action completes, you need to confirm whether you want to perform these actions, and after the process finishes running an
Apply complete indication is displayed.

You can view the output JSON file called cortex-service-account-<GCP host project ID>.json by running the ls command.

f. Download the JSON file from Google Cloud Shell.

1. In the Google Cloud Shell console, select ellipsis icon ( ) → Download.

2. Select the JSON file produced after running the Terraform script, and click Download.

g. Upload the downloaded Service Account Key JSON file in the Configure Account screen in Cortex XSIAM. You can drag and drop the file, or
Browse to the file.

h. Click Next.

4. (Optional) Define the Change Asset Logs screen of the wizard.

NOTE:

You can skip this step if you’ve already configured a Google Cloud Platform data collector with a Pub/Sub asset feed collection.

a. In the GCP Console, search for Topics, and select the Topics link.

b. CREATE TOPIC.

c. Specify a Topic ID, and CREATE TOPIC.

NOTE:

A Topic name is automatically populated underneath the Topic ID field.

The new topic is listed in the table in the Topics page.

d. Run the following command to create a feed on an asset using the gcloud CLI tool, which you can copy from the Change Asset Logs screen in
Cortex XSIAM by selecting the copy icon ( ), and paste in the gcloud CLI tool.

NOTE:

For more information on the gcloud CLI tool. see gcloud tool overview.
gcloud asset feeds create <FEED_ID> --project=xdr-cloud-projectid --pubsub-topic="<Topic name>" --content-type=resource --asset-
types="compute.googleapis.com/Instance,compute.googleapis.com/Image,compute.googleapis.com/Disk,compute.googleapis.com/Network,compute.googleapis.com/Subnetwork,
compute.googleapis.com/Firewall,storage.googleapis.com/Bucket,cloudfunctions.googleapis.com/CloudFunction"

The command contains a parameter already populated and parameters that you need to replace before running the command.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 700/1003
5/8/24, 9:18 AM PDF Export

<FEED_ID>—Replace this placeholder text with a unique asset feed identifier of your choosing.

--project—This parameter is automatically populated from the Project ID field in the Configure Account screen wizard in Cortex XSIAM.

<Topic name>—Replace this placeholder text with the topic name you created in the Topic details page in the GCP console.

e. In the GCP Console, search for Subscription, and select the Subscriptions link.

f. CREATE SUBSCRIPTION for the topic you created.

g. Set the following parameters.

Subscription ID—Specify a unique identifier for the subscription.

Select a Cloud Pub/Sub topic—Select the topic you created.

Delivery type—Select Pull.

h. Click CREATE.

The new subscription is listed in the table in the Subscriptions page.

i. Select the subscription that you created for your topic and add PERMISSIONS for the subscriber in the Subscription details page.

j. ADD PRINCIPAL to add permissions for the Service Account that you created the key for in the JSON file and uploaded to the Configure Account
wizard screen in Cortex XSIAM. Set the following permissions for the Service Account.

New principals—Select the designated Service Account Key you created in the JSON file.

Select a role—Select Pub/Sub Subscriber.

k. Copy the Subscription name and paste it in the Subscription Name field on the right-side of the Change Asset Logs screen in Cortex XSIAM , and
click Next.

NOTE:

The Subscription Name is the name of the new Google Cloud Platform data collector that is configured with a Pub/Sub asset feed collection.

5. Review the Summary screen of the wizard.

If something needs to be corrected, you can go Back to correct it.

6. Click Create.

Once cloud assets from GCP start to come in, a green check mark appears underneath the Cloud Inventory configuration with the Last collection time
displayed. It can take a few minutes for the Last Collection time to display as the processing completes.

NOTE:

Whenever the Cloud Inventory data collector integrations are modified by using the Edit, Disable, or Delete options, it can take up to 10 minutes for
these changes to be reflected in Cortex XSIAM.

In addition, if you created a Pub/Sub asset feed collection, a green check mark appears underneath the Google Cloud Platform configuration with the
amount of data received.

7. After Cortex XSIAM begins receiving GCP cloud assets, you can view the data in Assets → Cloud Inventory, where All Assets and Specific Cloud Assets
pages display the data in a table format. For more information, see Cloud Inventory Assets.

8.4.6.3 | Ingest Cloud Assets from Microsoft Azure

Abstract

Extend Cortex XSIAM visibility into cloud assets from Microsoft Azure.

Cortex XSIAM provides a unified, normalized asset inventory for cloud assets in Microsoft Azure. This capability provides deeper visibility to all the assets and
superior context for incident investigation.

To receive cloud assets from Microsoft Azure, you must configure the Data Sources settings in Cortex XSIAM using the Cloud Inventory data collector to
configure the Microsoft Azure wizard. The Microsoft Azure wizard includes instructions to be completed both in Microsoft Azure and the Microsoft Azure wizard
screens. After you set up data collection, Cortex XSIAM begins receiving new data from the source.

As soon as Cortex XSIAM begins receiving cloud assets, you can view the data in Assets → Cloud Inventory, where All Assets and Specific Cloud Assets pages
display the data in a table format.

To configure the Microsoft Azure cloud assets collection in Cortex XSIAM.

1. Open the Microsoft Azure wizard in Cortex XSIAM.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 701/1003
5/8/24, 9:18 AM PDF Export

a. Select Settings → Data Sources.

b. In the Cloud Inventory configuration, click Add Instance to begin a new configuration.

c. Click Azure.

2. Define the Configure Account screen of the wizard.

Setting the connection parameters on the right-side of the screen are dependent on certain configurations in Microsoft Azure as explained below.

a. Select the Organization Level as either Subscription (default), Tenant, or Management Group. The Organization Level that you select changes the
instructions and fields displayed on the screen.

b. Login to your Microsoft Azure Portal.

c. Search for Subscriptions, select Subscriptions, copy the applicable Subscription ID in Azure, and paste it in the Subscription ID field in the Configure
Account screen wizard in Cortex XSIAM.

NOTE:

This step is only relevant if you’ve configured the Organization Level as Subscription in the Configure Account screen in Cortex XSIAM.
Otherwise, you can skip this step if the Organization Level is set to Tenant or Management Group.

d. Search for Management groups, select Management groups, copy the applicable ID in Azure, and paste it in the Management Group ID field in the
Configure Account screen wizard in Cortex XSIAM.

NOTE:

This step is only relevant if you’ve configured the Organization Level as Management Group in the Configure Account screen in Cortex XSIAM.
Otherwise, you can skip this step if the Organization Level is set to Subscription or Tenant.

e. Search for Tenant properties, select Tenant properties, copy the Tenant ID in Azure, and paste it in the Tenant ID field in the Configure Account
screen wizard in Cortex XSIAM.

f. Specify a Cortex XDR Collection Name to be displayed underneath the Cloud Inventory configuration for this Azure collection.

g. Click Next.

3. Define the Account Details screen of the wizard.

a. Download the Terraform script. The name of the file downloaded is dependent on the Organization Level that you configured in the Configure
Account screen of the wizard.

Subscription—cortex-xdr-azure-subscription-ro.tf

Management Group—cortex-xdr-azure-group-ro.tf

Tenant—cortex-xdr-azure-org-ro.tf

WARNING:

To run the Terraform scipt when configuring the Organization Level at the Tenant level, you must first ensure that you elevate user access
to manage all Azure subscriptions and management groups for the User Access Administrator role. For more information, see the Microsoft
Azure documentation.

b. Login to the Azure Cloud Shell portal, and select Bash.

c. Click the upload/download icon ( ) to Upload the Terraform script to Cloud Shell, browse to the file, and click Open.

A notification with the Upload destination is displayed on the bottom-right corner of the screen.

d. Use the following commands to upload the Terraform script, which you can copy from the Account Details screen in Cortex XSIAM using the copy
icon ( ).

1. terraform init—Initializes the Terraform script. You need to wait until the initialization is complete before running the next command as
indicated in the image below.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 702/1003
5/8/24, 9:18 AM PDF Export

2. terraform apply—When running this command you will be asked to enter the following values, which are dependent on the Organization
Level that you configured.

NOTE:

Before running this command, ensure that your Azure CLI client is logged in by running az login. For more information, see Sign in with
Azure CLI.

var.subscription_id—Specify the Subscription ID that you configured in the Configure Account screen of the wizard from Microsoft
Azure. This value only needs to be specified if the Subscription ID is set to Subscription.

var.management.group_id—Specify the Management Group IDthat you configured in the Configure Account screen of the wizard
from Microsoft Azure. This value only needs to be specified if the Microsoft Group is set to Management Group.

var.tenant_id—Specify the Tenant ID that you configured in the Configure Account screen of the wizard from Microsoft Azure.

Before the action completes, you need to confirm whether you want to perform these actions, and after the process finishes running an Apply
complete indication is displayed.

e. Copy the client_id value displayed in the Cloud Shell window and paste it in the Application Client ID field in the Account Details screen in Cortex
XSIAM.

f. Copy the secret value displayed in the Cloud Shell window and paste it in the Secret field in the Account Details screen in Cortex XSIAM.

g. Download the JSON file from Cloud Shell using the upload/download icon ( ), so you have output field values for future reference.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 703/1003
5/8/24, 9:18 AM PDF Export

h. Click Next.

4. Review the Summary screen of the wizard.

If something needs to be corrected, you can go Back to correct it.

5. Click Create.

Once cloud assets from Azure start to come in, a green check mark appears underneath the Cloud Inventory configuration with the Last collection time
displayed. It can take a few minutes for the Last Collection time to display as the processing completes.

NOTE:

Whenever the Cloud Inventory data collector integrations are modified by using the Edit, Disable, or Delete options, it can take up to 10 minutes for
these changes to be reflected in Cortex XSIAM.

6. After Cortex XSIAM begins receiving Azure cloud assets, you can view the data in Assets → Cloud Inventory, where All Assets and Specific Cloud Assets
pages display the data in a table format. For more information, see Cloud Inventory Assets.

8.4.7 | Additional Log Ingestion Methods

Abstract

Cortex XSIAM supports custom log ingestion methods.

In addition to native log ingestion support, Cortex XSIAM also supports a number of custom log ingestion methods.

8.4.7.1 | Ingest Logs from a Syslog Receiver

Abstract

To extend visibility, Cortex XSIAM can receive Syslog from additional vendors that use CEF or LEEF formatted over Syslog (TLS not supported).

Cortex XSIAM can receive Syslog from a variety of supported vendors (see External Data Ingestion Vendor Support). In addition, Cortex XSIAM can receive
Syslog from additional vendors that use CEF, LEEF, CISCO, CORELIGHT, or RAW formatted over Syslog.

After Cortex XSIAM begins receiving logs from the third-party source, Cortex XSIAM automatically parses the logs in CEF, LEEF, CISCO, CORELIGHT, or RAW
format and creates a dataset with the name <vendor>_<product>_raw. You can then use XQL Search queries to view logs and create new IOC, BIOC, and
Correlation Rules.

To receive Syslog from an external source:

1. Set up your Syslog receiver to forward logs.

2. Activate the Syslog Collector applet on a Broker VM within your network.

3. Use the XQL Search to search your logs.

8.4.7.2 | Ingest Apache Kafka Events as Datasets

Abstract

Cortex XSIAM can receive logs and data from Apache Kafka directly to your log repository for query and visualization purposes.

Cortex XSIAM can receive events from Apache Kafka clusters directly to your log repository for query and visualization purposes. After you activate the Kafka
Collector applet on a Broker VM in your network, which includes defining the connection details and settings related to the list of subscribed topics to monitor
and upload to Cortex XSIAM, you can collect events as datasets.

After Cortex XSIAM begins receiving topic events from the Kafka clusters, Cortex XSIAM automatically parses the events and creates a dataset with the specific
name you set as the target dataset when you configured the Kafka Collector, and adds the data in these files to the dataset. You can then use XQL Search
queries to view events and create new Correlation Rules.

Configure Cortex XSIAM to receive events as datasets from topics in Kafka clusters.

1. Activate the Kafka Collector applet on a Broker VM within your network.

2. Use the XQL Search to query and review logs.

8.4.7.3 | Ingest CSV Files as Datasets

Abstract

Cortex XSIAM can receive CSV log files from a shared Windows directory, where the CSV log files must conform to specific guidelines.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 704/1003
5/8/24, 9:18 AM PDF Export

Cortex XSIAM can receive CSV log files from a shared Windows directory directly to your log repository for query and visualization purposes. After you activate
the CSV Collector applet on a Broker VM in your network, which includes defining the list of folders mounted to the Broker VM and setting the list of CSV files to
monitor and upload to Cortex XSIAM (using a username and password), you can ingest CSV files as datasets.

The ingested CSV log files must conform to the following guidelines:

Header field names must contain only letters (a-z, A-Z) or numbers (0-9) and must start with a letter. Spaces are converted to underscores (_).

Date values can be in either of the following formats:

YYYY-MM-DD (optionally including HH:MM:SS)

Unix Epoch time. For example, 1614858795.

After Cortex XSIAM begins receiving logs from the shared Windows directory, Cortex XSIAM automatically parses the logs and creates a dataset with the
specific name you set as the target dataset when you configured the CSV Collector. The CSV Collector checks for any changes in the configured CSV files, as
well as any new CSV files added to the configuration folders, in the Windows directory every 10 minutes and replaces the data in the dataset with the data from
those files. You can then use XQL Search queries to view logs and create new Correlation Rules.

Configure Cortex XSIAM to receive CSV files as datasets from a shared Windows directory.

1. Ensure that you share the applicable CSV files in your Windows directory.

2. Activate the CSV Collector applet on a Broker VM within your network.

3. Use the XQL Search to locate and review logs.

8.4.7.4 | Ingest Database Data as Datasets

Abstract

Cortex XSIAM can receive data from a client relational database directly to your log repository.

Cortex XSIAM can receive data from a client relational database directly to your log repository for query and visualization purposes. After you activate the
Database Collector applet on a Broker VM in your network, which includes defining the database connection details and settings related to the query details for
collecting the data from the database to monitor and upload to Cortex XSIAM, you can collect data as datasets.

After Cortex XSIAM begins receiving data from a client relational database, Cortex XSIAM automatically parses the logs and creates a dataset with the specific
name you set as the target dataset when you configured the Database Collector using the format <Vendor>_<Product>_raw. The Database Collector checks
for any changes in the configured database based on the SQL Query defined in the database connection according to the execution frequency of collection that
you configured and appends the data to the dataset. You can then use XQL Search queries to view data and create new Correlation Rules.

Configure Cortex XSIAM to receive data as datasets data from a client relational database.

1. Activate the Database Collector applet on a Broker VM within your network.

2. Use the XQL Search to query and review logs.

8.4.7.5 | Ingest Logs in a Network Share as Datasets

Abstract

Cortex XSIAM can receive logs from files and folders in a network share directly to your log repository for query and visualization purposes.

Cortex XSIAM can receive logs from files and folders in a network share directly to your log repository for query and visualization purposes. After you activate
the Files and Folders Collector applet on a Broker VM in your network, which includes defining the connection details and settings related to the list of files to
monitor and upload to Cortex XSIAM, you can collect files as datasets.

After Cortex XSIAM begins receiving logs from files and folders in a network share, Cortex XSIAM automatically parses the logs and creates a dataset with the
specific name you set as the target dataset when you configured the Files and Folders Collector using the format <Vendor>_<Product>_raw. The Files and
Folders Collector reads and processes the configured files one by one, as well as any new files added to the configured files and folders, in the network share
according to the execution frequency of collection that you configured and adds the data in these files to the dataset. You can then use XQL Search queries to
view logs and create new Correlation Rules.

NOTE:

The Files and Folders Collector applet only starts to collect files that are more than 256 bytes.

Configure Cortex XSIAM to receive logs as datasets from files and folders in a network share.

1. Activate the Files and Folders Collector applet on a Broker VM within your network.

2. Use the XQL Search to query and review logs.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 705/1003
5/8/24, 9:18 AM PDF Export

8.4.7.6 | Ingest FTP Files as Datasets

Abstract

Cortex XSIAM can receive logs from files and folders via FTP, FTPS, and SFTP directly to your log repository for query and visualization purposes.

Cortex XSIAM can receive logs from files and folders via FTP, FTPS, or SFTP directly to your log repository for query and visualization purposes. After you
activate the FTP Collector applet on a Broker VM in your network, which includes defining the connection details and settings related to the list of files to monitor
and upload to Cortex XSIAM, you can collect files as datasets.

After Cortex XSIAM begins receiving logs from files and folders via FTP, FTPS, or SFTP, Cortex XSIAM automatically parses the logs and creates a dataset with
the specific name you set as the target dataset when you configured the FTP Collector using the format <Vendor>_<Product>_raw. The FTP Collector reads
and processes the configured FTP files one by one, as well as any new FTP files added to the configured files and folders, in the FTP directory according to the
execution frequency of collection that you configured, and adds the data in these files to the dataset. You can then use XQL Search queries to view logs and
create new Correlation Rules.

Configure Cortex XSIAM to receive logs as datasets from files and folders via FTP, FTPS, or SFTP.

1. Activate the FTP Collector applet on a Broker VM within your network.

2. Use the XQL Search to query and review logs.

8.4.7.7 | Ingest NetFlow Flow Records as Datasets

Abstract

Cortex XSIAM can receive NetFlow flow records and IPFIX from a UDP port directly to your log repository for query and visualization purposes.

Cortex XSIAM can receive NetFlow flow records and IPFIX from a UDP port directly to your log repository for query and visualization purposes. After you
activate the NetFlow Collector applet on a Broker VM in your network, which includes configuring your NetFlow Collector settings, you can ingest NetFlow flow
records and IPFIX as datasets.

The ingested NetFlow flow record format must include, at the very least:

Source and Destination IP addresses

TCP/UDP source and destination port numbers

After Cortex XSIAM begins receiving flow records from the UDP port, Cortex XSIAM automatically parses the flow records and creates a dataset with the
specific name you set as the target dataset when you configured the NetFlow Collector. The NetFlow Collector adds the flow records to the dataset. You can
then use XQL Search queries to view those flow records and create new IOC, BIOC, and Correlation Rules. Cortex XSIAM can also analyze your logs to raise
Analytics alerts.

Configure Cortex XSIAM to receive NetFlow flow records as datasets from the routers and switches that support NetFlow.

1. Set up your NetFlow exporter to forward flow records to the IP address of the Broker VM that runs the NetFlow collector applet.

2. Activate the NetFlow Collector applet on a Broker VM within your network.

3. Use the XQL Search to query your flow records, using your designated dataset.

8.4.7.8 | Set up an HTTP Log Collector to Receive Logs

Abstract

You can set up Cortex XSIAM to receive logs from third-party sources, and automatically parse and process these logs.

In addition to logs from supported vendors, you can set up a custom HTTP log collector to receive logs in Raw, JSON, CEF, or LEEF format. The HTTP Log
Collector can ingest up to 80,000 events per sec.

After Cortex XSIAM begins receiving logs from the third-party source, Cortex XSIAM automatically parses the logs and creates a dataset with the name
<Vendor>_< Product>_raw. You can then use XQL Search queries to view logs and create new Correlation rules.

To set up an HTTP log collector to receive logs from an external source.

1. Create an HTTP Log collector in Cortex XSIAM.

a. Select Settings → Configurations → Data Collection → Data Sources.

b. In the HTTP configuration, click Add Instance.

c. Specify a descriptive Name for your HTTP log collection configuration.

d. Select the data object Compression, either gzip or uncompressed.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 706/1003
5/8/24, 9:18 AM PDF Export

e. Select the Log Format as Raw, JSON, CEF, or LEEF.

Cortex XSIAM supports logs in single line format or multiline format. For a JSON format, multiline logs are collected automatically when the Log
Format is configured as JSON. When configuring a Raw format, you must also define the Multiline Parsing Regex as explained below.

NOTE:

-The Vendor and Product defaults to Auto-Detect when the Log Format is set to CEF or LEEF.

-For a Log Format set to CEF or LEEF, Cortex XSIAM reads events row by row to look for the Vendor and Product configured in the logs. When
the values are populated in the event log row, Cortex XSIAM uses these values even if you specified a value in the Vendor and Product fields in
the HTTP collector settings. Yet, when the values are blank in the event log row, Cortex XSIAM uses the Vendor and Product that you specified in
the HTTP collector settings. If you did not specify a Vendor or Product in the HTTP collector settings, and the values are blank in the event log
row, the values for both fields are set to unknown.

f. Specify the Vendor and Product for the type of logs you are ingesting.

g. (Optional) Specify the Multiline Parsing Regex for logs with multilines.

This option is only displayed when the Log Format is set to Raw, so you can set the regular expression that identifies when the multiline event starts
in logs with multilines. It is assumed that when a new event begins, the previous one has ended.

h. Save & Generate Token.

Click the copy icon next to the key and record it somewhere safe. You will need to provide this key when you configure your HTTP POST request
and define the api_key. If you forget to record the key and close the window you will need to generate a new key and repeat this process.

Click Done when finished.

2. Send data to your Cortex XSIAM HTTP log collector.

a. Send an HTTP POST request to the URL for your HTTP Log Collector.

You can view a sample curl or python request on an HTTP collector instance by selecting View Example.

Here is a CURL example:

curl -X POST https://api-{tenant external URL}/logs/v1/event -H 'Authorization: {api_key}' -H 'Content-Type: text/plain' -d '{"example1": "test", "timestamp":
1609100113039}
{"example2": [12321,546456,45687,1]}'

Python 3 example:

import requests
def test_http_collector(api_key):
headers = {
"Authorization": api_key,
"Content-Type": "text/plain"
}
# Note: the logs must be separated by a new line
body = "{'example1': 'test', 'timestamp': 1609100113039}" \
"{'example2': [12321,546456,45687,1]}"
res = requests.post(url="https://api-{tenant external URL}/logs/v1/event",
headers=headers,
data=body)
return res

b. Substitute the values specific to your configuration.

url—You can copy the URL for your HTTP log collector from the Custom Collectors page. For example: https://api-{tenant external
URL}/logs/v1/event.

Authorization—Paste the api_key you previously recorded for your HTTP log collector, which is defined in the header.

Content-Type—Depending on the data object format you selected during setup, this will be application/json for JSON format or
text/plain for Text format. This is defined as part of the header.

Body—The body contains the records you want to send to Cortex XSIAM . Separate records with a \n (new line) delimiter. The request body
can contain up to 10Mib records although 1 Mib is recommended. In the case of a curl command, the records are contained in the -d
‘<records>’ parameter.

c. Review the possible success and failure code responses to your HTTP Post requests.

The following table provides the various success and failure code responses to your HTTP Post requests, which can help you troubleshoot any
problems with your HTTP Collector configuration.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 707/1003
5/8/24, 9:18 AM PDF Export

Success/Failure Response Code Description Output Code Displayed (If Applicable)

{ "error": "false"}
200 Success code that indicates there are no errors and
the request was successful.

401 Unauthorized error code that indicates either an

incorrect authorization token is being used or that the
HTTP Collector is deleted/disabled.

404 Error code 404 page not found that indicates a wrong
URL.

413 Error code indicating the payload is too large as the

request size limit is 10 MB.

{ "error": "error processing request, error:

500 Error code indicating the request was not able to be failed to process the request"}
processed due to an incorrect log format between
the request and the HTTP collector configuration.

429 Error code indicating too many requests as the rate

limit is 400 requests per second per customer per
endpoint.

3. Monitor your HTTP Log Collection integration.

You can return to the Settings → Configurations → Data Collection → Data Sources page to monitor the status of your HTTP Log Collection configuration.
For each instance, Cortex XSIAM displays the number of logs received in the last hour, day, and week. You can also use the Data Ingestion Dashboard to
view general statistics about your data ingestion configurations.

4. After Cortex XSIAM begins receiving logs, use the XQL Search to search your logs.

8.4.7.9 | Ingest Logs from BeyondTrust Privilege Management Cloud

Abstract

Extend Cortex XSIAM visibility into logs from BeyondTrust Privilege Management Cloud.

If you use BeyondTrust Privilege Management Cloud, you can take advantage of Cortex XSIAM investigation and detection capabilities by forwarding your logs
to Cortex XSIAM . This enables Cortex XSIAM to help you expand visibility into computer, activity, and authorization requests in the organization, correlate and
detect access violations, and query BeyondTrust Endpoint Privilege Management logs using XQL Search.

As soon as Cortex XSIAM starts to receive logs, Cortex XSIAM can analyze your logs in XQL Search and you can create new Correlation Rules.

To integrate your logs, you first need to configure SIEM settings and an AWS S3 Bucket according to the specific requirements provided by BeyondTrust. You
can then configure data collection in Cortex XSIAM by configuring an Amazon S3 data collector for a generic log type using the Beyondtrust Cloud ECS log
format.

Before you begin configuring data collection verify that you are using BeyondTrust Privilege Management Cloud version 21.6.339 or later.

Configure BeyondTrust Privilege Management Cloud collection in Cortex XSIAM.

1. Configure SIEM settings and an AWS S3 Bucket according to the requirements provided in the BeyondTrust documentation.

Ensure that when you add the AWS S3 bucket in the PMC and set the SIEM settings, you select ECS - Elastic Common Schema as the SIEM Format.

2. Configure BeyondTrust logs collection with Cortex XSIAM using an Amazon S3 data collector for generic data.

Ensure your Amazon S3 data collector is configured with the following settings.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 708/1003
5/8/24, 9:18 AM PDF Export

Log Type—Select Generic to configure your log collection to receive generic logs from Amazon S3.

Log Format—Select the log format type as Beyondtrust Cloud ECS.

NOTE:

For a Log Format set to Beyondtrust Cloud ECS, the following fields are automatically set and not configurable.

Vendor—Beyondtrust

Product—Privilege Management

Compression—Uncompressed

3. After Cortex XSIAM begins receiving data from BeyondTrust Privilege Management Cloud, you can use XQL Search to search your logs using the
beyondtrust_privilege_management_raw dataset that you configured when setting up your Amazon S3 data collector.

8.4.7.10 | Ingest Logs and Data from Box

Abstract

Ingest logs and data from Box enterprise accounts via the Box REST APIs.

Cortex XSIAM can ingest different types of data from Box enterprise accounts using the Box data collector. To receive logs and data from Box enterprise
accounts via the Box REST APIs, you must configure the Data Sources settings in Cortex XSIAM based on your Box enterprise account credentials. After you
set up data collection, Cortex XSIAM begins receiving new logs and data from the source.

When Cortex XSIAM begins receiving logs, the app creates a new dataset for the different types of data that you are collecting, which you can use to initiate
XQL Search queries. For example queries, refer to the in-app XQL Library. For all logs, Cortex XSIAM can raise Cortex XSIAM alerts (Analytics, Correlation
Rules, IOC, and BIOC), when relevant from Box logs. While Correlation Rules alerts are raised on non-normalized and normalized logs, Analytics, IOC, and
BIOC alerts are only raised on normalized logs.

The following table provides a brief description of the different types of data you can collect, the collection method and fetch interval for new data collected, the
name of the dataset to use in Cortex XSIAM to query the data using XQL Search, and whether the data is normalized.

NOTE:

The Fetch Intervals are non-configurable.

Type Of Data Description Collection Method Fetch Interval Dataset Name Normalized Data

Events and security alerts

Events Retrieves events related to Appends data 60 seconds box_admin_logs_raw When relevant, Cortex XSIAM
(admin_logs) file/folder management, normalizes SaaS audit event
permission changes, access logs into stories, which are
and login activities, user/groups collected in a dataset
management, folder called saas_audit_logs.
collaboration, file/folder
sharing, security settings
changes, tasks, permission
changes on folders, storage
expiration and data retention,
and workflows.

Box Shield Retrieves security alerts related Appends data 60 seconds box_shield_alerts_raw —
Alerts to suspicious locations,
suspicious sessions,
anomalous download, and
malicious content.

NOTE:

Collecting Box Shield Alerts

requires implementing Box
Shield,

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 709/1003
5/8/24, 9:18 AM PDF Export

Type Of Data Description Collection Method Fetch Interval Dataset Name Normalized Data

Directory and metadata

Users Lists user data. Overwrites data 10 minutes box_users_raw —

Groups Lists user group data. Overwrites data 10 minutes box_groups_raw —

Be sure you do the following tasks before you begin configuring data collection from Box to Cortex XSIAM.

1. Set up an Enterprise Box plan.

IMPORTANT:

To collect Box Shield Alerts, you must purchase Box Shield and it must be enabled on Box enterprise.

2. Create a valid Box account that is assigned to a role with sufficient permissions for the data you want to collect. For example, create an account assigned
to an Admin role to enable Cortex XSIAM to collect all metadata for all files, folders, and enterprise events for the entire organization.

3. Enable two-factor authentication for the Box account. For more information, see the Box documentation.

Configure Cortex XSIAM to receive logs and data from Box.

1. Complete the prerequisite steps for your Box enterprise account.

2. Create a new app in your Box account.

a. Log in to your Box account, and in the Dev Console, click Create New App.

b. Select Custom App.

c. Set these settings in the Custom App dialog:

Select Server Authentication (Client Credentials Grant).

Specify an App Name.

Click Create App.

The new app is created and the opened in the Configuration tab.

d. In the Configuration tab of the new app, scroll down to the following sections and configure the app.

In the App Access Level section, select App + Enterprise Access.

In the Application Scopes section, set the following Administrative Action permissions depending on the type of data you want to collect.

Administrative Action Data Type

Manage users Users

Manage groups Groups

NOTE:

There is a current bug with the Groups API from Box. If you don't configure the Box app with the proper
permissions for managing groups data, the Groups API from Box won't return an error message to Cortex
XSIAM indicating that the API failed to receive the data, and the Groups data will not be collected.

Manage enterprise Events (admin_logs)

properties
Box Shield Alerts

Once completed, scroll up in the tab to Save Changes.

e. In the Authorization tab, click Review and Submit to send your changes to the administrator for approval.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 710/1003
5/8/24, 9:18 AM PDF Export

In the Review App Authorization Submission dialog that is displayed, you can add a Description of the app changes, and then click Submit.

3. Ensure the new app changes are approved by an administrator in the Admin Console of the Box account.

a. Select Apps → Customer Apps Manager → Server Authentication Apps.

b. In the table, look for the Name of the Box app with the changes, where the Authorization Status is set to Pending Authorization, and select the three-
dot menu → Authorize App.

c. Click Authorize.

NOTE:

For any future change that you make to your Box app, ensure that you send the changes for approval to the administrator, who will need to approve
them as explained above.

4. In Cortex XSIAM, select Settings → Data Sources.

5. In the Box configuration, click Add Instance to begin a new configuration.

6. Set the following parameters, where some values require you to log in to your Box account to copy and paste the values to the applicable fields:

Name—Specify a descriptive name for this Box instance.

Enterprise ID—Specify the unique identifier for your organization's Box instance, which is used to access the token request. This field can't be
edited once the Box data collector instance is created.

You can retrieve this value from your Box account in the the General Settings tab, and scrolling to the App Info section. Copy the Enterprise ID and
paste it in this field in Cortex XSIAM.

Client ID—Specify the client ID or API key for the Box app you created.

You can retrieve this value from your Box account in the Configuration tab, and scrolling down to the OAuth 2.0 Credentials section. COPY the
Client ID and paste it into this field in Cortex XSIAM.

Client Secret—The client secret or API secret fort he Box app you created.

You can retrieve this value from your Box account in the Configuration tab, and scrolling down to the OAuth 2.0 Credentials section. Click Fetch
Client Secret, where you will need to authenticate yourself according to the two-factor authentication method defined in your Box app before the
Client Secret is displayed. Copy this value and paste it in this field in Cortex XSIAM.

Collect—Select the types of data you want to collect from Box. All the options are selected by default.

Events and security alerts

Events (admin_logs)—Collects events related to file/folder management, permission changes, access and login activities, user/groups
management, folder collaboration, file/folder sharing, security settings changes, tasks, permission changes on folders, storage
expiration and data retention, and workflows.

Box Shield Alerts—Collects security alerts related to suspicious locations, suspicious sessions, anomalous download, and malicious
content.

Directory and metadata

NOTE:

Inventory data snapshots are collected every 10 minutes.

Users—Collects user data.

Groups—Collects user group data.

7. Test the connection settings.

8. If successful, Enable Box log collection.

Once events start to come in, a green check mark appears underneath the Box configuration.

8.4.7.11 | Ingest Logs and Data from Dropbox

Abstract

Ingest logs and data from Dropbox Business accounts via the Dropbox Business API.

Cortex XSIAM can ingest different types of data from Dropbox Business accounts using the Dropbox data collector. To receive logs and data from Dropbox
Business accounts via the Dropbox Business API, you must configure the Data Sources settings in Cortex XSIAM based on your Dropbox Business Account
credentials. After you set up data collection, Cortex XSIAM begins receiving new logs and data from the source.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 711/1003
5/8/24, 9:18 AM PDF Export

When Cortex XSIAM begins receiving logs, the app creates a new dataset for the different types of data that you are collecting, which you can use to initiate
XQL Search queries. For example queries, refer to the in-app XQL Library. For all logs, Cortex XSIAM can raise Cortex XSIAM alerts (Analytics, Correlation
Rules, IOC, and BIOC), when relevant from Dropbox Business logs. While Correlation Rules alerts are raised on non-normalized and normalized logs, Analytics,
IOC, and BIOC alerts are only raised on normalized logs.

The following table provides a brief description of the different types of data you can collect, the collection method and fetch interval for new data collected, the
name of the dataset to use in Cortex XSIAM to query the data using XQL Search, and whether the data is normalized.

NOTE:

The Fetch Interval is non-configurable.

Type Of Data Description Collection Method Fetch Interval Dataset Name Normalized Data

Log collection

Events Retrieves team events, including Appends data 60 seconds dropbox_events_raw When relevant, Cortex
access events, administrative XSIAM normalizes SaaS
events, file/folders events, security audit event logs into
settings events, and more. stories, which are
collected in a dataset
team_log/get_events called saas_audit_logs.

Directory and metadata

Member Lists all device sessions of a team. Overwrites data 10 minutes dropbox_members_devices_raw —
Devices
team/devices/list_members_devices

Users Lists members of a group. Overwrites data 10 minutes dropbox_users_raw —

team/members/list_v2

Groups Lists groups on a team. Overwrites data 10 minutes dropbox_groups_raw —

team/groups/list

Be sure you do the following tasks before you begin configuring data collection from Dropbox Business to Cortex XSIAM.

1. Set up an Advanced Dropbox plan.

2. Create a Dropbox Business admin account with Security admin permissions, which is required to authorize Cortex XSIAM to access the Dropbox
Business account and generate the OAuth 2.0 access token.

Configure Cortex XSIAM to receive logs and data from Dropbox.

1. Complete the prerequisite steps for your Dropbox Business account.

2. Log in to Dropbox using an admin account designated with Security admin level permissions.

3. In the Dropbox App console, ensure that you either create a new app, or your existing app is created, with the following settings:

Choose an API—Select Scoped access.

Choose the type of access you need—Select Full dropbox for access to all files and folders in a user's Dropbox.

4. In the Permissions tab of your app, ensure that the applicable permissions are selected under the relevant section heading for the type of data you want to
collect:

Section Heading Permission Data To Collect

Account Info account_info.read All types of data

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 712/1003
5/8/24, 9:18 AM PDF Export

Section Heading Permission Data To Collect

Team Data team_data.member All types of data

Members members.read Users

groups.read Groups

Sessions sessions.list Member Devices

events.read Events

5. In the Settings tab of your app, copy the App key and App secret , where you must click Show to see the App secret and record them somewhere safe.
You will need to provide these keys when you configure the Dropbox data collector in Cortex XSIAM.

6. In Cortex XSIAM, select Settings → Data Sources.

7. In the Dropbox configuration, click Add Instance to begin a new configuration.

8. Set the following parameters:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 713/1003
5/8/24, 9:18 AM PDF Export

Name—Specify a descriptive name for this Dropbox instance.

App Key—Specify the App key, which is taken from the Settings tab of your Dropbox app.

App Secret—Specify the App secret, which is taken from the Settings tab of your Dropbox app.

Access Code—After specifying an App Key, you can obtain the access code by hovering over the Access Code tooltip, clicking the here link, and
signing in with your Dropbox Business account credentials. The URL link is https://www.dropbox.com/oauth2/authorize?
client_id=%APP_KEY%&amp;token_access_type=offline&amp;response_type=code, where the %APP_KEY% is replaced with the App Key
value specified.

NOTE:

When the App Key field is empty, the here link in the tooltip is disabled. When an incorrect App Key is entered, clicking the link results in a 404
error.

To obtain the Access Code complete the following steps in the page that opens in your browser:

1. Read the disclaimer and click Continue.

2. Review the permissions listed, which should match the permissions you configured in your Dropbox app in the Permissions tab according to
the type of data you want to collect, and click Allow.

3. Copy the Access Code Generated and paste it in the Access Code field in Cortex XSIAM. The access code is valid for around 4 minutes from
when it is generated.

NOTE:

Whenever you change the permissions of the Dropbox app, we recommend that you generate a new Access Code for the Dropbox data collector
instance so that the permissions match the updates.

Collect—Select the types of data you want to collect from Dropbox. All the options are selected by default.

Log collection

Events (get_events}—Retrieves team events, including access events, administrative events, file/folders events, security settings
events and more.

NOTE:

Event data is collected every 60 seconds with a 10 minute lag time.

Directory and metadata

Member Devices—Collects all device sessions of a team.

Users—Collects all members of a group.

Groups—Collects all groups on a team.

NOTE:

Inventory data snapshots are collected every 10 minutes.

9. Test the connection settings.

10. If successful, Enable Dropbox log collection.

Once events start to come in, a green check mark appears underneath the Dropbox configuration.

8.4.7.12 | Ingest Logs from Elasticsearch Filebeat

Abstract

Cortex XSIAM can ingest logs from Elasticsearch Filebeat, a file system logger that logs file activity on your endpoints and servers.

If you want to ingest logs about file activity on your endpoints and servers and do not use the Cortex XDR agent, you can install Elasticsearch Filebeat as a
system logger and then forward those logs to Cortex XSIAM. To facilitate log ingestion, Cortex XSIAM supports the same protocols that Filebeat and
Elasticsearch use to communicate. Cortex XSIAM supports using Filebeat up to version 8.2 with the Filebeat data collector. Cortex XSIAM also supports logs in
single line format or multiline format. For more information on handling messages that span multiple lines of text in Elasticsearch Filebeat, see Manage Multiline
Messages.

Cortex XSIAM supports all sections in the filebeat.yml configuration file, such as support for Filebeat fields and tags. As a result, this enables you to use the
add_fields processor to identify the product/vendor for the data collected by Filebeat so the collected events go through the ingestion flow (Parsing Rules). To
configure the product/vendor ensure that you use the default fields attribute, as opposed to the target attribute, as shown in the following example.

processors:
- add_fields:
fields:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 714/1003
5/8/24, 9:18 AM PDF Export

vendor: <Vendor>
product: <Product>

To provide additional context during investigations, Cortex XSIAM automatically creates a new Cortex Query Language (XQL) dataset from your Filebeat logs.
You can then use the XQL dataset to search across the logs Cortex XSIAM received from Filebeat.

To receive logs, you configure collection settings for Filebeat in Cortex XSIAM and output settings in your Filebeat installations. As soon as Cortex XSIAM
begins receiving logs, the data is visible in XQL Search queries.

1. In Cortex XSIAM , set up Data Collection.

a. Select Settings → Configurations → Data Collection → Data Sources.

b. In the Filebeat configuration, click Add Instance.

c. Specify a descriptive Name for your Filebeat log collection configuration.

d. Specify the Vendor and Product for the type of logs you are ingesting.

The vendor and product are used to define the name of your XQL dataset (<vendor>_<product>_raw). If you do not define a vendor or product,
Cortex XSIAM examines the log header to identify the type and uses that to define the vendor and product in the dataset. For example, if the type is
Acme and you opt to let Cortex XSIAM determine the values, the dataset name would be acme_acme_raw.

e. Save & Generate Token.

Click the copy icon next to the key and record it somewhere safe. You will need to provide this key when you set up output settings on your Filebeat
instance. If you forget to record the key and close the window you will need to generate a new key and repeat this process.

2. Set up Filebeat to forward logs.

After installing the Filebeat agent, configure an Elasticsearch output:

a. Under the output.elasticsearch section, configure the following entities:

hosts—Copy the API URL from your Filebeat configuration and paste it in this field.

compression_level—5 (recommended)

bulk_max_size—1000 (recommended)

api_key—Paste the key you created in when you configured Filebeat Log Collection in Cortex XSIAM.

proxy_url—(Optional) <server_ip>:<port_number>. You can specify your own <server_ip> or use the Broker VM to proxy Filebeat
communication using the format <Broker_VM_ip>:<port_number>. When using the Broker VM, ensure that you activate the Local Agent
Settings applet with the Agent Proxy enabled.

b. Save the changes to your output file.

After Cortex XSIAM begins receiving logs from Filebeat, they will be available in XQL Search queries.

3. (Optional) Monitor your Filebeat integration.

You can return to the Settings → Configurations → Data Collection → Data Sources page to monitor the status of your Filebeat configuration. For each
instance, Cortex XSIAM displays the number of logs received in the last hour, day, and week. You can also use the Data Ingestion Dashboard to view
general statistics about your data ingestion configurations.

4. (Optional) Set up alert notifications to monitor the following events.

A Filebeat agent status changes to disconnected.

A Filebeat module has stopped sending logs.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 715/1003
5/8/24, 9:18 AM PDF Export

8.4.7.13 | Ingest Logs from Forcepoint DLP

Abstract

Extend Cortex XSIAM visibility into logs from Forcepoint DLP.

If you use Forcepoint DLP to prevent data loss over endpoint channels, you can take advantage of Cortex XSIAM investigation and detection capabilities by
forwarding your logs to Cortex XSIAM. This enables Cortex XSIAM to help you expand visibility into data violation by users and hosts in the organization,
correlate and detect DLP incidents, and query Forcepoint DLP logs using XQL Search.

As soon as Cortex XSIAM starts to receive logs, Cortex XSIAM can analyze your logs in XQL Search and you can create new Correlation Rules.

To integrate your logs, you first need to set up an applet in a Broker VM within your network to act as a Syslog Collector. You then configure forwarding on your
log devices to send logs to the Syslog Collector in a CEF or LEEF format.

Configure Forcepoint DLP collection in Cortex XSIAM.

1. Verify that your Forcepoint DLP meet the following requirements.

Must use version 8.8.0.347 or a later release.

On premise installation only.

2. Activate the Syslog Collector applet on a Broker VM in your network.

Ensure the Broker VM is configured with the following settings.

Format—Select either a CEF or LEF Syslog format.

Vendor—Specify the Vendor as forcepoint.

Product—Specify the Product as dlp_endpoint.

3. Increase log storage for Forcepoint DLP logs.

As an estimate for initial sizing, note the average Forcepoint DLP log size. For proper sizing calculations, test the log sizes and log rates produced by your
Forcepoint DLP. For more information, see Manage Your Log Storage.

4. Configure the log device that receives Forcepoint DLP logs to forward syslog events to the Syslog Collector in a CEF or LEEF format.

For more information, see the Forcepoint DLP documentation.

5. After Cortex XSIAM begins receiving data from Forcepoint DLP, you can use XQL Search to search your logs using the forcepoint_dlp_endpoint
dataset.

8.4.7.14 | Ingest Logs from Proofpoint Targeted Attack Protection

Abstract

Ingest logs from Proofpoint Targeted Attack Protection (TAP).

To receive logs from Proofpoint Targeted Attack Protection (TAP), you must first configure TAP service credentials in the TAP dashboard, and then the Collection
Integrations settings in Cortex XSIAM based on your Proofpoint TAP configuration. After you set up data collection, Cortex XSIAM begins receiving new logs and
data from the source.

When Cortex XSIAM begins receiving logs, the app creates a new dataset (proofpoint_tap_raw) that you can use to initiate XQL Search queries. For example
queries, refer to the in-app XQL Library.

Configure the Proofpoint TAP collection in Cortex XSIAM.

1. Generate TAP Service Credentials in Proofpoint TAP.

TAP service credentials can be generated in the TAP Dashboard, where you will receive a Proofpoint Service Principal for authentication and Proofpoint
API Secret for authentication. Record these credentials as you will need to provide them when configuring the Proofpoint Targeted Attack Protection data
collector in Cortex XSIAM. For more information on generating TAP service credentials, see Generate TAP Service Credentials.

2. Configure the Proofpoint TAP collection in Cortex XSIAM.

a. Select Settings → Configurations → Data Collection → Data Sources.

b. In the Proofpoint Targeted Attack Protection configuration, click Add Instance to begin a new configuration.

c. Set these parameters.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 716/1003
5/8/24, 9:18 AM PDF Export

Name—Specify a descriptive name for your log collection configuration.

Proofpoint Endpoint—All Proofpoint endpoints are available on the tap-api-v2.proofpoint.com host. You can leave the default
configuration or specify another host.

Service Principal—Specify the Proofpoint Service Principal for authentication. TAP service credentials can be generated in the TAP
Dashboard.

API Secret—Specify the Proofpoint API Secret for authentication. TAP service credentials can be generated in the TAP Dashboard.

d. Click Test to validate access, and then click Enable.

Once events start to come in, a green check mark appears underneath the Proofpoint Targeted Attack Protection configuration with the amount of
data received.

3. (Optional) Manage your Proofpoint Targeted Attack Protection data collector.

After you enable the Proofpoint Targeted Attack Protection data collector, you can make additional changes as needed.

You can perform any of the following.

Edit the Proofpoint Targeted Attack Protection data collector settings.

Disable the Proofpoint Targeted Attack Protection data collector.

Delete the Proofpoint Targeted Attack Protection data collector.

8.4.7.15 | Ingest Logs and Data from Salesforce.com

Abstract

Use the Cortex XSIAM data collector to collect Audit Trail and Security Monitoring event logs from Salesforce.com.

The Cortex XSIAM data collector can collect Audit Trail and Security Monitoring event logs from Salesforce.com. During setup of this data collector, you can
choose to accept the default collection settings, or exclude the collection of content metadata and accounts.

The Salesforce.com data collector fetches events, and objects and metadata, including:

Login history

Setup audit trail

Flow Execution events

Transaction Security events

Content Distribution events

Package Install events

You can create multiple Salesforce.com data collector instances in Cortex XSIAM, for different parts of your organization.

Data are intentionally collected with a delay, to ensure that all the logs have been collected (to mitigate the effects of lags on the Salesforce.com side).

When Cortex XSIAM begins receiving logs, it creates new datasets for them, called salesforce_<object>_raw. Examples of <object> include:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 717/1003
5/8/24, 9:18 AM PDF Export

connectedapplication

permissionset

profile

groupmember

group

user

userrole

document

contentfolder

attachment

contentdistribution

tenantsecuritylogin

useraccountteammember

tenantsecurityuserperm

account

audit

login

eventlogfile

You can use these datasets to perform XQL search queries. For example queries, refer to the in-app XQL Library.

Prerequisites

To manage collection integration in Cortex XSIAM, ensure that you have the privilege to View/Edit Log Collections (for example, Instance Administrator).

To avoid errors, the minimum required Salesforce.com editions are Professional Edition with API access enabled, or Enterprise Edition, or higher.

How to

To use the client credentials flow required for Salesforce.com–Cortex XSIAM integration, you must create a connected app for Cortex XSIAM in Salesforce.com,
and configure its OAuth settings and access policies. Following these activities, configure Cortex XSIAM.

NOTE:

For more detailed reference information, see Configure a Connected App for the OAuth 2.0 Client Credentials Flow.

Unlike other data collector setups, in this case, the setup includes obtaining an OAuth 2.0 code from Salesforce.com, and this code is only valid for 15
minutes. Therefore, make sure that you enable the data collector within 15 minutes of obtaining the authorization code.

Perform the following procedures in the order that they appear, below.

Task 1. Configure Salesforce Connected App

1. On the Setup page, in Quick Find, type App Manager.

2. Click New Connected App.

3. Enter a meaningful name for the connected application and for the API. For example, you could name it panw_cortex_integration.

4. Enter your email address. This address will be used to retrieve the Consumer Key and Consumer Secret.

5. Select the Enable OAuth Settings checkbox.

6. In Callback URL, type

https://login.salesforce.com/services/oauth2/callback

and

https://{tenant external URL}.paloaltonetworks.com/configuration/data-sources

on separate lines, where {tenant external URL} is the name of your tenant as it appears in the URL of your Cortex XSIAM tenant.

7. For OAuth Scopes, select Full access (full) and Perform requests at any time (refresh_token, offline_access).

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 718/1003
5/8/24, 9:18 AM PDF Export

8. In the next options after OAuth Scopes, ensure that only the following checkboxes are selected:

Require Secret for Web Server Flow

Require Secret for Refresh Token Flow

Enable Credentials Flow

9. Click Save, and then Continue.

Task 2. Retrieve the Consumer Key and Consumer Secret

Consumer Key will be used for client_id, and Consumer Secret will be used for client_secret in OAuth 2.0.

1. On the Setup page, in Quick Find, type App Manager.

2. Find your connected application (the one that you defined for Cortex XSIAM). In the last column, click the arrow button and then click View.

3. In the API (Enable OAuth Settings) area, click Manage Consumer Details.

4. When you are asked to verify your identity, open the email that Salesforce sent to you, and copy the verification code. Go back to the Salesforce Verify
Your Identity page, paste the code in the Verification Code box, and click Verify. One of the following will happen:

The Consumer Key and Consumer Secret will be sent to the email address that you configured earlier for the Cortex XSIAM connected app.

On the Salesforce Connected App Name page, the Consumer Details area will display the Consumer Key and Consumer Secret, and you will be
able to copy them from here when required in the following procedures.

Task 3. Configure the Refresh Token expiration policy

1. On the Setup page, in Quick Find, type App Manager.

2. Find your connected application (the one that you defined for Cortex XSIAM). In the last column, click the arrow button and then click Manage.

3. Click Edit Policies.

4. In the OAuth Policies area:

Under Permitted Users, select All users may self-authorize.

Choose your refresh token policy. We recommend: Expire refresh token if not used for _ Day(s). For example, select this option and set it for 7 days.

Task 4. Configure OAuth 2.0

Configure the OAuth 2.0 application to call the Salesforce.com API using client_id and client_secret.

References: https://help.salesforce.com/s/articleView?id=sf.remoteaccess_oauth_client_credentials_flow

Task 5. Configure Cortex XSIAM

1. In Cortex XSIAM, create a Salesforce.com data collector instance:

Select Settings → Configurations → Data Collection → Data Sources.

In the Salesforce.com configuration, click Add Instance to begin a new configuration.

2. Enter a unique Name for the instance, enter the Salesforce Domain Name, and the Consumer Key and the Consumer Secret credentials obtained earlier
in this workflow. For example, the domain could be the API URL from which logs are received, such as
https://MyDomainName.my.salesforce.com/services/data/vXX.X/resource/

3. (Optional) Clear options that you do not require:

Content metadata: when selected (default), collects documents’ metadata.

Accounts: when selected (default), collects account objects.

NOTE:

When these options are cleared, only these data types will be omitted from collection. All other data will be collected as usual.

4. Click Enable. A popup which redirects you to your Salesforce instance appears, to get OAuth 2.0 authorization credentials and access.

5. Click OK.

In Salesforce.com, a new tab appears.

6. Enter your username and password, and Log In.

7. When you are asked to allow access, select Allow.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 719/1003
5/8/24, 9:18 AM PDF Export

A Salesforce data collection instance is created, and an authorization token is created and returned to Cortex XSIAM. Data collection begins.

Task 6. (Optional) Edit or test existing Salesforce.com collector settings

You can edit and test an existing collector instance after a successful initial connection between Salesforce.com and Cortex XSIAM. Do this by clicking Edit
(pencil icon) for the collector instance. The log collection window will be displayed, where you can make changes or test, by clicking Test.

Troubleshooting

If for any reason, the token is not created and sent to Cortex XSIAM, after a timeout period, an authorization failure error will be returned for the collector
instance. In this case, try again by clicking Edit (pencil icon) for the collector instance. The log collection window will be displayed again, where you can edit
settings and retry getting the authorization code.

8.4.7.16 | Ingest Data from ServiceNow CMDB

Abstract

Extend Cortex XSIAM visibility into data from ServiceNow CMDB.

To receive data from the ServiceNow CMDB database, you must first configure data collection from ServiceNow CMDB. ServiceNow CMDB is a logical
representations of assets, services, and the relationships between them that comprise the infrastructure of an organization. It is built as a series of connected
tables that contain all the assets and business services controlled by a company and its configurations. You can configure the Collection Integration settings in
Cortex XSIAM for the ServiceNow CMDB database, which includes selecting the specific tables containing the data that you want to collect, in the ServiceNow
CMDB Collector. You can select from the list of default tables and also specify custom tables. By default, the ServiceNow CMDB Collector is configured to
collect data from the following tables, which you can always change depending on your system requirements.

cmdb_ci

cmdb_ci_computer

cmdb_rel_ci

cmdb_ci_application_software

As soon as Cortex XSIAM begins receiving data, the app automatically creates a ServiceNow CMDB dataset for each table using the format
servicenow_cmdb_<table name>_raw. You can then use XQL Search queries to view the data and create new Correlation Rules.

You can only configure a single ServiceNow CMDB Collector, which is automatically configured every 6 hours to reload the data from the configured tables and
replace the existing data. You can always use the Sync Now option to reload the data and replace the existing data whenever you want.

Complete the following task before you begin configuring Cortex XSIAM to receive data from ServiceNow CMDB.

Create a ServiceNow CMDB user with SNOW credentials, who is designated to access the tables from ServiceNow CMDB for data collection in Cortex
XSIAM. Record the credentials for this user as you will need them when configuring the ServiceNow CMDB Collector in Cortex XSIAM.

Configure Cortex XSIAM to receive data from ServiceNow CMDB.

1. Select Settings → Configurations → Data Collection → Data Sources.

2. In the ServiceNow CMDB Collector configuration, click Add Instance to begin a new configuration.

3. Set the following parameters.

Domain—Specify your ServiceNow CMDB domain URL.

User Name—Specify the username for your ServiceNow CMDB user designated in Cortex XSIAM.

Password—Specify the password for your ServiceNow CMDB user designated in Cortex XSIAM.

Tables—You can do any of the following actions to configure the tables whose data is collected from ServiceNow CMDB.

Select the tables from the list of default ServiceNow CMDB tables that you want to collect from. After each table selection, select to add the
table to the tables already listed below for data collection.

Specify any custom tables that you want to configure for data collection.

From the default list of tables already configured, you can delete any of them by hovering over the table and selecting the X icon.

4. Click Test to validate access, and then click Enable.

Once events start to come in, a green check mark appears underneath the ServiceNow CMDB Collector configuration with the data and time that the data
was last synced.

5. (Optional) Manage your ServiceNow CMDB Collector.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 720/1003
5/8/24, 9:18 AM PDF Export

After you enable the ServiceNow CMDB Collector, you can make additional changes as needed. To modify a configuration, select any of the following
options.

Edit the ServiceNow CMDB Collector settings.

Disable the ServiceNow CMDB Collector.

Delete the ServiceNow CMDB Collector.

Sync Now to get the latest data from the tables configured. The data is replaced automatically every 6 hours, but you can always get the latest data
as needed.

6. After Cortex XSIAM begins receiving data from ServiceNow CMDB, you can use the XQL Search to search for logs in the new datasets, where each
dataset name is based on the table name using the format servicenow_cmdb_<table name>_raw.

8.4.7.17 | Ingest Report Data from Workday

Abstract

Extend Cortex XSIAM visibility into reports data from Workday.

To receive Workday report data, you must first configure data collection from Workday using a Workday custom report to ingest the appropriate data. This is
configured by setting up a Workday Collector in Cortex XSIAM and configuring report data collection via this Workday custom report that you set up.

As soon as Cortex XSIAM begins receiving data, the app automatically creates a Workday Cortex Query Language (XQL) dataset (workday_workday_raw).
You can then use XQL Search queries to view the data and create new Correlation Rules. In addition, Cortex XSIAM adds the workday fields next to each user
in the Key Assets list in the Incident View, and in the User node in the Causality View of Identity Analytics alerts.

NOTE:

Any user with permissions to view alerts and incidents can view the Workday data.

You can only configure a single Workday Collector, which is automatically configured to run the report every 6 hours. You can always use the Sync Now option
to run the report whenever you want.

Complete the following tasks before you begin configuring Cortex XSIAM to receive report data from Workday.

1. Create an Integration System User that is designated to access the custom report from Workday for data collection in Cortex XSIAM.

2. Create an Integration System Security Group for the Integration System User created in Step 1 for accessing the report. When setting this group ensure to
define the following.

Type of Tenanted Security Group—Select either Integration System Security Group (Constrained) or Integration System Security Group
(Unconstrained) depending on how your data is configured. For more information, see the Workday documentation.

Integration System User—Select the user that you defined in step 1 for accessing the custom report.

3. Create the Workday credentials for the Integration System User created in Step 1 so that the username and password can be used to access the report in
Cortex XSIAM. Record these credentials as you will need them when configuring the Workday Collector in Cortex XSIAM.

NOTE:

For more information on completing any of these prerequisite steps, see the Workday documentation.

Configure Cortex XSIAM to receive report data from Workday.

1. Configure a Workday custom report to use for data collection.

a. Login to the Workday Resource Center.

b. In the search field, specify Create Custom Report to open the wizard.

c. Configure the following Create Custom Report settings.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 721/1003
5/8/24, 9:18 AM PDF Export

Report Name—Specify the name of the report.

Report Details section.

Report Type—Select Advanced. When you select this option, the Enable As Web Service checkbox is displayed.

Enable As Web Service—Select this checkbox, so that you will be able to generate a URL of the report to configure in Cortex XSIAM.

Data Source section.

Optimized for Performance—Select whether the data should be optimized for performance. The way this checkbox is configured
determines the Data Source options available to choose from.

Date Source—Select the applicable data source containing the data that is used to configure data collection from Workday to Cortex
XSIAM.

d. Click OK, and configure the following Additional Info settings.

The Additional Info table in the Columns tab is where you can perform the following.

For the incident and card views in Cortex XSIAM , map the required fields from the Data Source configured by selecting the applicable Field
that you want to map to the Cortex XSIAM field name required for data collection in the Column Heading Override XML Alias column.

(Optional) You can map any additional fields from the Data Source configured that you want to be able to query in XQL Search using the
workday_workday_raw dataset. This is configured by selecting the applicable Field and leaving the default field name that is displayed in the
Column Heading Override XML Alias column. This default field name is what is used in XQL Search and the dataset to view and query the
data.

NOTE:

The Business Object changes depending on the Data Source selected.

For the incident and card views in Cortex XSIAM, map the following fields in the table by selecting the applicable Field that contains the data
representing the Cortex XSIAM field name as provided below that should be added to the Column Heading Override XML Alias. For example, for
full_name, select the applicable Field from the Business Object defined that contains the full name of the user and in the Column Heading
Override XML Alias specify full_name to map the set Field to the Cortex XSIAM field name.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 722/1003
5/8/24, 9:18 AM PDF Export

NOTE:

Cortex XSIAM uses a structured schema when integrating Workday data. To get the best Analytics results, specify all the fields marked with an
asterisk from the recommended schema.

workday_user_id*

full_name*

workday_manager_user_id*

manager*

worker_type*

position_title*

department*

private_email_address*

business_email_address*

employment_start_date*

employment_end_date

phone_number

mailing_address

e. (Optional) Filter out any employees that you do not want included in the Filter tab.

f. Share access to the report with the designated Integration System User that you created by setting the following settings in the Share tab.

Report Definition Sharing Options—Select Share with specific authorized groups and users.

Authorized Users—Select the designated Integration System User that you created for accessing the custom report.

g. Ensure that the following Web Services Options settings in the Advanced tab are configured.

Here is an example of the configured settings, where the Web Service API Version and Namespace are automatically populated and dependent on
your report.

h. (Optional) Test the report to ensure all the fields are populated.

i. Get the URL for the report.

1. In the related actions menu, select Actions → Web Service → View URLs.

2. Click OK.

3. Scroll down to the JSON section.

4. Hover over the JSON link and click the icon, which open a new tab in your browser with the URL for the report. You need to use the
designated user credentials to open the report.

5. Copy the URL for the report and record them somewhere as this URL needs to be provided when setting up the Workday Collector in Cortex
XSIAM.

j. Complete the report by clicking Done.

2. Configure the Workday collection in Cortex XSIAM.

a. Select Settings → Configurations → Data Collection → Data Sources.

b. In the Workday Collector configuration, click Add Instance to begin a new configuration.

c. Set the following parameters.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 723/1003
5/8/24, 9:18 AM PDF Export

Name—Specify the name for the Workday Collector that is displayed in Cortex XSIAM.

URL—Specify the URL of the custom report you configured in Workday.

User Name—Specify the username for the designated Integration System User that you created for accessing the custom report in Workday.

Password—Specify the password for the designated Integration System User that you created for accessing the custom report in Workday.

d. Click Test to validate access, and then click Enable.

A notification appears confirming that the Workday Collector was saved successfully, and closes on its own after a few seconds.

Once report data starts to come in, a green check mark appears underneath the Workday Collector configuration with the data and time that the
data was last synced.

3. (Optional) Manage your Workday Collector.

After you enable the Workday Collector, you can make additional changes as needed. To modify a configuration, select any of the following options.

Edit the Workday Collector settings.

Disable the Workday Collector.

Delete the Workday Collector.

Sync Now to run the report to get the latest report data. The report is run automatically every 6 hours, but you can always get the latest data as
needed.

4. After Cortex XSIAM begins receiving report data from Workday, you can use the XQL Search to search for logs in the new dataset
(workday_workday_raw).

8.4.8 | Ingest External Alerts

Abstract

For a more complete and detailed picture of the activity involved in an incident, Cortex XSIAM can ingest alerts from any external source.

For a more complete and detailed picture of the activity involved in an incident, Cortex XSIAM can ingest alerts from any external source. Cortex XSIAM stitches
the external alerts together with relevant endpoint data and displays alerts from external sources in relevant incidents and alerts tables. You can also see
external alerts and related artifacts and assets in Causality views.

To ingest alerts from an external source, you configure your alert source to forward alerts (in Auto-Detect (default), CEF, LEEF, CISCO, or CORELIGHT format)
to the Syslog collector. You can also ingest alerts from external sources using the Cortex XSIAM APIs.

After Cortex XSIAM begins receiving external alerts, you must map the following required fields to the Cortex XSIAM format.

TIMESTAMP

SEVERITY

ALERT NAME

In addition, these optional fields are available, if you want to map them to the Cortex XSIAM format.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 724/1003
5/8/24, 9:18 AM PDF Export

SOURCE IP

SOURCE PORT

DESTINATION IP

DESTINATION PORT

DESCRIPTION

DIRECTION

EXTERNAL ID

CATEGORY

ACTION

PROCESS COMMAND LINE

PROCESS SHA256

DOMAIN

PROCESS FILE PATH

HOSTNAME

USERNAME

NOTE:

If you send pre-parsed alerts using the Cortex XSIAM API, additional mapping is not required.

Storage of external alerts is determined by your Cortex XSIAM tenant retention policy. For more information, seeDataset Management.

To ingest external alerts.

1. Send alerts from an external source to Cortex XSIAM.

There are two ways to send alerts:

API—Use the Insert CEF Alerts API to send the raw Syslog alerts or use the Insert Parsed Alerts API to convert the Syslog alerts to the Cortex
XSIAM format before sending them to Cortex XSIAM. If you use the API to send logs, you do not need to perform the additional mapping step in
Cortex XSIAM.

Activate the Syslog collector and then configure the alert source to forward alerts to the Syslog collector. Then configure an alert mapping rule as
follows.

2. In Cortex XSIAM, select Settings → Configurations → Data Collection.

3. Right-click the Vendor Product for your alerts and select Filter and Map.

4. Use the filters at the top of the table to narrow the results to only the alerts you want to map.

Cortex XSIAM displays a limited sample of results during the mapping rule creation. As you define your filters, Cortex XSIAM applies the filter to the
limited sample but does not apply the filters across all alerts. As a result, you might not see any results from the alert sample during the rule creation.

5. Click Next to begin a new mapping rule.

On the left, configure the following.

a. Rule Information-Define the NAME and optional DESCRIPTION to identify your mapping rule.

b. Alerts Field-Map each required and any optional Cortex XSIAM field to a field in your alert source.

If needed, use the field converter ( ) to translate the source field to the Cortex XSIAM syntax.

For example, if you use a different severity system, you need to use the converter to map your severities fields to the Cortex XSIAM risks of Critical,
High, Medium, and Low.

You can also use regex to convert the fields to extract the data to facilitate matching with the Cortex XSIAM format. For example, say you need to
map the port but your source field contains both the IP address and port (192.168.1.200:8080). To extract everything after the :, use the following
regex:

^[^:]*_

For additional context when you are investigating an incident, you can also map additional optional fields to fields in your alert source.

6. Submit your alert filter and mapping rule when finished.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 725/1003
5/8/24, 9:18 AM PDF Export

9 | Apps
Abstract

Integrate your familiar security analysis tools with the Cortex XSIAM primary data lake to support SOC investigation efforts.

Apps leverage Cortex XSIAM as a data lake with familiar applications that allow you to reuse skills, resources, and capabilities.

9.1 | Notebooks
Abstract

Leverage the data collected by Cortex XSIAM using Jupyter Notebooks' data analysis and visualization capabilities within your existing security infrastructure.

Cortex XSIAM Notebooks enable you to analyze and visualize the extensive data collected by Cortex XSIAM. Using Jupyter tools, you can build machine
learning models to visualize clusters, identify anomalies, and then feed your findings back into the Cortex XSIAM environment to generate security insights.

You can write Python code, run all or parts of it, and create visualizations of the data sanitation that show the results of the algorithms you ran.

Create customized analytics and bring your own machine learning models into Cortex XSIAM.

Utilize existing public resources.

Visualize analytics using existing libraries and applications.

Document, automate, and reuse hunting processes.

Use the existing data manipulation and visualization tools to identify patterns, anomalies, and trends in the data.

Automate the custom investigation process and make it available as part of an incident with actions like creating alerts and adding a comment to an
incident.

PREREQUISITE:

Cortex XSIAM Notebooks usage requires the following.

Cortex XSIAM Enterprise or Cortex XSIAM Enterprise Plus.

Apps and XQL RBAC permissions.

To use Notebooks, you must have the View/Edit permissions in Settings → Configurations → Acces Management → Roles → Apps → Jupyter.

To configure Notebooks, you must have the View/Edit permissions in Settings → Configurations → Acces Management → Roles →
Configurations → Apps.

To work in Notebooks, you must have the Application Service Account role.

When you create a Notebooks instance, the API key is assigned the App Service Account role by default. You can change the API key or the role
to match your activities.

A daily minimum of 1000 compute units. After activation, 1000 units are deducted every day at 00:00 UTC.

XQL and BQ queries performed in Cortex XSIAM Notebooks are calculated similarly to Compute Unit usage of XQL queries originating from public
APIs.

Every notebook you create is preconfigured with Cortex SDK access that enables you to query the data using Cortex Query Language.

NOTE:

You can only add one instance of Notebooks.

Cortex XSIAM Notebooks has access to approved sites on the internet when embedded in Cortex XSIAM.

The Notebooks instance includes restart options.

Create a Notebook inside Cortex XSIAM.

1. Select Settings → Configurations → Integrations → Apps.

2. Click the menu to the right of Notebooks and +Create Instance.

3. Specify an Instance Name and Add Instance.

Cortex XSIAM displays a notification that the instance is being prepared, which may take time. When completed, the instance is available in the navigation
menu under Apps.

To edit the Notebooks instance, from Settings → Configurations → Integrations → Apps, hover over the instance and select the edit icon. You can change the
name of the instance, create a new API key, or select an API key from the list.

To start working in your Notebooks instance, select it in the navigation menu under Apps.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 726/1003
5/8/24, 9:18 AM PDF Export

10 | Data Management
Abstract

Learn how to manage your datasets, create Parsing Rules, and manage XQL APIs in Cortex XSIAM.

10.1 | Dataset Management

Abstract

Learn more about managing your datasets and understanding your overall data storage, period based retention.

The Dataset Management page enables you to manage your datasets and understand your overall data storage duration for different retention periods and
datasets based on your hot and cold storage licenses, and retention add-ons that extend your storage. You can view details about your Cortex XSIAM licenses
and retention add-ons by selecting Settings → Cortex XSIAM License. For more information on license retention and the defaults provided per license, see
License Retention.

IMPORTANT:

Cortex XSIAM enforces retention on all log-type datasets excluding Host Inventory, Vulnerability Assessment, Metrics, and Users.

Hot and Cold Storage

Your current hot and cold storage licenses, including the default license retention and any additonal retention add-ons to extend storage, are listed within the Hot
Storage License and Cold Storage License sections of the Dataset Management page. Whenever you extend your license retention, depending on your
requirements and license add-ons for both hot storage and cold storage, the add-ons are listed.

Additional Hot Storage

You can expand your license retention to include flexible Hot Storage based retention to help accommodate varying storage requirements for different retention
periods and datasets. This add-on license is available to purchase based on your storage requirements for a minimum of 1,000 GB. If this license is purchased,
an Additional Storage subheading in the Hot Storage License section is displayed on the Dataset Management page with a bar indicating how much of the
storage is used.

NOTE:

Only datasets that are already handled as part of the GB license are supported for this license. In addition, the retention configuration is only available
in Cortex XSIAM, as opposed to the public APIs or configuration from the parent MSSP tenant.

Edit Retention Plan

On any dataset configured to use Additional Hot Storage, you can edit the retention period. This enables you to view the current retention details for hot and cold
storage and configure the retention. This includes setting the amount of flexible hot storage-based retention designated for a dataset and the priority for the
dataset's hot storage. This is used when the storage limit is exceeded to know the data most critical to preserve.

How to edit the retention plan

1. Select Settings → Configurations → Data Management → Dataset Management.

2. In the Datasets table, right-click any dataset designated with flexible hot storage, and select Edit Retention Plan.

3. Set the following parameters:

Additional hot storage: Set the amount of flexible hot storage-based retention designated for this dataset in months, where a month is calculated as
31 days.

Hot Storage Priority: Select the priority designated for this dataset's hot storage as either Low, Medium, or High. This is used when the storage limit
is exceeded. Data is first deleted from lowest to highest, and then from the oldest to latest timestamp.

4. Click Save.

Datasets Table

For each dataset listed in the table, the following information is available:

Read more...
NOTE:

Certain fields are exposed and hidden by default. An asterisk (*) is beside every field that is exposed by default.

Datasets include dataset permission enforcements in the Cortex Query Language(XQL), Query Center, and XQL Widgets. For example, to view or
access any of the endpoints and host_inventory datasets, you need role-based access control (RBAC) permissions to the Endpoint Administration
and Host Inventory views. Managed Security Services Providers (MSSP) administration permissions are not enforced on child tenants, but only on the
MSSP tenant.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 727/1003
5/8/24, 9:18 AM PDF Export

Field Description

*TYPE Displays the type of dataset based on the method used to upload the data. The possible values include: Correlation, Lookup, Raw,
Snapshot, System, and User. For more information on each dataset type, see Manage Datasets.

*LOG UPDATE Event logs are updated either continuously (Logs) or the current state is updated periodically (State) as detailed in the LAST
TYPE UPDATED column.

*LAST UPDATED Last time the data in the dataset logs were updated.

*ADDITIONAL Amount of flexible hot storage-based retention designated for this dataset in months, where a month is calculated as 31 days.
STORAGE

*TOTAL DAYS Actual number of days that the data is stored in the Cortex XSIAM tenant, which is comprised of the HOT RANGE + the COLD
STORED RANGE.

*HOT RANGE Details the exact period of the Hot Storage from the start date to the end date.

*COLD RANGE Details the exact period of the Cold Storage from the start date to the end date.

*TOTAL SIZE Actual size of the data that is stored in the Cortex XSIAM tenant. This number is dependent on the events stored in the hot storage.
STORED For the xdr_data dataset, where the first 31 days of storage are included with your license, the first 31 days are not included in the
TOTAL SIZE STORED number.

*ADDITIONAL Actual size of the additional flexible hot storage data that is stored in the Cortex XSIAM tenant in GB. This number is dependent on the
SIZE STORED events stored in the hot storage.

*AVERAGE Average daily amount stored in the Cortex XSIAM tenant. This number is dependent on the events stored in the hot storage.
DAILY SIZE

*HOT STORAGE Indicates the priority set for the dataset's hot storage as either Low, Medium, or High. This is used when the storage limit is exceeded.
PRIORITY Data is first deleted from lowest to highest, and then from the oldest to latest timestamp.

*TOTAL EVENTS Number of total events/logs that are stored in the Cortex XSIAM tenant. This number is dependent on the events stored in the hot
storage.

*AVERAGE Average size of a single event in the dataset (TOTAL SIZE STORED divided by the TOTAL EVENTS). This number is dependent on
EVENT SIZE the events stored in the hot storage.

*TTL For lookup datasets, displays the value of the time to live (TTL) configured for when lookup entries expire and are removed
automatically from the dataset.

Forever: The lookup entries never expire (default).

Custom: Enables setting when the lookup entries expire by configuring the number of Days, Hours, and Minutes. The maximum
number of days is 99999.

For more information, see Set time to live for lookup datasets.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 728/1003
5/8/24, 9:18 AM PDF Export

Field Description

DEFAULT Details whether the dataset is configured to use as your default query target in XQL Search, so when you write your queries you do not
QUERY TARGET need to define a dataset. By default, only the xdr_data dataset is configured as the DEFAULT QUERY TARGET and this field is set to
Yes. All other datasets have this field set to No. When setting multiple default datasets, your query does not need to mention any of the
dataset names, and Cortex XSIAM queries the default datasets using a join.

TOTAL HOT Total hot storage retention configured for the dataset in months, where a month is calculated as 31 days.
RETENTION

TOTAL COLD Total cold storage retention configured for the dataset in months, where a month is calculated as 31 days.
RETENTION

10.1.1 | Manage Datasets

Abstract

Learn how to import, delete, and interact with custom or third-party datasets in Cortex XSIAM.

Cortex XSIAM runs every Cortex Query Language (XQL) query against a dataset. A dataset is a collection of column:value sets. If you do not specify a dataset
in your query, Cortex XSIAM runs the query against the default datasets configured, which is by default xdr_data for a dataset query. The xdr_data dataset
contains all of the endpoint and network data that Cortex XSIAM collects. For a Cortex Data Model (XDM) query, unless specific datasets are specified, a query
will run against all mapped datasets. You can always change the default datasets using the set to default option. You can also upload datasets as a CSV, TSV,
or JSON file that contains the data you are interested in querying. These uploaded datasets are called lookup datasets.

To query other datasets, you have two options:

Set a dataset as default, which enables you to query the datasets without specifying them in the query.

Name a specific dataset at the beginning of your query with the dataset stage command.

Dataset types

The type of dataset is based on the method used to upload the data. The possible types include:

Correlation: A dataset containing data saved from a correlation rule.

Lookup: A dataset containing key-value pairs that can be used as a reference to correlate to events. For example, a user list with corresponding access
privileges. You can import or create a lookup dataset, and then reference the values for a certain key, run queries and take action. For more information,
see Lookup datasets.

Raw: Every dataset where PANW data is ingested out-of-the-box or third-party data is ingested using a configured dedicated collector.

Snapshot: A dataset that contains only the last successful snapshot of the data, such as Workday or ServiceNow CMDB tables.

System: Cortex XSIAM datasets that are created out-of-the-box.

User: If saved by a query using the target command, the Type can be either User or Lookup.

Datasets in XQL
IMPORTANT:

By default, forensic datasets are not included in XQL query results, unless the dataset query is explicitly defined to use a forensic dataset.

Cortex Query Language (XQL) supports using different languages for dataset and field names. In addition, when setting up your XQL query, it is important to
keep in mind the following:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 729/1003
5/8/24, 9:18 AM PDF Export

The dataset formats supported are dependent on the data retention offerings available in Cortex XSIAM according to whether you want to query hot
storage or cold storage.

Hot Storage queries are performed on a dataset using the format dataset = <dataset name>. This is the default option.

dataset = xdr_data

Cold Storage queries are performed using the format cold_dataset = <dataset name>.

cold_dataset = xdr_data

The refresh times for datasets, where all Cortex XSIAM system datasets, which are created out-of-the-box, are continuously ingested in near real-time as
the data comes in, except for the following:

endpoints: Refreshed every hour.

pan_dss_raw: Refreshed daily.

Forensics datasets: The Forensics data is not configured to be updated by default. When you enable a collection in the Agent Settings profile, the
data is collected only once unless you specify an interval. If you specify an interval, the data is collected every <interval> number of hours with
the minimum being 12.

Query against a dataset by selecting it with the dataset command when you create an XQL query.

After you query runs, you can always save your query results as a dataset. You can use the target stage command to save query results as a dataset.
For details about this command, see the XQL Language Reference guide.

Managing datasets in the Dataset Management page

You can manage your datasets in Cortex XSIAM from the Settings → Configurations → Data Management → Dataset Management page.

Here are some of the main tasks available for all dataset types by right-clicking a particular dataset listed in the Datasets table:

NOTE:

For more information on tasks specific to lookup datasets, see Lookup datasets.

View Schema

Select View Schema to view the schema information for every field found in the dataset result set in the Schema tab after running the query in XQL. Each
system field in the schema is written with an underscore (_) before the name of the field in the FIELD NAME column in the table.

Set as default

Select Set as default to query the dataset without having to specify it in your queries in XQL by typing dataset = <name of dataset>. Once configured, the
DEFAULT QUERY TARGET column entry for this dataset is set to Yes. By default, this option is not available when right-clicking the xdr_data dataset as this
dataset is the only dataset configured as the DEFAULT QUERY TARGET as it contains all of the endpoint and network data that Cortex XSIAM collects. Once
you Set as default another dataset, you can always remove it by right-clicking the dataset and selecting Remove from defaults. When setting multiple default
datasets, your query does not need to mention any of the dataset names, and Cortex XSIAM queries the default datasets using a join.

Copy text to clipboard

Select Copy text to clipboard to copy the name of the dataset to your clipboard.

10.1.2 | Lookup datasets

Abstract

Learn more about lookup datasets to correlate data from a data source with events in your environment.

Lookup datasets enable you to correlate data from a data source you provide with the events in your environment. For example, you can create a lookup with a
list of high-value assets, terminated employees, or service accounts in your environment. Use lookups in your search, detection rules, threat hunting, and
response playbooks. Lookups are stored as name-value pairs and are cached for optimal query performance and low latency.

Use case scenarios

Investigate threats and respond to incidents quickly with the rapid import of IP addresses, file hashes, and other data from CSV files. After you import the
data, use lookup name-value pairs for joins and filters in threat hunting and general queries.

Import business data as a lookup. For example, import user lists with privileged system access, or terminated employees. Then, use the lookup to create
allowlists and blocklists to detect or prevent those users from logging in to the network.

Create allowlists to suppress alerts from a group of users, such as users from authorized IP addresses that perform tasks that would normally trigger the
alert. Prevent benign events from becoming alerts.

Enrich event data. Use lookups to enrich your event data with name-value combinations derived from external data sources.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 730/1003
5/8/24, 9:18 AM PDF Export

How are lookup datasets created?

You can import or create a lookup dataset, and then reference the values for a certain key, run queries and take action. Lookup datasets are created by any of
the following methods:

Manual upload from a CSV, TSV, or JSON file to Cortex XSIAM from the Dataset Management page. For more information, see Import a lookup dataset.

Automatic upload by the Files and Folders Collector.

Query results are saved to a lookup dataset. If saved using the target stage, the Type can be either User or Lookup. For more information, see the
target stage in the XQL Language Reference Guide.

After a lookup a dataset is imported, you can always edit the dataset to update the data manually by right-clicking the dataset and selecting Edit.

10.1.2.1 | Import a lookup dataset

Abstract

Learn more about importing data from an external file to create or update a lookup dataset in Cortex XSIAM.

You can import data from CSV, TSV, or JSON files into Cortex XSIAM to create or update lookup datasets.

PREREQUISITE:

When uploading a CSV, TSV, or JSON file, ensure that the file meets the following requirements:

The maximum size for the total data to be imported into a lookup dataset is 30 MB.

Field names can contain characters from different languages, special characters, numbers (0-9), and underscores (_).

Field names can't exceed 128 characters.

Field names can't contain duplicate names, white spaces, or carriage returns.

The file doesn't contain a byte array (binary data) as it can't be uploaded.

1. Select Settings → Configurations → Data Management → Dataset Management → + Lookup.

2. Browse to your CSV, TSV, or JSON file. You can only upload a TSV file if it contains a .tsv file extension.

3. (Optional) Under Name, type a new name for the target dataset.

By default, Cortex XSIAM uses the name of the original file as the dataset name. You can change this name to something that will be more meaningful for
your users when they query the dataset. For example, if the original file name is mrkdptusrsnov23.json, you can save the dataset as
marketing_dept_users_Nov_2023.

Dataset names can contain special characters from different languages, numbers (0-9) and underscores (_). You can create dataset names using
uppercase characters, but in queries, dataset names are always treated as if they are lowercase.

IMPORTANT:

The name of a dataset created from a TSV file must always include the extension. For example, if the original file name is mrkdptusrsnov23.tsv, you
can save the dataset with the name marketing_dept_users_Nov_2023.tsv.

4. Replace the existing data in the dataset overwrites the data in an existing lookup dataset with the contents of the new file.

5. Click Add to add the file as a lookup.

6. After receiving a notification reporting that the upload succeeded, Refresh to view it in your list of datasets.

10.1.2.2 | Download JSON file of lookup dataset

Abstract

Learn more about downloading a lookup dataset as a JSON file.

You can only download a JSON file for a lookup dataset, where the Type set to Lookup on the Dataset Management page. This option is not available for any
other dataset type.

When you download a lookup dataset with field names in a foreign language, the downloaded JSON file displays the fields as COL_<randomstring> as
opposed to returning the fields in the foreign language as expected.

1. Open the Settings → Configurations → Data Management → Dataset Management page.

2. In the Datasets table, right-click the lookup dataset that you want to download as a JSON file, and select Download.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 731/1003
5/8/24, 9:18 AM PDF Export

10.1.2.3 | Set time to live for lookup datasets

Abstract

Learn more about setting the time to live (TTL) for lookup datasets in Cortex XSIAM.

You can specify when lookup entries expire and are removed automatically from the lookup dataset by configuring the time to live (TTL). The time period of the
TTL interval is based on when the data was last updated. The default is forever and the entries never expire. You can also configure a specific time according to
the days, hours, and minutes. Expired elements are removed from the lookup dataset by a scheduled job that runs every five minutes.

1. Open the Settings → Configurations → Data Management → Dataset Management page.

2. In the Datasets table, right-click the lookup dataset, and select Set TTL.

3. Select one of the following to configure when lookup dataset entries expire and are removed:

Forever: Lookup entries never expire (default).

Custom: Lookup entries expire according to a set number of days, hours, and minutes. The maximum number of days is 99999.

4. Click Save.

The TTL column in the Datasets table is updated with the changes and these changes are applied immediately on all existing lookup entries.

10.2 | Parsing Rules

Abstract

Learn more about Cortex XSIAM Parsing Rules.

NOTE:

Only a user with Cortex Account Administrator or Instance Administrator permissions can access Parsing Rules.

Cortex XSIAM includes an editor for creating 3rd party Parsing Rules, which enables you to:

Remove unused data that is not required for analytics, hunting, or regulation.

Reduce your data storage costs.

Pre-process all incoming data for complex rule performance.

Add tags to the ingested data as part of the ingestion flow.

Easily identify and resolve Parsing Rules errors so you can troubleshoot them quickly.

Test your Parsing Rules on actual logs and validate their outputs before implementation.

Parsing Rules contain the following built-in characteristics.

Parsing Rules are bound to a specific vendor and product.

Parsing Rules take raw log input, perform an arbitrary number of transitions and modifications to the data using Cortex Query Language (XQL), and return
zero, one, or more rows that are eventually inserted into the Cortex XSIAM tenant.

Parsing Rules can be grouped together by a no-match policy. If all the rules of a group did not produce an output for a specific log record, a no-match
policy defines what to do, such as drop the log or keep the log in some default format.

Upon ingestion, all fields are retained even fields with a null value. You can also use XQL to query parsing rules for null values.

10.2.1 | Parsing Rules Editor Views

Abstract

Learn about the Parsing Rules editor User Defined Rules, Default Rules, Both, and Simulate views.

NOTE:

Only a user with Cortex Account Administrator or Instance Administrator permissions can access Parsing Rules.

The Parsing Rules editor contains the following views:

NOTE:

When there are any Parsing Rules errors to report, the Parsing Rules editor displays these errors at the bottom of the editor in a section called List of Errors.
Otherwise, this section is not displayed. For more information, see Troubleshooting Parsing Rules Errors.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 732/1003
5/8/24, 9:18 AM PDF Export

User Defined (default)—Displays an editor for writing your own custom parsing rules that override or extend the default rules and a List of Errors section to
help you troubleshoot errors in your Parsing Rules.

Default Rules—Displays the parsing rules that are provided by default with Cortex XSIAM in read-only mode and a List of Errors section to view any errors
in your Parsing Rules.Any Parsing Rules that are included with your installed Content Packs from the Marketplace are also listed under Installed Rules.

Both—Side-by-side view of both the Default Rules and User Defined rules, so you can easily view the different rules on one screen. In addition, the List of
Errors section helps you troubleshoot any errors in your Parsing Rules.

Simulate—Enables you to test your Parsing Rules on actual logs and validate their outputs, which helps minimize your errors when creating Parsing
Rules. The editor includes the following sections.

User defined—A list of the current User defined rules on the left side of the window.

XQL Samples—A table of the existing Cortex Query Language (XQL) raw data samples on the right side of the window, which contain sample logs
listing the Vendor, Product, Raw Log, and Sample Time. For each Vendor and Product, up to 5 different samples are available to choose from. From
this list, you can select the logs used to simulate the rule.

Logs Output—Displays in a table format the following columns per dataset at the bottom of the window.

-Dataset—Displays the applicable dataset name and a line number associated to this dataset in the User defined section.

-Vendor—The vendor associated with this dataset.

-Product—The product associated with this dataset.

-Logs Output—Displays the output logs that are available based on your User defined rules and XQL Samples selected after simulating the results.
When there is no output log to display, the text Output logs is not available with the corresponding error message is displayed. When there is
no output due to a missing rule in the User defined section for the logs selected, the text No output logs. You can change your parsing rules and try
again is displayed.

-Input Logs—Displays the relevant input log with a right-click pivot to Show diff between the Output Logs and Input Logs.

10.2.2 | Parsing Rules File Structure and Syntax

Abstract

The Parsing Rules file consists of multiple sections of three types, which also represent the custom syntax specific to Parsing Rules.

NOTE:

Only a user with Cortex Account Administrator or Instance Administrator permissions can access Parsing Rules.

File Structure

The Parsing Rules file consists of multiple sections of these three types, which also represent the custom syntax specific to Parsing Rules.

INGEST—This section is used to define the resulting dataset.

COLLECT—(Optional) This section defines a rule that enables data reduction and data manipulation at the Broker VM to help avoid sending unnecessary
data to the Cortex XSIAM server and reduce traffic, storage, and computing costs. In addition, the COLLECT section is used to manipulate, alter, and enrich
the data before it’s passed to the Cortex XSIAM server. While this rule is optional to configure, once added this rule runs before the INGEST section.

CONST—(Optional) This section is used to define strings and numbers that can be reused multiple times within Cortex Query Language (XQL)
statements in other INGEST sections by using $constName.

RULE—(Optional) Rules are part of the XQL syntax, which are tagged with a name, and can be reused in the code in the INGEST sections by using
[rule:ruleName].

EXTEND—(Optional) This section is used to chain your Parsing Rules logic to extend your existing default RULE sections, which are added by a Content
Package you installed from the Marketplace. An EXTEND section runs immediately after the default RULE section that it extends and enables data
manipulation without overriding or interfering with the existing vendor Parsing Rules.

The order of the sections is unimportant. The data of each section type gets grouped together during the parsing stage. Before any action takes place all
COLLECT, CONST, RULE, EXTEND, and INGEST objects are grouped together and collected to the same list.

Syntax

The syntax used in the Parsing Rules file is derived from XQL, but with a few modifications. This subset of XQL is called XQL for Parsing (XQLp).

NOTE:

For more information on the XQL syntax, see Cortex XQL Language Reference.

The COLLECT, CONST, INGEST, RULE, and EXTEND syntax is derived from XQL, but with the following modifications for XQLp.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 733/1003
5/8/24, 9:18 AM PDF Export

A statement never starts with a dataset or preset selection. The query's data source is meaningless. It is transparent to the user where the raw logs are
coming from, fully handled by the system.

Only the following XQL stages are permitted: alter, fields, filter, and join. In addition, a new call stage is supported, which is used to invoke another rule.

NOTE:

The join stage is only supported in CONST, INGEST, and RULE sections and is not supported in a COLLECT section.

You cannot call a RULE section that exists in Default Rules from the User Defined Rules section.

Only the following XQL functions are permitted in all sections: parse timestamp, parse epoch, and regexcapture.

NOTE:

The regexcapture function is only supported in Parsing Rules and cannot be used in any other XQL query.

No output stages are supported.

A Rule object can only contain a single statement.

A join inner query is restricted to using a lookup as a data source and is only supported in XQLp stages.

There is no default lookup, so all join inner queries must start with dataset=<lookup> | ....

CONST reference ($MY_CONST) is supported.

An IN condition can only take a sequence list, such as device_name in (“device1”, “device2”, “device3”) and not another XQL or XQLp inner
queries.

Comments in C programming language can be used anywhere throughout the Parsing Rules file.

// line comment
/* inner comment */

NOTE:

Every statement in the Parsing Rules file must end with a semicolon (;).

10.2.2.1 | INGEST

Abstract

Understanding how to write a [INGEST] section in a Parsing Rules file and the syntax to use.

An INGEST section is used to define the resulting dataset. The COLLECT, CONST, and RULE sections are only add-ons, used to help organize the INGEST sections,
and are optional to configure. Yet, a Parsing Rules file that contains no INGEST sections, generates no Parsing Rules. Therefore, the INGEST section is
mandatory to configure.

INGEST syntax is derived from Cortex Query Language (XQL) with a few modifications as explained in the Parsing Rules syntax. In addition, INGEST sections
contain the following syntax add-ons.

INGEST sections can have more than one XQLp statement, separated by a semicolon (;). Each statement creates a different Parsing Rule.

The following XQL functions and stages are also supported in the INGEST section:

Functions—arrayfilter, arraycreate, arraymerge, and object_create.

Stages—iploc and arrayexpand.

Another new stage is available called drop.

drop takes a condition similar to the XQL filter stage (same syntax), but drops every log entry that passes that condition. One can think of it as a
negative filter, so drop <condition> is not equivalent to filter not <condition>.

drop can only appear last in a statement. No other XQLp rules can follow.

INGEST sections take parameters, and not names as RULE sections use, where some are mandatory and others optional.

[ingest:vendor=<vendor>, product=<product>, dataset=<dataset>, no_hit=<keep\drop>, ingestnull=<true\false>]

filter raw_log not contains "alert";

The parameter descriptions are explained in the following table.

Parameter Description

vendor The vendor that the specified Parsing Rules apply to (mandatory).

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 734/1003
5/8/24, 9:18 AM PDF Export

Parameter Description

product The product that the specified Parsing Rules apply to (mandatory).

dataset The name of the dataset to insert every row with the results after applying any of the specified Parsing Rules (mandatory).

no_hit No-match strategy to use for the entire specified group of rules (optional). The default is keep.

If no_hit = drop, then in a scenario where none of the rules in the group generates output for a given log record, that record is
discarded.

If no_hit = keep, then in a scenario where none of the rules in the group generates output for a given log record, that record is kept
in the _raw_log field. This record is inserted into the group's dataset once, but every column holds NULL except for _raw_log which
holds the original JSON log record.

ingestnull Defines whether null value fields are ingested (optional). By default this is set to true, so you only need to set this parameter when you want
to overwrite the default definition.

Each statement represents a different Parsing Rule in the same group as depicted in the following example.

[CONST]
DEVICE_NAME = "ngfw";
[rule:use_two_rules]
filter severity = "medium" | call basic_rule | call use_xql_and_another_rule;
[rule:basic_rule]
fields log_type, severity | filter log_type="eal" and severity="HIGH" and type="something";
[rule:use_xql_and_another_rule]call multiline_statement | filter severity = "medium";
[rule:multiline_statement]
alter url = json_extract(_raw_log, "$.url")
| join type = inner conflict_strategy = both (dataset=my_lookup) as inn url=inn.url
|filter severity = "medium";
[ingest:vendor=panw, product=ngfw, dataset=panw_ngfw_ds, no_hit=drop]
filter log_type="traffic" | alter url = json_extract(_raw_log, "$.url");
call use_two_rules | join type = inner conflict_strategy = both (dataset=my_lookup) as inn severity=inn.severity | fields severity, log_type | drop device_name = $DEVICE_NAME;

This generates 1 group of 2 Parsing Rules for panw/ngfw, where all the ingested data into panw_ngfw_ds dataset.

The following represents the syntax for the rules.

Rule #1:
filter log_type="traffic" | alter url = json_extract(_raw_log, "$.url");
Rule #2:
filter severity = "medium"
| fields log_type, severity
| filter log_type="eal" and severity="HIGH" and type="something"
| alter url = json_extract(_raw_log, "$.url")
| join type = inner conflict_strategy = both (dataset=my_lookup) as inn url=inn.url
| filter severity = "medium"
| filter severity = "medium"
| join type = inner conflict_strategy = both (dataset=my_lookup) as inn severity=inn.severity
| fields severity, log_type
| drop device_name = $DEVICE_NAME

A few more points to keep in mind when writing INGEST sections.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 735/1003
5/8/24, 9:18 AM PDF Export

INGEST parameter names are not case-sensitive. Therefore, vendor=PANW and vendor=panw are the same.

Since section order is unimportant, you do not have to declare a RULE or a CONST before using it in an INGEST section.

You can have multiple INGEST sections with the same vendor, product, dataset , and no_hit values. Yet, this can lead to unexpected results. Consider
the following example:

[ingest:vendor=panw, product=ngfw, dataset=panw_ngfw_ds, no_hit=keep]

filter raw_log not contains "alert";
[ingest:vendor=panw, product=ngfw, dataset=panw_ngfw_ds, no_hit=keep]
filter device_type not contains "agent";

Let lw be a log row. If lw.raw_log contains an alert and lw.device_type contains an agent, then lw is inserted twice into the pan_ngfw_ds dataset as
every section is standalone.

To eliminate these kind of errors and misunderstandings, it is highly advised to group all rules having the same vendor, product, dataset , and
no_hit values in a single INGEST section.

Logs that were discarded by a drop stage are considered ingested with a no-match policy. This means they are not kept even if no_hit = keep.

Keep in mind that all rules inside a group get evaluated independently. This is in contrast to firewall-like rules, which stop evaluating the first rule that
is able to make a decision. Therefore, without proper filtering, it is possible to ingest the same log more than once.

You can override the default raw dataset in INGEST sections. For more information, see Parsing Rules Raw Dataset.

Cortex XDR supports configuring case sensitivity in Parsing Rules only within the INGEST section using the following configuration stage:

config case_sensitive = true | false

You can add a single tagor list of tags to the ingested data as part of the ingestion flow that you can easily query in XQL Search. You can add tags as part
of the INGEST section or use both the INGEST and RULE sections. The following are examples of each.

INGEST section.

Adding a single tag.

[INGEST:vendor="MSFT", product="Azure AD Audit", target_dataset="msft_ad_audit_tagging", no_hit=drop, ingestnull = false ]

tag add "New Event"

Adding a list of tags.

[INGEST:vendor="MSFT", product="Azure AD Audit", target_dataset="msft_ad_audit_tagging", no_hit=drop, ingestnull = false ]

tag add "New Event1", "New Event2", "New Event3"

INGEST and RULE sections.

Adding a single tag.

[INGEST:vendor="Check Point", product="Anti Malware", target_dataset="malware_test", no_hit= drop , ingestnull = true ]

alter xx = call new_tag_rule;

[RULE:new_tag_rule]
tag add "test";

Adding a list of tags.

[INGEST:vendor="Check Point", product="Anti Malware", target_dataset="malware_test", no_hit= drop , ingestnull = true ]

alter xx = call new_tag_rule;

[RULE:new_tag_rule]
tag add "test1", "test2", "test3";

10.2.2.2 | COLLECT

Abstract

Understanding how to write a [COLLECT] section in a Parsing Rules file, and the syntax to use.

A COLLECT section defines a rule that enables data reduction and data manipulation at the Broker VM to help avoid sending unnecessary data to the Cortex
XSIAM server and reduces traffic, storage, and computing costs. In addition, the COLLECT section is used to manipulate, alter, and enrich the data before it’s
passed to the Cortex XSIAM server. While this rule is optional to configure, once added, this rule runs before the INGEST section.

NOTE:

The CSV Collector applet is not affected by the COLLECT rules applied to a Broker VM.

To avoid performance issues on the Broker VM, Cortex XSIAM does not permit all Parsing Rules to run on the Broker VM by default, but only the Parsing Rules
that you designate.

The Broker VM is directly affected by the [COLLECT] rules you create, so depending on the complexity of the rules more hardware resources on the Broker VM
may be required. As a result, ensure that your Broker VM meets the following minimum hardware requirements to run [COLLECT] rules.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 736/1003
5/8/24, 9:18 AM PDF Export

8-core processor

8GB RAM

512GB disk

Plan for a max of 10K eps (events per second) per core.

COLLECT syntax is derived from Cortex Query Language (XQL) with a few modifications as explained in the Parsing Rules syntax. In addition, COLLECT rules
contain the following syntax add-ons.

COLLECT rules can have more than one XQLp statement, separated by a semicolon (;). Each statement creates a different data reduction and
manipulation at the Broker VM for a different vendor and product.

While the XQL stages alter and fields are permitted in COLLECT rules for various vendors and products, you should avoid using them for supported
vendors that can be used for Analytics as these stages can disrupt the operation of the Analytics Engine. For a list of these vendors, see the Visibility of
Logs and Alerts from External Sources table specifically those vendors with Normalized Log Visibility.

Another new stage is available called drop.

drop takes a condition similar to the XQL filter stage (same syntax), but drops every log entry that passes that condition. One can think of it as a
negative filter, so drop <condition> is not equivalent to filter not <condition>.

drop can only appear last in a statement. No other XQLp syntax can follow.

COLLECT sections take parameters, where some are mandatory and others optional.

[COLLECT:vendor=<vendor>, product=<product>, target_brokers = (bvm1, bvm2, bvm3), no_hit = <keep\drop>];

The parameter descriptions are explained in the following table.

Parameter Description

vendor The vendor that the specified COLLECT rule for data reduction and data manipulation at the Broker VM applies to (mandatory).

product The product that the specified COLLECT rule for data reduction and data manipulation at the Broker VM applies to (mandatory).

target_brokers Specifies the list of Brokers to run the COLLECT rule for data reduction and data manipulation based on the vendor and product
configured (mandatory). When target_brokers=*, the COLLECT rule applies to all the data collected by the Broker VM applets.

NOTE:

The CSV Collector applet is not affected by the COLLECT rules applied to a Broker VM.

no_hit No-match strategy to use for the entire specified group of COLLECT rules (optional). The default is keep.

If no_hit = drop, then in a scenario where none of the COLLECT rules in the group generates output for a given event, that
event is discarded.

If no_hit = keep, then in a scenario where none of the COLLECT rules in the group generates output for a given event, that
event is passed to the Cortex XSIAM server.

The following is an example of using a COLLECT rule to filter data for a specific vendor and product that will run before the INGEST section.

[COLLECT:vendor="Apache", product="ApacheServer", target_brokers = (bvm1, bvm2, bvm3), no_hit = drop]

alter source_log = json_extract_scalar(_raw_log, "$.source")
| filter source_log = "WebApp-Logs"
| fields source_log, _raw_log;
[INGEST:vendor="Apache", product="ApacheServer", target_dataset = "dvwa_application_log"]
alter log_timestamp = json_extract_scalar(_raw_log, "$.timestamp")
| alter log_msg = json_extract_scalar(_raw_log, "$.msg")
| alter log_remote_ip = json_extract_scalar(_raw_log, "$.Remote_IP")
| alter scanned_ip = json_extract_scalar(_raw_log, "$.Scanned_IP")
| fields log_msg ,log_remote_ip ,log_timestamp ,source_log ,scanned_ip , _raw_log;

A few more points to keep in mind when writing COLLECT rules.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 737/1003
5/8/24, 9:18 AM PDF Export

There are no COLLECT rules by default, so all collected events are forwarded by the Broker VM to the Cortex XSIAM server.

When COLLECT rules are defined, the designated Broker VMs check every collected event versus each rule. When there is a match for a given product or
vendor, the Broker VM checks if it meets the filter criteria.

If it meets the criteria, the event is passed to the Cortex XSIAM server.

If it doesn’t meet the criteria, it depends on the no_hit parameter.

-If no_hit=drop, then this COLLECT rule will not pass the event. Yet, the event still goes through other rules on this Broker VM.

-If no_hit=keep, the event is passed to the Cortex XSIAM server, and goes through other rules on this Broker VM.

When the evaluated event, doesn’t match any product or vendor for a defined COLLECT rule, the event is passed to the Cortex XSIAM server.

10.2.2.3 | CONST

Abstract

Understanding how to write a [CONST] section in a Parsing Rules file and the syntax to use.

A CONST section is used to define strings and numbers that can be reused multiple times within Cortex Query Language (XQL) statements in other INGEST
sections by using $constName. This can be helpful to avoid writing the same value in multiple sections, similar to constants in modern programming languages.

For example:

[CONST]
DEFAULT_DEVICE_NAME = "firewall3060"; // string
FILE_REGEX = "c:\\users\\[a-zA-Z0-9.]*"; // complex string
my_num = 3; /* int */

An example of using a CONST inside XQL statements in other INGEST sections using $constName:

NOTE:

The dollar sign ($) must be adjacent to the [CONST] name, without any whitespace in between.
...
| filter device_name = $DEFAULT_DEVICE_NAME
| alter new_field = JSON_EXTRACT(field, $FILE_REGEX)
| filter age < $MAX_TIMEOUT
| join type=$DEFAULT_JOIN_TYPE conflict_strategy=$DEFAULT_JOIN_CONFLICT_STRATEGY (dataset=my_lookup) as inn url=inn.url
...

NOTICE: Only quoted or integer terminal values are considered valid for CONST sections. For example, these will not compile:

[CONST]
WORD_CONST = abcde; //invalid
func_val = regex_extract(_raw_log, "regex"); // not possible
RECURSIVE_CONST = $WORD_CONST; // not terminal - not possible

CONST sections are meant to replace values. Other types, such as column names, are not supported:

...
| filter $DEVICE_NAME = "my_device" // illegal
...

A few more points to keep in mind when writing CONST sections.

CONST names are not case-sensitive. They can be written in any user-desired casing, such as UPPER_SNAKE, lower_snake, camelCase, and
CamelCase. For example, MY_CONST=My_Const=my_const.

CONST names must be unique inside a section, and across all sections of the file. You cannot have the same CONST name defined again in the same
section, or in any other CONST sections in the file.

Since section order is unimportant, you do not have to declare a CONST before using it. You can have the CONST section written below other sections that
use those CONST sections.

A CONST is an add-on to the Parsing Rule syntax and is optional to configure.

CONST syntax is derived from XQL, but a few modifications as explained in the Parsing Rules syntax.

10.2.2.4 | RULE

Abstract

Understanding how to write a [RULE] section in a Parsing Rules file and the syntax to use.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 738/1003
5/8/24, 9:18 AM PDF Export

Rules are very similar to functions in modern programming languages. They are essentially pieces of Cortex Query Language (XQL) syntax, tagged with a name
- alias, for easier code reuse and avoiding code duplications. A RULE is an add-on to the Parsing Rule syntax and is optional to configure.

RULE syntax is derived from XQL with a few modifications as explained in the Parsing Rules syntax.

NOTE:

For more information on the XQL syntax, see Cortex XQL Language Reference guide.

A few more points to keep in mind when writing RULE sections.

Rules are defined by [rule:ruleName] as depicted in the following example.

[rule:filter_alerts]
filter raw_log not contains "alert";

Rules are invoked by using a call keyword as depicted in the following example.

[rule:filter_alerts]
filter raw_log not contains "alert";
[rule:use_another_rule]
filter severity="LOW" | call filter_alerts | fields - raw_log;

This is equivalent to writing.

[rule:use_another_rule]
filter severity="LOW" | filter raw_log not contains "alert" | fields - raw_log;

Rule names are not case-sensitive. They can be written in any user-desired casing, such as UPPER_SNAKE, lower_snake, camelCase, and
CamelCase). For example, MY_RULE=My_Rule=my_rule.

Rule names must be unique across the entire file. This means you cannot have the same rule name defined more than once in the same file.

Since section order is unimportant, you do not have to declare a rule before using it. You can have the rule definition section written below other
sections that use this rule.

You can add a single tagor list of tags to the ingested data as part of the ingestion flow that you can easily query in XQL Search. You can add tags using
both the INGEST and RULE sections. For example,

Adding a single tag.

[INGEST:vendor="Check Point", product="Anti Malware", target_dataset="malware_test", no_hit= drop , ingestnull = true ]

alter xx = call new_tag_rule;

[RULE:new_tag_rule]
tag add "test";

Adding a list of tags.

[INGEST:vendor="Check Point", product="Anti Malware", target_dataset="malware_test", no_hit= drop , ingestnull = true ]

alter xx = call new_tag_rule;

[RULE:new_tag_rule]
tag add "test1", "test2", "test3";

NOTE:

You can also add tags using only the INGEST section. For more information, see INGEST.

10.2.2.5 | EXTEND

Abstract

Understanding how to write an [EXTEND] section in a Parsing Rules file, and the syntax to use.

An EXTEND section is used to chain your Parsing Rules logic to extend your existing default RULE sections, which are added by a Content Package you installed
from Marketplace. While optional to configure, an EXTEND section runs immediately after the default RULE section that it extends, and enables data manipulation
without overriding or interfering with the existing vendor Parsing Rules.

EXTEND syntax is derived from Cortex Query Language (XQL) with a few modifications as explained in the Parsing Rules File Structure and Syntax section. You
can have multiple XQL statements, separated by a semicolon (;). Each statement creates a different extension.

NOTE:

For more information on the XQL syntax, see Cortex XQL Language Reference.

A few more points to keep in mind when writing EXTEND sections.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 739/1003
5/8/24, 9:18 AM PDF Export

You can only extend a default rule that is not overridden in the RULE sections.

A rule can only be extended once.

A CONST section that is defined in Default Rules cannot be used in the User Defined Rules when configuring an EXTEND section.

An EXTEND section must specify the full header of the rule it is extending. When you extend a rule that was added by a Content Package installed from
Marketplace, the EXTEND section uses the format [EXTEND:<rule name> content_id = "<pack id>"], where the content_id comes from the
Content Package that the extended rule belongs to.

For example, you can see here the EXTEND section in User Defined Rules uses the full header of the RULE it’s extending from Default Rules.

Default Rules:

[RULE:parse_ngfw_hipmatch content_id = "IronNet"]

alter _time = time_generated
| call extract_common_ngfw_fields
| call extract_hipmatch_only_fields
| call common_post_processing;

User Defined Rules:

[EXTEND:parse_ngfw_hipmatch content_id = "IronNet"]

alter source = json_extract_scalar(source, "$.string")
| filter __firewall_type = "firewall.hipmatch";

When this rule is run, the default RULE section runs, and is immediately followed by the EXTEND section. This is equivalent to running one single RULE
section as follows.

[RULE:parse_ngfw_hipmatch content_id = "IronNet"]

alter _time = time_generated
| call extract_common_ngfw_fields
| call extract_hipmatch_only_fields
| call common_post_processing;
| alter source = json_extract_scalar(source, "$.string")
| filter __firewall_type = "firewall.hipmatch";

10.2.3 | Create Parsing Rules

Abstract

Cortex XSIAM includes an editor for creating 3rd party Parsing Rules.

NOTE:

Only a user with Cortex Account Administrator or Instance Administrator permissions can access Parsing Rules.

Cortex XSIAM provides a number of default Parsing Rules that you can easily override or extend as required using XQL and additional custom syntax that is
specific to creating Parsing Rules. Before creating your own Parsing Rules, we recommend you review the following:

Parsing Rules Editor Views

Parsing Rules File Structure and Syntax

To create Parsing Rules:

1. In Cortex XSIAM , select Settings → Configurations → Data Management → Parsing Rules.

2. Select the Parsing Rules editor view for writing your Parsing Rules.

You can select one of the following views.

User Defined—Leave the default view open and write your Parsing Rules directly in the editor.

Default Rules—Select this view to understand which parsing rules are provided by default with Cortex XSIAM in read-only mode.

Both—Select this view to see the Parsing Rules editor as well as the default rules as you write your Parsing Rules.

Simulate—Select this view to test your Parsing Rules on actual logs and validate their outputs as you write your Parsing Rules.

3. Write your Parsing Rules using XQL syntax and the syntax specific for Parsing Rules.

4. (Optional) Test your Parsing Rules on actual logs and validate their outputs using the Simulate view.

NOTE:

You need Cortex XSIAM administrator or Instance Administrator permissions to access the Simulate view and perform these tests.

a. Select the Simulate view.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 740/1003
5/8/24, 9:18 AM PDF Export

b. For the User defined rules that you want to test, select the logs from the XQL Samples listed that you want to use to simulate the rule. For each
Vendor and Product, up to 5 different samples are available to choose from.

c. Simulate the rules based on the logs selected.

You can also pivot (right-click) any of the logs that you’ve selected to Simulate the rules.

d. Review the results in the Logs output table to determine if your User defined rules are fine or need further changes.

The Logs output table displays the following columns per dataset at the bottom of the window.

Dataset—Displays the applicable dataset name and a line number associated with this dataset in the User defined rules section.

Vendor—The vendor associated with this dataset.

Product—The product associated with this dataset.

Output Logs—Displays the available output log. When there is no output log to display, the text Output logs is not available with the
corresponding error message is displayed. When there is no output due to a missing rule in the User defined rules section for the logs
selected, the text No output logs. You can change your parsing rules and try again is displayed.

Input Logs—Displays the relevant input log with a right-click pivot to Show diff between the Output Logs and Input Logs.

e. (Optional) Modify your User defined rules and repeat steps #2-4 until you are satisfied with the results.

5. (Optional) Override the default Parsing Rules raw dataset.

6. Save your changes.

Your PARSING RULES are saved successfully.

10.2.4 | Troubleshooting Parsing Rules Errors

Abstract

Learn how to easily identify and resolve parsing errors.

NOTE:

Only a user with Cortex Account Administrator or Instance Administrator permissions can access Parsing Rules.

To help you easily identify and resolve parsing errors in Cortex XSIAM, all parsing errors are saved to a separate dataset called parsing_rules_errors. This
dataset displays important information about each error, including the RAW_LOG, log metadata, Parsing Rule metadata, and error description, which you need
to effectively troubleshoot the problem. In addition, a Parsing Rules Error notification is sent to the Notification Center whenever a new parsing error is added to
the dataset.

Types of Parsing Errors

There are different types of parsing errors.

Compilation Errors: Unable to compile a rule for different reasons including invalid function parameters, such as invalid regex.

Data Format Errors: A mismatch between the expected data type, such as CEF, LEEF, or JSON with the actual data, such as TEXT or CSV.

Runtime Errors: Unable to apply a rule to the data, such as an attempt to add a String to a Number.

Parsing Errors Dataset

All parsing errors and Cortex Data Model (XDM) errors are saved to a dataset called parsing_rules_errors. The following table describes the fields that are
available when running a query in XQL Search for the parsing_rules_errors dataset in alphabetical order.

NOTE:

Some errors can only be found after the applicable logs are collected in Cortex XSIAM.

Read more...

Field Description Source

_BROKER_DEVICE_ID Displays the ID of the Broker VM associated to the log that triggered this error. Log Metadata

_BROKER_DEVICE_IP Displays the IP address of the Broker VM associated to the log that triggered this error. Log Metadata

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 741/1003
5/8/24, 9:18 AM PDF Export

Field Description Source

_BROKER_DEVICE_NAME Displays the device name of the Broker VM associated to the log that triggered this error. Log Metadata

_COLLECTOR_HOSTNAME Displays the host name of the data collector associated to the log that triggered this error. Log Metadata

_COLLECTOR_ID Displays the ID of the data collector associated to the log that triggered this error. Log Metadata

_COLLECTOR_IP_ADDRESS Displays the IP address of the data collector associated to the log that triggered this error. Log Metadata

_COLLECTOR_NAME Displays the name of the data collector associated to the log that triggered this error. Log Metadata

_COLLECTOR_TYPE Displays the type of data collector associated to the log that triggered this error. Log Metadata

CONTENT_ID Displays the package_id of a content pack containing the default Parsing Rule for which Parsing Rule
this error was generated.

CREATED_AT Displays a timestamp for when the rule, which generated the error, was created. Parsing Rule

END_LINE Displays the last line of the particular rule associated to this error. Parsing Rule

ERROR_CATEGORY Displays the category of the error, which can be one of the following: N/A

Compile: Compilation error, such as syntax error, missing argument, and invalid
regex.

Data format: Errors relating to the data format, such as received LEEF when
expected CEF.

Runtime: Error at run time, such as an attempt to add a String to a Number.

ERROR_MESSAGE Displays the error message. N/A

_FINAL_REPORTING_DEVICE_IP Displays the IP address of the device that the log was collected from that triggered this Log Metadata
error.

_FINAL_REPORTING_DEVICE_NAME Displays the name of the device that the log was collected from that triggered this error. Log Metadata

_ID Displays the Rule ID that triggered this error. Parsing Rule

INGEST_NULL Displays a boolean value of either TRUE or FALSE to indicate whether null value fields Parsing Rule
are configured to be ingested or not. By default, null fields are ingested.

NO_HIT Displays the no-match strategy configured for the rule group that generated the parsing Parsing Rule
error.

_PRODUCT Displays the defined PRODUCT associated to the log (for data format errors) or rule (for Log Metadata or
compilation and runtime errors) that triggered this error. Parsing Rule

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 742/1003
5/8/24, 9:18 AM PDF Export

Field Description Source

RAW_LOG Displays the raw log for the Parsing Rule error or parsed log for the Data Model Rule Raw log
error.

_REPORTING_DEVICE_IP Displays the IP address of the device that the log originated from that triggered this error. Log Metadata

_REPORTING_DEVICE_NAME Displays the name of the device that the log originated from that triggered this error. Log Metadata

RULE_TYPE Displays the type of rule that triggered this error. Parsing Rule

START_LINE Displays the first line of the particular rule associated to this error. Parsing Rule

TARGET_DATASET Displays the Target dataset associated to the rule that triggered this error. Parsing Rule

_TIME Displays the timestamp when the error was generated. Raw log

_VENDOR Displays the defined VENDOR associated to the log (for data format errors) or rule (for Raw log or Parsing
compilation and runtime errors) that triggered this error. Rule

XDRC_ID Displays the ID of the XDR Collector associated to the log that triggered this error. Log Metadata

XDRC_IP Displays the IP address of the XDR Collector associated to the log that triggered this Log Metadata
error.

XDRC_NAME Displays the name of the XDR Collector associated to the log that triggered this error. Log Metadata

XQL_TEXT Displays the specific section of the rule related to the error generated. Parsing Rule

10.2.5 | Parsing Rules Raw Dataset

Abstract

Each vendor and product has its own raw dataset with its own default format that can be overridden in an INGEST section.

NOTE:

Only a user with Cortex Account Administrator or Instance Administrator permissions can access Parsing Rules.

Each vendor and product has its own raw dataset that uses the format <vendor>_<product>_raw. For example, for Palo Alto Networks Next-Generation
Firewall, the dataset is called panw_ngfw_raw. This raw dataset by default keeps all raw logs, whether ingested or dropped for other datasets.

You can override the default raw dataset, by creating an INGEST section referring to that dataset. For example, the following syntax overrides the
panw_ngfw_raw automatic Parsing Rule.

[ingest:vendor=panw, product=ngfw, dataset=panw_ngfw_raw]

filter ... | alter ...;

10.3 | Data Model Rules

Abstract

Learn more about Cortex Data Model (XDM) Rules.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 743/1003
5/8/24, 9:18 AM PDF Export

NOTE:

Only a user with Cortex Account Administrator or Instance Administrator permissions can access Data Model Rules.

Cortex XSIAM enables you to map your logs into a single, unified data model. This data model provides a consolidated schema, and a simpler way to interact
with your data, regardless of its source or dataset. To familiarize yourself with the data model schema, see Cortex XSIAM Data Model Schema.

You can map your data to the data model using Data Model Rules, either by using the Default Rules that are automatically added when installing Content
Packages from the Marketplace, or by creating user-defined rules. You create rules with the Data Model Rules editor, which enables you to do the following:

Map 3rd party data to a consolidated schema with predefined data types.

Enjoy auto-complete and mapping suggestions.

Map multiple queryable datasets to the data model.

Data Model Rules contain the following built-in characteristics.

Each Data Model Rule is mapped between one dataset and the data model.

A Data Model Rule takes rows from a dataset to use as an input, performs an arbitrary number of transitions and modifications on each column in the
dataset using Cortex Query Language (XQL), and then returns the normalized rows with the corresponding data model’s schema.

10.3.1 | Data Model Rules Editor Views

Abstract

Learn about the Data Model Rules editor User Defined Rules, Default Rules, and Both views.

NOTE:

Only a user with Cortex Account Administrator or Instance Administrator permissions can access Data Model Rules.

The Data Model Rules editor contains the following views.

User Defined Rules (default)—Displays an editor for writing your own custom Data Model Rules that override the default rules. Once you edit a default
Data Model mapping, you will no longer receive Marketplace updates.

Default Rules (read-only)—Displays the data model rules that are provided by default.

Both—Side-by-side view of both the Default Rules and User Defined Rules, so that you can easily view both sets of rules on the same screen.

10.3.2 | Data Model Rules File Structure and Syntax

Abstract

Learn about the Data Model Rules file structure and syntax.

NOTE:

Only a user with Cortex Account Administrator or Instance Administrator permissions can access Data Model Rules.

File Structure

The Data Model Rules file consists of multiple sections of the following two types, which also represent the custom syntax specific to Data Model Rules.

MODEL—This section is used to define the mapping between a single dataset and the data model.

RULE—(Optional) Rules are part of the Cortex Query Language (XQL) syntax, which are tagged with a name, and can be reused in the code in the MODEL
sections, or in other RULE sections (recursively), by using [rule:ruleName].

The order of the sections is not significant.

Syntax

The syntax used in the Data Model Rules file is derived from XQL, with a few modifications. This subset of XQL is called XQL for Data Modeling (XQLm).

NOTE:

For more information on XQL syntax, see the XQL Language Reference Guide.

In the MODEL and RULE sections, the following modifications apply to the XQLm syntax.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 744/1003
5/8/24, 9:18 AM PDF Export

Only the following XQL stages are permitted: ALTER and FILTER. An additional CALL stage is supported, which is used to invoke another rule.

NOTE:

You cannot call a RULE section that exists in Default Rules from the User Defined Rules section.

No output stages are supported.

XDM_ALIAS cannot be used in rules. It is only supported in queries.

Every model definition in the Data Model Rules file must end with a semicolon (;).

Each XDM field used in the MODEL and RULE sections is constructed using dot notation using the following format.

xdm.[<context>].[<compound>].<field>

For more information, see Field Structure.

10.3.2.1 | MODEL

Abstract

Learn how to write a MODEL section in a Data Model Rules file, and about the syntax to use in the file.

A MODEL section is used to define the mapping between a single dataset and the data model. The MODEL section is mandatory per dataset. A RULE section is
optional, and is used to help organize the MODEL sections.

MODEL syntax is derived from Cortex Query Language (XQL), with a few modifications, as explained in Data Model Rules Syntax. In addition, MODEL sections
contain the following syntax add-ons.

You can have multiple MODEL sections.

MODEL sections take parameters, and not names as RULE sections use, where some are mandatory and others are optional.

[MODEL: dataset=<dataset>, content_id=<content_id>]

<build the XQL logic>;

The parameter descriptions are explained in the following table.

Parameter Description

dataset The name of the dataset that contains the source data to apply the mapping on (mandatory).

content_id Identifier of the content as defined in the content package from the Marketplace. This parameter is relevant only for Default Rules and is not
available in User Defined Rules (optional).

Example

[MODEL: dataset=panw_ngfw_traffic]
filter appid = "dns"
| alter dns_helper = json_extract(event, "$.dns")
| alter xdm.network.dns.opcode = to_integer(json_extract_scalar(dns_helper, "$.opcode"),
xdm.network.dns.is_truncated = to_boolean(json_extract_scalar(dns_helper, "$.is_truncated")
);

Points to keep in mind when writing MODEL sections:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 745/1003
5/8/24, 9:18 AM PDF Export

MODEL parameter names are not case-sensitive.

Cortex Data Model (XDM) System fields (_time, _insert_time, _vendor, _product) are mapped automatically from the dataset from the fields with the
same names.

As section order is not significant, you do not have to declare a RULE before using it in a MODEL section.

Each field used in the MODEL and RULE sections is constructed using dot notation with a specific format. Each field must be part of the predefined field set
of the data model's schema. However, temporary variables, which will not affect the modeling, may be used. For more information, see Field Structure.

A MODEL section can invoke a rule using the call stage.

In this example, both the RULE and MODEL sections are provided, so you can see how the call stage invokes the rule.

[RULE: common_ngfw_modeling]
alter xdm.source.ipv4 = json_extract_scalar(actor, "$.client_ip")
| alter xdm.network.ip_protocol = if(
proto = 6, XDM_CONST.IP_PROTOCOL_TCP,
proto = 11, XDM_CONST.IP_PROTOCOL_UDP,
proto
);

[MODEL: dataset=panw_ngfw_traffic]
filter appid = "dns"
| call common_ngfw_modeling
| alter dns_helper = json_extract(event, "$.dns")
| alter xdm.network.dns.opcode = to_integer(json_extract_scalar(dns_helper, "$.opcode"),
xdm.network.dns.is_truncated = to_boolean(json_extract_scalar(dns_helper, "$.is_truncated")
);

You can use the config case_sensitive stage in the MODEL section to configure whether field values in the XDM are evaluated as case sensitive or
case insensitive. The config case_sensitive stage must be added at the beginnning of the query. If you do not provide this stage in your query, the
default behavior is false; case is not considered when evaluating field values.

NOTE:

The Settings → Configurations → XQL Configuration → Case Sensitivity (case_sensitive) setting can overwrite this case_sensitive configuration for
all fields in the application except for BIOCs, which will remain case insensitive no matter what this setting is set to. For more information on this setting,
see Define XQL Configuration Settings.

Cortex XSIAM enables analytics to run on the following data:

All mapped network data to the network 5 tuple (source IP, source port, target IP, target port, IP protocol), automatically creating network stories for
XDM network data.

All mapped authentication data, automatically creating authentication stories for XDM identity data when the xdm.event.type field is set to
authentication and all of the following fields contain data:

xdm.source.ipv4

xdm.source.user.upn

xdm.event.original_event_type

xdm.event.outcome

xdm.event.outcome_reason

xdm.event.operation

IMPORTANT:

To maximize the variety of alerts 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.

NOTE:

We recommend that you do not configure the same data source in both Marketplace and using a Cortex XSIAM data collector. Yet, if you do, the
following will happen:

For network data, all relevant logs from the different data sources are stitched to the same network story.

For authentication data, all relevant logs from the different data sources are stitched to the same authentication story as long as the logs contain
the network 5 tuple (source IP, source port, target IP, target port, IP protocol). The rest of the logs, without the network 5 tuple, create duplicate
authentication stories.

10.3.2.2 | RULE

Abstract

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 746/1003
5/8/24, 9:18 AM PDF Export

Learn how to write a RULE section in a Data Model Rules file and about the syntax to use in the file.

Rules are very similar to functions in modern programming languages. They are essentially named pieces of Cortex Query Language (XQL) syntax, and can be
reused in the code in the MODEL sections, or in other RULE sections (recursively), by using [rule:ruleName]. A RULE is an optional data model syntax.

RULE syntax is derived from XQL with a few modifications, as explained in the Data Model Rules Syntax.

NOTE:

For more information on the XQL syntax, see the XQL Language Reference Guide.

Points to keep in mind when writing RULE sections:

Rules are defined by [rule:ruleName] as shown in the following example.

[RULE: common_ngfw_modeling]
alter xdm.source.ipv4 = json_extract_scalar(actor, "$.client_ip")
| alter xdm.network.ip_protocol = if(
proto = 6, XDM_CONST.IP_PROTOCOL_TCP,
proto = 11, XDM_CONST.IP_PROTOCOL_UDP,
proto
);

Rules are invoked by using a call stage.

Rule names are not case-sensitive.

Rule names must be unique across the entire file.

As section order is not significant, you do not have to declare a rule before using it. You can have the rule definition section written below other sections
that use that specific rule.

Each field used in the MODEL and RULE sections is constructed using dot notation with a specific format. However, temporary variables, which will not affect
the modeling, can be used. For more information, see Field Structure.

10.3.2.3 | Field Structure

Abstract

Learn more about the structure of the fields in the MODEL and RULE sections when creating Data Model Rules.

When creating Data Model Rules, each field used in the MODEL and RULE sections is constructed using dot notation using the following format.

xdm.<context>.[<compound>].<field>

Examples:

xdm.<context>.[<compound>].<field>

xdm.source.host.device_id

xdm.<context>.<field>

xdm.source.ipv4

Part Description

<context> This is a composition of fields (<field>), either simple or <compound>, that are grouped together to form a logically coherent unit.

<compound> This is a set of simple fields that are grouped together to form a meaningful group. For example, subject and recipients are part of the
<compound> field called email.

<field> This is a field that represents a primitive data type, such as a string or number or an array, or an IP address.

NOTE:

For more information on these data model fields, see Cortex XSIAM Data Model Schema.

Using ENUM fields

For fields of the ENUM type, you can map values from a predefined list of ENUMs. For example, the field xdm.network.ip_protocol is defined as
Enum.IP_PROTOCOL, so you can assign it values such as XDM_CONST.IP_PROTOCOL_TCP. The full list can be found in the automatically suggested values for the

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 747/1003
5/8/24, 9:18 AM PDF Export

relevant fields.

Note that this syntax is not mandatory, and you can map any STRING value, but we recommend its use for consistency across all model mapping.

Example:

[RULE: common_ngfw_modeling]
alter xdm.source.ipv4 = json_extract_scalar(actor, "$.client_ip")
| alter xdm.network.ip_protocol = if(
proto = 6, XDM_CONST.IP_PROTOCOL_TCP,
proto = 11, XDM_CONST.IP_PROTOCOL_UDP,
proto
);

10.3.3 | Create Data Model Rules

Abstract

Cortex XSIAM includes an editor for creating Data Model Rules.

NOTE:

Only a user with Cortex Account Administrator or Instance Administrator permissions can access Data Model Rules.

You can override rules or create your own rules using XQL and additional custom syntax that is specific to defining Data Model Rules. Once you edit a default
data model mapping, you will no longer receive Marketplace updates. Before you create your own Data Model Rules and override the defaults, we recommend
that you review the following information.

Data Model Rules Editor Views

Data Model Rules File Structure and Syntax

To create Data Model Rules.

1. In Cortex XSIAM, select Settings → Configurations → Data Management → Data Model Rules.

2. Select the Data Model editor view for writing your Data Model Rules.

You can select one of the following views.

User Defined Rules—Leave the default view open and write your Data Model Rules directly in the editor.

Both—Select this view to see the Data Model Rules editor as well as the default rules as you write your Data Model Rules.

3. Write your rules using XQL syntax and the syntax specific to Data Model Rules.

4. (Optional) Use XQL Search to test your Data Model Rules and review logs.

You can create queries on the data model. For more information, see Create an XQL Query.

10.3.4 | Troubleshooting Data Model Rules

Abstract

Learn more about how to easily identify and resolve Data Model Rules errors in Cortex XSIAM.

NOTE:

Only a user with Cortex Account Administrator or Instance Administrator permissions can access Data Model Rules.

To help you easily identify and resolve errors related to invalid Cortex Data Model (XDM) Rules, Cortex XSIAM provides the following:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 748/1003
5/8/24, 9:18 AM PDF Export

When an XDM query runs and one of the Data Model Rules is invalid, the invalid rule is automatically disabled and excluded from the query, and warning
is displayed.

When a Data Model Rule is disabled, a message is added to your Cortex XSIAM console Notification Center. For more information about the Data Model
Rules notifications, see Data Model Rules Notifications.

The Data Model Rules editor displays an error icon and a message beside invalid Data Model Rules.

An audit log is added to the Management Audit Log whenever a Data Model Rule becomes invalid, and when an invalid Data Model Rule becomes valid.

TIP:

To ensure you and your colleagues stay informed about Data Model Rules activity, you can also Configure Notification Forwarding to forward your Data
Model Rules audit logs to an email distribution list or Syslog server. For more information about the Data Model Rules audit logs, see Monitor Data
Model Rules Activity.

When a rule is fixed, it is automatically enabled. User defined Data Model Rules are updated manually in the User Defined Rules editor. While default
Data Model Rules are updated as part of a Marketplace package update, or a background change, such as an XQL content change.

All Data Model Rules compilation errors are added to the parsing_rules_errors dataset.

Dataset for Data Model Rules Errors

All Data Model Rules compilation errors, such as syntax errors, missing arguments, and invalid regex, are saved to a dataset called parsing_rules_errors.
This dataset also includes Parsing Rules errors. The following table describes the fields that are applicable to troubleshooting Data Model Rules errors when
running a query in XQL Search for the parsing_rules_errors dataset in alphabetical order.

NOTE:

Since this dataset also contains Parsing Rules errors, some of the fields are irrelevant for Data Model Rules and aren't included in the table.

Read more...

Field Description

CREATED_AT Displays the timestamp when the error was generated.

ERROR_CATEGORY Displays the category of the error, which for Data Model Rules errors is always Compile for compilation errors.

ERROR_MESSAGE Displays the error message.

_ID Displays the Rule ID that triggered this error.

RULE_TYPE Displays the type of rule that triggered this error.

TARGET_DATASET Displays the target dataset associated to the rule that triggered this error.

_TIME Displays the timestamp when the error was generated.

XQL_TEXT Displays the specific section of the Data Model Rule related to the error generated.

10.3.5 | Using Data Enrichment

Abstract

Learn about data-enriched fields and their limitations.

NOTE:

Data enrichement is a beta feature, supported by the Enterprise Plus license only.

Cortex XSIAM automatically enriches your Cortex Data Model (XDM) data with additional information and context. Some examples of the types of data that are
enriched include:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 749/1003
5/8/24, 9:18 AM PDF Export

NOTE:

For a complete list of auto-enriched fields, see the Cortex Data Model Schema Guide.

IP addresses are enriched with geolocation information.

User data is normalized.

If DSS exists, it is also enriched.

These enrichments are important for cyber analytics, rule detection, and investigations. Since these fields are enriched automatically by default, they do not
have to be mapped manually in Data Model Rules. Note that enrichment is not performed when the input fields needed for enrichment are not available.

Enriched data is calculated by the system upon ingestion, and is saved for future queries. Keep in mind that some data may change over time, such as IP
addresses that may change geolocation. Therefore, checking the same IP address in external systems at a later time might return a different geolocation result.

Overriding Data Enrichment

We do not recommend overriding enriched fields. However, if enriched fields are not desired, they can be overridden by mapping data to fields that are usually
enriched. For example:

[MODEL: dataset=okta_sso_raw]
| alter xdm.source.ip = actor->ip_address,
xdm.source.location.country = actor->country,
xdm.source.location.city = actor->geo.city;

When overriding enriched fields, ensure the following:

The overridden data should be normalized.

All relevant enriched fields should be overridden (for example, all location fields), and empty values should be filled with “unknown” (or with NULL, if
calculated enrichments are desired). These actions will prevent data mismatch and conflicts.

IMPORTANT:

When manually mapping ASN fields that are enriched, such as xdm.source.asn.as_number, with other ISP and domain fields that are not enriched, such as
xdm.source.asn.isp and xdm.source.asn.domain, it's possible to receive incorrect XDM query results due to the misalignment between the overridden
enrichement and system enrichment fields.

Limitations

Geolocation limitations

Some values will be NULL if the log country doesn't match the country detected by an external geolocation tool.

There might be discrepancies when some data come from the log and other data from the enrichment. For example, log country data versus
enrichment longitude data.

Data enrichment is not performed for EDR events.

This feature is not supported in cold storage.

Backward compatibility

Data ingested by versions prior to Cortex XSIAM version 1.3 will not be enriched, because enrichment is calculated at the time of ingestion.

By default, enrichment is performed for NULL values only (non-NULL values are not overridden). Therefore, some existing mapping rules may need to be
updated, in order to prevent mapping data to the enriched fields. Contact Customer Support for assistance with converting custom modeling rules and saved
queries.

10.3.6 | Data Model Rules Notifications

Abstract

Learn more about the notifications that are relevant for Cortex XSIAM Data Model Rules.

To help you monitor effectively your Data Model Rules, Cortex XSIAM sends notifications to your Cortex XSIAM console Notification Center.

Cortex XSIAM sends the following notification:

Invalid Data Model Rules—Notifies when a Data Model Rule is invalid and will be excluded from 'datamodel' queries.

To ensure you and your colleagues stay informed about Data Model Rules activity, you can also Configure Notification Forwarding to forward your Data Model
Rules logs to an email distribution list or Syslog server. For more information about the Data Model Rules audit logs, see Monitor Data Model Rules Activity.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 750/1003
5/8/24, 9:18 AM PDF Export

10.4 | Manage Event Forwarding

Abstract

Save your ingested, parsed data in an external location by exporting your event logs to a temporary GCP storage bucket.

LICENSE TYPE:

This feature requires an Event Forwarding add-on license. Only Administrators have access to this screen.

You can save your ingested, parsed data in an external location by exporting your event logs to a temporary storage bucket on Google Cloud Platform (GCP),
from where you can download them for up to 7 days.

Use the Event Forwarding page to activate your Event Forwarding licenses, to retrieve the path and credentials of your external storage destination on GPC.
Once this page is activated, Cortex XSIAM automatically creates the GCP bucket.

Upload to a temporary GCP storage bucket

1. Under Settings → Configurations → Data Management → Event Forwarding, activate the licenses in the Activation section.

Enable GB Event Forwarding to export parsed logs for Cortex XDR Pro per GB to an external SIEM for storage. This enables you to keep data in
your own storage in addition to the Cortex XSIAM data layer, for compliance requirements and machine learning purposes. The exported logs are
raw data, without any stories. Cortex XSIAM exports all the data without filtering or configuration options.

Enable Endpoints Event Forwarding to export raw endpoint data for Cortex XSIAM Pro EP and Cloud Endpoints. The exported logs are raw data,
without any stories. Cortex XSIAM exports a subset of the endpoint data without filtering or configuration options.

2. Save your selection.

3. Access GCP Cloud Storage using the Service Account.

The Destination section displays the details of the GCP bucket created by Cortex XSIAM, where your data is stored for 7 days. The data is compressed
and saved as a line-delimited JSON gzip file.

a. Copy the storage path displayed.

b. Generate and download the Service Account JSON WEB TOKEN, which contains the access key.

Save it in a secure location. If you need to regenerate the access token, Replace and download a new token. This action invalidates the previous
token.

The token provides access to all your data stored in this bucket and must be saved in a safe place.

Use the storage path and access key to manually retrieve your files or use an API for automated retrieval.

c. Using the storage path and the access key, retrieve your files manually or using an API.

Authenticating as a service account

Copying files and objects from GCP

4. (Optional) Use the Pub/Sub subscription to ensure reliable data retrieval without any loss.

a. Copy the Pub/Sub subscription provided.

b. Configure your application or system to receive messages from the Pub/Sub subscription.

Whenever a new file is added to the GCS bucket, a message is sent to the Pub/Sub subscription. The object path of the file in the bucket has the
prefix internal/.

c. Process the received message to initiate the download of the corresponding file.

10.4.1 | Endpoints Event Forwarding - Exported Data Types

Abstract

Find out which events are exported using Endpoint Event Forwarding in Cortex XSIAM.

Endpoints Event Forwarding exports ingested, parsed endpoint data for Cortex XDR pro EP and Cloud Endpoints. The exported logs are raw data, without any
stories. Cortex XSIAM exports the data without filtering or configuration options. The table below lists the types of events exported for the endpoints and the
fields that are included and excluded.

Exported Event Type Included Field Excluded Field

Network action_socket_type is_boot_replay

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 751/1003
5/8/24, 9:18 AM PDF Export

Exported Event Type Included Field Excluded Field

action_remote_ip action_proxy

action_remote_port action_network_app_ids

action_local_ip action_network_rule_ids

action_local_port action_network_dpi_fields

action_network_connection_id action_network_is_loopback

action_network_is_server action_upload

action_network_creation_time action_download

action_total_upload action_network_stats_seq

action_total_download action_network_is_ipv6

action_network_protocol

action_network_stats_is_last

Process uuid / _id action_process_causality_id

action_process_os_pid action_process_is_causality_root

action_process_instance_id action_process_is_replay

action_process_image_md5 action_process_yara_file_scan_result

action_process_image_sha256 action_process_wf_verdict

action_process_image_path action_process_static_analysis_score

action_process_image_name execution_actor_causality_id

action_process_image_extension action_process_ns_pid

action_process_image_command_line action_process_container_id

action_process_signature_product action_process_is_container_root

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 752/1003
5/8/24, 9:18 AM PDF Export

Exported Event Type Included Field Excluded Field

action_process_signature_vendor action_process_image_command_line_indices

action_process_signature_is_embedded action_process_is_special

action_process_signature_status action_process_ns_user_sid

action_process_integrity_level action_process_ns_user_real_sid

action_process_username action_process_file_size

action_process_user_sid action_process_file_create_time

action_process_in_txn action_process_file_mod_time

action_process_pe_load_info action_process_remote_session_ip

action_process_peb action_process_file_info

action_process_peb32 action_process_device_info

action_process_last_writer_actor execution_actor_instance_id

action_process_token action_process_user_real_sid

action_process_privileges action_process_requested_parent_pid

action_process_fds action_process_requested_parent_iid

action_process_scheduled_task_name

action_process_termination_date

action_process_instance_execution_time

action_process_termination_code

File action_file_path action_file_wf_verdict

action_file_name action_file_yara_file_scan_result

action_file_previous_file_path action_file_dir_query

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 753/1003
5/8/24, 9:18 AM PDF Export

Exported Event Type Included Field Excluded Field

action_file_previous_file_name action_file_previous_device_info

action_file_md5 action_file_device_info

action_file_sha256 action_file_reparse_path

action_file_size action_file_reparse_count

action_file_attributes action_file_dirty_reason

action_file_create_time action_file_remote_ip

action_file_mod_time action_file_remote_port

action_file_access_time action_file_remote_file_ip

action_file_type action_file_remote_file_host

action_file_operation_flags action_file_sec_desc

action_file_mode action_file_previous_file_extension

action_file_owner action_file_extension

action_file_owner_name action_file_archive_list

action_file_group action_file_contents

action_file_group_name

action_file_device_type

action_file_signature_product

action_file_signature_vendor

action_file_signature_is_embedded

action_file_signature_status

action_file_pe_info

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 754/1003
5/8/24, 9:18 AM PDF Export

Exported Event Type Included Field Excluded Field

action_file_prev_type

action_file_last_writer_actor

action_file_is_anonymous

Registry action_registry_value_type

action_registry_key_name

action_registry_data

action_registry_value_name

action_registry_old_key_name

action_registry_file_path

action_registry_return_val

Injection action_remote_process_thread_id action_remote_process_causality_id

action_remote_process_os_pid action_remote_process_is_causality_root

action_remote_process_instance_id action_remote_process_is_replay

action_remote_process_image_md5 action_remote_process_image_extension

action_remote_process_image_sha256 action_remote_process_image_command_line_indices

action_remote_process_image_path action_remote_process_is_special

action_remote_process_image_name action_remote_process_file_size

action_remote_process_image_command_line action_remote_process_file_create_time

action_remote_process_signature_product action_remote_process_file_mod_time

action_remote_process_signature_vendor action_remote_process_file_info

action_remote_process_signature_is_embedded

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 755/1003
5/8/24, 9:18 AM PDF Export

Exported Event Type Included Field Excluded Field

action_remote_process_signature_status

action_remote_process_thread_start_address

action_remote_process_integrity_level

action_remote_process_username

action_remote_process_user_sid

address_mapping

Load Image action_module_path action_module_is_replay

action_module_md5 action_module_yara_file_scan_result

action_module_sha256 action_module_file_size

action_module_base_address action_module_file_create_time

action_module_image_size action_module_file_mod_time

action_module_signature_product action_module_file_access_time

action_module_signature_vendor action_module_device_info

action_module_signature_is_embedded action_module_wf_verdict

action_module_signature_status

action_module_file_info

action_module_last_writer_actor

action_module_other_load_location

action_module_page_protection

action_module_system_properties

action_module_code_integrity

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 756/1003
5/8/24, 9:18 AM PDF Export

Exported Event Type Included Field Excluded Field

action_module_boot_code_integrity

User Status Change action_user_status

action_username

action_user_status_sid

action_user_session_id

action_user_is_local_session

Host Status Change action_boot_time

action_powered_off

Agent Status Change action_boot_instance_cleanup_required

agent_status_component

Host Metadata Discovery/Change host_metadata_interface_map

host_metadata_hostname

host_metadata_domain

Common Fields For All Event Types Included Field Excluded Field

Agent agent_content_version agent_install_type

agent_hostname event_utc_diff_minutes

agent_interface_map manifest_file_version

agent_os_sub_type source_message_id

agent_os_type zip_id

agent_version agent_request_time

agent_id server_request_time

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 757/1003
5/8/24, 9:18 AM PDF Export

Common Fields For All Event Types Included Field Excluded Field

agent_ip_addresses agent_id_hash

agent_ip_addresses_v6 agent_id_hash_bre

backtrace_identities

_product

_vendor

actor_fields

agent_is_vdi

Common event_version event_is_impersonated

event_type event_is_replay

event_sub_type event_impersonation_status

event_id event_is_simulated

event_timestamp event_user_presence

event_rpc_interface_uuid agent_host_boot_time

event_rpc_func_opnum agent_session_start_time

event_validity_enum

event_invalidity_field

event_rpc_inteface_version_major

event_rpc_inteface_version_minor

event_rpc_protocol

event_address_mapped

event_user_presence_status

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 758/1003
5/8/24, 9:18 AM PDF Export

Common Fields For All Event Types Included Field Excluded Field

Actor os_actor_local_ip actor_ns_user_sid

os_actor_local_port actor_process_auth_id

os_actor_primary_user_sid actor_process_causality_id

os_actor_primary_username actor_process_ns_pid

os_actor_process_command_line actor_process_session_id

os_actor_process_image_md5 actor_process_signature_is_embedded

os_actor_process_image_name actor_process_signature_product

os_actor_process_image_path actor_process_signature_vendor

os_actor_process_image_sha256 actor_remote_host

os_actor_process_signature_status actor_remote_pipe_name

os_actor_process_logon_id actor_remote_port

os_actor_process_os_pid actor_rpc_interface_version_major

os_actor_remote_ip actor_rpc_interface_version_minor

os_actor_process_instance_id actor_rpc_protocol

os_actor_thread_thread_id actor_type

actor_rpc_func_opnum

actor_rpc_interface_uuid

actor_process_device_info

actor_process_execution_time

actor_process_file_create_time

actor_process_file_mod_time

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 759/1003
5/8/24, 9:18 AM PDF Export

Common Fields For All Event Types Included Field Excluded Field

actor_process_file_size

actor_process_image_extension

actor_process_instance_id

actor_process_command_line_indices

actor_process_integrity_level

actor_process_is_special

actor_process_last_writer_actor

actor_process_instance_id

actor_thread_thread_id

actor_is_injected_thread

actor_causality_id

actor_effective_username

actor_effective_user_sid

10.5 | Manage Compute Units Usage

Abstract

Manage and track your Compute Units usage for API, Apps, and Cold Storage XQL queries.

Cortex XSIAM uses compute units (CU) for these types of queries,

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 760/1003
5/8/24, 9:18 AM PDF Export

API Queries—When running Cortex Query Language (XQL) queries on your data sources using APIs, each XQL query API consumes CU based on the
timeframe, complexity, and number of API response results.

Apps—The Notebooks instance consumes 1000 CU each day and BigQuery queries consume CU based on the timeframe, complexity, and number of
results. Apps is charged daily at 00:00 UTC.

Cold Storage Queries—Cold Storage is a data retention offering for cheaper storage usually for long-term compliance needs with limited search options.
You can perform queries on Cold Storage data using the dataset format cold_dataset = <dataset name>, which consumes CU according to the
following calculations.

Amount of data queried. 1CU for querying 35GB of data.

Timeframe, complexity, and the number of Cold Storage response results of each XQL Cold Storage query.

When you query Cold Storage data, the rewarmed data is saved in a temporary hot storage cache that is available for subsequent queries on the same
time-range at no additional cost. The rewarmed data is available in the cache for 24 hours and on each re-query the cached data is extended for 24 hours,
for up to 7 days.

NOTE:

The CU consumption of cold storage queries are based on the number of days in the query time frame. For example, when querying 1 hour of a specific
day, the CU of querying this entire day are consumed. When querying 1 hour that extends past 2 days, such as from 23:50 to 00:50 of the following day,
the CU of querying these two days are consumed.

Cortex XSIAM provides a free daily quota of CU allocated according to your license size. Queries called without enough quota will fail. To expand your
investigation capabilities, you can purchase additional CU by enabling the Compute Unit add-on.

The Compute Unit add-on provides an additional 1 compute unit per day, in addition to your free daily quota. For example, if you have allocated 5 free daily CU,
with the add-on you will have a total of 6 daily compute units. The CU are refreshed every 24 hours according to UTC time. You can purchase a minimum of 50
compute units.

To gauge how many CU you require, Cortex XSIAM provides a 30-day free trial period with a total of three times your allocated CU to run XQL API and Cold
Storage queries. You can then track the cost of each XQL API and Cold Storage query responses and the Compute Units Usage page. In addition, Cortex
XSIAM sends a notification when the Compute Units add-on has reached your daily threshold.

To enable the add-on, select Settings → Configurations → Cortex XDR License → Addons tile, and select the Compute Unit tile and Enable.

To manage your CU usage for your queries,

1. Select Settings → Configurations → Data Management → Compute Units Usage.

2. In the Daily Usage in Compute Units section, monitor the amount of quota units used over the past 24 hours and the amount of free daily quota allocated
according to your license size and the additional amount you have purchased. The time frame is calculated according to UTC time.

For Managed Security tenants, the values calculated are the total daily usage of parent and child tenants.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 761/1003
5/8/24, 9:18 AM PDF Export

3. In the Compute Units over last 30 Days section, track your quota usage over the past 30 days. The red line represents your daily license quota. For
Managed Security tenants, make sure you select from the MSSP Tenant Selection drop-down menu, the tenant for which you want to display the
information. To investigate further.

Hover over each bar to view the total number of query units used each day.

Select a bar to display in the XCompute Unit Usage table the list of queries executed on the selected day.

4. In the Compute Units Usage table, investigate all the queries that were executed on your tenant. For Managed Security tenants, make sure you select
from the MSSP Tenant Selection drop-down menu, the tenant for which you want to display the information. You can filter and sort according to the
following fields.

ID—Unique identifier representing the executed XQL API query.

Timestamp

For XQL API: date and time of query execution.

For Notebooks and BQ queries: date and time the query is charged.

Type—Indicates the type of query performed.

PAPI Key ID—API Key ID used to execute XQL APIs.

Query—The query description.

Compute Unit Usage—Displays how many query units were used to execute the query .

Tenant—Appears only in a Managed Security tenant. Displays which tenant executed an API query or Cold Storage query.

5. Investigate the XQL API or Cold Storage query results.

In the Compute Units Usage table, locate an XQL API or Cold Storage query, right-click and select Show Results.

The query is displayed on the XQL Search page where you can view the query results.

11 | Analytics
Abstract

Learn about the Cortex XDR analytics concepts.

11.1 | Analytics Concepts

Abstract

The Cortex XSIAM app uses an Analytics Engine to examine logs and data from your sensors.

Safeguarding a network requires a defense-in-depth strategy which utilizes current and patched software and hardware. Most strategies designed to keep
unwanted users out of a network stop intrusion attempts at the network perimeter, defending only against known threats. For example, systems scanning for
malicious software rely on previously identified MD5 signature databases. However, attackers constantly modify virus signatures to circumvent virus scanners.

Your network defense-in-depth strategy must include software and processes designed to detect and respond to an intruder who penetrates your systems. The
Cortex XSIAM app efficiently and automatically identifies abnormal activity on your network, while providing you with the exact information you need to rapidly
evaluate, isolate and remove potential threats.

Analytics Engine

Analytics Sensors

Coverage of MITRE Attack Tactics

Analytics Detection Time Intervals

Analytics Alerts and Analytics BIOCs

Identity Analytics

Identity Threat Module

Analytics Engine

The Cortex XSIAM app uses its Analytics Engine to examine logs and data retrieved from your sensors on the Cortex XSIAM tenants to build an activity
baseline, and recognize abnormal activity when it occurs. The Analytics Engine accesses your logs as they are streamed to the Cortex XSIAM tenant, including
any Firewall data, and analyzes the data as soon as it arrives. Cortex XSIAM raises an Analytics alert when the Analytics Engine determines an anomaly.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 762/1003
5/8/24, 9:18 AM PDF Export

The Analytics Engine examines traffic and data from a variety of sources such as network activity from firewall logs, VPN logs (from Prisma Access from the
Panorama plugin), endpoint activity data (on Windows endpoints), Active Directory or a combination of these sources, to identify the endpoints and users on
your network. After identifying the endpoints and the users, the Analytics Engine collects relevant details about each asset based on the information it obtains
from the logs to create profiles. The Analytics Engine can detect threats from only network data or only endpoint data, but for more context when investigating an
alert, we recommend using a combination of data sources.

Cortex XSIAM also enables analytics to run on all mapped network and authentication data. For more information, see MODEL.

The Analytics Engine creates and maintains the profiles to view the activity of the endpoint or user in context by comparing it to similar endpoints or users. The
large number of Profile types can generally be placed into one of three categories.

Peer Group Profiles—A statistical analysis of an entity or an entity relation that compares activities from multiple entities in a peer group. For example, a
domain can have a cross-organization popularity profile or per peer group popularity profile.

Temporal Profiles—A statistical analysis of an entity or an entity relation that compares the same entity to itself over time. For example, a host can have a
Profile depending on the number of ports it accessed in the past.

Entity classification—A model detecting the role of an entity. For example, users can be classified as service accounts, and hosts as domain controllers.

Analytics Sensors

To detect anomalous behavior, Cortex XSIAM can analyze logs and data from a variety of sensors.

Sensor Description

Palo Alto Networks sensors

Firewall traffic logs Palo Alto Networks Firewalls perform traditional and next-generation firewall
activities. The Cortex XSIAM Analytics Engine can analyze Palo Alto Networks
firewall logs to obtain intelligence about the traffic on your network. A Palo Alto
Networks firewall can also enforce Security policies based on IP addresses and
domains associated with Analytics alerts with external dynamic lists.

Enhanced application logs (EAL) To provide greater coverage and accuracy, you can enable enhanced application
logging on your Palo Alto Networks firewalls. Enhanced Application Logs (EAL)
are collected by the firewall to increase visibility into network activity for Palo Alto
Networks apps and services, like Cortex XSIAM.

Examples of the types of data that enhanced application logs gather include
records of DNS queries, the HTTP header User Agent field that specifies the web
browser or tool used to access a URL, and information about DHCP automatic IP
address assignment. For example, with DHCP information, Cortex XSIAM can
raise an alert when it detects unusual activity based on hostname instead of IP
address. This enables the security analyst to meaningfully assess whether the
user’s activity is within the scope of their role, and if not, to stop the activity.

GlobalProtect and Prisma Access logs If you use GlobalProtect or Prisma Access to extend your firewall security
coverage to your mobile users, Cortex XSIAM can analyze VPN traffic to detect
anomalous behavior on mobile endpoints.

Firewall URL logs (part of firewall threat logs) Palo Alto Networks firewalls can log Threat log entries when traffic matches one
of the Security Profiles attached to a security rule on the firewall. Cortex XSIAM
can analyze entries for Threat logs relating to URLs and raise alerts that indicate
malicious behavior such as command and control and exfiltration.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 763/1003
5/8/24, 9:18 AM PDF Export

Sensor Description

Cortex XSIAM agent endpoint data With a Cortex XSIAM Pro per Endpoint license, you can deploy Cortex XDR
agents on your endpoints to protect them from malware and software exploits.
The Analytics Engine can also analyze the EDR data collected by the agent to
raise alerts. To collect EDR data, you must install Cortex XDR agent 6.0 or a later
release on your Windows endpoints (Windows 7 SP1 or later).

The Cortex XSIAM Analytics Engine can analyze activity and traffic based solely
on endpoint activity data sent from Cortex XDR agents. For increased coverage
and greater insight during investigations, use a combination of Cortex XDR agent
data and firewalls to supply activity logs for analysis.

Pathfinder data collector In a firewall-only deployment where the Cortex XDR agent is not installed on
your endpoints, you can use Pathfinder to monitor endpoints. Pathfinder scans
unmanaged hosts, servers, and workstations for malicious activity. The Analytics
Engine can also analyze the Pathfinder data collector in combination with other
data sources to increase coverage of your network and endpoints, and to provide
more context when investigating alerts.

Directory Sync logs If you use the Cloud Identity Engine to provide Cortex XSIAM with Active
Directory data, the Analytics Engine can also raise alerts on your Active Directory
logs.

External sensors

Third-party firewall logs If you use non-Palo Alto Networks firewalls - Check Point, Fortinet, Cisco ASA -
in addition to or instead of Palo Alto Networks firewalls, you can set up a syslog
collector to facilitate log and alert ingestion. By sending your firewall logs to
Cortex XSIAM , you can increase detection coverage and take advantage of
Cortex XSIAM analysis capabilities. When Cortex XSIAM analyzes your firewall
logs and detects anomalous behavior, it raises an alert.

Third-party authentication service logs If you use an authentication service—Microsoft Azure AD, Okta, or PingOne—
you can set up log collection to ingest authentication logs and data into
authentication stories.

Windows Event Collector logs The Windows Event Collector (WEC) runs on the Broker VM collecting event
logs from Domain Controllers (DCs). The Analytics Engine can analyze these
event logs to raise alerts such as for credential access and defense evasion.

Coverage of MITRE Attack Tactics

Network attacks follow predictable patterns. If you interfere with any portion of this pattern, the attack is neutralized.

The Analytics Engine can raise an alert for any of the following attack tactics as defined by the MITRE ATT&CK™ knowledge base of tactics.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 764/1003
5/8/24, 9:18 AM PDF Export

Tactic Description

Execution After attackers gain a foothold in your network, they can use various
techniques to execute malicious code on a local or remote endpoint.

The Cortex XSIAM app detects malware and grayware on your network
using a combination of network activity, Pathfinder data collector of your
unmanaged endpoints, endpoint data from your Cortex XDR agents, and
evaluation of suspicious files using the WildFire cloud service.

Persistence To carry out a malicious action, an attacker can try techniques that maintain
access in a network or on an endpoint. An attacker can initiate configuration
changes—such as a system restart or failure—that require the endpoint to
restart a remote access tool or open a back door that allows the attacker to
regain access on the endpoint.

Discovery When an attacker has access to a part of your network, they use discovery
techniques to explore and identify subnets, servers and services that are
hosted on those endpoints. They aim to identify vulnerabilities within your
network.

The app detects these tactics by looking for indicators in your internal
network traffic such as changes in connectivity patterns, including increased
rates of connections, failed connections, and port scans.

Lateral Movement To expand the footprint inside your network, an attacker uses lateral
movement techniques to obtain credentials for additional access to more
data in the network.

The Analytics Engine detects attacks during this phase by examining

administrative operations (such as SSH, RDP, and HTTP), file share access,
and user credential usage that is beyond the norm for your network. The
app looks for indicators like increased administrative activity, SMB usage,
and remote code execution.

Command and Control The command and control tactic allows an attacker to remotely issue
commands to an endpoint and receive information from it. The Analytics
Engine identifies intruders using this tactic by looking for anomalies in
outbound connections, DNS lookups, and endpoint processes with bound
ports. The app detects unexplained changes in the periodicity of
connections and failed DNS lookups, changes in random DNS lookups, and
other indicators that suggest an attacker has gained initial control of a
system.

Exfiltration Exfiltration tactics are techniques used to retrieve data from a network, such
as valuable enterprise data. The app identifies this type of attack by
examining outbound connections with a focus on the volume of data being
transferred. Increases in this volume are an important symptom of data
exfiltration.

Analytics Detection Time Intervals

The Cortex XSIAM Analytics Engine retrieves logs from the Cortex XSIAM tenant to create a baseline so that it can raise alerts when abnormal activity occurs.
This analysis is highly sophisticated and performed on more than a thousand dimensions of data. Internally, Cortex XSIAM organizes its analytics activity into
algorithms called detectors. Each detector is responsible for raising an alert when suspicious behavior is detected.

To raise alerts, each detector compares the recent past behavior to the expected baseline by examining the data found in your logs. A certain amount of log file
time is required to establish a baseline and then a certain amount of recent log file time is required to identify what is currently happening in your environment.

There are several meaningful time intervals for Cortex XSIAM Analytics detectors:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 765/1003
5/8/24, 9:18 AM PDF Export

Time Interval Description

Activation Period The shortest amount of log file time before the app can raise an alert. This is
typically the period between the time a detector first starts running and the
time you see an alert. However, in some cases, detectors pause after an
upgrade as they enter a new activation period.

Most but not all detectors start running after the activation period ends. The
activation period provides the detector enough data to establish a baseline,
which in turn helps to avoid false positives.

The activation period is also called the profiling or waiting period and, is
informally referred to as soak time.

Test Period The amount of logging time that a detector uses to determine if unusual
activity is occurring on your network. The detector compares test period
data to the baseline created during the training period, and uses that
comparison to identify abnormal behavior.

Training Period The amount of logging time that the detector requires to establish a
baseline, and to identify the behavioral limits beyond which an alert is
raised. Because your network is not static in terms of its topology or usage,
detectors are constantly updating the baselines that they require for their
analytics. For this update process, the training period is how far back in time
the detector goes to update and tune the baseline.

This period is also referred to as the baseline period.

NOTE:

When establishing a baseline, detectors compute limits beyond which

network activity will require an alert. In some cases, detectors do not
compute baseline limits; instead they are predetermined by Cortex
XSIAM engineers. The engineers determine the values used for
predetermined limits using statistical analysis of malicious activity
recorded worldwide. The engineers routinely perform this statistical
analysis and update the predetermined limits as needed with each
release of Cortex XSIAM.

Deduplication Period The amount of time in which additional alerts for the same activity or
behavior are suppressed before Cortex XSIAM raises another Analytics
alert.

These time periods are different for every Cortex XSIAM Analytics detector. The actual amount of logging data (measured in time) required to raise any given
Cortex XSIAM Analytics alert is identified in the Cortex XDR Analytics Alert Reference Guide.

Analytics Alerts and Analytics BIOCs

The XDR Analytics Engine raises an alert when it detects suspicious activity, composed up of multiple events, that deviates from the behavior baseline it
establishes over time. To ensure the Analytics detectors raise alerts efficiently and do not overcrowd your Alerts table, Cortex XSIAM automatically disables
alerts from detectors that reach 5000 or more hits over a 24 hour period.

In addition to standard Analytics alerts, there is another category of alerts for Analytics behavioral indicators of compromise (BIOC)s. In contrast to standard
Analytics alerts, Analytics BIOCs (ABIOCs)—indicate a single event of suspicious behavior with an identified chain of causality. To identify the context and chain
of causality, ABIOCs leverage user, endpoint, and network profiles. The profile is generated by the Analytics Engine and can be based on a simple statistical
profile or a more complex machine-learning profile. Cortex XSIAM tailors each ABIOC to your specific environment after analyzing your logs and data sources
and continually tunes and delivers new ABIOCs with content updates.

Identity Analytics

Cortex XSIAM enables you investigate suspicious user activity information using Identity Analytics. When enabled, Identity Analytics aggregates and displays
user profile information, activity, and alerts associated with a user-based Analytics type alert and Analytics BIOC rule.

To easily track the alerts and Analytics BIOC rules, Cortex XSIAM displays an Identity Analytics tag in the Alerts table > Alert Name field and Analytics BIOC
Rules table > Name field. In the Analytics Alert View, when selecting the User node, Cortex XSIAM details the active directory group, organizational unit, role,
logins, hosts, alerts, and process executions associated with the user.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 766/1003
5/8/24, 9:18 AM PDF Export

To enable Identity Analytics, you must first:

Set Up Cloud Identity Engine (Formally Directory Sync Services (DSS))

Activate Cortex XDR Analytics

After configuring your Cloud Identity Engine instance and Cortex XSIAM Analytics, select Settings ( ) → Configurations → Cortex XSIAM - Analytics ,and in
the Featured in Analytics section, Enable Identity Analytics.

Identity Threat Module

The Identity Threat module provides superior coverage for stealthy identity threat vectors, including compromised accounts and insider threats. The module is
available as an add-on and includes the following UI features.

Automated and customizable Asset Role classification based on constant analysis of the users and host in your network. You can edit and manage the
User Asset Roles and Host Asset Roles to meet the needs of your organization.

The Behavioral Analytics tab in the Alert Panel view that displays background information for quicker triaging and investigation. This enables you to
analyze the deviation that triggered the alert against the backdrop of baseline behavior.

Risk Management Dashboard for reviewing the risk posture of the organization and enabling faster decision making. The dashboard contains a number of
Metrics widgets that present statistical risk information for your organization.

User Risk View and Host Risk View which provide additional information about the asset, including score trend timeline, notable events, peer comparison,
and additional asset-associated alerts and insights for easy uncovering of hidden threats.

12 | Asset Management
Abstract

Cortex XSIAM enables you to manage and configure your network parameters and assets, and cloud inventory assets.

12.1 | Network Configuration

Abstract

Cortex XSIAM Network Configuration provides a representation of your network assets by collecting and analyzing your network resources.

Network asset visibility is a crucial investigative tool in discovering rogue devices in your network and preventing malicious activity. Understanding how many
managed and unmanaged assets are part of your network provides you with vital information to better assess your security exposure and track network
communication.

Cortex XSIAM Network Configuration provides an accurate representation of your network assets by collecting and analyzing the following network resources.

User-defined IP Address Ranges and Domain Names associated with your internal network

EDR data collected by Firewall Logs

Cortex XSIAM Agent Logs

ARP Cache

Broker VM Network Mapper

Pathfinder Data Collector

In addition to the network resources, Cortex XSIAM allows you to configure in your Windows Agent Profile a Cortex XDR agent scan of your endpoints using
Ping that provides updated identifiers of your network assets, such as IP addresses and OS platforms. The scan is automatically distributed by Cortex XSIAM to
all the agents configured in the profile and cannot be initiated by request.

With the data aggregated by Cortex XSIAM Network Configuration you can locate and manage your assets more effectively and reduce the amount of research
required to.

Distinguish between assets managed and unmanaged by a Cortex XDR agent.

Identify assets that are part of your internal network.

Track network data communications from within and outside your network.

12.1.1 | Configure Your Network Parameters

Abstract

Define the IP address ranges and domain names used by Cortex XSIAM to identify your network assets.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 767/1003
5/8/24, 9:18 AM PDF Export

To track and identify assets in your network, you need to define your internal IP address ranges and domain names to enable Cortex XSIAM to analyze, locate,
and display assets.

Define Internal IP Address Ranges

1. In Cortex XSIAM , select Assets → Network Configuration → Internal IP Address Ranges.

2. Define an IP Address Range.

By default, Cortex XSIAM creates Private Network ranges that specify reserved industry-approved ranges. Private Network ranges are marked with a
icon and can only have the name edited.

To Add New Range select either.

Create New

In the Create IP Address Rage pop-up, enter the IP address Name and IP Address Range or CIDR values.

NOTE:

You can add a range that is fully contained in an existing range, however, you cannot add a new range that partially intersects with another
range.

The range names you define will appear when investigating the network-related events within the Cortex XSIAM console.

Save your definitions.

Upload from File

In the Upload IP Address Ranges pop-up, drag and drop or search for a CSV file listing the IP address ranges. Download example file to view
the correct format.

Add your list of IP address ranges.

3. Review your IP address ranges.

After you named and defined your IP address ranges, review the following information:

The IP Address Ranges table displays the following fields:

Range Name—Name of the IP address range you define.

First IP Address—First IP address value of the defined range.

Last IP Address—Last IP address value of the defined range.

Active Assets—Number of assets located within the defined range that have reported Cortex Agent logs or appeared in your Network Firewall Logs.

Active Managed Assets—Number of assets located within the defined range that are reported Cortex XSIAM Agent logs.

Modified By—User name of the user who last changed the range.

Modification Time—Timestamp of when this range was last changed.

4. Manage your IP address ranges.

In the IP Address Ranges table, locate your range and select:

Edit range—Edit the IP address configurations. Changes made will affect the Broker VM Network Mapper.

Delete range—Delete the IP address range.

View External IP Address Ranges

Abstract

The External IP Address Ranges page lists all external IP addresses attributed to your organization.

NOTE:

Viewing external IP address ranges requires the Attack Surface Management add-on.

An external IP address range is an IP address range that Cortex XSIAM has discovered through ASM scans and attributed to your organization. The complete
list of external IP Address Ranges can be viewed on the External IP Address Ranges page, as explained in the following steps. External IP address range
information is also available on asset details pages when an external IP address is used to attribute an asset to your organization.

1. In Cortex XSIAM, go to Assets → Network Configuration → IP Address Ranges → External IP Address Ranges.

2. Review your external IP address ranges, as needed.

The IP Address Ranges table displays the following fields:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 768/1003
5/8/24, 9:18 AM PDF Export

First IP Address—First IP address value of the defined range.

Last IP Address—Last IP address value of the defined range.

IPs Count—Number of IP addresses in the range.

Active Responsive IPS count

Business Units—Business units associated with this external IP range.

Date Added—The first time that Cortex XSIAM identified this IP Range.

3. Display details about an external IP range by selecting a row in the table.

The detailed view displays to the right of the table. External IP address range details include registration data, which Cortex XSIAM pulls from public RIR
(Regional Internet Registries) databases. Registration data includes network records and organization records.

Define Domain Names

1. In Cortex XSIAM , select Assets → Network Configuration → Internal Domain Suffixes.

2. In the Internal Domain Suffixes section, +Add the domain suffix you want to include as part of your internal network. For example, acme.com.

3. Select to add to the Domains List.

12.2 | Vulnerability Assessment

Abstract

Perform a vulnerability assessment of all endpoints in your network using Cortex XSIAM. This includes CVE, endpoint, and application analysis.

Cortex XSIAM vulnerability assessment enables you to identify and quantify the security vulnerabilities on an endpoint. After evaluating the risks to which each
endpoint is exposed and the vulnerability status of an installed application in your network, you can mitigate and patch these vulnerabilities on all the endpoints
in your organization.

Legacy Vulnerability Assessment

For a comprehensive understanding of the vulnerability severity, Cortex XSIAM retrieves the latest data for each Common Vulnerabilities and Exposures (CVE)
from the NIST National Vulnerability Database, including CVE severity and metrics.

PREREQUISITE:

The following are prerequisites for Cortex XSIAM to perform a vulnerability assessment of your endpoints.

Requirement Description

Licenses and Add-ons Host Insights Add-on.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 769/1003
5/8/24, 9:18 AM PDF Export

Requirement Description

Supported Platforms Windows

Cortex XDR agent 7.1 or a later release.

Cortex XSIAM lists only CVEs relating to the operating system, and not CVEs
relating to applications provided by other vendors.

Cortex XSIAM retrieves the latest data for each CVE from the NIST National
Vulnerability Database as well as from the Microsoft Security Response Center
(MSRC).

Cortex XSIAM collects KB and application information from the agents but
calculates CVE only for KBs based on the data collected from MSRC and other
sources

For endpoints running Windows Insider, Cortex XSIAM cannot guarantee an

accurate CVE assessment.

Cortex XSIAM does not display open CVEs for endpoints running Windows
releases for which Microsoft no longer fixes CVEs.

Linux

Cortex XDR agent 7.1 or a later release.

Cortex XSIAM collects all the information about the operating system and the installed
applications, and calculates CVE based on the the latest data retrieved from the NIST.

MacOS

Cortex XDR agent 7.1 or a later release.

Cortex XSIAM collects only the applications list from MacOS without CVE
calculation.

If Cortex XSIAM doesn't match any CVE to its corresponding application, an error message is
displayed, "No CVEs Found".

Setup and Permissions Ensure Host Inventory Data Collection is enabled for your Cortex XDR agent.

Limitations Cortex XSIAM calculates CVEs for applications according to the application version, and not
according to application build numbers.

Enhanced Vulnerability Assessment

The Enhanced Vulnerability Assessment mode uses an advanced algorithm to collect extensive details on CVEs from comprehensive databases and to produce
an in-depth analysis of the endpoint vulnerabilities. Turn on the Enhanced Vulnerability Assessment mode from Settings → Configurations → Vulnerability
Assessment. This option may be disabled for the first few days after updating Cortex XSIAM as the Enhanced Vulnerability Assessment engine is initialized.

PREREQUISITE:

The following are prerequisites for Cortex XSIAM to perform an Enhanced Vulnerability Assessment of your endpoints.

Requirement Description

Licenses and Add-ons Host Insights Add-on.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 770/1003
5/8/24, 9:18 AM PDF Export

Requirement Description

Supported Platforms Windows

Cortex XDR agent 8.3 or a later release.

Cortex XSIAM collects all the information about the operating system and the
installed applications, and calculates CVE based on the latest data retrieved from
the NIST.

CVEs that apply to applications that are installed by one user aren't detected when
another user without the application installed is logged in during the scan.

MacOS

Cortex XDR agent 8.3 or a later release.

Cortex XSIAM collects all the information about the operating system and the
installed applications, and calculates CVE based on the latest data retrieved from
the NIST.

Setup and Permissions Ensure Host Inventory Data Collection is enabled for your Cortex XDR agent.

Limitations Some CVEs may be outdated if the Cortex XDR agent wasn't updated recently.

Application versions which have reached end-of-life (EOL) may have their version listed
as 0. This doesn't affect the detection of the CVEs.

Some applications are listed twice. One of the instances may display invalid version,
however, this doesn't affect the functionality.

The scanning process may impact performance on the Cortex XDR agent during
scanning. The scan may take up to two minutes.

You can access the Vulnerability Assessment panel from Assets → Vulnerability Assessment.

Collecting the initial data from all endpoints in your network could take up to 6 hours. After that, Cortex XSIAM initiates periodical recalculations to rescan the
endpoints and retrieve the updated data. If at any point you want to force data recalculation, click Recalculate. The recalculation performed by any user on a
tenant updates the list displayed to every user on the same tenant.

CVE Analysis

To evaluate the extent and severity of each CVE across your endpoints, you can drill down into each CVE in Cortex XSIAM and view all the endpoints and
applications in your environment that are impacted by the CVE. Cortex XSIAM retrieves the latest information from the NIST public database. From Assets →
Host Insights → Vulnerability Assessment, select CVEs on the upper-right bar. This information is also available in the va_cves dataset, which you can use to
build queries in XQL Search.

If you have the Identity Threat Module enabled, you can also view the CVE analysis in the Host Risk View. To do so, from Assets → Asset Scores, select
the Hosts tab, right click on any endpoint, and select Open Host Risk View.

For each vulnerability, Cortex XSIAM displays the following default and optional values.

Value Description

Affected endpoints The number of endpoints that are currently affected by this CVE. For
excluded CVEs, the affected endpoints are N/A.

Applications The names of the applications affected by this CVE.

CVE The name of the CVE.

TIP:

You can click each individual CVE to view in-depth details about it on a
panel that appears on the right.

Description The general NIST description of the CVE.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 771/1003
5/8/24, 9:18 AM PDF Export

Value Description

Excluded Indicates whether this CVE is excluded from all endpoint and application
views and filters, and from all Host Insights widgets.

Platforms The name and version of the operating system affected by this CVE.

Severity The severity level (Critical, High, Medium, or Low) of the CVE as ranked in
the NIST database.

Severity score The CVE severity score is based on the NIST Common Vulnerability Scoring
System (CVSS). Click the score to see the full CVSS description.

You can perform the following actions from Cortex XSIAM as you analyze the existing vulnerabilities:

View CVE details—Left-click the CVE to view in-depth details about it on a panel that appears on the right. Use the in-panel links as needed.

View a complete list of all endpoints in your network that are impacted by a CVE—Right-click the CVE and then select View affected endpoints.

Learn more about the applications in your network that are impacted by a CVE—Right-click the CVE and then select View applications.

Exclude irrelevant CVEs from your endpoints and applications analysis—Right-click the CVE and then select Exclude. You can add a comment if
needed, as well as Report CVE as incorrect for further analysis and investigation by Palo Alto Networks. The CVE is grayed out and labeled Excluded and
no longer appears on the Endpoints and Applications views in Vulnerability Assessment, or in the Host Insights widgets. To restore the CVE, you can right-
click the CVE and Undo exclusion at any time.

NOTE:

The CVE will be removed/reinstated to all views, filters, and widgets after the next vulnerability recalculation.

Endpoint Analysis

To help you assess the vulnerability status of an endpoint, Cortex XSIAM provides a full list of all installed applications and existing CVEs per endpoint and also
assigns each endpoint a vulnerability severity score that reflects the highest NIST vulnerability score detected on the endpoint. This information helps you to
determine the best course of action for remediating each endpoint. From Assets → Vulnerability Assessment, select Endpoints on the upper-right bar. This
information is also available in the va_endpoints dataset. In addition, the host_inventory_endpoints preset lists all endpoints, CVE data, and additional metadata
regarding the endpoint information. You can use this dataset and preset to build queries in XQL Search.

For each vulnerability, Cortex XDR displays the following default and optional values.

Value Description

CVEs A list of all CVEs that exist on applications that are installed on the endpoint.

Endpoint ID Unique ID assigned by Cortex XSIAM that identifies the endpoint.

Endpoint name Hostname of the endpoint.

TIP:

You can click each individual endpoint to view in-depth details about it on
a panel that appears on the right.

Last Reported Timestamp The date and time of the last time the Cortex XDR agent started the process
of reporting its application inventory to Cortex XSIAM.

MAC address The MAC address associated with the endpoint.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 772/1003
5/8/24, 9:18 AM PDF Export

Value Description

IP address The IP address associated with the endpoint.

Platform The name of the platform running on the endpoint.

Severity The severity level (Critical, High, Medium, or Low) of the CVE as ranked in
the NIST database.

Severity score The CVE severity score based on the NIST Common Vulnerability Scoring
System (CVSS). Click the score to see the full CVSS description.

You can perform the following actions from Cortex XSIAM as you investigate and remediate your endpoints:

View endpoint details—Left-click the endpoint to view in-depth details about it on a panel that appears on the right. Use the in-panel links as needed.

View a complete list of all applications installed on an endpoint—Right-click the endpoint and then select View installed applications. This list
includes the application name, version, and installation path on the endpoint. If an installed application has known vulnerabilities, Cortex XSIAM also
displays the list of CVEs and the highest Severity.

(Windows only) Isolate an endpoint from your network—Right-click the endpoint and then select Isolate the endpoint before or during your remediation
to allow the Cortex XSIAM agent to communicate only with Cortex XSIAM .

(Windows only) View a complete list of all KBs installed on an endpoint—Right-click the endpoint and then select View installed KBs. This list includes
all the Microsoft Windows patches that were installed on the endpoint and a link to the Microsoft official Knowledge Base (KB) support article. This
information is also available in the host_inventory_kbs preset, which you can use to build queries in XQL Search.

Retrieve an updated list of applications installed on an endpoint—Right-click the endpoint and then select Rescan endpoint.

Application Analysis

You can assess the vulnerability status of applications in your network using the Host inventory. Cortex XSIAM compiles an application inventory of all the
applications installed in your network by collecting from each Cortex XDR agent the list of installed applications. For each application on the list, you can see the
existing CVEs and the vulnerability severity score that reflects the highest NIST vulnerability score detected for the application. Any new application installed on
the endpoint will appear in Cortex XSIAM within 24 hours. Alternatively, you can re-scan the endpoint to retrieve the most updated list.

NOTE:

Starting with macOS 10.15, Mac built-in system applications are not reported by the Cortex XDR agent and are not part of the Cortex XSIAM Application
Inventory.

From Incident Response → Host Inventory, select Applications.

To view the details of all the endpoints in your network on which an application is installed, right-click the application and select View endpoints.

To view in-depth details about the application, left-click the application name.

12.3 | Cloud Compliance

Abstract

Learn more about Cloud Compliance in Cortex XSIAM.

Cloud Compliance performs the Center for Internet Security (CIS) benchmarking compliance checks on endpoint resources for Linux and Kubernetes agents.
Cloud Compliance is mainly designed for cloud based Linux assets and Kubernetes hosts, but can also provide the same metric data for on-prem Linux
appliances. As a result, Cloud Compliance provides you with an overview of violations in terms of Cloud Security posture on your Linux boxes in terms of Linux
and container compliances, and also for Kubernetes, when applicable.

To receive data in the Cloud Compliance page, you need to configure your Linux agent settings profile to collect this data by selecting under XDR Pro the enable
cloud compliance collection option. The endpoints require this data collection option enabled for around 12 hours to set the benchmarks and display the results
in the Cloud Compliance page.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 773/1003
5/8/24, 9:18 AM PDF Export

12.4 | Manage Asset Scores

Abstract

Learn how to view and investigate User Scores and Host Scores using the Asset Scores page.

The Asset Scores page provides a central location from which you can view and investigate information relating to User Scores and Host Scores in your
network.

Cortex XSIAM aggregates data from Workday and Active Directory to create a list of user and host assets located within your network. When alerts and
incidents occur, they are associated with a host or user asset and Cortex XSIAM calculates a score that represents the risk level of each asset. This score can
help you to identify high-risk assets in your organization, and detect compromised accounts and malicious activities.

You can decide to Include System Users in the table, such as SYSTEM, administrators, NT authority and others.

NOTE:

As new alerts are associated with incidents, the User and Host Scores are recalculated. You can view the latest User and Host Scores on the Asset Scores
page, or track the Score trend on the User Risk View and Host Risk View.

To investigate your users and hosts, take the following steps.

1. Select Assets → Asset Scores. Use the toggle in the page header to switch between the USERS and HOSTS tabs.

NOTE:

The HOSTS tab is available only if the Identity Threat Module add-on is enabled.

2. Filter and review your assets.

The following table describes the fields in the USERS tab.

Read more...

Field Description

STARRED Whether the user is included in the watchlist.

USER SCORE Represents the Cortex XSIAM high-risk user score. The score is updated
continuously as new alerts are associated with incidents.

USER NAME Name of the user as provided by Cortex XSIAM.

FULL NAME Name of the user as provided by Workday or Active Directory.

DEPARTMENT Department of the user as provided by Workday or Active Directory.

PHONE NUMBER Phone number of user as provided by Workday or Active Directory.

EMAIL Email of the user as provided by Workday or Active Directory.

MEMBER OF (Derived from AD) The security groups that the user is associated with.

FEATURED Whether the user is flagged as a featured user in the platform.

LOCATION Location of the user as provided by Workday or Active Directory.

LAST LOGIN Last date and time the user accessed Cortex XSIAM.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 774/1003
5/8/24, 9:18 AM PDF Export

Field Description

ASSET ROLE Asset roles that the user is associated with.

The following table describes the fields in the HOSTS tab.

Read more...

Field Description

STARRED Whether the host is included in the watchlist.

HOSTNAME Unique ID of the host.

HOST SCORE Host score.

IP IP on which the endpoint is running.

HAS XDR AGENT Whether the endpoint has an XDR agent installed.

USERS Users assigned to the endpoint.

AGENT INSTALLATION DATE Date and time that the XDR agent was installed.

LAST COMMUNICATION Date and time of last communication.

OPERATING SYSTEM Operating system with which the endpoint is running.

ENDPOINT ISOLATED Whether the endpoint is isolated.

FEATURED Whether the host is flagged as a featured host in the platform.

TAGS Endpoint tags applied to the host.

GROUP NAMES User groups that the host is associated with.

ASSET ROLE Asset roles that the host is associated with.

3. Investigate further by locating the user or host you want to investigate, right-click and Open User Risk View or Host Risk View. For more information, see
Investigate a User and Investigate a Host.

NOTE:

Some User Associated Insights may not appear as part of the User Associated Incidents due to the insight generation mechanism. For example, when
an insight related to one of the assets in an incident is generated a few days after the associated incident, the insight may not be associated with the
incident.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 775/1003
5/8/24, 9:18 AM PDF Export

12.5 | Unified Asset Inventory

Abstract

From the Unified Asset Inventory page, you can view all of your on-prem and cloud assets in one place.

Cortex XSIAM provides a unified asset inventory that combines all of your on-prem and cloud assets in one place. Cortex XSIAM collects assets from multiple
sources. This data is then stitched and normalized to create an aggregated asset, showing you a consolidated view of all the data sources that belong to a
single asset.

The Assets → Asset Inventory page lets you view all the assets that Cortex XSIAM has attributed to your organization.

NOTE:

The Unified Asset Inventory page is currently in beta.

To use the Unified Asset Inventory, set the toggle to Unified Inventory on the Asset Inventory page. The documentation in this section describes the Unified
Asset Inventory.

If you prefer to use the previous version of the asset inventory, see existing asset inventory.

12.5.1 | Using the Unified Asset Inventory page

Abstract

The Unified Asset Inventory page displays all aggregated assets according to their data source(s).

To view the Unified Asset Inventory page, select Assets → Asset Inventory.

The Unified Asset Inventory page displays all aggregated assets according to their data source(s), where you can:

Click the aggregated asset itself for more detailed information via the side panel that appears.

Click on the expand icon of a given asset to see the data source(s) that contribute to a single asset.

Click each data source for more information via the side panel that appears.

Filtering assets

Click the filter icon to narrow results and search for specific assets.

By default the filter is set to Source: XSIAM, to filter based on the attributes in the aggregated asset.

To search based on data received from a specific source within an aggregated asset, filter by the specific data source. For example, select the source Cortex
XDR Agent to filter based on the asset data provided by the XSIAM agent.

In all cases, a list of aggregated assets that match the filter is displayed.

The following is a list of the fields displayed on the Unified Asset Inventory page. The assets shown and their data depend on your licensing and add-ons.

Field Description

Data sources Data sources that are attributed to an asset.

Name Displays the name that describes the asset.

Cloud provider The cloud provider that hosts cloud assets, such as GCP, AWS, or Azure.

Category Asset types given by each cloud vendor are normalized into this field.

Class Grouping of assets according to industry standards. For example, Compute,

Network, and Storage.

Cloud ID Displays the Resource ID as provided by the cloud provider.

Cloud GEO region The normalized value indicates the geographic region, such as North
America or the Middle East.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 776/1003
5/8/24, 9:18 AM PDF Export

Field Description

Cloud region The normalized value of the region.

Cloud zone Identifies the normalized zones within which cloud resources are deployed.

Cloud project Displays the project name associated with the respective Cloud provider:

AWS: Account

GCP: Project

Microsoft Azure: Subscription

Cloud project ID Displays the associated project ID as provided by the Cloud provider.

Cloud project hierarchy Organizational structure of cloud projects. Shows the hierarchy of ownership
with the cloud vendor.

Operating system family The operating system of the asset. For example, for Windows 10 and
Windows Server 2019, Windows will be listed as the operating system
family.

Operating system The operating system of the device.

Source tags The collection of tags that are associated with the asset in each source e.g.
cloud tags.

Activity status Activity status can be live unseen or deleted.

Agent identifier The ID of the endpoint protection agent installed on the asset.

Agent exists If there is an endpoint protection agent.

Is externally accessible Specifies whether the asset is accessible externally.

Vulnerability score Based on CVEs with the highest severity.

CVEs The CVEs as reported by data sources.

IPV4 addresses IPV4 addresses belonging to the asset.

MAC addresses MAC Addresses belonging to the asset.

IPV4 public addresses IPV4 public addresses belonging to the asset.

IPV6 addresses IPV6 addresses belonging to the asset.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 777/1003
5/8/24, 9:18 AM PDF Export

Field Description

Has active external services Indicates whether a system or network has active services accessible from
external networks.

Active external service types Specifies the types or categories of services running and accessible from
external networks.

First seen Timestamp of when the asset was first seen by the source that reported it.

Last seen Timestamp of when the asset was last seen by the source that reported it.

Certificate details formatted issuer org The issuing organization of the certificate.

Certificate algorithm Specifies the cryptographic algorithm used for generating digital signatures
within the certificate.

Certificate classifications Certificate classifications categorize digital certificates based on their

attributes.

Domain resolves Whether or not a domain name successfully resolves to an IP address.

Device category The classification or type of device within a network infrastructure.

Device model The specific model or version of a device within a network infrastructure.

12.6 | Existing Asset Inventory

NOTE:

The documentation in this section describes the existing asset inventory. Cortex XSIAM now provides a unified asset inventory that combines all of your on-
prem and cloud assets in one place.

If you prefer to use the unified asset inventory, see asset inventory.

12.6.1 | All Assets

Abstract

Cortex XSIAM enables you to view all external assets from the various asset categories on the All Assets page.

NOTE:

Ingesting and Viewing Cloud Compute Instances for Cloud Inventory Assets requires a Cortex XSIAM Pro per GB license.

NOTE:

Viewing Unassociated Responsive IPs, Domains, and Certificates data for Attack Surface Management requires the Attack Surface Management add-on.

The All Assets page enables you to view all your assets from various asset categories. Each asset is available in Cortex XSIAM in different ways depending on
the asset category and Cortex XSIAM license as explained in the following table.

Asset Category Availability In Cortex XSIAM License Required

On-Prem Automatically available Any license

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 778/1003
5/8/24, 9:18 AM PDF Export

Asset Category Availability In Cortex XSIAM License Required

Cloud Compute Instance Requires configuring either a Cloud Inventory data collector or Agents that are installed on Any license
the Cloud Compute Instances.

Unassociated Automatically available Attack Surface Management

Responsive IPs add-on

Domain Automatically available Attack Surface Management

add-on

Certificate Automatically available Attack Surface Management

add-on

To view the All Assets page, select Assets → Asset Inventory.

By default, the All Assets page displays all assets according to the asset name. To search for specific assets, use the filters above the results table to narrow the
results. You can export the tables and respective asset views to a tab-separated values (TSV) file. From the All Assets page, you can also manage the asset's
output using the right-click pivot menu.

The All Assets table is comprised of a number of common fields that are available when viewing any of the Specific Assets pages. The TYPE field is only
available in the All Assets table as this field determines the Specific Assets categories, and can be used to filter the different types of assets from the entire list of
assets.

When any row in the table is selected, a side panel on the right with greater details is displayed, where you can view additional data divided by sections. The
section heading names and data displayed change depending on the source of the assets.

The following table describes the fields that are available when viewing All Assets in alphabetical order.

NOTE:

Certain fields are exposed and hidden by default. An asterisk (*) is beside every field that is exposed by default.

Field Description

ACTIVE EXTERNAL An array column that displays all the active Service types observed for this asset.
SERVICES TYPES*

ASM IDs The ASM identifiers for this asset, indicate it is exposed to the Internet.

BUSINESS UNITS* A Business Unit is a designation to classify assets. tracks business units as a means to identify owning organizations of these
assets. Business units become extremely important when an organization has subsidiaries and groups established through
M&A activities.

CLOUD PROVIDER* The cloud provider used to collect these cloud assets is either GCP, AWS, or Azure.

NOTE:

This field only displays with a Cortex XSIAM Pro TB license.

CLOUD ID* Displays the Resource ID as provided by the cloud provider.

NOTE:

This field only displays with a Cortex XSIAM Pro TB license.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 779/1003
5/8/24, 9:18 AM PDF Export

Field Description

EXTERNALLY The provider of the asset is determined by an external assessment.

DETECTED
PROVIDERS*

FIRST OBSERVED* When the asset was first observed via any of the sources.

HAS ACTIVE EXTERNAL A boolean value that displays whether the asset has any active external services. Use this filter to narrow down the asset
SERVICES* inventory to internet-facing assets, and get a clear view of the organization's attack surface.

HAS XDR AGENT* Boolean value indicating if this asset has a Cortex XSIAM agent installed on it.

IP ADDRESSES* Array column specifying a list of IPs associated with this asset.

IP RANGE NAMES* Names of the IP address ranges allocated to the IP addresses.

LAST OBSERVED* When the asset was last observed via any of the sources.

MAC ADDRESSES* MAC addresses associated with this asset.

NAME* Displays the name that describes the asset as provided by the source, if provided.

OPERATING SYSTEM* The operating system reported by the source for this asset.

REGION* Displays the region as provided by the Cloud provider.

NOTE:

This field only displays with a Cortex XSIAM Pro TB license.

SOURCES* An array column that displays all the sources that provided observations for this asset.

TYPE* Type of asset, which can be defined as one of the following.

NOTE:

The options available are dependent on your Cortex XSIAM license.

Cloud Compute Instance

On-Prem

Certificate

Domain

Unassociated Responsive IPs

This field is unique to the All Assets table.

XDR AGENT ID If there is an endpoint installed on this asset, this is the endpoint ID.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 780/1003
5/8/24, 9:18 AM PDF Export

12.6.2 | All External Services

Abstract

The All External Services page presents the complete inventory of public internet-facing services attributed to your organization.

NOTE:

Viewing All External Services requires the Attack Surface Management add-on.

The All External Services page presents the complete inventory of public internet-facing services attributed to your organization. An external service can be any
internet-facing device or software that communicates on a domain:port or IP:port pair. The All External Services view enables your IT and security teams to
assess your total internet attack surface in detail. Some use cases include the following:

Enabling you to proactively reduce your attack surface, by providing a comprehensive view of your attack surface along with details about vulnerable
services.

Answering questions about what kinds of software and devices are being used.

Searching for specific software, technology, or configurations.

Discovering unused technology deployments or legacy software in need of updating.

To view the All External Services page, select Assets → Asset Inventory → All External Services.

By default, the All External Services page displays all external services according to the service name. To search for specific services, use the filters above the
results table to narrow the results or query the data using the XQL search. You can export the tables and respective service views to a tab-separated values
(TSV) file. From the All External Services page, you can also manage the output of the external services using the right-click pivot menu.

When any row in the All External Services table is selected, a side panel to the right of the table is displayed with details about the service.

The All External Services table includes the fields listed in the following table. Fields are listed in alphabetical order.

Field Description

ACTIVE CLASSIFICATIONS Facts that have been inferred about each of your services by examining a response for fingerprints. Classifications cover a
variety of details including:

Identifying specific software and versions.

Configuration details of note.

Identifying when the services do not implement best practices like web security headers or certificate security
standards.

Some Classifications merely note that a fact is true or false, like Missing Cache Control Header. Other Classifications
provide additional information, such as a version number for “nginx Server”. These details are viewable in the services
table and on the details page for the service by clicking the name of the service in the All External Services table.

BUSINESS UNITS A Business Unit is a designation to classify assets. Cortex XSIAM tracks business units as a means to identify owning
organizations of these assets. Business units become extremely important when an organization has subsidiaries and
groups established through M&A activities.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 781/1003
5/8/24, 9:18 AM PDF Export

Field Description

DISCOVERY TYPE Services are identified with one of the following two discovery types, depending on the level of confidence Cortex XSIAM
has in attributing it to your organization.

Directly Discovered—Services that are definitively associated with an asset that belongs to your organization.

Examples include:

It is hosted on one of your on-prem IP ranges.

The service advertises one of your organization's certificates.

It is on a managed cloud resource that is known to be yours.

Colocated with your Services—Service is running on the same IP as a different directly-discovered service.

In a multi-tenant hosting environment, these co-located services may belong to other organizations but can
sometimes pose adjacency risks to your services hosted on that IP. If your organization has “single-tenant
environment only” policies with 3rd party hosting providers, you can use this functionality to identify possible
violations of that policy.

DOMAIN The most recent domain on which the service is running.

EXTERNALLY DETECTED The provider of the asset is determined by an external assessment.

PROVIDERS

EXTERNALLY INFERRED Externally Inferred CVEs are identified by comparing the product name and version of active service, if identifiable, with
CVES CVES for those products in the National Vulnerability Database. Additional investigation may be required to confirm if the
CVE is present.

Click on the service to view the service details, which include the complete list of all the externally inferred CVEs.

EXTERNALLY INFERRED This score is based on the highest CVSSv3 score for Externally Inferred CVEs on this service. If there is no CVSSv3 score
VULNERABILITY SCORE for the CVE, then the CVSSv2 score is used.

This field applies only to services with Externally Inferred CVEs.

FIRST OBSERVED When the asset was first observed via any of the sources.

IP ADDRESSES Array column specifying a list of IPs associated with this asset.

IS ACTIVE Yes— indicates the service is active, which means that the service has been observed recently.

No— indicates the service is inactive, which means Cortex XSIAM no longer sees it on the internet.

LAST OBSERVED When the asset was last observed via any of the sources.

PORT The most recent port for the service.

PROTOCOL The application-level protocol on the public internet over which Cortex XSIAM validated the service.

SERVICE NAME The service type along with the specific domain:port or IP:port pair for the service.

SERVICE TYPE The type of server or software for the service.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 782/1003
5/8/24, 9:18 AM PDF Export

12.6.3 | Specific Assets

Abstract

Cortex XSIAM enables you to view specific external assets from a designated assets category in the Specific Assets page.

NOTE:

Ingesting and Viewing Cloud Compute Instances for Cloud Inventory Assets requires a Cortex XSIAM Pro per GB license.

NOTE:

Viewing Unassociated Responsive IPs, Domains, and Certificates data for Attack Surface Management requires the Attack Surface Management add-on.

The Specific Assets pages enable you to view specific assets from a designated asset category. Each specific table contains the common columns that are
listed in the All Assets table and some additional specific columns that are relevant for the type of asset.

To view the Specific Assets pages, select Assets → Asset Inventory → Specific Assets, and select a specific asset category.

By default, the Specific Assets pages display the assets according to the name of the asset. To search for specific assets, use the filters above the results table
to narrow the results. You can export the tables and respective asset views to a tab-separated values (TSV) file. From the Specific Assets page, you can also
manage the asset's output using the right-click pivot menu.

When any row in the table is selected, a side panel on the right with greater details is displayed, where you can view additional data divided by sections. The
section heading names and data displayed change depending on the source of the assets.

The table below describes the following for the different Specific Assets pages.

NOTE:

The Specific Assets listed are dependent on your Cortex XSIAM license. For more information, see All Assets.

Specific Assets—The name of the specific asset page.

Description—A brief description of the assets included on the specific asset page.

Unique Fields—The unique fields that are only available when viewing this specific asset page, and are displayed in addition to the common fields listed
for the All Assets page. These fields are exposed by default.

Specific Assets Description Unique Fields

Cloud Compute Include assets that are managed by Agents, where the agent reported that the No specific unique fields are displayed in addition
Instance assets are in a cloud environment. In addition, the assets can be Cloud to the common fields.
Compute Instances that were reported by a Cloud integration (i.e. Cloud
Inventory data collector) with or without a Cortex agent.

Cortex XSIAM attempts to associate the data received from the agent and the
data received from the Cloud Integration and tie them together into a single
asset.

On-Prem Includes devices that have an Agent and also devices that were identified by The following attributes are relevant for IoT
various sources yet were not associated with an Agent, such as IoT devices. devices and indicate the category and
subcategory to which an IoT device belongs. For
Does not include devices that are in the cloud. example, the category may identify network
behaviors common to all security cameras.
Respectively, the model identifies the model of the
IoT device.

DEVICE MODEL

DEVICE CATEGORY

DEVICE SUBCATEGORY

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 783/1003
5/8/24, 9:18 AM PDF Export

Specific Assets Description Unique Fields

Certificate Certificates (also known as digital or public key certificates) are used when FORMATTED ISSUER NAME
establishing encrypted communication channels to identify and authenticate a
CERTIFICATE ALGORITHM
trusted party. The most common use of certificates is for SSL/TLS, HTTPS,
FTPS, SSH, and VPN connections. The most common use of certificates is for CERTIFICATE CLASSIFICATION
HTTPS-based websites, which allow a web browser to validate that an HTTPS
web server is an authentic website. Cortex XSIAM tracks information for each
certificate, such as Issuer, Public key, Public Key Algorithm, Subject, Subject
Alternative Names, Subject Organization, Subject Country, Subject State, and
several “crypto health” checks.

Domain A domain name attributed to an organization by Cortex XSIAM . Subdomains of RESOLVES—Indicates whether the domain has a
attributed Domains are also tracked as Domains. When there are too many DNS resolution.
(>1k) recent subdomains for one domain, Cortex XSIAM collapses them into the
parent domain.

Unassociated An IP that currently or has previously exposed an External Service which was No specific unique fields are displayed in addition
Responsive IPs detected by Cortex XSIAM and associated with the organization. to the common fields.

Only Responsive IPs and certificates that have at least one active Service are
displayed in the Asset Inventory.

Externally detected Responsive IPs are matched with existing assets using the
asset’s IP addresses. If the Responsive IP was matched to an existing asset, its
data is added to the asset. Any externally detected Responsive IP that was not
matched with an existing asset, is considered an independent asset of type
“Unassociated External Responsive IP”.

12.6.4 | Cloud Inventory Assets

Abstract

Cortex XSIAM provides a unified, normalized asset inventory for cloud assets to provide deeper visibility and context for incident investigation.

NOTE:

Ingesting and Viewing Cloud Inventory Assets requires a Cortex XSIAM Pro per GB license.

Cortex XSIAM provides a unified, normalized asset inventory for cloud assets in Google Cloud Platform, Microsoft Azure, and Amazon Web Services. This
capability provides deeper visibility to all the assets and superior context for incident investigation. To receive cloud assets, you must first configure a Cloud
Inventory data collector for the vendor in Cortex XSIAM . As soon as Cortex XSIAM begins receiving cloud assets, you can view the data in Assets → Cloud
Inventory, where All Cloud Assets and Specific Cloud Assets pages display the data in a table format.

The following are some of the main features available to you on these pages.

When any row in the table is selected, a side panel on the right with greater details is displayed, where you can view additional data divided by sections.
The following are some descriptions of the main sections.

Internet Exposure—When there are any open external ports, these ports and their corresponding details are displayed, so you can quickly identify
the source of the problem. You can also view the raw JSON text of the banner details obtained from Cortex Xpanse.

Asset Editors—Displays the identities of the latest 5 editors listing the percentage of editing actions for a single identity. A link is provided to open a
predefined query in XQL Search on the cloud_audit_log dataset to view the edit operations by the identity selected for this asset in the last 7
days.

Asset Metadata—Details the asset metadata collected for the particular row selected in the table.

Depending on the cell you’ve selected in the table, different right-click pivot menus are available, such as Open IP View and Open in Quick Launcher.

You can export the tables and respective asset views to a tab-separated values (TSV) file.

For more information on these sections in the side panel, see Manage Your Cloud Inventory Assets.

12.6.4.1 | All Cloud Assets

Abstract

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 784/1003
5/8/24, 9:18 AM PDF Export

Cortex XSIAM enables you to view all your cloud assets from the various cloud assets categories on the All Cloud Assets page.

NOTE:

Ingesting and Viewing Cloud Inventory Assets requires a Cortex XSIAM Pro per GB license.

The All Cloud Assets page enables you to view all your cloud assets from the various cloud assets categories that you configured for collection from Google
Cloud Platform, Microsoft Azure, and Amazon Web Services using the Cloud Inventory data collector.

To view the All Cloud Assets page, select Assets → Cloud Inventory → All Cloud Assets.

By default, the All Cloud Assets page displays all cloud assets according to the most recent time that the data was updated. To search for specific assets, use
the filters above the results table to narrow the results. You can export the tables and respective asset views to a tab-separated values (TSV) file. From the All
Cloud Assets page, you can also manage the asset's output using the right-click pivot menu. For more information, see Manage Your Cloud Inventory Assets.

The All Cloud Assets table is comprised of a number of common fields that are available when viewing any of the Specific Cloud Assets pages. The TYPE and
SUBTYPE fields are only available in the All Cloud Assets table as these fields determine the Specific Cloud Assets categories, and can be used to filter the
different types of assets from the entire list of assets.

When any row in the table is selected, a side panel on the right with greater details is displayed, where you can view additional data divided by sections, such as
Asset Metadata and Asset Editors. The Asset Editors section also provides a link to open a predefined query in XQL Search on the cloud_audit_log dataset to
view the edit operations by the identity selected for this asset in the last 7 days.

The following table describes the fields that are available when viewing All Cloud Assets in alphabetical order.

NOTE:

Certain fields are exposed and hidden by default. An asterisk (*) is beside every field that is exposed by default.

Field Description

AVAILABILITY ZONE* Displays the AVAILABILITY ZONE according to the cloud provider.

CLOUD TAGS* Displays any cloud tags or labels configured according to the cloud provider.

CREATION TIME* Displays the time that the cloud asset was created.1 This information is not always available.

EXTERNAL IPS* Displays a list of external public IPs.

GEO REGION* Displays the normalized value indicating the geographic region, such as North America or the Middle East.

HEIRARCHY* Displays the hierarchy of the associated PROJECT in the cloud provider separated by a forward slash (/) similar to a file
path.

NOTE:

The PROJECT is called something else in each cloud provider. For more information, see the PROJECT description.

INTEGRATION KEY Internal Cortex XSIAM identification of the integration collection.

INTERNAL IPS* Displays list of internal private IPs.

INTERNET EXPOSURE Displays a list of ports, where the details regarding these ports are available to view in the side panel.
(PORTS)*

LAST REPORTED STATUS* Last reported status of the asset, such as AVAILABLE or READY.

NAME* Name that describes the asset as given in the cloud provider if provided.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 785/1003
5/8/24, 9:18 AM PDF Export

Field Description

PROJECT* Displays the associated project name as provided by the Cloud provider. For each cloud provider, the project is called
something else.

AWS—Account

GCP—Project

Microsoft Azure—Subscription

PROJECT ID Displays the associated project ID as provided by the Cloud provider, where the project is called something else in each
cloud provider. See PROJECT description.

PROVIDER* The cloud provider used to collect these cloud assets is either GCP, AWS, or Azure.

RAW ASSET Internal Cortex XSIAM debug information that displays the raw data used to parse the data.

REGION* Displays the region as provided by the Cloud provider.

RESOURCE GROUP Displays the RESOURCE GROUP when using an Azure PROVIDER.

RESOURCE ID Displays the RESOURCE ID as provided by the cloud provider.

SECONDARY ASSET ID Displays a SECONDARY ASSET ID provided by the cloud provider that is used in Cortex XSIAM to identify the asset if a
NAME is not provided.

SUBTYPE* The subtype of cloud asset based on the TYPE configured, which can be defined as one of the following.

NOTE:

Each Subtype is displayed with an icon beside it.

VM Instance

Bucket

Disk

Image

Subnet

Security Group

Other

This field is unique to the All Cloud Assets table.

TYPE* Type of cloud asset, which can be defined as one of the following.

Compute

Cloud Function

Storage

Other

This field is unique to the All Cloud Assets table.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 786/1003
5/8/24, 9:18 AM PDF Export

Field Description

UPDATE TIME* Displays the time that the cloud asset was updated. This information is not always available.

Due to a known AWS synchronization issue, where the creation time displayed in the AWS Console does not match the actual time when the AWS Bucket was
created, the CREATION TIME in Cortex XSIAM does not always match the AWS Console as Cortex XSIAM displays the actual time.

12.6.4.2 | Specific Cloud Assets

Abstract

Cortex XSIAM enables you to view specific cloud assets from a designated cloud assets category in the Specific Cloud Asset pages.

NOTE:

Ingesting and Viewing Cloud Inventory Assets requires a Cortex XSIAM Pro per GB license.

The Specific Cloud Assets pages enable you to view specific cloud assets from a designated cloud assets category from all the assets you configured to collect
from Google Cloud Platform, Microsoft Azure, and Amazon Web Services using the Cloud Inventory data collector. These asset cloud categories are based on a
combination of asset types and subtypes. Each specific table contains the common columns that are listed in the All Cloud Assets table and some additional
specific columns that are relevant for this type of cloud asset.

To view the Specific Cloud Assets pages, select Assets → Cloud Inventory → Specific Cloud Assets, and select a specific cloud asset category.

By default, the Specific Cloud Assets pages display the cloud assets according to the most recent time that the data was updated. To search for specific assets,
use the filters above the results table to narrow the results. You can export the tables and respective asset views to a tab-separated values (TSV) file. From the
Specific Cloud Assets page, you can also manage the asset's output using the right-click pivot menu. For more information, see Manage Your Cloud Inventory
Assets.

When any row in the table is selected, a side panel on the right with greater details is displayed, where you can view additional data divided by sections, such as
Asset Metadata and Asset Editors. The Asset Editors section also provides a link to open a predefined query in XQL Search on the cloud_audit_log dataset to
view the edit operations by the identity selected for this asset in the last 7 days.

The image below is an example of a Specific Cloud Assets page for Compute Instances.

The table below describes the different Specific Cloud Assets pages the following.

Specific Cloud Assets—The name of the specific cloud asset page.

Asset Type—The asset type that is automatically associated with this specific cloud asset page.

Asset Subtype—The asset subtype that is automatically associated with this specific cloud asset page.

Unique Fields—The unique fields that are only available when viewing this specific cloud asset page, and are displayed in addition to the common fields
listed for the All Cloud Assets page. These fields are exposed by default.

Specific Cloud Assets Asset Type Asset Subtype Unique Fields

Compute Instances Compute Instance MACHINE TYPE—Displays the type of machine.

LAST START TIME—Displays the last time the machine started.

Disks Compute Disk DISK SIZE—Displays the disk size as an integer in GB.

DISK IS ENCRYPTED—Displays a boolean value as either Yes or No to

indicate whether the disk is encrypted.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 787/1003
5/8/24, 9:18 AM PDF Export

Specific Cloud Assets Asset Type Asset Subtype Unique Fields

Storage Buckets Storage Bucket BUCKET ACCESS—Displays the bucket access options as one of the
following.

Public

Private

Fine Grained

Unknown

BUCKET LOCATION—Displays the bucket location as either Regional or Multi

Regional.

Virtual Private Clouds Compute VPC DEFAULT VPC—Displays a boolean value as either Yes or No to indicate whether
(VPCs) this asset is the default VPC.

Subnets Compute Subnet No specific unique fields are displayed in addition to the common fields.

Security Groups (FW Compute Security Group No specific unique fields are displayed in addition to the common fields.
Rules)

Images Compute Image No specific unique fields are displayed in addition to the common fields.

Network Interfaces Compute Network No specific unique fields are displayed in addition to the common fields.
Interfaces

Cloud Functions Cloud Cloud Function No specific unique fields are displayed in addition to the common fields.
Function

12.6.4.3 | Manage Your Cloud Inventory Assets

Abstract

Cortex XSIAM provides a central location to view and investigate information relating to inventory assets in the cloud.

The All Cloud Assets and Specific Cloud Assets pages provide a central location from which you can view and investigate information relating to inventory
assets in the cloud. These cloud inventory assets are collected from Google Cloud Platform, Microsoft Azure, and Amazon Web Services depending on your
defined cloud configurations, and are received by Cortex XSIAM using the Cloud Inventory data collector. These pages are designed in a similar format so you
can navigate to the page, view the data, and perform the same tasks to easily investigate your assets.

To manage your cloud inventory assets.

1. Select Assets → Cloud Inventory.

2. View All Cloud Assets by remaining on the page, or select a Specific Cloud Assets page from the list available on the left panel.

By default, the page displays all cloud assets according to the most recent time that the data was updated.

3. (Optional) Filter and review your assets.

You can use the filter icon ( ) at the top of the page to build a filter from scratch or filter the individual columns to view the information you are looking
for. To create a persistent filter, save ( ) it

4. (Optional) Export your filtered results to a tab-separated values (TSV) file using the Export to file icon ( ) on the top of the page.

5. (Optional) Investigate any asset further by selecting the applicable row in the table to reveal a side panel.

The side panel enables you to view additional data divided by sections, such as Asset Metadata and Asset Editors. The Asset Editors section also
provides a link ( ) to open in a new tab a predefined query in XQL Search on the cloud_audit_log dataset to view the edit operations by the identity

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 788/1003
5/8/24, 9:18 AM PDF Export

selected for this asset in the last 7 days.

The following table describes the common side panel components that are displayed for all asset types and subtypes and the specific side panel
components based on the specific cloud assets type selected.

Side Panel Component Description Example Image

Common Side Panel Components

Header The header row displays the following

information about the asset.

The NAME of the asset as displayed in

the table. If there is no value for the asset
name, the SECONDARY ASSET ID for
the asset is used.

The TYPE of asset.

Additional specific information per asset

type, which is only displayed only if a
value is available.

The cloud PROVIDER.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 789/1003
5/8/24, 9:18 AM PDF Export

Side Panel Component Description Example Image

Asset Metadata This section includes the following fields, which

are displayed if the information is available
from the output field values in the table.

Created at—Timestamp, which is not

always available.

Updated at—Timestamp, which is not

always available.

Region—Displays the region as provided

by the Cloud provider.

Availability zone—Displays the

AVAILABILITY ZONE according to the
cloud provider.

Geo Location—Displays the normalized

value indicating the geographic region,
such as North America or the Middle
East.

Project—Displays the associated project

name as provided by the Cloud provider.
For each cloud provider, the project is
called something else.

AWS—Account

GCP—Project

Microsoft Azure—Subscription

Hierarchy—Displays the hierarchy of the

associated PROJECT in the cloud
provider separated by a forward slash (/)
similar to a file path.

NOTE:

The Project is called something else in

each cloud provider. For more
information, see the PROJECT
description.

Public IPs—Displays a list of external

public IPs.

Private IPs—Displays a list of internal

private IPs.

Cloud Tags—Displays any cloud tags or

labels configured according to the cloud
provider.

Last Reported Status—Last reported

status of the asset, such as AVAILABLE
or READY.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 790/1003
5/8/24, 9:18 AM PDF Export

Side Panel Component Description Example Image

Asset Editors A bar chart of the identities of the Asset Editors

is displayed. Up to 5 editors are displayed in a
horizontal bar chart listing the percentage of
editing actions for a single identity. The chart
data does not include any actions where the
identity could not be resolved. If there are more
than 5 editors, then not all editors are
displayed, and the rest of the editors are
displayed in an Others bar.

The Asset Editor section provides a link ( ) to

open in a new tab a predefined query in XQL
Search on the cloud_audit_log dataset to
view the edit operations by the identity selected
for this asset in the last 7 days.

A notification about the data is also provided

using the format *Data since <timestamp>.

Internet Exposure When there are any open external ports, the
open ports and their corresponding details are
displayed.

Title—The title format is <IP>:<port>.

When you hover your mouse over the
title, you expose the Show banner info
icon, which opens a Banner window with
the raw JSON text obtained from Xpanse
containing the banner, which you can
view in JSON VIEW (default) or TREE
VIEW.

Observed Services—The type of service

observed with the open external port,
such as MySQL, HTTP, and TLS.

Observed at—A timestamp for when the

open external port was noticed.

Specific Side Panel Components

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 791/1003
5/8/24, 9:18 AM PDF Export

Side Panel Component Description Example Image

VM Instance The TYPE of asset is set to Compute and the

SUBTYPE is set to VM Instance. The header
includes the following additional fields.

Machine type—Displays the type of

machine.

Last started—Displays the last time the

machine started.

The following data is displayed in the panel.

Disks—A list of disks, where each disk

has the following properties.

Disk name. When you hover over

the disk name, you expose the
Show Disk icon, which enables you
to view in the side panel the
associated disk information, such
as the disk size in GB.

Boot Disk—Boolean value as

either Yes or No.

Disk Type—Type of disk such as

ebs or persistent.

Network Interfaces—List of Network

Interfaces, where the following is
displayed for each network interface if
the data exists.

Name on the network interface.

IP—The IP address of the network

interface.

When you hover over the network

interface name, you expose
different icons with different actions
that you can perform to open
different side panel components.

-View associated VPC—Drills

down to the VPC side panel
component if the ID exists.

-View network interface details—

Drills down to the corresponding
Network Interface row if the ID
exists.

-View associated subnet—Drills

down to the Subnet side panel
component if the ID exists.

Disk Displays the following information in the

Header.

Compute Disk as the specific cloud

assets type.

Is Encrypted—Displays a boolean value

as either Yes or No to indicate whether
the disk is encrypted.

Size of the disk in GB.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 792/1003
5/8/24, 9:18 AM PDF Export

Side Panel Component Description Example Image

VPC Displays the following information in the

Header.

Virtual Private Cloud (VPC) as the

specific cloud assets type.

CIDRs—A list of CIDRs.

Default—Displays a boolean value as

either Yes or No to indicate whether this
asset is the default VPC.

The following actions are available only if this

information is provided by the cloud provider.

Show Peer networks—Pivot to a new tab

with the VPC Networks table, which is
filtered on the list of IDs.

Show Subnets—Pivot to a new tab with

the Subnets table, which is filtered on the
list of IDs.

Subnet Displays the following information in the

Header.

Subnet as the specific cloud assets type.

CIDRs—A list of CIDRs.

Cloud Function Displays the following information in the

Header.

Cloud Functions as the specific cloud

assets type.

Runtime—Displays the runtime system,

such as python3.9.

Memory Size—The amount of memory in

MB.

Description—A description of the cloud

function.

Storage Bucket Displays the following information in the

Header.

Storage Bucket as the specific cloud

assets type.

Location Type—Displays the bucket

location as either Regional or Multi
Regional

Access Type—Displays the bucket

access options as one of the following.

Public

Private

Fine Grained

Unknown

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 793/1003
5/8/24, 9:18 AM PDF Export

Side Panel Component Description Example Image

Security Group Displays the following information in the

Header.

Security Group (FW Rule) as the specific

cloud assets type.

Group Name and Description for the

Security Group, if available. In AWS,
there is a name and description for the
entire group, while in GCP per rule.

A Security Group is a list of rules. A separate

Rules section is displayed in the side panel that
lists the following for each rule.

Name—Name of the rule.

Description—The description of the rule,

if it exists.

Rules icon ( )—Opens a Banner

window containing the raw JSON data
extracted for the rule, which you can view
in JSON VIEW (default) or TREE VIEW.

Some providers provide the associated VPC for

the Security Group and some provide an
associated Network Interface. The actions are
dependent on the available data and are
exposed when you hover over the INFO
heading under the NETWORK INTERFACES
section.

View associated VPC—Drills down to the

VPC side panel component if the ID
exists.

View network interface details—Drills

down to the corresponding Network
Interface row if the ID exists.

View associated subnet—Drills down to

the Subnet side panel component if the
ID exists.

6. (Optional) Manage cloud inventory assets, as needed.

At any time, you can return to the All Cloud Assets or Specific Cloud Assets pages to view and manage your cloud inventory assets. To manage a cloud
inventory asset, right-click the asset and select the desired action. Some actions are dependent on the type of cloud asset selected and the particular cell
you are performing the action from.

Show rows with ‘<field name>’ to filter the column list to only display the rows with a specific field name selected in the table.

Hide rows with ‘<field name>’ to filter the column list to hide the rows with a specific field name selected in the table.

Copy text to clipboard to copy the text from a specific field in the row of an asset.

Copy entire row to copy the text from all the fields in a row of an asset.

Open IP View—For the External IPs and Internal IPs column fields in the assets table, you can open the IP Address View, which provides a powerful
way to investigate and take action on an IP address by reducing the number of steps it takes to collect, research, and threat hunt related incidents.

Open in Quick Launcher—For the External IPs and Internal IPs column fields in the assets tables, you can open the Quick Launcher shortcut to
search for information, perform common investigative tasks, or initiate response actions related to a specific IP address or CIDR.

Show rows 30 days prior to ‘<timestamp field>’—For all timestamp fields in the assets tables, you can filter the column list to only display the rows
30 days earlier than the selected timestamp field.

Show rows 30 days after to ‘<timestamp field>’—For all timestamp fields in the assets tables, you can filter the column list to only display the rows
30 days after the selected timestamp field.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 794/1003
5/8/24, 9:18 AM PDF Export

12.7 | Asset Roles

Abstract

View asset roles and the number of assets that are associated with each role. Learn how to manage asset roles for users and endpoints.

NOTE:

Asset Roles are available only if the Identity Threat Module add-on is enabled.

Cortex XSIAM continuously analyzes your users and endpoints, and automatically classifies them based on their activities under asset roles, for example,
Domain Controller, Administrator, Executive User. You can edit, add, and fine-tune the assets associated with each asset role at any time.

Fine-tuned asset roles aid Cortex XSIAM Analytics in the following areas.

Enhancement of the accuracy of the analytics that run on assets, enabling better detection of uncommon activities by the asset based on the baseline for
the asset role.

Asset role visualization in the Incident view, the User view, and the Host view as background information for risk assessment.

Analysis of User and Host peer groups for score trend comparison over selected timelines.

You can add users and endpoints to any asset role manually or by importing a CSV file.

You can remove users from asset roles manually and override the automatically detected asset roles.

The tag family for asset roles provides the ability to slice and dice alerts and incidents. Automated and customizable asset role classification is based on
constant analysis of the users and host in your network. You can edit and manage the User Asset Roles and Host Asset Roles to meet the needs of your
organization.

The Assets → Asset Roles Configuration page displays the asset roles, their type, the number of assets that are associated with each asset role and the last
modification date. On this page, you can refresh the data, filter it, and change the layout.

To edit an asset role, right click and select Edit Asset Role. Depending on the type of asset, you can manage the user asset role list or the endpoint asset role
list for the asset role.

Manage Asset Roles for Users

Manage Asset Roles for Endpoints

12.7.1 | Manage Asset Roles for Endpoints

Abstract

Learn how to edit the host lists assigned to asset roles.

NOTE:

Endpoint Role Management is available only if the Identity Threat Module add-on is enabled.

The Edit Endpoint Role page enables you to edit the host lists assigned to asset roles. You may want to exclude some endpoints from certain asset roles even if
Cortex XSIAM automatically detected the endpoint as having this asset role. For example, if an endpoint is reassigned to another user and you want their
Analytics to be adjusted accordingly.

The Endpoints list on the page displays the endpoints classified under the asset role, if the asset role was assigned automatically or edited manually for the
endpoint, the last modification date, and the modifier.

To access the Edit Endpoint Role page, from Assets → Asset Role Configuration, right click to select the endpoint asset role and click Edit Asset Role.

INCLUDED ENDPOINTS displays all the endpoints Cortex XSIAM automatically detects as having this asset role and the endpoints you specify manually as
having this asset role. EXCLUDED ENDPOINTS displays the endpoints that were manually removed from an asset role. When you exclude an endpoint, it
remains in the Excluded Endpoints list and if detected automatically again in the future as having this role, will not be included in the role list.

If you want to remove an endpoint from the list of endpoints with this asset role, right click the endpoint and select Exclude Endpoint. The endpoint is then listed
under EXCLUDED ENDPOINTS for this asset role. When you exclude an endpoint from an asset role, by default Cortex XSIAM also removes the endpoint from
the parent asset roles of the current asset role. To remove the endpoint from the child asset role, but to leave it in any of its parent asset roles, click Advanced
Exclusion Settings, and select Don't Exclude next to the name of the parent asset role(s).

To include an Excluded endpoint back in the asset role, in the EXCLUDED ENDPOINTS list, right click the endpoint and select Delete Endpoint. If the endpoint
was automatically detected as having this asset role. it will be added back to the INCLUDED ENDPOINTS list again. Otherwise, the next time Cortex XSIAM
scans the assets and automatically detects their asset roles, this endpoint will be included in the asset role list.

To include endpoints from your system manually in an asset role list, in the asset role page, click Add Endpoint. Select the endpoint from the displayed endpoint
list, which displays the endpoints managed by the tenant. You can only add endpoints that have the Cortex XDR agent installed on them.

Manually added endpoints are analyzed by Analytics when it runs next and are displayed in the Incident view and the Host Risk view.

To delete a manually added endpoint from the Included Endpoints list, right click and Delete Endpoint.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 795/1003
5/8/24, 9:18 AM PDF Export

NOTE:

Deleting a manually added endpoint removes the endpoint from the INCLUDED ENDPOINTS list. If this endpoint is detected automatically as having this
asset role in the future, it will appear in the Included Endpoints list.

Excluding a manually added endpoint ensures that even if in the future the endpoint is detected as having this asset role, this detection is overridden and the
endpoint isn't included in the asset role.

To change the name of an endpoint, right click the endpoint name and Edit Endpoint.

12.7.2 | Manage Asset Roles for Users

Abstract

Learn how to edit the user lists assigned to asset roles.

NOTE:

User Role Management is available only if the Identity Threat Module add-on is enabled.

The Edit User Role page enables you to edit the user lists assigned to asset roles. You may want to exclude some users from certain asset roles even if Cortex
XSIAM automatically detected the user as having this asset role. For example, if a user's position in the organization is changed and you want their Analytics to
be adjusted accordingly.

The User list on the page displays the users classified under the asset role, if the asset role was assigned automatically or edited manually for the user, the last
modification date, and the modifier.

To access the Edit User Role page, from Assets → Asset Roles Configuration, right click to select the user asset role and click Edit Asset Role.

Some asset roles are nested under parent asset roles which are higher in the hierarchy of asset roles. The information icon next to the asset role name provides
the name of the parent rule this asset role may be nested under. For example, an Admin User asset role may be a child asset role of the parent asset role
Sensitive User.

INCLUDED USERS displays all the users Cortex XSIAM automatically detects as having this asset role and the users you specify manually as having this asset
role. EXCLUDED USERS displays the users that were manually removed from an asset role. When you exclude a user from an asset role, it remains in the
Excluded Users list and even if it's detected automatically again in the future as having this asset role, it will not be included in the asset role list.

If you want to remove a user from the list of users with this asset role, right click the user and select Exclude User. The user is then listed under EXCLUDED
USERS for this asset role. When you exclude a user from an asset role, by default Cortex XSIAM also removes the user from the parent asset roles of the
current asset role. To remove the user from the child asset role, but to leave it in any of its parent asset roles, click Advanced Exclusion Settings, and select
Don't Exclude next to the name of the parent asset role(s).

To include an excluded user back in the asset role, right click the user in the Excluded Users list and select Delete User. If the user was automatically detected
as having this asset role, it will be added back to the INCLUDED USERS list again. Otherwise, the next time Cortex XSIAM analyzes the assets and
automatically detects their asset roles, this user will be included in the asset role list.

To include users from your system manually in an asset role list, in the asset role page, click Add User.

To add one or more users manually, click Add New, and then type the user names one by one in the format Netbios\samAccount.

To add users from a CSV file, click Import from File. You can use the example file provided to structure your CSV file.

Manually added users are also analyzed by Analytics when it runs next, and are displayed in the Incident view and the User Risk view.

To delete a manually added user from the INCLUDED USERS, right click and Delete User.

NOTE:

Deleting a manually added user removes the user from the INCLUDED USERS list. If this user is detected automatically as having this asset role in the
future, it will appear in the INCLUDED USERS list again.

Excluding a manually added user ensures that even if in the future the user is detected as having this asset role, this detection is overridden and the user isn't
included in the asset role.

To change the name of a user, right click the user name and Edit User.

13 | Attack Surface Management

Abstract

Learn how to protect your environment from the outside using Attack Surface Management (ASM) in Cortex XSIAM.

NOTE:

Attack Surface Management is an add-on capability.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 796/1003
5/8/24, 9:18 AM PDF Export

Cortex XSIAM enables you to analyze your environment from the outside, which enhances the existing internal access to the environment provided with an
installed agent. This improves the visibility of your environment by attributing new assets to the organization, identifying which known assets are publicly
exposed to the internet, and alerting on risky services that pose a threat to the organization’s security posture. Enhancing existing capabilities with outside-in
Attack Surface Management (ASM) capabilities creates a holistic view of the organization and its security threats and allows security professionals to potentially
avoid attacks by proactively reducing their attack surface.

The following are the main use cases for using ASM by a SOC analyst.

Investigate and remediate ASM incidents and their underlying ASM alerts.

Enriching incidents with ASM data to provide greater visibility into all Internet-facing assets (i.e. external devices) and to attain a better sense of control to
reduce the attack surface.

Attack Surface Reduction—Reducing the Attack Surface by proactively analyzing Internet-facing assets and services.

As soon as Cortex XSIAM begins receiving assets that were attributed to the organization, you can view the data in Assets → Asset Inventory. The following
additional features are available to investigate these new assets.

The following tables are added to the Specific Assets page.

Unassociated Responsive IPs—An IP that currently or has previously exposed a Service and that was not matched with an existing IP of a known
asset.

Domains—A domain name attributed to an organization by Cortex XSIAM . Subdomains of attributed Domains are also tracked as Domains. When
there are too many (>1k) recent subdomains for one domain, Cortex XSIAM collapses them into the parent domain.

Certificates—A certificate attributed to an organization by Cortex XSIAM . Cortex XSIAM tracks historically sighted Certificates in addition to
currently observed ones.

The data from the new tables added to the Specific Assets page is also available on the All Assets page and can be filtered by Type.

Internet exposure assessments on servers for the On-Prem Assets and Cloud Compute Instances tables when an external IP is identified.

The All External Services page presents the complete inventory of public internet-facing services attributed to your organization.

Cortex XSIAM identifies Externally Inferred CVEs by comparing the product name and version of the active service, if identifiable, with CVES for those
products in the National Vulnerability Database. Externally inferred CVEs are identified for both assets and services.

Attack Surface Management Dashboard.

The following concepts are helpful for understanding ASM in Cortex XSIAM :

13.1 | External Assets

Abstract

The assets discovered in a Cortex XSIAM ASM scan include domains, certificates, and unassociated responsive IPs.

The external assets that were discovered in a Cortex XSIAM ASM scan and were attributed to your organization are available in the All Assets and Specific
Assets pages. External assets include the following asset types:

Domains—A domain name attributed to an organization by Cortex XSIAM . Subdomains of attributed Domains are also tracked as Domains. When there
are too many (>1k) recent subdomains for one domain, Cortex XSIAM collapses them into the parent domain.

Certificates—Certificates (also known as digital or public key certificates) are used when establishing encrypted communication channels to identify and
authenticate a trusted party. The most common use of certificates is for SSL/TLS, HTTPS, FTPS, SSH, and VPN connections. The most common use of
certificates is for HTTPS-based websites, which allow a web browser to validate that an HTTPS web server is an authentic website. tracks information for
each certificate, such as Issuer, Public key, Public Key Algorithm, Subject, Subject Alternative Names, Subject Organization, Subject Country, Subject
State, and several “crypto health” checks.

Unassociated Responsive IPs—An IP that currently or has previously exposed a service.

13.2 | Asset Attribution Evidence

The Asset Attribution Evidence section appears on the asset details panel and on the Assets tab in an incident. This section provides two key pieces of
information:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 797/1003
5/8/24, 9:18 AM PDF Export

Origin Information—Explains whether an asset was discovered by Cortex XSIAM or provided by your organization and when the asset was last seen.

Attribution Evidence—Explains why the asset was attributed to your organization. Provides the seed term that Cortex XSIAM used to attribute the asset to
your organization and the specific piece of scan data that Cortex XSIAM matched to the seed term.

A seed term is a text string that our research team generated and associated with your organization. For example, seed terms for Cortex Xpanse might
include: Xpanse, Cortex, Cortex Xpanse, Palo Alto Networks, PANW, PAN, etc. We use machine learning models as well as manual research to match
the seed terms with our scan data to attribute assets to your organization. Additional details on how we attribute assets can be found in the Cortex Xpanse
Discovery and Attribution datasheet.

Depending on the asset type and scan data, most assets will have one or more pieces of attribution evidence. Assets that don't have attribution evidence do not
have a seed term match. The following are reasons we may not have a seed term match:

The domain or IP range is provided by the customer and cannot be externally validated using public data.

The domain registration information is redacted, blank, or private. We attribute these through manual routing.

The domain is attributed by an associated website (e.g. example.com is attributed to Example Corp because the website at www.example.com shows
clear evidence of belonging to Example Corp).

The domain is attributed based on a DNS record.

If you have questions about a specific asset, reach out to Customer Success.

13.3 | External Services

Abstract

An external service is a server running at an IP:port or a domain:port that responds to scanners on some protocol.

An external service is a server running at an IP:port or a domain:port that responds to scanners on some protocol. The response must be on an application-
level protocol over the public Internet. Example: DNS Server at 103.61.60.114:53. You can view the complete inventory of external services attributed to your
organization on the Assets → Asset Inventory → All External Services page. You can also view the list of external services for a specific asset on the asset
details panel. See All External Services for more information.

13.4 | Externally Inferred CVEs

Cortex XSIAM identifies externally inferred CVEs by comparing the product name and version of active service, if identifiable, with CVES for those products in
the National Vulnerability Database. We categorize externally inferred CVE matches as high or medium confidence based on the version information that is
available on the service and from the National Vulnerability Database (NVD).

High Confidence Match—Precise version information is available both from the service and from NVD.

Medium Confidence Match—Part of the version information from the service matches the NVD entry for the CVE, but the version information from the
service or from NVD has additional characters.

NOTE:

An externally inferred CVE might impact your service or asset, but additional investigation is required to confirm that the CVE is actually present.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 798/1003
5/8/24, 9:18 AM PDF Export

Cortex XSIAM provides information about externally inferred CVEs for all assets and external services in the Asset Inventory. For every asset or service that has
an externally inferred CVE, Cortex XSIAM also provides an Externally Inferred Vulnerability Score, which is the highest CVSS v3 score that applies to an asset
or service. In cases where there is no CVSS v3 score, the CVSS v2 score is used.

To view externally inferred CVEs and details about them, see View Externally Inferred CVEs.

13.4.1 | View Externally Inferred CVEs

Abstract

Cortex XSIAM provides information about externally inferred CVEs for all assets and external services.

Cortex XSIAM provides information about externally inferred CVEs for all assets and external services in the Asset Inventory. For information about what
externally inferred CVEs are and how Cortex XSIAM identifies them, see Externally Inferred CVEs.

The following steps explain how to view externally inferred CVEs and information about them.

1. Select Assets → Asset Inventory.

2. Select All Assets, a Specific Assets page, or All External Services.

Each of these pages displays a tabular view of your assets or services that includes the Externally Inferred CVEs and Externally Inferred Vulnerability
Score fields.

3. View the complete list of externally inferred CVEs that impact an asset or service by selecting a row in the table for an asset or service that has externally
inferred CVEs.

After you select the row, the details panel for that asset or service displays to the right of the table, and includes a complete list of all the externally inferred
CVEs that impact that asset or service and the inferred CVE match confidence.

4. Click Detailed view next to any externally inferred CVE to display additional details.

The CVSS v3 Score, CVSS v2 Score, the product and version information used to make the inference, and a link to the CVE on the NVD website is
displayed.

13.5 | Attack Surface Testing

Abstract

Attack Surface Testing runs benign exploits against your externally facing assets to confirm the presence of vulnerabilities.

Cortex XSIAM Attack Surface Testing confirms the presence of a vulnerability on your external attack surface, enabling you to quickly and confidently prioritize
risks. With your approval, Cortex XSIAM runs benign exploits against externally facing assets to confirm the presence of vulnerabilities. Rather than manually
verifying inferred CVEs yourself, Cortex XSIAM Attack Surface Testing runs daily scans based on your preferences.

When you set up Attack Surface Testing, you select the targets for the testing, either all of a subset of your directly-discovered services (directly-discovered
services are services for which Cortex XSIAM has a registration record tying your organization to the the service). Once you've selected targets, Cortex XSIAM
runs attack surface scans daily. Attack surface test results are displayed on the Services tab in the Inventory, so you can review the data as part of your existing
attack surface management (ASM) workflow. All attack surface tests are enabled by default, but you can view information about the tests and disable tests if
needed from the Attack Surface Tests page.

Cortex XSIAM attack surface tests

Cortex XSIAM has an extensive set of attack surface tests for the CVEs and other known risks that affect externally-facing services and can be confirmed using
benign testing. Our vulnerability testing is layered on top of our existing ASM global scanning infrastructure, which distributes requests across a broad time
range to minimize the impact to scanned and tested services. We perform external scans only, which means we only test directly-discovered services accessible
from the public internet. Cortex XSIAM does not perform authenticated scanning or allow scans to change the state on a tested service. To further decrease test
load and the possibility of impacting a service, we map attack surface tests to service classifications, enabling us to run tests only on the relevant services in
your approved set of targets. For example, we only run Apache attack surface tests against your Apache services.

New attack surface tests are added at the discretion of the Cortex XSIAM Security Research Team when new vulnerabilities are announced.

13.5.1 | Set up Attack Surface Testing

NOTE:

You must have a role that includes edit permission for Vulnerability Testing to set up Attack Surface Testing. To check your role-based permissions go to
Settings → Configurations → Access Management → Roles, select the role, and find Vulnerability Testing on the Components tab under Incident Response
→ Detections.

To set up Attack Surface Testing for the first time, complete the following tasks:

1. Accept the End-User Licensing Agreement (EULA).

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 799/1003
5/8/24, 9:18 AM PDF Export

The EULA gives Cortex XSIAM permission to conduct attack surface testing scans. You only need to accept the EULA once. After accepting the EULA the
Vulnerability Testing Configuration page will open automatically so you can select the targets for testing.

2. Select targets for attack surface testing.

In this task, you'll select the directly-discovered services upon which Cortex XSIAM will run attack surface tests. After the initial set-up, you can update this
set of targets anytime.

After you complete the set-up tasks, Cortex XSIAM will begin daily attack surface testing scans. You can perform the following post-setup tasks to access attack
surface test results and change your attack surface testing configuration.

View attack surface test results

Enable new attack surface tests by default

View attack surface tests

View source IP addresses for Attack Surface Testing scans

Accept the End-User Licensing Agreement (EULA)

1. Navigate to Detection &Threat Intel → Attack Surface → Attack Surface Testing.

2. On the Welcome to Vulnerability Testing page, click Next.

3. Read the End-User Licensing Agreement and click Accept Terms.

After accepting the terms of the EULA, the Vulnerability Testing Configuration page will open where you can select the set of services to be tested.

13.5.2 | Select targets for Attack Surface Testing

Attack Surface Testing targets are directly-discovered services, which are services that are definitively associated with an asset that belongs to your
organization. You can choose to run attack surface tests on all your relevant directly-discovered services or you can specify a subset of services.

How to select a set of targets for attack surface testing

1. Navigate to Detection &Threat Intel → Attack Surface → Attack Surface Testing

2. In the Target Testing section, click Edit Targets (or Add Targets if this is the first time you have selected targets.)

3. Use the filter to define a set of targets from your list of Services.

4. Click Save Targets.

5. Make sure the toggle is set to Selected Targets. Setting the toggle to All Targets will override your target selection.

How to select all targets for attack surface testing

1. Navigate to Detection &Threat Intel → Attack Surface → Attack Surface Testing

2. In the Target Testing section, set the toggle to All Targets.

13.5.3 | View attack surface test results

Attack surface test results are displayed on the Services page in the Inventory. The following fields in the Services table enable you to search for specific
vulnerabilities.

Confirmed Vulnerabilities—This field lists CVE IDs (or other vulnerability IDs) of the vulnerabilities that have been confirmed present on the service. You
can search this field for a specific CVE ID to find all the services that have a confirmed vulnerability with that ID.

Confirmed Not Vulnerable—This field lists CVE IDs (or other vulnerability IDs) of the vulnerabilities that have been confirmed to be not present on the
service. You can search this field for a specific CVE ID to find all the services that have are confirmed not vulnerable for that vulnerability.

Vulnerability Test Result—The value Confirmed Vulnerable indicates there is at least one confirmed vulnerability on the service. You can filter on this field
to find all services with at least one confirmed vulnerability.

How to view attack surface test results for a specific CVE

1. Navigate to Assets → Asset Inventory → All External Services

2. Filter the Services table to find the services with a specific confirmed vulnerability.

1. Click on the filter icon at the top of the Confirmed Vulnerability ID column, and enter the vulnerability ID in the dialog box.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 800/1003
5/8/24, 9:18 AM PDF Export

2. Click anywhere outside the dialog box to filter.

The list of services that are confirmed to have that vulnerability will display.

3. Click on a row in the table to display the details panel for that service.

On the service details panel, you can review the list of tests run, test dates, whether each test produced a confirmed vulnerable or confirmed not
vulnerable result, evidence, and remediation guidance.

Click the arrow to the left of each test result to display the 14-day test history and the evidence payload returned by the service.

13.5.4 | Enable new attack surface tests by default

You can configure Cortex XSIAM to automatically enable or disable new attack surface tests when they are introduced. By default Cortex XSIAM enables new
attack surface tests.

1. Navigate to Detection &Threat Intel → Attack Surface → Attack Surface Testing.

2. In the New Vulnerability Tests section, select Opt-in in the toggle to enable new tests by default or Opt-out to disable new tests by default.

13.5.5 | View attack surface tests

View information about the available attack surface tests, and enable or disable tests on the Vulnerability Testing page. By default all tests are enabled.

1. Navigate to Policies and Rules → Attack Surface Testing.

2. Filter and sort the list of tests as needed to identify the tests you want to enable or disable.

3. Select one or more tests using the check boxes, and right click to Enable or Disable them.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 801/1003
5/8/24, 9:18 AM PDF Export

Attack surface test field descriptions

Field Description

Affected Software Software names and versions impacted by this vulnerability.

CWE IDs Common Weakness Enumeration ID. This ID is defined by MITRE.

Created When Cortex XSIAM released this test.

Description Description of the vulnerability.

EPSS Score The Exploit Prediction Scoring System (EPSS) score indicates the likelihood that a vulnerability will be
exploited in the wild. Possible values are between 0 and 100%, and the higher the score, the greater the
probability that a vulnerability will be exploited.

First Published When this vulnerability was first published.

ID Unique ID for this test.

Name Name of the test.

References Research references and supporting documentation.

Remediation Guidance Recommended steps for remediating or mitigating the vulnerability.

Severity Score The CVE severity score is based on the NIST Common Vulnerability Scoring System (CVSS).

Services Found Vulnerable The number of directly-discovered services owned by your organization that Cortex XSIAM has confirmed
vulnerable with this test.

Status Indicates whether the test is Enabled or Disabled.

Vendor Names Name of the vendor whose product is impacted by the vulnerability.

Vulnerability IDs CVE number or other public identifier for the vulnerability.

13.5.6 | View source IP addresses for Attack Surface Testing scans

To find the IP address range Cortex XSIAM uses for vulnerability tests, navigate to Detection &Threat Intel → Attack Surface → Attack Surface Testingand refer
to the Source IP Addresses section.

14 | Monitoring
Abstract

From the Cortex XSIAM management console you have a wide range of monitoring options available.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 802/1003
5/8/24, 9:18 AM PDF Export

14.1 | Dashboard
Abstract

Dashboards enable you to effectively monitor activity in your environment. In the Dashboard Manager, you can create new dashboards and take actions on
existing dashboards.

Dashboards offer graphical overviews of your tenant's activities, enabling you to effectively monitor incidents and overall activity in your environment. Each
dashboard comprises widgets that summarize information about your endpoint in graphical or tabular format.

When you sign in to Cortex XSIAM your default dashboard is displayed. To change the displayed dashboard, in the dashboard header choose from the list of
predefined and custom dashboards. You can also manage all of your dashboards from the Dashboard Manager.

On each dashboard, you can you can see the selected Time Range on the right side of the header. An indicator shows the time that the dashboard was last
updated, and if the data is not up-to-date you can click Refresh to update all widget data. You can also select widget specific time frames from the menu on an
XQL widget. If you select a different time frame for a widget, a clock icon is displayed.

The dashboard menu provides additional options for managing your dashboard, including the option to save the dashboard as a report template, set it as your
default dashboard, and disable the background animation.

If you are viewing a dashboard with dynamic parameters and filters configured, the dashboard header displays the defined filters. If dashboard drilldowns are
defined, you can click on data points, table rows, or other visualization elements to see interactive data insights. For more information, see Using Dashboard
Filters, Inputs, and Drilldowns.

Cortex XSIAM provides the following types of dashboards:

Command Center dashboards

Command Center dashboards provide instant visibility into your security operations, with drilldowns to additional dashboards and associated pages. For
more information, see Command Center dashboards.

Predefined dashboards

Predefined dashboards are configured for different system set-ups and use cases, and to assist SOC analysts in their investigations. You can create
reports and custom dashboards that are based on predefined dashboards. For more information, see Predefined Dashboards.

Custom dashboards

Custom dashboards provide the flexibility to design dashboards that are built to your own specifications. You can base custom dashboards on the
predefined dashboards or create a new dashboard from scratch, and save your custom dashboards as reports. For more information, see Build a Custom
Dashboard.

14.1.1 | Manage Dashboards

Abstract

From the Cortex XSIAM management console, use the Dashboards Manager to view and manage your dashboards.

In the Cortex XSIAM console, navigate to Dashboards & Reports → Customize → Dashboards Manager to view all custom and default dashboards. From the
Dashboards Manager, you can also delete, edit, duplicate, disable, and perform additional management actions on your dashboards.

To manage an existing dashboard, right-click the dashboard and select the desired action.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 803/1003
5/8/24, 9:18 AM PDF Export

Delete - Permanently delete a dashboard.

Edit - Edit an existing dashboard. You cannot edit the default dashboards provided by Palo Alto Networks, but you can save it as a new dashboard.

Save as new - Duplicate an existing template.

Disable - Temporarily disable a dashboard. If the dashboard is public, this dashboard is also removed for all users.

Set as default - Make the dashboard the default dashboard that displays when you (and other users, if the dashboard is public) log in to Cortex XSIAM .

Save as report template - Save a report as a template.

14.1.2 | Command Center dashboards

Abstract

Command Center dashboards provide interactive overviews of your system activity.

The Command Center dashboards provide interactive overviews of your Cortex XSIAM system status, including data ingestion metrics, incident and alert data,
automations, and more.

From the Command Center dashboards, click on elements of interest to drill down to additional dashboards and associated pages.

NOTE:

Access to the dashboards requires RBAC View permissions for Dashboards and XSIAM Command Center.

The dashboards are available in dark mode only. They are not editable, and you can't create dashboard templates or reports from them.

Some of the dashboard’s animations are not fully supported by the Safari web browser. We recommend that you view the dashboard with an alternative
web browser.

14.1.2.1 | XSIAM Command Center

Topic Not Found

14.1.2.2 | Cloud Command Center

Abstract

See a dynamic overview of the cloud activities on your tenant on the Cloud Command Center.

LICENSE TYPE:

This feature requires a Cortex XSIAM Enterprise Plus license.

The Cloud Command Center dashboard provides a dynamic overview of your cloud-based security operations with details about your cloud assets and projects,
related incidents, risks and vulnerabilities. From the dashboard you can drill down to dedicated views for further investigation into your cloud platform.

The following table describes each section on the Cloud Command Center:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 804/1003
5/8/24, 9:18 AM PDF Export

Section Details

Cloud Assets Displays information about your cloud platforms, the total number of assets configured per platform, and the
total number of cloud projects from of all of your cloud platforms. Hover over the total number of assets to
see a breakdown by category.

Line colors represent the connectivity status of the assets. You can hover over the lines to see a breakdown
of data ingestion, or details of collection errors.

NOTE:

The data ingestion breakdown is not supported by the Safari web browser. We recommend that you view
the dashboard with an alternative web browser.

If you have the enabled the Unified Inventory, you can click on a cloud platform to drilldown to the assets for
the selected platform.

Incidents Displays the total number of incidents opened in the timeframe that are associated with your cloud assets,
broken down by severity. Incidents are broken down into automated and manual incidents, where automated
incidents contain at least one playbook. You can also see the top nine open incidents as ranked by
SmartScore.

Key performance indicators Risks identified by Prisma Cloud, including attack paths, vulnerabilities, and misconfigurations.

Total number of assets discovered in the cloud.

Cloud data ingested by your cloud platforms in the timeframe, including flow logs and audit logs.

14.1.3 | Predefined Dashboards

Abstract

Cortex XSIAM comes with predefined dashboards for common reports that enable you to monitor the status of your deployment.

Cortex XSIAM provides predefined dashboards that display widgets tailored to the dashboard type. To access your default dashboard select Dashboards &
Reports → Dashboard. From the dashboard header, a drop-down menu lists the available Predefined and Custom dashboards. The available dashboards
depend on your license type.

You can rename and customize a predefined dashboard in the Dashboard Builder. For more information, see Build a Custom Dashboard.

Agent Management Dashboard

Abstract

Use the Agent Management dashboard to view information about the agents and endpoints in your system.

The Agent Management dashboard displays at-a-glance information about the endpoints and agents in your deployment.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 805/1003
5/8/24, 9:18 AM PDF Export

The dashboard includes the following Dashboard Widgets:

Agent Status Breakdown

Agent Content Version Breakdown (Top 5)

Agent Version Breakdown (Top 5)

Operating Type Distribution

Top Hosts (Top 10 | Last 30 days)

Asset Inventory dashboard

NOTE:

This dashboard is a part of the unified asset inventory and is only available when the toggle is set to the Unified Inventory view on the Asset Inventory page.

When customizing a dashboard in the Dashboard Manager, Unified Asset Inventory widgets should not be mixed with widgets from the existing inventory.

The Asset Inventory dashboard provides a detailed breakdown of assets categorized by account, type, location, and other parameters. Click on data points to
access the corresponding filtered data source on the Unified Asset Inventory page.

Attack Surface Management Dashboard

Abstract

Use the Attack Surface Management dashboard to get an overview of assets exposed to the internet, and a breakdown of relevance incidents.

NOTE:

Attack Surface Management requires the Attack Surface Management add-on.

The Attack Surface Management dashboard displays an overview of assets that are exposed to the Internet and a breakdown of incidents related to attack
surface exposure.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 806/1003
5/8/24, 9:18 AM PDF Export

The dashboard is comprised of the following Dashboard Widgets.

Open Attack Surface Incidents by Severity

Attack Surface Incidents By Status

Attack Surface Incidents Over Time

Total External Assets

Assets by Externally Detected Provider

Cloud Inventory Dashboard

Abstract

Use the Cloud Inventory dashboard to get an overview of your cloud-based assets.

The Cloud Inventory dashboard displays an overview of all your assets on the cloud.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 807/1003
5/8/24, 9:18 AM PDF Export

The dashboard is comprised of the following Dashboard Widgets:

Accounts by Cloud Provider

Compute Instances Over Time

Assets by Cloud Provider

Assets by Type

Assets by Sub-Type

Assets by Geo Region

Assets by Region

Assets by Responsive Port Number

Responsive Assets Over Time

Data Ingestion Dashboard

Abstract

Use the Data Ingestion dashboard to view information about the type and amount of data being ingested by Cortex XSIAM.

The Data Ingestion dashboard displays an overview and detailed information regarding the type and amount of data ingested by Cortex XSIAM according to the
Products and Vendors used. For example, Syslog Collector, Check Point logs, and authentication logs.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 808/1003
5/8/24, 9:18 AM PDF Export

The dashboard is comprised of the following Dashboard Widgets:

Daily Consumption—Stacked graphs measuring your daily data consumption, according to either Vendors (default) or Products, versus your daily
consumption limit. Each bar indicates a 24 hour range over the past 14 days. Cortex XSIAM measures and enforces the 24 hour rage according to UTC,
but the graph displays the 24 hour rage according to the selected tenant timezone.

Ingestion Rate—Displays your data ingestion rate, measured in Traffic/ Sec, over the past 24 hours, 7 days, or 30 days filtered according to the type of
Vendors (default), Products, or All Sources.

Detailed Ingestion—Table listing for the different Products (default) or Vendors, the LAST SEEN date and time, LAST DAY INGESTED for the amount of
data ingested over the last 24 hour range, and the CURRENT DAY INGESTED for the current amount ingested in the past 24 hours. Detailed ingestion for
the current 24 hours is updated in 5 minute intervals.

NOTE:

Due to a calculation change in NGFW log ingestion and improvements to data ingestion metrics, you cannot view data earlier than July 2023 on this
dashboard. However, you can still view this data by running Cortex XQL Language (XQL) queries on the metrics_center data set.

Incident Management Dashboard

Abstract

Use the Incidents Management dashboard to view a summary of incidents in your environment.

The Incidents Management dashboard provides a graphical summary of incidents in your environment, with incidents prioritized and listed by severity, assignee,
incident age, and affected hosts.

The dashboard includes the following Dashboard Widgets:

Incidents by Assignee (Top 10 | Last 30 days)

Open Incidents

Open Incidents By Severity (Last 30 days)

Open Incidents by Assignee Over Time (Top 10)

Top Hosts (Top 10 | Last 30 days)

Tasks By Assignee

Top Incidents (Top 10)

To filter a widget to display only incidents that match incident starring policies, select the star in the right corner. A purple star indicates that the widget is
displaying only starred incidents. The starring filter is persistent and will continue to show the filtered results until you clear the star.

IT Metrics Dashboard

Abstract

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 809/1003
5/8/24, 9:18 AM PDF Export

Gain visibility into IT performance on your agent with the IT Metrics dashboard.

The IT Metrics dashboard displays an overview of IT performance on your Cortex XDR Agent. On the dashboard you can review CPU and memory performance
data, connectivity data, and data about hard reboots and crashed applications.

The dashboard comprises the following widgets:

Current Internet Connectivity Status

Max CPU consumption (Top hosts | 24 hours)

Max Memory consumption (Top hosts | 24 hours)

Hard reboots

Applications Crashing (supported for Windows agents only)

Average CPU consumption (Top processes | 24 hours)

Average memory consumption (Top processes | 24 hours)

MITRE ATT&CK Framework Coverage Dashboard

Abstract

Learn more about the MITRE ATT&CK Coverage methods available in Cortex XSIAM.

The MITRE ATT&CK Framework Coverage dashboard displays a comprehensive overview of the Cortex XSIAM content and capabilities in context with the
MITRE ATT&CK framework.

On this dashboard you can see a breakdown of the protection modules and detection rules in place for each MITRE tactic and technique. You can use the
dashboard to review the elements that affect your coverage, and identify coverage gaps in your framework.

The dashboard is comprised of the following widgets:

Number of Detection Rules Per Tactic—Displays the number of detection rules that are available for each MITRE tactic.

MITRE ATT&CK Framework Coverage— Displays a MITRE matrix detailing the available coverage for each tactic and technique. By default, covered
methods are displayed. Click on a tactic or technique for details about the available prevention and detection methods. Note that the Protection numbers
represent modules, which are a grouping of several protections.

Contributing Data Source Types— Displays the connectivity status of the data sources that are contributing to a specific data source type on your
system.

NOTE:

When a contributing data source type is active, it does not imply that all the rules and detectors associated with the data source type are active. Rule
applicability is dependent on the data source's context and configuration. To enable an active status, data source types require the following setup:

Endpoint— Installed Cortex XDR agent.

Network— A contributing network device that is configured to ingest logs as Cortex XSIAM network connection stories.

Cloud— A data source that is contributing the required cloud related information.

Identity— An identity application that is supported in IA (Identity Analytics) and the ITM (Identity Threat Module).

For more information, contact your Customer Success representative.

NOTE:

The Number of Detection Rules Per Tactic and MITRE ATT&CK Framework Coverage widgets display a static overview of the available protections. They do
not reflect the protections that are currently active on the system.

My Dashboard

Abstract

Use My Dashboard to view incidents and MTTR for the logged-in user.

My Dashboard provides an overview of the incidents and MTTR for the logged-in user.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 810/1003
5/8/24, 9:18 AM PDF Export

The dashboard includes the following Dashboard Widgets:

My Incidents

My MTTR by Severity vs Target

My Open Incidents By Severity

My Incidents Over Time

Network Traffic Analysis (NTA) Dashboard

Abstract

Use the Network Traffic Analysis dashboard to visualize and track your network traffic.

The Network Traffic Analysis (NTA) dashboard helps you better visualize and track your Cortex XDR Network Traffic.

The dashboard is comprised of the following sections:

Overview

Threats

Network Zones

Geo Locations

DNS Activity

HTTP Activity

URL Activity

NGFW Ingestion Dashboard

Abstract

Use the NGFW Ingestion dashboard to see an overview of ingestion status for all log types, the daily quota consumption for NGFW, and a breakdown by log
type.

The NGFW Ingestion Dashboard provides an overview of ingestion status for all log types, the daily quota consumption for NGFW, and a breakdown by log type.

The dashboard includes the following Dashboard Widgets:

NGFW Daily Consumption

NGFW Ingestion Rate

NGFW Detailed Ingestion by log type

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 811/1003
5/8/24, 9:18 AM PDF Export

Playbook Optimization Dashboard

Abstract

Use the Playbook Optimization dashboard to get an overview of Playbook, script, and command metrics for optimization.

The Playbook Optimization dashboard provides an overview of Playbook, script, and command metrics for optimization.

The dashboard is comprised of the following Dashboard Widgets:

Playbook Runs

Task Executions

Average Runtime per Playbook

Average Runtime per Automation

Command Executions Per Integration Category

Command Executions by Type

Risk Management Dashboard

Abstract

Use the Risk Management dashboard to view alert and incident information against the background of baseline information, to aid in risk assessment.

NOTE:

This dashboard is available only when the Identity Threat Module add-on is enabled.

The Risk Management dashboard presents alert and incident information against the background of baseline information. The widgets in the dashboard enable
you to asses the risk your organization faces from compromised accounts and insider threats. The alerts are included in this dashboard if they are tagged by the
research as Identity Threat alerts or Identity Analytics alerts. An incident is included in the widgets even if only one alert in the incident is tagged as an Identity
threat or an Identity Analytics threat.

NOTE:

The Risk Management dashboard is provided as part of the Identity Threat Module add-on.

The dashboard includes the following Dashboard Widgets, detailed under Metrics Widgets.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 812/1003
5/8/24, 9:18 AM PDF Export

Users

Hosts

Identity Alerts and Insights

Score Trend Timeline

Top 10 Incidents

Top 5 Hosts at Risk

Top 5 Users at Risk

Watchlist

Security Admin Dashboard

Abstract

Use the Security Admin dashboard to view information about incidents, and the status of resolved and overdue ones.

The Security Admin Dashboard displays an overview and detailed information regarding the incidents across your organization and the status of resolved and
overdue incidents.

The dashboard includes the following Dashboard Widgets:

Incident Status Board—Displays a breakdown of the incidents over the last 30 days, 7 days, or 24 hours.

Resolved Incident MTTR—Displays the overall MTTR of all incidents created by severity and the average time it took to resolve the incidents compared to
the defined Target MTTR over the last 30 days, 7 days, or 24 hours.

Overdue Incidents of Top 5 Assignees—Displays the top 5 assignees by assignee name with the highest number of overdue incidents over the last 30
days, 7 days, or 24 hours according to the incidents creation time.

Incidents Over Time—Displays the number of new incidents and resolved incidents over 14 days.

Newest Incidents— Display incidents details of the 5 most recent incidents.

Security Manager Dashboard

Abstract

Use the Security Manager dashboard to view general information about incidents and agents.

The Security Manager Dashboard widgets display general information about Cortex XSIAM incidents and agents.

The dashboard includes the following Dashboard Widgets:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 813/1003
5/8/24, 9:18 AM PDF Export

Agent Status Breakdown

Agent Version Breakdown (Top 5)

Incidents by Assignee (Top 10 | Last 30 days)

Open Incidents By Severity (Last 30 days)

Top Incidents (Top 10)

Open Incidents

Threat Intel Management Dashboard

Abstract

Use the Threat Intel Management dashboard to view information about malicious or suspicious indicators in incidents.

The Threat Intel Management dashboard provides information about malicious or suspicious indicators in incidents.

The dashboard is comprised of the following Dashboard Widgets.

Active Indicator Volumes by Feed

Active Indicators by Type

Active Indicators by Verdict

14.1.4 | Build a Custom Dashboard

Abstract

You can customize the Cortex XSIAM dashboard to display and filter information that is most relevant to you and best presented for your review.

To create purposeful dashboards, consider the information that you require in your day-to-day operations. When you create a dashboard, you select widgets
from the widget library and choose their placement on the dashboard.

If you include Custom Cortex Query Language (XQL) widgets with parameter filters, you configure the parameters to filter widget data on the dashboard. When
you generate the dashboard, the header displays all defined filters. You can update the values directly in the header to alter the scope of the dashboard. For
more information, see Using dashboard filters and inputs.

1. Select Dashboards & Reports → Customize → Dashboards Manager → + New Dashboard.

2. In the Dashboard Builder, enter a unique Dashboard Name and an optional Description of the dashboard.

3. Choose the Dashboard Type and click Next.

You can use an existing dashboard as a template, or you can build a new dashboard from scratch.

4. Customize your dashboard.

To get a feel for how the data will look, Cortex XSIAM provides mock data. To see how the dashboard would look with real data in your environment, you
can use the toggle above the dashboard to use Real Data.

5. Add widgets to the dashboard. From the widget library, drag and drop widgets on to the dashboard.

a. For agent-related widgets, limit the results to only the endpoints that belong to the group by applying an endpoint scope.

Select the menu on the top right corner of the widget, select Groups, and select one or more endpoint groups.

b. For incident-related widgets, select the star to display only incidents that match an incident starring configuration on your dashboard, if desired. A
purple star indicates that the widget is displaying only starred incidents (see Manage Incident Starring).

6. (Optional) If your dashboard includes XQL widgets with dynamic parameters, you can Add FILTERS & INPUTS. For more information, see Configuring
Filters, Inputs, and Drilldowns.

7. (Optional) If your dashboard includes XQL widgets, you can configure drilldowns.

8. Set a Time Range for your dashboard.

By default, the widgets use the dashboard time frame. You can change the widget time frame by selecting the menu in the top right corner of the widget.

9. When you have finished customizing your dashboard, click Next.

10. To set the custom dashboard as your default dashboard, select Define as default dashboard.

11. To keep this dashboard visible only for you, select Private.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 814/1003
5/8/24, 9:18 AM PDF Export

Otherwise, the dashboard is public and visible to all Cortex XSIAM app users with the appropriate roles to view dashboards.

12. Generate your dashboard.

14.1.4.1 | Manage Your Widget Library

Abstract

Create, search, and view custom widgets in Cortex XSIAM, or use predefined widgets.

The widget library displays predefined widgets and user-created Custom Cortex Query Language (XQL) widgets. You can include these widgets in your custom
dashboards and reports. To access the widget library, navigate to Dashboards & Reports → Customize → Widget Library.

Create and Edit Custom Widgets Based on XQL Search Queries

1. In the widget menu, Create custom XQL widget.

2. Enter a widget Name and Description.

3. Create an XQL query. Select XQL Helper to view XQL search and schema examples.

4. Generate the XQL query to display the search results.

NOTE:

Cortex Query Language (XQL) queries generated from the widget library do not appear in the Query Center. The results are used only for creating the
custom widget.

5. In the Widget section, define how you want to visualize the results.

6. (Optional) Add parameters to the query.

You can use parameter filters to filter widget data on a dashboard or report, and create drilldowns on dashboards. For more information, see Using
Dashboard Filters, Inputs, and Drilldowns.

NOTE:

Use the filter stage with parameters prefixed with $.

If you specify a single value for a parameter, use the = operator. To specify multiple values for a parameter, use the IN operator.

If you Assign Parameters (default values), data is automatically populated when you add the widget to a dashboard or report. Alternatively, you
can configure default values when you set up a dashboard or report.

Parameter filter examples:

The following XQL query specifies a parameter that can be configured to filter a single value.

dataset = <dataset> | filter name = $name

The following XQL query specifies a parameter that can be configured to filter multiple static or dynamic values:

dataset = <dataset> | filter name IN ($name)

7. (Optional) Specify a time frame. The default time frame is 1M.

8. Save widget.

The custom widget appears in the list of existing widgets.

Search for Custom and Predefined Widgets

1. Search for a widget or Show widgets according to the widget category.

2. Select a widget type to display the widget graph type and parameters. By default, Cortex XSIAM displays the widget with Mock Data. Toggle to display
your current Real Data.

Edit or Delete Custom Widgets

1. Identify a custom widget to update or delete.

2. Select Update widget ( ) or Delete widget from library.

NOTE:

Any dashboards or reports that include the widget are affected by the changes.

14.1.4.1.1 | Dashboard Widgets

Abstract

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 815/1003
5/8/24, 9:18 AM PDF Export

Learn about the widgets that you can use on your Cortex XSIAM custom dashboards.

Cortex XSIAM provides the following list of widgets to help you create dashboards and reports displaying summarized information about your endpoints.

Agent Management Widgets

Abstract

Learn about Agent Management dashboard widgets.

Widget Name Description

Agent Content Version Breakdown Displays the total number of registered Cortex XSIAM agents and the
distribution of agents by content update version.

Agent Status Breakdown Displays the total number of Cortex XSIAM by the agent status.

Agent Upgrade Failure Reasons Displays the reasons for upgrade failures. Clickable links provide more
details for each one.

Agent Upgrade Statuses Displays the number of agents currently reporting each upgrade status
category. Clickable links provide more details for each one.

Agent Version Breakdown Displays the total number of registered Cortex XSIAM agents and the
distribution of agents by agent version.

Failed Agent Upgrades over Time Displays failed upgrade trends over time (last 24 hours, 7 days, or 30 days);
agent status (connected, disconnected, connection lost, uninstalled); or
agent groups scope.

Number of Installed Agents Displays a timeline of the number of agents installed on endpoints over the
last 24 hours, 7 days, or 30 days.

Operating System Type Distribution Displays the total number of registered agents and their distribution
according to the operating system.

Successful Agent Upgrades over Time Displays successful upgrade trends over time (last 24 hours, 7 days, or 30
days); agent status (connected, disconnected, connection lost, uninstalled);
or agent groups scope.

Asset Widgets

Abstract

Learn about Assets dashboard widgets.

Widget Name Description

Managed Assets vs Unmanaged Assets Displays a detailed breakdown of your active managed and unmanaged
assets.

Assets by Externally Detected Provider Displays a breakdown of all externally detected providers of internet-
exposed assets.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 816/1003
5/8/24, 9:18 AM PDF Export

Widget Name Description

Number of Installed Agents Displays a timeline of the number of agents installed on endpoints over the
last 24 hours, 7 days, or 30 Days.

Operating System Type Distribution Displays the total number of registered agents and their distribution
according to the operating system.

Top 5 Notable Users Displays the top 5 users with the highest User Score. Select a user to pivot
to the User View.

Total External Assets Displays a breakdown of all internet-exposed assets.

Cloud Widgets

Abstract

Learn about Cloud dashboard widgets.

Widget Name Description

Accounts by Cloud Provider Displays the number of accounts held in each cloud provider. Refreshes
every two hours.

Assets by Cloud Provider Displays the number of assets stored in each cloud provider. Refreshes
every two hours.

Assets by Geo Region Displays a breakdown of assets in each geographic region. Refreshes every
two hours.

Assets by Region Displays a breakdown of assets in each region. Refreshes every two hours.

Assets by Responsive Port Number Displays the number of exposed cloud assets by port number. Refreshes
every two hours.

Assets by Sub-Type Displays a breakdown of cloud assets by sub-type. Refreshes every two
hours.

Assets by Type Displays a breakdown of cloud assets by type. Refreshes every two hours.

Compute Instances Over Time Displays the number of times a virtual machine instance is used over time.

Select the time scope in the upper right to view the number of Compute
Instances over the last 24 hours, 7 days, or 30 days.

Responsive Assets Over Time Displays the number of exposed cloud assets over time.

Select the time scope in the upper right to view the number of exposed
cloud assets over the last 24 hours, 7 days, or 30 days.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 817/1003
5/8/24, 9:18 AM PDF Export

Custom Widget

Abstract

Learn about Custom dashboard widgets.

Widget Name Description

Custom Widget Displays visualization (such as chart, graph, or additional visualization

types) for the results of an XQL Search.

See the XQL Language Reference guide for detailed information about
creating an XQL Search Query.

Host Insights

Abstract

Learn about Host Insights dashboard widgets.

Widget Name Description

CVEs By Severity Provides a summary of the total number of existing CVEs in your network
according to critical, high, medium, and low severity.

Click a severity to open a filtered view of the CVEs.

Top CVEs By Affected Endpoints Displays the top Critical, High, and Medium severity CVEs currently existing
in your network according to the total number of endpoints affected by each
CVE.

Click a CVE to open a filtered view of all affected endpoints.

Top Vulnerable Applications Displays the most vulnerable applications with the highest number of
Critical, High, and Medium severity CVEs. Cortex XSIAM calculates the
vulnerabilities for different application versions running on different operating
systems.

Click an application to open a filtered view of all existing CVEs for the
selected application.

Top Vulnerable Endpoints Displays the most vulnerable endpoints with the highest number of critical,
high, and medium CVEs.

Click a host to open a filtered view of all existing CVEs for the selected host.

Vulnerabilities On All Endpoints Over Time Displays CVEs over time across your network.

Select the time scope in the upper right to view the number of CVEs over
the last 24 hours, 7 days, or 30 Days.

Hover over the graph to view the number of existing CVEs on a specific day.

Incident Management Widgets

Abstract

Learn about Incident Management dashboard widgets.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 818/1003
5/8/24, 9:18 AM PDF Export

Widget Name Description

Attack Surface Incidents By Status Displays the breakdown of the attack surface incidents in the system by
their status, at this moment in time.

Attack Surface Incidents Over Time Displays the total count of new and resolved attack surface incidents per
day.

Incidents By Assignee Displays the top 10 users that are assigned the highest number of incidents
over the last 30 days. For each assignee, the widget displays the distribution
of Aged and Total Open incidents. Aged incidents are older than one week
which have remained unresolved.

Select an assignee to open the incidents table filtered to display incidents

that are assigned to the selected assignee.

Incidents By MITRE ATT&CK Display a breakdown of the number of incidents involved with each MITRE
ATT&CK tactic and technique over the last 30 days, 7 days, 24 hours, or
custom time range according to the incidents creation time.

Select a tactic or technique to pivot to the Incidents Table filtered according

to the tactic/technique and creation time.

Incidents By Status Provides a summary of the total current number of open incidents according
to status. Click a status to open a filtered view of the incidents.

Incidents by Status Duration (Last 30 Days) Displays the average, maximum, and minimum time that incidents stayed in
a given status over the last 30 days.

You can click a maximum or minimum time for a status to open the incident
related to the max/min time.

Incidents Status Board Displays the last 30 days, 7 days, or 24 hours of the following information
according to the incidents creation time:

Total number of open incidents, how many are unassigned, and how
many are overdue according to the incident severity.

Breakdown of open incidents according to the status New and Under

Investigation.

Breakdown of resolved incidents according to resolved reason.

For further investigation, select each of the available breakdowns to pivot to

the Incident table sorted according to the incident creation time and selected
breakdown.

Incidents Over Time Displays the following information over the past 14 days:

Number of new incidents created per day.

Number of resolved incidents per day.

For further investigation, select each of the bars to pivot to the Incident table
sorted according to the creation date within the selected 24 hours.

My Incidents Displays all active incidents assigned to the logged-in user, sorted according
to the creation date. You can sort the list by age, severity or score.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 819/1003
5/8/24, 9:18 AM PDF Export

Widget Name Description

My Incidents Over Time Displays the daily number of new and resolved incidents assigned to the
logged-in user for the past 14 days.

My Open Incidents by Severity Displays a breakdown of open incidents assigned to the logged-in user,
grouped by severity, over the last 30 days. Click a severity level to open a
list of incidents filtered by that severity level.

My MTTR Displays the Mean Time to Resolve (MTTR) incidents assigned to the
logged-in user, compared to the defined Target MTTR. Available date filters
are 24 hours, 7 days, and 30 days.

Newest Incidents Displays the following details for the 5 most recent incidents:

Starred

Severity

ID

Score

Description

Creation time

Overdue Incidents of top 5 Assignees Displays the last 30 days, 7 days, or 24 hours of the following information
according to the incidents creation time:

Top 5 assignees, by assignee name, with the highest number of

overdue incidents.

For further investigation, select a user to pivot to the Incident table filtered
according to the incident creation time and assignee.

Resolved Incidents by Assignee Displays a breakdown of the top five users with the most resolved incidents
assigned to them according to the incident creation time.

For further investigation, select an assignee to pivot to the Incidents table

filtered according to the assignee and the resolved incident resolution time.

Resolved Incidents MTTR Displays either the last 30 days, 7 days, or 24 hours of the following
information according to incident creation time and resolved statuses:

Total Mean Time to Resolve (MTTR) of all incidents, according to

severity, created during the selected time frame and the average time
it took to resolve the incidents compared to the defined Target MTTR.

For further investigation, select a severity bar to pivot to the Incident table
filtered according to the incident creation time and severity.

Indicator Widgets

Abstract

Learn about Indicator dashboard widgets.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 820/1003
5/8/24, 9:18 AM PDF Export

Widget Name Description

Active Indicator Volumes by Feed Displays which feeds bring the most number of indicators over the last 24
hours, 7 days or 30 days. Displays active indicators grouped by calculation
time and by source. To view the data in this widget, you must have the View
Integration Threat Intel permission.

Active Indicators by Type Displays the breakdown of active indicators by type over the last 24 hours, 7
days or 30 days. Click a section of the chart to view the Indicator screen
filtered by that type. To view the data in this widget, you must have the View
Integration Threat Intel permission.

Active Indicators by Verdict Displays the breakdown of active indicators by verdict over the last 24
hours, 7 days or 30 days. Click a section of the chart to view the Indicator
screen filtered by that verdict.To view the data in this widget, you must have
the View Integration Threat Intel permission.

Investigation Widgets

Abstract

Learn about Investigation dashboard widgets.

Widget Name Description

Data Usage Breakdown Displays a timeline of the consumption of Cortex XSIAM data in TB. Hover
over the graph to see the amount at a specific time.

Detection By Actions Displays the top five actions performed on alerts or incidents. In the upper
right corner:

Toggle between alerts and incidents

Select to view the number of alert/incidents per action over the last 24
hours, 7 days, or 30 Days

Detections By Category Displays the top five categories of alerts or incidents. In the upper right
corner:

Toggle between alerts and incidents

Select to view the number of alert/incidents per category over the last
24 hours, 7 days, or 30 Days

Detection By Source Displays the top five sources of alerts or incidents. In the upper right corner:

Toggle between alerts and incidents

Select to view the number of alert/incidents per source over the last
24 hours, 7 days, or 30 Days

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 821/1003
5/8/24, 9:18 AM PDF Export

Widget Name Description

MITRE ATT&CK Framework Coverage Displays a MITRE matrix detailing the available coverage for each tactic and
technique in Cortex XSIAM. By default, covered methods are displayed.
Click on a tactic or technique for details about the available protection and
detection methods.

NOTE:

This widget displays a static overview of the available protection

and detection methods. It does not reflect the methods that are
currently active on the system.

The protection numbers represent modules, which are a grouping

of several protections.

MITRE Coverage Report Displays information about MITRE ATT&CK coverage in Cortex XSIAM. The
widget includes the number of techniques covered, and the number of
protection modules and detection rules available for each tactic. This widget
is suitable for reports.

Number of Detection Rules Per Tactic Displays the number of detection rules that are available for each MITRE
tactic, broken down by detection type.

Open Attack Surface Incidents by Severity Displays the breakdown of open attack surface incidents by severity at this
point in time.

Open Incidents Displays a timeline of aged versus open incidents, or open alerts. Aged
incidents and alerts are older than one week and remain unresolved.

Refine the data in the graph from the widget menu. You can select the time
frame, detection type, and group the data by hour, day, or week.

Hover over the graph to view additional details.

Open Incidents by Assignee Over Time (Top 10) Displays the top ten assignees with the highest number of assigned
incidents over a selected time frame.

Refine the data in the graph from the widget menu. You can select the time
frame, group the data by hour, day, or week, and select specific assignees
or unassigned incidents.

Open Incidents by Severity Displays the total open incidents over the last 30 days according to severity.

Select a severity to open a filtered view of incidents by the selected severity.

Response Action Breakdown Displays the top response actions taken in the Action Center over the last 24
hours, 7 days, or 30 Days.

Top Hosts Displays the top ten hosts with the highest number of incidents in order of
severity over the last 30 days. Incidents are color-coded: red for high
severity and yellow for medium severity.

Click a host to open a filtered view of all open incidents for the selected
host.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 822/1003
5/8/24, 9:18 AM PDF Export

Widget Name Description

Top Incidents Displays the top ten current incidents with the highest number of alerts
according to severity over the last 30 days, and each incident's score. Alerts
are color-coded; red for high and yellow for medium.

Click a severity to open a filtered view of all open alerts for the selected
incident.

Top incidents can be sorted by score.

IT Metrics Widgets

Abstract

Learn about IT metrics widgets.

Widget Name Description

Applications Crashing Displays applications that crashed during the selected time frame, the number of crashes per app, and the number of
hosts on which the app crashed. This widget is supported for Windows agents only.

Average CPU Consumption (Top Displays the average CPU consumption for the processes with highest average consumption.
30 Processes)

Average Memory Consumption Displays the average mem consumption for the processes with highest average consumption.
(Top 30 Processes)

Current Internet Connectivity Displays the current internet connectivity status for all endpoints.
Status

Hard Reboots Displays the total amount of hard reboots that occurred in the time frame.

Max CPU Consumption (Top 10 Displays the maximum percentage of CPU consumption for the top 10 hosts.
Hosts)

Max Memory Consumption (Top Displays the maximum percentage of memory consumption for the top 10 hosts.
10 Hosts)

Metrics Widgets

Abstract

Learn about Metrics dashboard widgets.

Widget Name Description

Average Runtime per Playbook Displays a breakdown of the average runtime of Playbooks over the last 24
hours, 7 days or 30 days. To view the data in this widget, you must have the
permission to view Playbooks.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 823/1003
5/8/24, 9:18 AM PDF Export

Widget Name Description

Average Runtime per Automation Displays a breakdown of the average script execution grouped by script
name duration per Automation over the last 24 hours, 7 days or 30 days. To
view the data in this widget, you must have the permission to view Scripts.

Command Executions by Type Displays a breakdown of command executions by Incident type over the last
24 hours, 7 days or 30 days. To view the data in this widget, you must have
the permission to view Integrations.

Command Executions Per Integration Category Displays a breakdown of command executions per Integration category over
the last 24 hours, 7 days or 30 days. To view the data in this widget, you
must have the permission to view Integrations.

Hosts Displays the number of hosts associated with identity threats tagged by
Identity Analytics or the Identity Threat module.
NOTE:

To view this widget, you must have the Identity Threat Module add-on
enabled.

Identity Alerts and Insights Displays the number of anomalies associated with identity threats tagged by
Identity Analytics or the Identity Threat module. To see the list of alerts and
NOTE:
insights, click the number.
To view this widget, you must have the Identity Threat Module add-on
enabled.

Playbook Runs Displays a breakdown of Playbook executions grouped by Playbook names

over the last 24 hours, 7 days or 30 days. To view the data in this widget,
you must have the permission to view Playbooks.

Score Trend Timeline Displays the organizational risk score trend over time. The organizational
risk score is calculated using the score and the number of users whose risk
NOTE:
score is greater than 0. Each bubble indicates the number of alerts and
To view this widget, you must have the Identity Threat Module add-on incidents created per day. Bigger bubbles represent more alerts and
enabled. incidents, and a possible risk.

Task Executions Displays a breakdown of Task executions by command execution type over
the last 24 hours, 7 days or 30 days.

Top 5 Hosts at Risk Displays the hosts that are most vulnerable to potential security threats.

NOTE:

To view this widget, you must have the Identity Threat Module add-on
enabled.

Top 5 Users at Risk Displays the users that are most vulnerable to potential security threats.

NOTE:

To view this widget, you must have the Identity Threat Module add-on
enabled.

Top 10 Incidents Displays the top 10 identity related incidents ordered by score.

NOTE:

To view this widget, you must have the Identity Threat Module add-on
enabled.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 824/1003
5/8/24, 9:18 AM PDF Export

Widget Name Description

Users Displays the number of users associated with identity threats tagged by
Identity Analytics or the Identity Threat module.
NOTE:

To view this widget, you must have the Identity Threat Module add-on
enabled.

Watchlist Displays the users who are most vulnerable to potential security threats.

NOTE:

To view this widget, you must have the Identity Threat Module add-on
enabled.

Network Traffic Analysis (NTA) Widgets

Abstract

Learn about Network Traffic Analysis dashboard widgets.

Widget Name Description

Actions Pie chart displaying the number of network traffic actions that occurred over
the last 24 hours. For example; block-url, drop-packet, and alert.

Daily DNS Queries Line graph displaying the number of DNS queries executed over the last 24
hours.

Daily Threats Area graph displaying the number of threats detected over that last 24
hours.

DNS Response Codes Pie chard displaying the number of DNS response codes over the last 24
hours. For example; Server Failure, Not Implemented, and No Error.

From Zone Bar graph displaying the amount of traffic over the last 24 hours from each
type of network zone. For example; lan-tap, TAP, and internet.

GB Sent and Received Line graph displaying the GB sent and received over the last 24 hours.

Geo Locations World map displaying the amount of network traffic according to
geographical area.

HTTP Content Type Pie chart displaying the amount of a HTTP content type running over the
network over the last 24 hours. For example; text/xml and application/ocsp-
request.

HTTP Method Pie chart displaying the how many HTTP method types were running over
the network over the last 24 hours. For example; PCHE, CPID, and UHDJ.

HTTP Response Codes Pie chart displaying the how many HTTP response codes were returned
over the network over the last 24 hours. For example; 200, 404, and 301.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 825/1003
5/8/24, 9:18 AM PDF Export

Widget Name Description

HTTP User Agent Bar chart displaying how many HTTP user agent types were used over the
last 24 hours. For example; curl and Go-http-client.

Recent Threats Table displaying Cortex XDR collected data of the threats detected over the
last 24 hours. For example; Source IP, Severity, and ID of the threat.

Transport Protocols Pie chart displaying the amount of transport protocol types used over the
last 24 hours. For example; TCP, UDP, and ICMP.

Threat Category Pie chart displaying the number of threat category types detected over the
last 24 hours. For example; dns-ddns, spyware, and brute-force.

Threat Severity Pie chart displaying the total number and breakdown of threat severity types
detected over the last 24 hours. For example; Informational, Medium, and
Critical.

Threat Sources Pie chart displaying the number of IP addresses from which the threats were
detected over the last 24 hours. For example; dns-ddns, spyware, and
brute-force.

Top App-IDs Pie chart displaying the number of App-IDs that accessed the network over
the last 24 hours

Top Geo Locations Pie chart displaying the number of network accesses from specific Geo
locations.

To Zone Bar graph displaying the amount of traffic over the last 24 hours to each
type of network zone. For example; lan-tap, TAP, and internet.

URL Categories Word Cloud graph displaying type of URLs that accessed the network over
the last 24 hours.

URL Risk Pie chart displaying the number of unknown URLs over the last 24 hours.

Zones Bar graph displaying the amount of traffic over the last 24 hours of each
type of network zone. For example; lan-tap, TAP, and internet.

System Monitoring Widgets

Abstract

Learn about System Monitoring dashboard widgets.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 826/1003
5/8/24, 9:18 AM PDF Export

Widget Name Description

Connected Data Sources Displays the connectivity status of the data sources that are contributing to a
specific data source type on your system.

NOTE:

When a data source type shows an active status, it does not imply that all
detectors associated with the data source are active. For more
information about the requirements to activate a data source type, see
MITRE ATT&CK Framework Coverage Dashboard.

Ingestion Rate Displays the rate at which Cortex XSIAM consumes data ingested from a
specific vendor or product over the past 24 hours, 7 days, or 30 days. All
ingestion rates are measured by bytes per second.

Daily Consumption A breakdown comparing the product/vendor consumption versus your

allowed daily limit over the past 24 hours, displayed in UTC.

The Daily limit is calculated according to your license: Amount of TB / 30

days

NOTE:

If the ingestion rate has exceeded your daily limit, Cortex XSIAM will
issue a notification through the Notification Center and email. After 3
continuous days of exceeding the ingestion rate, Cortex XSIAM will stop
ingesting data that exceeds the daily limit.

Detailed Ingestion Breakdown of ingestion data per vendor or product over the past 30 days.

Filter the following information for each source:

Product/Vendor—Name of the selected product or vendor.

First Seen—Timestamp of when product/vendor were first ingested.

Last Seen—Timestamp of when product/vendor were last ingested.

Last Day Ingested—Amount of data ingested over the past 30 days.

Current Day Ingested—Amount of data ingested over the past 24

hours.

Tasks Widgets

Abstract

Learn about Tasks dashboard widgets.

Widget Name Description

My Tasks Displays all active Playbook and To-Do tasks assigned to the logged-in user,
sorted by alert ID and then by task ID. Click the task to view the alert and
the task details in the Work Plan.

Return on Investment Displays the amount saved in dollars based on actions carried out by all
users in XSIAM across all incidents.

Tasks By Assignee Displays the top 10 users that are assigned the highest number of tasks
over the last 30 days. For each assignee, the widget displays the distribution
of Aged and Total Open tasks. Aged tasks are incomplete tasks older than
one week.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 827/1003
5/8/24, 9:18 AM PDF Export

User Defined Widgets

Abstract

Learn about user defined dashboard widgets.

Widget Name Description

Free Text Displays a text box allowing to insert free text.

Header Displays a title containing the free text. For example, name and description
of a report or dashboard, customer name, tenant ID, or date.

XQL Search

Abstract

Learn about the XQL Search dashboard widget.

Widget Name Description

XQL Query Displays visualization (such as chart, graph, or additional visualization

types) for the results of an XQL Search query over the past 24 hours, 7
days, or 30 days. By default, the query runs every 24 hours . Update Now to
rerun the query immediately.

See the XQL Language Reference guide for detailed information about
creating an XQL query.

14.1.4.2 | Using Dashboard Filters, Inputs, and Drilldowns

Abstract

Explains how to use dashboard filters and drilldowns.

On Custom dashboards, you can set up fixed filters, inputs, and drilldowns to enable you and other analysts to filter and manipulate the data of a dashboard.

Dashboard Filters

Fixed dashboard filters are displayed in the dashboard header. Depending on the configuration, the filters take the following format:

Free text/number: manually enter filter values into the input field.

Single Select: select a single predefined filter value from the dropdown list.

Multi Select: select multiple predefined or dynamic filter values from the dropdown list. For Multi Select Dynamic values, the list displays the first 100
results from the specified field. You can choose a value from the list, or start typing to search for a specific value.

Fixed filters are based on parameters that are defined in Custom XQL widgets. For information, see Manage Your Widget Library and Configuring Filters &
Inputs. Temporary filters are also displayed in the dashboard header, however these filters cannot be modified unless they are configured in the widgets and on
the dashboard.

Dashboard Drilldowns

Abstract

Dashboard drilldowns provide interactive data insights when clicking on data points, table rows, or other visualization elements.

Dashboard drilldowns provide interactive data insights when clicking on data points, table rows, or other visualization elements. Drilldowns can trigger contextual
changes on the dashboard, or they can link to an XQL search, a custom URL, another dashboard, or a report.

Hover over a widget to see details about the drilldown, and click a value to trigger the drilldown. If the drilldown triggers an in-dashboard drilldown, all widgets
that use the selected parameter are affected. Parameters that are configured as fixed filters are displayed in the dashboard header. Parameters that are not
configured are added as temporary filters. For more information, see Configuring Filters, Inputs, and Drilldowns.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 828/1003
5/8/24, 9:18 AM PDF Export

14.1.4.3 | Configuring Filters, Inputs, and Drilldowns

Abstract

Explains how to configure fixed filters on dashboards, and dashboard drilldowns.

You can configure fixed filters and dashboard drilldowns on Custom dashboards that contain XQL widgets.

Fixed filters are based on parameters defined in the Custom XQL widgets within the dashboard. To configure fixed filters:

1. Create custom XQL widgets with parameters, as explained in Create and Edit Custom Widgets Based on XQL Queries.

2. Add the widgets to a Custom dashboard, as explained in Build a Custom Dashboard.

3. Configure the parameters as fixed filters on the dashboard, as explained in Configuring Filters & Inputs.

You can use these parameters to create in-dashboard drilldowns, and drilldowns that map parameters to target dashboards, however not all drilldowns require
parameters. For more information, see Configuring Drilldowns.

After configuration, anyone who views your dashboard can change the fixed filters from the dashboard header and use the configured drilldowns.

Configuring Filters & Inputs

You can configure a maximum of five fixed filters on a dashboard. Filters can use predefined or dynamic values, and are based on parameters that you
configure in Custom XQL widgets.

1. Open a Custom dashboard and select Edit dashboard.

2. Add Filters & Inputs.

3. On the FILTERS & INPUTS panel, +Add an input and select one of the following options:

Single Select to specify a single predefined value

Multi Select to specify multiple predefined or dynamic values

Free text/number to specify a single free text value

4. Update the Parameter Title.

5. Select the Parameter that you want to configure.

These values are extracted from the XQL queries of the widgets on the dashboard.

6. If you selected Single Select or Multi Select values, specify Dropdown Options.

When you generate the dashboard, these values appear in a dropdown list for selection.

For Single Select and Multi Select Predefined values, manually type the list values.

The values must support the parameter type. For example, for $name specify characters and for $num specify numbers.

If you uploaded numbers in a string, specify each number in quotes, for example "500".

For Multi Select Dynamic values, configure an XQL Query to fetch dynamic values.

In the XQL Query Builder, configure a query that includes the field stage and the name of the column from which to take the dropdown values. All
values in the specified field will be available for selection, and the values are dynamically updated.

In this example, the name column is configured:

dataset = <dataset> | fields name

NOTE:

If you specify more than one field, only the first field value is used.

7. (Optional) Specify a Default Value for the selected parameters.

This value overwrites any predefined default values in the XQL query.

8. Save Filters & Inputs. The fixed filter is added to the dashboard header.

Configuring Drilldowns

Abstract

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 829/1003
5/8/24, 9:18 AM PDF Export

Learn how to create dashboard drilldowns based on individual XQL widgets.

The following procedure explains how to create dashboard drilldowns based on individual XQL widgets.

1. Open a Custom dashboard and select Edit dashboard.

2. Chose the widget to which you want to apply a drilldown, click on the widget menu, and select Add drilldown.

3. In Action On Click select one of the following options:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 830/1003
5/8/24, 9:18 AM PDF Export

In-Dashboard Drilldown­— This option interactively filters the dashboard data based on parameters defined in the Custom XQL widgets within the
dashboard.

Parameters— Select the parameter by which to filter. You can choose parameters that are defined in the XQL queries of the widgets on the
dashboard.

Value— Type your own value, or, select a variable from which to capture the clicked value and assign to a parameter. For more information,
see Variables in drilldowns.

Link to dashboard— This option opens a target dashboard.

Dashboard— Select the target dashboard.

Parameter (optional)— Select parameters by which to filter the data on the target dashboard. Parameters are available if there are
parameters defined in the widgets on the target dashboards.

Value— Type your own value, or, select a variable from which to capture the clicked value in the source dashboard and map as a parameter
in the target dashboard. For more information, see Variables in drilldowns.

Open XQL Search— This option runs an XQL query for additional investigation based on the clicked value.

XQL Query— Define the query that you want to run on drilldown. Type $ to see autocomplete options for variables that are available in the
widget drilldown. For more information, see Variables in drilldowns.

In the following example two parameters are passed from a table widget to an XQL query. The first parameter with the cell value that the user
clicked on, and a second parameter with the cell value in the request_url column in the row that the user clicked.

dataset=xdr_data
|filter event_type=$y_axis.value and requestUri=$row.request_url
|fields action_download, action_remote_ip as remote_ip,
actor_process_image_name as process_name
|comp count_distinct(action_download) as total_download by process_name,
remote_ip, remote_hostname
|sort desc total_download
|limit 10
|view graph type=single subtype=standard xaxis=remote_ip yaxis=total_download

Open custom URL— This option opens an external URL based on a clicked value.

URL Address— Type the URL. To create a dynamic drilldown, you can include Available parameters. For more information about the
parameters, see Variables in drilldowns.

In the following URL, the $x_axis.value parameter represents cortex products names. On drilldown, the $x_axis.value is replaced with the
clicked product name in the pie chart.

https://www.paloaltonetworks.com/cortex/cortex-$x_axis.value

Generate Report— This option runs a report from a clicked value.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 831/1003
5/8/24, 9:18 AM PDF Export

Variables in drilldowns

The following list describes the widget variables that are available in drilldowns, according to widget type.

The variable defines the value to capture in the drilldown, according to the element that is clicked. The captured value is then configured as a parameter by
which to filter data on drilldown.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 832/1003
5/8/24, 9:18 AM PDF Export

Chart (Area, Bubble, Column, Funnel, Line, Map, Pie, Scatter, or Word Cloud)

Read more...

$x_axis.name— selects the x-axis name.

$x_axis.value— selects the x-axis value for the clicked value.

$y_axis.name— selects the y-axis name.

$y_axis.value— selects the y-axis value for the clicked value.

Single value or gauge

Read more...

$y_axis.name— selects the y-axis name that the single value represents.

$y_axis.value— selects the y-axis value for the clicked value.

Table

Read more...

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 833/1003
5/8/24, 9:18 AM PDF Export

$first.name— selects the leftmost column name in the table.

$first.value— selects the leftmost value in the clicked table row.

$clicked.name— selects the column name of the clicked value.

$clicked.value— selects the value in the clicked table cell.

$row.<field_name>— selects the field (column) from the clicked table row.

14.1.5 | Reports

Abstract

Create, edit, and customize reports in Cortex XSIAM. Schedule reports with Cron expressions.

Reports contain statistical data in the form of widgets, which enable you to analyze data from inside or outside Cortex XSIAM, in different formats such as
graphs, pie charts, or text from information. After generating a report, it also appears in the Reports tab, so you can use the report again.

14.1.5.1 | Report Templates

Abstract

View, import, create, and modify report templates

On the Report Templates page, you can view, delete, import, create, and modify report templates. You can also select and generate multiple reports.

14.1.5.2 | Run or Schedule Reports

Abstract

You can run ad-hoc reports or create reports that are to be distributed as scheduled.

There are two ways to create a report template:

Run a Report Based on a Dashboard

You can generate a report based on an existing dashboard.

1. Select Dashboards & Reports → Customize → Dashboards Manager.

2. Right-click the dashboard from which you want to generate a report, and select Save as report template.

3. Enter a unique Report Name and an optional Description of the report, then Save the template.

4. Select Reporting → Report Templates.

5. Update FILTERS & INPUTS.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 834/1003
5/8/24, 9:18 AM PDF Export

If the report includes Custom Cortex Query Language (XQL) widgets with predefined parameter filters, each parameter requires a Default Value. For more
information about configuring FILTERS & INPUTS, see Create a Report from Scratch.

6. Run the report.

You can either Generate Report to run the report on-demand, or you can Edit the report template to define a schedule.

7. After your report completes, you can download it from the Reporting → Reports page.

Create a Report from Scratch

You can create a new report, using an existing or new template.

1. Select Dashboards & Reports → Customize → Reports Templates → + New Template.

2. Enter a unique Report Name and an optional Description of the report.

3. Select the Data Timeframe for your report.

You can choose Last 24H (day), Last 7D (week), Last 1M (month), or you can choose a custom time frame.

NOTE:

The custom time frame is limited to one month.

4. Choose the Report Type and click Next

You can use an existing template, or you can build a new report from scratch.

5. Customize your report.

To get a feel for how the data will look, Cortex XSIAM provides mock data. To see how the report would look with real data in your environment, you can
use the toggle above the report to use Real Data. Select Preview A4 to view how the report is displayed in an A4 format.

6. Add widgets to the report. From the widget library, drag and drop widgets on to the report.

a. For incident-related widgets, select the star to display only incidents that match an incident starring configuration on your dashboard, if desired. A
purple star indicates that the widget is displaying only starred incidents.

b. To remove a widget, select the menu in the top right corner of the widget, and Remove widget.

7. Configure FILTERS & INPUTS.

If you added Custom XQL widgets with predefined parameter filters, configure the parameters. For more information about adding parameter filters to a
widget, see Manage your Widget Library.

NOTE:

You can specify a maximum of four parameter filters.

a. Select + Add Filters & Inputs.

b. On the FILTERS & INPUTS panel, +Add an input and select one of the following options:

Single Select to specify a single predefined value

Multi Select to specify multiple predefined values

Free text/number to specify a single free text value

c. Update the Parameter Title.

d. Select the Parameter that you want to configure.

These values are extracted from the XQL queries of the widgets on the dashboard.

e. Specify a Default Value for the selected parameters.

This value overwrites any predefined default values in the XQL query.

NOTE:

The values must support the parameter type. For example, for $name specify characters and for $num specify numbers.

f. Save Filters & Inputs.

8. When you have finished customizing your report template, click Next.

9. If you are ready to run the report, select Generate now.

10. To run the report on a regular Schedule, you can specify the time and frequency that Cortex XSIAM will run the report.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 835/1003
5/8/24, 9:18 AM PDF Export

11. (Optional) Enter an Email Distribution list or Slack workspace to send a PDF version of your report.

Select Add password used to access report sent by email and Slack to set password encryption.

NOTE:

Password encryption is only available in PDF format.

12. (Optional) Attach CSV file of your XQL query widget to a report.

From the drop-down menu, search and select one or more of your custom widgets to attach to the report. The XQL query widget is attached to the report
as a CSV file along with the customized PDF. Depending on how you selected to send the report, the CSV file is attached as follows:

Email—Sent as separate attachments for each widget. The total size of the attachment in the email cannot exceed 20MB.

Slack—Sent within a ZIP file that includes the PDF file.

13. Save Template.

14. After your report completes, you can download it from the Reporting → Reports page.

In the Name field, reports with multiple files, PDF and CSV files, are marked with a icon, while reports with a single PDF are marked with a icon.
NOTE:

You can receive an email alert if a report fails to run due to timeout or fails to upload to the GCP bucket.

Configure the notification rule for a failed report.

1. Under Settings → Configurations → General → Notifications , + Add Forwarding Configuration.

2. Select a Name and a Description for your rule, and under Log Type, select Management Audit Logs.

3. Use a filter to select the Type as Reporting, Subtype as Run Report, and Result as Fail.

4. Under Distribution List, select the email address to send the notification to.

5. Click Done.

14.2 | Monitor Cortex XSIAM Incidents

Abstract

Incidents are aggregates of alerts relating to a single event and can be monitored from the Incidents page.

The Incidents page displays all incidents in the Cortex XSIAM management console to help you prioritize, track, triage, investigate and take remedial action.

See Investigate Incidents for more information.

14.3 | Monitor Gateway Management Activity

Abstract

Learn how to monitor Cortex Gateway permission management activities.

The Gateway allows you to manage the user roles and permissions across your Cortex XSIAM CSP accounts. To track your permission management activity, in
the Cortex Gateway Cortex Gateway, navigate to <User Name> and select Management Auditing.

NOTE:

You must have Account Admin role permissions to access the Management Auditing page.

The Management Audit Logs fields describe the following information:

Field Description

Description Log message describing the action taken and on which tenant. To filter according to a
tenant, use the contains operator.

Email Email of the user who performed the action.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 836/1003
5/8/24, 9:18 AM PDF Export

Field Description

Result The result of the action: Success, Fail, or N/A

Severity Severity associated with the log:

Critical

High

Medium

Low

Informational

Subtype Additional classification of permissions log.

Timestamp Date and time when the action occurred are displayed in UTC.

Type Type of action, Permissions or Roles.

User Name Name of the user who performed the action.

14.4 | Monitor Administrative Activity

Abstract

View all Cortex XSIAM administrator-initiated actions taken on alerts, incidents, and live terminal sessions.

From Settings → Management Auditing, you can track the status of all administrative and investigative actions. Cortex XSIAM stores audit logs for 365 days
(instead of 180 days, which was the retention period in the past). Use the page filters to narrow the results or manage tables to add or remove fields as needed.
For more information, see Manage Tables.

To ensure you and your colleagues stay informed about administrative activity, you can Configure Notification Forwarding to forward your Management Audit log
to an email distribution list, Syslog server, or Slack channel.

The following table describes the default and optional fields that you can view in alphabetical order.

Field Description

Email Email address of the administrative user

Description Descriptive summary of the administrative action. Hover over this field to view more
detailed information in a popup tooltip. This enables you to know exactly what has
changed, and, if necessary, roll back the change.

Host Name Name of any relevant affected hosts

ID Unique ID of the action

Result Result of the administrative action: Success, Partial, or Fail.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 837/1003
5/8/24, 9:18 AM PDF Export

Field Description

Subtype Subcategory of action

Timestamp Time and date of the action

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 838/1003
5/8/24, 9:18 AM PDF Export

Field Description

Type Type of activity logged, one of the following:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 839/1003
5/8/24, 9:18 AM PDF Export

Field Description

Agent Configuration—Configuration of a particular Cortex XDR agent on a

particular endpoint.

Agent Installation—Installation of the Cortex XDR agent on a particular endpoint.

Alert Exclusions—Suppression of particular alerts from Cortex XSIAM .

Alert Fields—Modification of alert fields.

Alert Layouts—Modification of alert layouts.

Alert Layout Rules—Modification of alert layout rules.

Alert Notifications—Modification of the format or timing of alerts.

Alert Rules—Modification of alert rules.

API Key—Modification of the Cortex XSIAM API key.

Authentication—User sessions started, along with the user name that started the
session.

Broker API—Operation related to the Broker application programming interface

(API).

Broker VM—Operation related to the Broker virtual machine (VM).

Dashboards—Use of particular dashboards.

Device Control Permanent Exceptions—Modification of permanent device control

exceptions.

Device Control Profile—Modification of a device control profile.

Device Control Temporary Exceptions—Modification of temporary device control

exceptions.

Disk Encryption Profile—Modification of a disk encryption profile.

Endpoint Administration—Management of endpoints.

Endpoint Groups—Management of endpoint groups.

Extensions Policy—Modification of extension policy settings, including host

firewall and disk encryption.

Extensions Profiles—Modification of extension profile settings.

Global Exceptions—Management of global exceptions.

Host Firewall Profile—Modification of a host firewall profile.

Host Insights— Initiation of Host Insights data collection scan (Host Inventory and
Vulnerability Assessment).

Incident Management—Actions taken on incidents and on the assets, alerts, and

artifacts in incidents.

Ingest Data—Import of data for immediate use or storage in a database.

Integrations—Integration operations, such as integrating Slack for outbound

notifications.

Licensing—Any licensing-related operation.

Live Terminal—Remote terminal sessions created and actions taken in the file
manager or task manager, a complete history of commands issued, their
success, and the response.

Managed Threat Hunting—Activity relating to managed threat hunting.

MSSP—Management of security services providers.

Policy & Profiles—Activity related to managing policies and profiles.

Prevention Policy Rules—Modification of prevention policy rules.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 840/1003
5/8/24, 9:18 AM PDF Export

Field Description

Protection Policy—Modification of the protection policy.

Protection Profile—Modification of the protection profile.

Public API—Authentication activity using an associated Cortex XSIAM API key.

Query Center—Operations in the Query Center.

Remediation—Remediation operations.

Reporting—Any reporting activity.

Response—Remedial actions taken. For example: Isolate a host, undo host

isolation, add a file hash signature to the block list, or undo the addition to the
block list.

Rules—Modification of rules.

Rules Exceptions—Creation, editing, or deletion under Rules exceptions.

SaaS Collection—Any collected SaaS data.

Script Execution—Any script execution.

Starred Incidents—Modification of starred incidents.

Vulnerability Assessment—Any vulnerability assessment activity.

User Name The user who performed the action.

14.5 | Monitor Agent Operational Status

Abstract

You can view the operational status of any Cortex XDR agent that you manage.

From the Cortex XSIAM management console, you have full visibility into the XDR agent operational status on the endpoint, which indicates whether the agent
is providing protection according to its predefined security policies and profiles. By observing the operational status on the endpoint, you can identify when the
agent may suffer from a technical issue or misconfiguration that interferes with the agent’s protection capabilities or interaction with Cortex XSIAM and other
applications. The XDR agent reports the operational status as follows:

Protected—Indicates that the XDR agent is running as configured and did not report any exceptions to Cortex XSIAM.

Partially protected—Indicates that the XDR agent reported one or more exceptions to Cortex XSIAM.

Unprotected—Indicates the XDR agent is not enforcing protection on the endpoint.

Local Resource Impact—indicates that the XDR agent machine resources currently available for use, are not enough for the agent to operate smoothly.

You can monitor the Cortex XDR agent Operational Status in Endpoints → All Endpoints. If the Operational Status field is missing, add it.

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

Status Description

Protected (Windows, Mac, and Linux) Indicates all protection modules are running as configured
on the endpoint.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 841/1003
5/8/24, 9:18 AM PDF Export

Status Description

Partially protected Windows

XDR data collection is not running, or not set

Behavioral threat protection is not running

Malware protection is not running

Exploit protection is not running

Mac

Operating system adaptive mode*

XDR Data Collection is not running, or not set

Behavioral threat protection is not running

Malware protection is not running

Exploit protection is not running

Linux

Kernel module not loaded**

Kernel module compatible but not loaded**

Kernel version not compatible**

XDR Data Collection is not running, or not set

Behavioral threat protection is not running

Anti-malware flow is asynchronous

Malware protection is not running

Exploit protection is not running

NOTE:

Any of the listed items could lead to a partially protected state. Refer to the
Cortex XSIAM management console for specific reasons for the state.

Unprotected Windows, Mac, and Linux:

Behavioral threat protection and Malware protection are not running

Exploit protection and malware protection are not running

The content is unavailable.

Local Resource Impact Windows, Mac, Linux

Machine CPU impact on the agent operation

Machine memory impact on the agent operation

In addition to the status, either one of the following sub-statuses appear:

Low local available memory

No local available memory

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 842/1003
5/8/24, 9:18 AM PDF Export

Status Description

CAUTION:

Status can have the following implications on the endpoint:

*(Status)—The exploit protection module is not running.

**(Status)—

XDR data collection is not running

Behavioral threat protection is not running

Anti-malware flow is asynchronous

Local privilege escalation protection is asynchronous

14.6 | Monitor Agent Activity

Abstract

You can monitor the activity of any Cortex XSIAM Broker VM that you manage.

The Cortex XDR agent logs entries for events that are monitored by the Cortex XDR agent, and hourly reports the logs back to Cortex XSIAM. Cortex XSIAM
stores the logs for 365 days. To view the XDR agent logs, select Settings → Agent Auditing.

To ensure you and your colleagues stay informed about agent activity, you can Configure Notification Forwarding to forward your Agent Audit log to an email
distribution list, Syslog server, or Slack channel.

You can customize your view of the logs by adding or removing filters to the Agent Audits Table. You can also filter the page result to narrow down your search.
The following table describes the default and optional fields that you can view in the Cortex XSIAM Agents Audit Table:

Field Description

Category The XDR agent logs these endpoint events using one of the following categories:

Audit—Successful changes to the agent indicating correct behavior.

Monitoring—Unsuccessful changes to the agent that may require administrator intervention.

Status—Indication of the agent status.

Description Log message that describes the action.

Domain Domain to which the endpoint belongs.

Endpoint ID A unique ID assigned by the XDR agent.

Endpoint Name Endpoint hostname.

Received Time Date and time when the action was received by the agent and reported back to Cortex XSIAM.

Result The result of the action ( Success, Fail, or N/A)

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 843/1003
5/8/24, 9:18 AM PDF Export

Field Description

Severity Severity associated with the log:

Critical

High

Medium

Low

Informational

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 844/1003
5/8/24, 9:18 AM PDF Export

Field Description

Type and Sub-Type Additional classification of agent log (Type and Sub-Type:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 845/1003
5/8/24, 9:18 AM PDF Export

Field Description

Installation:

Install

Uninstall

Upgrade

Policy change:

Local Configuration Change

Content Update

Policy Update

Process Exception

Hash Exception

Agent service:

Service start (reported only when the agent fails to start and the RESULT is Fail)

Service stopped

Anti-Tampering—reported when anti-tamper protection is disabled locally on an agent

Agent modules:

Module initialization

Local analysis module

Local analysis feature extraction

Agent status:

Fully protected

OS incompatible

Software incompatible

Kernel driver initialization

Kernel extension initialization

Proxy communication

Quota exceeded (reported when old prevention data is being deleted from the endpoint)

Minimal content

Action:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 846/1003
5/8/24, 9:18 AM PDF Export

Field Description

Endpoint Token

Scan

File retrieval

Terminate process

Isolate

Cancel isolation

Payload execution

Quarantine

Restore

Block IP address

Unblock IP address

Tagging

Timestamp Date and time when the action occurred.

XDR Agent Version The version of the XDR agent running on the endpoint.

14.7 | Monitor Agent Upgrade Status

Abstract

From Endpoints → All Endpoints, you can view the upgrade status of any Cortex XDR agent that you manage.

From the Cortex XSIAM management console, you have full visibility into the XDR agent upgrade status on the endpoint. You can monitor the Cortex XDR agent
statuses in Endpoints → All Endpoints. If the upgrade status fields are missing, add them. XDR agents report upgrade statuses as follows:

Status Description

Last upgrade status Displays the last upgrade status for each endpoint, and can be filtered by:

In Progress—This is the first stage shown when an upgrade is initiated (There is no Pending status).

Completed Successfully

Failed

No Upgrade—No upgrade of any type has been initiated for the endpoint. Newly installed endpoints will also show this status
until an upgrade is initiated by one of the upgrade methods.

Last upgrade status Displays a timestamp for the last time the upgrade status changed for each endpoint. This column can be filtered by date and time.
time

Last upgrade failure When relevant, displays the reason for an upgrade failure. This column can be filtered by free text.
reason

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 847/1003
5/8/24, 9:18 AM PDF Export

Status Description

Last upgrade source Displays the source that initiated the last upgrade, and can be filtered by the following:

Manual Server Upgrade—The upgrade was manually initiated from the server.

Auto Upgrade—The endpoint was automatically upgraded according to the upgrade policy.

Local Manual Upgrade—The upgrade was manually initiated at the endpoint side.

14.8 | Monitor Broker VM Activity

Abstract

Learn more about the monitored Cortex XSIAM Broker VM activities.

Cortex XSIAM logs entries for events related to the Broker VM monitored activities. Cortex XSIAM stores the logs for 365 days. To view the Broker VM audit
logs, select Settings → Management Audit Logs.

To ensure you and your colleagues stay informed about Broker VM activity, you can Configure Notification Forwarding to forward your Broker VM audit logs to
an email distribution list or Syslog server.

You can customize your view of the logs by adding or removing filters to the Management Audit Logs table. You can also filter the page result to narrow down
your search. The following table describes the default and optional fields that you can view in the Cortex XSIAM Management Audit Logs table:

NOTE:

Certain fields are exposed and hidden by default. An asterisk (*) is beside every field that is exposed by default.

Field Description

Description* Log message that describes the action.

Email Email of the user who performed the action.

Host Name* Name of any relevant affected hosts.

ID Unique ID of the action.

Reason This field is not applicable for Broker VM logs.

Result* The result of the action ( Success, Fail, or N/A)

Severity* Severity associated with the log:

Critical

High

Medium

Low

Informational

Timestamp* Date and time when the action occurred.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 848/1003
5/8/24, 9:18 AM PDF Export

Field Description

Type* and Sub-Type* Additional classifications of Broker VM logs (Type and Sub-Type):

Broker VMs:

Action on device

Add Cluster

Applet Activated

Applet Configuration

Applet connection_test Action

Applet Deactivated

Applet License Expired

Applet Mount Share Action

Applet Mount Share Test Action

Applet preview Action

Applet Scan Now Action

Applet Set Configuration

Applet Unmount All Shares Action

Authentication succeeded

Broker Log

Cluster Configuration

Cluster Failover

Cluster health declined

Cluster health recovered

Cluster Switchover

Device configuration

Disconnect

Register

Remove Cluster

Remove Device

Subscription Created

Subscription Deleted

Subscription Edited

Broker API:

Authentication failed

User Name* Name of the user who performed the action.

14.9 | Monitoring Collector Connectivity

Abstract

Learn how to monitor collector connectivity and resolve API connectivity errors.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 849/1003
5/8/24, 9:18 AM PDF Export

Cortex XSIAM provides tools to reduce disruption in data collection by monitoring the connectivity of your collectors , monitoring data ingestion health for all
integrations, and providing visibility into data collection errors. With these tools you can:

Verify that your collectors are connected, receive alerts when connection errors occur, and resolve API connection errors.

Identify and resolve errors in parsing and data model rules, and receive notifications when parsing errors occur.

Ensure that data is being successfully ingested for all data sources and receive alerts when disruptions occur in data collection.

For more information, see the following topics:

Verifying Collector Connectivity

Troubleshooting Parsing Rules Errors

Troubleshooting Data Model Rules

Monitoring Data Ingestion Health

14.9.1 | Verifying Collector Connectivity

Abstract

Verify collector connectivity and troubleshoot collector errors.

You can verify the connectivity status of a collector instance on the Data Sources page. Instances are grouped by integration, and a status icon shows a
summary of instance statuses for each integration. Expand the integration section to see the status of each individual instance, and hover over the status icons
to see details about warning or error statuses.

Troubleshooting collector errors

Where can I see if I have a connectivity error on a collector instance?

On the Data Sources page, instances in error status display an error icon. Hover over the error icon next to the instance name to see the error message as
received from the API.

Where can I trace the connectivity changes of a collector instance?

Each status change of an instance is logged in the collection_auditing dataset. Querying this dataset can help you see all the connectivity changes of an
instance over time, the escalation or recovery of the connectivity status, and the error, warning, and informational messages related to status changes.

This example searches for errors on Strata IOT integrations:

dataset = collection_auditing
|filter classification = "Error" and collector_type = "STRATA_IOT"

How can I set up collection alerts for collector errors?

Cortex XSIAM creates a collection alert each time an instance displays an error status. You can see a log of all collection alerts on the Data Ingestion Health
page. For more information, see Viewing ingestion and collection alerts.

How can I set up notifications for collection alerts?

Cortex XSIAM Data Ingestion Monitoring adds a notification to the Notifications Center when a collection alert occurs.

NOTE:

To receive collection notifications, ensure that Data Ingestion Monitoring is enabled and Display notifications is selected. For more information see
Define Data Ingestion Monitoring.

You can also set up notification forwarding for Data Ingestion Health alerts. For more information, see Configure Notification Forwarding.

14.10 | Monitoring Data Ingestion Health

Abstract

Learn more about Data Ingestion Health monitoring.

Cortex XSIAM collects granular data ingestion metrics that provide an insight into the data ingestion pipeline. With these metrics you can trace data collection
from a specific source, and breakdown by data source attributes such as Collector Name and Final Reporting Device.

You can use these metrics in Cortex Query Language (XQL) queries to investigate disruption and degradation in log collection. You can also create correlation
rules that use your own data ingestion logic to trigger alerts when disruption occurs for a specific data source within a specific timeframe.

In addition, Cortex XSIAM has a built-in data ingestion monitoring and alerts mechanism that monitors the availability and overall health of data collection in your
environment. This mechanism monitors data ingestion per data source along the data ingestion pipeline, identifies disruptions in data collection, and creates

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 850/1003
5/8/24, 9:18 AM PDF Export

ingestion alerts. For more information about defining the settings for this feature, including UI notifications, see Define Data Ingestion Monitoring.

For more information, see the following topics:

Overview of Data Ingestion Metrics

Creating Correlation Rules to Monitor Data Ingestion Health

Viewing ingestion and collection alerts

Measuring Data Freshness

14.10.1 | Overview of Data Ingestion Metrics

Abstract

Learn more about the data ingestion health metrics in the metrics_source dataset and the metrics_view preset.

The data ingestion metrics are calculated in 5-minute aggregation periods and saved to the metrics_source dataset and metrics_view preset. These metrics
measure the amount, size, and rate in which logs are ingested by a data source:

Metric Description

total_size_bytes Total size (in bytes) of the logs collected during the aggregation period.

total_size_rate Average size (in bytes per second) of the logs collected during the aggregation period.

total_event_count Total number of logs collected during the aggregation period

total_event_rate Average number (in count per second) of logs collected during the aggregation period.

In the metrics_source dataset the data ingestion metrics are saved alongside additional fields that describe the data source associated with the metrics. Only
entries with ingestion metric values greater than zero are saved in the dataset. Entries with zero values are not saved in this dataset. metrics_view is a preset
for data in the metrics_source dataset. The preset also simulates completion of entries with zero values in data ingestion metrics at runtime, which allows
effective use of metrics. Therefore, when investigating disruptions in data collection, we recommend using the metrics_view preset in XQL queries and
correlation rules.

The built-in data ingestion monitoring and alerts mechanism uses the data ingestion metrics to identify disruption in the data ingestion pipeline. When Cortex
XSIAM identifies a significant deviation from the normal pattern of log collection, ingestion alerts are triggered. You can see all ingestion alerts on the Data
Ingestion Health page. To troubleshoot or investigate an alert, right click an alert and click Investigate in XQL query to see the metrics that caused the alert to be
triggered. For more information, see Viewing ingestion and collection alerts.

Alternatively, you can create your own custom logic for data ingestion health monitoring by setting up correlation rules that monitor the data ingestion metrics.
For more information, see Creating Correlation Rules to Monitor Data Ingestion Health.

The following table describes all the fields in the metrics_source dataset and metrics_view preset:

Read more...

Field Type Description

total_size_bytes Integer Total size (in bytes) of the logs collected during the aggregation period.

total_size_rate Integer Average size (in bytes per second) of the logs collected during the
aggregation period.

total_event_count Integer Total number of logs collected during the aggregation period.

total_event_rate Integer Average number (in count per second) of logs collected during the
aggregation period.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 851/1003
5/8/24, 9:18 AM PDF Export

Field Type Description

data_freshness_max_delay Float Maximum delay value from all log entries in a record between log creation at
the source and ingestion into Cortex XSIAM (in seconds).

data_freshness_median Float Median delay value from all log entries in a record between log creation at
the source and ingestion into Cortex XSIAM (in seconds).

data_freshness_ninetieth_percentile Float Ninetieth percentile of delay values from all log entries in a record between
log creation at the source and ingestion into Cortex XSIAM (in seconds).

last_seen Datetime Time that the last logs were collected.

_vendor String Vendor of the observing data source.

_product String Product name of the observing data source.

_device_id String (For firewall devices) Device ID

_log_type String (For firewall devices) Log type

_collector_type String (Event Metadata) Type of collector that provided the log.

_collector_name String (Event Metadata) Name of the collector instance.

_collector_id String (Event Metadata) ID of the XDR Collector.

_collector_ip String (Event Metadata) IP address of the XDR Collector.

_reporting_device_name String (Event Metadata) Host name of the device where the log originated.

_reporting_device_ip String (Event Metadata) IP Address of the device where the log originated.

_final_reporting_device_name String (Event Metadata) Hostname of the device that the log was extracted from.

_final_reporting_device_ip String (Event Metadata) IP of the device that the log was extracted from.

_broker_device_name String (Event Metadata) Host name of the Broker VM.

_broker_device_ip String (Event Metadata) IP address of the Broker VM.

_broker_device_id String (Event Metadata) ID of the Broker VM.

_time Datetime Timestamp of the interval.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 852/1003
5/8/24, 9:18 AM PDF Export

14.10.2 | Creating Correlation Rules to Monitor Data Ingestion Health

Abstract

See examples of correlation rules for monitoring data ingestion health.

You can create correlation rules that monitor data collection for a specific source within a specific timeframe. Depending on your requirements, you can set up
correlations that alert you when no logs are collected during a specified timeframe, or when there is a deviation from the regular pattern of log collection.

The following examples can help you to set up your own correlation rules with the data ingestion metrics:

Example 1: No logs collected from a data source for 1 hour

Example 2: No logs received from a Firewall for 20 minutes

Example 1: No logs collected from a data source for 1 hour

In this example, the correlation runs every hour and calculates the number of logs that are collected for each data source over the previous hour. If no logs are
collected for a data source during an aggregation period, a security alert is triggered.

Example XQL:

preset = metrics_view
| comp sum(total_event_count) as total_event_count_sum by _collector_id, _collector_ip,
_collector_name, _collector_type, _final_reporting_device_ip, _final_reporting_device_name,
_broker_device_id, _vendor, _product
| filter total_event_count_sum = 0

Addition fields to specify in the correlation rule:

Field Value

Time Schedule Hourly

Query time frame 1 Hour

Alert Suppression Select Enable alert suppression.

Fields Uncheck total_event_rate_sum, leave other fields checked.

Action Select Generate alert.

Severity High

Category Collection

Alerts Fields Mapping The fields in the metrics_view preset are not mapped to the Alerts Table. To enrich your investigation
capabilities and enable automation on the fields in the correlation, you can create custom alert fields.

Example 2: No logs received from a Firewall for 20 minutes

In this example, the correlation runs every 20 minutes and calculates the number of logs that are received for each firewall in a lookup dataset during the last 20
minutes. If no logs are received from a device during an aggregation period, a security alert is triggered.

Example XQL:

preset = metrics_view
| join conflict_strategy = left type = inner (dataset = ngfw_device_Id_keepalive
| fields _device_id) as devices devices._device_id = _device_id | comp sum(total_event_count)
as total_event_count_sum by _device_id, _product,_vendor
| filter total_event_count_sum = 0

Addition fields to specify in the correlation rule:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 853/1003
5/8/24, 9:18 AM PDF Export

Field Value

Time Schedule Every 20 minutes

Query time frame 20 minutes

Alert Suppression Select Enable alert suppression.

Fields Uncheck total_event_rate_sum, leave other fields checked.

Action Select Generate alert.

Severity High

Category Collection

Alerts Fields Mapping The fields in the metrics_view preset are not mapped to the Alerts Table. To enrich your investigation
capabilities and enable automation on the fields in the correlation, you can create custom alert fields.

14.10.3 | Viewing ingestion and collection alerts

Abstract

Learn more about the Data Ingestion Health page and ingestion and collection alerts.

You can view ingestion and collection alerts on the Data Ingestion Health page. Access the page from Settings → Data Ingestion Health.

The Data Ingestion Health page lists all ingestion and collection alerts in your environment.

Collection alerts

Collection alerts identify API connectivity errors in collection integrations. To investigate all status changes you can query the collection_auditing
dataset.

Ingestion alerts

Ingestion alerts identify disruption in data collection and are based on the data ingestion health metrics. For more information about this option, see
Monitoring Data Ingestion Health.

You can further investigate an ingestion alert by right-clicking on the alert and selecting Investigate in XQL query. The query results display related data
ingestion metric entries that provide context to the alert and the events leading up to it. You can change the timeframe, and any of the other default
values to refine your search.

In the Data Ingestion Health Table, you can customize your view of the alerts by adding or removing filters. You can also filter the page result to narrow down
your search. The following table describes the default and optional fields.

Read more...

Field Description

ID Alert ID.

Timestamp Date and time when the alert occurred.

Type Type of alert.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 854/1003
5/8/24, 9:18 AM PDF Export

Field Description

Duration Amount of time that logs were not received in minutes.

Severity Severity associated with the alert.

Description Description of the alert.

Vendor Vendor of the observing data source.

Product Product name of the observing data source.

Device ID

Collector Type (Event Metadata) Type of the collector.

Collector Name (Event Metadata) Name of the collector instance.

Reporting Device IP (Event Metadata) IP Address of the device where the log originated.

Reporting Device Name (Event Metadata) Host name of the device where the log originated.

Final Reporting Device IP (Event Metadata) IP of the device that the log was extracted from.

Final Reporting Device Name (Event Metadata) Hostname of the device that the log was extracted from.

XDR Collector Name (Event Metadata) Host name of the XDR Collector.

XDR Collector IP (Event Metadata) IP address of the XDR Collector.

XDR Collector ID (Event Metadata) ID of the XDR Collector.

Broker VM Name (Event Metadata) Host name of the Broker VM.

Broker VM ID (Event Metadata) ID of the Broker VM.

Broker VM IP (Event Metadata) IP address of the Broker VM.

14.10.4 | Measuring Data Freshness

Abstract

Learn more about the data freshness metrics collected by Cortex XSIAM.

Cortex XSIAM provides metrics that calculate the freshness of your ingested data and highlight delays in your data collection. The metrics calculate the
freshness delay value by measuring the difference between log creation at the source (_TIME) and ingestion into Cortex XSIAM (_INSERT_TIME).

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 855/1003
5/8/24, 9:18 AM PDF Export

Metrics are collected and calculated per data source during five-minute aggregation periods and allocated into the following buckets. The recorded freshness
delay value is the top value in the range of the bucket:

0 to 30 seconds → 30 seconds

30 to 60 seconds → 60 seconds

60 seconds to 5 minutes → 300 seconds

5 minutes to 1 hour → 3,600 seconds

1 hour to 24 hours→ 86,400 seconds

24 hours to week→ 604,800 seconds

Metric Description

data_freshness_max_delay Maximum freshness delay value among all log entries in an aggregation period.

This reflects the worst case.

data_freshness_median Median freshness delay value among all log entries in an aggregation period.

50% of values are smaller than the median, and 50% of values are higher or equal to the median.

data_freshness_ninetieth_percentile Ninetieth percentile of delay values among all log entries in an aggregation period.

This delay value is 90% higher than other log entry differences. It reflects the worst case, but eliminates the spikes.

The metrics are saved to the metrics_source dataset and also available in the metrics_view preset.

NOTE:

The max_delay metric is taken from the maximum bucket value with a restricted limit; therefore, metrics show whole numbers.

The median and ninetieth_percentile metrics are statistical calculations that give an approximation of the real value; therefore, metrics show decimal
numbers.

Time slots with a zero log count or zero byte count display records with zero values. Subsequently, the data freshness metrics will also have zero
values.

Timezone differences between _TIME and _INSERT_TIME might cause time skews with negative differences. Negative differences are rounded to zero
values.

14.11 | Monitor Data Model Rules Activity

Abstract

Learn more about the monitored Cortex XSIAM Data Model Rules activities.

Cortex XSIAM logs entries for events related to the Data Model Rules monitored activities. Cortex XSIAM stores the logs for 365 days. To view the Data Model
Rules audit logs, select Settings → Management Audit Logs.

To ensure you and your colleagues stay informed about Data Model Rules activity, you can Configure Notification Forwarding to forward your Data Model Rules
audit logs to an email distribution list or Syslog server.

You can customize your view of the logs by adding or removing filters to the Management Audit Logs table. You can also filter the page result to narrow down
your search. The following table describes the default and optional fields that you can view in the Cortex XSIAM Management Audit Logs table:

NOTE:

Certain fields are exposed and hidden by default. An asterisk (*) is beside every field that is exposed by default.

Field Description

Description* Log message that describes the action.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 856/1003
5/8/24, 9:18 AM PDF Export

Field Description

Email Email of the user who performed the action.

Host Name* This field is not applicable for Data Model Rules logs.

ID Unique ID of the action.

Reason This field is not applicable for Data Model Rules logs.

Result* The result of the action ( Success, Fail, or Partial)

Severity* Severity associated with the log:

Critical

High

Medium

Low

Informational

Timestamp* Date and time when the action occurred.

Type* and Sub-Type* Additional classifications of Data Model Rules logs (Type and Sub-Type):

XDM Config:

Saving XDM mappings file—Indicates whenever a Data Model Rule is saved in the editor, the specific
changes made to the Cortex Data Model (XDM) mappings. In addition, indicates whenever the changes
weren't able to be saved.

Disabled—Indicates the Data Model Rule and associated dataset that are now disabled. This invalid
rule is excluded from the query until the changes are made to fix the problem.

Enabled—Indicates the Data Model Rule and associated dataset that have been updated and are now
enabled.

User Name* Name of the user who performed the action.

15 | Log Forwarding
Abstract

Cortex XSIAM log forwarding enables you to easily forward Cortex XSIAM alerts an external syslog receiver, Slack channel, or email.

To help you stay informed and updated, you can easily forward alerts and reports to an external syslog receiver, a Slack channel, or to email accounts.

15.1 | Log Forwarding Data Types

Abstract

In Cortex XSIAM, log forwarding includes different data types, which you can receive through different messaging formats.

To ensure you and your colleagues are informed and updated about events in your deployment, you can configure notification forwarding to Email, Slack, or a
syslog receiver. The following table displays the data types supported by each notification receiver.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 857/1003
5/8/24, 9:18 AM PDF Export

Data Type Email Slack Syslog

Alerts

Agent Audit Log —

Cortex XSIAM per Endpoint

Management Audit Log —

Data Ingestion Health alerts

Reports —

15.2 | Integrate Slack for Outbound Notifications

Abstract

Cortex XSIAM enables you to integrate the Slack messaging application for outbound notifications to be received by Slack recipients.

Integrate the app with your Slack workspace to better manage and highlight your Cortex XSIAM alerts and reports. By creating a Cortex XSIAM Slack channel,
you ensure that defined Cortex XSIAM alerts are exposed on laptop and mobile devices using the Slack interface. Unlike email notifications, Slack channels are
dedicated to spaces that you can use to contact specific members regarding your Cortex XSIAM alerts.

To configure a Slack notification, you must first install and configure the Cortex XSIAM app on Slack.

1. From Cortex XSIAM , select Settings → Configurations → Integrations → External Applications.

2. Select the provided link to install Cortex XSIAM on your Slack workspace.

NOTE:

You are directed to the Slack browser to install the Cortex XSIAM app. You can only use this link to install Cortex XSIAM on Slack. Attempting to install
from Slack marketplace will redirect you to Cortex XSIAM documentation.

3. Click Submit.

Upon successful installation, Cortex XSIAM displays the workspace to which you connected.

4. Configure Notification Forwarding.

After you integrate with your Slack workspace, you can configure your forwarding settings.

15.3 | Integrate a Syslog Receiver

Abstract

If you want to send Cortex XSIAM notifications to a Syslog receiver, you can set up log forwarding to the receiver.

To send Cortex XSIAM notifications to your Syslog server, you need to first define the settings for the Syslog server. Once this is completed, you can then
configure notification forwarding.

1. Before you define the Syslog settings, enable access to the following Cortex XSIAM IP addresses for your deployment region in your firewall
configurations:

Region Log Forwarding IP Addresses

United States - Americas (US) 35.232.87.9

35.224.66.220

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 858/1003
5/8/24, 9:18 AM PDF Export

Region Log Forwarding IP Addresses

Germany (DE) 35.234.95.96

35.246.192.146

Netherlands - Europe (EU) 34.90.202.186

34.90.105.250

Canada (CA) 35.203.54.204

35.203.52.255

United Kingdom (UK) 34.105.227.105

34.105.149.197

Singapore (SG) 35.240.192.37

34.87.125.227

Japan (JP) 34.84.88.183

35.243.76.189

Australia (AU) 35.189.38.167

34.87.219.39

United States - Government 104.198.222.185

35.239.59.210

India (IN) 34.93.247.41

34.93.183.131

Switzerland (CH) 34.65.228.95

34.65.74.83

Warsaw (PL) 34.118.45.145

34.118.126.170

Taiwan (TW) 35.234.2.208

35.185.171.91

Qatar (QT) 34.18.48.182

34.18.43.40

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 859/1003
5/8/24, 9:18 AM PDF Export

Region Log Forwarding IP Addresses

France (FA) 34.163.100.253

34.155.72.149

Israel (IL) 34.165.194.4

34.165.101.105

Saudi Arabia (SA) 34.166.50.215

34.166.55.72

Indonesia (ID) 34.101.248.99

34.101.176.232

2. Select Settings → Configurations → Integrations → External Applications.

3. In Syslog Servers, add a + New Server.

4. Define the Syslog server parameters:

Unique name for the server profile.

Destination—IP address or fully qualified domain name (FQDN) of the Syslog server.

Port—The port number on which to send Syslog messages.

Choose one of the syslog standard values. The value maps to how your syslog server uses the facility field to manage messages. For details on the
facility field, see RFC 5424.

Protocol—Select a method of communication with the Syslog server:

TCP—No validation is made on the connection with the Syslog server. However, if an error occurred with the domain used to make the
connection, the Test connection will fail.

UDP—No error checking, error correction, or acknowledgment. No validation is done for the connection or when sending data.

TCP + SSL— Cortex XSIAM validates the syslog server certificate and uses the certificate signature and public key to encrypt the data sent
over the connection.

Certificate—The communication between Cortex XSIAM and the Syslog destination can use TLS. In this case, upon connection, Cortex XSIAM
validates that the Syslog receiver has a certificate signed by either a trusted root CA or a self-signed certificate. You may need to merge the Root
and Intermediate certificate if you receive a certificate error when using a public certificate.

NOTE:

Up to TLS 1.3 is supported.

If your Syslog receiver uses a self-signed CA, Browse and upload your self-signed Syslog receiver CA.

NOTE:

Make sure the self-signed CA includes your public key.

If you only use a trusted root CA leave the Certificate field empty.

Ignore Certificate Error— Cortex XSIAM does not recommend, but you can choose to select this option to ignore certificate errors if they occur. This
will forward alerts and logs even if the certificate contains errors.

5. Test the parameters to ensure a valid connection and Create when ready.

You can define up to five Syslog servers. Upon success, the table displays the Syslog servers and their status.

6. (Optional) Manage your Syslog server connection.

In the Syslog Servers table

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 860/1003
5/8/24, 9:18 AM PDF Export

Locate your Syslog server and right-click to Send text message to test the connection.

Cortex XSIAM sends a message to the defined Syslog server which you can check to see if the test message indeed arrived.

If the message doesn’t arrive, Cortex XSIAM displays an error. View the error details and suggested solutions in Syslog Server Test Message
Errors.

Locate the Status field.

The Status field displays a Valid or Invalid TCP connection. Cortex XSIAM tests connection with the Syslog server every 10min. If no connection is
found after 1 hour, Cortex XSIAM send a notice to the notification center.

NOTE:

If you find the Syslog data limited, Cortex XSIAM recommends running the Get Alert API for complete alert data.

7. Configure Notification Forwarding.

After you integrate with your Syslog receiver, you can configure your forwarding settings.

15.3.1 | Syslog Server Test Message Errors

Abstract

Learn more about Syslog Server test message errors.

When configuring a syslog message, Cortex XSIAM sends a test message. If a test message cannot be sent, Cortex XSIAM displays an error message to help
you troubleshoot. Below are the descriptions and suggested solutions for the error messages.

Error Message Description

Host Resolving The IP address Ensure you have the correct IP address or the hostname.
Failed or hostname you
provided doesn't
exist, or can't be
resolved.

Configured The IP address Ensure you have the correct IP address or the hostname.
Local Address or hostname you
provided is
internal and can't
be used.

Wrong The certificate Re-create the certificate in the correct format, for example:
Certificate you uploaded is
-----BEGIN CERTIFICATE-----
Format in an unexpected MIIDHTCCAgWgAwIBAgIQSwieRyGdh6BNRQyp406bnTANBgkqhkiG9w0BAQsFADAhMR8wHQYDVQQDExZTVVJTLUNoYXJsaWVBbHBoYS1Sb290MB4XDTIwMDQzMDE4MjEzNFoXDTMwMDQzMDE4
format and can't ----END CERTIFICATE-----

be used. The
certificate must
be an ASCII
string or a bytes-
like object.

Connection Cortex XSIAM Check the firewall logs and the connection using WireShark.
Timed Out didn’t connect to
the syslog server
in the expected
time. This could
be because your
firewall blocked
the connection or
because the
configuration of
the syslog server
caused it to drop
the connection.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 861/1003
5/8/24, 9:18 AM PDF Export

Error Message Description

Connection The syslog Check the firewall logs and the connection using WireShark.
Refused server refused
the connection.
This could be
because your
firewall blocked
the connection or
because the
configuration of
the syslog server
caused it to drop
the connection.

Connection The connection Check the firewall logs and the connection using WireShark.
Reset was reset by the
syslog server.
This could be
because your
firewall blocked
the connection or
because the
configuration of
the syslog server
caused it to drop
the connection.

Certificate The uploaded Incorrect certificate—to check that the certificate you are uploading corresponds to the server syslog certificate, use the follo
Verification certificate
openssl verify -verbose -CAfile cortex_upload_certificate syslog_certificate
Failed couldn’t be
verified for one of If the certificate is correct, the result is syslog_certificate: OK.
the following
reasons. Incorrect hostname—make sure that the hostname/ip in the certificate matches the syslog server.

The Certificate chain—If you are using a list of certificates, merge the chain into one certificate. You can concatenate the certifica
certificate cat intermediate_cert root_cert > merged_syslog.crt
doesn't
correspond If the concatenated certificate doesn’t work, change the order of the root and intermediate certificates, and try again.
to the
To verify that the chain certificate was saved correctly, use the following openssl command.
certificate
on the openssl verify -verbose -CAfile cortex_upload_certificate syslog_certificate

syslog
If the certificate is correct, the result is syslog_certificate: OK.
server and
can't be
validated.

The
certificate
doesn’t
have the
correct
hostname.

You are
using a
certificate
chain and
didn’t
merge the
certificates
into one
certificate.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 862/1003
5/8/24, 9:18 AM PDF Export

Error Message Description

Connection The firewall or Check the firewall logs and the connection using WireShark.
Terminated the syslog server
Abruptly dropped the
connection
unexpectedly.
This could be
because the
firewall on the
customer side
limits the number
of connections,
the configuration
on the syslog
server drops the
connection, or
the network is
unstable.

Host The network Check the network configuration to make sure that everything is configured correctly like a firewall or a load balancer which may b
Unreachable configuration is
faulty and the
connection can't
reach the syslog
server.

SSL Error Unknown SSL To investigate the issue, contact support.

error.

Connection General error. To investigate the issue, contact support.

Unavailable

15.4 | Configure Notification Forwarding

Abstract

With Cortex XSIAM you can choose to receive notifications to keep up with the alerts and events that matter to your teams.

With Cortex XSIAM you can choose to receive notifications to keep up with the alerts and events that matter to your teams. To forward notifications, you create a
forwarding configuration that specifies the log type you want to forward. You can also add filters to your configuration to send notifications that match specific
criteria.

NOTE:

Cortex XSIAM applies the filter only to future alertsand events.

Use this workflow to configure notifications for alerts, agent audit logs, and management audit logs. To receive notifications about reports, see Create a Report
from Scratch.

1. Select Settings → Configurations → General → Notifications.

2. + Add Forwarding Configuration.

3. Define the configuration Name and Description.

4. Select the Log Type you want to forward:

Alerts—Send notifications for specific alert types (for example, XDR Agent or BIOC).

Agent Audit Logs—Send notifications for audit logs reported by your Cortex XSIAM agents.

Management Audit Logs—Send notifications for audit logs about events related to your Cortex XSIAM management console.

Data Ingestion Health—Send notifications for data ingestion health alerts.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 863/1003
5/8/24, 9:18 AM PDF Export

5. In the Configuration Scope, Filter the type of information you want included in a notification.

For example, set a filter Severity = Medium, Alert Source = XDR Agent. Cortex XSIAM sends the alerts or events matching this filter as a
notification.

6. (Optional) Define your Email Configuration.

a. In Email Distribution, add the email addresses to which you want to send email notifications.

b. Define the Email Grouping Time Frame, in minutes, to specify how often Cortex XSIAM sends notifications. Every 30 alerts or 30 events aggregated
within this time frame are sent together in one notification, sorted according to the severity. To send a notification when one alert or event is
generated, set the time frame to 0.

c. Choose whether you want Cortex XSIAM to provide an auto-generated subject.

d. If you previously used the Log Forwarding app and want to continue forwarding logs in the same format, you can Use Legacy Log Format. See Log
Format for IOC and BIOC Alerts.

7. Configure additional forwarding options.

Depending on the notification integrations supported by the Log Type, configure the desired Slack channel or Syslog receiver notification settings.

NOTE:

Before you can select a Slack channel or Syslog receiver you must Integrate Slack for Outbound Notifications and Integrate a Syslog Receiver.

a. Enter the Slack channel name and select from the list of available channels.

Slack channels are managed independently of Cortex XSIAM in your Slack workspace. After integrating your Slack account with your Cortex XSIAM
tenant, Cortex XSIAM displays a list of specific Slack channels associated with the integrated Slack workspace.

b. Select a Syslog receiver.

Cortex XSIAM displays the list of receivers integrated with your Cortex XSIAM tenant.

8. Select Done to create the forwarding configuration.

9. (Optional) To later modify a saved forwarding configuration, right-click the configuration, and Edit, Disable, or Delete it.

15.5 | Log Notification Formats

Abstract

Cortex XSIAM provides you with different formats for its log notifications.

When Cortex XSIAM alerts and audit logs are forwarded to an external data source, notifications are sent in the following formats. If you prefer Cortex XSIAM to
forward logs in legacy format, you can choose the legacy option in your log forwarding configuration.

Management Audit Log Messages

Alert Notification Format

Agent Audit Log Notification Format

Management Audit Log Notification Format

Legacy—Cortex XDR Log Format for IOC and BIOC Alerts

Cortex XDR Analytics Log Formats

Legacy—Cortex XDR (formerly Traps) Log Formats

15.5.1 | Management Audit Log Messages

Abstract

List of the Cortex XSIAM management audit log messages according to log type.

The following table displays the Cortex XSIAM management audit log messages by log type.

Message Details

Type-Action Center

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 864/1003
5/8/24, 9:18 AM PDF Export

Message Details

Action # {action_id} completed successfully. {action-- Sub Type—Action Completed

_description}.
Status—Success

Severity—Low

Action # {action_id} completed with {partial success}. Sub Type—Action Completed

{action--_description}.
Status—Failed

Severity—Low

Action # {action_id} {failed / timeout / expired.} {action-- Sub Type—Action Completed

_description}.
Status—Failed

Severity—Low

Action # completed successfully. Action description: Set Sub Type—Action Completed

Endpoint token with (x) days
Status—Success

Severity—Low

Type—Agent Configuration

Agent global uninstall password updated Sub Type—Global uninstall password

Status—Success

Severity—Informational

Agent auto upgrade configuration updated Sub Type—Agent auto upgrade

Status—Success

Severity—Informational

Agent content bandwidth management{bandwidth_allocation} Sub Type—Content bandwidth management

Status—Success

Severity—Informational

Agent advanced analysis configuration updated Sub Type—Advanced Analysis

Status—Success

Severity—Informational

Type—Agent Installation

Distribution creation timeout for distribution id Sub Type—Create

{distribution_id} packages generation - WLM task timed-out
Status—Fail

Severity—Informational

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 865/1003
5/8/24, 9:18 AM PDF Export

Message Details

Deleted installation package\'{distribution.dist_name}\ Sub Type—Delete

Status—Success

Severity—Informational

Edited installation Sub Type—Edit

package\'{current_distribution.dist_name}\
Status—Success

Severity—Informational

Failed to create {general_desc} Sub Type—Create

Status—Fail

Severity—Informational

Created {general_desc} Sub Type—Create

Status—Success

Severity—Informational

Type—Alert Exclusions

Auto-resolved {cases_info} incidents because all of the Sub Type—Auto-Resolve Incidents

alerts they contain are excluded
Status—Success

Severity—Informational

Reopened incident ID {cases_info} due to manual user action Sub Type—Unresolve Auto-Resolved Incidents

Status—Success

Severity—Informational

Failed to Add exclusion policy {name} Sub Type—Add exclusion policy fail

Status—Fail

Severity—Informational

Add exclusion policy #{res} Sub Type—Add exclusion policy

Status—Success

Severity—Informational

Failed to Edit exclusion policy {edit_id} Sub Type—Edit exclusion policy fail

Status—Fail

Severity—Informational

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 866/1003
5/8/24, 9:18 AM PDF Export

Message Details

Edit exclusion policy #{edit_id} Sub Type—Edit exclusion policy

Status—Success

Severity—Informational

Failed to delete exclusion policy Sub Type—Delete exclusion policy fail

Status—Fail

Severity—Informational

Delete exclusion policy {','.join(map(str, whitelist_ids))} Sub Type—Delete exclusion policy

Status—Success

Severity—Informational

Type—Alert Notifications

Notification ID {rule_id} Created Sub Type—New Configuration

Status—Success

Severity—Informational

Notification ID {rule_id} Edited Sub Type—Edit Configuration

Status—Success

Severity—Informational

Notification ID {rule_id} Enabled Sub Type—Enable Configuration

Status—Success

Severity—Informational

Notification ID {rule_id} Disabled Sub Type—Disable Configuration

Status—Success

Severity—Informational

Notification ID {rule_id} Deleted Sub Type—Delete Configuration

Status—Success

Severity—Informational

Type—Alert Rules

Alert rule ID {rule_id} created Sub Type—New Alert Rule

Status—Success

Severity—Informational

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 867/1003
5/8/24, 9:18 AM PDF Export

Message Details

Alert rule ID {rule_id} edited Sub Type—Edit Alert Rule

Status—Success

Severity—Informational

Alert rule ID {rule_id} deleted Sub Type—Delete Alert Rule

Status—Success

Severity—Informational

Alert rule ID {rule_id} was enabled Sub Type—Enable Alert Rule

Status—Success

Severity—Informational

Alert rule ID {rule_id} was disabled Sub Type—Disable Alert Rule

Status—Success

Severity—Informational

Type—Api Key

Api Key ID {id} was added Sub Type—Add New Key

Status—Success

Severity—Informational

Api Key ID {id} was edited Sub Type—Edit Key

Status—Success

Severity—Informational

Deleted Api Keys: {id} Sub Type—Delete Key

Status—Success

Severity—Informational

Api Key ID {id} was deleted Sub Type—Delete Key

Status—Success

Severity—Informational

Type—Authentication

Sub Type—Login

Status—Success

Severity—Informational

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 868/1003
5/8/24, 9:18 AM PDF Export

Message Details

Sub Type—Logout

Status—Success

Severity—Informational

User {user name} has failed to log in into the tenant, as the Sub Type—Login
user is disabled
Status—Fail

Severity—Informational

Type—Broker API

Broker {broker_id} has failed to authenticate Sub Type—Authentication failed

Status—Fail

Severity—Informational

Type—Broker VMs

Broker VM register request completed Sub Type—Register

Status—Success

Severity—Low

Broker VM register request failed Sub Type—Register

Status—Fail

Severity—Low

{app_pretty} activated on broker VM {device_id} Sub Type—Applet Activated

Status—Success

Severity—Low

{app_pretty} failed to activate on broker VM {device_id} Sub Type—Applet Activated

Status—Fail

Severity—Low

Setting configuration {app_pretty} on broker VM {device_id} Sub Type—Applet Set Configuration

Status—Success

Severity—Low

Failed setting configuration {app_pretty} on broker VM Sub Type—Applet Set Configuration

{device_id}
Status—Fail

Severity—Low

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 869/1003
5/8/24, 9:18 AM PDF Export

Message Details

Getting {app_pretty}'s configurations of broker VM Sub Type—Applet Get Configuration

{device_id}
Status—Success

Severity—Low

Failed getting {app_pretty} configurations for broker VM Sub Type—Applet Get Configuration
{device_id}
Status—Fail

Severity—Low

{app_pretty} deactivated on broker VM {device_id} Sub Type—Applet Deactivated

Status—Success

Severity—Low

{app_pretty} failed to deactivate on broker VM {device_id} Sub Type—Applet Deactivated

Status—Fail

Severity—Low

Broker VM {device_id} retrieve logs request created Sub Type—Broker Log

Status—Success

Severity—Low

Broker VM {device_id} retrieve logs failed request Sub Type—Broker Log

Status—Fail

Severity—Low

Broker VM {device_id} was deleted Sub Type—Remove Device

Status—Success

Severity—Low

Failed to delete Broker VM {device_id} Sub Type—Remove Device

Status—Fail

Severity—Low

Sent action {action_name} to device: {device_id} Sub Type—Action on device

Status—Success

Severity—Low

Failed to send action {action_name} to device: {device_id} Sub Type—Action on device

Status—Fail

Severity—Low

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 870/1003
5/8/24, 9:18 AM PDF Export

Message Details

Failed to start Live Shell with Broker device: {device_id} Sub Type—Action on device

Status—Fail

Severity—Low

Set configuration for device {device_id} Sub Type—Device configuration

Status—Success

Severity—Low

Failed to set configuration for device {device_id} Sub Type—Device configuration

Status—Fail

Severity—Low

Broker VM {device_name} has disconnected from the Cortex Sub Type—Disconnect

XSIAM server.
Status—Fail

Severity—Low

Pathfinder configuration request completed Sub Type—Edit Configuration

Status—Success

Severity—Low

Pathfinder configuration request failed Sub Type—Edit Configuration

Status—Fail

Severity—Low

Pathfinder credentials request completed Sub Type—Edit Credentials

Status—Success

Severity—Low

Pathfinder credentials request failed Sub Type—Edit Credentials

Status—Fail

Severity—Low

Pathfinder Test request completed Sub Type—Test

Status—Success

Severity—Low

Pathfinder Test request failed Sub Type—Test

Status—Fail

Severity—Low

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 871/1003
5/8/24, 9:18 AM PDF Export

Message Details

Type—Dashboards

Enabled Dashboard ID {dashboard_id} Sub Type—Enable Dashboard

Status—Success

Severity—Informational

Disabled Dashboard ID {dashboard_id} Sub Type—Disable Dashboard

Status—Success

Severity—Informational

Deleted Dashboard ID {dashboard_id} Sub Type—Delete Dashboard

Status—Success

Severity—Informational

Created Dashboard ID {dashboard_id} Sub Type—Create New Dashboard

Status—Success

Severity—Informational

Edited Dashboard ID {dashboard_id} Sub Type—Edit Dashboard

Status—Success

Severity—Informational

Type—Device Control Permanent Exceptions

Device control permanent exceptions were edited Sub Type—Edit

Status—Success

Severity—Informational

Failed to edit device control permanent exceptions Sub Type—Edit

Status—Fail

Severity—Informational

Exception was added to device control permanent exceptions Sub Type—Edit

profile
Status—Success

Severity—Informational

Failed to add exception to device control permanent Sub Type—Edit

exceptions profile
Status—Fail

Severity—Informational

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 872/1003
5/8/24, 9:18 AM PDF Export

Message Details

Type—Device Control Profile

{platform} {profile_type} profile {profile_name} was created Sub Type—Create

Status—Success

Severity—Informational

Failed to create a profile Sub Type—Create

Status—Fail

Severity—Informational

{platform} {profile_type} profile {profile_name} was deleted Sub Type—Delete

Status—Success

Severity—Informational

Failed to delete a profile Sub Type—Delete

Status—Fail

Severity—Informational

{platform} {profile_type} profile {profile_name} was edited Sub Type—Edit

Status—Success

Severity—Informational

Failed to edit a profile Sub Type—Edit

Status—Fail

Severity—Informational

A whitelist entry {vendor} {product} {serial} was added from Sub Type—Edit
a violation event to profile {profile_name}
Status—Success

Severity—Informational

Failed to add exception to device control exceptions profile Sub Type—Edit

Status—Fail

Severity—Informational

Type—Device Control Temporary Exceptions

A temporary exception for {vendor} {product} {serial} on Sub Type—Create

{target} {target_name} with {permission} permissions for
Status—Success
{time} {time_units} was created
Severity—Informational

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 873/1003
5/8/24, 9:18 AM PDF Export

Message Details

Failed to create a temporary exception from violation Sub Type—Create

Status—Fail

Severity—Informational

Device control temporary exceptions were updated Sub Type—Edit

Status—Success

Severity—Informational

Failed to update device control temporary exceptions Sub Type—Edit

Status—Fail

Severity—Informational

Type—Disk Encryption Profile

{platform} {profile_type} profile {profile_name} was created Sub Type—Create

Status—Success

Severity—Informational

Failed to create a host disk encryption profile Sub Type—Create

Status—Fail

Severity—Informational

{platform} {profile_type} profile {profile_name} was deleted Sub Type—Delete

Status—Success

Severity—Informational

Failed to delete a host disk encryption profile Sub Type—Delete

Status—Fail

Severity—Informational

{platform} {profile_type} profile {profile_name} was edited Sub Type—Edit

Status—Success

Severity—Informational

Failed to edit a host disk encryption profile Sub Type—Edit

Status—Fail

Severity—Informational

Type—EDL Management

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 874/1003
5/8/24, 9:18 AM PDF Export

Message Details

Enable EDL Sub Type—Enable

Status—Success

Severity—Informational

Disable EDL Sub Type—Disable

Status—Success

Severity—Informational

Edit username Sub Type—Edit

Status—Success

Severity—Informational

Edit password Sub Type—Edit

Status—Success

Severity—Informational

Edit username and password Sub Type—Edit

Severity—Informational

Status—Success

EDL Authentication Sub Type—Authentication

Status—Fail

Severity—Informational

Type—Endpoint Administration

Uninstall agent on {scope} Sub Type—Create

Status—Success

Severity—Informational

Upgrade {platform} on {scope} to {versions} Sub Type—Create

Status—Success

Severity—Informational

Retrieve endpoint data from {scope} Sub Type—Create

Status—Success

Severity—Informational

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 875/1003
5/8/24, 9:18 AM PDF Export

Message Details

Change managing server on {scope} using the following Sub Type—Create

distribution IDs {distribution_ids}
Status—Success

Severity—Informational

Set agent proxy ({proxy_addresses}) for {host_name} Sub Type—Create

Status—Success

Severity—Informational

Delete {host_name} Sub Type—Delete

Status—Success

Severity—Informational

Cancel {action_name} (id={group_action_id}) for {scope} Sub Type—Cancel

Status—Success

Severity—Informational

Disable agent proxy for {host_name} Sub Type—Disable

Status—Success

Severity—Informational

Could not include {endpoint-id} in auto upgrade Sub Type—Agent auto upgrade

Status—Fail

Severity—Informational

Could not exclude {endpoint-id} from auto upgrade Sub Type—Agent auto upgrade

Status—Fail

Severity—Informational

Could not include {endpoint-id} and {x} other endpoints in Sub Type—Agent auto upgrade
auto upgrade
Status—Fail

Severity—Informational

Could not exclude {endpoint-id} and {x} other endpoints from Sub Type—Agent auto upgrade
auto upgrade
Status—Fail

Severity—Informational

{endpoint-id} was excluded from auto upgrade Sub Type—Agent auto upgrade

Status—Success

Severity—Informational

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 876/1003
5/8/24, 9:18 AM PDF Export

Message Details

{endpoint-id} was included in auto upgrade Sub Type—Agent auto upgrade

Status—Success

Severity—Informational

{endpoint-id} and {x} other endpoints were included in auto Sub Type—Agent auto upgrade
upgrade
Status—Success

Severity—Informational

{endpoint-id} and {x} other endpoints were excluded from auto Sub Type—Agent auto upgrade
upgrade
Status—Success

Severity—Informational

(tag_name) to (endpoint_name) and 5 other endpoints Sub Type—Assign

Status—Success

Severity—Informational

(tag_name) from (endpoint_name) and 5 other endpoints Sub Type—Remove

Status—Success

Severity—Informational

Endpoint token was viewed for hash (hash_id) and agent id Sub Type—View Token
(agent-id)
Status—Success

Severity—Informational

Set endpoint token with (x) days expiration on (agent-id) Sub Type—Set Token

Status—Success

Severity—Low

Type—Endpoint Groups

Endpoint group '{group_name}' created Sub Type—Create Group

Status—Success

Severity—Informational

Endpoint group '{group_name}' failed to create Sub Type—Create Group

Status—Fail

Severity—Informational

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 877/1003
5/8/24, 9:18 AM PDF Export

Message Details

Endpoint group '{group_name}' deleted Sub Type—Delete Group

Status—Success

Severity—Informational

Endpoint group '{group_name}' failed to delete Sub Type—Delete Group

Status—Fail

Severity—Informational

Endpoint group edited {modified_fields} Sub Type—Edit Group

Status—Success

Severity—Informational

Endpoint group '{group_name}' failed to update Sub Type—Edit Group

Status—Fail

Severity—Informational

Type-Event Forwarding

{operation} Endpoint Event Forwarding Sub Type—Change Endpoint Event Forwarding settings

Status—Success

Severity—Informational

{operation} GB Event Forwarding Sub Type—Change GB Event Forwarding settings

Status—Success

Severity—Informational

Generated New Service Account JSON Web Token Sub Type—Event Forwarding Authentication

Status—Success

Severity—Informational

Type—Extensions Policy

Device Control policy rules were updated Sub Type—Edit

Status—Success

Severity—Informational

Failed to update device control policy rules Sub Type—Edit

Status—Fail

Severity—Informational

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 878/1003
5/8/24, 9:18 AM PDF Export

Message Details

Extensions policy rules were updated Sub Type—Edit

Status—Success

Severity—Informational

Failed to update extensions policy rules Sub Type—Edit

Status—Fail

Severity—Informational

Type—Extensions Profile

{platform} {profile_type} profile {profile_name} was created Sub Type—Create

Status—Success

Severity—Informational

Failed to create an extensions profile Sub Type—Create

Status—Fail

Severity—Informational

{platform} {profile_type} profile {profile_name} was deleted Sub Type—Delete

Status—Success

Severity—Informational

Failed to delete an extensions profile Sub Type—Delete

Status—Fail

Severity—Informational

{platform} {profile_type} profile {profile_name} was edited Sub Type—Edit

Status—Success

Severity—Informational

Failed to edit an extensions profile Sub Type—Edit

Status—Fail

Severity—Informational

Type—Featured Alert Fields

Added {count}new featured {field_type} {plural} Sub Type—Add

Status—Success

Severity—Informational

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 879/1003
5/8/24, 9:18 AM PDF Export

Message Details

Failed to add {count}new featured {field_type}{plural} Sub Type—Add

Status—Fail

Severity—Informational

Deleted {count}featured {field_type} {plural} Sub Type—Delete

Status—Success

Severity—Informational

Failed to delete {count}featured {field_type}{plural} Sub Type—Delete

Status—Fail

Severity—Informational

Edited {count}featured {field_type} {plural} Sub Type—Edit

Status—Success

Severity—Informational

Failed to edit {count}featured {field_type}{plural} Sub Type—Edit

Status—Fail

Severity—Informational

Imported new featured {field_type} {plural} Sub Type—Import

Status—Success

Severity—Informational

Failed to import new featured {field_type}{plural} Sub Type—Import

Status—Fail

Severity—Informational

Replaced all featured {field_type} {plural} with a new list Sub Type—Replace
containing {count}values
Status—Success

Severity—Informational

Failed to replace {count}featured {field_type}{plural} Sub Type—Replace

Status—Fail

Severity—Informational

Type—Global Exceptions

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 880/1003
5/8/24, 9:18 AM PDF Export

Message Details

Global exceptions were edited Sub Type—Edit

Status—Success

Severity—Informational

Failed to edit global exceptions Sub Type—Edit

Status—Fail

Severity—Informational

{exception_type} was added to global exceptions profile Sub Type—Edit

Status—Success

Severity—Informational

Failed to add exception to global exceptions profile Sub Type—Edit

Status—Fail

Severity—Informational

Type—Host Firewall Profile

{platform} {profile_type} profile {profile_name} was created Sub Type—Create

Status—Success

Severity—Informational

Failed to create a host firewall profile Sub Type—Create

Status—Fail

Severity—Informational

{platform} {profile_type} profile {profile_name} was deleted Sub Type—Delete

Status—Success

Severity—Informational

Failed to delete a host firewall profile Sub Type—Delete

Status—Fail

Severity—Informational

{platform} {profile_type} profile {profile_name} was edited Sub Type—Edit

Status—Success

Severity—Informational

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 881/1003
5/8/24, 9:18 AM PDF Export

Message Details

Failed to edit a host firewall profile Sub Type—Edit

Status—Fail

Severity—Informational

Type—Host Insights

Endpoint host insights collection initiated successfully Sub Type—Collect Host Insights from an Endpoint

Status—Success

Severity—Informational

Failed initiating host insights collection from an endpoint Sub Type—Collect Host Insights from an Endpoint

Status—Fail

Severity—Informational

Type—Incident Management

Changed incident {incident_id} status to {new_status} Sub Type—Change Incident Status

Status—Success

Severity—Informational

Changed incident {incident_id} severity to {new_severity} Sub Type—Change Incident Severity

Status—Success

Severity—Informational

Changed incident {incident_id} name to {new_name} Sub Type—Edit Incident Name

Status—Success

Severity—Informational

Deleted incident {incident_id} name Sub Type—Deleted Incident Name

Status—Success

Severity—Informational

Incident {incident_id} assigned to {user_name} Sub Type—Assign Incident

Status—Success

Severity—Informational

Incident {incident_id} unassigned Sub Type—Unassigned Incident

Status—Success

Severity—Informational

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 882/1003
5/8/24, 9:18 AM PDF Export

Message Details

Added artifact {artifact_type}: {artifact_value} to incident Sub Type—Add Key Artifact

{incident_id}
Status—Success

Severity—Informational

Added asset {asset_type}:{asset_value} to incident Sub Type—Add Key Asset

{incident_id}
Status—Success

Severity—Informational

Deleted artifact {artifact_type}: {artifact_value} from Sub Type—Delete Key Artifact

incident {incident_id}
Status—Success

Severity—Informational

Deleted asset {asset_type}:{asset_value} from incident Sub Type—Delete Key Asset

{incident_id}
Status—Success

Severity—Informational

Moved {count} alerts from incident {src_incident_id} to Sub Type—Move Alerts

incident {dst_incident_id}
Status—Success

Severity—Informational

Merged {src_incident_ids} with incident {dst_incident_id} Sub Type—Merge Incidents

Status—Success

Severity—Informational

Merged {src_incident_ids} incidents with incident Sub Type—Merge Incidents

{dst_incident_id}
Status—Success

Severity—Informational

Changed assignee of {count} incident{plural} to {user_name} Sub Type—Bulk Change Incident Assignee

Status—Success

Severity—Informational

Changed status of {count} incident{plural} to {status} Sub Type—Bulk Change Incident status

Status—Success

Severity—Informational

Changed severity of {count} incident{plural} to {severity} Sub Type—Bulk Change Incident Severity

Status—Success

Severity—Informational

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 883/1003
5/8/24, 9:18 AM PDF Export

Message Details

Changed scoring of {count} incident{plural} to {manual_score} Sub Type—Change Scoring

Status—Success

Severity—Informational

Changed scoring of {count} incident{plural} to rule-based Sub Type—Change Scoring

scoring
Status—Success

Severity—Informational

Changed scoring of incident #{incident_id} to {manual_score} Sub Type—Change Scoring

Severity—InformationalStatus—Success

Changed scoring of incident #{incident_id} to rule-based Sub Type—Change Scoring

scoring
Status—Success

Severity—Informational

Type—Ingest Data

Requested to ingest {num_of_alerts} CEFs Sub Type—CEF

Status—Success

Severity—Informational

Requested to ingest {num_of_alerts} LEEFs Sub Type—LEEF

Status—Success

Severity—Informational

Requested to ingest {num_of_alerts} parsed alerts Sub Type—Parsed Alerts

Status—Success

Severity—Informational

Type—Integrations

Created syslog integration {syslog_name} (ID={syslog_id} Sub Type—Create Syslog Integrations

Status—Success

Severity—Informational

Edited syslog integration {syslog_name} (ID={syslog_id}) Sub Type—Edit Syslog Integrations

Status—Success

Severity—Informational

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 884/1003
5/8/24, 9:18 AM PDF Export

Message Details

Deleted syslog integration {syslog_name} (ID={syslog_id}) Sub Type—Delete Syslog Integrations

Status—Success

Severity—Informational

Type—Licensing

Host Insights Add-on license has expired Sub Type—Expiration

Status—Success

Severity—Low

{license_name} license has expired Sub Type—Expiration

Status—Success

Severity—Informational

{license_name} license will expire in less than Sub Type—Expiration

{time_remaining_in_days} days
Status—Success

Severity—Informational

Your agents with data collection license pool reached Sub Type—Quota
{usage_percentage}% capacity, {usage} out of {purchased}
Status—Success
agents installed
Severity—Informational

Your agents with data collection license pool reached full Sub Type—Quota
capacity
Status—Success

Severity—Informational

Your installed agents license pool reached Sub Type—Quota

{usage_percentage}% capacity, {usage} out of {purchased}
Status—Success
agents installed
Severity—Informational

Your installed agents license pool reached full capacity Sub Type—Quota

Status—Success

Severity—Informational

Type—Live Terminal

Connection request sent to host: {host} Sub Type—Connect

Status—Success

Severity—Low

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 885/1003
5/8/24, 9:18 AM PDF Export

Message Details

Connection request sent to host: {host} Sub Type—Connect

Status—Fail

Severity—Low

Connection opened Sub Type—Status

Status—Success

Severity—Low

Connection opened Sub Type—Status

Status—Fail

Severity—Low

Connection closed Sub Type—Status

Status—Success

Severity—Low

Failed to {description} Sub Type—Status

Status—Fail

Severity—Low

{error_detail} in {path} Sub Type—Delete File

Status—Fail

Severity—Low

Delete file {path} Sub Type—Delete File

Status—Success

Severity—Low

Delete file {name} in {path} Sub Type—Delete File

Status—Success

Severity—Low

{error_detail} in {path} Sub Type—Move File

Status—Fail

Severity—Low

Move file {path} to {target_path} Sub Type—Move File

Status—Success

Severity—Low

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 886/1003
5/8/24, 9:18 AM PDF Export

Message Details

Move file {name} from {path} to {target_path} Sub Type—Move File

Status—Success

Severity—Low

{error_detail} in {path} Sub Type—Copy File

Status—Fail

Severity—Low

Copy file {path} to {target_path} Sub Type—Copy File

Status—Success

Severity—Low

Copy file {name} from {path} to {target_path} Sub Type—Copy File

Status—Success

Severity—Low

Type—Managed Threat Hunting

Pairing with {name} was removed Sub Type—Pairing

Status—Success

Severity—Informational

Registered to MTH service with email : {email} Sub Type—Register

Status—Success

Severity—Informational

Registered to MTH service with email : {email} Sub Type—Re-register

Status—Success

Severity—Informational

Registered to MTH service with email : {email} Sub Type—Register

Status—Fail

Severity—Informational

Registered to MTH service with email : {email} Sub Type—Re-register

Status—Fail

Severity—Informational

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 887/1003
5/8/24, 9:18 AM PDF Export

Message Details

Registered to MTH service with email : {email} Sub Type—Unregistered

Status—Success

Severity—Informational

Registered to MTH service with email : {email} Sub Type—Unregistered

Status—Fail

Severity—Informational

Type—MSSP

Synced {len(biocs)} BIOC rules and {len(exceptions)} Sub Type—Synchronization

exceptions
Status—Success

Severity—Informational

Synced {len(inclusions)} starred alerts Sub Type—Synchronization

Status—Success

Severity—Informational

Synced {len(whitelists)} exclusion alerts Sub Type—Synchronization

Status—Success

Severity—Informational

Synced {len(profiles)} profiles Sub Type—Synchronization

Status—Success

Severity—Informational

Synced {len(ab_list)} allow/block items Sub Type—Synchronization

Status—Success

Severity—Informational

Failed to fetch data from signed_url Sub Type—Synchronization

Status—Fail

Severity—Informational

Failed to sync {len(biocs)} BIOC rules and {len(exceptions)} Sub Type—Synchronization

exceptions
Status—Fail

Severity—Informational

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 888/1003
5/8/24, 9:18 AM PDF Export

Message Details

Failed to sync {len(inclusions)} starred alerts Sub Type—Synchronization

Status—Fail

Severity—Informational

Failed to sync {len(whitelists)} exclusion alerts Sub Type—Synchronization

Status—Fail

Severity—Informational

Failed to sync {len(ab_list)} allow/block list items Sub Type—Synchronization

Status—Fail

Severity—Informational

Failed to sync {len(profiles)} profiles Sub Type—Synchronization

Status—Fail

Severity—Informational

Type—Permission

{user name} was assigned permissions of role {role name} Sub Type—User Permissions Assigned

Status—Success

Severity—Informational

{user name} permissions were updated from {role name} to Sub Type—User Permissions Edited
{role name}
Status—Success

Severity—Informational

{user name} permissions were removed Sub Type—User Permissions Revoked

Status—Success

Severity—Informational

{user name} access has been disabled due to due to last login Sub Type—User Access Disabled
timeout
Status—Success

Severity—Informational

{user name} access has been manually disabled Sub Type—User Access Disabled

Status—Success

Severity—Informational

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 889/1003
5/8/24, 9:18 AM PDF Export

Message Details

{user name} access has been enabled Sub Type—User Access Enabled

Status—Success

Severity—Informational

{role name} created with the following permissions: {1,2,3,} Sub Type—Role Created

Status—Success

Severity—Informational

{role name} edited, the following permissions {1,2} were Sub Type—Role Edited
added and the following permissions removed {1,2,3}
Status—Success

Severity—Informational

{role name} deleted Sub Type—Role Deleted

Status—Success

Severity—Informational

Type—Policy & Profiles

{platform} {profile_type} profile {profile_name} was created Sub Type—Create

Status—Success

Severity—Informational

Failed to create a profile Sub Type—Create

Status—Fail

Severity—Informational

{platform} {profile_type} profile {profile_name} was created Sub Type—Create

by {parent_tenant}
Status—Success

Severity—Informational

Failed to create a profile by {parent_tenant} by Sub Type—Create

{parent_tenant}
Status—Fail

Severity—Informational

{platform} {profile_type} profile {profile_name} was deleted Sub Type—Delete

Status—Success

Severity—Informational

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 890/1003
5/8/24, 9:18 AM PDF Export

Message Details

Failed to delete a profile Sub Type—Delete

Status—Fail

Severity—Informational

{platform} {profile_type} profile {profile_name} was deleted Sub Type—Delete

by {parent_tenant}
Status—Success

Severity—Informational

Failed to delete a profile by {parent_tenant} Sub Type—Delete

Status—Fail

Severity—Informational

{platform} {profile_type} profile {profile_name} was edited Sub Type—Edit

Status—Success

Severity—Informational

Failed to edit a profile Sub Type—Edit

Status—Fail

Severity—Informational

{exception_type} was added to exceptions profile Sub Type—Edit

{profile_name}
Status—Success

Severity—Informational

Failed to add exception to exceptions profile Sub Type—Edit

Status—Fail

Severity—Informational

{platform} {profile_type} profile {profile_name} was edited Sub Type—Edit

by {parent_tenant}
Status—Success

Severity—Informational

Failed to edit a profile by {parent_tenant} Sub Type—Edit

Status—Fail

Severity—Informational

<X> profiles were exported Sub Type—Import / Export

Policy rule <name> was exported Status—Success

<x> policy rules were exported Severity—Informational

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 891/1003
5/8/24, 9:18 AM PDF Export

Message Details

<X> profiles were imported Sub Type—Import / Export

Policy rule <name> was imported Status—Success

<x> policy rules were imported Severity—Informational

Type—Prevention Policy Rules

Policy rules were updated Sub Type—Edit

Status—Success

Severity—Informational

Failed to update policy rules Sub Type—Edit

Status—Fail

Severity—Informational

Policy rules reverted to previous state due to profile Sub Type—Revert

removal by {parent_tenant}
Status—Success

Severity—Informational

Type—Public API

Source IP: {source_ip}, API key ID: {key_id} Sub Type—Authentication failed

Status—Fail

Severity—Informational

Type—Query Center

Query ID {identifier} was executed Sub Type—Run Query

Status—Success

Severity—Informational

Query ID {identifier} was scheduled Sub Type—Schedule Query

Status—Success

Severity—Informational

Query ID {identifier} was removed from scheduled queries Sub Type—Remove Scheduling

Status—Success

Severity—Informational

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 892/1003
5/8/24, 9:18 AM PDF Export

Message Details

Query ID {identifier} was renamed Sub Type—Rename Query

Status—Success

Severity—Informational

Query ID {identifier} was removed Sub Type—Remove Query

Status—Success

Severity—Informational

Query ID {identifier} was saved Sub Type—Save Query

Status—Success

Severity—Informational

Query ID {identifier} was enabled Sub Type—Enable Query

Status—Success

Severity—Informational

Query ID {identifier} was disabled Sub Type—Disable Query

Status—Success

Severity—Informational

Query ID {identifier} was rescheduled Sub Type—Edit Query

Status—Success

Severity—Informational

Type—Remediation

Created remediation action to {operations} from {scope} Sub Type—Create

Status—Success

Severity—Low

Canceled {action_name} (id={group_action_id}) on {scope} Sub Type—Cancel

Status—Success

Severity—Low

Type—Reporting

Downloaded report '{report_names}' ID {report_ids} Sub Type—Download Report

Status—Success

Severity—Informational

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 893/1003
5/8/24, 9:18 AM PDF Export

Message Details

Deleted report(s) '{report_names}' ID(s) {report_ids} Sub Type—Delete Report

Status—Success

Severity—Informational

Created report template '{template_name}' ID {template_id} Sub Type—Create New Report Template

Status—Success

Severity—Informational

Disabled report template '{template_name}' ID {template_id} Sub Type—Disable Report Template

Status—Success

Severity—Informational

Enabled report template '{template_name}' ID {template_id} Sub Type—Enable Report Template

Status—Success

Severity—Informational

Edited report template '{template_name}' ID {template_id} Sub Type—Edit Report Template

Status—Success

Severity—Informational

Deleted report template(s) '{template_name}' ID(s) Sub Type—Delete Report Template

{template_id}
Status—Success

Severity—Informational

Emailed report '{template_name}' ID {report_id} to {emails} Sub Type—Email Report

Status—Success

Severity—Informational

Failed to upload report {upload_report_name} to bucket Sub Type—Run Report

{bucket_name}
Status—Fail

Severity—Informational

Scheduled report failed to start due to timeout Sub Type—Run Report

Status—Fail

Severity—Informational

Slack report '{template_name}' ID {report_id} to {channels} Sub Type—Slack Report

Status—Success

Severity—Informational

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 894/1003
5/8/24, 9:18 AM PDF Export

Message Details

Type—Response

Retrieve {count} file(s) from {scope} Sub Type—Create

Status—Success

Severity—Low

Retrieve alert data from {scope} Sub Type—Create

Status—Success

Severity—Low

Quarantine {path}, SHA256: {hash} on {scope} Sub Type—Create

Status—Success

Severity—Low

Restore quarantined file with hash {hash} on {scope} Sub Type—Create

Status—Success

Severity—Low

Malware scan on {scope} Sub Type—Create

Status—Success

Severity—Low

Abort malware scan on {scope} Sub Type—Create

Status—Success

Severity—Low

Isolate {scope} from the network Sub Type—Create

Status—Success

Severity—Low

UnIsolate {scope} Sub Type—Create

Status—Success

Severity—Low

Kill process {process_name} on {scope} Sub Type—Create

Status—Success

Severity—Low

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 895/1003
5/8/24, 9:18 AM PDF Export

Message Details

Initiate Live Terminal on {scope} Sub Type—Create

Status—Success

Severity—Low

Delete {count} hash(es) from allow list Sub Type—Delete

Status—Success

Severity—Low

Delete {cout} hash(es) from block list Sub Type—Delete

Severity—LowStatus—Success

Delete isolation comment of {scope} Sub Type—Delete

Status—Success

Severity—Low

Cancel {action_name} (id= {action_id}) for {scope} Sub Type—Cancel

Status—Success

Severity—Low

Enable {count} hash(es) from allow list Sub Type—Enable

Status—Success

Severity—Low

Enable and move {count} hash(es) from allow list to block Sub Type—Enable
list
Status—Success

Severity—Low

Enable {count} hash(es) from block list Sub Type—Enable

Status—Success

Severity—Low

Enable and move {count} hash(es) from block list to allow Sub Type—Enable
list
Status—Success

Severity—Low

{add_on_name} Add-on activated successfully Sub Type—Enable

Status—Success

Severity—Low

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 896/1003
5/8/24, 9:18 AM PDF Export

Message Details

Disable {count} hash(es) from allow list Sub Type—Disable

Status—Success

Severity—Low

Disable {count} hash(es) from block list Sub Type—Disable

Status—Success

Severity—Low

{add_on_name} Add-on disabled successfully Sub Type—Disable

Status—Success

Severity—Low

Move {count} hash(es) to block list Sub Type—Move

Status—Success

Severity—Low

Move {count} hash(es) to allow list Sub Type—Move

Status—Success

Severity—Low

Edit comment of {count} hash in allow list Sub Type—Edit

Status—Success

Severity—Low

Updated incident ID of a hash from allow list: {hash} to: Sub Type—Edit
{incident_id}
Status—Success

Severity—Low

Removed incident ID of a hash from allow list: {hash} Sub Type—Edit

Status—Success

Severity—Low

Edit comment of {count} hash in block list Sub Type—Edit

Status—Success

Severity—Low

Updated incident ID of a hash from block list: {hash} to: Sub Type—Edit
{incident_id}"
Status—Success

Severity—Low

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 897/1003
5/8/24, 9:18 AM PDF Export

Message Details

Removed incident ID of a hash from block list: {hash} Sub Type—Edit

Status—Success

Severity—Low

Edit isolation comment of {scope} to {isolate_comment} Sub Type—Edit

Status—Success

Severity—Low

Disable {capability} on {scope} Sub Type—Disable Capability

Status—Success

Severity—Low

Removed {ip} from the blocked IP address list of {scope} Sub Type—Unblock

Status—Success

Severity—Low

Type—Rules

IOC created - indicator: {indicator} id: {rule_id} severity: Sub Type—Create

{rule_severity} type: {rule_type}
Status—Success

Severity—Informational

BIOC created - name: {rule_name} id: {rule_id} severity: Sub Type—Create

{rule_severity} type: {rule_type}
Status—Success

Severity—Informational

IOC deleted - indicator: {indicator} id: {rule_id} severity: Sub Type—Delete

{rule_severity} type: {rule_type}
Status—Success

Severity—Informational

BIOC deleted - name: {rule_name} id: {rule_id} severity: Sub Type—Delete

{rule_severity} type: {rule_type}
Status—Success

Severity—Informational

IOC changed - indicator: {indicator} id: {rule_id} severity: Sub Type—Change

{rule_severity} type: {rule_type}
Status—Success

Severity—Informational

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 898/1003
5/8/24, 9:18 AM PDF Export

Message Details

Changed {count} IOCs Sub Type—Change

Status—Success

Severity—Informational

BIOC changed - name: {rule_name} id: {rule_id} severity: Sub Type—Change

{rule_severity} type: {rule_type}
Status—Success

Severity—Informational

Changed {count} BIOCs Sub Type—Change

Status—Success

Severity—Informational

IOC disabled - indicator: {indicator} id: {rule_id} severity: Sub Type—Disable

{rule_severity} type: {rule_type}
Status—Success

Severity—Informational

Disabled {count} IOCs Sub Type—Disable

Status—Success

Severity—Informational

IOC Rule #{rule_id} ({rule_name}) has been disabled as it Sub Type—Disable

reached {limit} limit of hits in the past 24 hours.
Status—Success

Severity—Informational

BIOC disabled - name: {rule_name} id: {rule_id} severity: Sub Type—Disable

{rule_severity} type: {rule_type}
Status—Success

Severity—Informational

BIOC rule {rule_id} has been automatically disabled because Sub Type—Disable
it reached {hits} matches in the last {time} - name:
Status—Success
{rule_name} severity: {rule_severity} type: {rule_type}
Severity—Informational

Disabled {count} BIOCs Sub Type—Disable

Status—Success

Severity—Informational

Analytics BIOC rule disabled - name: '{rule_name}' global Sub Type—Disable

rule id: '{global_rule_id}'
Status—Success

Severity—Informational

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 899/1003
5/8/24, 9:18 AM PDF Export

Message Details

Disabled {count} Analytics BIOC rules Sub Type—Disable

Status—Success

Severity—Informational

BIOC Rule #{rule_id} ({rule_name}) has been disabled as it Sub Type—Disable

reached {limit} limit of hits in the past 24 hours.
Status—Success

Severity—Informational

IOC enabled - indicator: {indicator} id: {rule_id} severity: Sub Type—Enable

{rule_severity} type: {rule_type}
Status—Success

Severity—Informational

Enabled {count} IOCs Sub Type—Enable

Status—Success

Severity—Informational

BIOC enabled - name: {rule_name} id: {rule_id} severity: Sub Type—Enable

{rule_severity} type: {rule_type}
Status—Success

Severity—Informational

Enabled {count} BIOCs Sub Type—Enable

Status—Success

Severity—Informational

Analytics BIOC rule enabled - name: '{rule_name}' global rule Sub Type—Enable
id: '{global_rule_id}'
Status—Success

Severity—Informational

Enabled {count} Analytics BIOC rules Sub Type—Enable

Status—Success

Severity—Informational

Imported {count} IOCs Sub Type—Import

Status—Success

Severity—Informational

Imported {count} BIOCs Sub Type—Import

Status—Success

Severity—Informational

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 900/1003
5/8/24, 9:18 AM PDF Export

Message Details

{count} IOCs expired Sub Type—Expire

Status—Success

Severity—Informational

Exported {count} BIOCs Sub Type—Export

Status—Success

Severity—Informational

BIOC content updated - Palo Alto Networks repository provided Sub Type—Content Update
a BIOC update
Status—Success

Severity—Informational

Type—Rules Exceptions

Added new rule exception Sub Type—Add

Status—Success

Severity—Informational

Edited rule exception ID:{exception_id} Sub Type—Edit

Status—Success

Severity—Informational

Deleted {exception_ids_len} rule exceptions Sub Type—Delete

Status—Success

Severity—Informational

Deleted rule exception ID: {exception_id} Sub Type—Delete

Status—Success

Severity—Informational

Exported {exception_id} rule exception Sub Type—Export

Severity—Informationaltatus—Success

Exported {exported_exceptions} rule exceptions Sub Type—Export

Severity—Informationaltatus—Success

Imported {exception_id} rule exception Sub Type—Import

Status—Success

Severity—Informational

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 901/1003
5/8/24, 9:18 AM PDF Export

Message Details

Imported {imported_exceptions} rule exceptions Sub Type—Import

Status—Success

Severity—Informational

Type—SaaS Collection

{vendor} Data Collection for {name} created. Sub Type—Create Configuration

Status—Success

Severity—Informational

{vendor} Data Collection for {name} deleted. Sub Type—Delete Configuration

Status—Success

Severity—Informational

{vendor} Data Collection for {name} edited. Sub Type—Edit Configuration

Status—Success

Severity—Informational

{vendor} Data Collection for {name} disabled. Sub Type—Disable Configuration

Status—Success

Severity—Informational

{vendor} Data Collection for {name} enabled. Sub Type—Enable Configuration

Status—Success

Severity—Informational

{vendor} Data Collection for {name} was disconnected with Sub Type—Configuration Disconnected
error '{disconnected_error}'
Status—Fail

Severity—Informational

Collection authentication failed. Collection key ID {key_id}. Sub Type—Authentication Failed

Source IP: {source_ip}
Status—Fail

Severity—Informational

Okta API call exceeded rate limit due to too many requests. Sub Type—Data Collection
HTTP Status: 429 Too Many Requests. The collection of data
Status—Fail
from {okta_domain} is suspended for several minutes.
Severity—Informational

Type—Server Settings

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 902/1003
5/8/24, 9:18 AM PDF Export

Message Details

Built-in data ingestion monitoring and alerts were activated Sub Type—Data Ingestion Health

Status—Success

Severity—Medium

Built-in data ingestion monitoring and alerts were Sub Type—Data Ingestion Health
deactivated
Status—Success

Severity—Medium

Display notifications enabled Sub Type—Data Ingestion Health

Status—Success

Severity—Medium

Display notifications disabled Sub Type—Data Ingestion Health

Status—Success

Severity—Medium

Type—Scoring Rules

Scoring rules were updated Sub Type—Edit

Status—Success

Severity—Informational

Failed to update scoring rules Sub Type—Edit

Status—Fail

Severity—Informational

Type—Script ExecutionRun {script_name} on {scope} Sub Type—Run script

Status—Success

Severity—Low

Cancel {action_name} (id={group_action_id}) for {scope} Sub Type—Cancel

Status—Success

Severity—Low

Abort {action_name} (id={group_action_id}) for {scope} Sub Type—Abort

Status—Success

Severity—Low

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 903/1003
5/8/24, 9:18 AM PDF Export

Message Details

Add {outcome} script, name: {name}, description: Sub Type—Add Script

{description}, compatible for {platform}, script id:
Status—Success
{script_id}
Severity—Informational

Edit {script_name}, script id - {script_id}: {updated_values} Sub Type—Edit

Status—Success

Severity—Informational

Delete {script_name}, script id: {script_id} Sub Type—Delete

Status—Success

Severity—Informational

Type—Security Settings

Changed user login expiration from Sub Type—Change Session Expiration

{old_user_login_expiration} hours to
Status—Success
{old_user_login_expiration} hours
Severity—Informational

Changed dashboard expiration from Sub Type—Change Session Expiration

{previous_dashboard_expiration} to {new_dashboard_expiration}
Status—Success

Severity—Informational

{action} session’s approved domains {domain_list} Sub Type—Change Session’s Approved Domains

Status—Success

Severity—Informational

NOTE:

Action is Enabled, Disabled, or Changed.

domain_list is in one of the following formats.

for domainX, domainY

from: domainX to: domainY

(empty)

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 904/1003
5/8/24, 9:18 AM PDF Export

Message Details

{action} session’s approved CIDRs {CIDR_list} Sub Type—Change Session’s Approved CIDRs

Status—Success

Severity—Informational

NOTE:

Action is Enabled, Disabled, or Changed.

CIDR_list is in one of the following formats.

for CIDRX, CIDRY

from: CIDRX to: CIDRY

(empty)

{action} user expiration {expiration_change} Sub Type—Change User Expiration Settings

Status—Success

Severity—Informational

NOTE:

Action is Enabled, Disabled or Changed.

expiration_change is in one of the following formats.

for x days

from x days to y days

(empty)

Added domain(s) {domains_list} to the Allowed Domains list Sub Type—Add Allowed Distribution List Domain

Status—Success

Severity—Informational

Deleted domain(s) {domains_list} from the Allowed Domains Sub Type—Delete Allowed Distribution List Domain
list
Status—Success

Severity—Informational

Type—Starred Incidents

Incident {incident_id} was manually starred Sub Type—Manual Star

Status—Success

Severity—Informational

Incident {incident_id} was manually unstarred Sub Type—Manual Un-star

Status—Success

Severity—Informational

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 905/1003
5/8/24, 9:18 AM PDF Export

Message Details

{count} incident{plural} were starred Sub Type—Bulk Star

Status—Success

Severity—Informational

{count} incident{plural} were un-starred Sub Type—"Bulk Un-star

Status—Success

Severity—Informational

Enabled starring policy {edit_id} Sub Type—Enable Policy

Status—Success / Fail

Severity—Informational

Disabled starring policy {edit_id} Sub Type—Disable Policy

Status—Success / Fail

Severity—Informational

Edited starring policy {edit_id} Sub Type—Edit Policy

Status—Success / Fail

Severity—Informational

Deleted starring policy Sub Type—Delete Policy

Status—Success / Fail

Severity—Informational

Created starring policy {res} Sub Type—Create Policy

Status—Success / Fail

Severity—Informational

Type—System

Temporary Devops access granted to user: ({member}) Sub Type—Devops Access

Status—Success

Severity—Informational

15.5.2 | Alert Notification Format

Abstract

Cortex XDR Agent, BIOC, IOC, Analytics, Correlation, and third-party alerts are forwarded to external data resources according to the email, Slack, or syslog
format.

Cortex XDR Agent, BIOC, IOC, Analytics, Correlation and third-party alerts are forwarded to external data resources according to the following formats.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 906/1003
5/8/24, 9:18 AM PDF Export

Email Account

Alert notifications are sent to email accounts according to the settings you configured when you Configure Notification Forwarding. If only one alert exists in the
queue, a single alert email format is sent. If more than one alert was grouped in the time frame, all the alerts in the queue are forwarded together in a grouped
email format. Emails also include an alert code snippet of the fields of the alerts according to the columns in the Alert table.

Single Alert Email Example

Email Subject: Alert: <alert_name>

Email Body:
Alert Name: Suspicious Process Creation
Severity: High
Source: XDR Agent
Category: Malware
Action: Detected
Host: <host name>
Username:<user name>
Excluded: No
Starred: Yes
Alert: <link to Cortex XDR app alert view>
Incident: <link to Cortex XDR app incident view>

Grouped Alert Email Example

Email Subject: Alerts: <first_highest_severity_alert> + x others

Email Body:
Alert Name: Suspicious Process Creation
Severity: High
Source: XDR Agent
Category: MalwareAction: Detected
Host: <host name>
Username:<user name>
Excluded:No
Starred: Yes
Alert: <link to Cortex XDR app alert view>Incident: <link to Cortex XDR app incident view>
Alert Name: Behavioral Threat Protection
Alert ID: 2412
Description: A really cool detection
Severity: Medium
Source: XDR Agent
Category: Exploit
Action: Prevented
Host: <host name>
Starred: Yes
Alert: <link to Cortex XDR app alert view>
Incident: <link to Cortex XDR app incident view>
Notification Name: “My notification policy 2 ”
Notification Description: “Starred alerts with medium severity”

Body Email Example

{
"original_alert_json":{
"uuid":"<UUID Value>",
"recordType":"threat",
"customerId":"<Customer ID>",
"severity":4,
"generatedTime":"2020-11-03T07:46:03.166000Z",
"originalAgentTime":"2020-11-03T07:46:01.372974700Z",
"serverTime":"2020-11-03T07:46:03.312633",
"isEndpoint":1,
"agentId":"<agent ID>",
"endPointHeader":{
"osVersion":"<OS version>",
"agentIp":"<Agent IP Address>",
"deviceName":"<Device Name>",
"agentVersion":"<Agent Version>",
"contentVersion":"152-40565",
"policyTag":"<Policy Tag Value>",
"securityStatus":0,
"protectionStatus":0,
"dataCollectionStatus":1,
"isolationStatus":0,
"agentIpList":[
"<IP Address>"
],
"addresses":[
{
"ip":[
"<IP Address>"
],
"mac":"<Mac ID>"
}
],
"liveTerminalEnabled":true,
"scriptExecutionEnabled":true,
"fileRetrievalEnabled":true,
"agentLocation":0,
"fileSearchEnabled":false,
"deviceDomain":"env21.local",
"userName":"Aragorn",
"userDomain":"env21.local",

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 907/1003
5/8/24, 9:18 AM PDF Export

"userSid":"<User S ID>",
"osType":1,
"is64":1,
"isVdi":0,
"agentId":"<Agent ID>",
"agentTime":"2020-11-03T07:46:03.166000Z",
"tzOffset":120
},
"messageData":{
"eventCategory":"prevention",
"moduleId":"COMPONENT_WILDFIRE",
"moduleStatusId":"CYSTATUS_MALICIOUS_EXE",
"preventionKey":"<Prevention Key>",
"processes":[
{
"pid":111,
"parentId":<Parent ID>,
"exeFileIdx":0,
"userIdx":0,
"commandLine":"\"C:\\<file path>\\test.exe\" ",
"instanceId":"Instance ID",
"terminated":0
}
],
"files":[
{
"rawFullPath":"C:\\<file path>\\test.exe",
"fileName":"test.exe",
"sha256":"<SHA256 Value>",
"fileSize":"12800",
"innerObjectSha256":"<SHA256 Value>"
}
],
"users":[
{
"userName":"<User Name>",
"userDomain":"<Domain Name>",
"domainUser":"<Domain Name>\\<User Name>"
}
],
"urls":[

],
"postDetected":0,
"sockets":[

],
"containers":[

],
"techniqueId":[

],
"tacticId":[

],
"modules":[

],
"javaStackTrace":[

],
"terminate":0,
"block":0,
"eventParameters":[
"C:\\<file path>\\test.exe",
"B30--A56B9F",
"B30--A56B9F",
"1"
],
"sourceProcessIdx":0,
"fileIdx":0,
"verdict":1,
"canUpload":0,
"preventionMode":"reported",
"trapsSeverity":2,
"profile":"Malware",
"description":"WildFire Malware",
"cystatusDescription":"Suspicious executable detected",
"sourceProcess":{
"user":{
"userName":"<User Name>",
"userDomain":"<Domain Name>",
"domainUser":"<Domain Name>"\\"<User Name>"
},
"pid":1111,
"parentId":<Parent ID>,
"exeFileIdx":0,
"userIdx":0,
"commandLine":"\"C:\\<file path>\\test.exe\" ",
"instanceId":"<Instance ID>",
"terminated":0,
"rawFullPath":"C:\\<file path>\\Test.exe",
"fileName":"test.exe",

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 908/1003
5/8/24, 9:18 AM PDF Export

"sha256":"<SHA256 Value>",
"fileSize":"12800",
"innerObjectSha256":"<SHA256 Value>"
},
"policyId":"<Policy ID>"
}
},
"internal_id":<Internal ID>,
"external_id":"<External ID>",
"severity":"SEV_030_MEDIUM",
"matching_status":"MATCHED",
"end_match_attempt_ts":1604389636437,
"alert_source":"TRAPS",
"local_insert_ts":1604570760,
"source_insert_ts":160470366,
"alert_name":"WildFire Malware",
"alert_category":"Malware",
"alert_description":"Suspicious executable detected",
"bioc_indicator":null,
"matching_service_rule_id":null,
"attempt_counter":1,
"bioc_category_enum_key":null,
"alert_action_status":"REPORTED",
"case_id":111,
"is_whitelisted":false,
"starred":false,
"deduplicate_tokens":null,
"filter_rule_id":null,
"mitre_technique_id_and_name":[
""
],
"mitre_tactic_id_and_name":[
""
],
"agent_id":"80d2e314c92f6",
"agent_version":"7.2.1.2718",
"agent_ip_addresses":[
"10.208.213.137"
],
"agent_hostname":"<Agent Hostname>",
"agent_device_domain":"<Device Domain>",
"agent_fqdn":"<FQDN Value>",
"agent_os_type":"AGENT_OS_WINDOWS",
"agent_os_sub_type":"<Operating System Sub-Type> ",
"agent_data_collection_status":true,
"mac":"<Mac ID>",
"agent_is_vdi":null,
"agent_install_type":"STANDARD",
"agent_host_boot_time":[
1604446615
],
"event_sub_type":null,
"module_id":[
"WildFire"
],
"association_strength":null,
"dst_association_strength":null,
"story_id":null,
"is_disintegrated":null,
"event_id":null,
"event_type":[
1
],
"event_timestamp":[
1604389563166
],
"actor_effective_username":[
"<Domain Name>\\<User Name>"
],
"actor_process_instance_id":[
"<Actor>\/<Instance ID>"
],
"actor_process_image_path":[
"C:\\<file path>\\test.exe"
],
"actor_process_image_name":[
"test.exe"
],
"actor_process_command_line":[
"\"C:\\<file path>\\test.exe\" "
],
"actor_process_signature_status":[
"SIGNATURE_UNSIGNED"
],
"actor_process_signature_vendor":null,
"actor_process_image_sha256":[
"SHA256 Value>"
],
"actor_process_image_md5":[
"MD5 Value>"
],
"actor_process_causality_id":[
"<Actor>\/<Causality ID>"
],

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 909/1003
5/8/24, 9:18 AM PDF Export

"actor_causality_id":null,
"actor_process_os_pid":[
1111
],
"actor_thread_thread_id":[
1222
],
"causality_actor_process_image_name":[
"test1.exe"
],
"causality_actor_process_command_line":[
"C:\\<file path>\\test1.EXE"
],
"causality_actor_process_image_path":[
"C:\\<file path>\\test1.exe"
],
"causality_actor_process_signature_vendor":[
"Microsoft Corporation"
],
"causality_actor_process_signature_status":[
"SIGNATURE_SIGNED"
],
"causality_actor_causality_id":[
"AdaxtV\/iNIMAAAc8AAAAAA=="
],
"causality_actor_process_execution_time":[
1604389557724
],
"causality_actor_process_image_md5":null,
"causality_actor_process_image_sha256":[
"SHA256 value>"
],
"action_file_path":null,
"action_file_name":null,
"action_file_md5":null,
"action_file_sha256":null,
"action_file_macro_sha256":null,
"action_registry_data":null,
"action_registry_key_name":null,
"action_registry_value_name":null,
"action_registry_full_key":null,
"action_local_ip":null,
"action_local_port":null,
"action_remote_ip":null,
"action_remote_port":null,
"action_external_hostname":null,
"action_country":[
"UNKNOWN"
],
"action_process_instance_id":null,
"action_process_causality_id":null,
"action_process_image_name":null,
"action_process_image_sha256":null,
"action_process_image_command_line":null,
"action_process_signature_status":[
"SIGNATURE_UNAVAILABLE"
],
"action_process_signature_vendor":null,
"os_actor_effective_username":null,
"os_actor_process_instance_id":null,
"os_actor_process_image_path":null,
"os_actor_process_image_name":null,
"os_actor_process_command_line":null,
"os_actor_process_signature_status":[
"SIGNATURE_UNAVAILABLE"
],
"os_actor_process_signature_vendor":null,
"os_actor_process_image_sha256":null,
"os_actor_process_causality_id":null,
"os_actor_causality_id":null,
"os_actor_process_os_pid":null,
"os_actor_thread_thread_id":[
1396
],
"fw_app_id":null,
"fw_interface_from":null,
"fw_interface_to":null,
"fw_rule":null,
"fw_rule_id":null,
"fw_device_name":null,
"fw_serial_number":null,
"fw_url_domain":null,
"fw_email_subject":null,
"fw_email_sender":null,
"fw_email_recipient":null,
"fw_app_subcategory":null,
"fw_app_category":null,
"fw_app_technology":null,
"fw_vsys":null,
"fw_xff":null,
"fw_misc":null,
"fw_is_phishing":[
"NOT_AVAILABLE"
],

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 910/1003
5/8/24, 9:18 AM PDF Export

"dst_agent_id":null,
"dst_causality_actor_process_execution_time":null,
"dns_query_name":null,
"dst_action_external_hostname":null,
"dst_action_country":null,
"dst_action_external_port":null,
"is_pcap":null,
"contains_featured_host":[
"NO"
],
"contains_featured_user":[
"YES"
],
"contains_featured_ip":[
"YES"
],
"events_length":1,
"is_excluded":false

Slack Channel

You can send alert notifications to a single Slack contact or a Slack channel. Notifications are similar to the email format.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 911/1003
5/8/24, 9:18 AM PDF Export

Syslog Server

Alert notification forwarded to a Syslog server are sent in a CEF format RF 5425.

Section Description

<9>: PRI (considered a prioirty field)1: version number2020-03-22T07:55:07.964311Z:

Syslog Header timestamp of when alert/log was sentcortexxdr: host name

HEADER/Vendor="Palo Alto Networks" (as a constant string)HEADER/Device

CEF Header Product="Cortex XDR" (as a constant string)HEADER/Product Version= Cortex XDR
version (2.0/2.1....)HEADER/Severity=(integer/0 - Unknown, 6 - Low, 8 - Medium, 9 -
High)HEADER/Device Event Class ID=alert sourceHEADER/name =alert name

end=timestamp shost=endpoint_name deviceFacility=facility cat=category

CEF Body externalId=external_id request=request cs1=initiated_by_process cs1Label=Initiated
by (constant string) cs2=initiator_commande cs2Label=Initiator CMD (constant string)
cs3=signature cs3Label=Signature (constant string) cs4=cgo_name cs4Label=CGO name
(constant string) cs5=cgo_command cs5Label=CGO CMD (constant string)
cs6=cgo_signature cs6Label=CGO Signature (constant string) dst=destination_ip
dpt=destination_port src=source_ip spt=source_port fileHash=file_hash
filePath=file_path targetprocesssignature=target_process_signature
tenantname=tenant_name tenantCDLid=tenant_id CSPaccountname=account_name
initiatorSha256=initiator_hash initiatorPath=initiator_path osParentName=parent_name
osParentCmd=parent_command osParentSha256=parent_hash
osParentSignature=parent_signature osParentSigner=parent_signer incident=incident_id
act=action suser=actor_effective_username

Example

<177>1 2020-10-04T10:06:55.192016Z cortexxdr - - - - CEF:0|Palo Alto Networks|Cortex XDR|Cortex XDR 2.4|XDR Analytics|High Connection Rate|6|end=1601792870694 shost=WGHRAMG
deviceFacility=None cat=Discovery externalId=98106342 request=https:\/\/round-lake.dustinice.workers.dev:443\/https\/iga-bh.xdr.eu.paloaltonetworks.com\/alerts\/98106342 cs1=iexplore.exe cs1Label=Initiated by
cs2=\“C:\\\\Program Files (x86)\\\\Internet Explorer\\\\IEXPLORE.EXE\” SCODEF:11844 CREDAT:82946 \/prefetch:2 cs2Label=Initiator CMD cs3=Microsoft CorporationSIGNATURE_SIGNED-
cs3Label=Signature cs4=iexplore.exe cs4Label=CGO name cs5=\“C:\\\\Program Files (x86)\\\\Internet Explorer\\\\IEXPLORE.EXE\” SCODEF:11844 CREDAT:82946 \/prefetch:2 cs5Label=CGO
CMD cs6=Microsoft CorporationSIGNATURE_SIGNED- cs6Label=CGO Signature dst=10.12.4.37 dpt=8000 src=10.10.28.140 spt=58003
fileHash=e582676ec900249b408ab4e37976ae8c443635a7da77755daf6f896a172856a3 filePath=C:\\\\Program Files (x86)\\\\Internet Explorer\\\\iexplore.exe
targetprocesssignature=NoneSIGNATURE_UNAVAILABLE- tenantname=iGA tenantCDLid=1021319191 CSPaccountname=Information & eGovernment Authority
initiatorSha256=e582676ec900249b408ab4e37976ae8c443635a7da77755daf6f896a172856a3 initiatorPath=C:\\\\Program Files (x86)\\\\Internet Explorer\\\\iexplore.exe
cgoSha256=e582676ec900249b408ab4e37976ae8c443635a7da77755daf6f896a172856a3 osParentName=iexplore.exe osParentCmd=\“C:\\\\Program Files (x86)\\\\Internet
Explorer\\\\IEXPLORE.EXE\” SCODEF:11844 CREDAT:82946 \/prefetch:2 osParentSha256=e582676ec900249b408ab4e37976ae8c443635a7da77755daf6f896a172856a3
osParentSignature=SIGNATURE_SIGNED osParentSigner=Microsoft Corporation incident=118719 act=Detected suser=['root']

15.5.3 | Agent Audit Log Notification Format

Abstract

An email account or a syslog server are the notification channels through which the agent audit log is communicated.

Cortex XSIAM forwards the agent audit log to external data resources according to the following formats.

Email Account

Cortex XSIAM can forward agent audit log notifications to email accounts.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 912/1003
5/8/24, 9:18 AM PDF Export

Syslog Server

Agent audit logs forwarded to a Syslog server are sent in a CEF format RFC 5425 according to the following mapping.

Section Description

<9>: PRI (considered a prioirty field)1: version number2020-03-22T07:55:07.964311Z: timestamp of when alert/log was sentcortexxdr:
Syslog Header host name

HEADER/Vendor="Palo Alto Networks" (as a constant string)HEADER/Device Product="Cortex XDR Agent" (as a constant
CEF Header string)HEADER/Device Version= Cortex XDR Agent version (7.0/7.1....)HEADER/Severity=(integer/0 - Unknown, 6 - Low, 8 - Medium, 9 -
High)HEADER/Device Event Class ID="Agent Audit Logs" (as a constant string)HEADER/name = type

dvchost=domain shost=endpoint_name cat=category end=timestamp rt=received_time cs1Label=agentversion (constant string)

CEF Body cs1=agent_version cs2Label=subtype (constant string) cs2=subtype cs3Label=result (constant string) cs3=result cs4Label=reason
(constant string) cs4=reason msg=event_description tenantname=tenant_name tenantCDLid=tenant_id CSPaccountname=csp_id

Example:

<182>1 2020-10-04T10:41:14.608731Z cortexxdr - - - - CEF:0|Palo Alto Networks|Cortex XDR Agent|Cortex XDR Agent 7.2.0.63060|Agent Audit Logs|Agent Service|9|dvchost=WORKGROUP
shost=Test-Agent cat=Monitoring end=1601808073102 rt=1601808074596 cs1Label=agentversion cs1=7.2.0.63060 cs2Label=subtype cs2=Stop cs3Label=result cs3=N\/A cs4Label=reason
cs4=None msg=XDR service cyserver was stopped on Test-Agent tenantname=Test tenantCDLid=123456 CSPaccountname=1234

15.5.4 | Management Audit Log Notification Format

Abstract

You can receive notifications regarding the management audit log.

Cortex XSIAM forwards the management audit log to external data sources according to the following formats.

Email Account

Management audit log notifications are forward to email accounts.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 913/1003
5/8/24, 9:18 AM PDF Export

Syslog Server

Management Audit logs forwarded to a Syslog server are sent in a CEF format RF 5425 according to the following mapping:

Section Description

<9>: PRI (considered a prioirty field)1: version number2020-03-22T07:55:07.964311Z: timestamp of when alert/log
Syslog Header was sentcortexxdr: host name

HEADER/Vendor="Palo Alto Networks" (as a constant string)HEADER/Device Product="Cortex XDR" (as a constant
CEF Header string)HEADER/Device Version= Cortex XDR version (2.0/2.1....)HEADER/HEADER/Severity=(integer/0 - Unknown, 6 -
Low, 8 - Medium, 9 - High)HEADER/Device Event Class ID="Management Audit Logs" (as a constant string)HEADER/name =
type

suser=user end=timestamp externalId=external_id cs1Label=email (constant string) cs1=user_mail cs2Label=subtype

CEF Body (constant string) cs2=subtype cs3Label=result (constant string) cs3=result cs4Label=reason (constant string)
cs4=reason msg=event_description tenantname=tenant_name tenantCDLid=tenant_id CSPaccountname=csp_id

Example

3/18/2012:05:17.567 PM<14>1 2020-03-18T12:05:17.567590Z cortexxdr - - - CEF:0|Palo Alto Networks|Cortex XDR|Cortex XDR x.x |Management Audit Logs|REPORTING|6|suser=test
end=1584533117501 externalId=5820 cs1Label=email [email protected] cs2Label=subtype cs2=Slack Report cs3Label=result cs3=SUCCESS cs4Label=reason cs4=None msg=Slack
report 'scheduled_1584533112442' ID 00 to ['CUXM741BK', 'C01022YU00L', 'CV51Y1E2X', 'CRK3VASN9'] tenantname=test tenantCDLid=11111 CSPaccountname=00000

15.5.5 | Log Format for IOC and BIOC Alerts

Abstract

Cortex XSIAM supports Syslog and email formats for IOC and BIOC alerts.

Cortex XSIAM logs its IOC and BIOC alerts to the Cortex XSIAM tenant. If you configure Cortex XSIAM to forward logs in legacy format, when alert logs are
forwarded from the Cortex XSIAM tenant, each log record has the following format:

Syslog format:

"/edrData/action_country","/edrData/action_download","/edrData/action_external_hostname","/edrData/action_external_port","/edrData/action_file_extension","/edrData/action_file_m
d5","/edrData/action_file_name","/edrData/action_file_path","/edrData/action_file_previous_file_extension","/edrData/action_file_previous_file_name","/edrData/action_file_previo
us_file_path","/edrData/action_file_sha256","/edrData/action_file_size","/edrData/action_file_remote_ip","/edrData/action_file_remote_port","/edrData/action_is_injected_thread",
"/edrData/action_local_ip","/edrData/action_local_port","/edrData/action_module_base_address","/edrData/action_module_image_size","/edrData/action_module_is_remote","/edrData/ac
tion_module_is_replay","/edrData/action_module_path","/edrData/action_module_process_causality_id","/edrData/action_module_process_image_command_line","/edrData/action_module_pr
ocess_image_extension","/edrData/action_module_process_image_md5","/edrData/action_module_process_image_name","/edrData/action_module_process_image_path","/edrData/action_module
_process_image_sha256","/edrData/action_module_process_instance_id","/edrData/action_module_process_is_causality_root","/edrData/action_module_process_os_pid","/edrData/action_m
odule_process_signature_product","/edrData/action_module_process_signature_status","/edrData/action_module_process_signature_vendor","/edrData/action_network_connection_id","/ed
rData/action_network_creation_time","/edrData/action_network_is_ipv6","/edrData/action_process_causality_id","/edrData/action_process_image_command_line","/edrData/action_proces
s_image_extension","/edrData/action_process_image_md5","/edrData/action_process_image_name","/edrData/action_process_image_path","/edrData/action_process_image_sha256","/edrData
/action_process_instance_id","/edrData/action_process_integrity_level","/edrData/action_process_is_causality_root","/edrData/action_process_is_replay","/edrData/action_process_i
s_special","/edrData/action_process_os_pid","/edrData/action_process_signature_product","/edrData/action_process_signature_status","/edrData/action_process_signature_vendor","/e
drData/action_proxy","/edrData/action_registry_data","/edrData/action_registry_file_path","/edrData/action_registry_key_name","/edrData/action_registry_value_name","/edrData/act
ion_registry_value_type","/edrData/action_remote_ip","/edrData/action_remote_port","/edrData/action_remote_process_causality_id","/edrData/action_remote_process_image_command_li
ne","/edrData/action_remote_process_image_extension","/edrData/action_remote_process_image_md5","/edrData/action_remote_process_image_name","/edrData/action_remote_process_image
_path","/edrData/action_remote_process_image_sha256","/edrData/action_remote_process_is_causality_root","/edrData/action_remote_process_os_pid","/edrData/action_remote_process_s
ignature_product","/edrData/action_remote_process_signature_status","/edrData/action_remote_process_signature_vendor","/edrData/action_remote_process_thread_id","/edrData/action
_remote_process_thread_start_address","/edrData/action_thread_thread_id","/edrData/action_total_download","/edrData/action_total_upload","/edrData/action_upload","/edrData/actio
n_user_status","/edrData/action_username","/edrData/actor_causality_id","/edrData/actor_effective_user_sid","/edrData/actor_effective_username","/edrData/actor_is_injected_threa
d","/edrData/actor_primary_user_sid","/edrData/actor_primary_username","/edrData/actor_process_causality_id","/edrData/actor_process_command_line","/edrData/actor_process_execut
ion_time","/edrData/actor_process_image_command_line","/edrData/actor_process_image_extension","/edrData/actor_process_image_md5","/edrData/actor_process_image_name","/edrData/a
ctor_process_image_path","/edrData/actor_process_image_sha256","/edrData/actor_process_instance_id","/edrData/actor_process_integrity_level","/edrData/actor_process_is_special",

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 914/1003
5/8/24, 9:18 AM PDF Export

"/edrData/actor_process_os_pid","/edrData/actor_process_signature_product","/edrData/actor_process_signature_status","/edrData/actor_process_signature_vendor","/edrData/actor_th
read_thread_id","/edrData/agent_content_version","/edrData/agent_host_boot_time","/edrData/agent_hostname","/edrData/agent_id","/edrData/agent_ip_addresses","/edrData/agent_is_v
di","/edrData/agent_os_sub_type","/edrData/agent_os_type","/edrData/agent_session_start_time","/edrData/agent_version","/edrData/causality_actor_causality_id","/edrData/causalit
y_actor_effective_user_sid","/edrData/causality_actor_effective_username","/edrData/causality_actor_primary_user_sid","/edrData/causality_actor_primary_username","/edrData/causa
lity_actor_process_causality_id","/edrData/causality_actor_process_command_line","/edrData/causality_actor_process_execution_time","/edrData/causality_actor_process_image_comman
d_line","/edrData/causality_actor_process_image_extension","/edrData/causality_actor_process_image_md5","/edrData/causality_actor_process_image_name","/edrData/causality_actor_p
rocess_image_path","/edrData/causality_actor_process_image_sha256","/edrData/causality_actor_process_instance_id","/edrData/causality_actor_process_integrity_level","/edrData/ca
usality_actor_process_is_special","/edrData/causality_actor_process_os_pid","/edrData/causality_actor_process_signature_product","/edrData/causality_actor_process_signature_stat
us","/edrData/causality_actor_process_signature_vendor","/edrData/event_id","/edrData/event_is_simulated","/edrData/event_sub_type","/edrData/event_timestamp","/edrData/event_ty
pe","/edrData/event_utc_diff_minutes","/edrData/event_version","/edrData/host_metadata_hostname","/edrData/missing_action_remote_process_instance_id","/facility","/generatedTime
","/recordType","/recsize","/trapsId","/uuid","/xdr_unique_id","/meta_internal_id","/external_id","/is_visible","/is_secdo_event","/severity","/alert_source","/internal_id","/ma
tching_status","/local_insert_ts","/source_insert_ts","/alert_name","/alert_category","/alert_description","/bioc_indicator","/matching_service_rule_id","/external_url","/xdr_su
b_type","/bioc_category_enum_key","/alert_action_status","/agent_data_collection_status","/attempt_counter","/case_id","/global_content_version_id","/global_rule_id","/is_whitel
isted"

When alert logs are forwarded by email, each field is labeled, one line per field.

Email body format example.

edrData/action_country:
edrData/action_download:
edrData/action_external_hostname:
edrData/action_external_port:
edrData/action_file_extension: pdf
edrData/action_file_md5: null
edrData/action_file_name: XORXOR2614081980.pdf
edrData/action_file_path: C:\ProgramData\Cyvera\Ransomware\16067987696371268494\XORXOR2614081980.pdf
edrData/action_file_previous_file_extension: null
edrData/action_file_previous_file_name: null
edrData/action_file_previous_file_path: null
edrData/action_file_sha256: null
edrData/action_file_size: 0
edrData/action_file_remote_ip: null
edrData/action_file_remote_port: null
edrData/action_is_injected_thread:
edrData/action_local_ip:
edrData/action_local_port:
edrData/action_module_base_address:
edrData/action_module_image_size:
edrData/action_module_is_remote:
edrData/action_module_is_replay:
edrData/action_module_path:
edrData/action_module_process_causality_id:
edrData/action_module_process_image_command_line:
edrData/action_module_process_image_extension:
edrData/action_module_process_image_md5:
edrData/action_module_process_image_name:
edrData/action_module_process_image_path:
edrData/action_module_process_image_sha256:
edrData/action_module_process_instance_id:
edrData/action_module_process_is_causality_root:
edrData/action_module_process_os_pid:
edrData/action_module_process_signature_product:
edrData/action_module_process_signature_status:
edrData/action_module_process_signature_vendor:
edrData/action_network_connection_id:
edrData/action_network_creation_time:
edrData/action_network_is_ipv6:
edrData/action_process_causality_id:
edrData/action_process_image_command_line:
edrData/action_process_image_extension:
edrData/action_process_image_md5:
edrData/action_process_image_name:
edrData/action_process_image_path:
edrData/action_process_image_sha256:
edrData/action_process_instance_id:
edrData/action_process_integrity_level:
edrData/action_process_is_causality_root:
edrData/action_process_is_replay:
edrData/action_process_is_special:
edrData/action_process_os_pid:
edrData/action_process_signature_product:
edrData/action_process_signature_status:
edrData/action_process_signature_vendor:
edrData/action_proxy:
edrData/action_registry_data:
edrData/action_registry_file_path:
edrData/action_registry_key_name:
edrData/action_registry_value_name:
edrData/action_registry_value_type:
edrData/action_remote_ip:
edrData/action_remote_port:
edrData/action_remote_process_causality_id:
edrData/action_remote_process_image_command_line:
edrData/action_remote_process_image_extension:
edrData/action_remote_process_image_md5:
edrData/action_remote_process_image_name:
edrData/action_remote_process_image_path:
edrData/action_remote_process_image_sha256:
edrData/action_remote_process_is_causality_root:
edrData/action_remote_process_os_pid:
edrData/action_remote_process_signature_product:
edrData/action_remote_process_signature_status:
edrData/action_remote_process_signature_vendor:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 915/1003
5/8/24, 9:18 AM PDF Export

edrData/action_remote_process_thread_id:
edrData/action_remote_process_thread_start_address:
edrData/action_thread_thread_id:
edrData/action_total_download:
edrData/action_total_upload:
edrData/action_upload:
edrData/action_user_status:
edrData/action_username:
edrData/actor_causality_id: AdUcamNT99kAAAAEAAAAAA==
edrData/actor_effective_user_sid: S-1-5-18
edrData/actor_effective_username: NT AUTHORITY\SYSTEM
edrData/actor_is_injected_thread: false
edrData/actor_primary_user_sid: S-1-5-18
edrData/actor_primary_username: NT AUTHORITY\SYSTEM
edrData/actor_process_causality_id: AdUcamNT99kAAAAEAAAAAA==
edrData/actor_process_command_line:
edrData/actor_process_execution_time: 1559827133585
edrData/actor_process_image_command_line:
edrData/actor_process_image_extension:
edrData/actor_process_image_md5:
edrData/actor_process_image_name: System
edrData/actor_process_image_path: System
edrData/actor_process_image_sha256:
edrData/actor_process_instance_id: AdUcamNT99kAAAAEAAAAAA==
edrData/actor_process_integrity_level: 16384
edrData/actor_process_is_special: 1
edrData/actor_process_os_pid: 4
edrData/actor_process_signature_product: Microsoft Windows
edrData/actor_process_signature_status: 1
edrData/actor_process_signature_vendor: Microsoft Corporation
edrData/actor_thread_thread_id: 64
edrData/agent_content_version: 58-9124
edrData/agent_host_boot_time: 1559827133585
edrData/agent_hostname: padme-7
edrData/agent_id: a832f35013f16a06fc2495843674a3e9
edrData/agent_ip_addresses: ["10.196.172.74"]
edrData/agent_is_vdi: false
edrData/agent_os_sub_type: Windows 7 [6.1 (Build 7601: Service Pack 1)]
edrData/agent_os_type: 1
edrData/agent_session_start_time: 1559827592661
edrData/agent_version: 6.1.0.13895
edrData/causality_actor_causality_id: AdUcamNT99kAAAAEAAAAAA==
edrData/causality_actor_effective_user_sid:
edrData/causality_actor_effective_username:
edrData/causality_actor_primary_user_sid: S-1-5-18
edrData/causality_actor_primary_username: NT AUTHORITY\SYSTEM
edrData/causality_actor_process_causality_id:
edrData/causality_actor_process_command_line:
edrData/causality_actor_process_execution_time: 1559827133585
edrData/causality_actor_process_image_command_line:
edrData/causality_actor_process_image_extension:
edrData/causality_actor_process_image_md5:
edrData/causality_actor_process_image_name: System
edrData/causality_actor_process_image_path: System
edrData/causality_actor_process_image_sha256:
edrData/causality_actor_process_instance_id: AdUcamNT99kAAAAEAAAAAA==
edrData/causality_actor_process_integrity_level: 16384
edrData/causality_actor_process_is_special: 1
edrData/causality_actor_process_os_pid: 4
edrData/causality_actor_process_signature_product: Microsoft Windows
edrData/causality_actor_process_signature_status: 1
edrData/causality_actor_process_signature_vendor: Microsoft Corporation
edrData/event_id: AAABa13u2PQsqXnCAB1qjw==
edrData/event_is_simulated: false
edrData/event_sub_type: 1
edrData/event_timestamp: 1560649063308
edrData/event_type: 3
edrData/event_utc_diff_minutes: 120
edrData/event_version: 20
edrData/host_metadata_hostname:
edrData/missing_action_remote_process_instance_id:
facility:
generatedTime: 2019-06-16T01:37:43
recordType: alert
recsize:
trapsId:
uuid:
xdr_unique_id: ae65c92c6e704023df129c728eab3d3e
meta_internal_id: None
external_id: 318b7f91-ae74-4860-abd1-b463e8cd6deb
is_visible: null
is_secdo_event: null
severity: SEV_010_INFO
alert_source: BIOC
internal_id: None
matching_status: null
local_insert_ts: null
source_insert_ts: 1560649063308
alert_name: BIOC-16
alert_category: CREDENTIAL_ACCESS
alert_description: File action type = all AND name = *.pdf
bioc_indicator: "[{""pretty_name"":""File"",""data_type"":null,""render_type"":""entity"",
""entity_map"":null},{""pretty_name"":""action type"",""data_type"":null,
""render_type"":""attribute"",""entity_map"":null},{""pretty_name"":""="",

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 916/1003
5/8/24, 9:18 AM PDF Export

""data_type"":null,""render_type"":""operator"",""entity_map"":null},
{""pretty_name"":""all"",""data_type"":null,""render_type"":""value"",
""entity_map"":null},{""pretty_name"":""AND"",""data_type"":null,
""render_type"":""connector"",""entity_map"":null},
{""pretty_name"":""name"",""data_type"":""TEXT"",
""render_type"":""attribute"",""entity_map"":""attributes""},
{""pretty_name"":""="",""data_type"":null,""render_type"":""operator"",
""entity_map"":""attributes""},{""pretty_name"":""*.pdf"",
""data_type"":null,""render_type"":""value"",
""entity_map"":""attributes""}]"
matching_service_rule_id: 200
external_url: null
xdr_sub_type: BIOC - Credential Access
bioc_category_enum_key: null
alert_action_status: null
agent_data_collection_status: null
attempt_counter: null
case_id: null
global_content_version_id:
global_rule_id:
is_whitelisted: false

The following table summarizes the field prefixes and additional relevant fields available for BIOC and IOC alert logs.

Field Name Definition

/edrData/action_file* Fields that begin with this prefix describe attributes of a file for which Traps
reported activity.

edrData/action_module* Fields that begin with this prefix describe attributes of a module for which
Traps reported module loading activity.

edrData/action_module_process* Fields that begin with this prefix describe attributes and activity related to
processes reported by Traps that load modules such as DLLs on the
endpoint.

edrData/action_process_image* Fields that begin with this prefix describe attributes of a process image for
which Traps reported activity.

edrData/action_registry* Fields that begin with this prefix describe registry activity and attributes such
as key name, data, and previous value for which Traps reported activity.

edrData/action_network Fields that begin with this prefix describe network attributes for which Traps
reported activity.

edrData/action_remote_process* Fields that begin with this prefix describe attributes of remote processes for
which Traps reported activity.

edrData/actor* Fields that begin with this prefix describe attributes about the acting user that
initiated the activity on the endpoint.

edrData/agent* Fields that begin with this prefix describe attributes about the Traps agent
deployed on the endpoint.

edrData/causality_actor* Fields that begin with this prefix describe attributes about the causality group
owner.

Additional useful fields:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 917/1003
5/8/24, 9:18 AM PDF Export

Field Name Definition

/severity Severity assigned to the alert:

SEV_010_INFO

SEV_020_LOW

SEV_030_MEDIUM

SEV_040_HIGH

SEV_090_UNKNOWN

/alert_source Source of the alert: BIOC or IOC

/local_insert_ts Date and time when Cortex XSIAM – Investigation and Response ingested
the app.

/source_insert_ts Date and time the alert was reported by the alert source.

/alert_name If the alert was generated by Cortex XSIAM – Investigation and Response,
the alert name will be the specific Cortex XSIAM rule that created the alert
(BIOC or IOC rule name). If from an external system, it will carry the name
assigned to it by Cortex XSIAM .

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 918/1003
5/8/24, 9:18 AM PDF Export

Field Name Definition

/alert_category Alert category based on the alert source.

BIOC alert categories:

OTHER

PERSISTENCE

EVASION

TAMPERING

FILE_TYPE_OBFUSCATION

PRIVILEGE_ESCALATION

CREDENTIAL_ACCESS

LATERAL_MOVEMENT

EXECUTION

COLLECTION

EXFILTRATION

INFILTRATION

DROPPER

FILE_PRIVILEGE_MANIPULATION

RECONNAISSANCE

IOC alert categories:

HASH

IP

PATH

DOMAIN_NAME

FILENAME

MIXED

/alert_description Text summary of the event including the alert source, alert name, severity,
and file path. For alerts triggered by BIOC and IOC rules, Cortex XSIAM
displays detailed information about the rule.

/bioc_indicator A JSON representation of the rule characteristics. For example:

[{""pretty_name"":""File"",""data_type"":null,
""render_type"":""entity"",""entity_map"":null},
{""pretty_name"":""action type"",
""data_type"":null,""render_type"":""attribute"",
""entity_map"":null},{""pretty_name"":""="",
""data_type"":null,""render_type"":""operator"",
""entity_map"":null},{""pretty_name"":""all"",
""data_type"":null,""render_type"":""value"",
""entity_map"":null},{""pretty_name"":""AND"",
""data_type"":null,""render_type"":""connector"",
""entity_map"":null},{""pretty_name"":""name"",
""data_type"":""TEXT"",
""render_type"":""attribute"",
""entity_map"":""attributes""},
{""pretty_name"":""="",""data_type"":null,
""render_type"":""operator"",
""entity_map"":""attributes""},
{""pretty_name"":""*.pdf"",""data_type"":null,
""render_type"":""value"",
""entity_map"":""attributes""}]"

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 919/1003
5/8/24, 9:18 AM PDF Export

Field Name Definition

/bioc_category_enum_key Alert category based on the alert source. An example of a BIOC alert category
is Evasion. An example of a Traps alert category is Exploit Modules.

/alert_action_status Action taken by the alert sensor with action status displayed in parenthesis:

Detected

Detected (Download)

Detected (Post Detected)

Detected (Prompt Allow)

Detected (Reported)

Detected (Scanned)

Prevented (Blocked)

Prevented (Prompt Block)

/case_id Unique identifier for the incident.

/global_content_version_id Unique identifier for the content version in which a Palo Alto Networks global
BIOC rule was released.

/global_rule_id Unique identifier for an alert triggered by a Palo Alto Networks global BIOC
rule.

/is_whitelisted Boolean indicating whether the alert is excluded or not.

15.5.6 | Analytics Log Format

Abstract

Learn about the syntax and different variables that are used in the analytics log format.

Cortex XSIAM Analytics logs its alerts to the Cortex XSIAM tenant as analytics alert logs. If you configure Cortex XSIAM to forward logs in legacy format, each
log record has the following format:

Syslog format

sub_type,time_generated,id,version_info/document_version,version_info/magnifier_version,version_info/detection_version,alert/url,alert/category,alert/type,alert/name,alert/descr
iption/html,alert/description/text,alert/severity,alert/state,alert/is_whitelisted,alert/ports,alert/internal_destinations/single_destinations,alert/internal_destinations/ip_ran
ges,alert/external_destinations,alert/app_id,alert/schedule/activity_first_seen_at,alert/schedule/activity_last_seen_at,alert/schedule/first_detected_at,alert/schedule/last_dete
cted_at,user/user_name,user/url,user/display_name,user/org_unit,device/id,device/url,device/mac,device/hostname,device/ip,device/ip_ranges,device/owner,device/org_unit,files

Email body format example.

When analytics alert logs are forwarded by email, each field is labeled, one line per field.

sub_type: Update
time_generated: 1547717480
id: 4
version_info/document_version: 1
version_info/magnifier_version: 1.8
version_info/detection_version: 2019.2.0rc1
alert/url: https:\/\/round-lake.dustinice.workers.dev:443\/https\/ddc1...
alert/category: Recon
alert/type: Port Scan
alert/name: Port Scan
alert/description/html: \t<ul>\n\t\t<li>The device....
alert/description/text: The device ...
alert/severity: Low
alert/state: Reopened
alert/is_whitelisted: false
alert/ports: "[1,2,3,4,5,6,7,8,9,10,11...]

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 920/1003
5/8/24, 9:18 AM PDF Export

alert/internal_destinations/single_destinations: []
alert/internal_destinations/ip_ranges: "[{""max_ip"":""..."",""name"":""..."",""min_ip"":""...""}]"
alert/external_destinations: []
alert/app_id:
alert/schedule/activity_first_seen_at: 1542178800
alert/schedule/activity_last_seen_at: 1542182400
alert/schedule/first_detected_at: 1542182400
alert/schedule/last_detected_at: 1542182400
user/user_name:
user/url:
user/display_name:
user/org_unit:
device/id: 2-85e40edd-b2d1-1f25-2c1e-a3dd576c8a7e
device/url: https:\/\/round-lake.dustinice.workers.dev:443\/https\/ddc1 ...
device/mac: 00-50-56-a5-db-b2
device/hostname: DC1ENV3APC42
device/ip: 10.201.102.17
device/ip_ranges: "[{""max_ip"":""..."",""name"":""..."",""min_ip"":""..."",""asset"":""""}]"
device/owner:
device/org_unit:
files: []

The following table describes each field.

Field Name Definition

sub_type Alert log subtype. Values are:

New—First log record for the alert with this record id.

Update—Log record identifies an update to a previously logged alert.

StateOnlyUpdate—Alert state is updated. For internal use only.

time_generated Time the log record was sent to the Cortex XSIAM tenant. Value is a Unix
Epoch timestamp.

id Unique identifier for the alert. Any given alert can generate multiple log records
—one when the alert is initially raised, and then additional records every time
the alert status changes. This ID remains constant for all such alert records.

You can obtain the current status of the alert by looking for log records with this
id and the most recent alert/schedule/last_detected_at timestamp.

version_info/document_version Identifies the log schema version number used for this log record.

version_info/magnifier_version The version number of the Cortex XSIAM – Analytics instance that wrote this
log record.

version_info/detection_version Identifies the version of the Cortex XSIAM – Analytics detection software used
to raise the alert.

alert/url Provides the full URL to the alert page in the Cortex XSIAM – Analytics user
interface.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 921/1003
5/8/24, 9:18 AM PDF Export

Field Name Definition

alert/category Identifies the alert category, which is a reflection of the anomalous network
activity location in the attack life cycle. Possible categories are:

C&C—The network activity is possibly the result of malware attempting to

connect to its Command & Control server.

Exfiltration—A large amount of data is being transferred to an

endpoint that is external to the network.

Lateral—The network activity is indicative of an attacker who is

attempting to move from one endpoint to another on the network.

Malware—A file has been discovered on an endpoint that is probably

malware or riskware. Malware alerts can also be raised based on
network activity that is indicative of automated malicious traffic
generation.

Recon—The network activity is indicative an attacker that is exploring the

network for endpoints and other resources to attack.

alert/type Identifies the categorization to which the alert belongs. For example Tunneling
Process, Sandbox Detection, Malware, and so forth.

alert/name The alert name as it appears in the Cortex XSIAM – Analytics user interface.

alert/description/html The alert textual description in HTML formatting.

alert/description/text The alert textual description in plain text.

alert/severity Identifies the alert severity. These severities indicate the likelihood that the
anomalous network activity is a real attack.

High—The alert is confirmed to be a network attack.

Medium—The alert is suspicious enough to require additional

investigation.

Low—The alert is unverified. Whether the alert is indicative of a network

attack is unknown.

alert/state Identifies the alert state.

Open—The alert is currently active and should be undergoing triage or

investigation by the network security analysts.

Reopened—The alert was previously resolved or dismissed, but new

network activity has caused Cortex XSIAM – Analytics to reopen the
alert.

Archived—No action was taken on the alert in the Cortex XSIAM –

Analytics user interface, and no further network activity has occurred that
caused it to remain active.

Resolved—Network personnel have taken enough action to end the

attack.

Dismissed—The anomaly has been examined and deemed to be

normal, sanctioned, network activity.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 922/1003
5/8/24, 9:18 AM PDF Export

Field Name Definition

alert/is_whitelisted Indicates whether the alert is whitelisted. Whitelisting indicates that anomalous-
appearing network activity is legitimate. If an alert is whitelisted, then it is not
visible in the Cortex XSIAM – Analytics user interface. Alerts can be dismissed
or archived and still have a whitelist rule.

alert/ports List of ports accessed by the network entity during its anomalous behavior.

alert/internal_destinations/single_destinations Network destinations that the entity reached, or tried to reach, during the
course of the network activity that caused Cortex XSIAM – Analytics to raise
the alert. This field contains a sequence of JSON objects, each of which
contains the following fields:

ip—The destination IP address.

name—The destination name (for example, a host name).

alert/internal_destinations/ip_ranges IP address range subnets that the entity reached, or tried to reach, during the
course of the network activity that caused Cortex XSIAM – Analytics to raise
the alert. This field contains a sequence of JSON objects, each of which
contains the following fields:

max_ip—Last IP address in the subnet.

min_ip—First IP address in the subnet.

name—Subnet name.

alert/external_destinations Provides a list of destinations external to the monitored network that the entity
tried to reach, or actually reached, during the activity that raised this alert. This
list can contain IP addresses or fully qualified domain names.

alert/app_id The App-ID associated with this alert.

alert/schedule/activity_first_seen_at Time when Cortex XSIAM – Analytics first detected the network activity that
caused it to raise the alert. Be aware that there is frequently a delay between
this timestamp, and the time when Cortex XSIAM – Analytics raises an alert
(see the alert/schedule/first_detected_at field).

alert/schedule/activity_last_seen_at Time when Cortex XSIAM – Analytics last detected the network activity that
caused it to raise the alert.

alert/schedule/first_detected_at Time when Cortex XSIAM – Analytics first alerted on the network activity.

alert/schedule/last_detected_at Time when Cortex XSIAM – Analytics last alerted on the network activity.

user/user_name The name of the user associated with this alert. This name is obtained from
Active Directory.

user/url Provides the full URL to the user page in the Cortex XSIAM – Analytics user
interface for the user who is associated with the alert.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 923/1003
5/8/24, 9:18 AM PDF Export

Field Name Definition

user/display_name The user name as retrieved from Active Directory. This is the user name
displayed within the Cortex XSIAM – Analytics user interface for the user who is
associated with this alert.

user/org_unit The organizational unit of the user associated with this alert, as identified using
Active Directory.

device/id A unique ID assigned by Cortex XSIAM – Analytics to the device. All alerts
raised due to activity occurring on this endpoint will share this ID.

device/url Provides the full URL to the device page in the Cortex XSIAM – Analytics user
interface.

device/mac The MAC address of the network card in use on the device.

device/hostname The device host name.

device/ip The device IP address.

device/ip_ranges Identifies the subnet or subnets that the device is on. This sequence can
contain multiple inclusive subnets. Each element in this sequence is a JSON
object with the following fields:

asset—The asset name assigned to the device from within the Cortex
XSIAM – Analytics user interface.

max_ip—Last IP address in the subnet.

min_ip—First IP address in the subnet.

name—Subnet name.

device/owner The user name of the person who owns the device.

device/org_unit The organizational unit that owns the device, as identified by Active Directory.

files Identifies the files associated with the alert. Each element in this sequence is a
JSON object with the following fields:

full_path—The file full path (including the file name).

md5—The file MD5 hash.

15.5.7 | Log Formats

Abstract

Cortex XSIAM has different log formats that the Cortex XSIAM tenant forwards to an external server or email destination.

The following topics list the fields of each Cortex XSIAM log type that the Cortex XSIAM tenant can forward to an external server or email destination.

With log forwarding to a syslog receiver, the Cortex XSIAM tenant sends logs in the IETF syslog message format defined in RFC 5425. To facilitate parsing, the
delimiter is a comma and each field is a comma-separated value (CSV) string.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 924/1003
5/8/24, 9:18 AM PDF Export

NOTE:

The FUTURE_USE tag applies to fields that Cortex XSIAM does not currently implement.

With log forwarding to an email destination, the Cortex XSIAM tenant sends an email with each field on a separate line in the email body.

Threat Logs

Config Logs

Analytics Logs

System Logs

Threat Logs

Syslog format: recordType, class, FUTURE_USE, eventType, generatedTime, serverTime, agentTime, tzOffset, FUTURE_USE, facility, customerId, trapsId,
serverHost, serverComponentVersion, regionId, isEndpoint, agentId, osType, isVdi, osVersion, is64, agentIp, deviceName, deviceDomain, severity,
trapsSeverity, agentVersion, contentVersion, protectionStatus, preventionKey, moduleId, profile, moduleStatusId, verdict, preventionMode, terminate,
terminateTarget, quarantine, block, postDetected, eventParameters(Array), sourceProcessIdx(Array), targetProcessIdx(Array), fileIdx(Array), processes(Array),
files(Array), users(Array), urls(Array), description(Array)

Email body format example:

recordType: threat
messageData/class: threat
messageData/subClass:
eventType: AgentSecurityEvent
generatedTime: 2019-01-29T05:07:58.045-08:00
serverTime: 2018-07-02T20:01:39.591Z
endPointHeader/agentTime: 2018-07-02T20:01:03Z
endPointHeader/tzOffset: 180
product:
facility: TrapsAgent
customerId: 245143
trapsId: mac510a2monday-01
serverHost: coreop-qaauta-2606-0-112132729246-266
serverComponentVersion: 2.0.2
regionId: 70
isEndpoint: 1
agentId: dc3af3198f172048082c21ff0956866b
endPointHeader/osType: 2
endPointHeader/isVdi: 0
endPointHeader/osVersion: 10.11.6
endPointHeader/is64: 1
endPointHeader/agentIp: 10.200.37.201
endPointHeader/deviceName: A1260700MC1011
endPointHeader/deviceDomain:
severity: emergency
messageData/trapsSeverity: medium
endPointHeader/agentVersion: 5.1.0.1401
endPointHeader/contentVersion: 26-3625
endPointHeader/protectionStatus: 0
messageData/preventionKey: 9a94965188d2455486dd8d60cf4b3849
messageData/moduleId: COMPONENT_EPM_J01
messageData/profile: ExploitModules
messageData/moduleStatusId: CYSTATUS_JIT_EXCEPTION
messageData/verdict:
messageData/preventionMode: blocked
messageData/terminate: 1
messageData/terminateTarget:
quarantine:
messageData/block: 0
messageData/postDetected: 0
messageData/eventParameters: "[""/Users/administrator/Desktop/JitMac/j01_test"",""711046b89e2f2c70cdbb41f615c54bd1b4270ecbbb176edeb1bb4fe4619""]"
messageData/sourceProcessIdx: 0
messageData/targetProcessIdx: -1
messageData/fileIdx: 0
messageData/processes: "[{""exeFileIdx"":0,""commandLine"":""/Users/Administrator/Desktop/JitMac/j01_test test=system depth=1"",""userIdx"":0,""pid"":1359,""parentId"":452}]"
messageData/files: "[{""sha256"":""711046b89e2f2c70cdbb41f615c54bd1b4270ecbbb176edeb1bb4654619"", ""rawFullPath"":""/Users/administrator/Desktop/JitMac/j01_test"",""signers"":
[""N/A""],""fileName"":""j01_test""}]"
messageData/users: "[{""userName"":""Administrator""}]"
messageData/urls: []
messageData/description: Memory Corruption Exploit

Field Name Description

recordType Record type associated with the event and that you can use when managing
logging quotas. In this case, the record type is threat which includes logs
related to security events that occur on the endpoints.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 925/1003
5/8/24, 9:18 AM PDF Export

Field Name Description

class Class of Cortex XDR agent log: config, policy, system, or agent_log.

eventType Subtype of event: AgentActionReport, AgentDeviceControlViolation,

AgentGenericMessage, AgentSamReport, AgentScanReport,
AgentSecurityEvent, AgentStatistics, AgentTimelineEvent,
ServerLogPerAgent, ServerLogPerTenant, or ServerLogSystem.

generatedTime Coordinated Universal Time (UTC) equivalent of the time at which an event
was logged. For agent events, this represents the time on the endpoint. For
policy, configuration, and system events, this represents the time on Cortex
XSIAM in ISO-8601 string representation (for example, 2017-01-
24T09:08:59Z).

serverTime Coordinated Universal Time (UTC) equivalent of the time at which the server
generated the log. If the log was generated on an endpoint, this field
identifies the time the server received the log in ISO-8601 string
representation (for example, 2017-01-24T09:08:59Z).

agentTime Coordinated Universal Time (UTC) equivalent of the time at which an agent
logged an event in ISO-8601 string representation.

tzOffset Effective endpoint time zone offset from UTC, in minutes.

facility The Cortex XSIAM system component that initiated the event, for example:
TrapsAgent, TrapsServiceCore, TrapsServiceManagement, and
TrapsServiceBackend.

customerId The ID that uniquely identifies the Cortex XSIAM tenant instance which
received this log record.

trapsId Tenant external ID.

serverHost Hostname of Cortex XSIAM.

serverComponentVersion Software version of Cortex XSIAM.

regionId ID of Cortex XSIAM region:

10—Americas (N. Virginia)

70—EMEA (Frankfurt)

isEndpoint Indicates whether the event occurred on an endpoint.

0—No, host is not an endpoint.

1—Yes, host is an endpoint.

agentId Unique identifier for the Cortex XDR agent.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 926/1003
5/8/24, 9:18 AM PDF Export

Field Name Description

osType Operating system of the endpoint:

1—Windows

2—OS X/macOS

3—Android

4—Linux

isVdi Indicates whether the endpoint is a virtual desktop infrastructure (VDI):

0—The endpoint is not a VDI

1—The endpoint is a VDI

osVersion Full version number of the operating system running on the endpoint. For
example, 6.1.7601.19135.

is64 Indicates whether the endpoint is running a 64-bit version of Windows:

0—The endpoint is not running x64 architecture

1—The endpoint is running x64 architecture

agentIp IP address of the endpoint.

deviceName Hostname of the endpoint on which the event was logged.

deviceDomain Domain to which the endpoint belongs.

severity Syslog severity level associated with the event.

2—Critical. Used for events that require immediate attention.

3—Error. Used for events that require special handling.

4—Warning. Used for events that sometimes require special handling.

5—Notice. Used for normal but significant events that can require
attention.

6—Informational. Informational events that do not require attention.

Each event also has an associated Cortex XSIAM severity. See the
messageData.trapsSeverity field for details.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 927/1003
5/8/24, 9:18 AM PDF Export

Field Name Description

trapsSeverity Severity level associated with the event defined for Cortex XSIAM. Each of
these severities corresponds to a syslog severity level:

0—Informational. Informational messages that do not require

attention. Identical to the syslog 6 (Informational) severity level.

1—Low. Used for normal but significant events that can require
attention. Corresponds to the syslog 5 (Notice) severity level.

2—Medium. Used for events that sometimes require special handling.

Corresponds to the syslog 4 (Warning) severity level.

3—High. Used for events that require special handling. Corresponds

to the syslog 3 (Error) severity level.

4—Critical. Used for events that require immediate attention.

Corresponds to the syslog 2 (Critical) severity level.

See also the severity log field.

agentVersion Version of the Cortex XDR agent.

contentVersion Content version in the local security policy.

protectionStatus Cortex XDR agent protection status:

0—Protected

1—OsVersionIncompatible

2—AgentIncompatible

preventionKey Unique identifier for security events.

moduleId Security module name.

profile Name of the security profile that triggered the event.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 928/1003
5/8/24, 9:18 AM PDF Export

Field Name Description

moduleStatusId Identifies the specific component of Cortex XSIAM modules.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 929/1003
5/8/24, 9:18 AM PDF Export

Field Name Description

CYSTATUS_ABNORMAL_PROCESS_TERMINATION

CYSTATUS_ALIGNED_HEAP_SPRAY_DETECTED

CYSTATUS_CHILD_PROCESS_BLOCKED

CYSTATUS_CORE_LIBRARY_LOADED

CYSTATUS_CORE_LIBRARY_UNLOADING

CYSTATUS_CPLPROT_BLACKLIST

CYSTATUS_CPLPROT_REMOTE_DRIVE

CYSTATUS_CPLPROT_REMOVABLE_DRIVE

CYSTATUS_CYINJCT_DISPATCH

CYSTATUS_CYINJCT_MAPPING

CYSTATUS_CYVERA_PREVENTION

CYSTATUS_DANGEROUS_SYSTEM_SERVICE_CALLED

CYSTATUS_DEMO_EVENT

CYSTATUS_DEP_SEH_INF_VIOLATION

CYSTATUS_DEP_SEH_VIOLATION

CYSTATUS_DEP_VIOLATION

CYSTATUS_DEP_VIOLATION_UNALLOCATED

CYSTATUS_DEVICE_BLOCKED

CYSTATUS_DLLPROT_BLACKLIST

CYSTATUS_DLLPROT_CURRENT_WORKING_DIRECTORY

CYSTATUS_DLLPROT_REMOTE_DRIVE

CYSTATUS_DLLPROT_REMVABLE_DRIVE

CYSTATUS_DOTNET_CRITICAL

CYSTATUS_DSE

CYSTATUS_EPM_INIT_FAILED

CYSTATUS_FAILED_CHECK_MEDIA

CYSTATUS_FILE_DELETION_BOOT_DONE

CYSTATUS_FILE_DELETION_FAILED

CYSTATUS_FILE_DELETION_SUCCEEDED

CYSTATUS_FINGERPRINTING_ATTEMPT

CYSTATUS_FONT_PROT_DUQU

CYSTATUS_FORBIDDEN_MEDIA

CYSTATUS_FORBIDDEN_OPTICAL_MEDIA

CYSTATUS_FORBIDDEN_REMOTE_MEDIA

CYSTATUS_FORBIDDEN_REMOVABLE_MEDIA

CYSTATUS_GS_COOKIE_CORRUPTED_COOKIE

CYSTATUS_GUARD_PAGE_VIOLATION

CYSTATUS_HASH_CONTROL

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 930/1003
5/8/24, 9:18 AM PDF Export

Field Name Description

CYSTATUS_HEAP_CORRUPTION

CYSTATUS_HOOKING_ENTRY_POINT_FAILED

CYSTATUS_HOTPATCH_HIJACKING

CYSTATUS_ILLEGAL_EXECUTABLE

CYSTATUS_ILLEGAL_UNSIGNED_EXECUTABLE

CYSTATUS_INJ_APPCONTAINER_FAILURE

CYSTATUS_INJ_CTX_FAILURE

CYSTATUS_JAVA_FILE

CYSTATUS_JAVA_PROC

CYSTATUS_JAVA_REG

CYSTATUS_JIT_EXCEPTION

CYSTATUS_LINUX_BRUTEFORCE_PREVENTED

CYSTATUS_LINUX_ROOT_ESCALATION_PREVENTED

CYSTATUS_LINUX_SHELLCODE_PREVENTED

CYSTATUS_LINUX_SOCKET_SHELL_PREVENTED

CYSTATUS_LOCAL_ANALYSIS

CYSTATUS_MACOS_DLPROT_CWD_HIJACK

CYSTATUS_MACOS_DLPROT_DUPLICATE_PATH_CHECK

CYSTATUS_MACOS_G02_BLOCK_ALL

CYSTATUS_MACOS_G02_SIGNER_NAME_MISMATCH

CYSTATUS_MACOS_G02_SIGN_LEVEL_BELOW_MIN

CYSTATUS_MACOS_G02_SIGN_LEVEL_BELOW_PARENT

CYSTATUS_MACOS_MALICIOUS_DYLIB

CYSTATUS_MACOS_ROOT_ESCALATION_PREVENTED

CYSTATUS_MALICIOUS_APK

CYSTATUS_MALICIOUS_DLL

CYSTATUS_MALICIOUS_EXE

CYSTATUS_MALICIOUS_EXE_ASYNC

CYSTATUS_MALICIOUS_MACRO

CYSTATUS_MALICIOUS_STRING_DETECTED

CYSTATUS_MEMORY_USAGE_LIMIT_EXCEEDED

CYSTATUS_NOP_SLED_DETECTED

CYSTATUS_NO_MEMORY

CYSTATUS_NO_REGISTER_CORRECTED

CYSTATUS_PREALLOCATED_ADDR_ACCESSED

CYSTATUS_PROCESS_CREATION_VIOLATION

CYSTATUS_QUARANTINE_FAILED

CYSTATUS_QUARANTINE_SUCCEEDED

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 931/1003
5/8/24, 9:18 AM PDF Export

Field Name Description

CYSTATUS_RANSOMWARE

CYSTATUS_RESTORE_FAILED

CYSTATUS_RESTORE_SUCCEEDED

CYSTATUS_ROP_MITIGATION

CYSTATUS_SEH_CRITICAL

CYSTATUS_SEH_INF_CRITICAL

CYSTATUS_SHELL_CODE_TRAP_CALLED

CYSTATUS_STACK_OVERFLOW

CYSTATUS_SUSPENDED_PROCESS_BLOCKED

CYSTATUS_SUSPICIOUS_APC

CYSTATUS_SUSPICIOUS_LINK_FILE

CYSTATUS_SYSTEM_SCAN_FINISHED

CYSTATUS_SYSTEM_SCAN_STARTED

CYSTATUS_THREAD_INJECTION

CYSTATUS_TLA_MODEL_NOT_LOADED

CYSTATUS_TOKEN_THEFT_FILE_OPERATION

CYSTATUS_TOKEN_THEFT_PROCESS_CREATED

CYSTATUS_TOKEN_THEFT_REGISTRY_OPERATION

CYSTATUS_TOKEN_THEFT_THREAD_CREATED

CYSTATUS_TOKEN_THEFT_THREAD_INJECTED

CYSTATUS_TOKEN_THEFT_THREAD_STARTED

CYSTATUS_UASLR_CRITICAL

CYSTATUS_UNALLOWED_CODE_SEGMENT

CYSTATUS_UNAUTHORIZED_CALL_TO_SYSTEM_SERVICE

CYSTATUS_UNSIGNED_CHILD_PROCESS_BLOCKED

CYSTATUS_WILDFIRE_GRAYWARE

CYSTATUS_WILDFIRE_MALWARE

CYSTATUS_WILDFIRE_UNKNOWN

verdict Verdict for the file:

0—Benign

1—Malware

2—Grayware

4—Phishing

99—Unknown

preventionMode Action carried out by the Cortex XDR agent (block or notify). The prevention
mode is specified in the rule configuration.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 932/1003
5/8/24, 9:18 AM PDF Export

Field Name Description

terminate Termination action taken on the file.

0— Cortex XSIAM did not terminate the file.

1— Cortex XSIAM terminated the file.

terminateTarget Termination action taken on the target file (relevant for some child process
execution events where we terminate the child process but not the parent
process):

0—Target file was not terminated.

1—Target file was terminated.

quarantine Quarantine action taken on the file:

0—File was not quarantined.

1—File was quarantined.

block Block action taken on the file:

0—File was not blocked

1—File was blocked.

postDetected Post detection status of the file:

0—Initial prevention.

1—Detected after an initial execution.

eventParameters(Array) Parameters associated with the type of event. For example, username,
endpoint hostname, and filename.

sourceProcessIdx(Array) The prevention source process index in the processes array.

targetProcessIdx(Array) Target process index in the processes array. A missing or negative value
means there is no target process.

fileIdx(Array) Index of target files for specific security events such as: Scanning, Malicious
DLL, Malicious Macro events.

processes(Array) All related details for the process file that triggered an event:

1—System process ID

2—Parent process ID

3—File object corresponding to the process executable file

4—Command line arguments (if any)

5—Description field of the VERSIONINFO resource

6—File version field of the VERSIONINFO resource

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 933/1003
5/8/24, 9:18 AM PDF Export

Field Name Description

files(Array) File object includes:

1—SHA256 hash value of the file

2—SHA256 hash value of the macro

3—Raw full filepath

4—A predefined drive type: local, network mapped drive, UNC path
host, removable media, etc.

5—File name (with no extension), such as AdapterTroubleshooter

6—File extension (for example, EXE or DLL)

7—File type defined by the XDR agent

8—UTC file creation time

9—UTC file modification time

10—UTC file access time

11—File attributes bitmask

12—File size in bytes

13—Signer field of the code signing certificate

users(Array) Details about the active user on the endpoint when the event occurred:

1—Username of the active user on the endpoint.

2—Domain to which the user account belongs.

urls(Array) Additional details related to a URL:

1—Raw URL

2—URL schema; For example: HTTP, HTTPS, FTP, LDAP

3—Hostname in punycode

4—Host port

5—Canonicalized URL path part according to schema requirements

6—Query parameters (for http\s only)

7—Fragment parameters (for http\s only)

description(Array) (Mac only) Description of components related to Cortex XSIAM . For

example, the description of the ROP, JIT, Dylib hijacking modules for Mac
endpoints is Memory Corruption Exploit.

Config Logs

Syslog format: recordType, class, FUTURE_USE, subClassId, eventType, eventCategory, generatedTime, serverTime, FUTURE_USE, facility, customerId,
trapsId, serverHost, serverComponentVersion, regionId, isEndpoint, severity, trapsSeverity, messageCode, friendlyName, FUTURE_USE, msgTextEn,
userFullName, userName, userRole, userDomain, additionalData(Array), messageCode, errorText, errorData, resultData

Email body format example:

recordType: system
messageData/class: system
messageData/subClass: Provisioning
messageData/subClassId: 13
eventType: ServerLogPerTenant
messageData/eventCategory: tenant
generatedTime: 2019-01-31T18:15:19.000000+00:00
serverTime: 2019-01-31T18:15:19.000000+00:00

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 934/1003
5/8/24, 9:18 AM PDF Export

product:
facility: TrapsServerManagement
customerId: 004403511
trapsId: 18520498190303952
serverHost: 14917869646-201.proda.brz
serverComponentVersion: 2.0.9+624
regionId:
isEndpoint: 0
agentId:
severity: notice
messageData/trapsSeverity: informational
messageData/messageCode: 19015
messageData/friendlyName: User Login
messageData/msgTextLoc:
messageData/msgTextEn: User [email protected] has logged in with role superadmin
endPointHeader/userFullName:
endPointHeader/username:
endPointHeader/userRole:
endPointHeader/userDomain:
endPointHeader/agentTime:
endPointHeader/tzOffset:
endPointHeader/osType:
endPointHeader/isVdi:
endPointHeader/osVersion:
endPointHeader/is64:
endPointHeader/agentIp:
endPointHeader/deviceName:
endPointHeader/deviceDomain:
endPointHeader/agentVersion:
endPointHeader/contentVersion:
endPointHeader/protectionStatus:
messageData/userFullName:
messageData/username:
messageData/userRole:
messageData/userDomain:
messageData/messageName:
messageData/messageId:
messageData/processStatus:
messageData/errorText:
messageData/errorData:
messageData/resultData:
messageData/parameters:
messageData/additionalData: {}

Field Name Description

recordType Record type associated with the event and that you can use when managing
logging quotas. In this case, the record type is config which includes logs
related to Cortex XSIAM administration and configuration changes.

class Class of Cortex XSIAM log. System logs have a value of system.

subClass Subclass of event. Used to categorize logs in Cortex XSIAM.

subClassId Numeric representation of the subClass field for easy sorting and filtering.

eventType Subtype of event.

eventCategory Category of event, used internally for processing the flow of logs. Event
categories vary by class:

config—deviceManagement, distributionManagement,
reportManagement, securityEventManagement, systemManagement

policy—exceptionManagement, policyManagement,
profileManagement, sam

system—licensing, provisioning, tenant, userAuthentication,

workerProcessing

agent_log—agentFlow

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 935/1003
5/8/24, 9:18 AM PDF Export

Field Name Description

generatedTime Coordinated Universal Time (UTC) equivalent of the time at which an event
was logged. For agent events, this represents the time on the endpoint. For
policy, configuration, and system events, this represents the time on Cortex
XSIAM in ISO-8601 string representation (for example, 2017-01-
24T09:08:59Z).

serverTime Coordinated Universal Time (UTC) equivalent of the time at which the server
generated the log. If the log was generated on an endpoint, this field
identifies the time the server received the log in ISO-8601 string
representation (for example, 2017-01-24T09:08:59Z).

facility The Cortex XSIAM system component that initiated the event, for example:
TrapsAgent, TrapsServiceCore, TrapsServiceManagement, and
TrapsServiceBackend.

customerId The ID that uniquely identifies the Cortex XSIAM tenant instance which
received this log record.

trapsId Tenant external ID.

serverHost Hostname of Cortex XSIAM.

serverComponentVersion Software version of Cortex XSIAM.

regionId ID of Cortex XSIAM region:

10—Americas (N. Virginia)

70—EMEA (Frankfurt)

isEndpoint Indicates whether the event occurred on an endpoint.

0—No, host is not an endpoint.

1—Yes, host is an endpoint.

agentId Unique identifier for the Cortex XDR agent.

severity Syslog severity level associated with the event.

2—Critical. Used for events that require immediate attention.

3—Error. Used for events that require special handling.

4—Warning. Used for events that sometimes require special handling.

5—Notice. Used for normal but significant events that can require
attention.

6—Informational. Informational events that do not require attention.

Each event also has an associated Cortex XSIAM severity. See

the messageData.trapsSeverity field for details.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 936/1003
5/8/24, 9:18 AM PDF Export

Field Name Description

trapsSeverity Severity level associated with the event defined for Cortex XSIAM. Each of
these severities corresponds to a syslog severity level:

0—Informational. Informational messages that do not require

attention. Identical to the syslog 6 (Informational) severity level.

1—Low. Used for normal but significant events that can require
attention. Corresponds to the syslog 5 (Notice) severity level.

2—Medium. Used for events that sometimes require special handling.

Corresponds to the syslog 4 (Warning) severity level.

3—High. Used for events that require special handling. Corresponds

to the syslog 3 (Error) severity level.

4—Critical. Used for events that require immediate attention.

Corresponds to the syslog 2 (Critical) severity level.

See also the severity log field.

messageCode System-wide unique message code.

friendlyName Descriptive log message name.

msgTextEn Description of the event, in English.

userFullName Full username of Cortex XSIAM user.

userName Username associated with Cortex XSIAM user.

userRole Role assigned to Cortex XSIAM user.

userDomain Domain to which the user belongs.

agentTime Coordinated Universal Time (UTC) equivalent of the time at which an agent
logged an event in ISO-8601 string representation.

tzOffset Effective endpoint time zone offset from UTC, in minutes.

osType Operating system of the endpoint:

1—Windows

2—OS X/macOS

3—Android

4—Linux

isVdi Indicates whether the endpoint is a virtual desktop infrastructure (VDI):

0—The endpoint is not a VDI

1—The endpoint is a VDI

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 937/1003
5/8/24, 9:18 AM PDF Export

Field Name Description

osVersion Full version number of the operating system running on the endpoint. For
example, 6.1.7601.19135.

is64 Indicates whether the endpoint is running a 64-bit version of Windows:

0—The endpoint is not running x64 architecture

1—The endpoint is running x64 architecture

agentIp IP address of the endpoint.

deviceName Hostname of the endpoint on which the event was logged.

deviceDomain Domain to which the endpoint belongs.

agentVersion Version of the Cortex XSIAM agent.

contentVersion Content version in the local security policy.

protectionStatus Cortex XSIAM agent protection status:

0—Protected

1—OsVersionIncompatible

2—AgentIncompatible

userFullName Full name of Cortex XSIAM user.

userName Username associated with Cortex XSIAM user.

userRole Role assigned to Cortex XSIAM user.

userDomain Domain to which the user belongs.

messageName Name of the message.

messageId Unique numeric identifier of the message.

processStatus State of the process related to the event.

errorText If known, a description of the documented error.

errorData Parameters related to an event error.

resultData Parameters related to a successful event.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 938/1003
5/8/24, 9:18 AM PDF Export

Field Name Description

parameters Parameters supplied in the log message.

additionalData(Array) Additional information regarding event parameters.

loggedInUser User that is logged in to the Cortex XSIAM.

Analytics Logs

Syslog format: recordType, class, FUTURE_USE, eventType, eventCategory, generatedTime, serverTime, agentTime, tzOffset, FUTURE_USE, facility,
customerId, trapsId, serverHost, serverComponentVersion, regionId, isEndpoint, agentId, osType, isVdi, osVersion, is64, agentIp, deviceName, deviceDomain,
severity, agentVersion, contentVersion, protectionStatus, sha256, type, parentSha256, lastSeen, fileName, filePath, fileSize, localAnalysisResult, reported,
blocked, executionCount

Email body format example:

recordType: analytics
messageData/class: agent_data
messageData/subClass:
eventType: AgentTimelineEvent
messageData/eventCategory: hash
generatedTime: 2019-01-31T18:00:43Z
serverTime: 2019-01-31T18:59:46.586Z
endPointHeader/agentTime: 2019-01-31T18:00:43Z
endPointHeader/tzOffset: -480
product:
facility: TrapsAgent
customerId: 110044035
trapsId: 18520039498190352
serverHost: coreop-f-proda-mnmauto03930348053-311.proda.brz
serverComponentVersion: 2.0.9+564
regionId: 10
isEndpoint: 1
agentId: 3bcf7e5ff56e2891c78684a38b728e49
endPointHeader/osType: 2
endPointHeader/isVdi: 0
endPointHeader/osVersion: 10.12.6
endPointHeader/is64: 1
endPointHeader/agentIp: 192.168.0.21
endPointHeader/deviceName: Jeffreys-MacBook-Pro.local
endPointHeader/deviceDomain:
severity:
endPointHeader/agentVersion: 5.0.5.1193
endPointHeader/contentVersion: 42-6337
endPointHeader/protectionStatus: 0
messageData/sha256: 87e27ba9128d9c3b3d113c67623a06817a030b3bbb4d2871d1e6da9002206f26
messageData/type: macho
messageData/parentSha256:
messageData/lastSeen: 2019-01-31T18:00:43Z
messageData/fileName: crashpad_handler
messageData/filePath: /users/username/library/google/googlesoftwareupdate/googlesoftwareupdate.bundle/contents/macos/
messageData/fileSize: 353680
messageData/localAnalysisResult: "{""contentVersion"":""42-6337"",""result"":""Benign"",""trusted"":""None"",
""publishers"":[""developer id application: google, inc. (eqhxz8m8av)""],""resultId"":0,""trustedId"":0}"
messageData/reported: 0
messageData/blocked: 0
messageData/executionCount: 4179

Field Name Description

recordType Record type associated with the event and that you can use when managing
logging quotas. In this case, the record type is analytics which includes hash
execution reports from the agent.

class Class of Cortex XSIAM log: config, policy, system, and agent_log.

eventType Subtype of event.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 939/1003
5/8/24, 9:18 AM PDF Export

Field Name Description

eventCategory Category of event, used internally for processing the flow of logs. Event
categories vary by class:

config—deviceManagement, distributionManagement,
securityEventManagement, systemManagement

policy—exceptionManagement, policyManagement,
profileManagement, sam

system—licensing, provisioning, tenant, userAuthentication,

workerProcessing

agent_log—agentFlow

generatedTime Coordinated Universal Time (UTC) equivalent of the time at which an event
was logged. For agent events, this represents the time on the endpoint. For
policy, configuration, and system events, this represents the time on Cortex
XSIAM in ISO-8601 string representation (for example, 2017-01-
24T09:08:59Z).

serverTime Coordinated Universal Time (UTC) equivalent of the time at which the server
generated the log. If the log was generated on an endpoint, this field
identifies the time the server received the log in ISO-8601 string
representation (for example, 2017-01-24T09:08:59Z).

agentTime Coordinated Universal Time (UTC) equivalent of the time at which an agent
logged an event in ISO-8601 string representation.

tzOffset Effective endpoint time zone offset from UTC, in minutes.

facility The Cortex XSIAM system component that initiated the event, for example:
TrapsAgent, TrapsServiceCore, TrapsServiceManagement, and
TrapsServiceBackend.

customerId The ID that uniquely identifies the Cortex XSIAM tenant instance which
received this log record.

trapsId Tenant external ID.

serverHost Hostname of Cortex XSIAM.

serverComponentVersion Software version of Cortex XSIAM.

regionId ID of Cortex XSIAM region:

10—Americas (N. Virginia)

70—EMEA (Frankfurt)

isEndpoint Indicates whether the event occurred on an endpoint.

0—No, host is not an endpoint.

1—Yes, host is an endpoint.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 940/1003
5/8/24, 9:18 AM PDF Export

Field Name Description

agentId Unique identifier for the Cortex XDR agent.

osType Operating system of the endpoint:

1—Windows

2—OS X/macOS

3—Android

4—Linux

isVdi Indicates whether the endpoint is a virtual desktop infrastructure (VDI):

0—The endpoint is not a VDI

1—The endpoint is a VDI

osVersion Full version number of the operating system running on the endpoint. For
example, 6.1.7601.19135.

is64 Indicates whether the endpoint is running a 64-bit version of Windows:

0—The endpoint is not running x64 architecture

1—The endpoint is running x64 architecture

agentIp IP address of the endpoint.

deviceName Hostname of the endpoint on which the event was logged.

deviceDomain Domain to which the endpoint belongs.

severity Syslog severity level associated with the event.

2—Critical. Used for events that require immediate attention.

3—Error. Used for events that require special handling.

4—Warning. Used for events that sometimes require special handling.

5—Notice. Used for normal but significant events that can require
attention.

6—Informational. Informational events that do not require attention.

Each event also has an associated Cortex XSIAM severity. See

the messageData.trapsSeverity field for details.

agentVersion Version of the Cortex XDR agent.

contentVersion Content version in the local security policy.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 941/1003
5/8/24, 9:18 AM PDF Export

Field Name Description

protectionStatus Cortex XDR agent protection status:

0—Protected

1—OsVersionIncompatible

2—AgentIncompatible

sha256 Hash of the file using SHA256 encoding.

type Type of file:

0—Unknown

1—PE

2—Mach-o

3—DLL

4—Office file (containing a macro)

parentSha256 Hash of the parent file using SHA256 encoding.

lastSeen Coordinated Universal Time (UTC) equivalent of the time when the file last
ran on an endpoint in ISO-8601 string representation (for example, 2017-01-
24T09:08:59Z).

fileName File name, without the path or the file type extension.

filePath Full path, aligned to the OS format.

fileSize Size of the file in bytes.

localAnalysisResult This object includes the content version, local analysis module version,
verdict result, file signer, and trusted signer result. The trusted signer result
is an integer value:

0— Cortex XSIAM did not evaluate the signer of the file.

1—The signer is trusted.

2—The signer is not trusted.

reported Reporting status of the file, in integer value:

0— Cortex XSIAM did not report the security event.

1— Cortex XSIAM reported the security event.

blocked Blocking status of the file, in integer value:

0— Cortex XSIAM did not block the process or file.

1— Cortex XSIAM blocked the process or file.

executionCount The total number of times a file identified by a specific hash was executed.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 942/1003
5/8/24, 9:18 AM PDF Export

System Logs

Syslog format: recordType, class, FUTURE_USE, subClassId, eventType, eventCategory, generatedTime, serverTime, FUTURE_USE, facility, customerId,
trapsId, serverHost, serverComponentVersion, regionId, isEndpoint, agentId, severity, trapsSeverity, messageCode, friendlyName, FUTURE_USE, msgTextEn,
userFullName, username, userRole, userDomain, agentTime, tzOffset, osType, isVdi, osVersion, is64, agentIp, deviceName, deviceDomain, agentVersion,
contentVersion, protectionStatus, userFullName, username, userRole, userDomain, messageName, messageId, processStatus, errorText, errorData,
resultData, parameters, additionalData(Array)

Email body format example:

recordType: system
messageData/class: system
messageData/subClass: Provisioning
messageData/subClassId: 13
eventType: ServerLogPerTenant
messageData/eventCategory: tenant
generatedTime: 2019-01-31T18:15:19.000000+00:00
serverTime: 2019-01-31T18:15:19.000000+00:00
product:
facility: TrapsServerManagement
customerId: 004403511
trapsId: 18520498190303952
serverHost: 14917869646-201.proda.brz
serverComponentVersion: 2.0.9+624
regionId:
isEndpoint: 0
agentId:
severity: notice
messageData/trapsSeverity: informational
messageData/messageCode: 19015
messageData/friendlyName: User Login
messageData/msgTextLoc:
messageData/msgTextEn: User [email protected] has logged in with role superadmin
endPointHeader/userFullName:
endPointHeader/username:
endPointHeader/userRole:
endPointHeader/userDomain:
endPointHeader/agentTime:
endPointHeader/tzOffset:
endPointHeader/osType:
endPointHeader/isVdi:
endPointHeader/osVersion:
endPointHeader/is64:
endPointHeader/agentIp:
endPointHeader/deviceName:
endPointHeader/deviceDomain:
endPointHeader/agentVersion:
endPointHeader/contentVersion:
endPointHeader/protectionStatus:
messageData/userFullName:
messageData/username:
messageData/userRole:
messageData/userDomain:
messageData/messageName:
messageData/messageId:
messageData/processStatus:
messageData/errorText:
messageData/errorData:
messageData/resultData:
messageData/parameters:
messageData/additionalData: {}

Field Name Description

recordType Record type associated with the event and that you can use when managing
logging quotas. In this case, the record type is system which includes logs
related to automated system management and agent reporting events.

class Class of Cortex XSIAM log. System logs have a value of system.

subClass Subclass of event. Used to categorize logs in Cortex XSIAM user interface.

subClassId Numeric representation of the subClass field for easy sorting and filtering.

eventType Subtype of event.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 943/1003
5/8/24, 9:18 AM PDF Export

Field Name Description

eventCategory Category of event, used internally for processing the flow of logs. Event
categories vary by class:

config—deviceManagement, distributionManagement,
securityEventManagement, systemManagement

policy—exceptionManagement, policyManagement,
profileManagement, sam

system—licensing, provisioning, tenant, userAuthentication,

workerProcessing

agent_log—agentFlow

generatedTime Coordinated Universal Time (UTC) equivalent of the time at which an event
was logged. For agent events, this represents the time on the endpoint. For
policy, configuration, and system events, this represents the time on Cortex
XSIAM in ISO-8601 string representation (for example, 2017-01-
24T09:08:59Z).

serverTime Coordinated Universal Time (UTC) equivalent of the time at which the server
generated the log. If the log was generated on an endpoint, this field
identifies the time the server received the log in ISO-8601 string
representation (for example, 2017-01-24T09:08:59Z).

facility The Cortex XSIAM system component that initiated the event, for example:
TrapsAgent, TrapsServiceCore, TrapsServiceManagement, and
TrapsServiceBackend.

customerId The ID that uniquely identifies the Cortex XSIAM tenant instance which
received this log record.

trapsId Tenant external ID.

serverHost Hostname of Cortex XSIAM.

serverComponentVersion Software version of Cortex XSIAM.

regionId ID of Cortex XSIAM region:

10—Americas (N. Virginia)

70—EMEA (Frankfurt)

isEndpoint Indicates whether the event occurred on an endpoint.

0—No, host is not an endpoint.

1—Yes, host is an endpoint.

agentId Unique identifier for the Cortex XDR agent.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 944/1003
5/8/24, 9:18 AM PDF Export

Field Name Description

severity Syslog severity level associated with the event.

2—Critical. Used for events that require immediate attention.

3—Error. Used for events that require special handling.

4—Warning. Used for events that sometimes require special handling.

5—Notice. Used for normal but significant events that can require
attention.

6—Informational. Informational events that do not require attention.

Each event also has an associated Cortex XSIAM severity. See

the messageData.trapsSeverity field for details.

trapsSeverity Severity level associated with the event defined for Cortex XSIAM. Each of
these severities corresponds to a syslog severity level:

0—Informational. Informational messages that do not require

attention. Identical to the syslog 6 (Informational) severity level.

1—Low. Used for normal but significant events that can require
attention. Corresponds to the syslog 5 (Notice) severity level.

2—Medium. Used for events that sometimes require special handling.

Corresponds to the syslog 4 (Warning) severity level.

3—High. Used for events that require special handling. Corresponds

to the syslog 3 (Error) severity level.

4—Critical. Used for events that require immediate attention.

Corresponds to the syslog 2 (Critical) severity level.

See also the severity log field.

messageCode System-wide unique message code.

friendlyName Descriptive log message name.

msgTextEn Description of the event, in English.

userFullName Full username of Cortex XSIAM user.

userName Username associated with Cortex XSIAM user.

userRole Role assigned to Cortex XSIAM user.

userDomain Domain to which the user belongs.

agentTime Coordinated Universal Time (UTC) equivalent of the time at which an agent
logged an event in ISO-8601 string representation.

tzOffset Effective endpoint time zone offset from UTC, in minutes.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 945/1003
5/8/24, 9:18 AM PDF Export

Field Name Description

osType Operating system of the endpoint:

1—Windows

2—OS X/macOS

3—Android

4—Linux

isVdi Indicates whether the endpoint is a virtual desktop infrastructure (VDI):

0—The endpoint is not a VDI

1—The endpoint is a VDI

osVersion Full version number of the operating system running on the endpoint. For
example, 6.1.7601.19135.

is64 Indicates whether the endpoint is running a 64-bit version of Windows:

0—The endpoint is not running x64 architecture

1—The endpoint is running x64 architecture

agentIp IP address of the endpoint.

deviceName Hostname of the endpoint on which the event was logged.

deviceDomain Domain to which the endpoint belongs.

agentVersion Version of the Cortex XDR agent.

contentVersion Content version in the local security policy.

protectionStatus Cortex XDR agent protection status:

0—Protected

1—OsVersionIncompatible

2—AgentIncompatible

userFullName Full name of Cortex XSIAM user.

userName Username associated with Cortex XSIAM user.

userRole Role assigned to Cortex XSIAM user.

userDomain Domain to which the user belongs.

messageName Name of the message.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 946/1003
5/8/24, 9:18 AM PDF Export

Field Name Description

messageId Unique numeric identifier of the message.

processStatus State of the process related to the event.

errorText If known, a description of the documented error.

errorData Parameters related to an event error.

resultData Parameters related to a successful event.

parameters Parameters supplied in the log message.

additionalData(Array) Additional information regarding event parameters.

loggedInUser User that is logged in to the Cortex XSIAM.

16 | Managed Security
Abstract

In Cortex XSIAM, managed security includes a range of configuration options, including the set up of managed threat hunting, pairing tenants, and more.

Managed Security Services Providers (MSSP) and Managed Detection and Response (MDR) providers can manage security on behalf of their clients by pairing
their own interface with multiple Cortex XSIAM environments.

16.1 | About Managed Security

Abstract

Learn about the use of managed security in Cortex XDR.

Cortex XSIAM supports pairing multiple Cortex XSIAM environments with a single interface enabling Managed Security Services Providers (MSSP) and
Managed Detection and Response (MDR) providers to easily manage security on behalf of their clients.

Pairing an MSSP/MDR (parent) tenant with a client (child) tenant requires a separate Cortex XSIAM license for the parent tenant. To ensure bidirectional tenant
access between the parent and child, both need to approve the pairing from within the Cortex XSIAM app.

Once pairing is approved, Cortex XSIAM resets the child data and synchronizes the security actions configured in the parent tenant, enabling you to view and
investigate Cortex XSIAM data of a child tenant, and initiate security actions on their behalf.

16.2 | Managed Security Access Requirements

Abstract

You can set up managed security access configurations according to the following requirements.

To set up a managed security pairing, you and your child tenants must activate the Cortex XSIAM app, provide role permission, and define access
configurations.

The following table describes what and where you and your child tenants need to define.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 947/1003
5/8/24, 9:18 AM PDF Export

Tenant Application Action

Child Customer Support Portal (CSP) Account Add the user name from the parent tenant who is
initiating the parent-child pairing and ensure the
user name has Super User role permissions.

Gateway Provide the user name added in CSP with Admin

role permissions to access the child Cortex
XSIAM instance.

Parent Customer Support Portal (CSP) Account Ensure the parent user name has Super User
role permissions.

Cortex Gateway Ensure the user name added to the child tenant’s
CSP account has Admin role permissions on the
parent Cortex XSIAM instance.

16.3 | Switch to a Different Tenant

Abstract

The Cortex XSIAM management console provides the tenant navigator, which enables you to switch directly to another owned tenant.

When using multitenancy with Cortex XSIAM , use the Tenant Navigator function to switch directly to another tenant that you own. The tenant navigator includes
the following options:

Cortex XSIAM tenant gateway link.

Cortex XSIAM tenants to which you have access, divided per CSP account. If there are more than 5 tenants to switch to, a search option is available. If
there are more than 5 tenants within a specific account, a list of tenants is available for that CSP account.

CAUTION:

If you don’t own more than one account, the tenant navigator function is not available.

Pivot to Another Tenant

By choosing any tenant listed in the Tenant Navigator, you pivot to the main page of the Gateway or tenant.

1. In Cortex XSIAM, click the hub icon.

The Tenant Navigator panel opens. The currently chosen tenant is marked by a green Active Session label.

2. From the list of available tenants, choose the tenant to which you want to switch (navigate). You can also type a tenant name in the Search line to filter the
list of tenants according to what you type.

16.4 | Pair a Parent Tenant with Child Tenant

Abstract

You can pair a parent tenant to child tenants as needed.

After you and your child tenants have acquired the appropriate role permissions, you can pair your tenant to your child tenants.

NOTE:

Parent and child tenants must be located in the same region, cross-region pairing is not supported.

Pairing a Parent and Child Tenant

1. Log in to the Cortex XSIAM tenant that has been assigned as the parent tenant and select Settings → Configurations → Tenant Management.

The Tenant Management table displays:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 948/1003
5/8/24, 9:18 AM PDF Export

Tenant Name—Name of the child tenant.

Pairing Status—State of a pairing request: Paired, Pending, Failed, Rejected.

Account Name—CSP account to which the child tenant is associated.

Last Sync—Timestamp of when parent tenant last made contact with child tenant.

Managed Security Actions—A column for each security action with a status: Configuration name or Unmanaged. Unmanaged status means that a
configuration for the security action has not yet been selected.

2. + Pair Tenant.

3. In the Pair Tenant window, select the child tenant you want to pair. The dropdown only displays child tenants your are allowed to pair with.

Child tenants are grouped according to:

Unpaired—Children that have not yet been paired and are available. If another parent has requested to pair with the child but the child has not yet
agreed, the tenant will appear.

Paired—Children that have already been paired to this parent.

Paired with others—Children that have been paired with other parents.

Pending—Children with a pending pairing request.

4. Pair the tenant.

Cortex XSIAM sends a Request for Pairing to the specified child tenant.

5. In the child tenant Cortex XSIAM console, a child tenant user with Admin role permissions needs to approve the pairing by navigating to Notifications ,
locate the Request for Pairing notification and select Approve.

6. Verify the parent-child pairing.

After pairing has been approved, in the child tenant’s Cortex XSIAM app, when navigating to a page managed by a parent configuration, the child user is
notified by a flag who is managing their security.

In the child tenant’s, pages that you manage, appear with a read-only banner. Child tenant users cannot perform any actions from these pages, but can
view the configurations you create on their behalf.

Unpairing a Parent and Child Tenant

When you want to discontinue the pairing with a child tenant, in the Tenant Management page, right-click the tenant row and select Request Unpairing. For the
unpairing to take effect, the child tenant must approve the request.

When a child wants to unpair, the child user needs to select Settings → Unpair.

16.5 | Manage a Child Tenant

Abstract

From the Cortex XSIAM management console you can pair child tenants, enabling you to view and investigate data, and initiate security actions.

Pairing a child tenant enables you to view and investigate Cortex XSIAM data of a child tenant, and initiate security actions on their behalf.

In your Cortex XSIAM management console, you have access to view the following pages:

Incidents

Alerts

Query Builder

Query Center and Results

Causality View

Timeline View

To initiate security actions on your child tenant, you need to create a Configuration. Security actions are managed by configurations you create in the Cortex
XSIAM app and then assign to each of the child tenants. Each action requires its own configuration and allocation to a child tenant.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 949/1003
5/8/24, 9:18 AM PDF Export

NOTE:

Once a configuration is created Cortex XSIAM resets the child tenant data and synchronizes the security actions configured in the parent tenant.

You can create configuration for the following actions:

BIOC Rules and Exceptions

Starred Alerts Policies

Alert Exclusions

Profiles

Allow/Block Lists

The following sections describe how to manage your child tenants.

16.5.1 | Track your Tenant Management

Abstract

You can view the details of your tenants at any time.

After successfully pairing your child tenant, select Settings → Configurations → Tenant Management to view the child tenant details.

The Tenant Management page displays the following information about each of your child tenants:

Field Description

(Status Indicator) Identifies whether the child tenant is connected.

TENANT ID The Cortex XSIAM tenant ID.

TENANT NAME Name you defined during the pairing process.

ACCOUNT ID The CSP account ID.

ACCOUNT NAME Name of the parent tenant.

PAIRING STATUS Status of the child paring process:

Pending

Paired

Approved

Declined

Pending

Paired to another

Not Paired

LAST SYNC Timestamp of the last security action sync initiated by the parent tenant.

BIOC RULES & EXCEPTIONS Name of the configuration managing the BIOC rules and exceptions actions.

STARRED INCIDENTS POLICY Name of the configuration managing the starred incidents policy actions.

ALERT EXCLUSION Name of the configuration managing the alert exclusion actions.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 950/1003
5/8/24, 9:18 AM PDF Export

Field Description

PROFILES Name of the configuration managing the profile actions.

16.5.2 | Investigate Child Tenant Data

Abstract

For managed security providers, you can view, track, and investigate data across your Cortex XSIAM child tenants.

With Cortex XSIAM managed security, you can investigate the Cortex XSIAM child tenant data.

By default, Cortex XSIAM displays data for your tenant. To display data for of your child tenant, select the tenant from the drop-down.

Some common tasks that you might perform include:

Investigate incidents on a child tenant.

Investigate alerts on a child tenant.

Build and execute an XQL search query to search across the data of a child tenant.

When running an XQL Search, you can execute XQL queries across a single child tenant or up to 100 child tenants simultaneously.

For XQL queries on a single child tenant, Cortex XSIAM provides the parent tenant with autocompletion and validation capabilities to all datasets
available on the child tenant.

When executing XQL queries on multiple child tenants simultaneously:

Autocomplete and validation are supported on all datasets.

Queries are executed on each child tenant separately and return up to 1,000,000 results split across the selected tenants. For example, an
XQL query on 10 tenants returns a maximum of 100,000 per tenant.

You can select multiple datasets that share the same dataset name from different child tenants even when their schemas are different. Cortex
XSIAM displays only the common fields that have the same name and the same data type in both datasets. If the datasets from two child
tenants contain fields with the same name, but different data types, or one of the datasets contains fields that the other one doesn’t have,
these fields will not be displayed. By default, even when you don’t select fields, Cortex XSIAM automatically selects the fields that are
common to both child datasets.

In the example below, if you select two child tenants which both contain a dataset called users, Cortex XSIAM displays users as a possible
source for the query, even though they contain different fields.

Tenant_1:
users= {“employee_name”: “John”, “employee_number”: 123}
Tenant_2:
users= {“employee_name”: “John”, “employee_number”: "123", "national_ID": 123456789}

When you start selecting fields from users, Cortex XSIAM displays only the field employee_name as an option for the query since its name
and type are the same for both child tenants.

Use the Query Builder to build and execute an entity-specific query across the data of a child tenant. You can run either an ad-hoc query or a scheduled
query on one or more child tenants. For each query, Cortex XSIAM returns up to 100,000,000 results across all selected tenants.

Use the Query Center to view previously run XQL searches and entity queries run on your tenant and the child tenants.

16.5.3 | Create and Allocate Configurations

Abstract

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 951/1003
5/8/24, 9:18 AM PDF Export

From the Cortex XSIAM management console, you can create and allocate configurations for child tenants.

To manage security actions on behalf of your child tenant, you need to first create and allocate an action configuration.

1. Navigate to each of the following Cortex XSIAM pages and follow the detailed steps:

Detection & Threat Intel → Detection Rules → BIOC → Rules and Exceptions Configurations panel

Incident Response → Incident Configuration → Alert Exclusions → Alert Exclusions Configuration panel

Incident Response → Incident Configuration → Starred Alerts → Starred Alerts Configuration panel

Endpoints → Policy Management → Prevention → Profiles → Profile Configuration panel

Incident Response → Response → Action Center → Currently Applied Actions → Block List/Allow List → Allow List/Block List configuration panel

2. In the corresponding Configuration panel, + Create New configuration.

3. Enter the configuration Name and Description.

4. Create.

The new configuration appears in the Configuration pane.

5. Navigate to Settings → Tenant Management.

6. In the Tenant Management table, right-click a child tenant row and Edit Configurations.

7. Assign the configuration you want to use to manage each of the security actions.

NOTE:

You can configure Profiles only as Managed or Unmanaged. All profiles you create are automatically cloned to your child tenants.

8. Update.

The Tenant Management table is updated with your assigned configurations.

16.5.4 | Create a Security Managed Action

Abstract

Create a security type action to perform on behalf of your child tenants.

After you have created and assigned a configuration for each of your child tenant’s security actions, you can define the specific managed action on behalf of the
child tenant.

1. Navigate to each of the following Cortex XSIAM pages:

Rules → BIOC → Rules and Exceptions Configurations panel

Investigation → Incident Management → Exclusions → Alert Exclusions Configuration panel

Investigation → Incident Management → Starred Alerts → Starred Alerts Configuration panel

Endpoints → Policy Management → Prevention → Profiles → Profile Configuration panel

Response → Action Center → Currently Applied Actions → Block List/Allow List → Allow List/Block List configuration panel

2. In the corresponding Configuration panel, select the you created and allocated to your child tenant.

The corresponding security action Table displays the actions managing the child tenant.

3. Depending on the security action, select:

+ Add BIOC to create a BIOC Rule.

+ New Exception to create a BIOC Exception.

+ Add Exclusion to create an Alert Exclusion.

+ Add Starring Configuration to create a started alert inclusion.

+ New Profile to create a new endpoint profile.

NOTE:

Profiles you create are automatically cloned to your child tenants.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 952/1003
5/8/24, 9:18 AM PDF Export

16.6 | About Managed Threat Hunting

Abstract

Understand how Managed Threat Hunting can help your organization.

Cortex XSIAM provides the Managed Threat Hunting service as an add-on security service. To use Managed Threat Hunting, you must purchase a Managed
Threat Hunting license and have a license with a minimum of 500 endpoints.

Managed Threat Hunting augments your security by providing 24/7, year-round monitoring by Palo Alto Networks threat researchers and Unit 42 experts. The
Managed Threat Hunting teams proactively safeguard your organization and provide threat reports for critical security incidents and impact reports for emerging
threats that provide an analysis of exposure in your organization. In addition, the Managed Threat Hunting team can identify incidents and provide indepth
review of related threat reports.

16.7 | Set up Managed Threat Hunting

Abstract

Get started with the Managed Threat Hunting service, an add-on security service provided with Cortex XSIAM.

To get started with Managed Threat Hunting:

1. Open the Cortex XSIAM tenant and approve the pairing request sent to your tenant.

a. Navigate to Notifications and locate the Request for Pairing notification.

b. Select Approve and then Yes to confirm.

After the request is approved, Cortex XSIAM displays the Managed Threat Hunting label at the top of the page.

2. Configure notification emails for the impact reports and threat inquiries you want to send.

a. Select Settings → Configurations → Managed Services.

b. Enter one or more email addresses to which you want to send reports and inquires and ADD each one.

c. Save your changes.

3. Test the email, by going to your defined email address mailbox, and locate the Welcome to the Palo Alto Networks Cortex XSIAM Managed Threat
Hunting Service email. If you did not receive the email, contact Customer Support.

4. (Optional) If desired, forward Managed Threat Hunting alerts to external sources such as email or slack from the Settings → Configurations → General →
Notifications page.

This forwards the alert and the detailed report in a PDF format.

16.8 | Investigate Managed Threat Hunting Reports

Abstract

Investigate your Managed Threat Hunting reports.

The Managed Threat Hunting team proactively scans, identifies, and analyzes your Cortex XSIAM tenant for possible threats and creates detailed threat and
impact reports to help you track and manage your Cortex XSIAM data.

Cortex XSIAM displays the reports in a dedicated page that allows you to investigate and communicate with your Managed Threat Hunting team. When a new
report is sent, MTH send a notification to your Notification Center. MTH type notifications will appear at the top of your notification list and offer the following
options:

Open—Pivot to report in the Managed Threat Hunting table.

Dismiss—Delete the notification from your Notifications list.

NOTE:

The MTH page is available for users with the Managed Threat Hunting license and have the necessary permission to view and triage alerts and incidents in
Cortex XSIAM.

To investigate your reports:

1. In the Cortex XSIAM console, select MTH.

The Managed Threat Hunting page displays a side-by-side view of all your reports and their corresponding report details and communication.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 953/1003
5/8/24, 9:18 AM PDF Export

2. In the left-pane, select the report you want to investigate. You can sort the list according to the report Type, Insert Time, or Severity, and use the search
bar to help you locate reports.

After selecting a report, the right-pane view displays a summary of the Managed Threat Hunting findings along with an attachment of the complete report.

3. In the right-pane, investigate the report findings and add your comments.

The comments are a way for you to communicate directly with the Managed Threat Hunting without the need to send separate emails. When you post a
comment, the Managed Threat Hunters team is notified and can see and reply to your comments. Comments are listed chronologically and are visible to
all the Cortex XSIAM tenant users with access to the MTH page and the Managed Threat Hunting team. You can attach up to ten PDF or image format
files with a maximum of 10MB per file in each comment. Editing and deleting a comments is available only on comments you wrote.

17 | Marketplace
Abstract

Access the Cortex XSIAM Marketplace and install content packs. Convert existing content to content pack format.

The Marketplace is the location for installing and managing content, such as playbooks, integrations, automation, fields, and more.

17.1 | Marketplace Overview

Abstract

Use the Marketplace to install, exchange, contribute and manage your content in Cortex XSIAM.

The marketplace enables you to easily do the following:

Discover top-rated, validated content—Identify the content offerings recommended by your peers and validated by the world’s leading cyber security
company. Discover how to increase automation with the tools that you already have.

Solve your toughest security use cases—Deploy turn-key security workflows that span integrations, automations, alert fields, types, and playbooks with
a single click.

The Marketplace content packs are pre-built bundles of integrations, playbooks, automations and fields, and all the dependencies needed to support specific
security orchestration use cases. Content packs, which are free, can be used by all customers and contain any of the following elements:

Feature Description

Integrations You can define the following types of integrations:

(SOAR) Automation: Add your 3rd-party security and alert management vendors, which can
then trigger events from these integrations that become alerts in Cortex XSIAM. Once the alerts
are created, you can run playbooks on these incidents to enrich them with information from
other products in your system, which helps you complete the picture.

Collection (SIEM): Add integrations that collect raw events, such as logs. These integrations are
separate from automation integrations so that you can add a collection integration that requires
read permissions without having to add an automation (read and write permissions).

Playbooks You can automate many security processes, including handling investigations and managing tickets
and security responses that were previously handled manually. When an alert is ingested, the
playbook runs and an alert is created.

Alert Types All alerts that are ingested into Cortex XSIAM are assigned an alert type when they are classified.
After you classify the alert, you can then map the relevant fields to the alert.

Alert Fields Alert types contain fields that are relevant to the alert type.

Scripts Perform specific actions and are comprised of commands, which are used in playbook tasks and
when running commands in the alert War Room.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 954/1003
5/8/24, 9:18 AM PDF Export

Feature Description

Correlation Rules Analyzes correlation of multi-event from multiple sources by using the Cortex XSIAM XQL-based
engine for creating these correlations (scheduled) rules. Alerts can then be triggered based on these
rules with a defined time-frame and schedule.

Data Model Rules Data Model rules enable you to normalize logs for out-of-the-box analytics and data enrichment. This
allows you to do the following:

Map 3rd party data to a consolidated schema with predefined data types.

Enjoy auto-complete and mapping suggestions.

Map multiple datasets to one Data Model.

Some content packs contain out-of-the-box default Data Model Rules.

Parsing Rules Enables you to add rules which remove non-required data for analytics, hunting, or regulation, reduce
data storage costs, pre-process all incoming data, etc.

NOTE:

When installed, the parsing rules are enabled and added as Default Rules. When deleted, all
related parsing rules (including all Rule sections) are removed from the Default Rules tab.

Dashboards Dashboards consist of visualized data powered by fully customizable widgets, which enables you to
analyze data from inside or outside Cortex XSIAM, in different formats such as line charts, tables,
text, etc.

Reports Reports contain statistical data in the form of widgets (from a dashboard), which enable you to
analyze data from inside or outside Cortex XSIAM, in different formats such as line charts, tables, text
from information, etc.

Content Pack Support Types

Marketplace includes the following content pack support types:

Supported content packs

Applies only to content packs published by Palo Alto Networks. These content packs are supported and maintained by Palo Alto Networks according to
the Palo Alto Networks End User Support Agreement.

Partner-Supported content packs

Applies to content packs published by Cortex XSIAM Technology Partners. Support and maintenance is provided by the Technology Partner, whose
contact information appears in the content pack details. Technology Partners are required to join the industry-standard support framework, TSANet, to
deliver support to our mutual customers. Customers engage directly with the Partner for support and maintenance of the partner-supported content pack.

17.2 | Marketplace FAQs

Abstract

Frequently asked questions about Cortex XSIAM Marketplace content.

Should Marketplace content always be updated?

Marketplace updates are a source for bug fixes and provide new commands for integrations and automation. It’s a best practice to update content packs to the
newest available version. If you encounter any issue with content updates, you can revert to a previous version with one click.

When can Marketplace content be updated?

You can update content while the system is in use. If a playbook, for example, is running on an asset while you update that playbook, the original version of the
playbook will continue to run without issues. If the playbook includes an integration command that has been updated, and the update occurs before the playbook
reaches this task, the new version of the integration command will be used.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 955/1003
5/8/24, 9:18 AM PDF Export

How can content updates be rolled back? Are dependencies automatically rolled back as well?

You can view all versions of a content pack in the Marketplace and revert to earlier versions there. When you revert a content pack, only the content pack is
reverted, not the pack dependencies.

17.3 | Search and Navigate in the Marketplace

Abstract

Search the Cortex Marketplace and find free content. Search by use cases, integrations, and categories.

In the Marketplace, you can install, delete, and update content such as playbooks, integrations, and asset types.

You can browse all content (including installed content), or view only installed content packs. When a content pack needs to be updated you receive a
notification and can view the updates in the Installed Content Packs tab.

You can use the search bar to search for content by adding text and then selecting the relevant content from the search results.

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

Use cases: Filter according to high-level use cases, such as Phishing, Malware, Ransomware, Access, etc.

Integrations: Filter according to the integration included in the content pack.

Categories: Filter according to content pack categories, such as Messaging, Forensics & Malware Analysis, etc.

Published: Whether published by Cortex XSIAM or by Cortex XSIAM technology partners.

General

Filter Description

Certified Created and supported by a user and certified by Cortex XSIAM. Cortex XSIAM has
tested the content to ensure that it meets standards and works correctly.

Uses my integrations Content packs that use integrations that you have added instances for (whether or
not they are enabled).

Supported Supported by either Cortex XSIAM or a partner-supported content pack.

Content Pack Includes: Filter according to the content of the content pack, such as Automations, Integrations, Playbooks, etc.

Tags: Filter according to tags, such as Alerts, Network, Security, etc.

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

17.4 | Content Pack Lifecycle

Abstract

Search for and download content packs and receive content pack updates in the Marketplace.

In the Marketplace, you can search for new content packs to install by integration, categories, etc., when you search and navigate in the Marketplace. Before
you install a content pack you should review the content pack to see what it includes and any dependencies. For more information, see Content Pack
Installation.

Content Pack Updates

Content packs are updated for bug fixes, enhancements, and so on. When there is an update available for a content pack, you will see notifications in the
Installed Content Packs tab in the Marketplace.

The Marketplace is updated every 2 hours.

In the Version History tab of a content pack, you can see the currently installed version, earlier versions, and available updates. You can revert to a previous
version of a content pack if required.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 956/1003
5/8/24, 9:18 AM PDF Export

NOTE:

Third party product Integrations are developed and tested against a specific product version. For products which are on-prem or cloud based with specific API
versions, the version developed and tested against will be included in the integration's documentation. Newer versions of the product are not always
immediately tested and it is expected that products maintain API compatibility upon release of newer product versions. When upgrading to a newer product
version, it is highly recommended to test the integration in a dev environment before deploying to production.

Certification

Certified content packs are thoroughly reviewed by the team and pass a rigid set of requirements that ensure quality and that the pack consists of a complete
use case.

17.5 | Content Pack Installation

Abstract

Cortex XSIAM content pack dependencies, errors, and warning messages. Troubleshoot content pack installation.

Before you install a content pack, review the content pack to see what it includes, any dependencies that are required, reviews, etc. When selecting a content
pack, you can view the following information:

Details: General information about the content pack including installation, content, version, author, status, etc.

Content: The content to be installed, such as automations, integrations, etc.

Dependencies: Details of any Required Content Packs and Optional Content Packs that may need to be installed with the content pack.

Version History: View the currently installed version, earlier versions, available updates, and revert if required.

After installation, go to the relevant page to view the installed content. For example, to view a playbook, go to Incident Response → Automation → Playbooks.

Dependencies

In Cortex XSIAM, some objects are dependent on other objects. For example, a playbook may be dependent on other playbooks, scripts, integrations, and
incident fields, etc.

For example, an Alert may be dependent on a playbook, an alert type, and an alerts field. A script may be dependent on another script, an integration, etc.

When you install a content pack, mandatory dependencies including Required Content Packs are added automatically to ensure that it installs correctly.

Some content, while not essential for installation, ensures that the content runs successfully. These dependencies include Optional Content Packs, which can be
added or removed in the Cart.

WARNING:

If you delete a content pack, which depends on other content packs, these content packs may not run correctly. Also, if you roll back to an earlier version of a
content pack, other content packs might be affected. For example, if Content Pack A depends on layouts from Content Pack B Version 2, reverting to Content
Back B Version 1 could cause Content Pack A to stop working.

Required Content Packs

Required content packs are mandatory content packs, which download automatically with the content pack. These content packs are dependent on the required
content pack and without them installation fails.

If a content pack is dependent on one or more content packs, you have to install all of them. For example, if content pack A requires content pack B and content
pack B requires content pack C when you install content pack A, all of the other content packs are installed.

NOTE:

You cannot remove the Required Content Packs when installing a content pack.

In the following example, the Impossible Traveler content pack requires:

Active Directory Query v2 and Base content packs (both of which are installed).

Rasterize content pack (which needs to be installed).

Optional Content Packs

Optional Content Packs are used by the content pack you want to install but are not necessary for installation. You can choose which optional content pack to
install in the Cart. When you install optional content packs, mandatory dependencies are automatically included.

For example, in the Active Directory Query content pack, there are various optional content packs used by the content pack, such as Microsoft Graph Mail. You
can install the content pack without Microsoft Graph Mail if your organization does not need it.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 957/1003
5/8/24, 9:18 AM PDF Export

Errors and Warning Messages

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

Error Message Example

In this example, we want to install the Impossible Traveler content pack, but we already have a custom playbook with the same name/ID. When we try to install
the content pack, the installation fails.

When clicking view errors, you can see the error. You need to update the existing custom playbook.

Warning Message Example

In this example, we want to update the Common Scripts content pack.

When we try to install, a warning message may be issued about a missing Docker image.

If you click Install Anyway, the pack installs, but you need to add the missing Docker image for the content to run correctly.

17.5.1 | Install a Content Pack

Abstract

Install content packs from the Marketplace.

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

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

Go to the Data Sources page and add a data source by configuring an integration in the Data Sources page. Once configured, it automatically installs the
required content packs, and recommends additional beneficial content such as playbooks and dashboards that are relevant for this specific data source.
For details, see Adding a new data source or instance.

In Marketplace, select either Data Onboarder (which takes you to the integration configuration in the Data Sources page (for details, see Adding a new
data source or instance)) or install the content pack directly from Marketplace. If installing the content pack from Marketplace, you will then have to
configure the integration in the Automation &amp; Feed Integrations page.

NOTE:

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

1. Go to Marketplace → Browse and locate the content pack you want to install.

2. Click the required content pack and review the contents.

3. Click Install to add the content pack to the Cart.

You can view details of the content packs by clicking the content you want to install.

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

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

5. Click Install.

If you receive an error message, you need to fix the error before installing. In case of a warning message, you can install and fix it later. For more
information, see errors and warning messages.

After installation, go to the relevant tab to view/edit the content.

17.5.2 | Delete a Content Pack

Abstract

Delete a Cortex XSIAM content pack, including all content. Unsubscribe from content packs. Delete all detached and customized content.

When you delete a content pack, all content is deleted including all detached and customized content.

CAUTION:

If another pack is dependent on the content pack it may break other content. You can reinstall the content pack, but you cannot restore detached and
customized content.

1. Go to Marketplace → INSTALLED CONTENT PACKS.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 958/1003
5/8/24, 9:18 AM PDF Export

2. In the Content Packs Library section, search for the content pack and click the content pack you want to delete.

3. Click the trash can icon.

4. Review the warning message and click Delete.

17.5.3 | Update a Content Pack

Abstract

Update content packs in Cortex XSIAM. View available updates in the Marketplace.

When content packs are available for update, you can see the number of content packs that can be updated in the Installed Content Packs tab. You can update
to the latest content version or specific versions. If you have made any customizations, these are automatically included in any update. All dependent content
packs update automatically with the content pack.

NOTE:

Third party product Integrations are developed and tested against a specific product version. For products which are on-prem or cloud based with specific API
versions, the version developed and tested against will be included in the integration's documentation. Newer versions of the product are not always
immediately tested and it is expected that products maintain API compatibility upon release of newer product versions. When upgrading to a newer product
version, it is highly recommended to test the integration in a dev environment before deploying to production.

If other users have downloaded content, you can update content packs in your environment.

CAUTION:

If you want to downgrade, any content that depends on the content pack including any customizations may be deleted if it does not exist in the target content
pack version.

1. In the Installed Content Packs tab, search for the content that is available to update.

2. In the Version History tab of the content pack, view the updates that are available.

3. (Optional) If there is more than one update available, select which version to update.

If you choose to install the latest version it includes the previous version. If you have made any customizations these are included in any update. If any
dependencies require updating, these are automatically added.

4. Click the update to the version.

5. Click Update.

17.5.4 | Revert a Content Pack

Abstract

Revert to the previous version of an installed content pack.

You can revert to an earlier version of an installed content pack. Items that are not included in the version are also deleted, such as detached playbooks, scripts
that use other scripts from the content pack, etc.

NOTE:

If you roll back to an earlier version of a content pack, other content packs might be affected. For example, if content pack A depends on scripts from content
pack B version 2, reverting to content pack B version 1 could cause content pack A to stop working.

1. In the Installed Content Packs tab, click the content pack you want to revert.

2. In the Version History tab, select the version you want to revert.

3. Click Revert to this version. The version will be added to your Cart.

4. In the Cart, click Downgrade.

17.6 | Forward Requests to Long Running Integrations

Abstract

Configure and manage long running integrations to export internal data from Cortex XSIAM.

Some long running integrations provide internal data via API calls, to your third-party software, such as a firewall. You can set up Cortex XSIAM to allow third-
party software to access long running integrations installed either on the Cortex XSIAM tenant or on an engine. For example, you can provide access to external
dynamic lists.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 959/1003
5/8/24, 9:18 AM PDF Export

Long running integrations that provide internal data via API calls include, but are not limited to:

O365 Teams (Using Graph API)

Generic Webhook

Generic Export Indicators Service

TAXII Server

TAXII2 Server

XSOAR-Web-Server

PingCastle

Publish List

Simple API Proxy

Syslog v2

Web File Repository

NOTE:

Currently, you can only use long running integrations provided by Cortex XSIAM, you cannot create custom ones.

Configuring custom certificates or private API Keys in the long running integration instance is supported only on engines, not on the Cortex XSIAM
tenant.

Credentials

For long running integrations running on a tenant, you must set a username and password. For long running integrations running on an engine, we strongly
recommend setting a username and password, but it is not required.

Users with sufficient permissions can set the username and password for specific integration instances, on the Integrations → Instances page.

Listen Port

Integration Instance Running on a Tenant

If the long running integration runs on the Cortex XSIAM tenant, you do not need to enter a Listen Port in the instance settings. The system auto-selects
an unused port for the long running integration when the instance is saved.

Integration Instance Running on an Engine

You must set the Listen Port for access when configuring a long running integration instance on an engine. Use a unique port for each long running
integration instance. Do not use the same port for multiple instances.

Test the Connection

Integration Instance Running on a Tenant

You can use CURL commands from any terminal to access and test the long running integration at the URL:

https://ext-<cortex-xsoar-address>/xsoar/instance/execute/<instance-name>

For example: curl -v -u user:pass https://ext-mytenant.paloaltonetworks.com/xsoar/instance/execute/edl_instance_01\?

q\=type:ip

NOTE:

The data URL must always be prefixed by ext-.

Integration Instance Running on an Engine

You can use CURL commands from any terminal to access and test the long running integration at the engine URL:

http://<engine-address>:<integration listen port>/

For example: curl -v -u user:pass http://<engine_address>:<listen_port>/?n=50

Curl Request Parameters

When sending a curl request to the URL, you can use the following parameters.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 960/1003
5/8/24, 9:18 AM PDF Export

Argument Description Example

n The maximum number of entries in the output. If no https://ext-<cortex-

value is provided, will use the value specified in the List xsiam_instance>/instance/execute/<ExportIndicators_instance_name>?
Size parameter in the integration instance settings. n=50

s The starting entry index from which to export the https://ext-<cortex-

indicators. xsiam_instance>/instance/execute/<ExportIndicators_instance_name>?
s=10&n=50

v The output format. Supports PAN-OS https://ext-<cortex-

(text), CSV, JSON, mwg and proxysg (alias: bluecoat). xsiam_instance>/instance/execute/<ExportIndicators_instance_name>?
v=json

q The query used to retrieve indicators from the system. https://ext-<cortex-

xsiam_instance>/instance/execute/<ExportIndicators_instance_name>?
q="type:ip and sourceBrand:my_source"

t Only with mwg format. The type indicated on the top of https://ext-<cortex-
the exported list. Supports: string, applcontrol, xsiam_instance>/instance/execute/<ExportIndicators_instance_name>?
dimension, category, ip, mediatype, number and regex. v=mwg&t=ip

sp If set, will strip ports off URLs, otherwise will ignore https://ext-<cortex-
URLs with ports. xsiam_instance>/instance/execute/<ExportIndicators_instance_name>?
v=text&sp

di Only with PAN-OS (text) format. If set, will ignore URLs https://ext-<cortex-
which are not compliant with PAN-OS URL format xsiam_instance>/instance/execute/<ExportIndicators_instance_name>?
instead of being re-written. v=text&di

cr If set, will strip protocols off URLs. https://ext-<cortex-

xsiam_instance>/instance/execute/<ExportIndicators_instance_name>?
v=text&pr

cd Only with proxysg format. The default category for the https://ext-<cortex-
exported indicators. xsiam_instance>/instance/execute/<ExportIndicators_instance_name>?
v=proxysg&cd=default_category

ca Only with proxysg format. The categories which will be https://ext-<cortex-

exported. Indicators not in these categories will be xsiam_instance>/instance/execute/<ExportIndicators_instance_name>?
classified as the default category. v=proxysg&ca=category1,category2

tr Only with PAN-OS (text) format. Whether to collapse https://ext-<cortex-

IPs. xsiam_instance>/instance/execute/<ExportIndicators_instance_name>?
q="type:ip and sourceBrand:my_source"&tr=1
0 - Do not collapse.

1 - Collapse to ranges.

2 - Collapse to CIDRs

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 961/1003
5/8/24, 9:18 AM PDF Export

Argument Description Example

tx Whether to output CSV formats as textual web pages. https://ext-<cortex-

xsiam_instance>/instance/execute/<ExportIndicators_instance_name>?
v=csv&tx

18 | Engines
Abstract

Install, manage, configure, and troubleshoot engines.

18.1 | Engines Overview

Abstract

Understand engine architecture, load balancing groups, installation and configurations.

Engines are installed in a remote network and allow communication between the remote network and Cortex XSIAM. You can run integration commands on an
engine. It is possible to install a single engine or multiple engines.

You can install multiple engines on the same machine (Shell installation only) where you do not want to have numerous engines in different environments and to
manage those machines.

NOTE:

You cannot share a multiple-engine installation with a single-engine installation.

An engine is used for the following purposes:

Engine Proxy

Engine Load-Balancing

Engine Proxy

Engines enable to access internal or external services that are otherwise blocked by a firewall or a proxy, etc. For example, if a firewall blocks external
communication and you want to run the Rasterize integration, you need to install an engine to access the Internet.

Engine Architecture

Within the network, you need to allow the engine to access the Cortex XSIAM’s IP address and listening port (by default, TCP 443). The engine always initiates
the communication to Cortex XSIAM.

Engine Load-Balancing

Engines can be part of a load-balancing group, which enables the distribution of the command execution load. The load-balancing group uses an algorithm to
efficiently share the workload for integrations that the group is assigned to, thereby speeding up execution time. In general, heavy workloads are caused by
playbooks that run a high number of commands.

Before configuring an integration to run using multiple engines in a load-balancing group, it is recommended that you test the integration using a single engine in
the load-balancing group.

NOTE:

When you add an engine to a load-balancing group, you cannot use that engine separately. The engine does not appear in the engines drop-down menu
when configuring an integration instance.

Engine Installation and Configuration

After installing the engine, you can Configure Engines, such as log levels, add/remove servers to a load-balancing group, use as a web proxy, etc. You can also
Manage Engines, such as getting logs, add/remove engines, delete engines, remove engines, etc.

18.2 | Engine Installation

Abstract

Install, deploy and configure Cortex XSIAM engines.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 962/1003
5/8/24, 9:18 AM PDF Export

You can install engines on all Linux and Windows machines. Although engines are intended for Linux operating systems, they can be used on Windows, but
Windows machines must be configured to run Linux containers. Docker/Podman needs to be installed before installing an engine. If you are using the Shell
installer for an engine, Docker/Podman is installed automatically.

Engine Hardware Requirements

If your hard drive is partitioned, we recommend a minimum of 35 GB for the /var partition.

Component Dev Environment Minimum Production Minimum

CPU 8 CPU cores 16 CPU cores

Memory 16 GB RAM 32 GB RAM

Storage 50 GB 50 GB (if partitioned, 35 GB for /var)

Operating System Requirements

You can deploy a Cortex XSIAM engine on the following operating systems:

Operating System Supported Versions

CentOS 7.x

Ubuntu 18.04, 20.04, 22.04

RHEL 8.0, 8.1, 8.2, 8.3, 8.4, 8.5, 8.6, 8.7, 8.8, 9.0

Oracle Linux 7.x

Amazon Linux 2

NOTE:

Centos 8.x reached End of Life (EOL) on December 31, 2021, and is no longer a supported operating system.

Engine Required URLs

You need to allow the following in the URLs for Cortex XSIAM engines to operate properly.

The endpoint URL is: wss://api-<tenant domain>/xsoar/d1ws

FUNCTION SERVICE PORT DIRECTION

Integrations Integration-specific ports Outbound

Engine connectivity HTTPS 443 (configurable) Outbound

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 963/1003
5/8/24, 9:18 AM PDF Export

FUNCTION SERVICE PORT DIRECTION

Docker https://registry-1.docker.io 443 Outbound

https://registry.fedoraproject.org

https://registry.access.redhat.com

https://registry.centos.org

https://docker.io

https://registry.docker.io

https://auth.docker.io

This URL may change according to

Docker’s discretion.

https://production.cloudflare.docker.com

This URL may change according to

Docker’s discretion.

Engine Installation Types

Cortex XSIAM supports the following file types for installation on the engine machine:

Shell: For all Linux deployments, including Ubuntu, SUSE, RHEL, etc, except CentOS 7.x Automatically installs Docker/Podman, downloads
Docker/Podman images, enables remote engine upgrade, and allows installation of multiple engines on the same machine.

The installation file is selected for you. Shell installation supports the purge flag, which by default is false.

NOTE:

When upgrading a Shell type engine, you can use the Upgrade Engine feature in the Engines page. For CentOS 7 or Amazon Linux 2 type engines,
you need to upgrade these engine types using a zip type engine and not use the Upgrade Engine feature.

If you use the Shell installer, Docker/Podman is automatically installed. We recommend using Linux and not Windows to be able to use the Shell
Installer which installs all dependencies.

DEB: For Ubuntu operating systems.

RPM: RHEL operating systems.

NOTE:

Use DEB and RPM installation when shell installation is not available. You need to install Docker or Podman and any dependencies. You need to install
Docker or Podman and any dependencies. If installing on CentOS v7 you need to install Mirantis Container Runtime (formerly Docker Engine -
Enterprise) or Red Hat's Docker distribution to run specific Docker dependent integrations and scripts.

Zip: Used for Windows and CentOS 7 machines.

Configuration: Configuration file for download. When you install one of the other options, this configuration file (d1.conf ) is installed on the engine
machine.

IMPORTANT:

For DEB/RPM and Windows engines, Python (including 3.x) and containerization platform (Docker/Podman) must be installed and configured. For Docker or
Podman to work correctly on an engine, IPv4 forwarding must be enabled.

18.2.1 | Install an Engine

Topic Not Found

18.2.2 | Engine Offline Installation

Abstract

Install a Cortex XSIAM engine offline when you don’t have access to the Internet (tested on RHEL v8).

Use these instructions to install an engine on a machine without internet connectivity.

On a machine that has internet access, you need to download dependencies, docker images, and from the Cortex XSIAM tenant, the engine installation files.
You then need to transfer and install the files to the machine without internet access.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 964/1003
5/8/24, 9:18 AM PDF Export

Download Dependencies for Offline Installation

Install the following top level dependencies according to your operating system. These dependencies may be dependent upon other OS libraries.

NOTE:

Always verify that your dependencies are updated and take into account that they might change across releases.

RPM Dependencies

The following dependencies are required for Red Hat and CentOS deployments.

systemd

xmlsec1

xmlsec1-openssl

rpm-build

libcap

dnf-utils

file

fontconfig

expat

libpng

freetype

git

makeself

Run the following commands:

sudo yum check update

sudo yum install <name of the dependency>

(Red Hat v8 & above) If using Podman, you need to run:

sudo yum -y install slirp4netns fuse-overlayfs

sudo yum -y module install container-tools

Debian Dependencies

The following dependencies are required for Debian and Ubuntu deployments:

systemd

xmlsec1

rpm

libcap2-bin

file

libfontconfig1

libfreetype6

git

makeself

Run the following commands

sudo apt-get update

sudo apt-get install <name of the dependency>

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 965/1003
5/8/24, 9:18 AM PDF Export

Download Docker Images Offline

To download docker images you need to use the download_packs_and_docker_images script to download the docker image according to the content pack
integration you want to use, such as AWS-ILM, Cybereason, EWS, etc.

The download_packs_and_docker_images script enables you to download the latest content packs Docker images in a zip folder to your machine. The script is
located in the Utils folder in the GIT Content repository. If you do not have access to the GIT Content repository, you can download the script from here. For
detailed information and how to download the Docker images, see download packs offline.

Install an Engine Offline

1. On a machine with internet access, download the following:

a. Dependencies for your deployment type.

b. Relevant Docker images.

2. In the Cortex XSIAM tenant, download the engine installation file.

1. Select Settings → Configurations → Data Broker → Engines → Create New Engine.

2. In the Engine Name field, add a meaningful name for the engine.

3. Select one of the installer types from the dropdown list.

For Linux systems it is recommended to use the Shell installer.

4. (Optional) If you want to add the engine to a load balancing group, from the dropdown list, select the group you want to add.

The dropdown list only appears after you have created and connected an engine and created a load balancing group. To add the engine to a new
group, select Add new group from the dropdown list.

The engine cannot be used as an individual engine and does not appear when configuring an engine from the dropdown list.

5. (Optional) (Shell only) Select the checkbox to enable multiple engines to run on the same machine.

If you have an existing engine, you did not select the checkbox, and you want to install another engine on the same machine, you need to delete the
existing engine.

6. (Optional) Add any required configuration in JSON format.

7. Click Create New Engine.

3. On the machine you want to install the engine, do the following:

a. Transfer the files downloaded in steps 1 and 2.

b. Verify that the required dependencies in step 1a is installed successfully by running one of the following commands.

(Red Hat or CentOS) repoquery -a --installed

(Ubuntu or Debian) apt list --installed

c. Install the engine.

1. Grant execution permission by running the following command:

chmod +x /<engine-file-path>

2. Install the engine by running the following command:

sudo ./d1-<engine-name>-<XSIAM-version>-xxxxxxx.sh -- -tools=false -do-not-start-engine=true

For example, sudo ./d1-engine1-8.35-318874.sh -- -tools=false -do-not-start-engine=true

If you receive a permissions denied error, it is likely that you do not have permission to access the /tmp directory.

d. (Red Hat v8 & above) If you have not already done so, install and configure Podman, by following the steps in Migrate From Docker to Podman
(from step 2 onwards).

e. Load the Docker images that you downloaded in step 1b, by doing one of the following:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 966/1003
5/8/24, 9:18 AM PDF Export

(Ubuntu, Debian, Red Hat v7 & below, or CentOS v7 & below) Run the following command:

sudo docker load -i <YOUR_DOCKER_FILE>.zip

(Red Hat v8 & above) Do the following:

1. Ensure that the docker file has demisto:demisto ownership.

2. Ensure that you are in the root directory (cd /).

3. Run the following commands:

sudo -su demisto

podman load -i <YOUR_DOCKER_FILE>.zip

4. (Optional) To verify that images are able to run, use the podman images command. You can also run the podman images -q
"demisto/python:1.3-alpine" command to validate specific images and identify any issues.

4. Start the engine, by running the following command:

sudo systemctl start d1

NOTE:

For multiple engines the d1 service name may differ.

5. (Optional) After installation has completed, do the following:

a. Confirm that the engine status is active, by running the systemctl status d1 command.

b. Validate that the engine is connected and running by going to Settings → Configurations → Data Broker → Engines.

c. Run the engine on a sample integration. For example, go to Settings → Configurations → Data Collection → Automation & Feed Integrations and
search for the Hello World (Community Contribution) integration. Add or edit the instance and in the Run on field, select the engine.

d. In an Alert War Room, run a simple command to test that the engine is working properly using the integration.

For example, !helloworld-say-hello name"Mamba"

18.2.3 | Docker

Abstract

Cortex XSIAM Docker installation, configuration, security, and troubleshooting guides.

Docker is a software framework for building, running, and managing containers.

NOTE:

This section is relevant when installing an engine.

Cortex XSIAM maintains a repository of Docker images, available in the Docker hub under the Cortex organization. You can also access the Docker images
through the Cortex Container Registry.

Each Python/PowerShell script or integration has a specific Docker image listed in the YAML file. When the script or integration runs, if the specified Docker
image is not available locally, it is downloaded from the Docker hub or the Cortex Container Registry. The script or integration then runs inside the Docker
container. For more information on Docker, see the Docker documentation and Using Docker.

NOTE:

Docker images can be downloaded together with their relevant content packs, for offline installation.

18.2.3.1 | Install Docker

Abstract

Install Docker on engines and troubleshoot the installation.

Docker is required for engines to run Python/Powershell scripts and integrations in a controlled environment.

If you use the Shell installer to install an engine, Docker is automatically installed. If using DEB and RPM installations, you need to install Docker or Podman
before installing an engine. The engine uses Docker to run Python scripts, PowerShell scripts, and integrations in a controlled environment. By packaging
libraries and dependencies together, the environment remains the same and scripts and integrations are not affected by different server configurations.

Cortex XSIAM supports the latest Docker Engine release from Docker and the following corresponding supported Linux distributions:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 967/1003
5/8/24, 9:18 AM PDF Export

5.3.15 and later

5.4.2 and later

5.5 and later

These Linux distributions include their own Docker Engine package. In addition, older versions of Docker Engine released within the last 12 months are
supported unless there is a known compatibility issue with a specific Docker Engine version. In case of a compatibility issue, Cortex XSIAM will publish an
advisory notifying customers to upgrade their Docker Engine version.

You can use a version that is not supported. However, when encountering an issue that requires Customer Support involvement, you may be asked to upgrade
to a supported version before assistance can be provided.

Docker Installation by Operating System

If you need to install Docker before installing an engine, use the following procedures.

Red Hat

Ubuntu

Amazon Linux

Oracle Linux

There are two options for CentOS. The first option is Docker CE. To use Docker CE, install docker CE, configure Docker to start on boot, and Update
Container-Selinux. The second option is the CentOS Docker distribution. To use the CentOS Docker distribution, follow the instructions in Install Docker
Distribution for Red Hat on an Engine.

NOTE:

For CentOS v7, you need Mirantis Container Runtime (formerly Docker Engine - Enterprise) or Red Hat's Docker distribution to run specific Docker-
dependent integrations and scripts. For more information, see Install Docker Distribution for Red Hat on an Engine.

If you wish to use the Mirantis Container Runtime (formerly Docker Engine - Enterprise) follow the deployment guide for your operating system distribution.

18.2.3.2 | Change the Docker Installation Folder

Abstract

Instructions for changing the default Docker folder.

The /var/lib/docker/ folder is the default Docker folder for Ubuntu, Fedora, and Deblan in a standard engine installation.

To change the Docker folder:

1. Stop the Docker daemon.

sudo service docker stop

2. Create a file called daemon.json under the /etc/docker directory with the following content:

{
"data-root": "<path to your Docker folder>"
}

3. Copy the current data directory to the new one.

sudo rsync -aP /var/lib/docker/ <path to your Docker folder>

4. Rename the old docker directory.

sudo mv /var/lib/docker /var/lib/docker.bkp

5. After confirming that the change was successful, you can remove the backup file.

sudo rm -rf /var/lib/docker.bkp

6. Start the Docker daemon.

sudo service docker start

18.2.3.3 | Update Container-Selinux

Abstract

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 968/1003
5/8/24, 9:18 AM PDF Export

Update your container-selinux version.

When installing Docker, if you receive the message Requires: container-selinux >= 2.9, you need to install a newer version of container-selinux.

1. Go to CentOS Packages.

2. Find the latest version of container-selinux and copy the URL package.

3. Run the following command:

sudo yum install -y <copied container-selinux url

4. Install the latest version by running the following command (assuming the latest version is 2.74-1):

sudo yum install -y http://mirror.centos.org/centos/7/extras/x86_64/Packages/container-selinux-2.74-1.el7.noarch.rpm

18.2.3.4 | Install Docker Distribution for Red Hat on an Engine

Abstract

Install Docker distribution for Red Hat on CentOS v7.

Red Hat maintains its own package of Docker, which is the version used in OpenShift Container Platform environments, and is available in the RHEL Extras
repository. This procedure is relevant for CentOS v7.

NOTE:

CentOS v7 provides a similar docker distribution package as part of the CentOS Extras repository.

If running RHEL v8 or higher, the engine installs Podman packages and configures the operating system to enable Podman in rootless mode.

For more information about the different packages available to install on Red Hat, see the Red Hat Knowledge Base Article (requires a Red Hat subscription to
access).

1. Install Red Hat’s Docker package.

2. Run the following commands.

systemctl enable docker.service

systemctl restart docker.service

3. Change ownership of the Docker daemon socket so members of the dockerroot user group have access.

a. Edit or create the file /etc/docker/daemon.json.

b. Enable OS group dockerroot access to Docker by adding the following entry to the /etc/docker/daemon.json: "group": "dockerroot"file.
For example:

{ "group": "dockerroot" }

c. Restart the Docker service by running the following command.

systemctl restart docker.service

d. Engine Installation

e. After the engine is installed, run the following command to add the demisto os user to the dockerroot os group (Red Hat uses dockerroot group
instead of docker).

usermod -aG dockerroot demisto

f. Restart the engine.

4. Set the required SELinux permissions.

The Cortex XSIAM engine uses the /var/lib/demisto/temp directory (with subdirs) to copy files and receive files from running Docker containers. By
default, when SELinux is in enforcing mode directories under /var/lib/ it cannot be accessed by docker containers.

a. To allow containers access to the /var/lib/demisto/temp directory, you need to set the correct SELinux policy type, by typing the following
command.

chcon -Rt svirt_sandbox_file_t /var/lib/demisto/temp

b. ( Optional) Verify that the directory has the container_file_t SELinux type attached by running the following command.

ls -d -Z /var/lib/demisto/temp

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 969/1003
5/8/24, 9:18 AM PDF Export

c. Configure label confinement to allow Python and PowerShell containers to access other script folders.

In the d1.conf file, set the following parameters:

Key Value

For Python containers python.pass.extra.keys --security-opt=label=level:s0:c100,c200

For PowerShell containers powershell.pass.extra.keys --security-opt=label=level:s0:c100,c200

d. Open any incident and in the incident War Room CLI, run the /reset_containers command.

18.2.3.5 | Docker Image Security

Abstract

Information about Cortex XSIAM Docker image security practices.

The build process for Cortex XSIAM Docker images are fully open source and available for review. The project contains the source Docker files used to build the
images and the accompanying files. Cortex XSIAM uses only the secure Docker Hub registry for its Docker images. You can view the Docker trust information
for each image at the image info branch.

NOTE:

We automatically update our open source Docker images and their accompanying dependencies (OS and Python). Examples of automatic updates can
be viewed on GitHub.

We maintain Docker image information which includes information on Python packages, OS packages and image metadata for all our Docker images.
Data image information is updated nightly.

All of our images are continuously scanned using Prisma Cloud and an additional third-party scanner. We evaluate all critical/high findings and actively
work to prevent and mitigate security vulnerabilities.

Cortex XSIAM ensures container images are fully patched and do not contain unnecessary packages. Patches and dependencies are applied
automatically via our open source docker files build project.

18.2.3.6 | Configure Docker Pull Rate Limit

Abstract

Configure the Docker pull rate limit on public images. Create a Docker user account and receive higher pull limit.

Docker enforces a pull rate limit on public images. The limit is based on an IP address or as a logged-in Docker hub user. The default limit (100 pulls per 6
hours) is usually high enough for Cortex XSIAM's use of Docker images, but the rate limit may be reached if using a single IP address for a large organization
(behind a NAT). If the rate limit is reached, the following error message is issued:

Error response from daemon: toomanyrequests: You have reached your pull rate limit. You may increase the limit by authenticating
and upgrading: https://www.docker.com/increase-rate-limit.

To increase the limit, take the following steps.

1. Sign up a free user in the Docker hub.

The pull limit is higher for a registered user (200 pulls per 6 hours).

2. Authenticate the user on the engine machine by running the following command.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 970/1003
5/8/24, 9:18 AM PDF Export

sudo -u demisto docker login

3. (Optional) Instead of manually logging in to Docker to pull images, you can edit the Docker config file to use credentials from the file or from a credential
store.

18.2.3.7 | Docker FAQs

Abstract

Frequently asked questions (FAQ) about Docker installation, configuration, and security for Cortex XSIAM.

Does Cortex XSIAM use COPY or ADD for building images?

Cortex XSIAM uses COPY for building images. The COPY instruction copies files from the local host machine to the container file system. Cortex XSIAM
does not use the ADD instruction, which could potentially retrieve files from remote URLs and perform operations such as unpacking, introducing potential
security vulnerabilities.

Should the --restart flag be used?

The --restart flag should not be used. Cortex XSIAM manages the lifecycle of Docker images and restarts images as needed.

Can we restrict containers from acquiring additional privileges by setting the no-new-privileges option?

Cortex XSIAM does not support the no-new-privileges option. Some integrations and scripts may need to change privileges when running as a non-root
user (such as Ping).

Can we apply a daemon-wide custom seccomp profile?

The default seccomp profile from Docker is strongly recommended. The default seccomp profile provides protection as well as wide application
compatibility. While you can apply a custom seccomp profile, Cortex XSIAM cannot guarantee that it won't block system calls used by an integration or
script. If you apply a custom seccomp profile, you need to verify and test the profile with any integrations or scripts you plan to use.

Can we use TLS authentication for docker daemon configuration?

TLS authentication is not used, because Cortex XSIAM does not use docker remote connections. All communication is done via the local docker IPC
socket.

How do we set the logging level to info?

Set the log level in the Docker daemon configuration file.

Can we restrict Linux kernel capabilities within containers?

The default Docker settings (recommended) include 14 kernel capabilities and exclude 23 kernel capabilities. Refer to Docker’s full list of runtime
privileges and Linux capabilities.

You can further exclude capabilities via advanced configuration, but will first need to verify that you are not using a script that requires the capability. For
example, Ping requires NET_RAW capability.

Is the Docker health check option implemented at runtime?

The Cortex XSIAM tenant monitors the health of the containers and restarts/terminates containers as needed. The Docker health check option is not
needed.

Can we enable live restore?

Live restore is not used. Cortex XSIAM uses ephemeral docker containers. Every running container is stateless by design.

Can we restrict network traffic between containers?

Cortex XSIAM does not disable inter-container communication by default, as there are use cases where this might be needed. For example, a script
communicating with a long running integration which listens on a port, may require inter-container communication. If inter-container communication is not
required, it can be disabled by modifying the Docker daemon configuration.

Can we enable user namespace remapping?

Cortex XSIAM does not support user namespace remapping.

How do we configure auditing for Docker files and directories?

Auditing is an operating system configuration, and can be enabled in the operating system settings. Cortex XSIAM does not change the audit settings of
the operating system.

Does Cortex XSIAM map privileged ports?

Cortex XSIAM does not map privileged ports (TCP/IP port numbers below 1024).

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 971/1003
5/8/24, 9:18 AM PDF Export

Does Cortex XSIAM allow privileged execution?

Cortex XSIAM does not allow privileged execution of Docker commands.

Does Cortex XSIAM run SSH within containers?

Cortex XSIAM does not run SSH within containers.

Does Cortex XSIAM change the ownership of the socket?

Cortex XSIAM does not change the ownership of the socket.

Can we disable the userland proxy?

If the kernel supports hairpin NAT, you can disable docker userland proxy settings by modifying the Docker daemon configuration.

Does Cortex XSIAM support the AppArmor profile?

Cortex XSIAM supports the default AppArmor profile (only relevant for Ubuntu with AppArmor enabled).

Does Cortex XSIAM support the SELinux profile?

Cortex XSIAM supports the default SELinux profile (only relevant for RedHat/CentOS with SELinux enabled).

How does Cortex XSIAM handle secrets management?

For Docker swarm services, a secret is a blob of data, such as password, SSH private keys, SSL certificates, or other piece of data that should not be
transmitted over a network or stored unencrypted in a Docker file or in your application’s source code. Cortex XSIAM manages integration credentials
internally. It also supports using an external credentials service such as CyberArk.

18.2.4 | Podman

Abstract

Run Podman containers instead of Docker for RHEL v8.

Podman is a daemonless container engine for developing, managing, and running OCI Containers on the Linux System. Containers can either be run as root or
in rootless mode.

If you use the Shell installer to install an engine, Cortex XSIAM automatically detects the container management type based on the operating system. For
example, if your operating system is running RHEL v8 and higher, Cortex XSIAM installs Podman packages and configures the operating system to enable
Podman in rootless mode.

NOTE:

When upgrading an engine, the engine keeps the previously used container management type (regardless of distribution version).

By default, Podman uses the $HOME/.local/share/containers/storage directory. To use a different directory for container storage, edit the Podman config
file located at /home/demisto/.config/containers/storage.conf. If the file does not exist, create it and change the ownership:

cp /etc/containers/storage.conf /home/demisto/.config/containers

chown demisto:demisto /home/demisto/.config/containers/storage.conf

To set a different directory for container storage, change the key: rootless_storage_path in the storage.conf file. For example,
rootless_storage_path=/var/lib/containers/$USER/storage

The new storage directory needs to be owned by the demisto user, otherwise they will be denied access to it. To assign the demisto user ownership of the new
storage directory, on the Linux command line, run chown -R demisto:demisto <NEW-LOCATION>.

Do not use NAS storage for the $HOME directory. The directory needs to be a local directory for Podman to work.

TIP:

We recommend reserving 150 GB for container storage, either in the /home partition or a different storage directory that you have set using the
rootless_storage_path key.

If using PowerShell integrations, you may need to configure the default SELinux policy as Podman can affect processes which mmap to /dev/zero.

Docker Hardening Guidelines

Docker hardening guidelines can be applied to Podman, with the exception of Limit Available Memory, Limit Available CPU, and Limit PIDS.

18.2.4.1 | Install Podman

Abstract

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 972/1003
5/8/24, 9:18 AM PDF Export

Install Podman on engines for RHEL v8 or later.

This procedure for engines running on RHEL 8 or later. It may not work for other OS types.

NOTE:

Do not use NAS storage for the $HOME directory. The directory needs to be a local directory for Podman to work.

1. Install Podman with related packages by typing the following commands:

sudo yum -y install slirp4netns fuse-overlayfs

sudo yum -y module install container-tools

2. Run the following commands:

sudo touch /etc/subuid /etc/subgid

sudo mkdir -p /home/demisto

sudo chown demisto:demisto /home/demisto

3. Configure the unqualified-search-registries used by Podman.

Podman by default uses the fedoraproject.org, redhat.com, centos.org, and docker.io unqualified search registries. Since Cortex XSIAM images use only
the docker.io registry, you can speed up download times for container images by setting unqualified-search-registries to just docker.io.

a. Create or edit the /home/demisto/.config/containers/registries.conf config file.

b. In the file, set unqualified-search-registries = ["docker.io"].

NOTE:

If you edit the file with the root user, make sure to set the demisto user as file owner by running chown demisto:demisto
/home/demisto/.config/containers/registries.conf

4. Change the subuids and subgids by running the following command:

sudo usermod --add-subuids 200000-265535 --add-subgids 200000-265535 demisto

5. Set the net.ipv4.ping-group-range, by typing the following commands:

sudo sh -c "echo 'net.ipv4.ping_group_range=0 2000000' > /etc/sysctl.d/demisto-ping.conf"

sudo sysctl -w "net.ipv4.ping_group_range=0 2000000"

6. As root user, edit the following config file:

/usr/local/demisto/d1.conf

7. Change the "container.engine.type": "docker"to “podman”.

If this line does not exist, add the following line to the file:

"container.engine.type": "podman"

"Server": {
"HttpsPort": "443",
"ProxyMode": true
},
"container": {
"engine": {
"type": "podman"
}
},
"db": {
"index": {
"entry": {
"disable": true

18.2.4.2 | Migrate From Docker to Podman

Abstract

Switch from Docker to Podman when installing an engine for RHEL 8 or later.

Although Podman is set up automatically in an engine installation, it is possible to migrate from Docker to Podman in an existing engine.

NOTE:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 973/1003
5/8/24, 9:18 AM PDF Export

This procedure is intended for RHEL 8 or later. It may not work for other operating system types.

Do not use NAS storage for the $HOME directory. The directory needs to be a local directory for Podman to work.

1. Install Podman with related packages by typing the following commands:

sudo yum -y install slirp4netns fuse-overlayfs

sudo yum -y module install container-tools

2. Run the following commands:

sudo touch /etc/subuid /etc/subgid

sudo mkdir -p /home/demisto

sudo chown demisto:demisto /home/demisto

3. Configure the unqualified-search-registries used by Podman.

Podman by default uses the fedoraproject.org, redhat.com, centos.org, and docker.io unqualified search registries. Since Cortex XSIAMimages use only
the docker.io registry, you can speed up download times for container images by setting unqualified-search-registries to just docker.io.

1. Create or edit the /home/demisto/.config/containers/registries.conf file.

2. In the file, set unqualified-search-registries = ["docker.io"].

NOTE:

If you edit the file with the root user, make sure to set the demisto user as file owner by running chown demisto:demisto
/home/demisto/.config/containers/registries.conf.

4. Change the subuids and subgids:

sudo usermod --add-subuids 200000-265535 --add-subgids 200000-265535 demisto

5. Migrate existing containers to Podman:

sudo sh -c "podman system migrate"

6. Set the net.ipv4.ping-group-range, by typing the following commands:

sudo sh -c "echo 'net.ipv4.ping_group_range=0 2000000' > /etc/sysctl.d/demisto-ping.conf"

sudo sysctl -w "net.ipv4.ping_group_range=0 2000000"

7. As root user, edit the /usr/local/demisto/d1.conf file

8. Change the "container.engine.type": "docker" to "podman".

If this line does not exist, add the following line to the file:

"container.engine.type": "podman"

"Server": {
"HttpsPort": "443",
"ProxyMode": true
},
"container": {
"engine": {
"type": "podman"
}
},
"db": {
"index": {
"entry": {
"disable": true

9. Restart the service:

sudo systemctl restart d1

18.3 | Configure Engines

Abstract

Configure Cortex XSIAM engines to change the number of workers, access communication tasks, notify users if engine disconnects, and remove server from
group.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 974/1003
5/8/24, 9:18 AM PDF Export

You can Edit the Engine Configuration File either by modifying the d1.conf file on the engine or in when managing engines. You can only configure an engine in
if you have installed the engine using the shell installer.

You can configure the server and engine to do the following:

Configure Docker Hardening

Configure an Engine to Use Custom Certificates

Configure the Engine to Use a Web Proxy

Configure the Engine to Call the Server Without Using a Proxy

Use NGINX as a Reverse Proxy to the Engine

18.3.1 | Edit the Engine Configuration File

Abstract

Edit engine configurations by modifying d1.conf or specific properties in the JSON formatted configuration section.

You can edit the engine configuration by either modifying the d1.conf file on the engine, or in Cortex XSIAM by modifying specific properties in the JSON
formatted configuration dialog box (Shell installations only).

1. Modify the d1.conf file.

a. On the machine on which you installed the engine, navigate to the d1.conf file:

Installation Type Location

RPM, DEB, Shell /usr/local/demisto

If using multiple engines, the location is /usr/local/demisto/name of the engine>. For example,
/usr/local/demisto/d1_e1

ZIP Same folder as the binary.

b. Modify the file as required. See Common Properties When Editing an Engine Configuration.

You can also Configure the Engine to Use a Web Proxy.

2. Modify the configuration in Cortex XSIAM.

Ensure that the data is in JSON format. The properties that you specify override the values defined in the d1.conf file. A use case for modifying the
engine configuration is if you want to generate engine logs for a specific log level.

a. From the engines table, select the engine for which you want to modify the configuration.

b. Click Edit Configuration.

c. In the JSON formatted configuration dialog box, modify the properties as required. For more information, see Common Properties When Editing an
Engine Configuration.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 975/1003
5/8/24, 9:18 AM PDF Export

18.3.2 | Common Properties When Editing an Engine Configuration

Abstract

Edit the engine configuration by changing the common properties in the JSON formatted section of the d1.config file.

The following table describes the common properties when editing an engine configuration using the d1.conf file (located by default at /usr/local/demisto/)
or in the JSON formatted configuration dialog box in Cortex XSIAM.

Property Type Values Edit

http_proxy String The IP address of the HTTP proxy through which The engine d1.conf
the engine communicates. file.

https_proxy String The IP address of the HTTP/s proxy through which The engine d1.conf
the engine communicates. file.

LogLevel String debug The engine d1.conf

file or in the JSON
info formatted
configuration dialog
warning
box.

EngineURLs String array An array of tenant addresses to which the engine The engine d1.conf
tries to connect. If you change the tenant URL, file.
you need to update this parameter.

LogFile String Path to the d1.log file. If you change the name or The engine d1.conf
location of the d1.log file, you need to update this file.
parameter.

18.3.3 | Docker Hardening Guide

Abstract

Use the Docker Hardening Guide to configure the Cortex XSIAM settings when running Docker containers.

This guide describes the recommended engine settings for securely running Docker containers. For each engine that you want to apply Docker hardening, you
need to edit the engine configuration file to include the Docker hardening parameters.

When editing the configuration file, you can limit container resources, open file descriptors, limit available CPU, etc. For example, add the following keys to the
configuration file:

{"docker.run.internal.asuser": true,"limit.docker.cpu": true,"limit.docker.memory": true,"python.pass.extra.keys": "--pids-

limit=256##--ulimit=nofile=1024:8192"}

TIP:

We recommend reviewing the Docker Network Hardening guide, before changing any parameters in the configuration file.

To securely run Docker containers, it is recommended to use the latest Docker version.

You can Check Docker Hardening Configurations to verify that the Docker container has been hardened according to the recommended settings.

In the configuration file, you can update the following:

Action Description

Configure Docker Images Fine tune settings for Docker images according to the Docker image name.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 976/1003
5/8/24, 9:18 AM PDF Export

Action Description

Limit Container Resources Protects the engine machine from a container using too many system resources.

Limit Available Memory We recommend limiting available memory for each container to 1 GB.

Limit Available CPU on Your It is recommended to limit each container to 1 CPU.

System

Configure the PIDs Limit It is recommend limiting each container to 256 PIDs. This value is sufficient for using threads and sub-processes, and
protects against a fork bomb.

Configure the Open File It is recommend using a soft/hard limit of 1024/8192 filed descriptors for each container process.
Descriptors Limit

NOTE:

These settings can also be applied to Podman, with the exception of limiting available memory, limiting available CPU, and limiting PIDS.

18.3.3.1 | Configure Docker Images

Abstract

Apply more specific settings to Docker images by adding the advanced configuration key to the engine configuration file.

You can apply more specific fine tuned settings to Docker images, according to the Docker image name or the Docker image name including the image tag. To
apply settings to a Docker image name, add the advanced configuration key to the engine configuration file.

NOTE:

If you apply Docker image specific settings, they will be used instead of the general python.pass.extra.keys setting. This overrides the general memory
and CPU settings, as needed.

1. Edit the Engine Configuration File.

2. Add the following key to apply settings to a Docker image name.

"python.pass.extra.keys.<image_name>"

For example, "python.pass.extra.keys.demisto/dl". To apply settings to a Docker image name including the image tag, use
"python.pass.extra.keys.<image_name>": "<image_tag>". For example, "python.pass.extra.keys.demisto/dl": "1.4".

To set the Docker images demisto/dl(all tags) to use a higher max memory value of 2g and to remain with the recommended PIDs and ulimit, add the
following to the configuration file:

"python.pass.extra.keys.demisto/dl": "--memory=2g##--ulimit=no- file=1024:8192##--pids-limit=256"

3. Save the changes.

4. Restart the demisto service on the engine machine.

sudo systemctl start d1

(Ubuntu/DEB) sudo service d1 restart

18.3.3.2 | Check Docker Hardening Configurations

Abstract

Check Docker hardening configurations on an engine by running the !DockerHardeningCheck command in the Incident/Alert War Room CLI.

Check your Docker hardening configurations on an engine by running the !DockerHardeningCheck command in the Incident/Alert War Room CLI. The results
show the following:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 977/1003
5/8/24, 9:18 AM PDF Export

Non-root User

Memory

File Descriptors

CPUs

PIDs

Before running the command, ensure that your engine is up and running.

1. Update the DockerHardeningCheck script to run on the engine.

NOTE:

By default, the DockerHardeningScript runs on the Cortex XSIAM tenant.

a. Go to Incident Response → Automation → Scripts → DockerHardeningCheck → Settings.

b. In the Run on field select Single engine and from the drop-down list, select the engine you want to run the script.

c. Save the script.

2. Verify the Docker container has been hardened according to recommended settings, in the Incident/Alert War Room CLI, run the
!DockerHardeningCheck command.

18.3.3.3 | Run Docker with Non-Root Internal Users

Abstract

Run Docker with non-root internal users and for containers that do not support non-root internal users.

For additional security isolation, it is recommended to run Docker containers as non-root internal users. This follows the principle of least privilege.

Configure the engine to execute containers as non-root internal users.

a. Edit the Engine Configuration File.

b. Add the following key:

"docker.run.internal.asuser": true

c. For containers that do not support non-root internal users, add the following key:

"docker.run.internal.asuser.ignore" : "A comma separated list of container names. The engine matches the container
names according to the prefixes of the key values>"

For example, "docker.run.internal.asuser.ignore"="demisto/python3:","demisto/python:"

The engine matches the key values for the following containers:

demisto/python:1.3-alpine
demisto/python:2.7.16.373
demisto/python3:3.7.3.928
demisto/python3:3.7.4.977

The : character should be used to limit the match to the full name of the container. For example, using the : character does not find
demisto/python-deb:2.7.16.373.

d. Save the changes.

e. Restart the demisto service on the engine computer.

sudo systemctl start d1

(Ubuntu/DEB) sudo service d1 restart

18.3.3.4 | Configure the Memory Limit Support Without Swap Limit Capabilities

Abstract

Configure the container memory limit support without swap limit capabilities.

When a container exceeds the specified amount of memory, the container starts to swap. Not all Linux distributions have the swap limit support enabled by
default.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 978/1003
5/8/24, 9:18 AM PDF Export

Red Hat and CentOS distributions usually have swap limit support enabled by default.

Debian and Ubuntu distributions usually have swap limit support disabled by default.

To check if your system supports swap limit capabilities, in the engine machine run the following command:

sudo docker run --rm -it --memory=1g demisto/python:1.3-alpine true

If swap limit capabilities is enabled, Configure the Memory Limitation . To test the memory, see Test the Memory Limit.

If you see the WARNING: Your kernel does not support swap limit capabilities or the cgroup is not mounted. Memory limited without
swap. message in the output (the message may vary between Docker versions), you have two options:

Configure swap limit capabilities by following the Docker documentation.

Follow the procedure set out below.

To protect the host from a container using too many system resources (either because of a software bug or a DoS attack), limit the resources available for each
container. In the engine configuration file, some of these settings are set using the advanced parameter: python.pass.extra.keys. This key receives as a
parameter full docker run options, separated with the ## string.

If you see the WARNING: No swap limit support you can configure memory support without swap limit capabilities.

To set the docker run option --memory-swap option to -1 (disables swap memory enforcement):

1. Edit the Engine Configuration File.

2. Add the following key:

"python.pass.extra.keys": "--memory=1g##--memory-swap=-1"

If you have the python.pass.extra.keys already set up with a value, add the vlaue after the ## separator.

3. Save the changes.

4. Restart the demisto service on the engine machine.

sudo systemctl start d1

(Ubuntu/DEB) sudo service d1 restart

18.3.3.5 | Configure the Memory Limitation

Abstract

Configure the memory limitation by adding a server configuration in Cortex XSIAM.

It is recommended limiting available memory for each container to 1 GB.

NOTE:

On CentOS 7.x distributions with Docker CE or EE with version 17.06 and later, ensure that your kernel fully supports kmem accounting or that it has been
compiled to disable kmem accounting. The kmem accounting feature in Red Hat’s Linux kernel has been reported to contain bugs, which cause kernel
deadlock or slow kernel memory leaks. This is caused by a patch introduced in runc, which turns on kmem accounting automatically when user memory
limitation is configured, even if not requested by the Docker CLI setting --kernel-memory (see: opencontainers/runc#1350). Users using Red Hat's
distribution of Docker based on version 1.13.1 are not affected as this distribution of Docker does not include the runc patch. For more information see Red
Hat’s Docker distribution documentation.

If you do not want to apply Docker memory limitations, due to the note above, you should explicitly set the advanced parameter: limit.docker.memory to
false.

If swap limit capabilities is enabled, in Cortex XSIAM configure the memory limitation using the following advanced parameters.

1. Edit the Engine Configuration File.

2. Add the following keys.

"limit.docker.memory": true, "docker.memory.limit": "1g"

3. Save the changes.

4. Restart the demisto service on the engine machine.

sudo systemctl start d1

(Ubuntu/DEB) sudo service d1 restart

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 979/1003
5/8/24, 9:18 AM PDF Export

18.3.3.6 | Test the Memory Limit

Abstract

Test the Docker memory limit by running a script in the Playground.

After configuring the memory limitation to the recommended 1 GB, you can test the memory limit in the playground.

1. Go toIncident Response → Automation Scripts and create a New Script.

2. In the Script Name field, type Test Memory.

3. Add the following script:

from multiprocessing import Process

import os

def big_string(size):
sys.stdin = os.fdopen(0, "r")
s = 'a' * 1024
while len(s) < size:
s = s * 2
print('completed creating string of length: {}'.format(len(s)))

size = 1 * 1024 * 1024 * 1024

p = Process(target=big_string, args=(size, ))
p.start()
p.join()
if p.exitcode != 0:
return_error("Return code from sub process indicates failure: {}".format(p.exitcode))
else:
print("Success allocating memory of size: {}".format(size))

4. From the SCRIPT SETTINGS dialog box, in the BASIC section, select the script to run on the Single engine and select the engine where you want to run
the script.

5. Save the script.

6. To test the memory limit, type !TestMemory.

The command returns an error when it fails to allocate 1 GB of memory.

18.3.3.7 | Limit Available CPU on Your System

Abstract

Limit the available CPU on your system for Docker.

Follow these instructions to set the advanced parameters to configure the CPU limit.

It is recommended limiting each container to 1 CPU.

1. Edit the Engine Configuration File.

2. Add the following keys:

"limit.docker.cpu": true, "docker.cpu.limit": "<CPU Limit>" (For example, 1.0. Default is 1.0).

3. Save the changes.

4. Restart the demisto service on the engine machine.

sudo systemctl start d1

(Ubuntu/DEB) sudo service d1 restart

18.3.3.8 | Configure the PIDs Limit

Abstract

Configure the PIDs limit by adding a server configuration for a Cortex XSIAM engine.

Configure the PIDs limit by setting the python.pass.extra.keys advanced parameter.

1. Edit the Engine Configuration File.

2. Add the following key:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 980/1003
5/8/24, 9:18 AM PDF Export

"python.pass.extra.keys": "--pids-limit=256"

3. Save the changes.

4. Restart the demisto service on the engine machine.

sudo systemctl start d1

(Ubuntu/DEB) sudo service d1 restart

18.3.3.9 | Configure the Open File Descriptors Limit

Abstract

Configure the open file descriptors limit by adding a server configuration in an engine.

You need to set the python.pass.extra.keys advanced parameter to configure the open file descriptors limit.

1. Edit the Engine Configuration File.

2. Type the following key.

"python.pass.extra.keys": "--ulimit=nofile=1024:8192"

3. Save the changes.

4. Restart the demisto service on the engine machine.

sudo systemctl start d1

(Ubuntu/DEB) sudo service d1 restart

18.3.3.10 | Docker Network Hardening

Abstract

Use the Docker network hardening guide to control network access.

Docker creates its own networking stack that enables containers to communicate with other networking endpoints. You can use iptables rules to restrict which
networking sources the containers communicates with. By default, Docker uses a networking configuration that allows unrestricted communication for
containers, so that containers can communicate with all IP addresses.

Block Network Access to the Host Machine

Integrations and scripts running within containers do not usually require access to the host network. For added security, you can block network access from
containers to services running on the engine machine.

1. Add the following iptables rule for each private IP on the tenant machine:

sudo iptables -I INPUT -s <IP address range> -d <host private ip address> -j DROP

For example, to limit all source IPs from containers that use the IP ranges 172.16.0.0/12, run sudo iptables -I INPUT -s 172.16.0.0/12 -d
10.18.18.246 -j DROP. This also ensures that new Docker networks which use addresses in the IP address range of 172.16.0.0/12 are blocked from
access to the host private IP. The default IP range used by Docker is 172.16.0.0/12. If you have configured a different range in Docker's daemon.json
config file, use the configured range. Alternatively, you can limit specific interfaces by using the interface name, such as docker0, as a source.

2. (Optional) To view a list of all private IP addresses on the host machine, run sudo ifconfig -a

Assign a Docker Network for a Docker Image

If your engine is installed on a cloud provider such as AWS or GCP, it is a best practice to block containers from accessing the cloud provider’s instance
metadata service. The metadata service is accessed via IP address 169.254.169.254. For more information about the metadata service and the data exposed,
see the AWS and GCP documentation

There are cases where you might need to provide access to the metadata service. For example, access is required when using an AWS integration that
authenticates via the available role from the instance metadata service. You can create a separate Docker network, without the blocked iptable rule, to be used
by the AWS integration’s Docker container. For most AWS integrations the relevant Docker image is: demisto/boto3py3

1. Create a new Docker network by running the following command:

sudo docker network create -d bridge -o com.docker.network.bridge.name=docker-metadata aws-metadata

2. Edit the Engine Configuration File.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 981/1003
5/8/24, 9:18 AM PDF Export

3. Add the following key.

"python.pass.extra.keys.demisto/boto3py3": "--network=aws-metadata"

4. Save the changes.

5. Restart the demisto service on the engine machine.

sudo systemctl start d1

(Ubuntu/DEB) sudo service d1 restart

6. Verify the configuration of your new Docker network:

sudo docker network inspect aws-metadata

Block Internal Network Access

In some cases, you might need to block specific integrations from accessing internal network resources and allow the integrations to access only external IP
addresses. This setting is recommended for the Rasterize integration when used to Rasterize untrusted URLs or HTML content, such as those obtained via
external emails. With internal network access blocked, a rendered page in the Rasterize integration cannot perform a SSRF or DNS rebind attack to access
internal network resources.

1. Create a new Docker network by running the following command:

sudo docker network create -d bridge -o com.docker.network.bridge.name=docker-external external

2. Block network access to the host machine for the new Docker network:

iptables -I INPUT -i docker-external -d <host private ip> -j DROP

3. Block network access to cloud provider instance metadata:

sudo iptables -I DOCKER-USER -i docker-external -d 169.254.169.254/32 -j DROP

4. Block internal network access:

sudo iptables -I DOCKER-USER -i docker-external -d 10.0.0.0/8 -j DROP

sudo iptables -I DOCKER-USER -i docker-external -d 172.16.0.0/12 -j DROP

sudo iptables -I DOCKER-USER -i docker-external -d 192.168.0.0/16 -j DROP

5. Edit the Engine Configuration File.

6. Add the following key to run integrations that use the demisto/chromium docker image with the Docker network external.

"python.pass.extra.keys.demisto/chromium": "--network=external"

7. Save the changes.

8. Restart the demisto service on the engine machine.

sudo systemctl start d1

(Ubuntu/DEB) sudo service d1 restart

9. Verify the configuration of your new Docker network:

sudo docker network inspect external

Persist Iptables Rules

By default, iptables rules are not persistent after a reboot. To ensure your changes are persistent, save the iptables rules by following the recommended
configuration for your Linux operating system:

Ubuntu

Red Hat and related operating system flavors

18.3.4 | Configure the Engine to Use a Web Proxy

Abstract

Configure an engine to use a web proxy by editing the d1.conf file.

The engine uses a web proxy if the following environment variables are set:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 982/1003
5/8/24, 9:18 AM PDF Export

http_proxy

https_proxy

If the environment variables are not set, or you wish to use a different settings than those specified in the environment variables, set the configuration with your
specific proxy details in the d1.conf file. For example:

{"http_proxy": "http://proxy.host.local:8080",
"https_proxy": "https://proxy.host.local:8443"}

18.3.5 | Configure the Engine to Call the Server Without Using a Proxy

Abstract

Configure an engine to call the server without using a proxy.

In some cases, due to specific environment architecture, you may need to configure the engine to use a proxy when working with integrations, but not use a
proxy when calling the Cortex XSIAM tenant.

1. On the computer where you have installed the engine, go to the directory for d1.conf file.

For RPM, DEB, Shell go to /usr/local/demisto.

2. Add the following configuration:

Key Value

engine.to.server.proxy false (default is true)

18.3.6 | Use NGINX as a Reverse Proxy to the Engine

Abstract

Use NGINX as a reverse proxy to the Cortex XSIAM engines.

NGINX can act as a reverse proxy that sits between internal applications and external clients, forwarding client requests to the appropriate application. Using
NGINX as a reverse proxy in front of the engine enables you to provide network segmentation where the proxy can be put on a public subnet (DMZ) while the
engine can be on a private subnet, only accepting traffic from the proxy. Additionally, NGINX provides a number of advanced load balancing and acceleration
features that you can utilize.

The following topics describe how to install NGINX, how to use a Self-Signed Certificate for non-production environments, and how to configure NGINX.

Install NGINX on the Engine

Generate a Certificate for NGINX

Configure NGINX on an Engine

Use Engines Through the NGINX Reverse Proxy

If you want to use an engine (d1) through the reverse proxy, you need to modify EngineURLs in the d1.conf file to point to the host and port the NGINX server
is listening on.

18.3.6.1 | Install NGINX on the Engine

Abstract

Install NGINX on Cortex XSIAM Red Hat/Amazon and Ubuntu Linux distributions.

You can install NGINX on the Red Hat/Amazon (yum) and Ubuntu Linux distributions. For full instructions and available distributions, see NGINX documentation.

1. On the engine machine, run one of the following commands according to your Linux system:

RedHat/Amazon: sudo yum install nginx

Ubuntu: sudo apt-get install nginx

2. (Optional) Verify the NGINX installation by running the following command:

sudo nginx -v

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 983/1003
5/8/24, 9:18 AM PDF Export

18.3.6.2 | Generate a Certificate for NGINX

Abstract

Generate a certificate for NGINX for non-production set ups.

You should not use self-signed certificates for production systems. It is recommended to use a properly signed certificate for production systems. These
instructions are intended only for non-production setups.

1. To use OpenSSL to generate a self-signed certificate, on the engine machine run the following command:

sudo openssl req -x509 -nodes -days 3650 -newkey rsa:2048 -keyout /etc/nginx/cert.key -out /etc/nginx/cert.crt

2. When prompted, complete the on-screen instructions to complete the required fields.

18.3.6.3 | Configure NGINX on an Engine

Abstract

Configure NGINX on a Cortex XSIAM engine.

Follow these instructions to configure NGINX on an engine.

1. Open the following NGINX configuration file with your preferred editor:

/etc/nginx/conf.d/demisto.conf

2. Use the following configuration template:

Replace DEMISTO_ENGINE with the appropriate hostname.

# Replace DEMISTO_ENGINE with the appropriate hostname. If needed, change port 443 to the port on which the engine is listening.

upstream demisto {
server DEMISTO_ENGINE:443;
}

# Uncomment to redirect http to https (optional)

# server {
# listen 80;
# return 301 https://$host$request_uri;
# }

server {
# Change the port if you want NGINX to listen on a different port
listen 443;

ssl_certificate /etc/nginx/cert.crt;
ssl_certificate_key /etc/nginx/cert.key;

ssl on;
ssl_session_cache builtin:1000 shared:SSL:10m;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4;
ssl_prefer_server_ciphers on;

access_log /var/log/nginx/demisto.access.log;

location / {

proxy_set_header Host $host;

proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;

proxy_pass https://demisto;
proxy_read_timeout 90;
}

location ~ ^/(websocket|d1ws|d2ws) {
proxy_pass https://demisto;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
proxy_set_header Origin "";
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}

3. Restart the NGINX server, by typing the following command:

sudo service nginx restart

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 984/1003
5/8/24, 9:18 AM PDF Export

4. Verify you can access the engine by browsing to the NGINX server host.

18.3.7 | Configure an Engine to Use Custom Certificates

Abstract

Replace the self-signed certificate for an engine with a valid CA certificate for communication tasks.

For communication tasks that go through an engine, you can replace the default self-signed certificate for the engine with your own certificate.

1. Find the two files created by the engine. The default location is /usr/local/demisto.

d1.key.pem

d1.cert.pem

2. Replace the contents of these files with your own certificates.

3. Change file owner to demisto:

chown -R demisto:demisto d1.key.pem

chown -R demisto:demisto d1.cert.pem

4. Set the file permissions:

chmod 600 d1.key.pem

chmod 644 d1.cert.pem

18.4 | Manage Engines

Abstract

Manage engines and load balancing groups.

You can manage engines and load-balancing groups by going to Settings → Configurations → Engines.

You can view engine names, hosts, status, connection, etc.

You can do the following:

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 985/1003
5/8/24, 9:18 AM PDF Export

Add/remove engines to the Load-Balancing Group.

You can only add the engine to the Load-Balancing group after you have connected the engine.

Create Load-Balancing Groups

When selecting Load-Balancing Group → Add to new group, you can create multiple Load-Balancing groups and decide which engines are part of each
group. It is useful to create separate Load-Balancing groups. For example,

Use separate Load-Balancing groups for different integrations and instances. Create Load-Balancing groups for certain tasks, which can help
segregate the infrastructure of critical integrations.

Managed Security Service Providers may want to split internal engines and SaaS product engines.

If you have multiple AWS accounts that are not connected and do not want a single point of failure for AWS integrations that use STS.

Users can move an engine from one group to another. A group will be deleted when the last engine is removed from it.

Each engine can only be part of a separate group.

Get engine logs

Logs are located in /var/log/demisto. For multiple engines, logs are located in /var/log/demisto/<name of the engine>. For example,
var/log/demisto.d1_e1.

Upgrade an engine

Whenever there is a Cortex XSIAM major version change or a change in server-engine protocol version, your engines require an upgrade. In the the
Status column of the UI, the Cortex XSIAM version for that engine is red.

To upgrade the engine, select the checkbox for the engine that requires the upgrade and click Upgrade Engine. When the upgrade finishes, the version
appears in the Cortex XSIAM Version. The upgrade procedure can take several minutes.

You can only upgrade the engine if you installed the engine with the shell installer. To upgrade engines that were not installed with the shell installer, you
need to remove the engine and do a fresh install. For more information, see Engine Installation. For troubleshooting, see Troubleshoot Engine Upgrades.

Delete an engine

18.5 | Use an Engine in an Integration

Abstract

Use an engine or load-balancing group of engines to fetch alerts and run commands for an integration.

When you create an integration instance, you can select whether to fetch alerts and run commands executed for the integration using the engine or a load-
balancing group of engines. After you add the engine or load-balancing group to an integration instance, you can run commands using the engine or load-
balancing group by specifying the using argument in the Alert War Room.

Command Example

!url url="www.cnn.com" using=urlscan.io_instance_1

18.6 | Run a Script Using an Engine

Abstract

Run a script on an engine or load-balancing group to distribute the workload and improve performance.

You can run a script on an engine or load-balancing group to distribute the workload and improve performance.

1. Go to Incident Response → Automation → Scripts.

2. Select the script and click Settings.

3. From the BASIC section, in the Run on field, select either a single engine or a load-balancing group.

The option to select an engine or load-balancing group only appears if at least one engine or load-balancing group is connected.

4. From the drop-down, select the name of the engine or load-balancing group.

5. Save the script.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 986/1003
5/8/24, 9:18 AM PDF Export

18.7 | Remove an Engine

Abstract

Remove an engine by running the relevant command, depending on your operating system.

You can remove a engine when it is no longer needed.

Run one of the following commands according to your operating system:

Installation Command

RPM Get the full package: rpm -qa | grep -i ^d1_*

Remove the package: rpm -evv d1_ <package name>

DEB Get the full package: dpkg-query -W -f='${Package}' d1_*

Remove the package: dpkg --purge <package name>

SH Remove an Engine: sudo <engine-file-path> -- -purge

For Windows machines, delete the engine file that was created.

18.8 | Troubleshoot Engines

Abstract

Troubleshoot engines by accessing logs and viewing errors.

When troubleshooting engines, access the logs from Settings → Configurations → Engines and select the engine from which you want to download the logs.

Debug Engines

The d1.log field appears whenever an engine is running. The d1.log field contains information necessary for your customer success team to debug any engine
related issue. The field displays any error, as well as noting whether the engine is connected.

Engine 443 Error

This error might occur when a connection is established between an engine and , because, by default, Linux does not allow processes to listen on low-level
ports.

Error Message

listen tcp :443: bind: permission denied

Solution

In the d1.conf file, change the port number to a higher one, for example, 8443.

Run this command: sudo setcap CAP_NET_BIND_SERVICE=+eip /path/to/binary. After running this command the server should be able to bind to
low-numbered ports.

18.8.1 | Troubleshoot Engine Installation

Abstract

Troubleshoot a failed engine installation.

After installing the engine, check that the engine is connected to the Cortex XSIAM tenant and that it is running.

1. Go to Settings → Configurations → Data Broker → Engines and verify that the engine is connected.

2. If the engine is not connected, run the following command on the engine server to check if the engine service is running.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 987/1003
5/8/24, 9:18 AM PDF Export

sudo systemctl status d1

3. Access the d1 log on the engine server.

sudo tail -f /var/log/demisto/d1.log

If the engine service is not running, and there’s nothing relevant in the log, run journalctl on the engine server to understand why the installation
failed.

If the engine service is running, review the errors to see if the engine is failing to connect or if there are other issues (ignore all errors related to
\d2ws, since this is not the same as d1ws.) Most often, the server address is incorrect and you will see an error like this:

error Cannot connect to [wss://<mainServerIP/HostName>/d1ws]: wss://<mainServerIP/HostName>/d1ws: dial tcp: lookup

localhost: no such host. . Waiting 3 seconds. Will try until…

In this case, navigate to /usr/local/demisto/d1.conf and change the EngineURLs parameter to an address the engine can reach. Check the
addresses at the beginning of the upgrade_engine.sh file and update them to be the same as in the conf file. The addresses should be a comma-
separated list.

NOTE:

You can ignore the following error: Cannot create folder '/var/lib/demisto'

The configurations that might affect the upgrade_engine.sh script are the following variables located at the beginning of the script:

SERVER_URLS

TRUST_ANY_CERT

If you make a change to the baseURLs configuration, you must apply the change in /usr/local/demisto/d1.conf AND in
/usr/local/demisto/upgrade_engine.sh under the SERVER_URLS var.

If you make a change in the engine.connection.trust_any_certificate configuration, you must apply the change in
/usr/local/demisto/upgrade_engine.sh as follows:

If the engine.connection.trust_any_certificate configuration was set to true (trust any certificate), set the TRUST_ANY_CERT
variable to -k.

If the engine.connection.trust_any_certificate configuration was set to false, the TRUST_ANY_CERT variable should be blank (““).

4. To check the connectivity from the engine to the Cortex XSIAM tenant, see Troubleshoot Engine Connectivity.

5. If the installation issue remains, open a support case with logs from the engine.

a. On the engine server, in /usr/local/demisto/d1.conf, set "LogLevel": "debug”.

b. Restart the d1 service and let it run for a few minutes.

sudo systemctl restart d1

c. Capture a journalctl:

journalctl --since "1 day ago" > engineTroubleshootingJournalctl.log

d. On the engine server, tar up the log, conf, journalctl, and install log on the engine.

tar -cvzf engineLogs.tar.gz /var/log/demisto /usr/local/demisto/d1.conf /tmp/demisto_install.log

engineTroubleshootingJournalctl.log

18.8.2 | Troubleshoot Docker Networking Issues

Abstract

Troubleshoot Docker networking issues in Cortex XSIAM.

In Cortex XSIAM, integrations and scripts run either on the tenant, or on an engine.

If you have Docker networking issues when using an engine, you need to modify the d1.conf file.

1. On the machine where the Engine is installed, open the d1.conf file.

2. Add to the d1.conf file the following:

{
"LogLevel": "info",
"LogFile": "/var/log/demisto/d1.log",
"EngineURLs": [

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 988/1003
5/8/24, 9:18 AM PDF Export

"wss://1234.demisto.live/d1ws"
],
"BindAddress": ":443",
"EngineID": "XYZ",
"ServerPublic": "ABC"
"ArtifactsFolder": "",
"TempFolder": "",
"python.pass.extra.keys": "--network=host"
}

3. Save the file.

4. Restart the engine using systemctl restart d1 or service d1 restart.

18.8.3 | Troubleshoot Docker Performance Issues

Abstract

Troubleshoot Docker performance issues in Cortex XSIAM. Update Docker package and dependencies.

This information is intended to help resolve the following Docker performance issues.

Containers are getting stuck.

The Docker process consumes a lot of resources.

Time synchronization issues between the container and the OS.

Cause

The installed Docker package and its dependencies are not up to date.

Workaround

1. Update the package manager cache.

Linux Distribution Command

CentOS yum check-update

Debian apt-get update

2. (Optional) Check for a newer version of the Docker package.

Linux Distribution Command

CentOS yum check-update docker

Debian apt-cache policy docker

3. Update the Docker package.

Linux Distribution Command

CentOS yum update docker

Debian apt-get update docker

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 989/1003
5/8/24, 9:18 AM PDF Export

18.8.4 | Troubleshoot Podman Installation

Abstract

Troubleshoot Podman installation issues, including Keyring Quota Exceeded error and unused containers taking up resources.

Keyring Quota Exceeded Error

Script failed to run: Docker code runner got container error: [Docker code script is in inconsistent state, ... error: [exit
status 126] stderr: [Error: OCI runtime error: crun: create keyring ...: Disk quota exceeded]

By default, Podman creates a keyring that is used by each container. The limit per user on the machine might be low and Podman can reach the limit when
running more containers than the keyring limit. To check the keyring usage, run the sudo cat /proc/key-users operating system command.

The command returns the usage for each UID (to retrieve the demisto user UID, run id demisto ). The fourth column shows the number of keys used out of the
total number available. For more information about keys, see Kernel Key Retention Service.

You can either increase the limit of max keyrings (increasing to 1000 is safe and reasonable) per user as specified by your Linux vendor documentation or you
can disable keyring creation by Podman. We recommend disabling keyring creation, unless keyrings are used by Podman in other applications on the machine.
To disable keyring creation by Podman, modify the containers.conf file and add the option keyring = false under the "[containers]" section. For more
information, see the Containers Engine Configuration File.

Unused Containers Taking up Resources

In some cases, if the Podman process crashes or is killed abruptly it can leave containers on disk. You might see errors such as error allocating lock for
new container: allocation failed; exceeded num_lock when the maximum number of locks used to manage containers is exhausted due to the unused
containers that remain.

1. Change to the demisto operating system user sudo su - -s /bin/bash demisto.

2. Run podman ps -a -f status=exited to check for unused containers.

3. Clean up the unused containers podman container cleanup --rm -a.

NOTE:

When you run podman container cleanup --rm -a, you might see a message such as running or paused containers cannot be moved
without force. The message can be safely ignored, as it only pertains to current running containers, which are not removed.

4. After clean up, verify there are no remaining unused containers podman ps -a -f status=exited.

18.8.5 | Troubleshoot Engine Upgrades

Abstract

Troubleshoot failed engine upgrades. Manually upgrade Cortex XSIAM engines.

During an upgrade, the upgrade file is sent to the engine server. A cron job running on the engine server checks if that file exists. The most common upgrade
error is that the job is not running so the new installer does not run.

1. SSH to the machine.

2. Check the d1 service status on the engine server. It is possible that it stopped or doesn't exist.

sudo systemctl status d1

3. Access the installer log on the engine server and review the error.

sudo vi /tmp/demisto_install.log

4. Rerun the installer on the engine using one of the following options. You can open a second window and run watch df -h. If the problem seems to be
disk space, you should resolve the disk space issue and then rerun the installer.

a. Option 1

i. Download the installer from the user interface and copy it to the engine.

ii. Add the following commands:

sudo chmod +x installer.sh

sudo ./installer.sh -- -y

b. Option 2

i. Verify that /usr/local/demisto/d1_upgrade.sh exists.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 990/1003
5/8/24, 9:18 AM PDF Export

sudo chmod +x /usr/local/demisto/d1_upgrade.sh

sudo /usr/local/demisto/d1_upgrade.sh

ii. If d1_upgrade.sh does not exist, check if /usr/local/demisto/archived_d1_upgrade.sh exists and that it was created at the time of the
attempted upgrade.

If the file exists and was created at the time of the attempted upgrade, run the following on the engine server:

sudo chmod +x /usr/local/demisto/d1_upgrade_archive.sh

sudo /usr/local/demisto/d1_upgrade_archive.sh

18.8.6 | Troubleshoot Engine Connectivity

Abstract

Troubleshoot engine connectivity from the engine to the endpoint, including an Engine 443 error.

The following provides instructions for troubleshooting connectivity issues from the engine to the endpoint.

1. Follow the instructions in network troubleshooting.

2. Ensure that the engine can reach the endpoint by running the following command on the server engine.

sudo curl -kvv <endpointURL>

3. If the engine could not reach the endpoint, try the IP with curl instruction adding the http(s)//, or try using ping.

If this works, add the IP to the /etc/hosts file with the hostname and try to reach the endpoint again by running the following command on the engine
server

sudo curl -kvv <endpointURL>

If this still fails, then this is an issue of connectivity between the engine and endpoint and you need to resolve this with your networking team.

4. Once connectivity has been confirmed via curl:

Try connecting within Docker without passing host networking.

docker run -it --rm demisto/netutils:1.0.0.6138 curl -kvv <endpointURL>

If this succeeds but the integration still fails, it could be an integration credentials issue. In that case, open a support case.

If without passing host networking fails, run the following:

docker run -it --rm --network=host demisto/netutils:1.0.0.6138 curl -kvv <endpointURL>

If this succeeds, add "python.pass.extra.keys": "--network=host" to /usr/local/demisto/d1.conf and retest the integration.

If you see a Docker or Selinux issue, see Troubleshoot Docker Networking Issues.

5. If the installation issue remains, open a support case with logs from the engine.

a. On the engine server, in /usr/local/demisto/d1.conf, set "LogLevel": "debug”.

b. Restart the d1 service and let it run for a few minutes.

sudo systemctl restart d1

c. Capture a journalctl:

journalctl --since "1 day ago" > engineTroubleshootingJournalctl.log

d. On the engine server, tar up the logs, conf, journalctl, and install log on the engine.

tar -cvzf engineLogs.tar.gz /var/log/demisto /usr/local/demisto/d1.conf /tmp/demisto_install.log

engineTroubleshootingJournalctl.log

Engine 443 Error

This error might occur when a connection is established between an engine and the Cortex XSIAM tenant, because, by default, Linux does not allow processes
to listen on low-level ports.

Error Message

listen tcp :443: bind: permission denied

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 991/1003
5/8/24, 9:18 AM PDF Export

Solution

In the d1.conf file, change the port number to a higher one, for example, 8443.

Run this command: sudo setcap CAP_NET_BIND_SERVICE=+eip /path/to/binary. After running this command the server should be able to bind to
low-numbered ports.

18.8.7 | Troubleshoot Integrations Running on Engines

Abstract

Troubleshoot integrations running on an engine.

The following are common errors that occur when integrations are running on an engine:

Troubleshoot Engine Import Error or Invalid Syntax Error

Troubleshoot Permission Denied

18.8.8 | Troubleshoot Engine Import Error or Invalid Syntax Error

Abstract

Troubleshoot engine import error or invalid syntax error when running an integration on an engine.

When running an integration on an engine, the most common errors are:

Broken Pipe

“ ImportError: No module named...

Invalid syntax

Script failed to run: exec: “python”: executable file not found in $PATH (2603)

These errors could indicate that the engine is not using Docker.

1. Use SSH to access the engine server.

2. Make sure Docker is healthy.

a. Ensure that Docker is installed and is running.

sudo systemctl status docker

If the Docker status is not good, restart your Docker.

sudo systemctl restart docker

b. Ensure Docker can run a container.

sudo docker run hello-world

If this fails, reinstall your Docker.

3. Access the d1.conf file on the engine server.

sudo vi /usr/local/demisto/d1.conf

4. Add the "python.engine.docker": true configuration to the d1.conf file and remove any other configurations related to python and Docker, such as
“python.executable.no.docker”.

5. Restart the system on the engine server.

sudo systemctl restart d1

6. Retest the integration from the user interface. This may take a few minutes since it may need to pull the relevant Docker image.

18.8.9 | Troubleshoot Permission Denied

Abstract

Troubleshoot engine permission denied.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 992/1003
5/8/24, 9:18 AM PDF Export

A common error message you may see when running integrations on engines is something like: Got permission denied while trying to connect to
the Docker daemon socket at unix:///var/run/docker.sock: Get http://%2Fvar%2Frun%2Fdocker.sock/v1.35/images/json?t.

1. Determine if you are using a Docker group or Dockerroot group by running one of the following on the server engine:

ls -la /var/run/docker.sock

The output from this command will show what user/group is running docker.sock. For example:

srw-rw----. 1 root docker 0 Apr 12 20:32 /var/run/docker.sock

shows that it’s a Docker group and not Dockerroot.

cat /etc/group | grep docker

This command shows if you are running Docker or Dockerroot.

NOTE:

Docker CE installations typically run Docker, while Docker EE installations typically run Dockerroot.

2. To fix a Docker user, run the following commands on the server engine:

a. sudo groupadd docker

b. sudo usermod -aG docker demisto

c. sudo systemctl restart docker

d. sudo systemctl restart d1

3. To fix a dockerroot user, run the following commands on the server engine:

a. sudo groupadd dockerroot

b. Set the dockerroot group in /etc/docker/daemon.json. For example: { "group": "dockerroot" }.

c. sudo usermod -aG dockerroot demisto

d. sudo chcon -Rt svirt_sandbox_file_t /var/lib/demisto/temp

e. sudo systemctl restart docker

f. sudo systemctl restart d1

19 | Automation and Feed Integrations

Abstract

Add integration instances to your system.

In Cortex XSIAM you can add and configure integrations such as messaging (such as EWS, Gmail), SIEM (such as IBM QRadar), authentication (such as AD,
SAML, etc), feeds (such as AutoFocus), etc. For example, the IBM QRadar integration enables you to ingest QRadar events in Cortex XSIAM as alerts. You can
then process the alerts using a playbook, analyze the data, and take any response as required.

Some of these integrations are installed out-of-the box from Content Packs. You can also create your own integration, or upload an integration.

In the Automation & Feed Integration page (Settings → Configurations) you can do the following:

Configure an integration instance.

You can fetch alerts from an integration instance and update settings by clicking the settings cog wheel icon. You can also add classifiers and mappers to
the instance.

View existing instances.

Enable/disable the integration instance.

Create or bring your own integration (BYOI).

Upload an integration.

View version history of the integrations.

19.1 | Fetch Alerts From an Integration Instance

Abstract

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 993/1003
5/8/24, 9:18 AM PDF Export

Learn how to poll third-party integration instances and turn them into alerts that trigger automations (fetching).

You can poll third-party integration instances for events and turn them into Cortex XSIAM alerts that trigger automations (fetching). There are several
integrations that support fetching, but not all support this feature. You can view each integration in Developer Hub.

NOTE:

The Developer Hub contains integrations for Cortex XSIAM and Cortex XSOAR, but not all integrations can be used with Cortex XSIAM.

When setting up an instance, you can configure the integration instance to fetch events. You can also set the interval for which to fetch new alerts, by configuring
the Alert Fetch Interval field. The fetch interval default is 1 minute. This enables you to control the interval in which an integration instance reaches out to third
party platforms to fetch alerts into Cortex XSIAM . If the integration instance, does not have the Alert Fetch Interval field, you can add this field by editing the
integration settings.

NOTE:

You can add the field to any integration that fetches alerts. For out-of-the-box integrations, to add the field, you need to create a copy of the integration.
Editing the integration settings including adding the Incident Fetch Interval field, breaks the connection to out-of-the-box content. Any future updates to this
integration will be applied to the out-of-the-box integration and not to the copy integration.

If you turn off fetching for a period of time and then turn it on or disabled the instance and enabled it, the instance remembers the "last run" timestamp, and pulls
all events that occurred while it was off. If you don't want this to happen, verify that the instance is enabled and click Reset the “last run” timestamp when editing
the instance. Also, note that "last run" is retained when an instance is renamed.

1. Select the integration instance you want to fetch incidents by going to Settings → Configurations → Automations & Feed Integrations and click Add
instance.

2. Select the Fetches alerts checkbox.

Once enabled, Cortex XSIAM searches for events that occurred within the time frame set for the integration, which is based on the specific integration.
The default is 10 minutes prior, but can be changed in the integration script implementation.

3. (Optional) In the Alerts Fetch Interval field, set the number of hours or days, and the number of minutes the interval for which to fetch alerts (default 1
minute).

4. (Optional) If the Alerts Fetch Interval field does not appear, add it to the integration.

Relevant for any alerts fetching integration.

a. For out-of-the-box integrations, select the duplicate integration button.

If you have already duplicated the integration, click the Edit integration’s source button.

b. In the Basic section, select the Fetches alerts checkbox.

In the Parameters section, you can see that the AlertFetchInterval parameter is added. Change the default value if necessary.

c. Click Save.

19.2 | Classification and Mapping

Abstract

Classify and map an integration so you can see the results in alert fields when investigation an alert.

The classification and mapping feature enables you to take the events and event information that Cortex XSIAM ingests from integrations, and classify the event
as a type of Cortex XSIAM alert.

For example, you may configure EWS to ingest both Phishing and Malware alerts so you can classify their respective alert types based on some information in
the event. By classifying the events as different alert types, you can process them with different playbooks suited to their respective requirements.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 994/1003
5/8/24, 9:18 AM PDF Export

Classification

Classification determines the type of alert that is created for events ingested from a specific integration. You create a classifier and define that classifier in an
integration.

Mapping

You can map the fields from your third party integration to the fields in your alert layouts.

You can do the following:

Map your fields to alert types irrespective of the integration or classifier. This means that you can create a mapping before defining an instance and
ingesting incidents. By doing so, when you do define an instance and apply a mapper, the alerts that come in are already mapped.

Create a default mapping for all of the fields that are common to all alert types, and then map only those fields that are specific to each alert type
individually. You can still overwrite the contents of a field in the specific alert type.

Use auto-map to automatically map fields based on their naming convention. For example, severity would be mapped to importance.

19.3 | Classify Events Using a Classifier for Alert Types

Abstract

Classify events using a classification key in an integration ingestion.

When an integration fetches alerts, it populates the rawJSON object in the alert object. The rawJSON object contains all of the attributes for the event. For
example, source, when the event was created, the priority that was designated by the integration, etc. When classifying the event, you want to select an attribute
that can determine the event type.

You can use this procedure for creating a classifier or duplicating an existing classifier.

1. Go to Settings → Configurations → Object Setup → Alerts → Classification & Mapping.

2. Click New and select Alert Classifier.

If you want to duplicate the classifier, select the relevant classifier and then duplicate it.

3. Under Get data, select from where you want to pull the information based on which you will classify the incident types.

Pull from instance - select an existing integration instance.

Select schema - when supported by the integration, this will pull all the fields for the integration from the database from which you can select by
which to classify the events.

Upload JSON - upload a formatted JSON file which includes the field by which you want to classify.

4. In the Select Instance field, select the instance from where you want to choose the value.

5. In the Data fetched from select the value by which you want to classify the events.

6. Drag values from the Unmapped Values column to the relevant alert type on the right.

You can optionally choose a default alert type for unclassified incidents from Direct unclassified events to: Select.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 995/1003
5/8/24, 9:18 AM PDF Export

7. Click Save.

8. Go to Settings → Automation & Feed Integrations.

a. Select the integration to which you want to apply the classifier.

b. In the integration settings, under Classifier, select the classifier you created and click Save.

19.4 | Map Fields to Alert Types

Abstract

You can create independent mappers for integrations.

Mappers enable you to map information from incoming events to the alert fields that you have in your system. You can map to system alert fields or custom alert
fields.

Mapping event attributes or alert fields takes place in two stages. First you map all of the fields that are common to all alerts in the default mapping. Second, you
map the additional fields that are specific for each alert indicator type, or overwrite the mapping that you used in the default mapping.

NOTE:

In the Classification & Mapping page, the mapping does not indicate for which alert types they are configured. Therefore, when creating a mapper, it is best
practice to add to the mapper name, the alert types the mapper is for. For example, Mail Listener - Phishing.

NOTE:

When mapping a list, we recommend you map to a multi select field. Short text fields do not support lists. If you do need to map a list to a short text field, add
a transformer in the relevant playbook task, to split the data back into a list.

You can use this procedure for creating a classifier or duplicating an existing mapper for alert types.

1. Go to Settings → Configurations → Object Setup → Alerts → Classification & Mapping.

2. Click New and select Alert Mapper (incoming). The Alert Mapper maps all of the fields you are pulling from the integrations to the alert fields in your
layouts.

3. Under Get data, select from where you want to pull the information based on where you want to map the alert types.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 996/1003
5/8/24, 9:18 AM PDF Export

Pull from instance - select an existing integration instance.

Select schema - when supported by the integration, this pulls all of the fields for the integration from the database. This enables you to see all of the
fields for each given event type that the integration supports.

Upload JSON - upload a formatted JSON file which includes the field you want to map.

4. Under Alert Type, start by mapping out the Common Mapping. This mapping includes the fields that are common to all of the alert types and will save time
having to define these fields individually in each alert type.

5. Click the event attribute to which you want to map. You can further manipulate the field using filters and transformers.

You can click Auto Map to automatically map fields with common or similar names to fields in Cortex XSIAM . For example, Severity to Importance or
Description to Description.

6. Repeat this process for the other alert types for which this mapping is relevant.

7. Click Save.

8. Go to Settings → Configurations → Data Collection → Automation & Feed Integrations.

a. Select the integration instance to which you want to apply the mapper.

b. In the integration settings, under Mapper (incoming) select the mapper you created and click Save.

19.5 | Credentials in Cortex XSIAM

Abstract

Configure credentials for integration instances by entering them manually, by using Credentials in Cortex XSIAM Settings or by using external credentials.

Saved credentials simplify and compartmentalize administrative tasks, and enable you to save login information without exposing usernames, passwords, or
certificates. You can also reuse credentials across multiple systems, for example, when using the same administrator password across multiple endpoints.

After you set up a credential, you can configure integration instances to use it instead of entering the name and password manually. Also, when you configure a
system in which an agent will be deployed, you can use the credentials argument instead of user and password.

There are several ways you can configure credentials for an integration instance.

Manually enter a username and password whenever you configure an integration instance.

Add credentials in the Credentials page.

Use credentials saved in an external credentials vault, e.g., CyberArk, or HashiCorp.

19.5.1 | Configure Cortex XSIAM Credentials

Abstract

Credentials enables you to centrally manage credentials, which include a unique name for the credential, username, password, and certificate.

Credentials enables you to centrally manage credentials, which include a unique name for the credential, username, password, and certificate. You can then
select the credential name when configuring an integration instance.

1. Select Settings → Configurations → Integrations → Credentials → New Credential.

2. Add the following parameters.

Parameters Description

Credential Name The display name for the credential.

Username The username for the credential.

Workgroup The workgroup to associate this credential with. Relevant for third-party
services, such as Active Directory, CyberArk, HashiCorps, etc.

Password The password for the credential.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 997/1003
5/8/24, 9:18 AM PDF Export

Parameters Description

Certificate Certificate or SSH key to use for the credential.

3. Save the credential.

19.5.2 | Configure an External Credentials Vault

Abstract

Cortex XSIAM integrates with external credential vaults, which enables you to use them in Cortex XSIAM without hard coding or exposing the credentials.

Cortex XSIAM integrates with external credential vaults, which enables you to use them without hard coding or exposing the credentials. The credentials are not
stored in Cortex XSIAM, but the integration fetches the credentials from the external vault when called. The credentials are passed to the relevant executed
integrations as part of the integration parameters.

Sample credentials provider integrations:

CyberArk AIM

HashiCorp Vault

After the integration is configured to fetch credentials, the credentials will be available from the Credentials menu, and for use in scripts and playbooks. To use
these credentials in an integration, click Switch to credentials in an integration instance, and select the necessary credential from the menu.

20 | Glossary
The following terms are used in the Cortex products:

20.1 | Alert
When you identify a threat, you can define specific rules for which you want Cortex XDR/Cortex XSIAM to raise alerts. Non-informational alerts are consolidated
from your detection sources to enable you to efficiently and effectively triage the events you see each day on the Alerts page. By analyzing the alert, you can
better understand the cause of what happened and the full story with context to validate whether an alert requires additional action. Cortex XDR/Cortex XSIAM
supports saving 2M alerts per 4000 agents or 20 terabytes, half of the alerts are allocated for informational alerts and half for severity alerts.

20.2 | Alert Exclusion

An alert exclusion is a rule that contains a set of alert match criteria that you want to suppress from Cortex XDR/Cortex XSIAM. You can add an Alert Exclusion
rule from scratch or you can base the exclusion off of alerts that you investigate in an incident. After you create an exclusion rule, Cortex XDR/Cortex XSIAM
excludes and no longer saves any of the future alerts that match the criteria from incidents and search query results. If you select to apply the policy to historic
results as well as future alerts, Cortex XDR/Cortex XSIAM identifies the historic alerts as grayed out.

20.3 | Analytics behavioral indicators of compromise (ABIOCs)

Analytics behavioral indicators of compromise (ABIOCs). In contrast to standard Analytics alerts, ABIOCs indicate a single event of suspicious behavior with an
identified chain of causality. To identify the context and chain of causality, ABIOCs leverage user, endpoint, and network profiles. The profile is generated by the
Analytics Engine and can be based on a simple statistical profile or a more complex machine-learning profile.

20.4 | Attack Surface Management (ASM)

Attack Surface Management (ASM). Provides embedded attack surface management (ASM) capabilities for an attacker’s view of your organization, with asset
discovery, vulnerability assessment, and risk management.

20.5 | Behavioral indicators of compromise (BIOCs)

Behavioral indicators of compromise (BIOCs) enable you to alert and respond to behaviors—tactics, techniques, and procedures. Instead of hashes and other
traditional indicators of compromise, BIOC rules detect behavior such as is the behavior related to processes, registry, files, and network activity.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 998/1003
5/8/24, 9:18 AM PDF Export

20.6 | Bring Your Own Machine Learning (BYOML)

Topic Not Found

20.7 | Broker Virtual Machine (Broker VM)

Broker Virtual Machine (VM). The Palo Alto Networks Broker is a secured virtual machine (VM), integrated with Cortex XDR/Cortex XSIAM, that bridges your
network and the Cortex product. By setting up the broker, you establish a secure connection in which you can route your endpoints, and collect and forward logs
and files for analysis.

20.8 | Broker Virtual Machine Fully Qualified Domain Name (Broker VM FQDN)
Broker VM Fully Qualified Domain Name (FQDN). The Broker VM is where you define the Broker VM FQDN as it will be defined in your Domain Name System
(DNS). This enables connection between the WEF and WEC, acting as the subscription manager. The Broker VM FQDN settings affect the WEC and Agent
Installer and Content Caching.

20.9 | Causality Group Owner (CGO)

Causality Group Owner (CGO). The causality chains are listed according to the CGO, also called the causality actor. The CGO is the process that is responsible
for all the other processes, events, and alerts in the chain.

20.10 | Causality View

The Causality View provides a powerful way to analyze and respond to alerts. The scope of the Causality View is the Causality Instance (CI) to which this alert
pertains. The Causality View presents the alert (generated by Cortex XDR/Cortex XSIAM or sent to Cortex XDR/Cortex XSIAM from a supported alert source
such as the XDR agent) and includes the entire process execution chain that led up to the alert. On each node in the CI chain, Cortex XDR/Cortex
XSIAM provides information to help you understand what happened around the alert.

20.11 | Cloud Detection and Response (CDR)

Cloud Detection and Response (CDR). Analyzes cloud audit, flow, and container host logs together with data from other sources for holistic detection and
response across your hybrid enterprise.

20.12 | Cortex Data Model (XDM)

Cortex Data Model (XDM). The XDM enables you to map your logs into a single, unified data model. This data model provides a consolidated schema, and a
simpler way to interact with your data, regardless of its source or dataset. To familiarize yourself with the data model schema, see Cortex XSIAM Data Model
Schema.

20.13 | Cortex Query Language (XQL)

Cortex Query Language. The Cortex Query Language (XQL) enables you to query for information contained in a wide variety of data sources in Cortex
XDR/Cortex XSIAM for rigorous endpoint and network event analysis.

20.14 | Dataset
A dataset is a collection of column:value sets and has a unique name. Every Cortex Query Language query begins by identifying a dataset that the query will run
against. If you do not specify a dataset in your query, the query runs against the default datasets configured.

20.15 | Elasticsearch Filebeat

See Filebeat.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 999/1003
5/8/24, 9:18 AM PDF Export

20.16 | Endpoint Detection and Response (EDR)

Endpoint Detection and Response (EDR). With Endpoint Detection and Response (EDR), enterprises rely on endpoint data as a means to trigger cybersecurity
incidents. As cybercriminals and their tactics have become more sophisticated, the time to identify and contain breaches has only increased. Cortex Extended
Detection and Response (XDR) goes beyond the traditional EDR approach of using only endpoint data to identify and respond to threats by applying machine
learning across all your enterprise, network, cloud, and endpoint data. This approach enables you to quickly find and stop targeted attacks and insider abuse
and remediate compromised endpoints.

20.17 | Endpoint Protection Platform (EPP)

Endpoint Protection Platform (EPP). Prevents endpoint attacks with a proven endpoint agent that blocks exploits, malware, and fileless attacks and collects full
telemetry for detection and response.

20.18 | Exception
To allow full granularity, Cortex XDR/Cortex XSIAM enables you to create exceptions from your baseline policy. With these exceptions you can remove specific
folders or paths from evaluation, or disable specific security modules. You can configure exception rules for Cortex XDR/Cortex XSIAM protection and
prevention actions in a centralized location, and apply them across multiple profiles. The exceptions can be configured from Settings → Exception Configuration.

20.19 | Exception vs Alert Exclusion

Exceptions enables to you create exceptions from your baseline policy, so you can remove specific folders or paths from evaluation, or disable specific security
modules. You can configure exception rules for Cortex XDR/Cortex XSIAM protection and prevention actions in a centralized location, and apply them across
multiple profiles. While an Alert Exclusion is a rule that contains a set of alert match criteria that you want to suppress from Cortex XDR/Cortex XSIAM. You can
add an Alert Exclusion rule from scratch or you can base the exclusion off of alerts that you investigate in an incident.

20.20 | Extended Detection and Response (XDR)

Extended Detection and Response (XDR). Gathers telemetry from any source for unrivaled detection coverage and accuracy, with the highest number of
technique-level detections in the 2022 MITRE ATT&CK evaluations.

20.21 | External Dynamic List (EDL)

External Dynamic List (EDL). An EDL is a hosted text file. In Cortex XDR/Cortex XSIAM/Cortex XSOAR, you can configure an EDL to share a list of Cortex
XDR/Cortex XSIAM/Cortex XSOAR indicators with other products in your network, such as a firewall or SIEM. For example, your Palo Alto Networks firewall can
add IP address and domain data from the EDL to block or allow lists.

20.22 | Filebeat
Elasticsearch Filebeat, also called Filebeat, is a type of log source that can be ingested by Cortex XDR/Cortex XSIAM. Depending on the type of Elasticsearch
Filebeat logs that you want to ingest, a different data source is used.

20.23 | Forensics
Allows you to perform forensic analysis easily by collecting all the artifacts you need and displaying them in an intuitive forensics console.

20.24 | Fully Qualified Domain Name (FQDN)

Fully Qualified Domain Name (FQDN). A FQDN, sometimes also referred to as an absolute domain name, is a domain name that specifies its exact location in
the tree hierarchy of the Domain Name System (DNS).

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 1000/1003
5/8/24, 9:18 AM PDF Export

20.25 | Identity Threat Detection and Response (ITDR)

Identity Threat Detection and Response (ITDR). An add-on license available for purchase on top of either the Cortex XDR Pro licenses or both Cortex XSIAM
Enterprise and Cortex XSIAM Enterprise Plus licenses. Enables Asset Roles Configuration, Advanced Analytics Alert layout, Risk Management Dashboard,
User/Host Risk View, Designated Analytics for Compromised Accounts, and Insider Threat Coverage.

20.26 | Incident
An attack can affect several hosts or users and raises different alert types stemming from a single event. All artifacts, assets, and alerts from a threat event are
gathered into an Incident. The Incidents page displays all incidents to help you prioritize, track, triage, investigate and take remedial action.

20.27 | Indicators of compromise (IOCs)

Indicators of compromise (IOCs) provide the ability to alert known malicious objects on endpoints across the organization. You can load IOC lists from various
threat-intelligence sources into the product or define them individually.

20.28 | IT Metrics Dashboard

The IT Metrics dashboard in Cortex XSIAM displays an overview of IT performance on your Cortex XDR Agent. On the dashboard you can review CPU and
memory performance data, connectivity data, and data about hard reboots and crashed applications. The dashboard comprises a number of widgets.

20.29 | Managed Threat Hunting (MTH)

Managed Threat Hunting (MTH). The Managed Threat Hunting service offers round-the-clock monitoring from Unit 42 experts to discover attacks anywhere in
your organization. Our threat hunters work on your behalf to discover advanced threats, such as state-sponsored attackers, cybercriminals, malicious insiders
and malware.

20.30 | Management, Reporting, and Compliance

Simplifies operations, centralizing all configuration, monitoring, and reporting functions, including endpoint policy management, orchestration, and response.

20.31 | Master Boot Record Protection (MBR Protection)

Master Boot Record (MBR) Protection. Cortex XDR/Cortex XSIAM includes an improved detection engine on the Cortex XDR agent to enhance its protection
against malicious Master Boot Record (MBR) manipulations.

20.32 | MITRE ATT&CK Framework Coverage Dashboard

The MITRE ATT&CK Framework Coverage dashboard displays a comprehensive overview of the Cortex XSIAM content and capabilities in context with the
MITRE ATT&CK framework. This dashboard enables you to see a breakdown of the protection modules and detection rules in place for each MITRE tactic and
technique. You can use the dashboard to review the elements that affect your coverage, and identify coverage gaps in your framework.

20.33 | Next-Generation Firewall (NGFW)

Next-Generation Firewall (NGFW). You can forward firewall data from your NGFW and Panorama devices.

20.34 | Notebooks
Cortex XSIAM Notebooks enable you to analyze and visualize the extensive data collected by Cortex XSIAM. Using Jupyter tools, you can build machine
learning models to visualize clusters, identify anomalies, and then feed your findings back into the Cortex XSIAM environment to generate security insights.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 1001/1003
5/8/24, 9:18 AM PDF Export

20.35 | On-write File Protection

Cortex XDR/Cortex XSIAM provides out-of-the-box On-write File Protection for Windows, which monitors and takes action on malicious files during the on-write
process.

20.36 | Playbook
A playbook is a high-level automation tool that coordinates multiple tasks or actions in a workflow. Playbooks are a series of tasks, conditions, automations,
conditions, commands, and loops that run in a predefined flow to save time and improve the efficiency and results of the investigation and response process.

20.37 | Prisma
Prisma is another Cortex product that can be integrated to Cortex XDR/Cortex XSIAM. For example, you can receive alerts from Prisma Cloud Compute and
forwarded data from Prisma Access.

20.38 | Script
A script performs specific actions and can be comprised of integration commands, which are used in playbook tasks and when running automation on demand in
the War Room.

20.39 | Security Information and Event Management (SIEM)

Security Information and Event Management (SIEM). Delivers all common SIEM functions, including log management, correlation and alerting, reporting, and
long-term data retention.

20.40 | Security Orchestration, Automation, and Response (SOAR)

Security Orchestration, Automation, and Response (SOAR). Automates nearly any use case with hundreds of built-in playbooks and offers customization with a
visual drag-and-drop playbook editor.

20.41 | Threat Intelligence Platform (TIP)

Threat Intelligence Platform (TIP). Aggregates, scores, and distributes threat intelligence data, including the industry-leading Unit 42 threat feed, to third-party
tools and enriches alerts for context and attribution.

20.42 | Unified Extensible Firmware Interface Protection (UEFI Protection)

Unified Extensible Firmware Interface (UEFI) Protection. Cortex XDR/Cortex XSIAM provides out-of-the-box UEFI protection on Windows. When Cortex
XDR/Cortex XSIAM detects UEFI manipulation attempts, the Cortex XDR agent carries out the configured action (default is Block).

20.43 | User and Entity Behavior Analytics (UEBA)

User and Entity Behavior Analytics (UEBA). Uses machine learning and behavioral analysis to profile users and entities and alert on behaviors that may indicate
a compromised account or malicious insider.

20.44 | Virtual Machine

See Broker Virtual Machine.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 1002/1003
5/8/24, 9:18 AM PDF Export

20.45 | Vulnerability Assessment (VA)

Vulnerability Assessment (VA). Cortex XDR/Cortex XSIAM vulnerability assessment enables you to identify and quantify the security vulnerabilities on an
endpoint in Cortex XDR/Cortex XSIAM. Relying on the information from Cortex XDR/Cortex XSIAM, you can easily mitigate and patch these vulnerabilities on all
endpoints in your organization.

20.46 | Windows Event Collector (WEC)

Windows Event Collector (WEC). The WEC runs on the Broker VM collecting event logs from Windows Servers, including Domain Controllers (DCs). The WEC
can be deployed in multiple setups, and can be connected directly to multiple event generators (DCs or Windows Servers) or routed using one or more WECs.
Behind each WEC there may be multiple generating sources.

20.47 | XSIAM Command Center

The XSIAM Command Center dashboard provides a dynamic overview of your security operations process, and supports drilldowns to additional dashboards
and dedicated pages. The dashboard visualizes the current status of your tenant and its activity during the selected timeframe. Click on any element to drilldown
to dashboards or pages displaying data filtered by your selection.

https://docs-cortex.paloaltonetworks.com/internal/api/webapp/print/3b73597a-a20d-41ed-8ec9-00c522e6f663 1003/1003