Palo Al To Full Guide
Uploaded by
גל משקוביץPalo Al To Full Guide
Uploaded by
גל משקוביץCortex XDR Documentation
Confidential - Copyright © Palo Alto Networks
Confidential - Copyright © Palo Alto Networks
Cortex XDR Documentation
Displayed in the header
1. Define endpoint groups
2. Manage endpoint profiles
3. Endpoint data collection
4. Configure global agent settings
5. Guidelines for keeping Cortex XDR agents and content updated
6. Step 5: Define data sources
7. Configure server settings
8. Configure security settings
9. Log forwarding
9.1. Forward logs from Cortex XDR to external services
9.1.1. Integrate a syslog receiver
9.1.2. Integrate Slack for outbound notifications
9.1.3. Configure notification forwarding
9.1.4. Monitor administrative activity
9.2. Log notification formats
9.2.1. Management audit log messages
9.2.2. Alert notification format
9.2.3. Agent Audit log notification format
9.2.4. Management Audit log notification format
9.2.5. Log format for IOC and BIOC alerts
9.2.6. Analytics log format
9.2.7. Log formats
10. Automation rules
10.1. Manage automation rules
10.2. Automation settings
10.3. Automation rule actions
10.4. Automation Audit Log
11. Manage user roles and access management
11.1. Manage user roles
11.2. Manage user access
11.2.1. User access reference information
11.3. Manage user scope
12. Endpoint security
12.1. Endpoint protection
12.1.1. Malware protection
12.1.2. Exploit protection
12.1.3. File analysis and protection flow
12.1.4. Endpoint protection capabilities
12.1.5. Endpoint protection modules
12.1.6. Processes protected by exploit security policy
12.1.7. WildFire analysis concepts
12.1.8. Guidelines for keeping Cortex XDR agents and content updated
12.1.9. About content updates
12.1.10. Endpoint data collection
12.2. Install and manage endpoints
12.2.1. Set up endpoint protection
12.2.1.1. Set up endpoint profiles and exception rules
12.2.1.1.1. Set up malware prevention profiles
12.2.1.1.2. Set up exploit prevention profiles
12.2.1.1.3. Set up agent settings profiles
12.2.1.1.4. Set up restrictions prevention profiles
12.2.1.1.5. Set up exception profiles and rules
Displayed in the footer
Page 2 of 952
Cortex XDR Documentation
Displayed in the header
12.2.1.1.5.1. Exception configuration
12.2.1.1.5.2. Alert exclusions
12.2.1.1.5.2.1. Add an alert exclusion rule
12.2.1.1.5.3. Add an IOC or BIOC rule exception
12.2.1.1.5.4. Add a disable prevention rule
12.2.1.1.5.5. Add a disable injection and prevention rule
12.2.1.1.5.6. Add a support exception rule
12.2.1.1.5.7. Add a legacy exception rule
12.2.1.1.5.7.1. Add a new exceptions security profile
12.2.1.1.5.7.2. Add a global endpoint policy exception
12.2.1.2. Define endpoint groups
12.2.1.3. Configure global agent settings
12.2.1.4. Apply profiles to endpoints
12.2.1.5. Create an agent installation package
12.2.1.5.1. Manage an agent installation package
12.2.1.6. Harden endpoint security
12.2.1.6.1. Device control
12.2.1.6.2. Host firewall
12.2.1.6.2.1. Host firewall for Windows
12.2.1.6.2.2. Host firewall for macOS
12.2.1.6.3. Disk encryption
12.2.1.6.4. Host Inventory
12.2.1.6.5. Vulnerability Assessment
12.2.1.7. Set a Cortex XDR agent Critical Environment version
12.2.1.8. Set an application proxy for Cortex XDR agents
12.2.1.9. Pairing Prisma Cloud Compute with Cortex XDR
12.2.2. Manage endpoint protection
12.2.2.1. Manage endpoint tags
12.2.2.2. Set an alias for an endpoint
12.2.2.3. Manage endpoint prevention profiles
12.2.2.4. Upgrade Cortex XDR agents
12.2.2.5. Restart agent
12.2.2.6. Uninstall the Cortex XDR agent
12.2.2.7. Delete Cortex XDR agents
12.2.2.8. Manage agent tokens
12.2.2.9. Retrieve support file password
12.2.2.10. Move agents between managing servers
12.2.2.11. Clear agent database
12.2.2.12. Send push notifications to iOS
12.2.2.13. Monitor agent operational status
12.2.2.14. Monitor agent activity
12.2.2.15. Monitor agent upgrade status
13. Detect threats and analyze data
13.1. Detection rules
13.1.1. What's an IOC?
13.1.1.1. IOC rule details
13.1.1.2. Create an IOC rule
13.1.2. What's a BIOC?
13.1.2.1. BIOC rule details
13.1.2.2. Create a BIOC rule
13.1.2.3. Manage Global BIOC Rules
13.1.3. What's a correlation rule?
13.1.3.1. Correlation rule details
13.1.3.2. Create a correlation rule
13.1.3.3. Manage correlation rules
13.1.3.4. Monitor correlation rules
13.1.4. Manage existing indicators
13.2. Analytics
13.2.1. Analytics engine
13.2.2. Analytics sensors
13.2.3. Coverage of MITRE Attack tactics
13.2.4. Analytics detection time intervals
13.2.5. Analytics alerts and Analytics BIOCs
13.2.6. Identity Analytics
13.2.7. Identity Threat Module
13.3. Forensic investigations
13.3.1. Manage an investigation
13.3.1.1. Create a new investigation
13.3.1.2. Edit an investigation
13.3.1.3. Close an investigation
13.3.1.4. User permissions
13.3.2. Data collection
13.3.2.1. Hunting
13.3.2.1.1. Create a hunt
13.3.2.1.2. Hunt results
13.3.2.1.3. Hunt status
13.3.2.2. Triage
13.3.2.2.1. Create a triage
13.3.2.2.2. Upload an offline triage package
13.3.2.2.3. Offline triage collection
13.3.2.2.4. Triage results
13.3.2.2.5. Triage status
13.3.3. Analysis and documentation
13.3.3.1. Review alerts
13.3.3.2. Investigation timeline
13.3.3.3. Key assets & artifacts
Displayed in the footer
Page 3 of 952
Cortex XDR Documentation
Displayed in the header
13.3.4. Export
13.4. Asset management
13.4.1. Vulnerability Assessment
13.4.2. Network configuration
13.4.2.1. Configure your network parameters
13.4.3. Cloud Compliance
13.4.4. Manage Asset Scores
13.4.5. Asset Inventory
13.4.5.1. All Assets
13.4.5.2. Specific Assets
13.4.6. Asset Roles
13.4.6.1. Manage Asset Roles for Users
13.4.6.1.1. Honey user
13.4.6.2. Manage Asset Roles for Endpoints
13.4.7. Cloud Inventory Assets
13.4.7.1. All Cloud Assets
13.4.7.2. Specific Cloud Assets
13.4.7.3. Manage Your Cloud Inventory Assets
14. Configure incidents and alerts
14.1. External integrations
14.2. Prioritize incidents with starring and scoring
14.2.1. Incident starring
14.2.2. Incident scoring
14.2.2.1. Set up incident scoring
14.3. Automation rules
14.3.1. Automation settings
14.3.2. Automation rule actions
14.3.3. Automation audit log
15. Investigate and respond to incidents
15.1. Incident handling
15.1.1. What are incidents?
15.1.2. Understanding the Incidents page
15.1.2.1. Incidents table view reference information
15.1.3. Manage incidents
15.1.3.1. Resolution reasons for incidents and alerts
15.2. Investigate artifacts and assets
15.2.1. Investigate an IP address
15.2.2. Investigate an asset
15.2.3. Investigate a host
15.2.4. Investigate a file and process hash
15.2.5. Investigate a user
15.3. Investigate alerts
15.3.1. Overview of the Alerts page
15.3.2. Triage and investigate alerts
15.3.2.1. Copy alerts
15.3.2.2. Analyze an alert
15.3.2.3. Create profile exceptions
15.3.2.4. Add a file path to a malware profile allow list
15.3.2.5. Create a featured alert field
15.3.2.6. View generating BIOC or IOC rule
15.3.2.7. Retrieve additional alert details
15.3.2.8. Export alert details to a file
15.3.2.9. Exclude an alert
15.3.2.10. Investigate contributing events
15.3.2.11. Query incident and alert data
15.3.2.12. Manage automation rules
15.3.3. Alert investigation views
15.3.3.1. Alert side panel
15.3.3.2. Causality view
15.3.3.3. Network causality view
15.3.3.4. Cloud causality view
15.3.3.5. SaaS causality view
15.3.3.6. Analytics alert view
15.3.3.7. Timeline
15.4. Investigate endpoints
15.4.1. Overview of the Action Center
15.4.1.1. Initiate and monitor endpoint actions
15.4.1.2. Action Center reference information
15.4.2. Manage endpoints
15.4.3. Retrieve files from an endpoint
15.4.4. Retrieve support logs from an endpoint
15.4.5. Retrieve support file password
15.4.6. Scan an endpoint for malware
Displayed in the footer
Page 4 of 952
Cortex XDR Documentation
Displayed in the header
15.5. Investigate files
15.5.1. Manage file execution
15.5.2. Manage quarantined files
15.5.3. Review WildFire analysis details
15.5.4. Import file hash exceptions
15.6. Response actions
15.6.1. Initiate a Live Terminal session
15.6.2. Isolate an endpoint
15.6.3. Pause endpoint protection
15.6.4. Remediate changes from malicious activity
15.6.5. Run scripts on an endpoint
15.6.6. Search and destroy malicious files
15.6.7. Manage external dynamic lists
15.6.8. Collect a memory image
15.7. Build XQL queries
15.7.1. About the Query Builder
15.7.2. How to build XQL queries
15.7.2.1. Get started with XQL queries
15.7.2.2. Useful XQL user interface features
15.7.2.3. XQL Query best practices
15.7.2.4. Expected results when querying fields
15.7.2.5. Create XQL query
15.7.2.6. Review XQL query results
15.7.2.7. Translate to XQL
15.7.2.8. Graph query results
15.7.3. XQL query entities
15.7.3.1. Create authentication query
15.7.3.2. Create event log query
15.7.3.3. Create file query
15.7.3.4. Create image load query
15.7.3.5. Create network connections query
15.7.3.6. Create network query
15.7.3.7. Create process query
15.7.3.8. Create registry query
15.7.3.9. Query across all entities
15.7.4. Edit and rerun queries in Query Center
15.7.4.1. Query Center reference information
15.7.5. Manage scheduled queries
15.7.5.1. Scheduled Queries reference information
15.7.6. Manage your personal query library
15.8. Dashboards
15.8.1. About dashboards
15.8.2. Predefined dashboards
15.8.3. Custom dashboards
15.8.3.1. Build a custom dashboard
15.8.3.2. Manage your Widget Library
15.8.3.3. Create custom XQL widgets
15.8.3.4. Configure fixed dashboard filters
15.8.3.5. Configure dashboard drilldowns
15.8.3.5.1. Variables in drilldowns
15.8.4. Reports
15.8.4.1. Report templates
15.8.4.2. Run or schedule reports
15.9. Quick Launcher
15.10. Research a known threat
16. Data management
16.1. Broker VM
16.1.1. What is the Broker VM?
16.1.2. Set up and configure Broker VM
16.1.2.1. Broker VM image installations
16.1.2.1.1. Set up Broker VM on Alibaba Cloud
16.1.2.1.2. Set up Broker VM on Amazon Web Services
16.1.2.1.3. Set up Broker VM on Google Cloud Platform (GCP)
16.1.2.1.4. Set up Broker VM on KVM using Ubuntu
16.1.2.1.5. Set up Broker VM on Microsoft Azure
16.1.2.1.6. Set up Broker VM on Microsoft Hyper-V
16.1.2.1.7. Set up Broker VM on Nutanix Hypervisor
16.1.2.1.8. Set up Broker VM on VMware ESXi using vSphere Client
16.1.2.2. Broker VM data collector applets
16.1.2.2.1. Activate Apache Kafka Collector
16.1.2.2.2. Activate CSV Collector
16.1.2.2.3. Activate Database Collector
16.1.2.2.4. Activate Files and Folders Collector
16.1.2.2.5. Activate FTP Collector
16.1.2.2.6. Activate Local Agent Settings
16.1.2.2.7. Activate NetFlow Collector
16.1.2.2.8. Activate Network Mapper
16.1.2.2.9. Activate Pathfinder
16.1.2.2.10. Activate Syslog Collector
16.1.2.2.11. Activate Windows Event Collector
16.1.2.2.11.1. Activate Windows Event Collector on Windows Core
16.1.2.2.11.2. Renew WEC certificates
Displayed in the footer
Page 5 of 952
Cortex XDR Documentation
Displayed in the header
16.1.3. Manage Broker VM
16.1.3.1. View Broker VM details
16.1.3.2. Edit Broker VM Configuration
16.1.3.3. Increase Broker VM storage allocated for data caching
16.1.3.4. Monitor Broker VM using Prometheus
16.1.3.5. Collect Broker VM Logs
16.1.3.6. Upgrade Broker VM
16.1.3.7. Import Broker VM Configuration
16.1.3.8. Open Live Terminal
16.1.3.9. Add Broker VM to cluster
16.1.3.10. Switchover Primary Node in Cluster
16.1.3.11. Remove from Cluster
16.1.4. Broker VM High Availability Cluster
16.1.4.1. Configure High Availability Cluster
16.1.4.2. Manage Broker VM clusters
16.1.4.2.1. View cluster details
16.1.4.2.2. Edit cluster
16.1.4.2.3. Add applet to cluster
16.1.4.2.4. Add Broker VM to cluster
16.1.4.2.5. Remove cluster
16.1.5. Broker VM notifications
16.1.6. Monitor Broker VM activity
16.2. XDR Collectors
16.2.1. XDR Collector audit logs
16.2.2. XDR Collector machine requirements and supported operating systems
16.2.3. Resources required to enable access to XDR Collectors
16.2.4. Manage XDR Collectors
16.2.4.1. Configure the XDR Collector upgrade scheduler
16.2.4.2. Create an XDR Collector installation package
16.2.4.3. Install the XDR Collector installation package for Windows
16.2.4.3.1. Install the XDR Collector on Windows using the MSI
16.2.4.3.2. Install the XDR Collector on Windows using Msiexec
16.2.4.4. Install the XDR Collector installation package for Linux
16.2.4.5. XDR Collectors installation resource for Windows and Linux
16.2.4.6. Set an application proxy for XDR Collectors
16.2.4.7. Upgrade XDR Collectors
16.2.4.8. Uninstall the XDR Collector
16.2.4.9. Set an alias for an XDR Collector machine
16.2.5. Define XDR Collector machine groups
16.2.6. About Cortex XDR Collector content updates
16.2.7. XDR Collector profiles
16.2.8. Add an XDR Collector profile for Windows
16.2.8.1. Ingest logs from Windows DHCP using Elasticsearch Filebeat
16.2.8.2. Ingest Windows DNS debug logs using Elasticsearch Filebeat
16.2.9. Add an XDR Collector profile for Linux
16.2.10. Apply profiles to collection machine policies
16.2.11. XDR Collector datasets
16.3. Data Ingestion
16.3.1. Visibility of logs and alerts from external sources
16.3.2. Visibility of Cortex XDR audit and authentication logs
16.3.3. External data ingestion vendor support
16.3.4. Palo Alto Networks integrations
16.3.4.1. About Palo Alto Networks integrations
16.3.4.2. Ingest data from Next-Generation Firewall
16.3.4.2.1. Ingest Next-Generation Firewall logs using the Syslog collector
16.3.4.3. Ingest data from Prisma Access
16.3.4.4. Ingest alerts from Prisma Cloud Compute
16.3.4.5. Ingest alerts from Prisma Cloud
16.3.4.6. Ingest detection data from Strata Logging Service
16.3.4.7. Ingest alerts and assets from IoT Security
16.3.4.8. Collecting URL and File log types
16.3.4.8.1. Detectors connected to URL and File log types
16.3.5. External data ingestion
16.3.5.1. External applications
16.3.5.2. Ingest network connection logs
16.3.5.2.1. Ingest network flow logs from Amazon S3
16.3.5.2.1.1. Create an assumed role
16.3.5.2.1.2. Configure data collection from Amazon S3 manually
16.3.5.2.2. Ingest network Route 53 logs from Amazon S3
16.3.5.2.3. Ingest logs from Check Point firewalls
16.3.5.2.4. Ingest logs from Cisco ASA firewalls and AnyConnect
16.3.5.2.5. Ingest logs from Corelight Zeek
16.3.5.2.6. Ingest logs from Fortinet Fortigate firewalls
16.3.5.2.7. Ingest logs and data from a GCP Pub/Sub
16.3.5.2.8. Ingest logs from Microsoft Azure Event Hub
16.3.5.2.9. Ingest network flow logs from Microsoft Azure Network Watcher
16.3.5.2.10. Ingest logs and data from Okta
16.3.5.2.11. Ingest logs from Windows DHCP using Elasticsearch Filebeat
16.3.5.2.12. Ingest logs from Zscaler Internet Access
16.3.5.2.13. Ingest logs from Zscaler Private Access
16.3.5.3. Ingest authentication logs and data
16.3.5.3.1. Ingest audit logs from AWS Cloud Trail
16.3.5.3.2. Ingest logs from Microsoft Azure Event Hub
16.3.5.3.3. Ingest logs and data from a GCP Pub/Sub
16.3.5.3.4. Ingest logs and data from Google Workspace
16.3.5.3.5. Ingest logs and data from Microsoft 365
16.3.5.3.6. Ingest logs from Microsoft Office 365
16.3.5.3.7. Ingest logs and data from Okta
16.3.5.3.8. Ingest logs and data from OneLogin
16.3.5.3.9. Ingest authentication logs from PingFederate
Displayed in the footer
Page 6 of 952
Cortex XDR Documentation
Displayed in the header
16.3.5.3.10. Ingest authentication logs and data from PingOne
16.3.5.4. Ingest operation and system logs from cloud providers
16.3.5.4.1. Ingest generic logs from Amazon S3
16.3.5.4.2. Ingest logs from Amazon CloudWatch
16.3.5.4.3. Ingest logs and data from a GCP Pub/Sub
16.3.5.4.4. Ingest logs from Google Kubernetes Engine
16.3.5.4.5. Ingest logs from Microsoft Azure Event Hub
16.3.5.4.6. Ingest logs and data from Okta
16.3.5.5. Ingest endpoint data
16.3.5.6. Ingest cloud assets
16.3.5.6.1. Ingest cloud assets from AWS
16.3.5.6.2. Ingest cloud assets from Google Cloud Platform
16.3.5.6.3. Ingest cloud assets from Microsoft Azure
16.3.5.7. Additional log ingestion methods
16.3.5.7.1. Ingest logs from a Syslog receiver
16.3.5.7.2. Ingest Apache Kafka events as datasets
16.3.5.7.3. Ingest CSV files as datasets
16.3.5.7.4. Ingest database data as datasets
16.3.5.7.5. Ingest logs in a network share as datasets
16.3.5.7.6. Ingest FTP files as datasets
16.3.5.7.7. Ingest NetFlow flow records as datasets
16.3.5.7.8. Set up an HTTP log collector to receive logs
16.3.5.7.9. Ingest logs from BeyondTrust Privilege Management Cloud
16.3.5.7.10. Ingest logs and data from Box
16.3.5.7.11. Ingest logs and data from Dropbox
16.3.5.7.12. Ingest logs from Elasticsearch Filebeat
16.3.5.7.13. Ingest logs from Forcepoint DLP
16.3.5.7.14. Ingest logs from Proofpoint Targeted Attack Protection
16.3.5.7.15. Ingest logs and data from Salesforce.com
16.3.5.7.16. Ingest data from ServiceNow CMDB
16.3.5.7.17. Ingest report data from Workday
16.3.5.7.18. Ingest external alerts
16.3.6. Verifying collector connectivity
16.4. Dataset management
16.4.1. What are datasets?
16.4.2. Lookup datasets
16.4.2.1. Import a lookup dataset
16.4.2.2. Download JSON file of lookup dataset
16.4.2.3. Set time to live for lookup datasets
16.4.3. Monitor datasets activity
16.5. Parsing Rules
16.5.1. What are Parsing Rules?
16.5.2. Parsing Rules editor views
16.5.3. Parsing Rules file structure and syntax
16.5.3.1. INGEST
16.5.3.2. COLLECT
16.5.3.3. CONST
16.5.3.4. RULE
16.5.4. Create Parsing Rules
16.5.5. Troubleshooting Parsing rules errors
16.5.6. Parsing Rules Raw Dataset
16.6. Manage Event Forwarding
16.6.1. Endpoints Event Forwarding - included/excluded fields by event type
16.7. Manage compute units
16.7.1. Compute units usage
17. Cortex XDR XQL
17.1. Get started with XQL
17.1.1. XQL language features
17.1.2. XQL Language Structure
17.1.2.1. Adding comments in queries
17.1.3. Supported operators
17.1.4. Datasets and presets
17.1.5. About examples
17.1.6. JSON functions
17.1.7. How to filter for empty values in the results table
17.2. Build XQL queries
17.2.1. About the Query Builder
17.2.2. How to build XQL queries
17.2.2.1. Get started with XQL queries
17.2.2.2. Useful XQL user interface features
17.2.2.3. XQL Query best practices
17.2.2.4. Expected results when querying fields
17.2.2.5. Create XQL query
17.2.2.6. Review XQL query results
17.2.2.7. Translate to XQL
17.2.2.8. Graph query results
17.2.3. XQL query entities
17.2.3.1. Create authentication query
17.2.3.2. Create event log query
17.2.3.3. Create file query
17.2.3.4. Create image load query
17.2.3.5. Create network connections query
17.2.3.6. Create network query
17.2.3.7. Create process query
Displayed in the footer
Page 7 of 952
Cortex XDR Documentation
Displayed in the header
17.2.3.8. Create registry query
17.2.3.9. Query across all entities
17.2.4. Edit and rerun queries in Query Center
17.2.4.1. Query Center reference information
17.2.5. Manage scheduled queries
17.2.5.1. Scheduled Queries reference information
17.2.6. Manage your personal query library
17.3. Stages
17.3.1. alter
17.3.2. arrayexpand
17.3.3. bin
17.3.4. call
17.3.5. comp
17.3.6. config
17.3.6.1. case_sensitive
17.3.6.2. timeframe
17.3.7. dedup
17.3.8. fields
17.3.9. filter
17.3.10. getrole
17.3.11. iploc
17.3.12. join
17.3.13. limit
17.3.14. replacenull
17.3.15. sort
17.3.16. Tag
17.3.17. target
17.3.18. top
17.3.19. transaction
17.3.20. union
17.3.21. view
17.3.22. windowcomp
17.4. Functions
17.4.1. add
17.4.2. approx_count
17.4.3. approx_quantiles
17.4.4. approx_top
17.4.5. array_all
17.4.6. array_any
17.4.7. arrayconcat
17.4.8. arraycreate
17.4.9. arraydistinct
17.4.10. arrayfilter
17.4.11. arrayindex
17.4.12. arrayindexof
17.4.13. array_length
17.4.14. arraymap
17.4.15. arraymerge
17.4.16. arrayrange
17.4.17. arraystring
17.4.18. avg
17.4.19. coalesce
17.4.20. concat
17.4.21. convert_from_base_64
17.4.22. count
17.4.23. count_distinct
17.4.24. current_time
17.4.25. date_floor
17.4.26. divide
17.4.27. earliest
17.4.28. extract_time
17.4.29. extract_url_host
17.4.30. extract_url_pub_suffix
17.4.31. extract_url_registered_domain
17.4.32. first
17.4.33. first_value
17.4.34. floor
17.4.35. format_string
17.4.36. format_timestamp
17.4.37. if
17.4.38. incidr
17.4.39. incidr6
17.4.40. incidrlist
17.4.41. int_to_ip
17.4.42. ip_to_int
Displayed in the footer
Page 8 of 952
Cortex XDR Documentation
Displayed in the header
17.4.43. json_extract
17.4.44. json_extract_array
17.4.45. json_extract_scalar
17.4.46. json_extract_scalar_array
17.4.47. lag
17.4.48. last
17.4.49. last_value
17.4.50. latest
17.4.51. len
17.4.52. list
17.4.53. lowercase
17.4.54. ltrim, rtrim, trim
17.4.55. max
17.4.56. median
17.4.57. min
17.4.58. multiply
17.4.59. object_merge
17.4.60. object_create
17.4.61. parse_epoch
17.4.62. parse_timestamp
17.4.63. pow
17.4.64. rank
17.4.65. regexcapture
17.4.66. regextract
17.4.67. replace
17.4.68. replex
17.4.69. round
17.4.70. row_number
17.4.71. split
17.4.72. stddev_population
17.4.73. stddev_sample
17.4.74. string_count
17.4.75. subtract
17.4.76. sum
17.4.77. time_frame_end
17.4.78. timestamp_diff
17.4.79. timestamp_seconds
17.4.80. to_boolean
17.4.81. to_epoch
17.4.82. to_float
17.4.83. to_integer
17.4.84. to_json_string
17.4.85. to_number
17.4.86. to_string
17.4.87. to_timestamp
17.4.88. uppercase
17.4.89. values
17.4.90. var
18. Reference
18.1. RBAC permissions
18.1.1. Role permissions by components
18.1.2. Default PANW roles
18.1.2.1. Account Admin
18.1.2.2. Deployment Admin
18.1.2.3. Instance Administrator
18.1.2.4. Investigation Admin
18.1.2.5. Investigator
18.1.2.6. IT Admin
18.1.2.7. Privileged Investigator
18.1.2.8. Privileged IT Admin
18.1.2.9. Privileged Responder
18.1.2.10. Privileged Security Admin
18.1.2.11. Responder
18.1.2.12. Scoped Endpoint Admin
18.1.2.13. Security Admin
18.1.2.14. Viewer
18.2. Microsoft Windows security auditing setup
18.2.1. Enable security auditing event IDs
18.2.1.1. Enable security auditing event IDs with GPO
18.2.1.2. Set up local machine security auditing without GPO
18.2.1.3. Additional setup for Active Directory Certificate Services (ADCS) events
18.2.1.4. Enable auditing access to AD domain objects - 4662
18.2.2. Enable additional event logs using Event Viewer
18.2.3. Enable LDAP server events logging (1644)
18.2.3.1. Enable LDAP server events logging using RegEdit
18.2.3.2. Enable LDAP server events logging using GPO
Displayed in the footer
Page 9 of 952
Cortex XDR Documentation
Displayed in the header
18.2.3.3. Validate log collection for LDAP Server events
19. Glossary
19.1. Alert
19.2. Alert Exclusion
19.3. Analytics behavioral indicators of compromise (ABIOCs)
19.4. Attack Surface Management (ASM)
19.5. Behavioral indicators of compromise (BIOCs)
19.6. Bring Your Own Machine Learning (BYOML)
19.7. Broker Virtual Machine (Broker VM)
19.8. Broker Virtual Machine Fully Qualified Domain Name (Broker VM FQDN)
19.9. Causality Group Owner (CGO)
19.10. Causality View
19.11. Cloud Detection and Response (CDR)
19.12. Cortex Data Model (XDM)
19.13. Cortex Query Language (XQL)
19.14. Dataset
19.15. Elasticsearch Filebeat
19.16. Endpoint Detection and Response (EDR)
19.17. Endpoint Protection Platform (EPP)
19.18. Exception
19.19. Exception vs Alert Exclusion
19.20. Extended Detection and Response (XDR)
19.21. External Dynamic List (EDL)
19.22. Filebeat
19.23. Forensics
19.24. Fully Qualified Domain Name (FQDN)
19.25. Identity Threat Detection and Response (ITDR)
19.26. Incident
19.27. Indicators of compromise (IOCs)
19.28. IT Metrics Dashboard
19.29. Managed Threat Hunting (MTH)
19.30. Management, Reporting, and Compliance
19.31. MITRE ATT&CK Framework Coverage Dashboard
19.32. Next-Generation Firewall (NGFW)
19.33. Notebooks
19.34. On-write File Protection
19.35. Playbook
19.36. Prisma
19.37. Script
19.38. Security Information and Event Management (SIEM)
19.39. Security Orchestration, Automation, and Response (SOAR)
19.40. Threat Intelligence Platform (TIP)
19.41. Unified Extensible Firmware Interface Protection (UEFI Protection)
19.42. User and Entity Behavior Analytics (UEBA)
19.43. Virtual Machine
19.44. Vulnerability Assessment (VA)
19.45. Windows Event Collector (WEC)
19.46. XDR Collector (XDRC)
19.47. XSIAM Command Center
Displayed in the footer
Page 10 of 952
Cortex XDR Documentation
Displayed in the header
1 | Define endpoint groups
Abstract
Define an endpoint group and then apply policy rules and manage specific endpoints.
You can define an endpoint group and then apply policy rules and manage specific endpoints. If you set up Cloud Identity Engine, you can also leverage your
Active Directory user, group, and computer details to define endpoint groups.
Do one of the following :
Create a dynamic group by enabling Cortex XDR to populate your endpoint group dynamically using endpoint characteristics, such as an endpoint tag,
partial hostname or alias, full or partial domain or workgroup name, IP address, range or subnets, installation type (VDI, temporary session or standard
endpoint), agent version, endpoint type (workstation, server, mobile), 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.
How to define an endpoint group
1. From Cortex XDR, select Endpoints → Endpoint Groups → +Add Group.
2. Select one of the following:
Create New to create an endpoint group from scratch
Upload From File using plain text files with a new line separator, to populate a static endpoint group from a file containing IP addresses,
hostnames, or aliases.
3. Enter a Group Name and optional description to identify the endpoint group. The name you assign to the group will be visible when you assign endpoint
security profiles to endpoints.
4. Determine the endpoint properties for creating an endpoint group:
Dynamic: Use the filters to define the criteria you want to use to dynamically populate an endpoint group. Dynamic groups support multiple criteria
selections and can use AND or OR operators. For endpoint names and aliases, and domains and workgroups, you can use * to match any string
of characters. As you apply filters, Cortex XDR 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 XDR. You can select up to 250 endpoints.
Disconnecting Cloud Identity Engine in your Cortex XDR deployment can affect existing endpoint groups and policy rules based on Active Directory
properties.
5. Create the endpoint group.
After you save your endpoint group, it is ready for use to assign security profiles to endpoints and in other places where you can use endpoint groups.
At any time, you can return to the 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: Remove the endpoint group.
Save as new: Duplicate the endpoint group and save it as a new group.
Export group: Export the list of endpoints that match the endpoint group criteria to a tab separated values (TSV) file.
View endpoints: Pivot from an endpoint group to a filtered list of endpoints on the Endpoint Administration page where you can quickly view and initiate
actions on the endpoints within the group.
2 | Manage endpoint profiles
Abstract
Endpoint security profiles can be used immediately, or customized, to protect your endpoints from threats.
Cortex XDR provides default security profiles that you can use out of the box to immediately begin protecting your endpoints from threats. These profiles are
applied to endpoints by mapping them to policies and then mapping the policies to endpoints.
Displayed in the footer
Page 11 of 952
Cortex XDR Documentation
Displayed in the header
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.
Related information
Set up malware prevention profiles
Set up exploit prevention profiles
Set up agent settings profiles
Set up restrictions prevention profiles
Set up exception profiles and rules
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.
When you enable behavioral threat protection or EDR data collection in your endpoint security policy, the Cortex XDR agent can also continuously monitor
endpoint activity for malicious event chains identified by Palo Alto Networks. The endpoint data that the Cortex XDR agent collects when you enable these
capabilities varies by platform type.
Agents with Cortex XDR Pro per Endpoint apply limits and filters on network, file, and registry logs. To expand these limits and filters requires the Extended
Threat Hunting Data (XTH) add-on.
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)
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
Displayed in the footer
Page 12 of 952
Cortex XDR Documentation
Displayed in the header
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
Move and later)
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)
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)
Displayed in the footer
Page 13 of 952
Cortex XDR Documentation
Displayed in the header
Category Events Attributes
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)
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.
Displayed in the footer
Page 14 of 952
Cortex XDR Documentation
Displayed in the header
Category Events Attributes
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.
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
Displayed in the footer
Page 15 of 952
Cortex XDR Documentation
Displayed in the header
Category Events Attributes
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 collected for Windows endpoints
In Traps 6.1.3 and later releases, Cortex XDR and Traps agents can send the following Windows Event Logs to the tenant.
For more information on how to set up Windows event logs collection, see Microsoft Windows security auditing setup.
Path Provider Event IDs And Description
Application EMET
Application Windows Error Reporting Only for Windows Error Reporting (WER) events when an application
stops unexpectedly
Application Microsoft-Windows-User 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.
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
Displayed in the footer
Page 16 of 952
Cortex XDR Documentation
Displayed in the header
Path Provider Event IDs And Description
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 Local Modifications (Levels 0, 2, 4)
Security
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
Displayed in the footer
Page 17 of 952
Cortex XDR Documentation
Displayed in the header
Path Provider Event IDs And Description
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
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
Displayed in the footer
Page 18 of 952
Cortex XDR Documentation
Displayed in the header
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
Displayed in the footer
Page 19 of 952
Cortex XDR Documentation
Displayed in the header
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
Displayed in the footer
Page 20 of 952
Cortex XDR Documentation
Displayed in the header
Category Events Attributes
Files Create Full path of the file
*Requires XTH add-on Open Hash of the file
Write For specific files only and only if the file was
written.
Delete
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
4 | Configure global agent settings
Abstract
Learn how to configure the Cortex XDR agent global settings that operate on your endpoints.
In addition to 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 XDR 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 XDR 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.
Displayed in the footer
Page 21 of 952
Cortex XDR Documentation
Displayed in the header
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.
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 XDR
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 XDR 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 XDR 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 About Content
Updates in the Cortex XDR Administrator Guide.
4. Configure content bandwidth allocated for all endpoints.
To control the amount of bandwidth allocated in your network to Cortex XDR content updates, assign a Content bandwidth management value between
20-10,000 Mbps. To help you with this calculation, Cortex XDR 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 XDR 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 XDR to automatically retrieve the files.
After Cortex XDR receives the data, it automatically analyzes the memory contents and renders a verdict. When the analysis is complete, Cortex XDR
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 XDR to automatically create
and distribute exceptions based on the Advanced Analysis results.
a. Configure the desired options:
Enable Cortex XDR to automatically upload defined alert data files for advanced analysis. Advanced Analysis increases the Cortex XDR
exploit protection module accuracy.
Automatically apply Advanced Analysis exceptions to your Global Exceptions list. This will apply all Advanced Analysis exceptions
suggested by Cortex XDR, 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 XDR. 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 XDR 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.
Displayed in the footer
Page 22 of 952
Cortex XDR Documentation
Displayed in the header
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
XDR receives a Benign Low Confidence verdict, the agent enforces the Malware Security profile settings you currently have in place (Run local analysis
to determine the file verdict, Allow, or Block).
Disabling this capability takes immediate effect on new hashes, fresh agent installations, and existing security policies. It could take up to a week to take
effect on existing agents in your environment pending agent caching.
9. Enable Informative BTP Alerts.
Behavioral threat protection (BTP) alerts have been given unique and informative names and descriptions, to provide immediate clarity into the events
without having to drill down into each alert. Enable to display of the informative BTP rule alert names and descriptions. After you update the settings, new
alerts include the changes while already existing alerts remain unaffected.
If you have any Cortex XDR filters, starring policies, exclusion policies, scoring rules, log forwarding queries, or automation rules configured for
XSIAM/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.
5 | Guidelines for keeping Cortex XDR agents and content updated
Abstract
Learn more about how to control Cortex XDR agent and content upgrades.
This document covers a recommended strategy and best practices for managing agent and content updates to help reduce the risk of downtime in a
production environment, while helping ensure timely delivery of security content and capabilities.
Keeping Cortex XDR agents up-to-date is essential for protecting against evolving threats and vulnerabilities. Regular updates ensure the latest security
features for malware and exploit prevention, and compatibility with the latest software environments, which helps reduce the risk of attacks. This can also help
organizations meet regulatory standards while maintaining strong overall protection.
Content updates, such as new threat intelligence or detection logic, are critical for defending against newly discovered cyber threats and malware and are
designed to ensure that systems remain protected against the latest attacks. Content updates address compatibility issues as well, helping achieve smooth
operations alongside the Cortex XDR agent. Without regular content updates, security solutions may fail to detect new or evolving threats, leaving systems
vulnerable to attacks.
When planning Cortex XDR agent upgrades and content updates, consult with the appropriate stakeholders and teams and follow the change management
strategy in your organization.
The Cortex XDR agent can retrieve content updates immediately as they become available, after a pre-configured delay period of up to 30 days, or you can
choose to select a specific version.
Cortex XDR can be configured to manage the deployment of agent and content updates by adjusting the following settings:
AGENT UPGRADE SETTINGS
Agent settings per endpoint:
Displayed in the footer
Page 23 of 952
Cortex XDR Documentation
Displayed in the header
Agent Auto-Upgrade is disabled by default. Before enabling agent auto-upgrade for Cortex XDR agents, make sure to consult with all relevant
stakeholders in your organization. Enabling this option allows you to define the scope of the automatic updates, such as upgrading to the latest agent
release, one release prior, only maintenance releases, or maintenance releases within a specific version.
Upgrade Rollout includes two options: Immediate, where the Cortex XDR agent automatically receives new releases, including maintenance updates
and features, and Delayed, which lets you set a delay of 7 to 45 days after a version is released before upgrading endpoints.
Global agent settings: Configure the Cortex XDR agent upgrade scheduler and the number of parallel upgrades to apply to all endpoints in your
organization. You can also schedule the upgrade task for specific days of the week and set a specific time range for the upgrades.
CONTENT UPDATE SETTINGS
Content updates per endpoint:
Content Auto-Update is enabled by default and automatically retrieves the latest content before deploying it on the endpoint. If you disable content
updates, the agent will stop fetching updates from the Cortex XDR tenant and will continue to operate with the existing content on the endpoint.
Content Rollout: The Cortex XDR agent can retrieve content updates immediately as they become available, after a pre-configured delay period of up
to 30 days, or you can choose to select a specific version.
Global content updates: Configure the content update cadence and bandwidth allocation within your organization. To enforce immediate protection against
the latest threats, enable minor content updates. Otherwise, the content updates in your network occur only on major releases.
Guidelines for planning Cortex XDR agent upgrades
Use a phased rollout plan by creating batches for deploying updates. The specifics may vary based on your organization and its structure. Start with a control
group, then deploy to 10% of your organization. Subsequently, allocate the remaining upgrades in batches that best suit your organization until achieving a full
100% rollout.
Example 3.
The following is an example of a rollout plan for deploying a Cortex XDR agent upgrade:
Phase 1: Control group rollout: Start by selecting a control group of endpoints as early adopters. This group should consist of a diverse range of operating
systems, devices, applications, and servers, with a focus on low-risk endpoints. After a defined testing period, such as one week, assess for any issues. If no
problems are found, move to the next phase.
Phase 2: 10% rollout: Expand the rollout to 10% of the organization’s endpoints. This group should maintain the same variety as the control group but include
low- to medium-risk endpoints. Monitor performance during the set period. If the rollout is successful with no issues, proceed to the next phase.
Phase 3: 40% rollout: After confirming the success of the 10% rollout, extend the deployment to 40% of the organization. Continue including a variety of
endpoints while gradually incorporating some medium-risk endpoints. Ensure thorough testing during this phase before moving forward.
Phase 4: 80% rollout: Extend the deployment to 80% of the organization's endpoints. This batch should include a wide variety of endpoints, incorporating
both medium and high-risk systems. After a careful monitoring period and confirmation that everything is stable, move to the final phase.
Phase 5: Full rollout: Complete the rollout by updating the remaining 20% of the organization’s endpoints. By this point, the majority of systems should have
been thoroughly tested, reducing the risk of issues in the final stage. Once complete, 100% of the organization will be updated.
Guidelines for planning content updates
Content updates are typically provided on a weekly basis. Use a phased rollout plan by creating batches for deploying updates. Start with a control group,
then deploy to 10% of your organization. Subsequently, allocate the remaining upgrades in batches that best suit your organization until achieving a full 100%
rollout.
Example 4.
The following is an example of a rollout plan over a period of one week for deploying content updates:
Phase 1: Control group rollout: Keep the default configuration set to deploy content updates immediately.
Phase 2: 10% rollout: Content is automatically deployed on day 2 following a delay period defined in the profile.
Phase 3: 60% rollout: Content is automatically deployed on day 3 following a delay period defined in the profile.
Displayed in the footer
Page 24 of 952
Cortex XDR Documentation
Displayed in the header
Phase 4: Full rollout: Increase the deployment to include medium and high-risk systems, until the entire organization is updated.
How to configure agent and content update settings
The following information will help you select and configure the update settings.
Cortex XDR agent upgrades
Configure one or more of the settings described in this section to keep your Cortex XDR agents up-to-date.
Distribute agent upgrades to selected endpoints
1. Create an agent installation package for each operating system version for which you want to upgrade the Cortex XDR agent.
Note the installation package names.
2. Select 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.
You can install the Cortex XDR agent on Linux endpoints using a package manager. If you do not want to use the package manager, clear the option
Upgrade to installation by package manager.
When you upgrade an agent on a Linux endpoint that is not using a package manager, Cortex XDR upgrades the installation process by default
according to the endpoint Linux distribution.
The Cortex XDR agent keeps the name of the original installation package after every upgrade.
5. Upgrade.
Cortex XDR 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).
Custom dashboards that include upgrade status widgets, and the All Endpoints page display upgrade status.
During the upgrade process, the endpoint operating system might request a reboot. However, you do not have to perform the reboot for the Cortex
XDR agent upgrade process to complete it successfully.
After you upgrade on an endpoint with Cortex XDR Device Control rules, you need to reboot the endpoint for the rules to take effect.
Agent settings per endpoint
These profiles can be configured on one or more endpoints, static/dynamic groups, tags, IP ranges, endpoint names, or other parameters that allow the
creation of logical endpoint groups. See how to define endpoint group.
1. Go to Endpoints → Policy Management → Profiles, and then edit an existing profile, add a new profile, or import from a file.
2. Choose the operating system, and select Agent Settings. Then click Next.
3. Go to Agent Upgrade. By default, this option is disabled.
Before enabling Auto-Update for Cortex XDR agents, make sure to consult with all relevant stakeholders in your organization.
The following table describes the available Agent Auto-Upgrade options:
Displayed in the footer
Page 25 of 952
Cortex XDR Documentation
Displayed in the header
Item Options Description
Automatic Upgrade Scope Latest agent release (Default) For One release before the latest one, Cortex XDR upgrades the agent to
the previous release before the latest, including maintenance releases.
One release before the latest one
Major releases are numbered X.X, such as release 8.0, or 8.2. Maintenance
Only maintenance releases releases are numbered X.X.X, such as release 8.2.2.
For Only maintenance releases in a specific version, select the required
Only maintenance releases in a
release version.
specific version
Upgrade Rollout Immediate (Default) The Cortex XDR agent will automatically get any new agent release,
maintenance and new features
Delayed
For Delayed, set the delay period (number of days) to wait after the version
release before upgrading endpoints. Choose a value between 7 and 45.
Global agent settings
Configure the Cortex XDR agent upgrade scheduler and the number of parallel upgrades to apply to all endpoints in your organization.
1. Go to Settings → Configurations → Agent Configurations, and scroll to Agent upgrade.
2. Configure the Cortex XDR agent upgrade scheduler and the number of parallel upgrades.
Item Description
Amount of parallel During the first week of a new Cortex XDR agent release rollout, only a single batch of agents is upgraded. After that, auto-
upgrades upgrades continue to be deployed across your network with the number of parallel upgrades as configured.
Set the number of parallel agent upgrades, where the maximum is 500 agents.
Days in week Schedule the upgrade task for specific days of the week.
Schedule Schedule a specific time range. The minimum range is four hours.
Content updates
When a new content update is available, Cortex XDR 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 XDR. By staggering the distribution of content updates, Cortex XDR reduces the bandwidth
load and prevents bandwidth saturation due to the high volume and size of the content updates across many endpoints. You can view the distribution of
endpoints by content update version from the dashboard.
You can configure whether to update content per endpoint or use the global settings. The information in this topic will help you select and configure these
methods.
Displayed in the footer
Page 26 of 952
Cortex XDR Documentation
Displayed in the header
Content update settings per endpoint
Configure content update options for agents within the organization to ensure it is always protected with the latest security measures.
These profiles can be configured on one or more endpoints, static/dynamic groups, tags, IP ranges, endpoint names, or other parameters that allow the
creation of logical endpoint groups.
The following table describes the available Content Configuration options:
1. Go to Endpoints → Policy Management → Profiles , and then edit an existing profile, add a new profile, or import from a file.
2. Choose the operating system, and select Agent Settings. Then click Next.
3. Go to Content Configuration. By default, this option is Enabled.
Item Options More Details
Content Auto-Update Enabled (Default) When Content Auto-Update is enabled, the Cortex XDR agent retrieves the
most updated content and deploys it on the endpoint.
Disabled
If you disable content updates, the agent stops retrieving them from the
Cortex XDR tenant, and keeps working with the current content on the
endpoint.
Staging Content Enabled Enable users to deploy agent staging content on selected test
environments. Staging content is released before production content,
Disabled (Default) allowing for early evaluation of the latest content update.
Content Rollout Immediate (Default) The Cortex XDR agent can retrieve content updates immediately as they
are available, after a pre-configured delay period of up to 30 days, or you
Delayed
can select a specific version.
Specific When you delay content updates, the Cortex XDR agent will retrieve the
content according to the configured delay. For example, if you configure a
delay period of two days, the agent will not use any content released in the
last 48 hours.
Global content update settings
1. Go to Settings → Configurations → Agent Configurations, and scroll to Content Management.
2. Configure the content update cadence and bandwidth allocation within your organization.
Displayed in the footer
Page 27 of 952
Cortex XDR Documentation
Displayed in the header
Item Description
Enable bandwidth Based on the number of agents you want to update with content and upgrade packages, active or future agents, the Cortex
control XDR 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 XDR supports between 20 - 10000 Mbps, you can enter
one of the recommended values or enter one of your own. For optimized performance and reduced bandwidth consumption,
it is recommended that you install and update new agents with Cortex XDR agents 7.3 and later include the content
package built in using SCCM.
XDR Calculator for Based on the number of agents you want to update with content and upgrade packages, active or future agents, the Cortex
Recommended XDR calculator configures the recommended amount of Mbps (Megabits per second) required for a connected agent to
Bandwidth retrieve a content update over 24 hours or a week. This calculation is based on connected agents and includes an overhead
for large content update.
Cortex XDR supports between 20 - 10000 Mbps.
It is recommended to allocate a minimum of 20 Mbps, or you can enter a value.
Enable minor To enforce immediate protection against the latest threats, enable minor content updates. Otherwise, the content updates in
content version your network occur only on major releases.
updates
6 | Step 5: Define data sources
Abstract
Learn how to configure data ingestion ingest data from a variety of Palo Alto Networks and third-party sources.
To provide you with a more complete and detailed picture of the activity involved in an incident, you can configure Cortex XDR to ingest data from a variety of
Palo Alto Networks and third-party sources.
Related information
Palo Alto Network integrations
External data ingestion
7 | Configure server settings
Abstract
Configure server settings such as keyboard shortcuts, timezone, and timestamp format.
You can configure server settings such as keyboard shortcuts, timezone, and timestamp format, to create a more personalized user experience in Cortex XDR.
Go to Settings → Configurations → General → Server Settings.
Keyboard shortcuts, timezone, and timestamp format are not set universally and only apply to the user who sets them.
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 XDR, auditing logs, and when exporting files.
Displayed in the footer
Page 28 of 952
Cortex XDR Documentation
Displayed in the header
Server Setting Description
Timestamp Format The format in which to display Cortex XDR data. The format affects the
timestamps displayed in Cortex XDR, auditing logs, and when exporting
files.
This setting is configured per user and not per tenant.
Email Contacts A list of email addresses Cortex XDR 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 when downloading retrieved files from an
endpoint. This prevents users from opening potentially malicious files.
Administrator permissions required.
If the Password Protection (for downloaded files) setting under Settings →
Configuration → General → Server Settings is enabled, enter the password
'suspicious' to download the file.
Google Maps Key Enter the Google Maps API key
to display the physical location of an entity on a Google map.
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.
XQL Configuration Enables setting case sensitivity across Cortex XDR.
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.
From Cortex XDR version 3.3, the default case sensitivity setting was
changed to case insensitive (config case_sensitive = false). If
you've been using Cortex XDR before this version was released, the default
case sensitivity setting is still configured to be case sensitive (config
case_sensitive = true).
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.
Displayed in the footer
Page 29 of 952
Cortex XDR Documentation
Displayed in the header
Server Setting Description
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.
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
XDR tenant. Pairing is one-to-one, with the two tenants being in the same
region.
For more information, see Pairing Prisma Cloud with Cortex XDR .
8 | Configure security settings
Abstract
Configure security settings such as session expiration, user login expiration, and dashboard expiration.
You can configure security settings such as how long users can be logged into Cortex XDR, and from which domains and IP ranges users can log in.
Go to Settings → Configurations → General → Security Settings.
Settings Options Description
Session Expiration User Login Expiration The number of hours (between 1 and 24) after
which the user login session expires. You can
also choose to automatically log users out after a
specified period of inactivity.
Dashboard Expiration Whether the Dashboard page expires at the
same time as the user login session or after
seven days. This is useful when you view a
dashboard on a separate screen.
For example, if you select seven days for
dashboards and eight hours for login expiration
and you are currently viewing the Dashboard
page, the dashboard expiration takes priority
(seven days). This ensures that the Dashboard
page continues to display the widgets for an
extended period.
Displayed in the footer
Page 30 of 952
Cortex XDR Documentation
Displayed in the header
Settings Options Description
Allowed Sessions Approved Domains The domains from which you want to allow user
access (login) to Cortex XDR. You can add or
remove domains as necessary.
Approved IP Ranges The IP ranges from which you want to allow user
access (login) to Cortex XDR. You can also
choose to limit API access from specific IP
addresses.
User Expiration Deactivate Inactive User Deactivate an inactive user, and also set the user
deactivation trigger period. By default, user
expiration is disabled. When enabled, enter the
number of days after which inactive users should
be deactivated.
Allowed Domains Domain Name The domain names that can be used in your
distribution lists for reports. For example, when
generating a report, ensure the reports are not
sent to email addresses outside your
organization.
9 | Log forwarding
Abstract
Stay informed and updated about events in your system by forwarding alerts and reports to an external service, such as a syslog receiver, a Slack channel, or
an email account.
Logs provide information about events that occur in the system. These logs are a valuable tool in troubleshooting issues that might arise in your Cortex XDR
tenant.
To stay informed about important alerts and events, you can configure your notifications and specify the type of logs you want to forward. You can choose to
receive these notifications through a syslog receiver, a Slack channel, or an email account.
9.1 | Forward logs from Cortex XDR to external services
Abstract
Learn how to forward logs from Cortex XDR to external services such as email, Slack, or a syslog receiver.
You can forward logs from Cortex XDR to an external service. This allows you to stay updated on important alerts and events. Available services include the
following:
Slack channel and/or syslog receiver: Integrate the service with Cortex XDR. Once the integration is complete, configure notification forwarding
specifying the log type you want to forward.
Email distribution list: Configure notification forwarding specifying the log type you want to forward.
The following table shows the log types supported for each notification type:
Log Type Email Slack Syslog
Alerts ✓ ✓ ✓
Agent Audit log ✓ — ✓
Requires Cortex XDR Pro per Endpoint
Displayed in the footer
Page 31 of 952
Cortex XDR Documentation
Displayed in the header
Log Type Email Slack Syslog
Management Audit log ✓ — ✓
Data Ingestion Health alerts ✓ ✓ ✓
Reports ✓ ✓ —
9.1.1 | Integrate a syslog receiver
Abstract
Define syslog settings and then configure notification forwarding to receive notifications about alerts and reports.
A syslog receiver can be a physical or virtual server, a SaaS solution, or any service that accepts syslog messages.
To send Cortex XDR notifications to your syslog receiver, you first need to define the settings for the syslog receiver. Once this is complete, you can configure
notification forwarding.
How to send logs to a syslog receiver
Before you begin, enable access to the following Cortex XDR IP addresses for your region in your firewall.
Region Log Forwarding IP Addresses
United States - Americas (US) 35.232.87.9
35.224.66.220
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
Displayed in the footer
Page 32 of 952
Cortex XDR Documentation
Displayed in the header
Region Log Forwarding IP Addresses
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
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
Spain (ES) 34.175.83.90
34.175.230.150
1. Select Settings → Configurations → Integrations → External Applications.
2. In Syslog Servers, click + New Server.
3. Define the following parameters:
Parameter Description
Name Unique name for the server profile.
Displayed in the footer
Page 33 of 952
Cortex XDR Documentation
Displayed in the header
Parameter Description
Destination IP address or fully qualified domain name (FQDN) of the syslog receiver.
Port Port number on which to send syslog messages.
Facility Select one of the syslog standard values. The value maps to how your syslog server uses the facility field to manage messages. For
details on the facility field, see RFC 5424.
Protocol Method of communication with the syslog receiver:
TCP: No validation is made on the connection with the syslog receiver. However, if an error occurred with the domain used to
make the connection, the Test connection will fail.
UDP: No error checking, error correction, or acknowledgment. No validation is done for the connection or when sending data.
TCP + SSL: Cortex XDR validates the syslog receiver certificate and uses the certificate signature and public key to encrypt the
data sent over the connection.
Certificate The communication between Cortex XDR and the syslog destination can use TLS. In this case, upon connection, Cortex XDR validates
that the syslog receiver has a certificate signed by either a trusted root CA or a self-signed certificate. You may need to merge the
Root and Intermediate certificate if you receive a certificate error when using a public certificate.
If your syslog receiver uses a self-signed CA, upload your self-signed syslog receiver CA. If you only use a trusted root CA leave
the certificate field empty.
Up to TLS 1.3 is supported.
Make sure the self-signed CA includes your public key.
You can ignore certificate errors. For security reasons, this is not recommended. If you choose this option, logs will be forwarded even
if the certificate contains errors.
4. Test the parameters to ensure a valid connection, and click Create when ready.
You can define up to five syslog receivers. Upon success, the table displays the syslog servers and their status.
What to do next
After you integrate with your syslog receiver, configure your forwarding settings. For more information see, Configure notification forwarding.
Syslog receiver test message errors
When configuring a syslog message, Cortex XDR sends a test message. If a test message cannot be sent, Cortex XDR displays an error message to help you
troubleshoot.
The following table includes 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.
Displayed in the footer
Page 34 of 952
Cortex XDR Documentation
Displayed in the header
Error Message Description
Wrong The certificate Re-create the certificate in the correct format, for example:
Certificate you uploaded is
-----BEGIN CERTIFICATE-----
Format in an unexpected MIIDHTCCAgWgAwIBAgIQSwieRyGdh6BNRQyp406bnTANBgkqhkiG9w0BAQsFADAhMR8wHQYDVQQDExZTVVJTLUNoYXJsaWVBbHBoYS1Sb290MB4XDTIwMDQzMDE4MjEzNFo
format and can't ----END CERTIFICATE-----
be used. The
certificate must
be an ASCII
string or a bytes-
like object.
Connection Cortex XDR Check the firewall logs and the connection using WireShark.
Timed Out didn’t connect to
the syslog
receiver in the
expected time.
This could be
because your
firewall blocked
the connection or
because the
configuration of
the syslog server
caused it to drop
the connection.
Connection The syslog Check the firewall logs and the connection using WireShark.
Refused receiver refused
the connection.
This could be
because your
firewall blocked
the connection or
because the
configuration of
the syslog server
caused it to drop
the connection.
Connection The connection Check the firewall logs and the connection using WireShark.
Reset was reset by the
syslog receiver.
This could be
because your
firewall blocked
the connection or
because the
configuration of
the syslog
receiver caused
it to drop the
connection.
Displayed in the footer
Page 35 of 952
Cortex XDR Documentation
Displayed in the header
Error Message Description
Certificate The uploaded Incorrect certificate: to check that the certificate you are uploading corresponds to the server syslog certificate, use the fol
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 certific
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.
receiver
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.
Connection The firewall or the Check the firewall logs and the connection using WireShark.
Terminated syslog receiver
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
receiver 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
Unreachable configuration is
faulty and the
connection can't
reach the syslog
receiver.
Displayed in the footer
Page 36 of 952
Cortex XDR Documentation
Displayed in the header
Error Message Description
SSL Error Unknown SSL To investigate the issue, contact support.
error.
Connection General error. To investigate the issue, contact support.
Unavailable
9.1.2 | Integrate Slack for outbound notifications
Abstract
Learn how to integrate Cortex XDR with your Slack workspace and stay updated on important alerts and events.
Integrate Cortex XDR with your Slack workspace to manage and highlight your alerts and reports. Creating a Cortex XDR Slack channel ensures that defined
alerts are exposed on laptop and mobile devices using the Slack interface. Unlike email notifications, Slack channels provide dedicated spaces where you can
contact specific members regarding your alerts.
How to integrate Slack with Cortex XDR
1. From Cortex XDR, select Settings → Configurations → Integrations → External Applications.
2. Select the provided link to install Cortex XDR on your Slack workspace.
You are directed to the Slack browser to install Cortex XDR. You can only use this link to install Cortex XDR on Slack. Attempting to install from Slack
Marketplace will redirect you to Cortex XDR documentation.
3. Click Submit.
Upon successful installation, Cortex XDR displays the workspace to which you connected.
What to do next
After you integrate with your Slack workspace, configure your forwarding settings. For more information see, Configure notification forwarding.
9.1.3 | Configure notification forwarding
Abstract
Learn how to create a forwarding configuration that specifies the log type you want to forward.
After you integrate with an external service such as Slack or a syslog receiver, create a forwarding configuration that specifies the log type you want to forward.
You can configure notifications for alerts, agent audit logs, and management audit logs. To receive notifications about reports, see Create a report from
scratch.
Before you can select a syslog receiver or a Slack channel, you need to integrate these external services with Cortex XDR.
For more information, see:
Integrate a syslog receiver
Integrate Slack for outbound notifications
How to configure notifications
1. Select Settings → Configurations → General → Notifications.
2. Click + Add Forwarding Configuration.
3. Enter a name and description for the configuration.
4. Select the log type you want to forward:
Alerts: Send notifications for specific alert types (for example, XDR Agent or BIOC.
To configure notification forwarding for Health alerts, select Log Type = Alerts and filter the Alerts table by Alert Domain = Health.
Agent Audit Logs: Send notifications for audit logs reported by your Cortex XDR agents.
Management Audit Logs: Send notifications for audit logs about events related to your Cortex XDR tenant.
Displayed in the footer
Page 37 of 952
Cortex XDR Documentation
Displayed in the header
5. Click Next, and under Scope, filter the type of information you want included in a notification.
For example, for a filter set to Severity = Medium, Alert Source = XDR Agent, Cortex XDR sends the alerts or events matching this filter as a
notification.
6. Click Next.
7. (Optional) Define your email configuration:
a. In the Distribution List, add the email addresses to which you want to send email notifications.
b. In the Grouping Timeframe, define the time frame, in minutes, to specify how often Cortex XDR sends notifications. Every 20 alerts or 20 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 XDR to provide an auto-generated subject.
d. If you previously used log forwarding and want to continue forwarding logs in the same format, select Use Legacy Log Format. For more
information, see Log format for IOC and BIOC alerts.
8. Depending on the notification integrations supported by the log type, configure the Slack channel or syslog receiver notification settings. For a list of log
types supported in each notification type, see Forward logs from Cortex XDR to external services.
Enter the Slack channel name and select from the list of available channels. Slack channels are managed independently of Cortex XDR in your
Slack workspace. After integrating your Slack account with your Cortex XDR tenant, Cortex XDR displays a list of specific Slack channels
associated with the integrated Slack workspace.
Select a syslog receiver. Cortex XDR displays the list of receivers integrated with your Cortex XDR tenant.
9. Click Done to create the forwarding configuration.
9.1.4 | Monitor administrative activity
Abstract
View all Cortex XDR 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 XDR 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.
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.
Subtype Subcategory of action
Timestamp Time and date of the action
Displayed in the footer
Page 38 of 952
Cortex XDR Documentation
Displayed in the header
Field Description
Type Type of activity logged, one of the following:
Displayed in the footer
Page 39 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR .
Alert Notifications: Modification of the format or timing of alerts.
Alert Rules: Modification of alert rules.
API Key: Modification of the Cortex XDR 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.
Protection Policy: Modification of the protection policy.
Protection Profile: Modification of the protection profile.
Public API: Authentication activity using an associated Cortex XDR API key.
Displayed in the footer
Page 40 of 952
Cortex XDR Documentation
Displayed in the header
Field Description
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.
9.2 | Log notification formats
Abstract
Cortex XDR provides you with different formats for its log notifications.
When Cortex XDR alerts and audit logs are forwarded to an external data source, notifications are sent according to the necessary format (syslog messages,
email, or Slack notifications). If you prefer Cortex XDR to forward logs in legacy format, select the legacy option in your log forwarding configuration.
9.2.1 | Management audit log messages
Abstract
View the types of Cortex XDR management audit log messages that are sent.
Cortex XDR management audit log messages are sent based on the various components, for example, Action Center, Alert Rules, or Authentication. It is
recommended that you review the subtype, status, and informational fields for each message.
List of components
Displayed in the footer
Page 41 of 952
Cortex XDR Documentation
Displayed in the header
Action Center
Agent Configuration
Agent Installation
Alert Exclusions
Alert Notifications
Alert Rules
API Key
Authentication
Broker API
Broker VMs
Dashboards
Device Control Permanent Exceptions
Device Control Profile
Device Control Temporary Exceptions
Disk Encryption Profile
EDL Management
Endpoint Administration
Endpoint Groups
Event Forwarding
Extensions Policy
Extensions Profile
Featured Alert Fields
Global Exceptions
Host Firewall Profile
Host Insights
Incident Management
Ingest Data
Integrations
Licensing
Live Terminal
Managed Threat Hunting
MSSP
Permission
Policy & Profiles
Prevention Policy Rules
Public API
Query Center
Remediation
Reporting
Response
Rules
Displayed in the footer
Page 42 of 952
Cortex XDR Documentation
Displayed in the header
Rules Exceptions
SaaS Collection
Server Settings
Scoring Rules
Security Settings
Starred Incidents
System
9.2.2 | Alert notification format
Abstract
Learn about the formats used to forward Cortex XDR agent, BIOC, IOC, analytics, correlation, and third-party alerts.
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.
Email account
Alert notifications are sent to email accounts according to the settings you configured. Email messages also include an alert code snippet of the fields
according to the columns in the Alert table.
The notification format is as follows:
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.
Example 5.
Single alert email message
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>
Example 6.
Grouped alert email message
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”
Example 7.
Displayed in the footer
Page 43 of 952
Cortex XDR Documentation
Displayed in the header
Email body
{
"original_alert_json":{
"uuid":"<UUID Value>",
"recordType":"threat",
"customerId":"<Customer ID>",
"severity":4,
"...",
"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.
Syslog receiver
Alert notifications forwarded to a syslog receiver are sent in a CEF format RF 5425.
Section Description
Syslog header <9>: PRI (considered a priority field)1: version
number2020-03-22T07:55:07.964311Z: timestamp of when
alert/log was sentcortexxdr: host name
CEF header HEADER/Vendor="Palo Alto Networks" (as a constant
string)HEADER/Device 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
CEF body end=timestamp shost=endpoint_name
deviceFacility=facility cat=category
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 8.
Displayed in the footer
Page 44 of 952
Cortex XDR Documentation
Displayed in the header
end=timestamp shost=endpoint_name deviceFacility=facility cat=category 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
9.2.3 | Agent Audit log notification format
Abstract
An email account or a syslog receiver are the notification channels through which the Agent Audit log is communicated.
Forwarding agent audit logs requires a Cortex XDR Pro per Endpoint license.
Cortex XDR forwards the Agent Audit log to these external data resources:
Email account: Sent according to the settings you configured
Syslog receiver: Sent in a CEF format RFC 5425 according to the following mapping:
Section Description
Syslog header <9>: PRI (considered a prioirty field)1: version number2020-03-22T07:55:07.964311Z:
timestamp of when alert/log was sentcortexxdr: host name
CEF hHeader HEADER/Vendor="Palo Alto Networks" (as a constant string)HEADER/Device
Product="Cortex XDR Agent" (as a constant 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
CEF body dvchost=domain shost=endpoint_name cat=category end=timestamp rt=received_time
cs1Label=agentversion (constant string) 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 9.
<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
9.2.4 | Management Audit log notification format
Abstract
An email account or a syslog receiver are the notification channels through which the Management Audit log is communicated.
Cortex XDR forwards the Management Audit log to these external data sources:
Displayed in the footer
Page 45 of 952
Cortex XDR Documentation
Displayed in the header
Email account: Sent according to the settings you configured
Syslog receiver: Sent in a CEF format RFC 5425 according to the following mapping:
Section Description
Syslog header <9>: PRI (considered a prioirty field)1: version number2020-03-
22T07:55:07.964311Z: timestamp of when alert/log was sentcortexxdr: host
name
CEF header HEADER/Vendor="Palo Alto Networks" (as a constant string)HEADER/Device
Product="Cortex XDR" (as a constant 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
CEF body suser=user end=timestamp externalId=external_id cs1Label=email (constant
string) cs1=user_mail 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 10.
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 cs1=test@paloaltonetworks.com 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
9.2.5 | Log format for IOC and BIOC alerts
Abstract
An email account or a syslog receiver are the notification channels through which IOC and BIOC alerts are communicated.
Cortex XDR logs IOC and BIOC alerts. If you configure Cortex XDR to forward logs in the legacy format, when alert logs are forwarded from Cortex XDR, each
log record has the following format:
Displayed in the footer
Page 46 of 952
Cortex XDR Documentation
Displayed in the header
Email account: Each field is labeled, one line per field.
Example 11.
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
...
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
Syslog format
Example 12.
"/edrData/action_country","/edrData/action_download","/edrData/action_external_hostname","/edrData/action_external_port","/edrData/action_file_extension","
/edrData/action_file_md5","/edrData/action_file_name","/edrData/action_file_path","/edrData/action_file_previous_file_extension","/edrData/action_file_prev
ious_file_name","/edrData/action_file_previous_file_path","/edrData/action_file_sha256","/edrData/action_file_size","/edrData/action_file_remote_ip","/edrD
ata/action_file_remote_port","/edrData/action_is_injected_thread","/edrData/action_local_ip","/edrData/action_local_port","/edrData/action_module_base_addr
ess","/edrData/action_module_image_size","/edrData/action_module_is_remote","/edrData/action_module_is_replay","/edrData/action_module_path","/edrData/acti
on_module_process_causality_id","/edrData/action_module_process_image_command_line","/edrData/action_module_process_image_extension","/edrData/action_modul
e_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_mo
dule_process_signature_product","/edrData/action_module_process_signature_status","/edrData/action_module_process_signature_vendor","/edrData/action_networ
k_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_pro
cess_image_path","/edrData/action_process_image_sha256","/edrData/action_process_instance_id","/edrData/action_process_integrity_level","/edrData/action_pr
ocess_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_ven
dor","/edrData/action_remote_process_thread_id","/edrData/action_remote_process_thread_start_address","/edrData/action_thread_thread_id","/edrData/action_t
otal_download","/edrData/action_total_upload","/edrData/action_upload","/edrData/action_user_status","/edrData/action_username","/edrData/actor_causality_i
d","/edrData/actor_effective_user_sid","/edrData/actor_effective_username","/edrData/actor_is_injected_thread","/edrData/actor_primary_user_sid","/edrData/
actor_primary_username","/edrData/actor_process_causality_id","/edrData/actor_process_command_line","/edrData/actor_process_execution_time","/edrData/actor
_process_image_command_line","/edrData/actor_process_image_extension","/edrData/actor_process_image_md5","/edrData/actor_process_image_name","/edrData/acto
r_process_image_path","/edrData/actor_process_image_sha256","/edrData/actor_process_instance_id","/edrData/actor_process_integrity_level","/edrData/actor_p
rocess_is_special","/edrData/actor_process_os_pid","/edrData/actor_process_signature_product","/edrData/actor_process_signature_status","/edrData/actor_pro
cess_signature_vendor","/edrData/actor_thread_thread_id","/edrData/agent_content_version","/edrData/agent_host_boot_time","/edrData/agent_hostname","/edrDa
ta/agent_id","/edrData/agent_ip_addresses","/edrData/agent_is_vdi","/edrData/agent_os_sub_type","/edrData/agent_os_type","/edrData/agent_session_start_time
","/edrData/agent_version","/edrData/causality_actor_causality_id","/edrData/causality_actor_effective_user_sid","/edrData/causality_actor_effective_userna
me","/edrData/causality_actor_primary_user_sid","/edrData/causality_actor_primary_username","/edrData/causality_actor_process_causality_id","/edrData/causa
lity_actor_process_command_line","/edrData/causality_actor_process_execution_time","/edrData/causality_actor_process_image_command_line","/edrData/causalit
y_actor_process_image_extension","/edrData/causality_actor_process_image_md5","/edrData/causality_actor_process_image_name","/edrData/causality_actor_proce
ss_image_path","/edrData/causality_actor_process_image_sha256","/edrData/causality_actor_process_instance_id","/edrData/causality_actor_process_integrity_l
evel","/edrData/causality_actor_process_is_special","/edrData/causality_actor_process_os_pid","/edrData/causality_actor_process_signature_product","/edrDat
a/causality_actor_process_signature_status","/edrData/causality_actor_process_signature_vendor","/edrData/event_id","/edrData/event_is_simulated","/edrData
/event_sub_type","/edrData/event_timestamp","/edrData/event_type","/edrData/event_utc_diff_minutes","/edrData/event_version","/edrData/host_metadata_hostna
me","/edrData/missing_action_remote_process_instance_id","/facility","/generatedTime","/recordType","/recsize","/trapsId","/uuid","/xdr_unique_id","/meta_i
nternal_id","/external_id","/is_visible","/is_secdo_event","/severity","/alert_source","/internal_id","/matching_status","/local_insert_ts","/source_insert
_ts","/alert_name","/alert_category","/alert_description","/bioc_indicator","/matching_service_rule_id","/external_url","/xdr_sub_type","/bioc_category_enu
m_key","/alert_action_status","/agent_data_collection_status","/attempt_counter","/case_id","/global_content_version_id","/global_rule_id","/is_whitelisted
"
Field prefixes for BIOC and IOC alert logs
Field Name Description
/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.
Displayed in the footer
Page 47 of 952
Cortex XDR Documentation
Displayed in the header
Field Name Description
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 fields for BIOC and IOC alert logs
Field Name Description
/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 XDR – Investigation and Response ingested the
app.
/source_insert_ts Date and time the alert was reported by the alert source.
Displayed in the footer
Page 48 of 952
Cortex XDR Documentation
Displayed in the header
Field Name Description
/alert_name If the alert was generated by Cortex XDR – Investigation and Response, the
alert name will be the specific Cortex XDR 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 XDR .
/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 XDR
displays detailed information about the rule.
Displayed in the footer
Page 49 of 952
Cortex XDR Documentation
Displayed in the header
Field Name Description
/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""}]"
/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.
9.2.6 | Analytics log format
Abstract
Learn about the syntax and different variables that are used in the analytics log format.
Cortex XDR Analytics logs alerts as analytics alert logs. If you configure Cortex XDR to forward logs in the legacy format, each log record has the following
format:
Displayed in the footer
Page 50 of 952
Cortex XDR Documentation
Displayed in the header
Syslog format:
Example 13.
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/description/html,alert/description/text,alert/severity,alert/state,alert/is_whitelisted,alert/ports,alert/internal_destinations/single_des
tinations,alert/internal_destinations/ip_ranges,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_detected_at,user/user_name,user/url,user/display_name,user/org_unit,device/id,device/url,devi
ce/mac,device/hostname,device/ip,device/ip_ranges,device/owner,device/org_unit,files
Email account: Each field is labeled, one line per field.
Example 14.
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:\/\/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 ...
...
device/id: 2-85e40edd-b2d1-1f25-2c1e-a3dd576c8a7e
device/url: 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: []
Fields for analytics alert logs
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 XDR 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 XDR – Analytics instance that wrote this log
record.
version_info/detection_version Identifies the version of the Cortex XDR – Analytics detection software used to
raise the alert.
Displayed in the footer
Page 51 of 952
Cortex XDR Documentation
Displayed in the header
Field Name Definition
alert/url Provides the full URL to the alert page in the Cortex XDR – Analytics user
interface.
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 XDR – 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 XDR – Analytics to reopen the alert.
Archived: No action was taken on the alert in the Cortex XDR –
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.
Displayed in the footer
Page 52 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR – 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 XDR – 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 XDR – 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 XDR – 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 XDR – Analytics raises an alert (see
the alert/schedule/first_detected_at field).
alert/schedule/activity_last_seen_at Time when Cortex XDR – Analytics last detected the network activity that
caused it to raise the alert.
alert/schedule/first_detected_at Time when Cortex XDR – Analytics first alerted on the network activity.
alert/schedule/last_detected_at Time when Cortex XDR – 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 XDR – Analytics user
interface for the user who is associated with the alert.
Displayed in the footer
Page 53 of 952
Cortex XDR Documentation
Displayed in the header
Field Name Definition
user/display_name The user name as retrieved from Active Directory. This is the user name
displayed within the Cortex XDR – 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 XDR – 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 XDR – 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
XDR – 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.
9.2.7 | Log formats
Abstract
Learn about the different log formats that Cortex XDR can forward to an external server or email account.
The following lists the fields for each log type that Cortex XDR can forward to an external server or email destination.
Keep in mind the following:
Displayed in the footer
Page 54 of 952
Cortex XDR Documentation
Displayed in the header
When log forwarding to a syslog receiver, Cortex XDR 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.
The FUTURE_USE tag applies to fields that Cortex XDR does not currently implement.
When log forwarding to an email account, Cortex XDR sends an email with each field on a separate line in the email body.
Threat logs
The syslog format is as follows:
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)
Fields for threat logs
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.
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
XDR 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 XDR system component that initiated the event, for example:
TrapsAgent, TrapsServiceCore, TrapsServiceManagement, and
TrapsServiceBackend.
customerId The ID that uniquely identifies the Cortex XDR tenant instance which
received this log record.
trapsId Tenant external ID.
serverHost Hostname of Cortex XDR.
Displayed in the footer
Page 55 of 952
Cortex XDR Documentation
Displayed in the header
Field Name Description
serverComponentVersion Software version of Cortex XDR.
regionId ID of Cortex XDR 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.
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.
Displayed in the footer
Page 56 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR severity. See the
messageData.trapsSeverity field for details.
trapsSeverity Severity level associated with the event defined for Cortex XDR. 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.
Displayed in the footer
Page 57 of 952
Cortex XDR Documentation
Displayed in the header
Field Name Description
moduleStatusId Identifies the specific component of Cortex XDR modules.
Displayed in the footer
Page 58 of 952
Cortex XDR Documentation
Displayed in the header
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
CYSTATUS_HEAP_CORRUPTION
Displayed in the footer
Page 59 of 952
Cortex XDR Documentation
Displayed in the header
Field Name Description
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
CYSTATUS_RANSOMWARE
CYSTATUS_RESTORE_FAILED
Displayed in the footer
Page 60 of 952
Cortex XDR Documentation
Displayed in the header
Field Name Description
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.
terminate Termination action taken on the file.
0: Cortex XDR did not terminate the file.
1: Cortex XDR terminated the file.
Displayed in the footer
Page 61 of 952
Cortex XDR Documentation
Displayed in the header
Field Name Description
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
Displayed in the footer
Page 62 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR . For example,
the description of the ROP, JIT, Dylib hijacking modules for Mac endpoints
is Memory Corruption Exploit.
Config logs
The syslog format is as follows:
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
Fields for config logs
Displayed in the footer
Page 63 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR administration and configuration
changes.
class Class of Cortex XDR log. System logs have a value of system.
subClass Subclass of event. Used to categorize logs in Cortex XDR.
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
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
XDR 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 XDR system component that initiated the event, for example:
TrapsAgent, TrapsServiceCore, TrapsServiceManagement, and
TrapsServiceBackend.
customerId The ID that uniquely identifies the Cortex XDR tenant instance which
received this log record.
trapsId Tenant external ID.
serverHost Hostname of Cortex XDR.
serverComponentVersion Software version of Cortex XDR.
Displayed in the footer
Page 64 of 952
Cortex XDR Documentation
Displayed in the header
Field Name Description
regionId ID of Cortex XDR 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 XDR severity. See
the messageData.trapsSeverity field for details.
trapsSeverity Severity level associated with the event defined for Cortex XDR. 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 XDR user.
userName Username associated with Cortex XDR user.
Displayed in the footer
Page 65 of 952
Cortex XDR Documentation
Displayed in the header
Field Name Description
userRole Role assigned to Cortex XDR 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
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
Displayed in the footer
Page 66 of 952
Cortex XDR Documentation
Displayed in the header
Field Name Description
userFullName Full name of Cortex XDR user.
userName Username associated with Cortex XDR user.
userRole Role assigned to Cortex XDR 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.
parameters Parameters supplied in the log message.
additionalData(Array) Additional information regarding event parameters.
loggedInUser User that is logged in to the Cortex XDR.
Analytics logs
The syslog format is as follows:
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
Fields for analytics logs
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 XDR log: config, policy, system, and agent_log.
eventType Subtype of event.
Displayed in the footer
Page 67 of 952
Cortex XDR Documentation
Displayed in the header
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
XDR 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 XDR system component that initiated the event, for example:
TrapsAgent, TrapsServiceCore, TrapsServiceManagement, and
TrapsServiceBackend.
customerId The ID that uniquely identifies the Cortex XDR tenant instance which
received this log record.
trapsId Tenant external ID.
serverHost Hostname of Cortex XDR.
serverComponentVersion Software version of Cortex XDR.
regionId ID of Cortex XDR 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.
Displayed in the footer
Page 68 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR severity. See
the messageData.trapsSeverity field for details.
agentVersion Version of the Cortex XDR agent.
contentVersion Content version in the local security policy.
Displayed in the footer
Page 69 of 952
Cortex XDR Documentation
Displayed in the header
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 XDRdid 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 XDR did not report the security event.
1: Cortex XDR reported the security event.
blocked Blocking status of the file, in integer value:
0: Cortex XDR did not block the process or file.
1: Cortex XDR blocked the process or file.
Displayed in the footer
Page 70 of 952
Cortex XDR Documentation
Displayed in the header
Field Name Description
executionCount The total number of times a file identified by a specific hash was executed.
System logs
The syslog format is as follows:
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)
Fields for system logs
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 XDR log. System logs have a value of system.
subClass Subclass of event. Used to categorize logs in Cortex XDR user interface.
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,
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
XDR 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).
Displayed in the footer
Page 71 of 952
Cortex XDR Documentation
Displayed in the header
Field Name Description
facility The Cortex XDR system component that initiated the event, for example:
TrapsAgent, TrapsServiceCore, TrapsServiceManagement, and
TrapsServiceBackend.
customerId The ID that uniquely identifies the Cortex XDR tenant instance which
received this log record.
trapsId Tenant external ID.
serverHost Hostname of Cortex XDR.
serverComponentVersion Software version of Cortex XDR.
regionId ID of Cortex XDR 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 XDR severity. See
the messageData.trapsSeverity field for details.
Displayed in the footer
Page 72 of 952
Cortex XDR Documentation
Displayed in the header
Field Name Description
trapsSeverity Severity level associated with the event defined for Cortex XDR. 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 XDR user.
userName Username associated with Cortex XDR user.
userRole Role assigned to Cortex XDR 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
Displayed in the footer
Page 73 of 952
Cortex XDR Documentation
Displayed in the header
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 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 XDR user.
userName Username associated with Cortex XDR user.
userRole Role assigned to Cortex XDR 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.
Displayed in the footer
Page 74 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR.
10 | Automation rules
Abstract
Use automation rules to define alert conditions that trigger an action that you specify within the rule.
Cortex XDR provides an easy way to automate the day-to-day activities of SOC analysts. Automation rules enable you to define alert conditions that trigger the
action that you specify within the rule. As alerts are created, Cortex XDR checks if the alert matches any of the alert conditions from the automated rules, and if
there is a match, the corresponding action is then triggered. The automation rules only apply to new alerts which will either create a new incident or be
combined with an existing one.
Automation rules only apply to alerts that are grouped into incidents by the system. Most alerts with low and informational severity do not allow an automation
rule to be automatically executed on them.
The automation rules run in the order they're created. You can drag the rules to change the order. If you select the setting Stop processing after this rule within
a rule, the rule is still processed, but the rules following are not processed if alert conditions are met.
Automation rules 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.
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.
The Automation Rules page displays a table of all the rules created.
The following describes the fields:
Displayed in the footer
Page 75 of 952
Cortex XDR Documentation
Displayed in the header
Field Description
Action The action that is triggered when the alert matches the condition configured within the automation rule,
The options are:
Communication
Send email
Send Slack message
Syslog forwarding
Alert and Incident Management
Assign incident
Set alert severity
Set alert status
Forensics
Forensic Triage
This option requires a license which includes the Forensics Add-on.
Endpoint Response
Isolate endpoint
Retrieve File
Run endpoint script
Run malware scan
Terminate Causality (CGO)
Action Parameters Required information for the action. For example, for the action Send email, you must enter the email of the person receiving the
notification.
Conditions The rule condition defined for the automation rule. For example Severity=Critical, where the rule triggers the action on all alerts
where Severity=Critical.
Triggering Alerts The number of alerts triggered by the automation rule.
Stop Processing Indicates that the Stop processing after this rule is selected.
Status If the automation rule is enabled or disabled.
Excluded Displays the endpoint/s ID excluded from the automation rule.
Endpoints
Created by Displays the name of the user that created the automation rule.
Modification Time Time when the automation rule was last modified.
10.1 | Manage automation rules
Abstract
Displayed in the footer
Page 76 of 952
Cortex XDR Documentation
Displayed in the header
Learn how to manage automation rules for Cortex XDR.
Before you create or manage automation rules, go to Settings → Configuration → Automation Settings and configure the settings for Endpoint Action Limit
Thresholds and Automation Rules Notifications.
Add or edit an automation rule to trigger an action when the alert matches the condition of the rule created.
1. Navigate to Incident Response → Response → Automation and select Automation Rules.
2. Click Add Automation Rule.
3. For rule name and conditions, do the following:
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. From the Action list, select the relevant action to initiate when the alert condition is triggered.ActionFrom the
5. In the Exclude Endpoints page, select the endpoint and click Next.
This option is only accessible to Action type Endpoint Response.
6. In the Summary page, verify the settings and click Done.
10.2 | Automation settings
Abstract
Threshold limits may be implemented for settings of automation rules.
Before you begin creating automation rules, consider setting thresholds for the following endpoint actions:
Only administrator can configure these settings.
Endpoint Action Limit Thresholds Description
Isolate endpoint on up to _ endpoints in _ hour/s When an alert condition is triggered, and the action specified is to isolate the endpoint, the
limit threshold defined enables the set number of endpoints to be isolated for the period of
time defined. This is to prevent an overflow of endpoints isolated from the network at the
same time.
If the setting is turned off, there is no threshold for the isolation of endpoints.
Run endpoint script on up to _ endpoints in _ hour/s When an alert condition is triggered, and the action specified is to run the endpoint script,
the limit threshold defined enables the set number of endpoints to run the script for the
period of time defined. This is to prevent an overflow of endpoints running scripts at the
same time.
If the setting is turned off, there is no threshold for the running scripts on the endpoints.
Terminate Causality (CGO) on up to _ endpoints in _ hour/s When an alert condition is triggered, and the action specified is to terminate causality, the
limit threshold defined enables the set number of endpoints to terminate the causality chain
of processes for the period of time defined. This is to prevent an overflow of endpoints
terminating causality chain of processes at the same time.
If the setting is turned off, there is no threshold for terminating causality on the endpoints.
Forensic Triage on up to _ endpoints in _ hour/s When an alert condition is triggered, and the action specified is set to Forensic Triage, the
limit threshold defined enables the set number of endpoints to triage for the period of time
defined. This is to prevent an overflow of endpoints to triage at the same time.
If the setting is turned off, there is no threshold for the running scripts on the endpoints.
This option is only accessible to users that have the forensics add-on license.
Displayed in the footer
Page 77 of 952
Cortex XDR Documentation
Displayed in the header
Automation Rule Notifications Description
Distribution List Enter the email of the people to notify
Slack Enter the slack contact to notify.
10.3 | Automation rule actions
Abstract
Includes the list of actions to take when the alert condition of the automation rule is triggered for Cortex XDR.
When creating the automation rule, the action is triggered when an alert matches the condition of the automation rule.
You can configure the following types of actions:
Action Settings
Communication Choose one of the options to receive notifications to keep up with alerts.
Send email
Send Slack message
Syslog forwarding—The list of servers displayed are the servers
integrated with the Cortex XDR tenant.
Alert and Incident Management
Assign Incident Assign the incident that is linked to the alert.
Assign Condition
(Default) Assign only to unassigned incidents
Always assign
Assign To—Select the person from the list to assign the incident.
Set alert status Alert Status—Select alert status to override the present status of the alert.
New
Under Investigation
Resolved
Set alert severity Alert Severity—Select alert severity to override the present severity of the
alert.
Critical
High
Medium
Low
Forensics
Displayed in the footer
Page 78 of 952
Cortex XDR Documentation
Displayed in the header
Action Settings
Forensics Triage Triage Configuration
Select the triage configuration from the list.
Endpoint Response
Run endpoint script Run the Action On.
Alert initiator host—The host specified under Host of the alert from the
Alerts table.
Alert remote host—The host specified under Remote Host of the alert
in the Alerts table.
Script.
Script Library
Script—Select the script from the list to run on the endpoint.
The scripts listed are from the Script Library.
Script Timeout (Seconds)—Enter seconds for timeout.
Code Snippet
Script—Add commands to create a script to run on the
endpoint.
Script Timeout (Seconds)—Enter seconds for timeout
Isolate endpoint/Run malware scan Run the action on.
Alert initiator host—The host specified under Host of the alert from the
Alerts table.
Alert remote host—The host specified under Remote Host of the alert
in the Alerts table.
Retrieve File Retrieve File from.
Alert initiator file—The file specified under Initiator Path of the alert
from the Alerts table.
Alert causality group owner path—The path specified under CGO
path of the alert from the Alerts table.
Terminate Causality (CGO) Select this option to terminate the causality chain of processes associated
with the alert/s of the automation rule.
Stop processing after this rule The current rule is the last to be processed only if triggered.
10.4 | Automation Audit Log
Abstract
Includes the list of fields included in the Automation Audit Log for Cortex XDR.
The Automation Audit Log shows all the records of all the automation rule executions, including successful, failed, and paused actions.
Right-click on a record and select View triggering alert to view the details of the alert in the Alerts table. Only If the record is an Endpoint Response action, you
can select View in Action Center, to view details of the action in the Action Center.
Displayed in the footer
Page 79 of 952
Cortex XDR Documentation
Displayed in the header
The Automation Audit Log includes the following information:
Field Description
Timestamp The date and time of the last time the automation rule was triggered.
Action The action that was triggered.
Trigger Status The status of the action— Success, fail, or pause.
Description Details of the trigger status.
Triggering Alert ID The ID of the alert that was triggered by the automation rule.
Automation Rule ID The ID of the automation rule.
Automation Rule Version The version number that is updated every time the rule's conditions or actions are modified.
11 | Manage user roles and access management
Abstract
Learn how to manage access for users, user roles, user groups, and Single Sign-On (SSO) for users on a specific Cortex XDR tenant.
You can manage access for users, and create and assign user roles and user groups for a specific tenant. When Single Sign-On (SSO) is enabled, you can
manage SSO for users.
Users
You can manage access permissions and activities for users allocated to a specific Customer Support Portal account and tenant.
User roles
User roles enable you to define the type of access and actions a user can perform. User roles are assigned to users, or to user groups.
Cortex XDR provides predefined built-in user roles that provide specific access rights that cannot be modified. You can also create custom, editable user
roles.
Dataset access permissions
You can also set dataset access permissions using user roles or set specific permissions using role-based access control (RBAC). Configuring administrative
access depends on the security requirements of your organization. Dataset permissions control dataset access for all components, while RBAC controls
access to a specific component. By default, dataset access management is disabled, and users have access to all datasets. If you enable dataset access
management, you must configure access permissions for each dataset type, and for each user role. When a dataset component is enabled for a particular
role, the Alert and Incidents pages include information about datasets. For more information on how to set dataset access permissions, see Manage user roles.
User groups
You can use user groups to streamline configuration activities by grouping together users whose access permission requirements are similar. Import user
groups from Active Directory, or create them from scratch in Cortex XDR.
Single Sign-On
Manage your SSO integration with the Security Assertion Markup Language (SAML) 2.0 standard to securely authenticate system users across enterprise-wide
applications and websites, with one set of credentials. This configuration allows system users to authenticate using your organization's Identity Provider (IdP),
such as Okta or PingOne. You can integrate any IdP with Cortex XDR supported by SAML 2.0.
SSO with SAML 2.0 configuration activities are dependent on your organization’s IdP. Some of the field values need to be obtained from your organization’s IdP,
and some values need to be added to your organization’s IdP. It is your responsibility to understand how to access your organization’s IdP to provide these
fields, and to add any fields from Cortex XDR to your IdP.
Displayed in the footer
Page 80 of 952
Cortex XDR Documentation
Displayed in the header
After SSO configuration is complete, when you sign in as an SSO user, the Cortex XDR permissions granted to you after logging in, either from the group
mapping or from the default role configuration, are effective throughout the entire session for the defined maximum session length. Maximum session length is
defined in your Cortex XDR Session Security Settings. This applies even if the default role configuration is updated, or the group membership settings were
changed.
11.1 | Manage user roles
Abstract
Manage user roles that are assigned to Cortex XDR users or user groups in Cortex XDR Access Management.
Managing Roles requires an Account Admin or Instance Administrator role. For more information, see Predefined user roles.
Manage user roles that are assigned to Cortex XDR users or user groups in Cortex XDR Access Management. User roles enable you to define the type of
access and actions a user can perform.
You can only set dataset access permissions from a user role in Cortex XDR Access Management. When creating user roles from the Cortex Gateway, these
settings are disabled. By default, dataset access management is disabled, and users have access to all datasets. If you enable dataset access management,
you must configure access permissions for each dataset type, and for each user role. When a dataset component is enabled for a particular role, the Alert and
Incidents pages include information about datasets.
Create user role
1. Select Settings → Configurations → Access Management → Roles.
2. Click New Role.
3. Under Role Name, enter a name for the user role.
4. (Optional) Under Description, enter a description for the user role.
5. Under Components, expand each list and select the permissions for each of the components. For more information, Role-based Permission Levels for
Cortex XDR/XSIAM.
6. Under Datasets (Disabled), you have two options for setting the Cortex Query Language (XQL) dataset access permissions for the user role:
Set the user role with access to all XQL datasets by leaving the dataset access management as disabled (default).
Set the user role with limited access to certain XQL datasets by selecting the Enable dataset access management toggle and selecting the
datasets under the different dataset category headings.
7. Click Save.
Edit user role
1. Select Settings+Configurations+Access Management+Roles.
2. Right-click the relevant user role, and select Edit Role.
3. (Optional) Under Role Name, modify the name for the user role.
4. (Optional) Under Description, enter a description for the user role or modify the current description.
5. Under Components, expand each list and select the permissions for each of the components. For more information, Role-based Permission Levels for
Cortex XDR/XSIAM.
6. Under Datasets, you have two options for setting the Cortex Query Language (XQL) dataset access permissions for the user role:
Set the user role with access to all XQL datasets by disabling the Enable dataset access management toggle.
Set the user role with limited access to certain XQL datasets by selecting the Enable dataset access management toggle and selecting the
datasets under the different dataset category headings.
7. Click Save.
Create new role based on an existing role
1. Select Settings+Configurations+Access Management+Roles.
2. Right-click the relevant user role, and select Save As New Role.
3. (Optional) Under Role Name, modify the name for the user role.
4. (Optional) Under Description, enter a description for the user role or modify the current description.
5. Under Components, expand each list and select the permissions for each of the components. For more information, Role-based Permission Levels for
Cortex XDR/XSIAM.
Displayed in the footer
Page 81 of 952
Cortex XDR Documentation
Displayed in the header
6. Under Datasets, you have two options for setting the Cortex Query Language (XQL) dataset access permissions for the user role:
Set the user role with access to all XQL datasets by disabling the Enable dataset access management toggle.
Set the user role with limited access to certain XQL datasets by selecting the Enable dataset access management toggle and selecting the
datasets under the different dataset category headings.
7. Click Save.
11.2 | Manage user access
Abstract
Manage access permissions for Cortex XDR users.
Manage access permissions for Cortex XDR users.
Edit user permissions
Update a user's role, add a user to a user group, and view permissions based on the role and user groups assigned to the user.
If Scope-Based Access Control (SBAC) is enabled for the tenant, you can use specific tags to assign user permissions. For more information, see Manage
user scope.
You can only reduce the permissions of an Account Admin user via Cortex Gateway.
1. Select Settings → Configurations → Access Management → Users.
2. Right-click the relevant user, and select Edit User Permissions.
To apply the same settings to multiple users, select them, and then right-click and select Edit User Permissions.
3. Under Role, select the default or custom role.
4. (Optional) Under User Groups, add the user to a group.
5. (Optional) Under Show Accumulated Permissions:
a. Do one of the following:
Select all to view the combined permissions for every role and user group assigned to the user.
Select a specific role assigned to the user to view the available permissions for that role.
b. Under Components, expand each list to view the permissions to the various Cortex XDR components.
c. Under Datasets, there are two possibilities for viewing a user's dataset access permissions:
When dataset access management is enabled and the user has access to certain Cortex Query Language (XQL) datasets, the datasets are
listed.
When dataset access management is disabled and users have access to all XQL datasets, the text No dataset has been selected is
displayed.
User permissions for components and datasets are based on the acess permissions set in the user role. For more information on editing these user role
permissions, see Manage user roles.
6. (Optional) If Scope-Based Access Control is enabled for the tenant, click Scope and select a tag family and the corresponding tags.
Guidelines for selecting tags
Keep in mind the following:
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 is considered as allowed.
7. Click Save.
Import multiple users
Use a CSV file to import users who belong to a Customer Support Portal account, and assign them roles that are defined in Cortex XDR. You can use the CSV
template provided in Cortex XDR, or prepare a CSV file from scratch.
Displayed in the footer
Page 82 of 952
Cortex XDR Documentation
Displayed in the header
1. Select Settings → Configurations → Access Management → Users.
2. Click Import Multiple User Roles.
3. Do one of the following:
To use the CSV template, click Download example file, and replace the example values with your values.
Prepare a CSV file from scratch. Make sure the file includes these columns:
User email: Email address of the user belonging to a Customer Support Portal account, for example, john.smith1@exampleCompany.com.
Role name: Name of the role that you want to assign to this user, for example, Privileged Responder. The role must already exist in Cortex
XDR.
Is an account role: A boolean value that defines whether the user is designated with an Account Admin role in Cortex Gateway. Set the value
to TRUE; otherwise, the value is set to FALSE (default).
4. Locate the file and drag it to the dialog box.
5. Click Import.
View user permissions
View all of the permissions currently assigned to a user.
1. Select Settings → Configurations → Access Management → Users.
2. Right-click the relevant user, and select Edit User Permissions.
To apply the same settings to multiple users, select them, and then right-click and select Edit User Permissions.
3. Under Show Accumulated Permissions, do one of the following:
Select all to view the combined permissions for every role and user group assigned to the user.
Select a specific role assigned to the user to view the available permissions for that role.
4. Under Components, expand each list to view the permissions to the various Cortex XDR components.
5. Under Datasets, there are two possibilities for viewing a user's dataset access permissions:
When dataset access management is enabled and the user has access to certain Cortex Query Language (XQL) datasets, the datasets are listed.
When dataset access management is disabled and users have access to all XQL datasets, the text No dataset has been selected is displayed.
Hide user
There might be instances where you want to hide a user from the list of users, for example, a user that has a Customer Support Portal Super User role but isn't
active on your Cortex XDR tenant. Once you hide a user, they will no longer be displayed in the list of users when Show User Subset is selected on the Users
page.
1. Select Settings+Configurations+Access Management+Users.
2. Right-click the relevant user, and select Hide User.
Add user to a user group
1. Select Settings+Configurations+Access Management+Users.
2. Right-click the relevant user, and select Edit User Permissions.
To apply the same settings to multiple users, select them, and then right-click and select Edit User Permissions.
3. Under User Groups, add the user to a group.
4. Click Save.
Deactivate user
You cannot deactivate a user who has an Account Admin role.
1. Select Settings+Configurations+Access Management+Users.
2. Right-click the relevant user, and select Deactivate User.
3. Click Deactivate.
Remove role assigned to user
Displayed in the footer
Page 83 of 952
Cortex XDR Documentation
Displayed in the header
You cannot remove a user who has an Account Admin role.
1. Select Settings+Configurations+Access Management+Users.
2. Right-click the relevant user, and select Remove User Role.
3. Click Remove.
11.2.1 | User access reference information
The following is a list of common fields on the Users page:
Field Description
Show User Displays all users except for hidden users.
Subset
User Type Indicates whether a user was defined in Cortex XDR using the Customer Support Portal, SSO (single sign-on) using your organization’s
IdP, or both Customer Support Portal/SSO.
Direct XDR Name of the role specifically assigned to a user. When a user does not have any Cortex XDR access permissions assigned specifically
Role to them, the field displays No-Role.
Groups Lists the groups to which a user belongs. Any group that was imported from Active Directory displays AD beside the group name.
If a user group has scoping permissions, the users in the group are granted permissions according to the user group settings, even if
the user does not have configured scope settings.
Group Roles Lists the group roles based on the groups to which a user belongs. Hovering over the group role displays the group associated with this
role.
Scope Only visible if Scope-Based Access Control is enabled for the tenant.
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.
11.3 | Manage user scope
Abstract
Learn about Scope-Based Access Control (SBAC) and how to assign users to specific tags of different types in your organization.
With Scope-Based Access Control (SBAC), Cortex XDR 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 XDR 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, see Configure server settings.
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 XDR.
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.
Displayed in the footer
Page 84 of 952
Cortex XDR Documentation
Displayed in the header
The rest of the functional areas and their permissions in Cortex XDR 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.
How to define user scope
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.
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.
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.
12 | Endpoint security
Abstract
Learn about configuring and managing endpoint security.
Learn about configuring and managing endpoint security.
12.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 XDR 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 XDR 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 XDR 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 XDR can prevent all types of attacks, whether these are known or unknown threats.
Displayed in the footer
Page 85 of 952
Cortex XDR Documentation
Displayed in the header
12.1.1 | Malware protection
Abstract
Cortex XDR prevents malware attacks and provides protection on endpoints based on the different operating systems.
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 XDR 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.
The Malware Prevention Engine uses mitigation methods that implements malware protection on endpoints based on the different operating systems.
Windows
Malware Protection Type Description
Anti webshell protection Enables Cortex XDR to protect endpoint processes from dropping
malicious web shells.
Credential gathering protection Enables Cortex XDR to protect endpoints from processes trying to access
or steal passwords and other credentials.
Cryptominers protection Enables Cortex XDR to protect against attempts to locate or steal
cryptocurrencies.
Endpoint scanning Enables Cortex XDR to scan endpoints and attached removable drives for
dormant, inactive malware.
Financial malware threat protection Enables Cortex XDR to protect against techniques specific to financial and
banking malware.
Global behavioral threat protection rules Enables Cortex XDR to use rules to protect endpoints from malicious
causality chains.
In-process shellcode protection Enables Cortex XDR to protect against in-process shellcode attack threats.
Displayed in the footer
Page 86 of 952
Cortex XDR Documentation
Displayed in the header
Malware Protection Type Description
Malicious device protection Enables Cortex XDR to protect against the connection of potentially
malicious devices to endpoints.
Office files with macros examination Enables Cortex XDR to analyze and prevent malicious macros embedded
in Microsoft Office files (Word, Excel) from running on Windows endpoints.
On-write file protection Enables Cortex XDR to monitor and take action on malicious files during the
on-write process.
Portable executable and DLL Enables Cortex XDR to analyze and prevent malicious executable files and
DLL files from running on Windows endpoints.
PowerShell script file examination Enables Cortex XDR to analyze and prevent malicious PowerShell script
files from running on Windows endpoints.
UAC bypass prevention Enables Cortex XDR to protect against the User Access Control (UAC)
bypass mechanism that is associated with privilege elevation attempts.
macOS
Malware Protection Type Description
Endpoint scanning Enables Cortex XDR to scan endpoints and attached removable drives for dormant, inactive malware.
Global behavioral threat Enables Cortex XDR to use rules to protect endpoints from malicious causality chains.
protection rules
Credential gathering protection Enables Cortex XDR to protect endpoints from processes trying to access or steal passwords and other credentials.
Anti webshell protection Enables Cortex XDR to protect endpoint processes from dropping malicious web shells.
Financial malware threat Enables Cortex XDR to protect against techniques specific to financial and banking malware.
protection
Cryptominers protection Enables Cortex XDR to protect against attempts to locate or steal cryptocurrencies.
Anti tampering protection Enables Cortex XDR to protect against tampering attempts.
Ransomware protection Enables Cortex XDR to protect against encryption-based activity associated with ransomware attacks.
Malicious child process Enables Cortex XDR to prevent script-based attacks. Such attacks can be used to deliver malware by blocking
protection targeted processes that are commonly used to bypass traditional security methods.
Mach-O file examination Enables Cortex XDR to check Mach-O files for malware.
Displayed in the footer
Page 87 of 952
Cortex XDR Documentation
Displayed in the header
Malware Protection Type Description
Local file threat examination Enables Cortex XDR to detect malicious files on the endpoint.
DMG file examination Enables Cortex XDR to check DMG files for malware.
Linux
Malware Protection Type Description
Endpoint scanning Enables Cortex XDR to scan endpoints and attached removable drives for dormant, inactive malware.
Global threat behavioral threat protection Enables Cortex XDR to use rules to protect endpoints from malicious causality chains.
rules
Credential gathering protection Enables Cortex XDR to protect endpoints from processes trying to access or steal passwords and other
credentials.
Anti webshell protection Enables Cortex XDR to protect endpoint processes from dropping malicious web shells.
Financial malware threat protection Enables Cortex XDR to protect against techniques specific to financial and banking malware.
Cryptominers protection Enables Cortex XDR to protect against attempts to locate or steal cryptocurrencies.
Container escaping protection Enables Cortex XDR to protect against container-escaping attempts.
ELF file examination Enables Cortex XDR to examine ELF files on endpoints and perform additional actions on them.
Local file threat examination Enables Cortex XDR to detect malicious files on the endpoint.
Reverse shell protection Enables Cortex XDR to prevent attempts to redirect standard input and output streams to network sockets.
Android
Malware Protection Type Description
APK files examination Enables Cortex XDR to analyze and prevent malicious APK files from running on endpoints.
iOS
Malware Protection Type Description
URL filtering Enables Cortex XDR to analyze and block or report malicious URLs, and to block or allow custom URLs.
Spam reports Enables Cortex XDR to report calls and messages as spam.
Displayed in the footer
Page 88 of 952
Cortex XDR Documentation
Displayed in the header
Malware Protection Type Description
Call and messages blocking Enables Cortex XDR to act on incoming calls and messages from known spam numbers.
Safari browser security This security module can provide proactive gating of suspicious sites accessed using Safari, and provides informative site
module analysis to the device user. This option is recommended for iOS devices that do not belong to your organization and do
not use the Network Shield feature.
Network and EDR security This module lets you configure granular control and monitoring of network traffic on iOS-based supervised devices. The
module devices' profiles must be also configured for this on the MDM side as explained in the Cortex XDR Agent iOS Guide.
12.1.2 | Exploit protection
Abstract
Cortex XDR prevents exploit attempts and provides protection on endpoints based on the different operating systems.
An exploit is a sequence of commands that takes advantage of a bug or vulnerability in software or hardware to gain unauthorized access or control.
To combat an attack in which an attacker takes advantage of a software exploit or vulnerability, Cortex XDR employs Endpoint Protection Modules (EPM). Each
EPM targets a specific exploit type in the attack chain. Some capabilities that Cortex XDR EPMs provide are reconnaissance prevention, memory corruption
prevention, code execution prevention, and kernel protection.
The following table lists the types of exploits for which Cortex XDR provides protection.
Exploit Protection Type Description
Reconnaissance prevention Prevents attackers from probing the network for vulnerabilities while preserving the option to perform internal
reconnaissance testing.
Memory corruption Prevents adversaries from exploiting memory corruption vulnerabilities.
prevention
Code execution prevention Prevents malicious code that could allow attackers to deploy additional malware to steal sensitive data.
Kernel protection Protects the kernel against kernel threats and exploits.
12.1.3 | File analysis and protection flow
Abstract
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.
Displayed in the footer
Page 89 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR 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 XDR. For example, if a user
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 XDR. 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 XDR 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.
Displayed in the footer
Page 90 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR for in-depth analysis by WildFire.
To enhance performance and efficiency, hash verdict requests from the Cortex XDR agent will be routed to the WildFire service with the lowest latency. File
uploads for analysis will strictly adhere to the designated Cortex XDR and WildFire regions, ensuring data remains within the appropriate geographical
boundaries.
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 XDR 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 XDR. 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 XDR , 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 XDR is
unreachable. The Cortex XDR agent can rely on the local analysis verdict until it receives an official WildFire verdict or hash exception.
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 Set up malware prevention profiles.
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 XDR.
Displayed in the footer
Page 91 of 952
Cortex XDR Documentation
Displayed in the header
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.
12.1.4 | 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.
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
Displayed in the footer
Page 92 of 952
Cortex XDR Documentation
Displayed in the header
Protection Capability Windows Mac Linux Android IOS
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.
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.
Displayed in the footer
Page 93 of 952
Cortex XDR Documentation
Displayed in the header
Protection Capability Windows Mac Linux Android IOS
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.
Dynamic kernel protection
Protect the endpoint from kernel-level threats such as bootkits, rootkits, and susceptible drivers.
SMS and MMS malicious URL filtering — — — —
Spam reports — — — —
Call and messages blocking — — — —
Container-escaping attempts — — — —
Network URL filtering — — — —
URL filtering for supervised devices
Cryptocurrency wallets protection
Protection for cryptocurrency wallets stored on endpoints.
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.
Displayed in the footer
Page 94 of 952
Cortex XDR Documentation
Displayed in the header
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.
12.1.5 | 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.
Displayed in the footer
Page 95 of 952
Cortex XDR Documentation
Displayed in the header
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.
Displayed in the footer
Page 96 of 952
Cortex XDR Documentation
Displayed in the header
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.
Displayed in the footer
Page 97 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR
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.
Displayed in the footer
Page 98 of 952
Cortex XDR Documentation
Displayed in the header
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.
Displayed in the footer
Page 99 of 952
Cortex XDR Documentation
Displayed in the header
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.
UEFI BTP
Reinforces the malware protection from
pre-boot attacks.
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.
12.1.6 | 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.
Displayed in the footer
Page 100 of 952
Cortex XDR Documentation
Displayed in the header
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
Displayed in the footer
Page 101 of 952
Cortex XDR Documentation
Displayed in the header
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
Displayed in the footer
Page 102 of 952
Cortex XDR Documentation
Displayed in the header
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
Displayed in the footer
Page 103 of 952
Cortex XDR Documentation
Displayed in the header
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
Displayed in the footer
Page 104 of 952
Cortex XDR Documentation
Displayed in the header
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
12.1.7 | WildFire analysis concepts
Abstract
Learn about the analysis concepts used by Wildfire.
File forwarding
Cortex XDR 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 XDR 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 XDR 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 XDR to forward samples to WildFire. A sample can be:
Displayed in the footer
Page 105 of 952
Cortex XDR Documentation
Displayed in the header
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 Set up malware prevention profiles.
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 XDR 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).
In cases when the Cortex XDR 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 XDR 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:
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 Set up agent settings profiles), 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 XDR for the verdict. If Cortex XDR receives a verdict request for a file that was
already analyzed, Cortex XDR immediately responds to the Cortex XDR agent with the verdict.
Displayed in the footer
Page 106 of 952
Cortex XDR Documentation
Displayed in the header
If Cortex XDR 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 XDR receives the verdict it responds to the Cortex XDR
agent that requested the verdict.
For information on file-examination settings, see Set up malware prevention profiles.
12.1.8 | Guidelines for keeping Cortex XDR agents and content updated
Abstract
Learn more about how to control Cortex XDR agent and content upgrades.
This document covers a recommended strategy and best practices for managing agent and content updates to help reduce the risk of downtime in a
production environment, while helping ensure timely delivery of security content and capabilities.
Keeping Cortex XDR agents up-to-date is essential for protecting against evolving threats and vulnerabilities. Regular updates ensure the latest security
features for malware and exploit prevention, and compatibility with the latest software environments, which helps reduce the risk of attacks. This can also help
organizations meet regulatory standards while maintaining strong overall protection.
Content updates, such as new threat intelligence or detection logic, are critical for defending against newly discovered cyber threats and malware and are
designed to ensure that systems remain protected against the latest attacks. Content updates address compatibility issues as well, helping achieve smooth
operations alongside the Cortex XDR agent. Without regular content updates, security solutions may fail to detect new or evolving threats, leaving systems
vulnerable to attacks.
When planning Cortex XDR agent upgrades and content updates, consult with the appropriate stakeholders and teams and follow the change management
strategy in your organization.
The Cortex XDR agent can retrieve content updates immediately as they become available, after a pre-configured delay period of up to 30 days, or you can
choose to select a specific version.
Cortex XDR can be configured to manage the deployment of agent and content updates by adjusting the following settings:
AGENT UPGRADE SETTINGS
Agent settings per endpoint:
Agent Auto-Upgrade is disabled by default. Before enabling agent auto-upgrade for Cortex XDR agents, make sure to consult with all relevant
stakeholders in your organization. Enabling this option allows you to define the scope of the automatic updates, such as upgrading to the latest agent
release, one release prior, only maintenance releases, or maintenance releases within a specific version.
Upgrade Rollout includes two options: Immediate, where the Cortex XDR agent automatically receives new releases, including maintenance updates
and features, and Delayed, which lets you set a delay of 7 to 45 days after a version is released before upgrading endpoints.
Global agent settings: Configure the Cortex XDR agent upgrade scheduler and the number of parallel upgrades to apply to all endpoints in your
organization. You can also schedule the upgrade task for specific days of the week and set a specific time range for the upgrades.
CONTENT UPDATE SETTINGS
Content updates per endpoint:
Content Auto-Update is enabled by default and automatically retrieves the latest content before deploying it on the endpoint. If you disable content
updates, the agent will stop fetching updates from the Cortex XDR tenant and will continue to operate with the existing content on the endpoint.
Content Rollout: The Cortex XDR agent can retrieve content updates immediately as they become available, after a pre-configured delay period of up
to 30 days, or you can choose to select a specific version.
Global content updates: Configure the content update cadence and bandwidth allocation within your organization. To enforce immediate protection against
the latest threats, enable minor content updates. Otherwise, the content updates in your network occur only on major releases.
Guidelines for planning Cortex XDR agent upgrades
Use a phased rollout plan by creating batches for deploying updates. The specifics may vary based on your organization and its structure. Start with a control
group, then deploy to 10% of your organization. Subsequently, allocate the remaining upgrades in batches that best suit your organization until achieving a full
100% rollout.
Example 15.
The following is an example of a rollout plan for deploying a Cortex XDR agent upgrade:
Phase 1: Control group rollout: Start by selecting a control group of endpoints as early adopters. This group should consist of a diverse range of operating
systems, devices, applications, and servers, with a focus on low-risk endpoints. After a defined testing period, such as one week, assess for any issues. If no
problems are found, move to the next phase.
Phase 2: 10% rollout: Expand the rollout to 10% of the organization’s endpoints. This group should maintain the same variety as the control group but include
low- to medium-risk endpoints. Monitor performance during the set period. If the rollout is successful with no issues, proceed to the next phase.
Displayed in the footer
Page 107 of 952
Cortex XDR Documentation
Displayed in the header
Phase 3: 40% rollout: After confirming the success of the 10% rollout, extend the deployment to 40% of the organization. Continue including a variety of
endpoints while gradually incorporating some medium-risk endpoints. Ensure thorough testing during this phase before moving forward.
Phase 4: 80% rollout: Extend the deployment to 80% of the organization's endpoints. This batch should include a wide variety of endpoints, incorporating
both medium and high-risk systems. After a careful monitoring period and confirmation that everything is stable, move to the final phase.
Phase 5: Full rollout: Complete the rollout by updating the remaining 20% of the organization’s endpoints. By this point, the majority of systems should have
been thoroughly tested, reducing the risk of issues in the final stage. Once complete, 100% of the organization will be updated.
Guidelines for planning content updates
Content updates are typically provided on a weekly basis. Use a phased rollout plan by creating batches for deploying updates. Start with a control group,
then deploy to 10% of your organization. Subsequently, allocate the remaining upgrades in batches that best suit your organization until achieving a full 100%
rollout.
Example 16.
The following is an example of a rollout plan over a period of one week for deploying content updates:
Phase 1: Control group rollout: Keep the default configuration set to deploy content updates immediately.
Phase 2: 10% rollout: Content is automatically deployed on day 2 following a delay period defined in the profile.
Phase 3: 60% rollout: Content is automatically deployed on day 3 following a delay period defined in the profile.
Phase 4: Full rollout: Increase the deployment to include medium and high-risk systems, until the entire organization is updated.
How to configure agent and content update settings
The following information will help you select and configure the update settings.
Cortex XDR agent upgrades
Configure one or more of the settings described in this section to keep your Cortex XDR agents up-to-date.
Distribute agent upgrades to selected endpoints
1. Create an agent installation package for each operating system version for which you want to upgrade the Cortex XDR agent.
Note the installation package names.
2. Select 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.
Displayed in the footer
Page 108 of 952
Cortex XDR Documentation
Displayed in the header
You can install the Cortex XDR agent on Linux endpoints using a package manager. If you do not want to use the package manager, clear the option
Upgrade to installation by package manager.
When you upgrade an agent on a Linux endpoint that is not using a package manager, Cortex XDR upgrades the installation process by default
according to the endpoint Linux distribution.
The Cortex XDR agent keeps the name of the original installation package after every upgrade.
5. Upgrade.
Cortex XDR 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).
Custom dashboards that include upgrade status widgets, and the All Endpoints page display upgrade status.
During the upgrade process, the endpoint operating system might request a reboot. However, you do not have to perform the reboot for the Cortex
XDR agent upgrade process to complete it successfully.
After you upgrade on an endpoint with Cortex XDR Device Control rules, you need to reboot the endpoint for the rules to take effect.
Agent settings per endpoint
These profiles can be configured on one or more endpoints, static/dynamic groups, tags, IP ranges, endpoint names, or other parameters that allow the
creation of logical endpoint groups. See how to define endpoint group.
1. Go to Endpoints → Policy Management → Profiles, and then edit an existing profile, add a new profile, or import from a file.
2. Choose the operating system, and select Agent Settings. Then click Next.
3. Go to Agent Upgrade. By default, this option is disabled.
Before enabling Auto-Update for Cortex XDR agents, make sure to consult with all relevant stakeholders in your organization.
The following table describes the available Agent Auto-Upgrade options:
Item Options Description
Automatic Upgrade Scope Latest agent release (Default) For One release before the latest one, Cortex XDR upgrades the agent to
the previous release before the latest, including maintenance releases.
One release before the latest one
Major releases are numbered X.X, such as release 8.0, or 8.2. Maintenance
Only maintenance releases releases are numbered X.X.X, such as release 8.2.2.
For Only maintenance releases in a specific version, select the required
Only maintenance releases in a
release version.
specific version
Upgrade Rollout Immediate (Default) The Cortex XDR agent will automatically get any new agent release,
maintenance and new features
Delayed
For Delayed, set the delay period (number of days) to wait after the version
release before upgrading endpoints. Choose a value between 7 and 45.
Global agent settings
Configure the Cortex XDR agent upgrade scheduler and the number of parallel upgrades to apply to all endpoints in your organization.
1. Go to Settings → Configurations → Agent Configurations, and scroll to Agent upgrade.
2. Configure the Cortex XDR agent upgrade scheduler and the number of parallel upgrades.
Item Description
Amount of parallel During the first week of a new Cortex XDR agent release rollout, only a single batch of agents is upgraded. After that, auto-
upgrades upgrades continue to be deployed across your network with the number of parallel upgrades as configured.
Set the number of parallel agent upgrades, where the maximum is 500 agents.
Displayed in the footer
Page 109 of 952
Cortex XDR Documentation
Displayed in the header
Item Description
Days in week Schedule the upgrade task for specific days of the week.
Schedule Schedule a specific time range. The minimum range is four hours.
Content updates
When a new content update is available, Cortex XDR 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 XDR. By staggering the distribution of content updates, Cortex XDR reduces the bandwidth
load and prevents bandwidth saturation due to the high volume and size of the content updates across many endpoints. You can view the distribution of
endpoints by content update version from the dashboard.
You can configure whether to update content per endpoint or use the global settings. The information in this topic will help you select and configure these
methods.
Content update settings per endpoint
Configure content update options for agents within the organization to ensure it is always protected with the latest security measures.
These profiles can be configured on one or more endpoints, static/dynamic groups, tags, IP ranges, endpoint names, or other parameters that allow the
creation of logical endpoint groups.
The following table describes the available Content Configuration options:
1. Go to Endpoints → Policy Management → Profiles , and then edit an existing profile, add a new profile, or import from a file.
2. Choose the operating system, and select Agent Settings. Then click Next.
3. Go to Content Configuration. By default, this option is Enabled.
Item Options More Details
Content Auto-Update Enabled (Default) When Content Auto-Update is enabled, the Cortex XDR agent retrieves the
most updated content and deploys it on the endpoint.
Disabled
If you disable content updates, the agent stops retrieving them from the
Cortex XDR tenant, and keeps working with the current content on the
endpoint.
Staging Content Enabled Enable users to deploy agent staging content on selected test
environments. Staging content is released before production content,
Disabled (Default) allowing for early evaluation of the latest content update.
Displayed in the footer
Page 110 of 952
Cortex XDR Documentation
Displayed in the header
Item Options More Details
Content Rollout Immediate (Default) The Cortex XDR agent can retrieve content updates immediately as they
are available, after a pre-configured delay period of up to 30 days, or you
Delayed
can select a specific version.
Specific When you delay content updates, the Cortex XDR agent will retrieve the
content according to the configured delay. For example, if you configure a
delay period of two days, the agent will not use any content released in the
last 48 hours.
Global content update settings
1. Go to Settings → Configurations → Agent Configurations, and scroll to Content Management.
2. Configure the content update cadence and bandwidth allocation within your organization.
Item Description
Enable bandwidth Based on the number of agents you want to update with content and upgrade packages, active or future agents, the Cortex
control XDR 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 XDR supports between 20 - 10000 Mbps, you can enter
one of the recommended values or enter one of your own. For optimized performance and reduced bandwidth consumption,
it is recommended that you install and update new agents with Cortex XDR agents 7.3 and later include the content
package built in using SCCM.
XDR Calculator for Based on the number of agents you want to update with content and upgrade packages, active or future agents, the Cortex
Recommended XDR calculator configures the recommended amount of Mbps (Megabits per second) required for a connected agent to
Bandwidth retrieve a content update over 24 hours or a week. This calculation is based on connected agents and includes an overhead
for large content update.
Cortex XDR supports between 20 - 10000 Mbps.
It is recommended to allocate a minimum of 20 Mbps, or you can enter a value.
Enable minor To enforce immediate protection against the latest threats, enable minor content updates. Otherwise, the content updates in
content version your network occur only on major releases.
updates
12.1.9 | 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 XDR called
content updates. Content updates can contain changes or updates to any of the following:
Cortex XDR 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.
Displayed in the footer
Page 111 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR 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 XDR. By staggering the distribution of content updates, Cortex XDR 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 XDR 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 XDR 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, 1280-<build_num> and 1290-<build_num> are major releases, and 1281-<build_num> , 1282-
<build_num>, and 1291-<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 XDR global agent configurations.
Content download source, as part of the Cortex XDR 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.
12.1.10 | 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.
When you enable behavioral threat protection or EDR data collection in your endpoint security policy, the Cortex XDR agent can also continuously monitor
endpoint activity for malicious event chains identified by Palo Alto Networks. The endpoint data that the Cortex XDR agent collects when you enable these
capabilities varies by platform type.
Agents with Cortex XDR Pro per Endpoint apply limits and filters on network, file, and registry logs. To expand these limits and filters requires the Extended
Threat Hunting Data (XTH) add-on.
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:
Displayed in the footer
Page 112 of 952
Cortex XDR Documentation
Displayed in the header
Field Description
Absolute timestamp Kernel system time
Relative timestamp Uptime since the computer started
Thread ID ID of the originating thread
Process ID ID of the originating process
Process creation time Part of the process unique ID per boot session (PID + creation time)
Sequence ID Unique integer per boot session
Primary user SID Unique identifier of the user
Impersonating user SID Unique identifier of the impersonating user, if applicable
EDR data collected for Windows endpoints
Category Events Attributes
Mount a device (volume and hardware) Mount 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
Displayed in the footer
Page 113 of 952
Cortex XDR Documentation
Displayed in the header
Category Events Attributes
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
Move and later)
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)
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
Displayed in the footer
Page 114 of 952
Cortex XDR Documentation
Displayed in the header
Category Events Attributes
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)
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)
Displayed in the footer
Page 115 of 952
Cortex XDR Documentation
Displayed in the header
Category Events Attributes
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.
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 collected for Windows endpoints
In Traps 6.1.3 and later releases, Cortex XDR and Traps agents can send the following Windows Event Logs to the tenant.
For more information on how to set up Windows event logs collection, see Microsoft Windows security auditing setup.
Path Provider Event IDs And Description
Application EMET
Application Windows Error Reporting Only for Windows Error Reporting (WER) events when an application
stops unexpectedly
Displayed in the footer
Page 116 of 952
Cortex XDR Documentation
Displayed in the header
Path Provider Event IDs And Description
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.
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
Displayed in the footer
Page 117 of 952
Cortex XDR Documentation
Displayed in the header
Path Provider Event IDs And Description
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 Local Modifications (Levels 0, 2, 4)
Security
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
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
Displayed in the footer
Page 118 of 952
Cortex XDR Documentation
Displayed in the header
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
Displayed in the footer
Page 119 of 952
Cortex XDR Documentation
Displayed in the header
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
Displayed in the footer
Page 120 of 952
Cortex XDR Documentation
Displayed in the header
Category Events Attributes
Files Create Full path of the file
*Requires XTH add-on Open Hash of the file
Write For specific files only and only if the file was
written.
Delete
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
12.2 | Install and manage endpoints
Abstract
Learn how to set up profiles, policies and other settings for endpoint protection, how to install Cortex XDR agent on endpoints, and how to manage them after
installation.
Endpoint protection starts with the Cortex XDR agent that is installed on each endpoint in your environment. The agent package that you install on endpoints
contains many settings that are configured by default, out-of-the-box, to enable you to get protection up and running quickly. However, these settings can also
be modified and used in different combinations, by using profiles, which are then mapped to policies, and by configuring global settings.
Several endpoint management tasks can be performed remotely by administrators, from Cortex XDR. These include tasks such as applying tags and aliases to
endpoints, upgrading the Cortex XDR agent, uninstalling and deleting the Cortex XDR agent, and more.
To stay up to date with the latest policy and endpoint status, Cortex XDR communicates regularly with your Cortex XDR agents. For example, when you
upgrade your endpoints to the latest release, Cortex XDR creates an installation package and distributes it to the agent on their next communication. Similarly,
Displayed in the footer
Page 121 of 952
Cortex XDR Documentation
Displayed in the header
the agent can send back data from the endpoint to Cortex XDR, such as data gathered on the endpoint or tech support files. In Cortex XDR, there are two
types of communication.
12.2.1 | Set up endpoint protection
Abstract
Set up endpoint protection profiles and policies, exceptions, endpoint hardening, and other endpoint settings.
Set up endpoint protection profiles and policies, exceptions, endpoint hardening, and other endpoint settings.
12.2.1.1 | Set up endpoint profiles and exception rules
Abstract
Endpoint security profiles can be used immediately, or customized, to protect your endpoints from threats.
Cortex XDR provides default security profiles that you can use out-of-the-box to immediately begin protecting your endpoints from threats. These profiles are
applied to endpoints by mapping them to policies, and then mapping the policies to endpoints.
While security rules enable you to block or allow files to run on your endpoints, security profiles help you customize and reuse settings across different groups
of endpoints. When the Cortex XDR agent detects behavior that matches a rule defined in your security policy, the Cortex XDR agent applies the security
profile that is attached to the rule for further inspection.
Profiles associated with one or more targets that are beyond the scope of your defined user permissions are locked, and cannot be edited.
12.2.1.1.1 | Set up malware prevention profiles
Abstract
Configure malware prevention profiles to control the actions taken by Cortex XDR agents when known malware, macros, and unknown files try to run.
Malware prevention profiles protect against the execution of malware including trojans, viruses, worms, and grayware. Malware prevention 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.
You can configure the action that Cortex XDR agents take when known malware, macros, and unknown files try to run on 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. The
default setting for each capability is shown in parentheses in the user interface. To fine-tune your malware prevention 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 that you override, clear the Use Default option, and select the setting of your choice.
In this profile, the Report options configure the endpoints to report the corresponding suspicious files, actions, processes, or behaviors to Cortex XDR, without
blocking them. The Disabled options configure the endpoints to neither analyze nor report the corresponding malware or behavior.
The tasks below are organized according to the operating systems used by your organization's endpoints.
Windows
1. Add a new profile and define basic settings.
a. From Cortex XDR, select Endpoints → Policy Management → Prevention → Profiles. Click +Add Profile, and select whether to create a new profile,
or to import a profile from a file.
New profiles based on imported profiles are added, and do not replace existing ones.
b. Select the Windows platform, and Malware as the profile type.
c. Click Next.
d. For Profile Name, enter a unique name for 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.
e. For Description, to provide additional context for the purpose or business reason for creating the profile, enter a profile description. For example,
you might include an incident identification number or a link to a help desk ticket.
2. Configure Portable Executable and DLL Examination. The Cortex XDR agent can analyze and prevent malicious executable files and DLL files from
running on Windows endpoints.
As part of the anti-malware security flow, the Cortex XDR agent leverages the operating system's 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. If the endpoint is not connected to the internet, or you
experience delays with executables and DLLs running on the endpoint, contact Customer Support.
Displayed in the footer
Page 122 of 952
Cortex XDR Documentation
Displayed in the header
Item Options More Details
Action Mode Block When the Cortex XDR agent detects attempts to run malware, it
performs the configured action.
Report
Disabled
Quarantine Malicious Disabled By default, the Cortex XDR agent blocks malware from running, but
Executables does not quarantine the file. You can enable one of the options to
Quarantine WildFire malware quarantine files, depending on the verdict issuer.
verdict
The Quarantine Malicious Executables feature is not available for
Quarantine WildFire and Local malware identified on network drives.
Analysis malware verdict
Action when file is Allow Allow: Unknown files are not blocked and local verdicts are not issued
unknown to WildFire for them.
Run Local Analysis
Run Local Analysis: The Cortex XDR agent uses embedded machine
Block
learning to determine the likelihood that an unknown file is malware, and
issues a local verdict for the file.
Block: Block unknown files but do not run local analysis. In this case,
unknown files remain blocked until the Cortex XDR agent receives an
official WildFire verdict.
Action when file is benign Allow Select the action to take when a file with a Benign Low Confidence
with low confidence verdict from WildFire tries to run on the endpoint. When local analysis is
Run Local Analysis
enabled, the Cortex XDR agent uses embedded machine learning to
Block 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, the file remains blocked until the Cortex XDR agent receives a
high-confidence WildFire verdict.
To enable this capability, ensure that WildFire analysis scoring is also
enabled in Global Agent Settings.
For optimal user experience, we recommend that you set the action
mode to either Allow or Run Local Analysis.
Upload unknown files to Enabled When enabled, the Cortex XDR agent sends unknown files to Cortex
WildFire XDR, and Cortex XDR sends the files to WildFire for analysis.
Disabled
The file types that the Cortex XDR agent analyzes depend on the
platform type. WildFire accepts files up to 100 MB in size.
Treat Grayware as Enabled When enabled, Cortex XDR treats all grayware with the same Action
Malware Mode as configured for malware.
Disabled
When disabled, grayware is considered benign, and is not blocked.
3. Configure options for Office Files with Macros Examination. The Cortex XDR agent can analyze and prevent malicious macros embedded in Microsoft
Office files (Word, Excel) from running on Windows endpoints.
Displayed in the footer
Page 123 of 952
Cortex XDR Documentation
Displayed in the header
Item Options More Details
Action Mode Block When the Cortex XDR agent detects attempts to run malware, it
performs the configured action.
Report
Disabled
Action when file is Allow Select the action to take when a file is not recognized by WildFire. When
unknown to WildFire local analysis is enabled, the Cortex XDR agent uses embedded
Run Local Analysis machine learning to determine the likelihood that an unknown file is
malware, and issues a local verdict for the file.
Block
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.
Action when WildFire Allow Select the action to take when a file with a Benign Low Confidence
verdict is Benign Low verdict from WildFire tries to run on the endpoint. When local analysis is
Confidence Run Local Analysis enabled, the Cortex XDR agent uses embedded machine learning to
determine the likelihood that an unknown file is malware, and issues a
Block
local verdict for the file.
If you block this file but do not run a local analysis, the file remains
blocked until the Cortex XDR agent receives a high-confidence WildFire
verdict.
To enable this capability, ensure that WildFire analysis scoring is also
enabled in Global Agent Settings.
For optimal user experience, we recommend that you set the action
mode to either Allow or Run Local Analysis.
Upload unknown files to Enabled When enabled, the Cortex XDR agent sends unknown files to Cortex
WildFire XDR, and Cortex XDR sends the files to WildFire for analysis. For macro
Disabled
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 100 MB in size.
Examine Office files from Enabled You can enable the Cortex XDR agent to examine Microsoft Office files
network drives on network drives when they contain a macro that attempts to run.
Disabled
4. Configure PowerShell Script Files to analyze and prevent malicious PowerShell script files from running on Windows-based endpoints.
Item Options More Details
Action Mode Block When the Cortex XDR agent detects attempts to run PowerShell script
files, it performs the configured action.
Report
Disabled
Displayed in the footer
Page 124 of 952
Cortex XDR Documentation
Displayed in the header
Item Options More Details
Quarantine Malicious Disabled By default, the Cortex XDR agent blocks malware from running, but
Script Files does not quarantine the file. You can enable one of the options to
Quarantine WildFire malware
quarantine files, depending on the verdict issuer.
verdict
The Quarantine Malicious Script Files feature is not available for malware
Quarantine WildFire and Local identified on network drives.
Analysis malware verdict
Action when file is Allow Allow: Unknown files are not blocked and local verdicts are not issued
unknown to WildFire for them.
Run Local Analysis
Run Local Analysis: The Cortex XDR agent uses embedded machine
Block learning to determine the likelihood that an unknown file is malware, and
issues a local verdict for the file.
Block: Block unknown files but do not run local analysis. In this case,
unknown files remain blocked until the Cortex XDR agent receives an
official WildFire verdict.
Upload unknown files to Enabled When enabled, the Cortex XDR agent sends unknown files to Cortex
WildFire XDR, and Cortex XDR sends the files to WildFire for analysis.
Disabled
The file types that the Cortex XDR agent analyzes depend on the
platform type. WildFire accepts files up to 100 MB in size.
5. Configure On-write File Protection to monitor and take action on malicious files during the on-write process.
Item Options More Details
Action Mode Enabled When enabled, the Cortex XDR agent monitors for malicious files during
the on-write process, and if finds any, it sends alerts and quarantines the
Disabled files.
6. Configure Endpoint Scanning to scan endpoints and attached removable drives for dormant, inactive malware.
Item Options More Details
End-User Initiated Local Enabled When enabled, the endpoint user can perform a local scan on the
Scan endpoint.
Disabled
Displayed in the footer
Page 125 of 952
Cortex XDR Documentation
Displayed in the header
Item Options More Details
Periodic Scan Enabled We recommend that you disable scheduled scanning. VDI machine
scans are based on the golden image and additional files will be
Disabled
examined upon execution.
Periodic scanning enables you to scan endpoints on a recurring basis
without waiting for malware to run on the endpoint. When enabled, you
can set the time interval (weekly or monthly) and the day and time at
which to start scanning. In addition, you can choose to enable or disable
scanning of removable media drives.
Periodic scanning is persistent, and if the scan is scheduled to start
while the endpoint is turned off, the scan will be initiated when the
endpoint is turned on again. The scheduling of future scans is not
affected by this delay.
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.
7. Configure the Global Behavioral Threat Protection Rules. Use these rules to protect endpoints from malicious causality chains.
Item Options More Details
Action Mode Block The Cortex XDR agent protects against malicious causality chains, using
behavioral threat protection rules. When the action mode is set to Block,
Report the Cortex XDR agent terminates all processes and threads in the event
Disabled chain up to the causality group owner (CGO).
Quarantine Malicious Files Enabled When enabled, the Cortex XDR agent quarantines the processes and
the artifacts, such as files, related to the CGO.
Disabled
When disabled, the Cortex XDR agent does not quarantine the CGO of
an event chain, nor any scripts or files called by the CGO.
Action Mode for Block Behavioral threat protection rules can also detect attempts to load
Vulnerable Drivers vulnerable drivers which can be used to bypass the Cortex XDR agent.
Report
Protection As with other rules, Palo Alto Networks threat researchers can deliver
Disabled changes to vulnerable driver rules with content updates.
Advanced API Monitoring Enabled When enabled, the Cortex XDR agent adds additional hooks in user
mode processes for increased coverage of anti-exploit and anti-malware
Disabled modules.
8. Configure Credential Gathering Protection to protect endpoints from processes trying to access or steal passwords and other credentials.
Item Options More Details
Action Mode Block The Cortex XDR agent protects against all processes and threads in the
event chain up to the credential gathering process or file.
Report
When this module is disabled, the Cortex XDR agent does not analyze
Disabled
the event chain and does not block credential gathering.
Displayed in the footer
Page 126 of 952
Cortex XDR Documentation
Displayed in the header
Item Options More Details
Quarantine Malicious Files Enabled When enabled, the Cortex XDR agent quarantines the process or file
related to the credential gathering event chain.
Disabled
9. Configure Anti Webshell Protection to protect endpoint processes from dropping malicious web shells.
Item Options More Details
Action Mode Block In a causality chain, when the Cortex XDR agent detects a process that
attempts to drop malicious web shells, it performs the configured action.
Report
Disabled
Quarantine Malicious Files Enabled When enabled, the Cortex XDR agent quarantines the processes or files
that are related to the web shell drop event chain, and any scripts or
Disabled files called by the web shell dropping process.
10. Configure Financial Malware Threat Protection to protect against techniques specific to financial and banking malware.
Item Options More Details
Action Mode Block In a causality chain, when the Cortex XDR agent detects a process that
attempts to access or steal financial or banking information, the Cortex
Report XDR agent performs the configured action.
Disabled
Quarantine Malicious Files Enabled When enabled, the Cortex XDR agent quarantines the processes or files
related to the financial information gathering event chain, and scripts or
Disabled
files called by the financial information gathering process.
Crypto Wallet Protection Enabled When enabled, provides protection for cryptocurrency wallets that are
stored on endpoints. Cryptocurrency wallets store private keys that are
Disabled used to access crypto assets.
11. Configure Cryptominers Protection to protect against attempts to locate or steal cryptocurrencies.
Item Options More Details
Action Mode Block In a causality chain, when the Cortex XDR agent detects a cryptomining
process or file, the Cortex XDR agent performs the configured action.
Report
Disabled
Quarantine Malicious Files Enabled When enabled, the Cortex XDR agent quarantines the process or file
detected during a cryptocurrency gathering attempt.
Disabled
12. Configure In-process shellcode protection to protect against in-process shellcode attack threats.
Displayed in the footer
Page 127 of 952
Cortex XDR Documentation
Displayed in the header
Item Options More Details
Action Mode Block 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
Report
XDR agent performs the configured action.
Disabled
Quarantine Malicious Files Enabled When enabled, the Cortex XDR agent quarantines the in-process
shellcode processes or files related to a causality chain.
Disabled
Process Injection 32 Bit Enabled When enabled, the Cortex XDR agent quarantines 32 bit in-process
shellcode processes or files related to a causality chain.
Disabled
Process injection 32 bit is set to Enabled by default for all new tenants
created after 25 June 2023. For tenants created before this date, the
default was set to Disabled.
Shellcode AI Protection Enabled When enabled, Precision AI-based detection rules use machine learning
to detect and prevent in-memory shellcode attacks.When enabled,
Disabled Precision AI-based detection rules use machine learning to detect and
prevent in-memory shellcode attacks.
13. Configure Malicious Device Prevention to protect against the connection of potentially malicious devices to endpoints.
Item Options More Details
Action Mode Block When the Cortex XDR agent detects the connection of potentially
malicious external device to an endpoint, the Cortex XDR agent
Report
performs the configured action.
Disabled
14. Configure UAC Bypass Prevention to protect against the User Access Control (UAC) bypass mechanism that is associated with privilege elevation
attempts.
Item Options More Details
Action Mode Block When the Cortex XDR agent detects a UAC bypass
mechanism, the Cortex XDR agent performs the configured action. The
Report
Block option blocks all processes and threads in the event chain up to
Disabled the UAC bypass mechanism.
Quarantine Malicious Files Enabled When enabled, the Cortex XDR agent quarantines the UAC bypass
processes or files related to the chain, and any scripts or files released
Disabled to the UAC bypass mechanism.
15. Configure Anti Tampering Protection to protect against tampering attempts.
Displayed in the footer
Page 128 of 952
Cortex XDR Documentation
Displayed in the header
Item Options More Details
Action Mode Block When the Cortex XDR agent detects a tampering attempt, including
modification and/or termination of the Cortex XDR agent, it
Report
performs the configured action.
Disabled 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.
Quarantine Malicious Files Enabled When enabled, the Cortex XDR agent quarantines the processes or files
that are related to the tampering attempt.
Disabled
Malicious Safe Mode Block Define the action to take when the Cortex XDR agent detects safe mode
Rebooting Protection reboot attempts made suspiciously by other apps.
Report
Disabled
16. Configure IIS Protection to protect against Internet Information Server (IIS) attacks.
Item Options More Details
Action Mode Block When the Cortex XDR agent detects a threat that targets an Internet
Information Server (IIS), the Cortex XDR agent performs the configured
Report action.
Disabled
Quarantine Malicious Files Enabled When enabled, the Cortex XDR agent quarantines the processes or files
that are related to the IIS attack.
Disabled
17. Configure UEFI Protection, to protect the endpoint from Unified Extensible Firmware Interface (UEFI) manipulation attempts.
Item Options More Details
Action Mode Block When the Cortex XDR agent detects UEFI manipulation attempts, it
performs the configured action. When Block is selected, the Cortex XDR
Report agent blocks all processes and threads in the event chain, up to the
UEFI threat.
Disabled
Quarantine Malicious Files Enabled When enabled, the Cortex XDR agent quarantines the processes or files
that are related to the UEFI threat.
Disabled
18. Configure Ransomware Protection to protect against encryption-based activity associated with ransomware attacks.
Displayed in the footer
Page 129 of 952
Cortex XDR Documentation
Displayed in the header
Item Options More Details
Action Mode Block When the Cortex XDR agent detects ransomware activity locally on the
endpoint or in pre-defined network folders, the Cortex XDR agent
Report
performs the configured action.
Disabled
Quarantine Malicious Enabled When enabled, the Cortex XDR agent quarantines the processes that
Process are related to the ransomware activity.
Disabled
The Quarantine Malicious Process option is only available if Action
Mode is set to Block.
Protection Mode Normal By default, Protection Mode is set to Normal, where the decoy files on
the endpoint are present, but do not interfere with benign applications
Aggressive and end user activity on the endpoint. If you suspect your network has
been infected with ransomware, and you need to provide better
coverage, you can apply the Aggressive protection mode. Aggressive
mode exposes more applications in your environment to the Cortex XDR
agent decoy files. However, it also increases the likelihood that benign
software is exposed to decoy files, raising false ransomware alerts, and
impairing user experience.
19. Configure Malicious Child Process Protection to prevent script-based attacks. Such attacks can be used to deliver malware by blocking targeted
processes that are commonly used to bypass traditional security methods.
Item Options More Details
Action Mode Block When the Cortex XDR agent detects known suspicious parent-child
relationships that are used to bypass security, the Cortex XDR agent
Report
performs the configured action. When Block is selected, known
Disabled suspicious child processes are blocked from starting.
20. To prevent attacks that extract passwords from memory using the Mimikatz tool, set Password Theft Protection to Enabled.
21. Configure Respond to Malicious Causality Chains options, which define the automatic response actions taken by the Cortex XDR agent when it identifies
malicious causality chains.
Item Options More Details
Terminate Connection and Enabled When the Cortex XDR agent identifies a remote network connection that
Block IP Address of attempts to perform malicious activity—such as encrypting endpoint
Remote Causality Group Disabled files—the agent can automatically block the IP address to close all
Owner existing communication, and to block new connections from this IP
address to the endpoint. When Cortex XDR blocks 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.
22. Configure the Network Packet Inspection Engine to analyze network packet data for malicious behavior.
Displayed in the footer
Page 130 of 952
Cortex XDR Documentation
Displayed in the header
Item Options More Details
Action Mode Terminate session By analyzing the network packet data, the Cortex XDR agent can
already detect malicious behavior at the network level, and provide
Report
protection to the growing corporate network boundaries. The engine
Disabled leverages both Palo Alto Networks NGFW content rules, and new Cortex
XDR content rules created by the Cortex XDR Research Team. The
Cortex XDR content rules are updated through the security content. This
feature focuses on detecting outbound C2 activity.
The Terminate session option configures Cortex XDR agents to analyze
connections and to drop the malicious connections.
The Report option configures XDR agents to analyze connections, to
allow the transmission of packets in your network, but to report them to
Cortex XDR.
23. Configure Dynamic Kernel Protection to protect the endpoint from kernel-level threats such as bootkits, rootkits, and susceptible drivers.
Item Options More Details
Action Mode Block When set to Block, this protection module loads during the boot process
to protect the endpoint against malicious processes running at boot
Report time.
Disabled
24. To save the profile, click Create.
What to do next
If you are ready to apply your new profile to endpoints, you do this by adding it to a policy rule. If you still need to define other profiles, you can do this later.
During policy rule creation or editing, you select the endpoints to which to assign the policy. There are different ways of doing this, such as:
Create a policy rule from the Prevention Profiles page
1. Navigate to Endpoints → Policy Management → Prevention → Profiles.
2. Right-click your new profile, and select Create a new policy rule using this profile.
3. Configure the policy rule.
Edit an existing policy rule from the Policy Rules page
1. Navigate to Endpoints → Policy Management → Prevention → Policy Rules.
2. Right click an existing policy and select Edit.
3. Add your new profile to the policy rule.
Create a new policy rule from the Policy Rules page
1. Navigate to Endpoints → Policy Management → Prevention → Policy Rules.
2. Click Add Policy.
3. Configure a new policy that includes your new profile.
macOS
1. Add a new profile and define basic settings.
a. From Cortex XDR, select Endpoints → Policy Management → Prevention → Profiles. Click +Add Profile, and select whether to create a new profile,
or to import a profile from a file.
New profiles based on imported profiles are added, and do not replace existing ones.
b. Select the macOS platform, and Malware as the profile type.
c. Click Next.
Displayed in the footer
Page 131 of 952
Cortex XDR Documentation
Displayed in the header
d. For Profile Name, enter a unique name for 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.
e. For Description, to provide additional context for the purpose or business reason for creating the profile, enter a profile description. For example,
you might include an incident identification number or a link to a help desk ticket.
2. Configure Endpoint Scanning to scan endpoints and attached removable drives for dormant, inactive malware.
Item Options More Details
Periodic Scan Enabled We recommend that you disable scheduled scanning. VDI machine
scans are based on the golden image and additional files will be
Disabled
examined upon execution.
Periodic scanning enables you to scan endpoints on a recurring basis
without waiting for malware to run on the endpoint. When enabled, you
can set the time interval (weekly or monthly) and the day and time at
which to start scanning. In addition, you can choose to enable or disable
scanning of removable media drives.
Periodic scanning is persistent, and if the scan is scheduled to start
while the endpoint is turned off, the scan will be initiated when the
endpoint is turned on again. The scheduling of future scans is not
affected by this delay.
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.
3. Configure the Global Behavioral Threat Protection Rules. These rules can be used to protect endpoints from malicious causality chains.
Item Options More Details
Action Mode Block The Cortex XDR agent protects against malicious causality chains, using
behavioral threat protection rules. When the action mode is set to Block,
Report the Cortex XDR agent terminates all processes and threads in the event
chain up to the causality group owner (CGO).
Disabled
Quarantine Malicious Files Enabled When enabled, the Cortex XDR agent quarantines the processes and
the artifacts, such as files, related to the CGO.
Disabled
When disabled, the Cortex XDR agent does not quarantine the CGO of
an event chain, nor any scripts or files called by the CGO.
4. Configure Credential Gathering Protection to protect endpoints from processes trying to access or steal passwords and other credentials.
Item Options More Details
Action Mode Block The Cortex XDR agent protects against all processes and threads in the
event chain up to the credential gathering process or file.
Report
When this module is disabled, the Cortex XDR agent does not analyze
Disabled the event chain and does not block credential gathering.
Quarantine Malicious Files Enabled When enabled, the Cortex XDR agent quarantines the process or file
related to the credential gathering event chain.
Disabled
5. Configure Anti Webshell Protection to protect endpoint processes from dropping malicious web shells.
Displayed in the footer
Page 132 of 952
Cortex XDR Documentation
Displayed in the header
Item Options More Details
Action Mode Block In a causality chain, when the Cortex XDR agent detects a process that
attempts to drop malicious web shells, it performs the configured action.
Report
Disabled
Quarantine Malicious Files Enabled When enabled, the Cortex XDR agent quarantines the processes or files
that are related to the web shell drop event chain, and any scripts or
Disabled files called by the web shell dropping process.
6. Configure Financial Malware Threat Protection to protect against techniques specific to financial and banking malware.
Item Options More Details
Action Mode Block In a causality chain, when the Cortex XDR agent detects a process that
attempts to access or steal financial or banking information, the Cortex
Report
XDR agent performs the configured action.
Disabled
Quarantine Malicious Files Enabled When enabled, the Cortex XDR agent quarantines the processes or files
related to the financial information gathering event chain, and scripts or
Disabled files called by the financial information gathering process.
Crypto Wallet Protection Enabled When enabled, provides protection for cryptocurrency wallets that are
stored on endpoints. Cryptocurrency wallets store private keys that are
Disabled
used to access crypto assets.
7. Configure Cryptominers Protection to protect against attempts to locate or steal cryptocurrencies.
Item Options More Details
Action Mode Block In a causality chain, when the Cortex XDR agent detects a cryptomining
process or file, the Cortex XDR agent performs the configured action.
Report
Disabled
Quarantine Malicious Files Enabled When enabled, the Cortex XDR agent quarantines the process or file
detected during a cryptocurrency gathering attempt.
Disabled
8. Configure Anti Tampering Protection to protect against tampering attempts.
Item Options More Details
Action Mode Block When the Cortex XDR agent detects a tampering attempt, including
modification and/or termination of the Cortex XDR agent, it
Report performs the configured action.
Disabled 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.
Displayed in the footer
Page 133 of 952
Cortex XDR Documentation
Displayed in the header
Item Options More Details
Quarantine Malicious Files Enabled When enabled, the Cortex XDR agent quarantines the processes or files
that are related to the tampering attempt.
Disabled
9. Configure Ransomware Protection to protect against encryption-based activity associated with ransomware attacks.
Item Options More Details
Action Mode Block When the Cortex XDR agent detects ransomware activity locally on the
endpoint or in pre-defined network folders, the Cortex XDR agent
Report
performs the configured action.
Disabled
Quarantine Malicious Files Enabled When enabled, the Cortex XDR agent quarantines the files that are
related to the ransomware activity.
Disabled
10. Configure Malicious Child Process Protection to prevent script-based attacks. Such attacks can be used to deliver malware by blocking targeted
processes that are commonly used to bypass traditional security methods.
Item Options More Details
Action Mode Block When the Cortex XDR agent detects known suspicious parent-child
relationships that are used to bypass security, the Cortex XDR agent
Report
performs the configured action. When Block is selected, known
Disabled suspicious child processes are blocked from starting.
Quarantine Malicious Files Enabled When enabled, the Cortex XDR agent quarantines the files that are
related to a malicious child process.
Disabled
11. Configure Mach-O Files Examination to check Mach-O files for malware.
Item Options More Details
Action Mode Block When the Cortex XDR agent detects attempts to run malware, it
performs the configured action.
Report
Disabled
Quarantine malicious Disabled By default, the Cortex XDR agent blocks malware from running, but
Mach-O files does not quarantine the file. You can enable one of the options to
Quarantine WildFire malware quarantine files, depending on the verdict issuer.
verdict
The Quarantine Malicious Mach-O Files feature is not available for
Quarantine WildFire and Locals malware identified on network drives.
Analysis malware verdict
Displayed in the footer
Page 134 of 952
Cortex XDR Documentation
Displayed in the header
Item Options More Details
Action on unknown Mach- Allow Allow: Unknown files are not blocked and local verdicts are not issued
O files to WildFire for them.
Run Local Analysis
Run Local Analysis: The Cortex XDR agent uses embedded machine
Block learning to determine the likelihood that an unknown file is malware, and
issues a local verdict for the file.
Block: Block unknown files but do not run local analysis. In this case,
unknown files remain blocked until the Cortex XDR agent receives an
official WildFire verdict.
Action when WildFire Allow Select the action to take when a file with a Benign Low Confidence
verdict is Benign Low verdict from WildFire tries to run on the endpoint. When local analysis is
Confidence Run Local Analysis enabled, the Cortex XDR agent uses embedded machine learning to
determine the likelihood that an unknown file is malware, and issues a
Block
local verdict for the file. If you block this file but do not run a local
analysis, the file remains blocked until the Cortex XDR agent receives a
high-confidence WildFire verdict.
For optimal user experience, we recommend that you set the action
mode to either Allow or Run Local Analysis.
Upload Mach-O files for Enabled When enabled, the Cortex XDR agent sends unknown files to Cortex
cloud analysis XDR, and Cortex XDR sends the files to WildFire for analysis.
Disabled
The file types that the Cortex XDR agent analyzes depend on the
platform type. WildFire accepts files up to 100 MB in size.
Treat Grayware as Enabled When enabled, Cortex XDR treats all grayware with the same Action
Malware Mode as configured for malware.
Disabled
When disabled, grayware is considered benign, and is not blocked.
12. Configure Local File Threat Examination to enable detection of malicious files on the endpoint.
This module is supported by Cortex XDR agent 8.1.0 and later releases.
Item Options More Details
Action Mode Enabled When enabled, the Local Threat-Evaluation Engine (LTEE) analyzes the
endpoint for PHP files arriving from a web server and alerts about any
Disabled malicious PHP scripts.
Terminate Malicious Enabled When enabled, the Cortex XDR agents terminates malicious PHP files on
Processes the endpoint.
Disabled
Quarantine Malicious Files Enabled When enabled, the Cortex XDR agent quarantines malicious files on the
endpoint and does not quarantine updated files.
Disabled
13. Configure DMG File Examination to check DMG files for malware.
Displayed in the footer
Page 135 of 952
Cortex XDR Documentation
Displayed in the header
Item Options More Details
Action Mode Block When the Cortex XDR agent detects attempts to run malware in DMG
files, it performs the configured action.
Report
Disabled
Quarantine Malicious Enabled When enabled, the Cortex XDR agent quarantines malicious executable
Executables DMG files.
Disabled
The Quarantine Malicious Executables feature is not available for
malware identified on network drives.
Upload unknown files to Enabled When enabled, the Cortex XDR agent sends unknown files to Cortex
WildFire XDR, and Cortex XDR sends the files to WildFire for analysis.
Disabled
The file types that the Cortex XDR agent analyzes depend on the
platform type. WildFire accepts files up to 100 MB in size.
14. To save the profile, click Create.
What to do next
If you are ready to apply your new profile to endpoints, you do this by adding it to a policy rule. If you still need to define other profiles, you can do this later.
During policy rule creation or editing, you select the endpoints to which to assign the policy. There are different ways of doing this, such as:
Create a policy rule from the Prevention Profiles page
1. Navigate to Endpoints → Policy Management → Prevention → Profiles.
2. Right-click your new profile, and select Create a new policy rule using this profile.
3. Configure the policy rule.
Edit an existing policy rule from the Policy Rules page
1. Navigate to Endpoints → Policy Management → Prevention → Policy Rules.
2. Right click an existing policy and select Edit.
3. Add your new profile to the policy rule.
Create a new policy rule from the Policy Rules page
1. Navigate to Endpoints → Policy Management → Prevention → Policy Rules.
2. Click Add Policy.
3. Configure a new policy that includes your new profile.
Linux
1. Add a new profile and define basic settings.
a. From Cortex XDR, select Endpoints → Policy Management → Prevention → Profiles. Click +Add Profile, and select whether to create a new profile,
or to import a profile from a file.
New profiles based on imported profiles are added, and do not replace existing ones.
b. Select the Linux platform, and Malware as the profile type.
c. Click Next.
d. For Profile Name, enter a unique name for 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.
e. For Description, to provide additional context for the purpose or business reason for creating the profile, enter a profile description. For example,
you might include an incident identification number or a link to a help desk ticket.
2. Configure Endpoint Scanning to scan endpoints for dormant, inactive malware.
Endpoint scanning is enabled by default on the following: /etc, /tmp, /home, /usr, /bin, /sbin, /lib, /var, /opt, /dev, /root, /boot.
Displayed in the footer
Page 136 of 952
Cortex XDR Documentation
Displayed in the header
Item Options More Details
Periodic Scan Enabled We recommend that you disable scheduled scanning. VDI machine
scans are based on the golden image and additional files will be
Disabled
examined upon execution.
Periodic scanning enables you to scan endpoints on a recurring basis
without waiting for malware to run on the endpoint. When enabled, you
can set the time interval (weekly or monthly) and the day and time at
which to start scanning.
Periodic scanning is persistent, and if the scan is scheduled to start
while the endpoint is turned off, the scan will be initiated when the
endpoint is turned on again. The scheduling of future scans is not
affected by this delay.
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.
Scan Timeout Number of hours If a scan exceeds the number of hours configured here, the Cortex XDR
agent stops the scan.
Scan Additional 1. If you want to scan additional directories, click +Add.
Directories
2. Enter a directory path. Use ? to match a single character or * to
match any string of characters in the directory path.
3. Press Enter or click the check mark.
4. To add additional folders, repeat these steps.
3. Configure the Global Behavioral Threat Protection Rules. These rules can be used to protect endpoints from malicious causality chains.
Item Options More Details
Action Mode Block The Cortex XDR agent protects against malicious causality chains, using
behavioral threat protection rules. When the action mode is set to Block,
Report
the Cortex XDR agent terminates all processes and threads in the event
Disabled chain up to the causality group owner (CGO).
Quarantine Malicious Files Enabled When enabled, the Cortex XDR agent quarantines the processes and
the artifacts, such as files, related to the CGO.
Disabled
When disabled, the Cortex XDR agent does not quarantine the CGO of
an event chain, nor any scripts or files called by the CGO.
4. Configure Credential Gathering Protection to protect endpoints from processes trying to access or steal passwords and other credentials.
Item Options More Details
Action Mode Block The Cortex XDR agent protects against all processes and threads in the
event chain up to the credential gathering process or file.
Report
When this module is disabled, the Cortex XDR agent does not analyze
Disabled the event chain and does not block credential gathering.
Displayed in the footer
Page 137 of 952
Cortex XDR Documentation
Displayed in the header
Item Options More Details
Quarantine Malicious Files Enabled When enabled, the Cortex XDR agent quarantines the process or file
related to the credential gathering event chain.
Disabled
5. Configure Anti Webshell Protection to protect endpoint processes from dropping malicious web shells.
Item Options More Details
Action Mode Block In a causality chain, when the Cortex XDR agent detects a process that
attempts to drop malicious web shells, it performs the configured action.
Report
Disabled
Quarantine Malicious Files Enabled When enabled, the Cortex XDR agent quarantines the processes or files
that are related to the web shell drop event chain, and any scripts or
Disabled files called by the web shell dropping process.
6. Configure Financial Malware Threat Protection to protect against techniques specific to financial and banking malware.
Item Options More Details
Action Mode Block In a causality chain, when the Cortex XDR agent detects a process that
attempts to access or steal financial or banking information, the Cortex
Report XDR agent performs the configured action.
Disabled
Quarantine Malicious Files Enabled In a causality chain, when the Cortex XDR agent detects a process that
attempts to access or steal financial or banking information, the Cortex
Disabled
XDR agent performs the configured action.
7. Configure Cryptominers Protection to protect against attempts to locate or steal cryptocurrencies.
Item Options More Details
Action Mode Block In a causality chain, when the Cortex XDR agent detects a cryptomining
process or file, the Cortex XDR agent performs the configured action.
Report
Disabled
Quarantine Malicious Files Enabled When enabled, the Cortex XDR agent quarantines the process or file
detected during a cryptocurrency gathering attempt.
Disabled
8. Configure Container Escaping Protection to protect against container-escaping attempts.
Displayed in the footer
Page 138 of 952
Cortex XDR Documentation
Displayed in the header
Item Options More Details
Action Mode Block When the Cortex XDR agent detects container escaping attempts, it
performs the configured action.
Report
Disabled
9. Configure ELF File Examination to examine ELF files on endpoints and perform additional actions on them.
Item Options More Details
Action Mode Block When the Cortex XDR agent detects attempts to run malware in ELF
files, it performs the configured action.
Report
Disabled
Quarantine malicious ELF Disabled By default, the Cortex XDR agent blocks malware from running, but
files does not quarantine the file. You can enable one of the options to
Quarantine WildFire malware quarantine files, depending on the verdict issuer.
verdict
The Quarantine Malicious ELF Files feature is not available for malware
Quarantine WildFire and Local
identified on network drives.
Analysis malware verdict
Action on unknown ELF Allow Allow: Unknown files are not blocked and local verdicts are not issued
files to WildFire for them.
Run Local Analysis
Run Local Analysis: The Cortex XDR agent uses embedded machine
Block learning to determine the likelihood that an unknown file is malware, and
issues a local verdict for the file.
Block: Block unknown files but do not run local analysis. In this case,
unknown files remain blocked until the Cortex XDR agent receives an
official WildFire verdict.
Upload ELF files for cloud Enabled When enabled, the Cortex XDR agent sends unknown files to Cortex
analysis XDR, and Cortex XDR sends the files to WildFire for analysis.
Disabled
The file types that the Cortex XDR agent analyzes depend on the
platform type. WildFire accepts files up to 100 MB in size.
Treat Grayware as Enabled When enabled, Cortex XDR treats all grayware with the same Action
Malware Mode as configured for malware.
Disabled
When disabled, grayware is considered benign, and is not blocked.
10. Configure Local File Threat Examination to enable detection of malicious files on the endpoint.
This module is supported by Cortex XDR agent 8.1.0 and later releases.
Item Options More Details
Action Mode Enabled When enabled, the Local Threat-Evaluation Engine (LTEE) analyzes the
endpoint for PHP files arriving from a web server and alerts about any
Disabled malicious PHP scripts.
Displayed in the footer
Page 139 of 952
Cortex XDR Documentation
Displayed in the header
Item Options More Details
Quarantine Malicious Files Enabled When enabled, the Cortex XDR agent quarantines malicious files on the
endpoint and does not quarantine updated files.
Disabled
11. Configure Reverse Shell Protection to prevent attempts to redirect standard input and output streams to network sockets.
Item Options More Details
Action Mode Block When the Cortex XDR agent detects attempts to redirect standard input
and output streams to network sockets, it performs the configured
Report
action.
Disabled
12. To save the profile, click Create.
What to do next
If you are ready to apply your new profile to endpoints, you do this by adding it to a policy rule. If you still need to define other profiles, you can do this later.
During policy rule creation or editing, you select the endpoints to which to assign the policy. There are different ways of doing this, such as:
Create a policy rule from the Prevention Profiles page
1. Navigate to Endpoints → Policy Management → Prevention → Profiles.
2. Right-click your new profile, and select Create a new policy rule using this profile.
3. Configure the policy rule.
Edit an existing policy rule from the Policy Rules page
1. Navigate to Endpoints → Policy Management → Prevention → Policy Rules.
2. Right click an existing policy and select Edit.
3. Add your new profile to the policy rule.
Create a new policy rule from the Policy Rules page
1. Navigate to Endpoints → Policy Management → Prevention → Policy Rules.
2. Click Add Policy.
3. Configure a new policy that includes your new profile.
Android
1. Add a new profile and define basic settings.
a. From Cortex XDR, select Endpoints → Policy Management → Prevention → Profiles. Click +Add Profile, and select whether to create a new profile,
or to import a profile from a file.
New profiles based on imported profiles are added, and do not replace existing ones.
b. Select the Android platform, and Malware as the profile type.
c. Click Next.
d. For Profile Name, enter a unique name for 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.
e. For Profile Name, enter a unique name for 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.
2. Configure APK Files Examination, to analyze and prevent malicious APK files from running on endpoints.
Displayed in the footer
Page 140 of 952
Cortex XDR Documentation
Displayed in the header
Item Options More Details
Action Mode Block When the Cortex XDR agent detects attempts to run malicious APK files,
it performs the configured action.
Report
Disabled
Action on unknown APK Allow Allow: Unknown files are not blocked and local verdicts are not issued
files to WildFire for them.
Run Local Analysis
Run Local Analysis: The Cortex XDR agent uses embedded machine
Block learning to determine the likelihood that an unknown file is malware, and
issues a local verdict for the file.
Block: Block unknown files but do not run local analysis. In this case,
unknown files remain blocked until the Cortex XDR agent receives an
official WildFire verdict.
Upload APK files for cloud Enabled When enabled, the Cortex XDR agent sends unknown files to Cortex
analysis XDR, and Cortex XDR sends the files to WildFire for analysis.
Disabled
The file types that the Cortex XDR agent analyzes depend on the
platform type. WildFire accepts files up to 100 MB in size.
Treat Grayware as Enabled When enabled, Cortex XDR treats all grayware with the same Action
Malware Mode as configured for malware.
Disabled
When enabled, Cortex XDR treats all grayware with the same Action
Mode as configured for malware.
3. To save the profile, click Create.
What to do next
If you are ready to apply your new profile to endpoints, you do this by adding it to a policy rule. If you still need to define other profiles, you can do this later.
During policy rule creation or editing, you select the endpoints to which to assign the policy. There are different ways of doing this, such as:
Create a policy rule from the Prevention Profiles page
1. Navigate to Endpoints → Policy Management → Prevention → Profiles.
2. Right-click your new profile, and select Create a new policy rule using this profile.
3. Configure the policy rule.
Edit an existing policy rule from the Policy Rules page
1. Navigate to Endpoints → Policy Management → Prevention → Policy Rules.
2. Right click an existing policy and select Edit.
3. Add your new profile to the policy rule.
Create a new policy rule from the Policy Rules page
1. Navigate to Endpoints → Policy Management → Prevention → Policy Rules.
2. Click Add Policy.
3. Configure a new policy that includes your new profile.
iOS
1. Add a new profile and define basic settings.
a. Select Endpoints → Policy Management → Prevention → Profiles. Click +Add Profile, and select whether to create a new profile, or to import a
profile from a file.
New profiles based on imported profiles are added, and do not replace existing ones.
Displayed in the footer
Page 141 of 952
Cortex XDR Documentation
Displayed in the header
b. Select the iOS platform, and Malware as the profile type.
c. Click Next.
d. For Profile Name, enter a unique name for 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.
e. For Description, to provide additional context for the purpose or business reason for creating the profile, enter a profile description. For example,
you might include an incident identification number or a link to a help desk ticket.
2. Configure URL filtering to analyze and block or report malicious URLs, and to block or allow custom URLs.
Blocking functionality is different for each security module. For SMS/MMS, Cortex XDR agent will move detected messages containing such URLs from
unknown senders to the Junk folder.
Item Options More Details
Action Mode Block When the Cortex XDR agent detects malicious URLs, the Cortex XDR
agent performs the configured action.
Report
To add numbers to the Block List, click +Add and enter the URL. Press
Disabled Enter to add more URLs.
To add URLs to the Allow List, define a list on the Legacy Agent
Exceptions page.
3. Configure Spam Reports to report calls and messages as spam.
Item Options More Details
Spam Report Enabled Configure reporting of spam calls and messages to Cortex analysts.
Disabled
4. Configure Call and Messages Blocking for incoming calls and messages from known spam numbers.
Item Options More Details
Action Mode Block When the Cortex XDR agent detects incoming calls or messages from
known spam numbers, the Cortex XDR agent performs the configured
Report action.
Disabled
To add numbers to the Block List, click +Add and enter the phone
number. Press Enter to add more numbers.
To add numbers to the Allow List, define a list on the Legacy
Agent Exceptions page.
Ensure that the same numbers are not added multiple times with
different leading zeros.
5. 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 do not use the
Network Shield feature.
To fully enable the Safari browser 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, the endpoint's operation status is reported 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.
Displayed in the footer
Page 142 of 952
Cortex XDR Documentation
Displayed in the header
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. When this module is also activated on the device, alerts are
forwarded to the tenant.
When set to Disabled, and users decide to enable the module on their
devices, alerts are visible locally on the iOS device only, and are not
forwarded to the tenant.
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
6. 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 for this on the MDM side as explained in the Cortex XDR Agent iOS Guide.
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 known
URL filtering malicious URLs.
Disabled
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.
Displayed in the footer
Page 143 of 952
Cortex XDR Documentation
Displayed in the header
Item Options More Details
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 the
tenant.
Digest alerts max 1 to 7 days When Digest alerts is enabled, you can limit the digest alert to no more
frequency than one per <selected number of days>.
Max alerts per app Hours Limit alert notifications by the Cortex XDR agent app 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>.
7. To save the profile, click Create.
12.2.1.1.2 | Set up exploit prevention profiles
Abstract
Exploit prevention profiles control the action that the Cortex XDR agent takes when attempts to exploit software vulnerabilities or flaws occur.
Exploit prevention profiles block attempts to exploit system flaws in browsers, and in the operating system. For example, exploit prevention profiles help protect
against exploit kits, illegal code execution, and other attempts to exploit process and system vulnerabilities.
You can configure the action that 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 prevention profile. Default settings are shown in parentheses. To fine-tune your
exploitprevention policy, you can override the configuration of each capability to block the malicious exploit, allow but report it, or disable the module.
To view which processes are protected by each capability, see Processes Protected by Exploit Security Policy.
For each setting that you override, clear the corresponding option to Use Default, and select the setting of your choice.
In this profile, the Report options configure the endpoints to report the corresponding exploit attempts to Cortex XDR, without blocking them. The Disabled
options configure the endpoints to neither analyze nor report the corresponding malware or behavior.
The tasks below are organized according to the operating systems used by your organization's endpoints.
Windows
1. Add a new profile and define basic settings.
a. From Cortex XDR, select Endpoints → Policy Management → Prevention → Profiles. Click +Add Profile, and select whether to create a new profile,
or to import a profile from a file.
New profiles based on imported profiles are added, and do not replace existing ones.
b. Select the Windows platform, and Exploit as the profile type.
c. Click Next.
d. For Profile Name, enter a unique name for 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.
Displayed in the footer
Page 144 of 952
Cortex XDR Documentation
Displayed in the header
e. For Description, to provide additional context for the purpose or business reason for creating the profile, enter a profile description. For example,
you might include an incident identification number or a link to a help desk ticket.
2. Configure Browser Exploits Protection, to protect endpoints from malicious or compromised websites.
Item Options More Details
Action Mode Block When the Cortex XDR agent detects attempts to exploit browser
processes for malicious purposes, it performs the configured action.
Report
Disabled
3. Configure Logical Exploits Protection to prevent execution of malicious code using common operating system mechanisms.
Item Options More Details
Action Mode Block When the Cortex XDR agent detects attempts to execute malicious code
using operating system mechanisms, it performs the configured action.
Report
Disabled
Block List DLLs The block list blocks the specified DLLs when they are run by a
protected process, using the DLL Hijacking module.
1. Click +Add to configure entries in your Block List.
2. Enter the name of the process that you want to block.
3. Enter the associated DLL name.
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/).
4. Configure Known Vulnerable Processes Protection to automatically protect endpoints from attacks that try to leverage common operating system
mechanisms for malicious purposes.
Item Options More Details
Action Mode Block Attackers can use existing mechanisms in the operating system to
execute malicious code. When you set this option to Block, in order to
Report block such code, you can also configure Java Deserialization Protection.
Disabled
Java Deserialization Enabled When enabled, the same action mode defined for the Known Vulnerable
Protection Process Protection is inherited here.
Disabled
5. Configure Operating System Exploit Protection to prevent attackers from using operating system mechanisms for malicious purposes.
Displayed in the footer
Page 145 of 952
Cortex XDR Documentation
Displayed in the header
Item Options More Details
Action Mode Block When the Cortex XDR agent detects attempts to use the operating
system's own mechanisms to perform an attack, the Cortex XDR agent
Report
performs the configured action.
Disabled
6. Configure Exploit Protection for Additional Processes to protect third-party processes running on endpoints.
Item Options More Details
Action Mode Block The Cortex XDR agent can protect third-party processes from
exploitation. To protect these processes, define them in the Processes
Report list below this field. If you select the Block option, we recommend that
you perform testing and validation to ensure that there are no
Disabled
compatibility issues with the third-party processes that you have defined.
In exploit prevention 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
SO Hijacking
Processes If you want to add exploit protection for one or more additional third-
party processes, add them here.
1. Click +Add to configure entries in your Processes list.
2. Enter the file name of the process that you want to block, and
press ENTER.
3. For additional processes, repeat the previous steps.
7. Configure Unpatched Vulnerabilities Protection to provide a temporary workaround for protecting unpatched endpoints from known vulnerabilities.
This step provides a temporary workaround for the following publicly known information-security vulnerabilities and exposures: CVE-2021-24074, CVE-
2021-24086 and CVE-2021-24094.
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.
If you have Windows endpoints in your network that are unpatched and exposed to a known vulnerability, we strongly recommend that you upgrade to
the latest Windows Update that has a fix for that vulnerability.
Displayed in the footer
Page 146 of 952
Cortex XDR Documentation
Displayed in the header
Item Options More Details
Modify IPv4 and IPv6 Do not modify system settings To address known vulnerabilities CVE-2021-24074, CVE-2021-24086,
Settings and CVE-2021-24094, you can Modify IPv4 and IPv6 settings as follows:
Modify settings until the endpoint is
patched Do not modify system settings (default): Do not modify the IPv4
and IPv6 settings currently set on the endpoint, whether the
Revert system settings to your current values are your original values or values that were
previous settings 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.
This workaround applies only to the specific Windows versions listed as
exposed to these CVEs, and requires a Cortex XDR agent release 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.
8. To save the profile, click Create.
What to do next
If you are ready to apply your new profile to endpoints, you do this by adding it to a policy rule. If you still need to define other profiles, you can do this later.
During policy rule creation or editing, you select the endpoints to which to assign the policy. There are different ways of doing this, such as:
Create a policy rule from the Prevention Profiles page
1. Navigate to Endpoints → Policy Management → Prevention → Profiles.
2. Right-click your new profile, and select Create a new policy rule using this profile.
3. Configure the policy rule.
Edit an existing policy rule from the Policy Rules page
1. Navigate to Endpoints → Policy Management → Prevention → Policy Rules.
2. Right click an existing policy and select Edit.
3. Add your new profile to the policy rule.
Create a new policy rule from the Policy Rules page
1. Navigate to Endpoints → Policy Management → Prevention → Policy Rules.
2. Click Add Policy.
Displayed in the footer
Page 147 of 952
Cortex XDR Documentation
Displayed in the header
3. Configure a new policy that includes your new profile.
macOS
1. Add a new profile and define basic settings.
a. From Cortex XDR, select Endpoints → Policy Management → Prevention → Profiles. Click +Add Profile, and select whether to create a new profile,
or to import a profile from a file.
New profiles based on imported profiles are added, and do not replace existing ones.
b. Select the macOS platform, and Exploit as the profile type.
c. Click Next.
d. Enter a unique Profile Name for 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.
e. For Description, to provide additional context for the purpose or business reason for creating the profile, enter a profile description. For example,
you might include an incident identification number or a link to a help desk ticket.
2. Configure Browser Exploits Protection, to protect endpoints from malicious or compromised websites.
Item Options More Details
Action Mode Block When the Cortex XDR agent detects attempts to exploit browser
processes for malicious purposes, it performs the configured action.
Report
Disabled
3. Configure Logical Exploits Protection to prevent execution of malicious code using common operating system mechanisms.
Item Options More Details
Action Mode Block When the Cortex XDR agent detects attempts to execute malicious code
using operating system mechanisms, it performs the configured action.
Report
Disabled
4. Configure Known Vulnerable Processes Protection to automatically protect endpoints from attacks that try to leverage common operating system
mechanisms for malicious purposes.
Item Options More Details
Action Mode Block Attackers can use existing mechanisms in the operating system to
execute malicious code. When you set this option to Block, in order to
Report block such code, you can also configure Java Deserialization Protection.
Disabled
5. Configure Operating System Exploit Protection to prevent attackers from using operating system mechanisms for malicious purposes.
Item Options More Details
Action Mode Block When the Cortex XDR agent detects attempts to use the operating
system's own mechanisms to perform an attack, the Cortex XDR agent
Report performs the configured action.
Disabled
Displayed in the footer
Page 148 of 952
Cortex XDR Documentation
Displayed in the header
6. Configure Exploit Protection for Additional Processes to protect third-party processes running on endpoints.
Item Options More Details
Action Mode Block The Cortex XDR agent can protect third-party processes from
exploitation. To protect these processes, define them in the Processes
Report
list below this field. If you select the Block option, we recommend that
Disabled you perform testing and validation to ensure that there are no
compatibility issues with the third-party processes that you have defined.
In exploit prevention 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
SO Hijacking
Processes If you want to add exploit protection for one or more additional third-
party processes, add them here.
1. Click +Add to configure entries in your Processes list.
2. Enter the file name of the process that you want to block, and
press ENTER.
3. For additional processes, repeat the previous steps.
7. To save the profile, click Create.
What to do next
If you are ready to apply your new profile to endpoints, you do this by adding it to a policy rule. If you still need to define other profiles, you can do this later.
During policy rule creation or editing, you select the endpoints to which to assign the policy. There are different ways of doing this, such as:
Create a policy rule from the Prevention Profiles page
1. Navigate to Endpoints → Policy Management → Prevention → Profiles.
2. Right-click your new profile, and select Create a new policy rule using this profile.
3. Configure the policy rule.
Edit an existing policy rule from the Policy Rules page
1. Navigate to Endpoints → Policy Management → Prevention → Policy Rules.
2. Right click an existing policy and select Edit.
3. Add your new profile to the policy rule.
Create a new policy rule from the Policy Rules page
1. Navigate to Endpoints → Policy Management → Prevention → Policy Rules.
2. Click Add Policy.
3. Configure a new policy that includes your new profile.
Linux
1. Add a new profile and define basic settings.
a. From Cortex XDR, select Endpoints → Policy Management → Prevention → Profiles. Click +Add Profile, and select whether to create a new profile,
or to import a profile from a file.
New profiles based on imported profiles are added, and do not replace existing ones.
b. Select the Linux platform, and Exploit as the profile type.
Displayed in the footer
Page 149 of 952
Cortex XDR Documentation
Displayed in the header
c. Click Next.
d. Enter a unique Profile Name for 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.
e. For Description, to provide additional context for the purpose or business reason for creating the profile, enter a profile description. For example,
you might include an incident identification number or a link to a help desk ticket.
2. Configure Known Vulnerable Processes Protection to automatically protect endpoints from attacks that try to leverage common operating system
mechanisms for malicious purposes.
Item Options More Details
Action Mode Block Attackers can use existing mechanisms in the operating system to
execute malicious code. When you set this option to Block, in order to
Report block such code, you can also configure Java Deserialization Protection.
Disabled
3. Configure Operating System Exploit Protection to prevent attackers from using operating system mechanisms for malicious purposes.
Item Options More Details
Action Mode Block When the Cortex XDR agent detects attempts to use the operating
system's own mechanisms to perform an attack, the Cortex XDR agent
Report performs the configured action.
Disabled
4. Configure Exploit Protection for Additional Processes to protect third-party processes running on endpoints.
Item Options More Details
Action Mode Block The Cortex XDR agent can protect third-party processes from
exploitation. To protect these processes, define them in the Processes
Report list below this field. If you select the Block option, we recommend that
you perform testing and validation to ensure that there are no
Disabled
compatibility issues with the third-party processes that you have defined.
In exploit prevention 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
SO Hijacking
Processes If you want to add exploit protection for one or more additional third-
party processes, add them here.
1. Click +Add to configure entries in your Processes list.
2. Enter the file name of the process that you want to block, and
press ENTER.
3. For additional processes, repeat the previous steps.
5. To save the profile, click Create.
What to do next
Displayed in the footer
Page 150 of 952
Cortex XDR Documentation
Displayed in the header
If you are ready to apply your new profile to endpoints, you do this by adding it to a policy rule. If you still need to define other profiles, you can do this later.
During policy rule creation or editing, you select the endpoints to which to assign the policy. There are different ways of doing this, such as:
Create a policy rule from the Prevention Profiles page
1. Navigate to Endpoints → Policy Management → Prevention → Profiles.
2. Right-click your new profile, and select Create a new policy rule using this profile.
3. Configure the policy rule.
Edit an existing policy rule from the Policy Rules page
1. Navigate to Endpoints → Policy Management → Prevention → Policy Rules.
2. Right click an existing policy and select Edit.
3. Add your new profile to the policy rule.
Create a new policy rule from the Policy Rules page
1. Navigate to Endpoints → Policy Management → Prevention → Policy Rules.
2. Click Add Policy.
3. Configure a new policy that includes your new profile.
12.2.1.1.3 | Set up agent settings profiles
Abstract
Use agent settings profiles to customize Cortex XDR agent settings for different platforms and groups of users.
Use agent settings profiles to customize Cortex XDR agent settings for different platforms and groups of users.
The tasks below are organized according to the operating systems used by your organization's endpoints.
Windows
1. Add a new profile and define basic settings.
a. Select Endpoints → Policy Management → Prevention → Profiles. Click +Add Profile, and select whether to create a new profile or import a profile
from a file.
New profiles based on imported profiles are added, and do not replace existing ones.
b. Select the Windows platform, and Agent Settings as the profile type.
c. Click Next.
d. For Profile Name, enter a unique name for 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.
e. For Description, to provide additional context for the purpose or business reason for creating the profile, enter a profile description. For example,
you might include an incident identification number or a link to a help desk ticket.
2. For Disk Quota, configure the amount of disk space to allot for Cortex XDR agent logs. Specify a value in MB from 100 to 10,000 (default is 5,000).
3. Configure the User Interface options for Cortex XDR.
By default, Cortex XDR uses the settings specified in the default agent settings profile and displays the default configuration in parentheses. When you
select a setting other than the default, you override the default configuration for the profile.
Item Options More Details
Tray Icon Visible (default) Choose whether you want the Cortex XDR agent icon to be Visible or
Hidden in the notification area (system tray).
Hidden
XDR Agent Console Enabled When enabled, allows access to Cortex XDR.
Access
Disabled
Displayed in the footer
Page 151 of 952
Cortex XDR Documentation
Displayed in the header
Item Options More Details
XDR Agent User Enabled Enable this option to operate display notifications in the notifications area
Notifications on the endpoint. When you enable notifications, you can use the default
Disabled
notification messages that are displayed for each option, or provide
custom text for each notification type. You can also customize a
notification footer. Options include:
Live Terminal User Notifications: 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.
Live Terminal Active Session Indication: Enable this option to
display a blinking light ( ) on the tray icon for the duration of the
remote session to indicate to the end user that a Live Terminal
session is in progress.
Persistent Isolation Notification
Endpoint Network Isolation Notification
Endpoint Network Un-Isolation Notification
Blocked Connectivity Notification
Exploit/Malware Events Set to Block
Restriction Events Set to Block
Restriction Events Set to Notify User
Notification Footer Text
USB Device Was Blocked
USB Disk Drive Was Allowed in Read-Only Mode
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.
4. Customize Agent Security settings. By default, the Cortex XDR agent protects all agent components. However, you can configure protection with more
granularity for Cortex XDR agent services, processes, files, registry values and tampering protection.
In 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.
a. Enable XDR Agent Tampering Protection.
If you choose the Enable option, you must also enable XDR Agent Tampering Protection in the malware profile and set it to Block. Ensure that both
profiles are assigned to the same endpoints.
b. You can customize the following options:
Item Options More Details
Service Protection Enabled Protects against stopping agent services. When this protection is
enabled, agent services won't accept operating system stop requests.
Disabled
Process Protection Enabled Protects against attempts to tamper with agent processes; injecting into
them, terminating them, reading, or writing into their virtual memory.
Disabled
Displayed in the footer
Page 152 of 952
Cortex XDR Documentation
Displayed in the header
Item Options More Details
File Protection Enabled Protects against attempts to tamper with agent files; deleting, replacing,
renaming, moving, or writing files/directories.
Disabled
Registry Protection Enabled Protects against attempts to tamper with agent registry settings and
agent policies, such as deleting, adding, and renaming registry keys or
Disabled
values which belong to the agent.
Pipe Protection Enabled Protects against attempts to tamper with the agent's pipe-based inter-
process communication (IPC) mechanism.
Disabled
5. For Uninstall Password, configure an uninstall password.
Define and confirm an encrypted password that the user must specify to uninstall the Cortex XDR agent. The uninstall password, also known as the
supervisor password, is also used to protect against tampering attempts using Cytool commands. The password must contain:
8 to 32 characters
At least one of each of the following:
Lower-case letter
Upper-case letter
Number
Special character: !@#%
6. 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.
When you enable Cortex XDR agent registration with the Windows Security Center, Windows automatically shuts down Microsoft Defender on Windows-
based workstation endpoints. If you still want to allow Microsoft Defender to run on a workstation endpoint where Cortex XDR is installed, you must use
the Disable option. However, Palo Alto Networks does not recommend running Windows Defender and the Cortex XDR agent on the same endpoint,
because this might cause performance and incompatibility issues with Global Protect and other applications.
On Windows-based servers, ensure that Windows Defender is disabled. This can be done using a Group Policy Object (GPO) or another group
management tool of your choice.
Displayed in the footer
Page 153 of 952
Cortex XDR Documentation
Displayed in the header
Item Options More Details
Windows Security Enabled The Cortex XDR agent registers with the Windows Security Center as an
Integration official Antivirus (AV) software product. As a result, Windows
automatically shuts down Microsoft Defender on the endpoint, 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 Windows Server-based
endpoints where the Cortex XDR agent is installed.
Enabled No Patches (Traps 5.0 release only) Select this option if you want to register the
agent with the Windows Security Center, but prevent Windows from
automatically installing Meltdown/Spectra vulnerability patches on the
endpoint.
Disabled The Cortex XDR agent does not register with the Windows Action Center.
As a result, Windows Action Center might indicate that virus protection is
off, depending on other security products that are installed on the
endpoint.
7. Configure Alerts Data collection options.
When the Cortex XDR agent raises alerts on process-related activity on the endpoint, the agent collects the contents of memory and other data about the
event, in what is known as an alert data dump file. You can configure the Cortex XDR agent to automatically upload alert data dump files to Cortex XDR.
Item Options More Details
Alert Data Dump File Size Small The Full option creates the largest and most complete set of information.
Medium
Full
Automatically Upload Alert Enabled During event investigation, if automatic upload was disabled, you can
Data Dump File still manually retrieve this data.
Disabled
8. Enable XDR Pro Endpoint Capabilities, and then configure the capabilities required by your organization. The Cortex XDR Pro features are hidden until
you enable this option.
Requires a Cortex XDR Pro per Endpoint license. When you enable this feature, a Cortex XDR Pro per Endpoint license is consumed.
Item Options More Details
Monitor and Collect Enabled (Not supported in Traps 5.0.x)
Enhanced Endpoint Data
Disabled 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. When you enable the Cortex XDR agent to monitor and collect
enhanced endpoint data, Cortex XDR shares 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.
Displayed in the footer
Page 154 of 952
Cortex XDR Documentation
Displayed in the header
Item Options More Details
Enable Host Insights Enabled Requires Host Insights add-on.
Capabilities
Disabled This is not supported in Traps 5.0.x.
When enabled, the various host insight capabilities can be configured.
Endpoint Information Enabled When enabled, the Cortex XDR agent collects host inventory information
Collection such as users, groups, services, drivers, hardware, and network shares,
Disabled as well as information about applications installed on the endpoint,
including CVE and installed KBs for Vulnerability Assessment.
File Search and Destroy Enabled (Not supported in Traps 5.0.x)
Action Mode
Disabled 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 XDR monitors all the files on the
endpoint, or only common file types. If you choose Common file types,
Cortex XDR monitors the following file types:
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.
Additionally, you can exclude files that exist under a specific local path
on the endpoint from inclusion in the files database.
Monitor and Collect Enabled Requires Forensics Add-on.
Forensics Data
Disabled This is not supported in Traps 5.0.x.
When enabled, the Cortex XDR agent collects detailed information about
what happened on your endpoint, to create a forensics database. Define
the following to enable collection and collection time intervals for the
following entity types:
Process Execution
File Access
Persistence
Command History
Network
Remote Access
Search Collections
Data collected by the agent is displayed on the tenant's Forensics page.
Displayed in the footer
Page 155 of 952
Cortex XDR Documentation
Displayed in the header
Item Options More Details
Distributed Network Scan Enabled (Not supported in Traps 5.0.x)
Disabled When enabled, the Cortex XDR agent scans your network using Ping or
Nmap to provide updated identifiers of your unmanaged network assets.
To enable access to these options, scroll Ping scans return the IP address, MAC address, Hostname, and
down to Network Location Configuration, Platform, whereas Nmap will scan the most common ports for the IP
and set Action Mode to Enabled. address, Hostname, Platform, and OS version.
Ping is a lighter scan, that generates icmp requests to peers and does
not use external tools. Nmap will make more noise on the network, but
the resulting can be better, and also supports operating system
detection.
Ping scans are performed in 30 minute intervals. Nmap scans are
performed in 60 minute intervals.
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 affect 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.
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. If you want to exclude IP address ranges, select Excluded IP
Address Ranges. The IP address ranges are populated from your
network configurations.
5. If you selected Nmap, enable or disable OS Fingerprinting of the
IP address.
Depending on the type of scan you defined, the agent Ping scan takes
30 minutes, and Nmap takes 60 minutes. Following each scan, Cortex
XDR aggregates the IP addresses that were collected, and displays the
results in the Asset Management table.
9. Configure XDR Cloud for hosts running on cloud platforms. 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.
Displayed in the footer
Page 156 of 952
Cortex XDR Documentation
Displayed in the header
Item Options More Details
XDR Cloud Auto-detect If you set this to Enabled in the profile, any agent using this profile will be
treated as if it is a cloud-based agent for licensing purposes.
Enabled
This feature requires a Cortex XDR Cloud per Host license. This license is required for both cloud-based and on-prem use of K8 nodes.
10. Configure Response Actions for specific applications or processes, using an Allow list.
If you need to isolate an endpoint, but want to allow access for a specific application or process, add it to the Network Isolation Allow List. Keep the
following considerations in mind:
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.
For VDI sessions, use of the network isolation response action can disrupt communication with the VDI host management system, thereby stopping
access to the VDI session. Therefore, before using the response action, you must add the VDI processes and corresponding IP addresses to your
allow list.
a. Click Add to add an entry to the allow list.
b. Specify the Process Path that 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.
c. Click the check mark.
11. Configure Backup Management to backup endpoint data.
Item Options More Details
Shadowcopy Activation Enabled When enabled, the Cortex XDR agent automatically turns on the system
protection of the endpoint. This ensures that the data is backed up and
Disabled may be recovered in cases of any security breaches or loss of data.
Disk Space Limitation Disk space in MB Limits the amount of disk space in MB that can be used for endpoint
data backup.
12. Configure the method used to update content on your endpoints.
(Not supported in Traps 5.0.x)
If you disable or delay automatic-content updates provided by Palo Alto Networks, it may affect the security level in your organization.
If you disable content updates for a newly installed agent, the agent retrieves the content for the first time from Cortex XDR, 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.
Item Options More Details
Content Auto-update Enabled (default) By default, the Cortex XDR agent always retrieves the most updated
content and deploys it on the endpoint, to ensure that it is always
Disabled (default)
protected with the latest security measures.
If you disable content updates, the agent stops retrieving them from the
Cortex XDR tenant, and keeps working with the current content on the
endpoint.
Displayed in the footer
Page 157 of 952
Cortex XDR Documentation
Displayed in the header
Item Options More Details
Content Staging Enabled Enable users to deploy agent staging content on selected test
environments. Staging content is released before production content,
Disabled (default)
allowing for early evaluation of the latest content update.
Content Rollout Immediately The Cortex XDR agent can retrieve content updates immediately as they
are available, or after a pre-configured delay period. When you delay
Delayed 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.
13. Agent Auto-Upgrade is disabled by default. Before enabling Auto-Update for Cortex XDR agents, make sure to consult with all relevant stakeholders in
your organization.
Automatic upgrades are not supported with non-persistent VDI and temporary sessions.
Item Options More Details
Agent Auto-Upgrade Enabled
Disabled (Default)
Automatic Upgrade Scope Latest agent release For One release before the latest one, Cortex XDR upgrades the agent
to the previous release before the latest, including maintenance
One release before the latest one releases. Major releases are numbered X.X, such as release 8.0, or 8.2.
Only maintenance releases Maintenance releases are numbered X.X.X, such as release 8.2.2.
Only maintenance releases in a For Only maintenance releases in a specific version, select the required
specific version release version.
Upgrade Rollout Immediate For Delayed, set the delay period (number of days) to wait after the
version release before upgrading endpoints. Choose a value between 7
Delayed and 45.
To control the agent auto upgrade scheduler and number of parallel
upgrades in your network, configure Global Agent Settings.
14. Specify a Download Source, or multiple sources, from which Cortex XDR agent retrieves agent and content updates. The options provided help you to
reduce external network bandwidth loads during updates. When all sources are selected, the download sources are prioritized in the following order:
P2P > Broker VM > Cortex XDR 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 XDR server on their following heartbeat.
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, the new content update will start within one minute in P2P, and within five minutes from Cortex XDR.
Displayed in the footer
Page 158 of 952
Cortex XDR Documentation
Displayed in the header
Item Options More Details
Select all Selected When selected, all download source options are enabled.
Clear
P2P 33221 (default port) Cortex XDR deploys serverless peer-to-peer distribution to Cortex XDR
agents in your LAN network by default. Within the six hour randomization
custom port
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 port specified
for P2P Port. By default, Cortex XDR uses port 33221. You can change
the port number, if required by your organization.
Broker VM Select all (Requires Broker VM 12.0 and later)
Brokers If you have a Palo Alto Networks Broker VM in your network, you can
leverage the Local Agent Settings applet to cache release upgrades
Clusters and content updates. When the Broker VM is enabled and configured
appropriately (refer to Activate the Local Agent Settings) , it retrieves the
(only Broker VMs that are connected and
latest installers and content every 15 minutes. The Broker VM stores
configured for caching can be selected)
them for a 30-day retention period since an agent last asked for them.
If the files are not available on the Broker VM at the time of the request,
the agent proceeds to download the files directly from the Cortex XDR
server.
When you select multiple Broker VMs, the agent chooses a Broker VM
randomly for each download request.
15. Configure Network Location Configuration for your Cortex XDR agents. If you configure host firewall rules in your network, you must:
Enable Network Location Configuration Action Mode, so that Cortex XDR can test the network location of your device.
Configure your network's DNS name and its internal IP address.
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.
Item Options More Details
Action Mode Enabled When Enabled, a domain controller (DC) test checks whether the device
is connected to the internal network or not. If the device is connected to
Disabled the internal network, it is determined to be in the organization. If the DC
test fails or returns an external domain, Cortex XDR performs a DNS
connectivity test.
DNS Name Your network's DNS name The Cortex XDR agent tests network location by submitting a Domain
Name Server (DNS) name that is known only to the internal network. If
the DNS returns the pre-configured internal IP address, the device is
determined to be within the organization. If the DNS IP address cannot
be resolved, the device is deemed to be located elsewhere.
IP Address Your network's DNS internal IP address Enter the internal DNS IP address to be used by the DNS test.
16. Define Agent Proxy Settings.
Displayed in the footer
Page 159 of 952
Cortex XDR Documentation
Displayed in the header
Select whether to Enable or Disable Direct Server Access for the agent when connected using a proxy.
17. Configure Agent Certificates. For improved security, enforce the use of root CA that is provided by Palo Alto Networks rather than on the local machine.
Item Options More Details
Certificate Enforcement Enabled When enabled, certificate enforcement is enabled.
Disabled If the Cortex XDR agent is initially unable to communicate without the
local store, enforcement is not enabled and the agent will show as
Disabled (Notify)
partially protected.
When set to Disabled (Notify), Cortex XDR agents with this policy will
trigger a banner in the server to notify customers about potential risk,
and will 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.
When set to Disabled, Cortex XDR agents with this policy will trigger a
banner in the server to notify customers about potential risk, and will
direct them to change the certificate and the setting. The Last Certificate
Enforcement Fallback column of the All Endpoints table is not updated,
and no management audit logs related to the local store fallback are
received by the server.
18. To save the profile, click Create.
What to do next
If you are ready to apply your new profile to endpoints, you do this by adding it to a policy rule. If you still need to define other profiles, you can do this later.
During policy rule creation or editing, you select the endpoints to which to assign the policy. There are different ways of doing this, such as:
Create a policy rule from the Prevention Profiles page
1. Navigate to Endpoints → Policy Management → Prevention → Profiles.
2. Right-click your new profile, and select Create a new policy rule using this profile.
3. Configure the policy rule.
Edit an existing policy rule from the Policy Rules page
1. Navigate to Endpoints → Policy Management → Prevention → Policy Rules.
2. Right click an existing policy and select Edit.
3. Add your new profile to the policy rule.
Create a new policy rule from the Policy Rules page
1. Navigate to Endpoints → Policy Management → Prevention → Policy Rules.
2. Click Add Policy.
3. Configure a new policy that includes your new profile.
macOS
1. Add a new profile and define basic settings.
a. Select Endpoints → Policy Management → Prevention → Profiles. Click +Add Profile, and select whether to create a new profile or import a profile
from a file.
New profiles based on imported profiles are added, and do not replace existing ones.
b. Select the macOS platform, and Agent Settings as the profile type.
c. Click Next.
d. Enter a unique Profile Name for 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.
Displayed in the footer
Page 160 of 952
Cortex XDR Documentation
Displayed in the header
e. For Description, to provide additional context for the purpose or business reason for creating the profile, enter a profile description. For example,
you might include an incident identification number or a link to a help desk ticket.
2. For Disk Quota, configure the amount of disk space to allot for Cortex XDR agent logs. Specify a value in MB from 100 to 10,000 (default is 5,000).
3. Configure the User Interface options for Cortex XDR.
By default, Cortex XDR uses the settings specified in the default agent settings profile and displays the default configuration in parentheses. When you
select a setting other than the default, you override the default configuration for the profile.
Item Options More Details
Tray Icon Visible (default) Choose whether you want the Cortex XDR agent icon to be Visible or
Hidden in the notification area (system tray).
Hidden
XDR Agent Console Enabled When enabled, allows access to Cortex XDR.
Access
Disabled
XDR Agent User Enabled Enable this option to operate display notifications in the notifications area
Notifications on the endpoint. When you enable notifications, you can use the default
Disabled
notification messages that are displayed for each option, or provide
custom text for each notification type. You can also customize a
notification footer. Options include:
Live Terminal User Notifications: 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.
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.
Live Terminal Active Session Indication: Enable this option to
display a blinking light ( ) on the status bar for the duration of the
remote session to indicate to the end user that a Live Terminal
session is in progress.
Persistent Isolation Notification
Endpoint Network Isolation Notification
Endpoint Network Un-Isolation Notification
Blocked Connectivity Notification
Exploit/Malware Events Set to Block
Restriction Events Set to Block
Restriction Events Set to Notify User
Notification Footer Text
USB Device Was Blocked
USB Disk Drive Was Allowed in Read-Only Mode
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.
4. For Agent Security, configure XDR Agent Tampering Protection (default is Enabled). By default, the Cortex XDR agent protects all agent components.
Displayed in the footer
Page 161 of 952
Cortex XDR Documentation
Displayed in the header
If you choose the Enabled option, you must also set Anti Tampering Protection in the malware security profile to Block, and ensure that both profiles are
assigned to the same endpoints.
In 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.
5. For Uninstall Password, configure an uninstall password.
Define and confirm an encrypted password that the user must specify to uninstall the Cortex XDR agent. The uninstall password, also known as the
supervisor password, is also used to protect against tampering attempts via Cytool commands. The password must contain:
8 to 32 characters
At least one of each of the following:
Lower-case letter
Upper-case letter
Number
Special character: !@#%
6. Configure Alerts Data collection options.
When the Cortex XDR agent raises alerts on process-related activity on the endpoint, the agent collects the contents of memory and other data about the
event, in what is known as an alert data dump file. You can configure the Cortex XDR agent to automatically upload alert data dump files to Cortex XDR.
Item Options More Details
Alert Data Dump File Size Small The Full option creates the largest and most complete set of information.
Medium
Full
Automatically Upload Alert Enabled During event investigation, if automatic upload was disabled, you can
Data Dump File still manually retrieve this data.
Disabled
7. Requires a Cortex XDR Pro per Endpoint license. When you enable this feature, a Cortex XDR Pro per Endpoint license is consumed.
Enable XDR Pro Endpoint Capabilities, and then configure the capabilities required by your organization. The Cortex XDR Pro features are hidden until
you enable this option.
Item Options More Details
Monitor and Collect Enabled (Not supported in Traps 5.0.x)
Enhanced Endpoint Data
Disabled 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. When you enable the Cortex XDR agent to monitor and collect
enhanced endpoint data, Cortex XDR shares 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.
Displayed in the footer
Page 162 of 952
Cortex XDR Documentation
Displayed in the header
Item Options More Details
Enable Host Insights Enabled Requires Host Insights add-on.
Capabilities
Disabled This option is not supported in Traps 5.0.x.
When enabled, the various host insight capabilities can be configured.
Endpoint Information Enabled When enabled, the Cortex XDR agent collects Host Inventory
Collection information such as users, groups, services, drivers, hardware, and
Disabled network shares, as well as information about applications installed on
the endpoint, including CVE and installed KBs for Vulnerability
Assessment.
File Search and Destroy Enabled (Not supported in Traps 5.0.x)
Action Mode
Disabled 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 XDR monitors all the files on the
endpoint, or only common file types. If you choose Common file types,
Cortex XDR monitors the following file types:
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.
Monitor and Collect Enabled Requires Forensics Add-on.
Forensics Data
Disabled This is not supported in Traps 5.0.x.
When enabled, the Cortex XDR agent collects detailed information about
what happened on your endpoint, to create a forensics database. Define
the following to enable collection and collection time intervals for the
following entity types:
Process Execution
File Access
Persistence
Command History
Network
Search Collections
Data collected by the agent is displayed on the tenant's Forensics page.
8. Configure XDR Cloud for hosts running on cloud platforms. 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.
Displayed in the footer
Page 163 of 952
Cortex XDR Documentation
Displayed in the header
Item Options More Details
XDR Cloud Auto-detect If you set this to Enabled in the profile, any agent using this profile will be
treated as if it is a cloud-based agent for licensing purposes.
Enabled
This feature requires a Cortex XDR Cloud per Host license. This license is required for both cloud-based and on-prem use of K8 nodes.
9. Configure Response Actions for specific applications or processes, using an Allow list.
If you need to isolate an endpoint, but want to allow access for a specific application or process, add it to the Network Isolation Allow List. Keep the
following considerations in mind:
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.
a. Click Add to add an entry to the allow list.
b. Specify the Process Path that 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.
c. Click the check mark.
10. Configure Backup Management.
Item Options More Details
Time Machine Activation Enabled When enabled, this option automatically turns on the Time Machine
setting of the endpoint. This ensures that the data is backed up and may
Disabled be recovered in cases of any security breaches or loss of data.
11. Configure the method used to update content on your endpoints.
(Not supported in Traps 5.0.x)
If you disable or delay automatic-content updates provided by Palo Alto Networks, it may affect the security level in your organization.
If you disable content updates for a newly installed agent, the agent retrieves the content for the first time from Cortex XDR, 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.
Item Options More Details
Content Auto-update Enabled (default) By default, the Cortex XDR agent always retrieves the most updated
content and deploys it on the endpoint, to ensure that it is always
Disabled (default)
protected with the latest security measures.
If you disable content updates, the agent stops retrieving them from the
Cortex XDR tenant, and keeps working with the current content on the
endpoint.
Staging Content Enabled Enable users to deploy agent staging content on selected test
environments. Staging content is released before production content,
Disabled (default)
allowing for early evaluation of the latest content update.
Displayed in the footer
Page 164 of 952
Cortex XDR Documentation
Displayed in the header
Item Options More Details
Content Rollout Immediately The Cortex XDR agent can retrieve content updates immediately as they
are available, or after a pre-configured delay period. When you delay
Delayed
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.
12. Agent Auto-Upgrade is disabled by default. Before enabling Auto-Update for Cortex XDR agents, make sure to consult with all relevant stakeholders in
your organization.
Automatic upgrades are not supported with non-persistent VDI and temporary sessions.
Item Options More Details
Agent Auto-Upgrade Enabled
Disabled (Default)
Automatic Upgrade Scope Latest agent release For One release before the latest one, Cortex XDR upgrades the agent
to the previous release before the latest, including maintenance
One release before the latest one
releases. Major releases are numbered X.X, such as release 8.0, or 8.2.
Only maintenance releases Maintenance releases are numbered X.X.X, such as release 8.2.2.
For Only maintenance releases in a specific version, select the required
Only maintenance releases in a
release version.
specific version
Upgrade Rollout Immediate For Delayed, set the delay period (number of days) to wait after the
version release before upgrading endpoints. Choose a value between 7
Delayed and 45.
To control the agent auto upgrade scheduler and number of parallel
upgrades in your network, configure Global Agent Settings.
13. Specify a Download Source, or multiple sources, from which Cortex XDR agent retrieves agent and content updates. The options provided help you to
reduce external network bandwidth loads during updates. When all sources are selected, the download sources are prioritized in the following order:
P2P > Broker VM > Cortex XDR 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 XDR server on their following heartbeat.
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, the new content update will start within one minute in P2P, and within five minutes from Cortex XDR.
Item Options More Details
Select all Selected When selected, all download source options are enabled.
Clear
Displayed in the footer
Page 165 of 952
Cortex XDR Documentation
Displayed in the header
Item Options More Details
P2P 33221 (default port) Cortex XDR deploys serverless peer-to-peer distribution to Cortex XDR
agents in your LAN network by default. Within the six hour randomization
custom port
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 port specified
for P2P Port. By default, Cortex XDR uses port 33221. You can change
the port number, if required by your organization.
Broker VM Select all (Requires Broker VM 12.0 and later)
Brokers If you have a Palo Alto Networks Broker VM in your network, you can
leverage the Local Agent Settings applet to cache release upgrades
Clusters and content updates. When the Broker VM is enabled and configured
appropriately (refer to Activate the Local Agent Settings) , it retrieves the
(only Broker VMs that are connected and
latest installers and content every 15 minutes. The Broker VM stores
configured for caching can be selected)
them for a 30-day retention period since an agent last asked for them.
If the files are not available on the Broker VM at the time of the request,
the agent proceeds to download the files directly from the Cortex XDR
server.
When you select multiple Broker VMs, the agent chooses a Broker VM
randomly for each download request.
14. Configure Network Location Configuration for your Cortex XDR agents. If you configure host firewall rules in your network, you must:
Enable Network Location Configuration Action Mode, so that Cortex XDR can test the network location of your device.
Configure your network's DNS name and its internal IP address.
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.
Item Options More Details
Action Mode Enabled When Enabled, a domain controller (DC) test checks whether the device
is connected to the internal network or not. If the device is connected to
Disabled the internal network, it is determined to be in the organization. If the DC
test fails or returns an external domain, Cortex XDR performs a DNS
connectivity test.
DNS Name Your network's DNS name The Cortex XDR agent tests network location by submitting a Domain
Name Server (DNS) name that is known only to the internal network. If
the DNS returns the pre-configured internal IP address, the device is
determined to be within the organization. If the DNS IP address cannot
be resolved, the device is deemed to be located elsewhere.
IP Address Your network's DNS internal IP address Enter the internal DNS IP address to be used by the DNS test.
15. Define Agent Proxy Settings.
Select whether to Enable or Disable Direct Server Access for the agent when connected using a proxy.
16. Configure Agent Certificates. For improved security, enforce the use of root CA that is provided by Palo Alto Networks rather than on the local machine.
Displayed in the footer
Page 166 of 952
Cortex XDR Documentation
Displayed in the header
Item Options More Details
Certificate Enforcement Enabled When enabled, certificate enforcement is enabled.
Disabled If the Cortex XDR agent is initially unable to communicate without the
local store, enforcement is not enabled and the agent will show as
Disabled (Notify) partially protected.
When set to Disabled (Notify), Cortex XDR agents with this policy will
trigger a banner in the server to notify customers about potential risk,
and will 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.
When set to Disabled, Cortex XDR agents with this policy will trigger a
banner in the server to notify customers about potential risk, and will
direct them to change the certificate and the setting. The Last Certificate
Enforcement Fallback column of the All Endpoints table is not updated,
and no management audit logs related to the local store fallback are
received by the server.
17. To save the profile, click Create.
What to do next
If you are ready to apply your new profile to endpoints, you do this by adding it to a policy rule. If you still need to define other profiles, you can do this later.
During policy rule creation or editing, you select the endpoints to which to assign the policy. There are different ways of doing this, such as:
Create a policy rule from the Prevention Profiles page
1. Navigate to Endpoints → Policy Management → Prevention → Profiles.
2. Right-click your new profile, and select Create a new policy rule using this profile.
3. Configure the policy rule.
Edit an existing policy rule from the Policy Rules page
1. Navigate to Endpoints → Policy Management → Prevention → Policy Rules.
2. Right click an existing policy and select Edit.
3. Add your new profile to the policy rule.
Create a new policy rule from the Policy Rules page
1. Navigate to Endpoints → Policy Management → Prevention → Policy Rules.
2. Click Add Policy.
3. Configure a new policy that includes your new profile.
Linux
1. Add a new profile and define basic settings.
a. Select Endpoints → Policy Management → Prevention → Profiles. Click +Add Profile, and select whether to create a new profile or import a profile
from a file.
New profiles based on imported profiles are added, and do not replace existing ones.
b. Select the Linux platform, and Agent Settings as the profile type.
c. Click Next.
d. Enter a unique Profile Name for 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.
e. For Description, to provide additional context for the purpose or business reason for creating the profile, enter a profile description. For example,
you might include an incident identification number or a link to a help desk ticket.
2. For Disk Quota, configure the amount of disk space to allot for Cortex XDR agent logs. Specify a value in MB from 100 to 10,000 (default is 5,000).
3. Configure Alerts Data collection options.
Displayed in the footer
Page 167 of 952
Cortex XDR Documentation
Displayed in the header
When the Cortex XDR agent raises alerts on process-related activity on the endpoint, the agent collects the contents of memory and other data about the
event, in what is known as an alert data dump file. You can configure the Cortex XDR agent to automatically upload alert data dump files to Cortex XDR.
Item Options More Details
Alert Data Dump File Size Small The Full option creates the largest and most complete set of information.
Medium
Full
Automatically Upload Alert Enabled During event investigation, if automatic upload was disabled, you can
Data Dump File still manually retrieve this data.
Disabled
4. Requires a Cortex XDR Pro per Endpoint license. When you enable this feature, a Cortex XDR Pro per Endpoint license is consumed.
Enable XDR Pro Endpoint Capabilities, and then configure the capabilities required by your organization. The Cortex XDR Pro features are hidden until
you enable this option.
Item Options More Details
Monitor and Collect Enabled (Not supported in Traps 5.0.x)
Enhanced Endpoint Data
Disabled 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. When you enable the Cortex XDR agent to monitor and collect
enhanced endpoint data, Cortex XDR shares 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.
Enable Host Insights Enabled Requires Host Insights add-on; not supported in Traps 5.0.x
Capabilities
Disabled When enabled, the various host insight capabilities can be configured.
Endpoint Information Enabled When enabled, the Cortex XDR agent collects Host Inventory
Collection information such as users, groups, services, drivers, hardware, and
Disabled network shares, as well as information about applications installed on
the endpoint, including CVE and installed KBs for Vulnerability
Assessment.
Enable Compliance Enabled
Collection
Disabled
5. Configure XDR Cloud for hosts running on cloud platforms. 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.
Displayed in the footer
Page 168 of 952
Cortex XDR Documentation
Displayed in the header
Item Options More Details
XDR Cloud Auto-detect If you set this to Enabled in the profile, any agent using this profile will be
treated as if it is a cloud-based agent for licensing purposes.
Enabled
This feature requires a Cortex XDR Cloud per Host license. This license is required for both cloud-based and on-prem use of K8 nodes.
6. Configure Response Actions for specific applications or processes, using an Allow list.
If you need to isolate an endpoint, but want to allow access for a specific application or process, add it to the Network Isolation Allow List. Keep the
following considerations in mind:
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.
a. Click Add to add an entry to the allow list.
b. Specify the Process Path that 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.
c. Click the check mark.
7. 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 and enter the number of hours or days. We recommend 24 hours (default).
8. Configure the method used to update content on your endpoints.
(Not supported in Traps 5.0.x)
If you disable or delay automatic-content updates provided by Palo Alto Networks, it may affect the security level in your organization.
If you disable content updates for a newly installed agent, the agent retrieves the content for the first time from Cortex XDR, 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.
Item Options More Details
Content Auto-update Enabled (default) By default, the Cortex XDR agent always retrieves the most updated
content and deploys it on the endpoint, to ensure that it is always
Disabled (default) protected with the latest security measures.
If you disable content updates, the agent stops retrieving them from the
Cortex XDR tenant, and keeps working with the current content on the
endpoint.
Staging Content Enabled Enable users to deploy agent staging content on selected test
environments. Staging content is released before production content,
Disabled (default) allowing for early evaluation of the latest content update.
Displayed in the footer
Page 169 of 952
Cortex XDR Documentation
Displayed in the header
Item Options More Details
Content Rollout Immediately The Cortex XDR agent can retrieve content updates immediately as they
are available, or after a pre-configured delay period. When you delay
Delayed
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.
9. Agent Auto-Upgrade is disabled by default. Before enabling Auto-Update for Cortex XDR agents, make sure to consult with all relevant stakeholders in
your organization.
Automatic upgrades are not supported with non-persistent VDI and temporary sessions.
Item Options More Details
Agent Auto-Upgrade Enabled
Disabled (Default)
Automatic Upgrade Scope Latest agent release For One release before the latest one, Cortex XDR upgrades the agent
to the previous release before the latest, including maintenance
One release before the latest one
releases. Major releases are numbered X.X, such as release 8.0, or 8.2.
Only maintenance releases Maintenance releases are numbered X.X.X, such as release 8.2.2.
For Only maintenance releases in a specific version, select the required
Only maintenance releases in a
release version.
specific version
Upgrade Rollout Immediate For Delayed, set the delay period (number of days) to wait after the
version release before upgrading endpoints. Choose a value between 7
Delayed and 45.
To control the agent auto upgrade scheduler and number of parallel
upgrades in your network, configure Global Agent Settings.
10. Specify a Download Source, or multiple sources, from which Cortex XDR agent retrieves agent and content updates. The options provided help you to
reduce external network bandwidth loads during updates. When all sources are selected, the download sources are prioritized in the following order:
P2P > Broker VM > Cortex XDR 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 XDR server on their following heartbeat.
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, the new content update will start within one minute in P2P, and within five minutes from Cortex XDR.
Item Options More Details
Select all Selected When selected, all download source options are enabled.
Clear
Displayed in the footer
Page 170 of 952
Cortex XDR Documentation
Displayed in the header
Item Options More Details
P2P 33221 (default port) Cortex XDR deploys serverless peer-to-peer distribution to Cortex XDR
agents in your LAN network by default. Within the six hour randomization
custom port
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 port specified
for P2P Port. By default, Cortex XDR uses port 33221. You can change
the port number, if required by your organization.
Broker VM Select all (Requires Broker VM 12.0 and later)
Brokers If you have a Palo Alto Networks Broker VM in your network, you can
leverage the Local Agent Settings applet to cache release upgrades
Clusters and content updates. When the Broker VM is enabled and configured
appropriately (refer to Activate the Local Agent Settings) , it retrieves the
(only Broker VMs that are connected and
latest installers and content every 15 minutes. The Broker VM stores
configured for caching can be selected)
them for a 30-day retention period since an agent last asked for them.
If the files are not available on the Broker VM at the time of the request,
the agent proceeds to download the files directly from the Cortex XDR
server.
When you select multiple Broker VMs, the agent chooses a Broker VM
randomly for each download request.
11. Define Agent Proxy Settings.
Select whether to Enable or Disable Direct Server Access for the agent when connected using a proxy.
12. Configure Advanced Vulnerability Scanning for periodic Active Vulnerability Analysis (AVA) scans. This option is only available for tenants that are paired
with Prisma Cloud.
Item Options More Details
Advanced Vulnerability Enabled
Scanning
Disabled
Periodic Scan 24 Hours For the default setting, select 24 Hours.
Custom For other time frames, select Custom, and then configure the desired
time frame. 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.
13. Configure Agent Operation Mode. Three modes of operation exist:
Kernel module-based operation, offering synchronous anti-malware protection, event collection from kernel level, and anti-lpe protection
User Space Agent: user mode agent, for agents running Linux kernel 5.0.0 or higher, offering synchronous anti-malware and event collection from
kernel level
Neither of the above. When working in Kernel module-based operation running on an endpoint with an unsupported kernel, or installing with
installation flag --no-km , or when working in User Space Agent mode on a Linux kernel older than 5.0.0, the agent will run in Asynchronous
mode. In such cases, the anti-malware protection is asynchronous, and there is no event collection, no BTP, no EDR and no anti-lpe. This operation
mode frequently shows "partially protected" endpoints. To avoid this, you can configure the profile to give preference to Kernel mode, but to switch
to User Space Agent mode when the kernel module for an endpoint is not supported by a content update, and switch back when a the kernel
module in use is supported in a newer content update.
Displayed in the footer
Page 171 of 952
Cortex XDR Documentation
Displayed in the header
Endpoints running the Cortex XDR agent in Kernel mode can now be configured to automatically fall back to User Space Agent mode when a content
update does not contain a kernel module for the kernel used by an endpoint.
Item Options More Details
Mode Kernel We recommend using Kernel mode.
User Space Agent User Space Agent mode requires Linux kernel 5.0.0 or higher.
When Kernel Mode is Enabled When Kernel mode is used, to ensure continued full protection when a
unavailable, use User kernel version is not supported by a content update, select the Enabled
Disabled
Space Mode option.
User Space Agent mode requires Linux kernel 5.0.0 or higher. Endpoints
running an older Linux kernel version with this fallback enabled, will not
start using User Space Agent mode, and will operate asynchronously.
When a newer content update supports the endpoint's kernel module,
fallback is canceled, and Kernel mode is automatically resumed.
14. To save the profile, click Create.
What to do next
If you are ready to apply your new profile to endpoints, you do this by adding it to a policy rule. If you still need to define other profiles, you can do this later.
During policy rule creation or editing, you select the endpoints to which to assign the policy. There are different ways of doing this, such as:
Create a policy rule from the Prevention Profiles page
1. Navigate to Endpoints → Policy Management → Prevention → Profiles.
2. Right-click your new profile, and select Create a new policy rule using this profile.
3. Configure the policy rule.
Edit an existing policy rule from the Policy Rules page
1. Navigate to Endpoints → Policy Management → Prevention → Policy Rules.
2. Right click an existing policy and select Edit.
3. Add your new profile to the policy rule.
Create a new policy rule from the Policy Rules page
1. Navigate to Endpoints → Policy Management → Prevention → Policy Rules.
2. Click Add Policy.
3. Configure a new policy that includes your new profile.
Android
1. Add a new profile and define basic settings.
a. Select Endpoints → Policy Management → Prevention → Profiles. Click +Add Profile, and select whether to create a new profile or import a profile
from a file.
b. Select the Android platform, and Agent Settings as the profile type.
c. Click Next.
d. For Profile Name, enter a unique name for 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.
e. For Description, to provide additional context for the purpose or business reason for creating the profile, enter a profile description. For example,
you might include an incident identification number or a link to a help desk ticket.
2. Configure the method used to update content on your endpoints.
(Not supported in Traps 5.0.x)
If you disable or delay automatic-content updates provided by Palo Alto Networks, it may affect the security level in your organization.
Displayed in the footer
Page 172 of 952
Cortex XDR Documentation
Displayed in the header
If you disable content updates for a newly installed agent, the agent retrieves the content for the first time from Cortex XDR, 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.
Item Options More Details
Content Auto-update Enabled (default) By default, the Cortex XDR agent always retrieves the most updated
content and deploys it on the endpoint, to ensure that it is always
Disabled (default) protected with the latest security measures.
If you disable content updates, the agent stops retrieving them from the
Cortex XDR tenant, and keeps working with the current content on the
endpoint.
Content Rollout Immediately The Cortex XDR agent can retrieve content updates immediately as they
are available, or after a pre-configured delay period. When you delay
Delayed 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.
3. Configure network usage preferences.
When the option Upload Using Cellular Data is enabled, the Cortex XDR agent uses cellular data to send unknown apps to the Cortex XDR 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.
4. To save the profile, click Create.
What to do next
If you are ready to apply your new profile to endpoints, you do this by adding it to a policy rule. If you still need to define other profiles, you can do this later.
During policy rule creation or editing, you select the endpoints to which to assign the policy. There are different ways of doing this, such as:
Create a policy rule from the Prevention Profiles page
1. Navigate to Endpoints → Policy Management → Prevention → Profiles.
2. Right-click your new profile, and select Create a new policy rule using this profile.
3. Configure the policy rule.
Edit an existing policy rule from the Policy Rules page
1. Navigate to Endpoints → Policy Management → Prevention → Policy Rules.
2. Right click an existing policy and select Edit.
3. Add your new profile to the policy rule.
Create a new policy rule from the Policy Rules page
1. Navigate to Endpoints → Policy Management → Prevention → Policy Rules.
2. Click Add Policy.
3. Configure a new policy that includes your new profile.
iOS
1. Add a new profile and define basic settings.
a. Select Endpoints → Policy Management → Prevention → Profiles. Click +Add Profile, and select whether to create a new profile or import a profile
from a file.
New profiles based on imported profiles are added, and do not replace existing ones.
b. Select the iOS platform, and Agent Settings as the profile type.
c. Click Next.
Displayed in the footer
Page 173 of 952
Cortex XDR Documentation
Displayed in the header
d. For Profile Name, enter a unique name for 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.
e. For Description, to provide additional context for the purpose or business reason for creating the profile, enter a profile description. For example,
you might include an incident identification number or a link to a help desk ticket.
2. Configure the following notifications that can be pushed to the iOS device.
Item Options More Details
App Notifications Enabled Select whether to enable or disable notifications from the app on the iOS
device.
Disabled
Jailbreak Detection Enabled Select whether to enable or disable Jailbreak Detection notification to
the device.
Disabled
Restart Recommendation Enabled Select whether to enable or disable a reboot notification to the device.
An option can be set for a reminder every number of days. The default is
Disabled 15 days.
Stationary Device Enabled Select whether to enable or disable notifications for stationary iOS
Indicators devices, such as iPads that are expected to remain in a fixed location.
Disabled Options include:
Significant location change
Unplugged from power
Low battery. You can configure a threshold for the device's
remaining charge level (10% - 90%).
Significant network change
Show Stationary Device indication on its home screen
3. To save the profile, click Create.
What to do next
If you are ready to apply your new profile to endpoints, you do this by adding it to a policy rule. If you still need to define other profiles, you can do this later.
During policy rule creation or editing, you select the endpoints to which to assign the policy. There are different ways of doing this, such as:
Create a policy rule from the Prevention Profiles page
1. Navigate to Endpoints → Policy Management → Prevention → Profiles.
2. Right-click your new profile, and select Create a new policy rule using this profile.
3. Configure the policy rule.
Edit an existing policy rule from the Policy Rules page
1. Navigate to Endpoints → Policy Management → Prevention → Policy Rules.
2. Right click an existing policy and select Edit.
3. Add your new profile to the policy rule.
Create a new policy rule from the Policy Rules page
1. Navigate to Endpoints → Policy Management → Prevention → Policy Rules.
2. Click Add Policy.
3. Configure a new policy that includes your new profile.
Displayed in the footer
Page 174 of 952
Cortex XDR Documentation
Displayed in the header
12.2.1.1.4 | Set up restrictions prevention profiles
Abstract
Restrictions prevention profiles limit where executables can run on an endpoint.
Restrictions prevention profiles limit the locations from which executables can run on an endpoint.
Windows
By default, the Cortex XDR agent receives a default profile that contains a pre-defined configuration for each restriction capability. The default setting for each
capability is shown in parentheses in the user interface. To fine-tune your restrictions prevention policy, you can override the default configuration of each
capability as follows. For each setting that you override, clear the Use Default option, and select the setting of your choice.
Block: Block file execution.
Notify: Allow file execution, 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 XDR.
Report: Allow file execution, but report it to Cortex XDR.
Disabled: Disable the module, and do not analyze or report execution attempts from restricted locations.
Example 17.
To customize the configuration for specific Cortex XDR agents, configure a new restrictions prevention profile and assign it to one or more policy rules. You can
restrict files from running from specific local folders, or from removable media.
1. Add a new profile and define basic settings.
a. From Cortex XDR, select Endpoints → Policy Management → Prevention → Profiles. Click +Add Profile, and select whether to create a new profile
or import a profile from a file.
New profiles based on imported profiles are added, and do not replace existing ones.
b. Select the Windows platform, and Restrictions as the profile type.
c. Click Next.
d. For Profile Name, enter a unique name for 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.
e. For Description, to provide additional context for the purpose or business reason for creating the profile, enter a profile description. For example,
you might include an incident identification number or a link to a help desk ticket.
2. Configure Executable Files to restrict file execution to pre-defined locations.
Item Option More Details
Action Mode Block When the Cortex XDR agent detects execution of files from outside the
pre-defined locations, it performs the configured action.
Notify
To add files or folders to the Block List, click +Add, enter the path,
Report and press Enter. To add more files or folders, click +Add again.
Disabled You can 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\*).
To add files or folders to the Allow List, define a list on the Legacy
Agent Exceptions page.
3. Configure Network Location Files to restrict access to all network locations except for explicitly trusted ones.
Displayed in the footer
Page 175 of 952
Cortex XDR Documentation
Displayed in the header
Item Option More Details
Action Mode Block When the Cortex XDR agent detects execution of files from network
locations that are not trusted, it performs the configured action.
Notify
To add files or folders to the Allow List, define a list on the Legacy Agent
Report Exceptions page.
Disabled
4. Configure Removable Media Files to restrict file execution launched from external drives that are attached to endpoints in your network.
Item Option More Details
Action Mode Block When the Cortex XDR agent detects execution of files from removable
media,it performs the configured action.
Notify
To add files or folders to the Allow List, define a list on the Legacy Agent
Report
Exceptions page.
Disabled
5. Configure Optical Drive Files to restrict file execution launched from optical disc drives that are attached to endpoints in your network.
Item Option More Details
Action Mode Block When the Cortex XDR agent detects execution of files from an optical
disc drive, it performs the configured action.
Notify
To add files or folders to the Allow List, define a list on the Legacy Agent
Report Exceptions page.
Disabled
6. Configure Custom Prevention Rules.
Item Option More Details
Action Mode Enabled When user-defined BIOC prevention rules are present in the system, you
can enable them here.
Disabled
Configure custom BIOC prevention rules here:
Detection Rules → BIOC
7. To save the profile, click Create.
What to do next
If you are ready to apply your new profile to endpoints, you do this by adding it to a policy rule. If you still need to define other profiles, you can do this later.
During policy rule creation or editing, you select the endpoints to which to assign the policy. There are different ways of doing this, such as:
Create a policy rule from the Prevention Profiles page
1. Navigate to Endpoints → Policy Management → Prevention → Profiles.
2. Right-click your new profile, and select Create a new policy rule using this profile.
3. Configure the policy rule.
Edit an existing policy rule from the Policy Rules page
1. Navigate to Endpoints → Policy Management → Prevention → Policy Rules.
Displayed in the footer
Page 176 of 952
Cortex XDR Documentation
Displayed in the header
2. Right click an existing policy and select Edit.
3. Add your new profile to the policy rule.
Create a new policy rule from the Policy Rules page
1. Navigate to Endpoints → Policy Management → Prevention → Policy Rules.
2. Click Add Policy.
3. Configure a new policy that includes your new profile.
macOS
1. Add a new profile and define basic settings.
a. From Cortex XDR, select Endpoints → Policy Management → Prevention → Profiles. Click +Add Profile, and select whether to create a new profile
or import a profile from a file.
New profiles based on imported profiles are added, and do not replace existing ones.
b. Select the macOS platform, and Restrictions as the profile type.
c. Click Next.
d. For Profile Name, enter a unique name for 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.
e. For Description, to provide additional context for the purpose or business reason for creating the profile, enter a profile description. For example,
you might include an incident identification number or a link to a help desk ticket.
2. Configure Custom Prevention Rules.
Item Option More Details
Action Mode Enabled When user-defined BIOC prevention rules are present in the system, you
can enable them here.
Disabled
Configure custom BIOC prevention rules here:
Detection Rules → BIOC
3. To save the profile, click Create.
What to do next
If you are ready to apply your new profile to endpoints, you do this by adding it to a policy rule. If you still need to define other profiles, you can do this later.
During policy rule creation or editing, you select the endpoints to which to assign the policy. There are different ways of doing this, such as:
Create a policy rule from the Prevention Profiles page
1. Navigate to Endpoints → Policy Management → Prevention → Profiles.
2. Right-click your new profile, and select Create a new policy rule using this profile.
3. Configure the policy rule.
Edit an existing policy rule from the Policy Rules page
1. Navigate to Endpoints → Policy Management → Prevention → Policy Rules.
2. Right click an existing policy and select Edit.
3. Add your new profile to the policy rule.
Create a new policy rule from the Policy Rules page
1. Navigate to Endpoints → Policy Management → Prevention → Policy Rules.
2. Click Add Policy.
3. Configure a new policy that includes your new profile.
Linux
1. Add a new profile and define basic settings.
Displayed in the footer
Page 177 of 952
Cortex XDR Documentation
Displayed in the header
a. From Cortex XDR, select Endpoints → Policy Management → Prevention → Profiles. Click +Add Profile, and select whether to create a new profile
or import a profile from a file.
New profiles based on imported profiles are added, and do not replace existing ones.
b. Select the Linux platform, and Restrictions as the profile type.
c. Click Next.
d. For Profile Name, enter a unique name for 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.
e. For Description, to provide additional context for the purpose or business reason for creating the profile, enter a profile description. For example,
you might include an incident identification number or a link to a help desk ticket.
2. Configure Custom Prevention Rules.
Item Option More Details
Action Mode Enabled When user-defined BIOC prevention rules are present in the system, you
can enable them here.
Disabled
Configure custom BIOC prevention rules here:
Detection Rules → BIOC
3. To save the profile, click Create.
What to do next
If you are ready to apply your new profile to endpoints, you do this by adding it to a policy rule. If you still need to define other profiles, you can do this later.
During policy rule creation or editing, you select the endpoints to which to assign the policy. There are different ways of doing this, such as:
Create a policy rule from the Prevention Profiles page
1. Navigate to Endpoints → Policy Management → Prevention → Profiles.
2. Right-click your new profile, and select Create a new policy rule using this profile.
3. Configure the policy rule.
Edit an existing policy rule from the Policy Rules page
1. Navigate to Endpoints → Policy Management → Prevention → Policy Rules.
2. Right click an existing policy and select Edit.
3. Add your new profile to the policy rule.
Create a new policy rule from the Policy Rules page
1. Navigate to Endpoints → Policy Management → Prevention → Policy Rules.
2. Click Add Policy.
3. Configure a new policy that includes your new profile.
12.2.1.1.5 | Set up exception profiles and rules
Abstract
Exception profiles can be configured to override security policies for known processes, files, digital signers, URLs, BTP rules, telephone numbers, and other
exceptions.
Exception profiles override the security policy in scenarios such as:
Displayed in the footer
Page 178 of 952
Cortex XDR Documentation
Displayed in the header
Allow a process or a file to run on an endpoint
Allow a known digital signer
Allow access to specific URLs (via Safari) or telephone numbers
Disable a specific behavioral threat protection (BTP) rule
Import exceptions from the Cortex XDR support team
12.2.1.1.5.1 | Exception configuration
Abstract
Learn how to configure exceptions from your baseline policy.
To allow full granularity, Cortex XDR 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 protection and prevention actions in a
centralized location, and apply them across multiple profiles. The exceptions can be configured from Settings → Exception Configuration.
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 that takes action on specific behaviors.
Disable Injection and Prevention rules specify exceptions that bypasses a process from prevention modules and injections.
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 XDR version 3.5, Legacy Agent Exceptions and Support Exceptions were configured through their relevant profiles.
Starting with version 3.5, Cortex XDR 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 XDR simulates the migration to enable you to review the results before activating the migration.
How to migrate existing exceptions
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.
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
Set up exploit prevention profiles
Set up malware prevention profiles
Set up restrictions prevention profiles
After the migration, you can Add a support exception rule or Add a legacy exception rule.
12.2.1.1.5.2 | Alert exclusions
Abstract
Learn how to review and manage alert exclusions.
The Settings → Exception Configuration → Alert Exclusions page displays the alert exclusion rules in Cortex XDR.
An Alert Exclusion is a rule that contains a set of alert match criteria that you want to suppress from Cortex XDR. You can add an Alert Exclusion rule from
scratch or base the exclusion on alerts you investigate in an incident. After you create an exclusion rule, Cortex XDR 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 identifies the historic alerts as grayed out.
Displayed in the footer
Page 179 of 952
Cortex XDR Documentation
Displayed in the header
The agent continues to raise excluded alerts on the endpoint, but they are not saved or displayed in Cortex XDR. Configuring an alert exclusion does not
remove or delete any of the logs that would have triggered the alert.
You can also set up alert exceptions by creating global endpoint policy exceptions. For more information, see Add a global endpoint policy exception.
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.
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.
Add an alert exclusion rule
Abstract
Learn how to create a rule to exclude certain criteria from raising alerts in Cortex XDR.
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
XDR to display alerts that match certain criteria, you can create an alert exclusion rule.
After you create an exclusion rule, Cortex XDR 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.
If an incident contains only alerts with exclusions, Cortex XDR 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.
You can also set up alert exceptions by creating global endpoint policy exceptions. For more information, see Add a global endpoint policy exception.
Alert exclusions support Scope-Based Access Control (SBAC). For more information, see Manage user scope.
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.
Displayed in the footer
Page 180 of 952
Cortex XDR Documentation
Displayed in the header
Build an alert exclusion policy from alerts in an 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 Response → Incidents, from the Incident view, click the menu icon 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.
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.
This action is irreversible. All historically excluded alerts will remain excluded if you disable or delete the rule.
7. Create the alert exception rule.
12.2.1.1.5.3 | Add an IOC or BIOC rule exception
Abstract
Learn 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 Detection rules. For each exception, you also specify the rule
scope to which the exception applies.
In case you need to map fields returned in an XQL process query to your exception configuration, the following table provides a matrix for the criteria
mentioned in this procedure to the fields returned in a process query.
IOC/BIOC Suppression Rule Conditions Process Query Result Fields
Process Sha256 actor_process_image_sha256
Process Name actor_process_image_name
Displayed in the footer
Page 181 of 952
Cortex XDR Documentation
Displayed in the header
IOC/BIOC Suppression Rule Conditions Process Query Result Fields
Process Path actor_process_image_path
Signed By Vendor actor_process_signature_vendor
User Name actor_effective_username
Cgo Full Path actor_process_command_line
Process Cmd causality_actor_process_image_path
Cortex XDR 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 that define the exception.
You can use wildcards to match the command line.
5. Select the scope of the exception, whether the exception applies to IOCs, BIOCs, or both.
By default, all BIOC rules that 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:
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
12.2.1.1.5.4 | Add a disable prevention rule
Abstract
You can generate granular exceptions to prevention actions defined for your endpoints.
You can 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 XDR still generates alerts from the disabled rules.
All applicable prevention actions are skipped for the files and process that match the properties defined in the rule.
Consider the consequences of disabling a prevention rule before you add the exception and monitor it over time.
You can only apply a Disable Prevention Rule to agents version 7.9 and later.
Displayed in the footer
Page 182 of 952
Cortex XDR Documentation
Displayed in the header
1. From Settings → Exception Configuration → Disable Prevention Rules, select +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 that 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 list.
7. Enable the rule.
8. Review the configurations for the exception, and if the risks are acceptable to you, select I understand the risk.
12.2.1.1.5.5 | Add a disable injection and prevention rule
Abstract
You can generate a temporary exception to bypass a process from prevention modules and injections.
You can generate a temporary exception to bypass a process from prevention modules and injections. You can specify paths, or command line, from both
prevention and injection. This may be useful when you have processes that are essential to your organization and must not be terminated. Cortex XDR still
generates alerts from data collections.
Exceptions are limited up to 48 hours by default and configurable up to one week.
Consider the consequences of disabling a prevention rule before you add the exception and monitor it over time.
You can only apply a Disable Prevention Rule to agents version 7.9 and later.
1. Select Settings → Exception Configuration → Disable Injection and Prevention.
2. Click +Add Injection Rule.
3. Specify a rule name and an optional description.
4. Select the platform. To cover all your endpoints, you can prevent different exception rules per platform.
5. Add the Process Name , and specify the Path to bypass.
6. Select the time limit for the exception rule.
7. Select the Scope for the rule. If you want to apply the rule to only specific Exception Profiles, select them from the list.
8. Enable the rule.
9. Click Yes, to confirm that you acknowledge that the selected rules will be disabled.
12.2.1.1.5.6 | Add a support exception rule
Abstract
Learn 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.
Keep in mind the following:
Prior to Cortex XDR version 3.5, support exceptions were configured through profiles.
Starting with version 3.5, Cortex XDR enables you to manage the support exceptions from a central location and easily apply them across multiple
profiles on the Support Exception Rules page.
To manage the prevention profile exceptions from Exception Configuration, you must first migrate your existing exceptions configured via the Prevention
profiles.
Displayed in the footer
Page 183 of 952
Cortex XDR Documentation
Displayed in the header
Your migrated rules are displayed on the Settings → Exception Configurations → Support Exception Rules page. For more information about the migration, see
Exception configuration.
1. From Settings → Exception Configuration → Support Exception Rules, click + Import from file.
2. Locate 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.
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
Set up exploit prevention profiles
Set up malware prevention profiles
Set up restrictions prevention profiles
12.2.1.1.5.7 | Add a legacy exception rule
Abstract
Learn how to use Cortex XDR Legacy Exception rules 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 may continue to generate Cortex XDR security events. If you want to exclude event reporting, configure this on the Alert Exclusions
page (Settings → Exception Configurations → Alert Exclusions).
Keep in mind the following:
Prior to Cortex XDR version 3.5, legacy exceptions were configured through profiles.
Starting with version 3.5, Cortex XDR 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.
1. Select Settings → Exception Configurations → Legacy Agent Exceptions, and then click + 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. Optionally, select Select all to apply the exception to all profiles for this module or select
specific profiles.
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 XDR 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.
Displayed in the footer
Page 184 of 952
Cortex XDR Documentation
Displayed in the header
Type Module Platform Parameters
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.
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.
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.
PDF Examination 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.
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.
Displayed in the footer
Page 185 of 952
Cortex XDR Documentation
Displayed in the header
Type Module Platform Parameters
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.
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.
UEFI 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.
PowerShell Script 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.
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.
Displayed in the footer
Page 186 of 952
Cortex XDR Documentation
Displayed in the header
Type Module Platform Parameters
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.
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 XDR to block.
Call and Messages Blocking iOS Add to your allow list names and
Allow list phone numbers of contacts that
you do not want Cortex XDR 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.
Displayed in the footer
Page 187 of 952
Cortex XDR Documentation
Displayed in the header
Type Module Platform Parameters
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.
4. For each module, enter the file or folder path that you want to add to the exception rule, and press ENTER. Repeat this step to add additional paths to
the rule.
5. Select the endpoint profiles to which you want to apply this rule.
6. Click Next.
7. Review the rule, and then select the warning message checkbox.
8. Click Create.
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
Set up exploit prevention profiles
Set up malware prevention profiles
Set up restrictions prevention profiles
Add a new exceptions security profile
Abstract
Learn 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.
Starting with version 3.5, Cortex XDR 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.
How to create an endpoint-specific exception
1. Add a new profile.
a. From Cortex XDR, select Endpoints → Policy Management → Prevention → Profiles → +Add Profile and select whether to Create New or Import
from File a new profile.
New imported profiles are added and not replaced.
b. Select the platform to which the profile applies and Exceptions as the profile type.
Displayed in the footer
Page 188 of 952
Cortex XDR Documentation
Displayed in the header
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.
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.
Configure a support exception
1. Import the json file you received from the Palo Alto Networks support team by either browsing for it in your files or by dragging the file on the page.
2. Click Create.
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 XDR 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 XDR 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 XDR 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 XDR 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 XDR to continue enforcing the Gatekeeper Enhancement protection module on the source process running other child processes.
Displayed in the footer
Page 189 of 952
Cortex XDR Documentation
Displayed in the header
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 profiles to endpoints.
If you want to remove an exceptions profile from your network, go to the Profiles page, right-click, and select Delete.
Add a global endpoint policy exception
Abstract
Learn how to define and manage global endpoint policy exceptions in Cortex XDR.
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.
Starting with version 3.5, Cortex XDR 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 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 a global process exception
Configure exception rules forCortex XDR protection and prevention actions in a centralized location, and apply them across multiple profiles.
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
Configure support exception rules for Cortex XDR protection and prevention actions in a centralized location, and apply them across multiple profiles.
1. Go to Endpoints → Prevention → Global Exceptions.
2. Select Support Exceptions.
Import the JSON file you received from the Palo Alto NetworksPalo 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 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).
Displayed in the footer
Page 190 of 952
Cortex XDR Documentation
Displayed in the header
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 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.
You cannot edit global exceptions generated from a BTP security event.
Add a global credential gathering protection exception
When you view a Credential Gathering Protection alert in the Alerts table that 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.
You cannot edit global exceptions generated from a Credential Gathering Protection security event.
Add a global anti webshell protection exception
When you view an Anti Webshell Protection alert in the Alerts table that 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.
You cannot edit global exceptions generated from an Anti Webshell Protection security event.
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.
Displayed in the footer
Page 191 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR can provide a secondary validation of Cortex XDR agent alerts raised by exploit protection modules. To perform the
additional analysis, Cortex XDR analyzes alert data sent by the Cortex XDR agent. If Advanced Analysis indicates an alert is benign, Cortex XDR can
automatically create exceptions and distribute the updated security policy to your endpoints.
By enabling Cortex XDR 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 XDR displays the affected platform, exception name, and the relevant alert ID for which Cortex XDR determined activity was
benign. To drill down into the alert details, click the Generating Alert ID.
Add a global digital signer exception
When you view in the Alerts table a Digital Signer Restriction alert 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
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
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
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 XDR 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
Displayed in the footer
Page 192 of 952
Cortex XDR Documentation
Displayed in the header
it and click X. You cannot edit global exceptions generated from a gatekeeper enhancement security event.
Import and export exceptions
Select + Import/Export to Export your exceptions list and/or Import from File.
The exported file is encoded in Base64 and cannot be edited.
12.2.1.2 | Define endpoint groups
Abstract
Define an endpoint group and then apply policy rules and manage specific endpoints.
You can define an endpoint group and then apply policy rules and manage specific endpoints. If you set up Cloud Identity Engine, you can also leverage your
Active Directory user, group, and computer details to define endpoint groups.
Do one of the following :
Create a dynamic group by enabling Cortex XDR to populate your endpoint group dynamically using endpoint characteristics, such as an endpoint tag,
partial hostname or alias, full or partial domain or workgroup name, IP address, range or subnets, installation type (VDI, temporary session or standard
endpoint), agent version, endpoint type (workstation, server, mobile), 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.
How to define an endpoint group
1. From Cortex XDR, select Endpoints → Endpoint Groups → +Add Group.
2. Select one of the following:
Create New to create an endpoint group from scratch
Upload From File using plain text files with a new line separator, to populate a static endpoint group from a file containing IP addresses,
hostnames, or aliases.
3. Enter a Group Name and optional description to identify the endpoint group. The name you assign to the group will be visible when you assign endpoint
security profiles to endpoints.
4. Determine the endpoint properties for creating an endpoint group:
Dynamic: Use the filters to define the criteria you want to use to dynamically populate an endpoint group. Dynamic groups support multiple criteria
selections and can use AND or OR operators. For endpoint names and aliases, and domains and workgroups, you can use * to match any string
of characters. As you apply filters, Cortex XDR 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 XDR. You can select up to 250 endpoints.
Disconnecting Cloud Identity Engine in your Cortex XDR deployment can affect existing endpoint groups and policy rules based on Active Directory
properties.
5. Create the endpoint group.
After you save your endpoint group, it is ready for use to assign security profiles to endpoints and in other places where you can use endpoint groups.
At any time, you can return to the 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: Remove the endpoint group.
Save as new: Duplicate the endpoint group and save it as a new group.
Export group: Export the list of endpoints that match the endpoint group criteria to a tab separated values (TSV) file.
View endpoints: Pivot from an endpoint group to a filtered list of endpoints on the Endpoint Administration page where you can quickly view and initiate
actions on the endpoints within the group.
Displayed in the footer
Page 193 of 952
Cortex XDR Documentation
Displayed in the header
12.2.1.3 | Configure global agent settings
Abstract
The different Cortex XDR agents that operate on your endpoints require configuration of different global settings.
In addition to the customizable Agent Settings Profiles for each Operating System and different endpoint targets, you can configure global Agent
Configurations that apply to all the endpoints in your network.
1. From Cortex XDR, 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 XDR or set a new one and Save. This global uninstall password applies to all the endpoints (excluding
mobile) in your network. If you change the password later on, the new default password applies to all new and existing profiles to which it applied before.
If you want to use a different password to uninstall specific agents, you can override the default global uninstall password by setting a different password
for those agents in the Agent Settings profile. The selected password must satisfy the requirements enforced by Password Strength indicator.
A new password must satisfy the following Password Strength indicator requirements:
It must be 8 to 32 characters.
It must contain at least one upper-case, at least one lower-case letter, at least one number, and at least one of the following characters: !@#%.
3. Manage the content updates bandwidth and frequency in your network.
Enable bandwidth control: Palo Alto Networks enables you to control your Cortex XDR agent network consumption by adjusting the bandwidth it is
allocated. Based on the number of agents you want to update with content and upgrade packages, active or future agents, the Cortex XDR
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 XDR 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 XDR 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 XDR content updates, assign a Content bandwidth management value between
20-10,000 Mbps. To help you with this calculation, Cortex XDR 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 XDR 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, where 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 XDR to automatically retrieve the files.
After Cortex XDR receives the data, it automatically analyzes the memory contents and renders a verdict. When the analysis is complete, Cortex XDR
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 XDR to automatically create
and distribute exceptions based on the Advanced Analysis results.
a. Configure the desired options:
Displayed in the footer
Page 194 of 952
Cortex XDR Documentation
Displayed in the header
Enable Cortex XDR to automatically upload defined alert data files for advanced analysis. Advanced Analysis increases the Cortex XDR
exploit protection module accuracy.
Automatically apply Advanced Analysis exceptions to your Global Exceptions list. This will apply all Advanced Analysis exceptions
suggested by Cortex XDR, 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 XDR. Default is 30 days; Range is 2 to 60 days. Day one is counted as the first 24 hours with no connection.
Agent Deletion (Days): Configure the number of days after which the agent and related data is removed from the Cortex XDR management
console and database. Default is 180 days; Range is 3 to 360 days and must exceed the Connection Lost value. Day one is the first 24
hours of lost connection.
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. After this, when
Cortex XDR receives a Benign Low Confidence verdict, the agent enforces the Malware Security profile settings you currently have in place (Run local
analysis to determine the file verdict, Allow, or Block).
Disabling this capability takes immediate effect on new hashes, fresh agent installations, and existing security policies. It could take up to a week to take
effect on existing agents in your environment pending agent caching.
9. Enable Informative BTP Alerts.
Behavioral threat protection (BTP) alerts have been given unique and informative names and descriptions, to provide immediate clarity into the events
without having to drill down into each alert. Enable to display of the informative BTP rule alert names and descriptions. After you update the settings, new
alerts include the changes while already existing alerts remain unaffected.
If you have any Cortex XDR 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.
12.2.1.4 | Apply profiles to endpoints
Abstract
Learn how to apply security profiles to your endpoints, depending on the platform used.
Cortex XDR 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 XDR, create a policy rule.
Do one of the following:
Displayed in the footer
Page 195 of 952
Cortex XDR Documentation
Displayed in the header
Select Endpoints → Policy Management → Prevention → Policy Rules, and select + New Policy or Import from File.
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 click 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 XDR 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.
The exported file is encoded in Base64 and cannot be edited.
12.2.1.5 | 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, create an agent installation package. Review Where can I install the Cortex XDR agent for
supported versions and operating systems.
To install the Cortex XDR agent software, you must use a valid installation package that exists in your Cortex XDR management console. If you delete an
installation package, new agents installed from this package are not able to register to Cortex XDR, however, existing agents may re-register using the Agent
ID generated by the installation package.
1. From Cortex XDR, select Endpoints → Agent Installations.
2. Click Create to create a new installer.
3. Enter a unique name and an optional description to identify the installation package.
The package name can contain letters, numbers, hyphens, underscores, commas, and spaces, and should not exceed 100 characters.
4. Select the Package Type:
Displayed in the footer
Page 196 of 952
Cortex XDR Documentation
Displayed in the header
Standalone Installer: Use for fresh installations and to upgrade agents on a registered endpoint that is connected to Cortex XDR.
Upgrade from ESM: Use this package to upgrade Traps agents which connect to the on-premises Traps Endpoint Security Manager to Cortex
XDR. 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.
Guidelines for Kubernetes installer
Settings for the Kubernetes installer cannot be changed after you create the installation package.
For the Agent Daemonset Namespace, it is recommended to use the default cortex-xdr namespace.
For a more granular deployment, enter any labels or selectors in the Node Selector. The Cortex XDR agent will be deployed only on these
nodes.
To configure the Cortex XDR agent to communicate through a proxy, enter either the IP address and port number or enter 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.
Helm Installer: Use this package for fresh installations and upgrades of Cortex XDR agents running on Kubernetes clusters.
5. Select the platform and relevant settings, and then click Create.
Cortex XDR prepares your installation package and displays it on the Agent Installations page.
6. Download your installation package.
When the status of the package shows Completed, right-click the package, and click Download.
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.
12.2.1.5.1 | Manage an agent installation package
Abstract
Learn how to make changes such as deleting an agent installation package or editing the package name.
You can manage agent installation packages on the Agent Installations page. To manage a specific package, right-click the agent version, and select the
desired action:
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.
Since Cortex XDR 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 XDR 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.
12.2.1.6 | Harden endpoint security
Abstract
By hardening your endpoints with Cortex XDR agent, you can make these endpoints more secure and safer from attackers.
You can extend the security on your endpoints beyond the Cortex XDR agent built-in prevention capabilities to provide increased network security coverage
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
Displayed in the footer
Page 197 of 952
Cortex XDR Documentation
Displayed in the header
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.
Field Description
Associated Targets 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.
Hardened endpoint security capabilities are not supported for Android endpoints.
Module Windows Mac Linux
Device Control ✓ ✓ –
Protects endpoints from loading malicious Cortex XDR agent 7.0 and later Cortex XDR agent 7.2 and later
files from USB-connected removable devices
(CD-ROM, disk drives, floppy disks, and For VDI, Cortex XDR agent 7.3
Windows portable devices drives). and later
Host Firewall ✓ ✓ –
Protects endpoints from attacks originating in Cortex XDR agent 7.1 and later Cortex XDR agent 7.2 and later
network communications to and from the
endpoint.
Displayed in the footer
Page 198 of 952
Cortex XDR Documentation
Displayed in the header
Module Windows Mac Linux
Disk Encryption ✓ ✓ –
Provides visibility into endpoints that encrypt Cortex XDR agent 7.1 and later Cortex XDR agent 7.2 and later
their hard drives using BitLocker or FileVault.
12.2.1.6.1 | Device control
Abstract
Protect your Windows and macOS-based endpoints from connecting to malicious USB-connected removable devices, to Bluetooth devices, and to print jobs.
By default, all external USB and Bluetooth devices are allowed to connect to your Windows and macOS-based Cortex XDR endpoints, and all print jobs are
allowed. To protect endpoints from connecting to removable devices, such as disk drives, CD-ROM drives, floppy disk drives, Bluetooth devices, and other
portable devices, that can contain malicious files, Cortex XDR provides device control. Different types of print jobs can also be blocked.
Using device control, you can:
(Windows and macOS) Block all supported USB-connected devices for an endpoint group.
(Windows and macOS) Block a USB device type but add to your allow list a specific vendor from that list that will be accessible from the endpoint.
(Windows only) Block connections to Classic Bluetooth devices or Low Energy Bluetooth services. These are two different Bluetooth protocols used for
short-range wireless connections.
Some examples of Classic Bluetooth devices include: laptop computers, tablets, telephones, audio/video devices, wearables, peripherals,
imaging devices, health devices, toys, and so on.
Some examples of Low Energy Bluetooth devices include: telephone alert status, microphone control, health sensors, insulin delivery, location and
navigation, object transfer, and so on.
Temporarily block only some device types on an endpoint.
USB devices (Windows and macOS)
Bluetooth devices (Windows only)
(Windows and macOS) Block some, or all, print jobs to local or network printers, or to file.
Depending on your defined user scope permissions, creating device profiles, policies, exceptions, and violations may be disabled.
When you enable device control protection for the first time, some devices that are already connected to the endpoint (or paired, in case of Bluetooth) will not
be immediately affected by the change.
The profile change will affect the connected device after one of the following occurs:
Disconnection and reconnection of the device
A computer restart
For Bluetooth, toggling Bluetooth off and on, or manually unpairing the device
The following are prerequisites to enforce device control policy rules on your endpoints:
Platform Prerequisites
Windows For VDI:
For VMware Horizon, you must disable Sharing → Allow access to removable storage in your VMware
Horizon client settings.
Mac No prerequisites
Linux Not supported
Displayed in the footer
Page 199 of 952
Cortex XDR Documentation
Displayed in the header
Platform Prerequisites
Android Not supported
iOS Not supported
The following limitations apply to device control on your endpoints:
Platform Device Type Limitation
Windows VDI 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 XDR Device Control is supported on
generic virtual channels only.
Windows Bluetooth Serial number queries are not supported.
If a profile is set to block specific Bluetooth Low Energy (BLE) services, Cortex XDR
only blocks the services set to Block, and not the functionality of the entire device.
This means that if a device has multiple services, some of them might still be
accessible, while others are blocked.
Cortex XDR attempts to aggregate all related BLE services so that they appear under
a single logical Bluetooth device control violation report. However, some Bluetooth
devices might be reported in a separate violation report due to the way these devices
are paired in the Windows operating system and because they reside outside the
device container.
Cortex XDR cannot block low energy services or report device control violations on
devices that do not report any LE services. The devices can, however, be blocked
completely by setting the entire Bluetooth device to Block.
Exceptions can only be created when the Vendor field for the device is available in a
violation report.
Exceptions for specific BLE devices cannot be created from a violation report.
Exceptions for such devices can only be created by disabling the the blocked LE
services in the policy.
If a Bluetooth device vendor is registered as a Vendor (with ID) in the regulatory
organization that supervises USB devices, but is not registered as a Bluetooth
device, exceptions cannot be created from a violation report. An alternate method for
creating an exception is to create a separate profile for the endpoints using the
Bluetooth devices, and allow/unblock use of the specific Bluetooth classes or BLE
services for these devices.
macOS - No limitations
Linux - Not supported
Android - Not supported
Displayed in the footer
Page 200 of 952
Cortex XDR Documentation
Displayed in the header
Platform Device Type Limitation
iOS - Not supported
Device control profiles
To apply device control in your organization, define device control profiles that determine which device types Cortex XDR blocks, and which it permits. There
are two types of profiles:
Displayed in the footer
Page 201 of 952
Cortex XDR Documentation
Displayed in the header
Profile Description
Configuration Profile Allow or block these device type groups:
Disk Drives (USB-connected)
CD-Rom Drives (USB-connected)
Floppy Disk Drives (USB-connected)
(Windows only) Windows Portable Devices (USB-connected)
(Windows only) Bluetooth Devices (block, allow, or custom types)
The Custom option includes configuration options for specific
Bluetooth Classes (Bluetooth Classic) device types, and for
Low Energy Services (Bluetooth Low Energy).
When you select an option in Bluetooth Classes, the right pane
of the dialog box provides a detailed list of device types that
belong to the selected class. You can choose all, or some of
the items in this list.
Print Jobs (all, or custom types)
When set to Block, all print jobs sent from the endpoint will be
blocked.
When set to Custom, the following options are available:
Network printer jobs only when outside Corp. network blocks
print jobs sent to network printers while the endpoint is not on
the corporate network.
Network printer jobs (internal/VPN) blocks print jobs sent to
network printers while the endpoint is connected to the network
via VPN or an internal connection.
Local printer jobs blocks print jobs sent to a printer which is
directly connected to an endpoint.
Printing to file (Windows only) blocks print jobs that are saved
as a file. This option only blocks the print driver.
For network printer print jobs, ensure that you also configure the
Agent Settings profile, Network Location Configuration option. This
setting must be set to Enabled, and configured.
If you do not enable and configure this setting, all network printer
operations will be treated as internal network print jobs.
The Print Job option does not block connections to a printer, but
blocks print jobs according to the type of print job. You cannot block
use of a specific printer with this feature.
Any print job that is not sent via the endpoint's printer spooler, such
as a file uploaded to a remote software based printing service, will
not be blocked.
Cortex XDR 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.
Displayed in the footer
Page 202 of 952
Cortex XDR Documentation
Displayed in the header
Profile Description
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 → Extensions → Profiles, select +Add Profile and then select either Create New or Import from File.
2. Select a 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 XDR.
4. Configure Device Configuration.
For each group of device types, select the desired action. To use the default option defined by Palo Alto Networks, leave Use Default selected.
For Disk Drives only, you can also allow connecting in Read-only mode.
For Print Jobs, you can choose the Custom option, and then select the desired print job type.
For Bluetooth Devices, you can choose the Custom option, and then select the desired Bluetooth Classes or Low Energy Services type.
Currently, the default is set to Use Default (Allow), however, Palo Alto Networks may change the default definition at any time.
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. To save your device profile definitions, click Create.
If needed, you can edit, delete, or duplicate your profiles.
You cannot edit or delete the default profiles pre-defined in Cortex XDR.
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.
Type: Select the device type that you want to add to the allow list: Bluetooth, CD-ROM, Disk Drive, Floppy Disk, or Windows Portable Devices
(Windows only).
(Disk Drives only) Permission: Select the permissions you want to grant: Read only or Read/Write.
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. If you want to add serial number where the last character is a space character, use quotation marks. For
example, "K04M1972138 ".
5. To save your device exceptions profile, click Create.
Displayed in the footer
Page 203 of 952
Cortex XDR Documentation
Displayed in the header
If needed, you can later edit, delete, or duplicate your profiles.
You cannot edit or delete the predefined profiles in Cortex XDR.
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 XDR 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.
When enabling Device Control protection for the first time, some devices that are already connected (or paired in case of Bluetooth) to the machine will not be
immediately affected by the change. The profile change will affect the connected device after one of the following occurs:
Disconnection and reconnection of the device
A computer restart
For Bluetooth devices only: Bluetooth toggled off and on, or manual unpairing of the device.
1. In Endpoints → Policy management → Extensions → Policy Rules, select + New Policy or Import from File.
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.
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 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.
4. Save the policy hierarchy.
After the policy is saved and applied to the agents, Cortex XDR 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, you can use the Endpoints → Device Control Violations page to monitor all instances where
end users attempted to connect restricted devices or print jobs, and Cortex XDR 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 XDR logs the following event details,
where relevant and available for each device or print job:
Displayed in the footer
Page 204 of 952
Cortex XDR Documentation
Displayed in the header
ID
Timestamp for the violation event
Host name of the endpoint
Platform (operating system)
Agent ID
User name
IP address
Type of device
GUID of the device
Vendor ID of the device
Vendor of the device
Product name
Serial number (not supported for Bluetooth devices on Windows-based endpoints)
Print Job Type
Document Name of a print job
Additional Information
Major Class
Minor Class
Vendor Type
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 XDR 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.
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.
Displayed in the footer
Page 205 of 952
Cortex XDR Documentation
Displayed in the header
Exception Name Description
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.
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 XDR 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.
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 XDR as all other device classes.
Displayed in the footer
Page 206 of 952
Cortex XDR Documentation
Displayed in the header
Add a custom user notification
You can personalize the Cortex XDR 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 Set up agent settings profiles.
Ingest connect and disconnect events of USB devices
This feature requires a Cortex XDR Pro license.
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:
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
12.2.1.6.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 XDR 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 XDR 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 XDR 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 XDR host firewall profile.
Displayed in the footer
Page 207 of 952
Cortex XDR Documentation
Displayed in the header
Platform Requirements And Limitations
Mac Cortex XDR agent 7.5 or a later release.
After you disable or remove the Cortex XDR 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 XDR host firewall.
Automatically allow built-in software to receive incoming connections.
Automatically allow downloaded signed software to receive incoming
connections.
Linux Not supported.
12.2.1.6.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 XDR 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 XDR 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.
To configure the Cortex XDR host firewall in your network, follow this high-level workflow:
Ensure you meet the host firewall requirements and prerequisites.
Create rules 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.
Set up the host firewall
Set up your rule groups and host firewall profile.
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 XDR is assigned a unique ID and must be contained within a group. Additionally, you can import
existing firewall rules into Cortex XDR, 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.
Displayed in the footer
Page 208 of 952
Cortex XDR Documentation
Displayed in the header
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.
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.
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 XDR 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
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 XDR host firewall or export them. Right-click the rule and
Import/Export.
Displayed in the footer
Page 209 of 952
Cortex XDR Documentation
Displayed in the header
Manage 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
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 XDR 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 XDR
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
Displayed in the footer
Page 210 of 952
Cortex XDR Documentation
Displayed in the header
Field Description
Group Name Name of the group rules group
Mode Displays whether the rules group is enabled
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
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 XDR.
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
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.
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.
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.
Displayed in the footer
Page 211 of 952
Cortex XDR Documentation
Displayed in the header
After the policy is saved and applied to the agents, Cortex XDR enforces the host firewall policies in your environment.
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.
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.
12.2.1.6.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 XDR 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 XDR 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 XDR host firewall rules leverage the operating system firewall APIs
and enforce these rules on your endpoints, but not your Windows or Mac firewall settings.
In Cortex XDR 3.0, no change was made to the Host Firewall Configuration or operation on macOS endpoints. All existing policies configured in Cortex XDR
2.9 still apply and will continue to work as expected with Cortex XDR agent 7.2 or a later release. Enforcement events triggered by macOS endpoints are not
included in the Host Firewall Events table.
To configure the Cortex XDR 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.
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 XDR 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.
Displayed in the footer
Page 212 of 952
Cortex XDR Documentation
Displayed in the header
To apply location-based host firewall rules, you must first enable network location configuration in your agent settings profile. When enabled, Cortex XDR
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.
5. (Optional) Manage Legacy Host Firewall Rules.
Manage Host Firewall Rules created on macOS 10 and Cortex XDR agent 7.5 and earlier.
a. Enable Manage Host Firewall to allow Cortex XDR 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:
Displayed in the footer
Page 213 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR 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.
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 the policies in the desired order of execution.
4. Save the policy hierarchy.
After the policy is saved and applied to the agents, Cortex XDR 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 XDR 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 XDR
host firewall blocks only incoming communications on Mac endpoints, still allowing outbound communication initiated from the endpoint.
12.2.1.6.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 XDR provides full visibility into encrypted Windows and Mac endpoints that were encrypted using BitLocker and FileVault, respectively. Additionally, you
can apply Cortex XDR 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:
Displayed in the footer
Page 214 of 952
Cortex XDR Documentation
Displayed in the header
Requirement / Limitation Windows Mac
Endpoint Prerequisites 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 You can enforce XDR disk encryption
rules only on the Operating System volume. policy rules only on the Operating System
volume.
The Cortex XDR Disk Encryption profile for
Mac can encrypt the endpoint disk,
however, it cannot decrypt it. After you
disable the Cortex XDR 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
XDR if the endpoint was encrypted through
Make sure your Cortex XDR disk Cortex XDR, and up to one hour if it was
encryption policy does not conflict with the encrypted through another MDM.
GPO configuration to Choose drive
encryption method and cipher strength. In line with the operating system
requirements, the Cortex XDR 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 Networksrecommends that you
do not apply an encryption enforcement
from another MDM on the endpoint
together with the Cortex XDR encryption
profile.
Follow this high-level workflow to deploy the Cortex XDR disk encryption in your network:
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.
Displayed in the footer
Page 215 of 952
Cortex XDR Documentation
Displayed in the header
Field Description
Encryption Status The endpoint encryption status can be:
Applying Policy: Indicates that the Cortex XDR 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 XDR disk encryption policy.
Not Compliant: Indicates that the Cortex XDR agent encryption
status on the endpoint is not compliant with the Cortex XDR 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 XDR.
Unmanaged: Indicates that the endpoint encryption is not managed
by Cortex XDR.
Endpoint ID Unique ID assigned by Cortex XDR that identifies the endpoint.
Endpoint Name Hostname of the endpoint.
Endpoint Status Status of the endpoint, for more information, see Manage endpoints.
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 information,
see Manage endpoints.
MAC Address MAC address of the endpoint.
Operating System 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 XDR 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.
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.
Displayed in the footer
Page 216 of 952
Cortex XDR Documentation
Displayed in the header
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.
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 XDR 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
XDR 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 XDR 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.
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.
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 XDR 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.
Displayed in the footer
Page 217 of 952
Cortex XDR Documentation
Displayed in the header
12.2.1.6.4 | Host Inventory
Abstract
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 XDR 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 XDR 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 XDR 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 – ✓ –
Groups ✓ ✓ ✓
Mounts – ✓ ✓
Services ✓ – –
Shares ✓ ✓ ✓
Displayed in the footer
Page 218 of 952
Cortex XDR Documentation
Displayed in the header
Entity Windows Mac Linux
System Information ✓ ✓ ✓
Users ✓ ✓ –
Users to Groups ✓ ✓ ✓
For each entity, Cortex XDR 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 an 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 XDR 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 XDR 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 XDR 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 XDR 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
Disks Details about the disk volumes that exist on an endpoint.
For each disk that exists on an endpoint, Cortex XDR lists details such as the drive type, name, file system, free
space, and total size.
Displayed in the footer
Page 219 of 952
Cortex XDR Documentation
Displayed in the header
Data Description
Drivers Details about all the drivers installed on an endpoint.
For each driver, Cortex XDR lists all the following details:
Information about the driver, such as the driver name, type, and path.
Listing details about the driver runtime configuration:
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 XDR 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 XDR 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 XDR 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 XDR 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 XDR 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
System Information General system information about an endpoint.
For each endpoint, Cortex XDR 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
Displayed in the footer
Page 220 of 952
Cortex XDR Documentation
Displayed in the header
Data Description
Users List of users whose credentials are stored on the endpoint.
For each user, Cortex XDR 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.
Cortex XDR includes only the first 10,000 results per endpoint.
Cortex XDR 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 XDR includes this user in the user-to-group mapping, but does not include it
in the user's insights view.
12.2.1.6.5 | Vulnerability Assessment
Abstract
Perform a vulnerability assessment of all endpoints in your network using Cortex XDR. This includes CVE, endpoint, and application analysis.
Cortex XDR 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 XDR retrieves the latest data for each Common Vulnerabilities and Exposures (CVE)
from the NIST National Vulnerability Database, including CVE severity and metrics.
The following are prerequisites for Cortex XDR to perform a vulnerability assessment of your endpoints.
Requirement Description
Licenses and Add-ons Cortex XDR Pro per Endpoint license.
Host Insights Add-on.
Displayed in the footer
Page 221 of 952
Cortex XDR Documentation
Displayed in the header
Requirement Description
Supported Platforms Windows
Cortex XDR agent 7.1 or a later release.
Cortex XDR lists only CVEs relating to the operating system, and not CVEs relating
to applications provided by other vendors.
Cortex XDR retrieves the latest data for each CVE from the NIST National
Vulnerability Database as well as from the Microsoft Security Response Center
(MSRC).
Cortex XDR 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 XDR cannot guarantee an accurate
CVE assessment.
Cortex XDR 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 XDR 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 XDR collects only the applications list from MacOS without CVE calculation.
If Cortex XDR 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 XDR 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 XDR as the Enhanced Vulnerability Assessment engine is
initialized.
The following are prerequisites for Cortex XDR to perform an Enhanced Vulnerability Assessment of your endpoints.
Requirement Description
Licenses and Add-ons Cortex XDR Pro per Endpoint license.
Host Insights Add-on.
Displayed in the footer
Page 222 of 952
Cortex XDR Documentation
Displayed in the header
Requirement Description
Supported Platforms Windows
Cortex XDR agent 8.3 or a later release.
Cortex XDR 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 XDR 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 XDR 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 XDR and view all the endpoints and
applications in your environment that are impacted by the CVE. Cortex XDR 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 XDR 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.
You can click each individual CVE to view in-depth details about it on a
panel that appears on the right.
Displayed in the footer
Page 223 of 952
Cortex XDR Documentation
Displayed in the header
Value Description
Description The general NIST description of the CVE.
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 XDR 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.
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 XDR 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 XDR that identifies the endpoint.
Endpoint name Hostname of the endpoint.
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 XDR.
MAC address The MAC address associated with the endpoint.
Displayed in the footer
Page 224 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR 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, and version, of applications on the endpoint. If an installed application has known vulnerabilities, Cortex XDR 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 XDR agent to communicate only with Cortex XDR .
(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 XDR 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 XDR within 24 hours. Alternatively, you can re-scan the endpoint to retrieve the most updated list.
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 XDR 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.2.1.7 | Set a Cortex XDR agent Critical Environment version
Abstract
Set the Cortex XDR agent as a Critical Environment (CE) version.
After you install the Cortex XDR agent and the agent registers with Cortex XDR, you can set endpoints to run with a Cortex XDR agent Critical Environment (CE)
version.
CE versions are designed for sensitive and highly regulated environments. These versions receive full content update coverage and contain the same feature
set as the standard line it is based on. Please note, that some bug fixes, introducing higher stability risk, may not be incorporated into the maintenance
releases of these lines. Support is provided for CE versions for 24 months, while support for standard versions is provided for 9 months.
To ensure the stability of the line, CE versions maintenance release cadence is longer than in the standard line, we recommend that deployment is adjusted
accordingly.
Setting an endpoint with a CE agent version requires you to define your agent configurations which then allows you to do the following:
Create a CE agent installation package
Define the upgrade and auto-upgrade in the Agent Settings Profile
Displayed in the footer
Page 225 of 952
Cortex XDR Documentation
Displayed in the header
1. Define your agent configuration.
a. Navigate to Settings → Configurations → Agent Configurations → Critical Environment Versions.
b. Click Enable Critical Environment Versions to be Created and Installed in the Tenant.
2. Track endpoints with CE Agent versions.
Navigate to Endpoints → All Endpoints table and locate the Version Type field to view whether the endpoint is defined as a Standard or Critical
Environment agent.
12.2.1.8 | 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.
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 XDR server through a wide-system proxy you can 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 XDR.
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 XDR server through the app-specific proxies, the agent resumes communication through the system-wide proxy
defined on the endpoint. If that also fails, the agent directly resumes communication with Cortex XDR.
How to set an agent proxy in Cortex XDR
1. From Cortex XDR, select Endpoints → All Endpoints.
2. If needed, filter the list of endpoints.
3. Select the row of the endpoint for which you want to set a proxy.
4. Right-click the endpoint and select Endpoint Control → Set Agent Proxy.
5. 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 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.
6. Click Set.
7. 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 XDR
server through the system-wide proxy. If a system-wide proxy is not defined, the agent resumes direct communication with the Cortex XDR server. If
neither a system-wide proxy nor direct communication exists, the agent will disconnect from Cortex XDR.
12.2.1.9 | Pairing Prisma Cloud Compute with Cortex XDR
Abstract
Learn how to pair Prisma Cloud Compute with Cortex XDR for use with the Cortex XDR Agent for Cloud.
Cortex XDR and Prisma Cloud Compute are offering a unified cloud security agent for Windows and Linux. The Cortex XDR Agent for Cloud provides end to
end prevention and vulnerability coverage on Linux cloud environments.
Cortex XDR Agent for Cloud has a single management server that is based on a Cortex XDR tenant. Policy management, data, and alerts are first managed
between the Cortex XDR tenant and Cortex XDR Agent for Cloud, and then runtime protection and vulnerability coverage can be provided on Prisma Cloud
Compute and Cortex XDR.
Prerequisites
To enable the capabilities of Cortex XDR Agent for Cloud, the Prisma Cloud Compute tenant must be paired with an existing Cortex XDR tenant. Pairing is one
to one, with the two tenants being in the same region.
Pairing Prisma Cloud Compute to Cortex XDR can only be done when both Cortex XDR and Prisma Cloud Compute tenants are already active.
Displayed in the footer
Page 226 of 952
Cortex XDR Documentation
Displayed in the header
Requirements for Windows Hosts
The following are required in order for Windows agents to be visible in the Prisma Cloud Compute tenant:
The tenant must have the XDR Cloud per Host license and the Host insights add-on.
In the XDR Pro Endpoints section of the Agent Settings profile, enable the XDR Pro Endpoints Capabilities and then enable the Host Insights capabilities.
Vulnerabilities are based on the Cortex vulnerability assessment engine, which may be different than Prisma vulnerability scanning.
Cloud metadata information is not reported for results collected by the Cortex XDR agent running on a Windows endpoint and Compliance Assessment is not
supported by the Cortex XDR agent for Cloud.
Pair Prisma Cloud Compute with Cortex XDR
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 XDR.
2. Paste the pairing key in Cortex XDR.
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 XDR and Prisma Cloud Compute tenants are paired.
A Successfully paired with <Prisma Tenant URL> message will be shown.
Unpair Prisma Cloud Compute from Cortex XDR
1. The two paired tenants can be unpaired from either console.
In Cortex XDR, 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 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 XDR and Prisma Cloud Compute tenants are unpaired.
When unpairing, the Active Vulnerability Analysis Module under the Agent Settings profile is reset to Disable mode.
If Prisma Cloud and Cortex XDR are to be paired again, the Active Vulnerability Analysis Module must be enabled manually.
12.2.2 | Manage endpoint protection
Abstract
The Cortex XDR agent is installed on each of your endpoints, and you can manage the agents using Cortex XDR.
The Cortex XDR agent is installed on each of your endpoints, and you can perform various management activities on the agents, using Cortex XDR.
12.2.2.1 | 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.
The following explanations use Windows operating system installation parameters and Cytool argument examples.
Create an endpoint tag
An endpoint tag can be created during installation of the Cortex XDR agent.
An endpoint tag can be created after installation either from the Cortex XDR agent or from the Cortex XDR management console.
Displayed in the footer
Page 227 of 952
Cortex XDR Documentation
Displayed in the header
Add an endpoint tag as an installation parameter of the Cortex XDR agent's installer
Installer parameter: run msiexec /i ... ENDPOINT_TAGS="Name1, Name 2, Name3".
Cytool argument: cytool endpoint_tags add "tag1 [,tag2,...,tagN]".
Tag names are case sensitive.
In 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 the Cortex XDR 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]".
Tag names are case sensitive and can contain spaces.
From the Cortex XDR 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.
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.
When SBAC is enabled, assigning tags may impact user permissions.
5. Save the tag names you selected.
Remove an endpoint tag
Depending on where you created your tag, Server or Agent, you can choose to edit or remove the tags.
If you remove the tag and there are assigned users or user groups with scope settings, this can impact user permissions in the system.
From the Cortex XDR 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 XDR 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 that you removed.
Track your endpoint tags
From the Cortex XDR agent
1. Navigate to the Cytool folder location and open the CLI as an administrator.
2. Cytool Argument: cytool endpoint_tags list.
From the Cortex XDR 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.
12.2.2.2 | Set an alias for an endpoint
Abstract
Displayed in the footer
Page 228 of 952
Cortex XDR Documentation
Displayed in the header
Configure an alias to identify one or more endpoints by a name that is different from the endpoint hostname.
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 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.
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 click Update.
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 Cortex XDR.
12.2.2.3 | Manage endpoint prevention profiles
Abstract
You can manage the endpoint prevention profiles of your Cortex XDR agent endpoints in various ways, including editing, duplicating, and populating endpoint
prevention policy rules.
After you create and customize your endpoint prevention profiles, you can manage them from the Prevention Profiles page as needed.
View the prevention policy rules that use a specific prevention profile
Before you modify or delete a profile, you can check which policy rules, if any, use the profile.
From Endpoints → Policy Management → Prevention → Profiles, right-click the profile and select View policy Rules.
Cortex XDR opens the Prevention Policy Rules page on a new tab. This page is filtered, and only displays the rules that use the profile that you selected.
Edit, export, duplicate, or delete an endpoint prevention profile
Edit a profile:
1. From Endpoints → Policy Management → Prevention → Profiles, right-click the profile and select Edit.
2. Make your changes, and then click Save.
Export a profile:
1. From Endpoints → Policy Management → Prevention → Profiles, right-click the profile and select Export Profile.
2. Click Export. The profile is downloaded to your computer.
Duplicate a profile:
1. From Endpoints → Policy Management → Prevention → Profiles, right-click the prevention profile and select Save as New. A new profile is displayed,
containing the values from the profile that you selected.
2. Edit the profile name and description, edit any values that you want to change, and then click Create.
3. Populate a new prevention policy rule with your new profile.
Delete a profile:
1. If necessary, delete or detach any policy rules that use the profile before attempting to delete it.
2. From Endpoints → Policy Management → Prevention → Profiles, locate the profile that you want to remove. The profile's Usage Count cell must have a 0
(zero) value.
3. Right-click the prevention profile and select Delete.
4. To confirm the deletion, click Yes.
Populate a new prevention policy rule with a prevention profile
1. From Endpoints → Policy Management → Prevention → Profiles, right-click the profile and select Create a new policy rule using this profile.
Cortex XDR automatically populates the Platform selection based on your profile configuration, and assigns the profile based on the profile type.
Displayed in the footer
Page 229 of 952
Cortex XDR Documentation
Displayed in the header
2. For Policy Name, enter a meaningful name, and optionally, add a description for the policy rule.
3. Assign any additional profiles that you want to apply to your policy rule, and click Next. A list of endpoints is displayed.
4. Select the target endpoints for the policy rule, or use the filters to define criteria for the policy rule to apply, and then click Next.
5. Review the policy rule summary, and then click Done.
View information about your endpoint prevention profiles
The following table displays the fields that are available on the Prevention Profiles page, in alphabetical order. The table includes both default fields and
additional fields that are available in the column manager. To view this page, go to Endpoints → Policy Management → Prevention → Profiles.
Field Description
Associated Targets The endpoints or endpoint groups to which the profile is assigned
Created By The administrator who created the prevention profile
Created Time The date and time at which the prevention profile was created
Description An optional description entered by an administrator to describe the prevention profile
Modification Time The date and time at which the prevention profile was modified
Modified By The administrator who modified the prevention profile
Name The prevention profile name
Profile ID The ID assigned to to the profile by Cortex XDR
Summary Summary of prevention profile configuration
Type The prevention profile type, such as Malware or Agent Settings
Usage Count The number of policy rules that use the profile. If you want to delete a profile, ensure that this cell
displays "0".
12.2.2.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 XDR, you can upgrade the Cortex XDR agent software using a method supported by
the endpoint platform:
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.
iOS: Upgrade the app directly from the Apple App Store (agent version 8.6 or later), or push the app to your endpoints from an endpoint management
system.
Windows, Mac, or Linux: Create new installation packages and push the Cortex XDR agent package to up to 5,000 endpoints from Cortex XDR.
The following list includes important points to take into account when upgrading the Cortex XDR agent:
Displayed in the footer
Page 230 of 952
Cortex XDR Documentation
Displayed in the header
Review the recommended guidelines for keeping Cortex XDR agents and content updated. Read more here.
You cannot upgrade the Cortex XDR 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.
You cannot enable auto-upgrade for Mobile, VDI, and TS installations.
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 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.
Upgrades are supported using actions that you can initiate from the Action Center or from All Endpoints as described in this workflow.
How to upgrade Cortex XDR agent software
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.
You can install the Cortex XDR agent on Linux endpoints using a package manager. If you do not want to use the package manager, clear the option
Upgrade to installation by package manager.
When you upgrade an agent on a Linux endpoint that is not using a package manager, Cortex XDR upgrades the installation process by default
according to the endpoint Linux distribution.
The Cortex XDR agent keeps the name of the original installation package after every upgrade.
5. Upgrade.
Cortex XDR 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).
Custom dashboards that include upgrade status widgets, and the All Endpoints page display upgrade status.
During the upgrade process, the endpoint operating system might request a reboot. However, you do not have to perform the reboot for the Cortex
XDR agent upgrade process to complete it successfully.
After you upgrade on an endpoint with Cortex XDR Device Control rules, you need to reboot the endpoint for the rules to take effect.
12.2.2.5 | Restart agent
Abstract
Learn how to restart the agent on the endpoint.
You can restart an agent from the Cortex XDR tenant. 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 XDR, navigate to Endpoints → All Endpoints. Select the relevant endpoint 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.
Displayed in the footer
Page 231 of 952
Cortex XDR Documentation
Displayed in the header
12.2.2.6 | Uninstall the Cortex XDR agent
Abstract
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 XDR tenant 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 endpoint 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 XDR as Endpoint Name - N/A (Uninstalled).
Data associated with the deleted endpoint is displayed in the Action Center tables and the Causality View for the standard 90-day retention period.
Alerts that already include the endpoint data at the time of the alert creation are not affected.
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 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.
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 XDR.
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.
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 XDR.
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.
12.2.2.7 | Delete Cortex XDR agents
Abstract
Delete endpoints from Cortex XDR tenant views.
If you have an endpoint that you no longer want to track through Cortex XDR, for example, if the endpoint disconnected from Cortex XDR, or an endpoint
where the Cortex XDR agent was uninstalled, you can delete the endpoint from the Cortex XDR tenant views. Deleting an endpoint triggers the following
lifespan flow:
Displayed in the footer
Page 232 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR 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-day retention period.
Alerts that already include the endpoint data at the time of alert creation are not affected.
Additionally, Cortex XDR 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.
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.
12.2.2.8 | Manage agent tokens
Abstract
Manage tokens per agent to retrieve the password used to run functions at the agent.
You can now run some of the agent functions that require administrative passwords using a unique token shared between Cortex XDR and Cortex XDR agent.
Two types of tokens can be set:
Rolling token: Automatically generated per endpoint every fourteen days by the system and then sent to the relevant agent
Temporary token: Set a temporary token that is valid anywhere from one to twenty-one days.
Agent token is supported from Cortex XDR server version 3.3 and Cortex XDR agent version 7.7.1. It is only supported for Windows and Mac.
1. View agent password.
You can view the password of the selected agent. Whether the password is from a rolling token or a temporary token is indicated in the dialog.
a. Select Endpoints → All Endpoints → Endpoint Control → View Token.
b. Click the copy button to copy the password displayed and then click Ok.
You can now use the password to run functions at the agent.
2. Add a temporary token.
You can generate a temporary token for any of the agents for a specified number of days between one to twenty-one days. If the agent is disconnected,
it gets the temporary token when the agent connects.
You can select a single or many endpoints at once to add a temporary token.
a. Select Endpoints → All Endpoints → Endpoint Control → Set Temporary Token.
b. In the Token Expiration field, add the number of days for which to generate a temporary token for the agent and then click the Add Token
Expiration blue arrow.
c. Click the copy button to copy the password displayed and then click Create to begin generating the token.
d. Go to the Action Center to view which agent received the temporary token.
You can now use the password to run functions at the agent.
3. Retrieve the token using the token hash from the endpoint.
If the endpoint is disconnected from the server at the point the rolling token was updated, it won’t be possible to run agent functions with the updated
token from the server. You can still retrieve the password to run functions at the agent.
a. From the agent, run the cytool.exe to run the token query command. This command displays the current token of the endpoint.
b. Copy the token from the command line interface of the agent.
c. In the server, at the top of the page, click Retrieve Token.
Displayed in the footer
Page 233 of 952
Cortex XDR Documentation
Displayed in the header
d. In the Retrieve Token dialog box, in the Hash field, paste the token that you copied from the endpoint.
e. Click the copy button to copy the password displayed and then click Ok.
You can now use the password to run functions at the agent.
12.2.2.9 | 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 Cortex XDR agent version 7.8 and later, 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 XDR 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.
a. At the top of the page, click Tokens and Passwords and select Retrieve Support File Password.
b. In the Retrieve Support File Password dialog box, 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.
c. 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.
a. Right-click the relevant action of action type Support File Retrieval and select Additional Data.
b. Right-click the action and select Retrieve Support File Password.
c. In the Retrieve Support File Password dialog box, in the Encrypted Password field, paste the token that you copied from the metadata file located
in the download file.
d. Click the copy button to copy the password displayed and then click Ok. Use the password to unzip the TSF file.
12.2.2.10 | Move agents between managing servers
Abstract
You can move Cortex XDR agents to other Cortex XDR managing servers.
You can move existing agents between Cortex XDR managing servers directly from Cortex XDR. 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 before making changes:
Ensure you are running a Cortex XDR agent 7.2 or a later release.
Endpoint type is not Kubernetes Node.
Installation type is not VDI.
Ensure you have administrator privileges for Cortex XDR 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.
Cortex XDR does not support moving agents between FedRamp and commercial tenants.
How to move Cortex XDR agents to other managing servers
1. Obtain an installation package ID from the target managing server.
a. Log in to Cortex XDR 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.
Displayed in the footer
Page 234 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR 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.
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.
12.2.2.11 | Clear agent database
Abstract
Learn how to 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.
Clearing the agent database is supported on all platforms with Cortex XDR agent version 7.9 or later 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.
Displayed in the footer
Page 235 of 952
Cortex XDR Documentation
Displayed in the header
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.
You can only right-click to cancel the clear agent database for actions with a pending status.
12.2.2.12 | Send push notifications to iOS
Abstract
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 Cortex XDR.
1. Navigate to Endpoints → All Endpoints and locate the required iOS device or devices.
2. Right-click and select Endpoint Control → Send Push Notification.
3. 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.
12.2.2.13 | Monitor agent operational status
Abstract
You can view the operational status of any Cortex XDR agent that you manage.
From the Cortex XDR 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 XDR 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 XDR.
Partially protected: Indicates that the XDR agent reported one or more exceptions to Cortex XDR.
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.
Displayed in the footer
Page 236 of 952
Cortex XDR Documentation
Displayed in the header
Status Description
Protected (Windows, Mac, and Linux) Indicates all protection modules are running as configured
on the endpoint.
Partially protected Windows
XDR data collection is not running, or not set
Behavioral threat protection is not running
Malware protection is not running
Exploit protection is not running
Mac
Operating system adaptive mode*
XDR Data Collection is not running, or not set
Behavioral threat protection is not running
Malware protection is not running
Exploit protection is not running
Linux
Kernel module not loaded**
Kernel module compatible but not loaded**
Kernel version not compatible**
XDR Data Collection is not running, or not set
Behavioral threat protection is not running
Anti-malware flow is asynchronous
Malware protection is not running
Exploit protection is not running
Any of the listed items could lead to a partially protected state. Refer to the
Cortex XDR 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
Displayed in the footer
Page 237 of 952
Cortex XDR Documentation
Displayed in the header
Status Description
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
12.2.2.14 | Monitor agent activity
Abstract
You can monitor the activity of any Cortex XDR Broker VM that you manage.
Viewing agent audit logs requires either a Cortex XDR Prevent or Cortex XDR Pro per Endpoint license.
The Cortex XDR agent logs entries for events that are monitored by the Cortex XDR agent, and hourly reports the logs back to Cortex XDR. Cortex XDR 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 XDR 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 XDR.
Result The result of the action (Success, Fail, or N/A)
Displayed in the footer
Page 238 of 952
Cortex XDR Documentation
Displayed in the header
Field Description
Severity Severity associated with the log:
Critical
High
Medium
Low
Informational
Displayed in the footer
Page 239 of 952
Cortex XDR Documentation
Displayed in the header
Field Description
Type and Sub-Type Additional classification of agent log (Type and Sub-Type):
Displayed in the footer
Page 240 of 952
Cortex XDR Documentation
Displayed in the header
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:
Displayed in the footer
Page 241 of 952
Cortex XDR Documentation
Displayed in the header
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.
12.2.2.15 | 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 XDR 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
Displayed in the footer
Page 242 of 952
Cortex XDR Documentation
Displayed in the header
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.
13 | Detect threats and analyze data
13.1 | Detection rules
Abstract
Cortex XDR uses rules to detect threats and raise alerts.
Adding threat detection rules requires a Cortex XDR Pro license.
Cortex XDR uses rules to detect the threats in your network and to raise alerts. You can add specific detection rules for which you want Cortex XDR to raise
alerts. The following are the different types of rules available:
Indicators of compromise (IOCs): IOCs are used to alert for known artifacts that are considered malicious or suspicious. IOCs are static, simple, and
based on the detection of criteria such as SHA256 hashes, IP addresses and domains, file names, and paths. You create IOC rules based on
information you gather from various threat-intelligence feeds or as a result of an investigation within Cortex XDR. For example, if you find out that a
certain ransomware uses a certain file hash, you can add the file hash as an IOC and get an alert if it is detected.
Behavioral indicators of compromise (BIOCs): BIOCs detect suspicious behavior. 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 XDR Analytics, Cortex XDR can use
Analytics BIOCs (ABIOCs) to establish baseline behavior and detect any deviation from this behavior.
Correlation Rules: Correlation rules help you analyze the relationship between multiple events from multiple sources by using the Cortex Query Language
(XQL) based engine.
13.1.1 | What's an IOC?
Abstract
Indicators of compromise (IOCs) alert you about known malicious objects on your endpoints.
Managing IOCs requires a Cortex XDR Pro license.
Indicators of compromise (IOCs) enable Cortex XDR to trigger alerts about known malicious objects on endpoints across the organization. You can load
collections of IOCs from threat-intelligence sources into the Cortex XDR app or define them individually.
Cortex XDR 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 load or define IOCs, the tenant checks for matches in the xdr_data dataset that contains all the information collected about the endpoints and the
network. The app looks for IOC matches in all data collected in the past and continues to evaluate any new data it receives in the future.
Alerts for IOCs are identified by the source type of the IOC.
13.1.1.1 | IOC rule details
Abstract
Manage all indicators of compromise (IOCs) configured from or uploaded to Cortex XDR.
Displayed in the footer
Page 243 of 952
Cortex XDR Documentation
Displayed in the header
Managing IOCs requires a Cortex XDR Pro license.
In the Detection Rules → IOC page, you can view all indicators of compromise (IOCs) configured from or uploaded to Cortex XDR. To view the number of IOC
rules, 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 ALERTS The number of alerts triggered by this indicator.
BACKWARDS SCAN STATUS Status of the Cortex XDR search for the first 10,000 matches when the IOC rule was
created or edited. Status can be:
Done
Failed
Pending
Queued
BACKWARDS SCAN TIMESTAMP Timestamp of the Cortex XDR search for the first 10,000 matches in your Cortex XDR
when the IOC rule was created or edited.
BACKWARDS SCAN RETRIES Number of times Cortex XDR searched for the first 10,000 matches in your Cortex XDR
when the IOC rule was created or edited.
CLASS The IOC's class. For example, 'Malware'.
Field cannot exceed 36 characters.
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.
Displayed in the footer
Page 244 of 952
Cortex XDR Documentation
Displayed in the header
Field Description
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 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.
13.1.1.2 | Create an IOC rule
Abstract
From the Cortex XDR management console, you can upload or configure indicator of compromise (IOC) rules criteria.
Adding IOC rules requires a Cortex XDR Pro license.
Create new indicator of compromise (IOC) rules and optionally define rule expiration for all IOC rules. You can create an IOC ruke either by configuring a single
one or by uploading a file that contains multiple IOCs.
To ensure your IOC rules raise alerts efficiently and do not overcrowd your Alerts table, Cortex XDR automatically does the following:
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. In Detection Rules → IOC, select + Add IOC.
2. Configure the IOC criteria.
Configure a single IOC
After investigating a threat, if you identify a malicious artifact, you can create an alert for the Single IOC right away.
1. Configure the INDICATOR value on which you want to match.
2. Configure the IOC TYPE. Options are Full Path, File Name, Domain, Destination IP, and MD5 or SHA256 Hash.
3. Configure the SEVERITY you want to associate with the alert for the IOC.
4. (Optional) Enter a comment that describes the IOC.
5. (Optional) Configure the IOC's REPUTATION and its RELIABILITY.
6. (Optional) Configure the EXPIRATION settings for this IOC. Default, Specific Expiration Date, No Expiration.
7. Click Save.
Upload multiple IOCs
If you want to match multiple indicators, you can upload the criteria in a CSV file. You can upload IOCs using REST APIs in either CSV or JSON format.
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 XDR accepts, you can download the example file.
Displayed in the footer
Page 245 of 952
Cortex XDR Documentation
Displayed in the header
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 for the file.
Cortex XDR supports a file with multiple IOCs in a pre-configured format. For help in determining the format syntax, Cortex XDR provides an
example text file that you can download.
3. Configure the SEVERITY you want to associate with the 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 and its RELIABILITY.
6. (Optional) Enter an EXPIRATION for the IOC. Default, Specific Expiration Date, No Expiration.
7. Click Upload.
3. (Optional) Define any expiration criteria for your IOC rules.
You can also configure additional expiration criteria per IOC type to apply to all IOC rules of that type. 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 XDR 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.
13.1.2 | What's a BIOC?
Abstract
Behavioral indicators of compromise (BIOCs) alert you to respond to potentially compromising behaviors.
Adding IOCs requires a Cortex XDR Pro license.
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 related to processes, registry, files, and network activity.
To benefit from the latest threat research, the Cortex XDR tenant automatically receives pre-configured rules from Palo Alto Networks. These global rules are
delivered to all tenants with content updates. When 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.
When there is a match on a BIOC rule, Cortex XDR 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 trigger behavioral threat prevention alerts based on your custom prevention rules in addition to the BIOC detection alerts.
13.1.2.1 | BIOC rule details
Abstract
From the Cortex XDR management console, you can define your own rules based on behavior with the behavioral indicator of compromise (BIOC) rules.
Managing BIOCs requires a Cortex XDR Pro license.
Manage your behavioral indicator of compromise (BIOC) rules in Detection Rules → BIOC.
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).
If you have Cortex XDR Analytics enabled, you can also view Analytics BIOCs (ABIOCs) on a separate page. To access this page, click Analytics BIOC Rules
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. 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.
Displayed in the footer
Page 246 of 952
Cortex XDR Documentation
Displayed in the header
Field Description
# OF ALERTS The number of alerts triggered by this rule.
BACKWARDS SCAN STATUS Status of the Cortex XDR 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 XDR search for the first 10,000 matches in your Cortex
XDR when the BIOC rule was created or edited.
BACKWARDS SCAN RETRIES Number of times Cortex XDR searched for the first 10,000 matches in your
Cortex XDR 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.
Displayed in the footer
Page 247 of 952
Cortex XDR Documentation
Displayed in the header
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 rule 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.
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 XDR requires in order to
activate the rule.
Displayed in the footer
Page 248 of 952
Cortex XDR Documentation
Displayed in the header
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.
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.
13.1.2.2 | Create a BIOC rule
Abstract
You can configure rules for behavioral indicators of compromise (BIOCs) to trigger an alert on an identified threat.
Adding BIOC rules requires a Cortex XDR Pro license.
When you identify a threat and its characteristics, you can configure rules for behavioral indicators of compromise (BIOCs) for this threat.
You can create a BIOC rule either by configuring a single one or by uploading a file that contains multiple BIOCs.
After you create a BIOC rule, Cortex XDR searches for the first 10,000 matches in your tenant and triggers an alert if a match is detected. After the initial scan,
Cortex XDR triggers alerts every time a new match is detected.
You can also use BIOC rules to create prevention rules that terminate the causality chain of a malicious process and trigger Cortex XDR Agent behavioral
prevention type alerts.
To ensure your BIOC rules trigger alerts efficiently and do not overcrowd your Alerts table, Cortex XDR automatically does the following:
Disables BIOC rules that reach 5000 or more hits over a 24-hour period.
Creates a rule exception based on the PROCESS SHA256 field for BIOC rules that hit more than 100 endpoints over a 72 hour period.
Create a BIOC 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.
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.
Displayed in the footer
Page 249 of 952
Cortex XDR Documentation
Displayed in the header
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.
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 XDR , select Detection Rules → BIOC.
2. Select + Add BIOC.
3. Configure your BIOC criteria using one of the following methods.
Build the BIOC 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. It is highly recommended that you test the behavior of a new
or edited BIOC rule before you save it.
When you test the rule, Cortex XDR immediately searches for rule matches across all your Cortex XDR tenant data. The results are displayed in the
Query Results tab underneath the XQL query field. Adjust any rule definition as needed.
To demonstrate the expected behavior of the rule before you save it, Cortex XDR 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.
1. Select an 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. It is highly recommended that you test the behavior of a
new or edited BIOC rule before you save it.
When you test the rule, Cortex XDR immediately searches for rule matches across all your Cortex XDR Cortex XDR tenant data. Adjust any rule
definition as needed.
To demonstrate the expected behavior of the rule before you save it, Cortex XDR 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 the BIOC rule.
4. Define the following parameters.
a. Name—Specify a description or leave the default name which is automatically populated using the format XQL-BIOC-<rule number>.
b. Type—Select a rule TYPE that describes the activity.
Displayed in the footer
Page 250 of 952
Cortex XDR Documentation
Displayed in the header
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.
Import multiple BIOC rules
To match multiple indicators, you can upload the criteria in a CSV file. You can upload BIOCs using REST APIs in either CSV or JSON format. Your file can be a
list of BIOCs from external feeds or a file that you previously exported from Cortex XDR. The export/import capability is useful for rapid copying of BIOCs
across different Cortex XDR instances.
Upload a file, one BIOC per line, that contains up to 20,000 BIOCs. For example, you can upload multiple file paths and MD5 hashes for a BIOC rule. To help
you format the upload file in the syntax that Cortex XDR accepts, you can download the example file.
You can only import files that were exported from Cortex XDR. You can not edit an exported file.
1. From Cortex XDR, select 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 XDR 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.
Configure a custom prevention rule
Custom prevention rules are supported on Cortex XDR 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 Security Profile and trigger Cortex XDR 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
XDR agent:
Blocks a process at the endpoint level according to the defined rule properties.
Triggers 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 scratch or a Cortex XDR 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.
Displayed in the footer
Page 251 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR 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.
You can only add to existing profiles you created, Cortex XDR 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.
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.
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 triggered the prevention alert.
13.1.2.3 | Manage Global BIOC Rules
Abstract
Update and copy BIOC rules, and add rule exceptions in Cortex XDR.
Global BIOC rules are detection rules created by Cortex and distributed to the tenants. Cortex XDR checks automatically for the latest update of global BIOC
rules and applies them. If there are no new global BIOC rules, Cortex XDR 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.
To see which rules are pushed by Palo Alto Networks, display the optional Source field.
Retrieve the latest global BIOC rules
1. Navigate to Detection Rules → BIOC.
2. To view the content details, hover over the status Content up to date, to show the global rules version number and the date the global rules were
checked.
The content status displays the date when the content was last updated, either automatically or manually by an administrator.
3. If the status displays Could not check update, click the status to check for updates manually.
Displayed in the footer
Page 252 of 952
Cortex XDR Documentation
Displayed in the header
The last updated date changes when the download is successful.
Copy global BIOC rules
You cannot directly modify a global rule, but you can copy global rules as a template to create new rules.
1. Locate a Palo Alto Networks Source type rule, right-click and select Save as New.
2. Review and modify the BIOC properties.
3. 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.
Add an exception to global BIOC rules
You cannot edit global rules, but you can add exceptions to the rule. For more information about rule exceptions, see Add a rule exception.
13.1.3 | What's a correlation rule?
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.
Managing correlation rules requires a Cortex XDR Pro license.
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. 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.
After you configure your correlation rules, you can manage them in Detection Rules → Correlations, and view and analyze the generated alerts in Incidents and
the Alerts Table. In addition, alerts triggered by correlation rules are factored into the number of incidents displayed in the dashboards.
13.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.
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 manage all user-defined Correlation Rules from 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 manage existing rules using the right-click pivot menu. You can also import and export rules in JSON format, which can
help you to transfer your configurations between environments for onboarding, migration, backup, and sharing. You can bulk export and import multiple rules
at a time.
In addition, the Correlation Rules page enables you to easily identify and resolve correlation rules errors. The number of errors is indicated at the top of the
page in red 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>
Only an administrator can create and view queries built with an unknown dataset that currently does not exist in Cortex XDR .
A notification is also displayed in Cortex XDR to indicate these correlation rules errors.
Fields that are available for each correlation rule in alphabetical order
Certain fields are exposed and hidden by default. An asterisk (*) is beside every field that is exposed by default.
Displayed in the footer
Page 253 of 952
Cortex XDR Documentation
Displayed in the header
Field Description
# OF ALERTS* The number of alerts triggered by this rule.
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.
Displayed in the footer
Page 254 of 952
Cortex XDR Documentation
Displayed in the header
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>
Only an administrator can create and view queries built with an unknown
dataset that currently does not exist in Cortex XDR.
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.
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.
Displayed in the footer
Page 255 of 952
Cortex XDR Documentation
Displayed in the header
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.
13.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, or import a many correlation rules from a file.
Correlation rules require a Cortex XDR Pro license. 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 Detection Rules → Correlation Rules page or when building a query in XQL Search. You can also import a
number of correlation rules.
When setting up correlation rules, you have the following capabilities:
Displayed in the footer
Page 256 of 952
Cortex XDR Documentation
Displayed in the header
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, which includes any of the following:
Generate an alert: You can also define the alert settings, which include the Alerts Field Mapping for incident enrichment, Alert Severity, MITRE
Attack Tactics and Techniques, and other alert settings.
Save data to a dataset: Use this option to test and fine-tune new rules before initiating alerts and applying correlation of correlation use cases.
Add data to a lookup dataset
Remove data from a lookup dataset
To ensure your correlation rules raise alerts efficiently and do not overcrowd your Alerts table, Cortex XDR automatically disables correlation rules that reach
5000 or more hits over a 24-hour period.
Create a correlation rule from scratch
1. Open the New Correlation Rule editor.
You can do this in two ways:
From the Correlation Rules page.
1. Select 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.
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 XDR . 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.
The XQL features for call, top, config timeframe, and wildcards in datasets (dataset in (<dataset prefix>_*)) are currently not
supported in Correlation Rules. If you add them to the XQL definition, you will not be able to Create or Save the Correlation Rule.
The XQL features for transaction in datasets (dataset in (<dataset prefix>_*)) are currently not supported in Real Time correlation
rules.
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
time_frame_end() function, which returns the timestamp at the end of the time frame in which the rule is executed.
4. Configure the Timing settings.
Displayed in the footer
Page 257 of 952
Cortex XDR Documentation
Displayed in the header
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.
5. (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.
6. Configure the resulting Action for the Correlation Rule.
You can select one of the following resulting actions to occur, where the configuration settings change depending on your selection:
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.
Alert Settings
Displayed in the footer
Page 258 of 952
Cortex XDR Documentation
Displayed in the header
Alert Name: Specify a name. You can incorporate a variable based on a query output field in the format $fieldName.
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.
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.
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
There is no validation or auto complete for these parameters and the values can be null or empty. In these scenarios, Cortex XDR 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 XDR does not know in advance if the parameters exist or contain the correct values. As a result, Cortex XDR 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.
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.
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 XDR 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. Each preconfigured field that is
automatically mapped is clearly displayed. There are two ways to map the alert fields.
Displayed in the footer
Page 259 of 952
Cortex XDR Documentation
Displayed in the header
Use the preconfigured Cortex XDR alert field mapping
Select this option if you want Cortex XDR to automatically map the fields for you. This checkbox only displays when your Correlation Rule can be
configured to use Cortex XDR incident enrichment and then it is set as the default option. We recommend using this option whenever it is available
to you.
Manually map the alert fields by selecting the fields that you want to map. When you create the Correlation Rule, Cortex XDR 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.
In a case where Use the Cortex XDR default incident enrichment is not selected and you have not mapped any alert fields, the alert is dispatched
into a new incident.
Save to dataset
Use to save 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 XDR 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
Add to lookup
Use to add data to a specified lookup dataset. After selecting this option, perform the following:
1. In the Target Dataset field, select an existing lookup dataset to add the data.
After the dataset is chosen, a mapping table is displayed. A list of fields from the lookup schema are listed in the KEY column to allow you to map
fields from the query to an entry in the lookup.
2. In the VALUE column, map at least one field from the query to an entry in the lookup dataset (KEY column).
3. (optional) You can set a single field or multiple fields as unique by selecting the checkbox in the UNIQUE column. A unique field means these
fields are designated as a key to update existing entries as opposed to creating a new entry. If multiple fields are selected, these fields together
are used to identify existing entries. If several existing entries meet the condition, all these entries are updated. If no existing entries meet the
condition, the entry is added as a new one. If no field is marked as unique, records are added as new.
The maximum size of a lookup dataset is 50 MB. If the data exceeds this limit, the add to lookup action fails.
Remove from lookup
Removes data from a specified lookup dataset. Once this option is selected, perform the following:
1. In the Target Dataset field, select an existing lookup dataset to remove data.
After the dataset is chosen, a mapping table is displayed. A list of fields from the lookup schema are listed in the KEY column to allow you to map
fields from the query to an entry in the lookup.
2. In the VALUE column, map at least one field from the query to an entry in the lookup dataset (KEY column). All rows (lookup entries) matching
these field mapping values (filtering condition) will be deleted. If several existing entries meet the condition, all these entries are deleted. If no
existing entries meet the condition, no entries are deleted.
7. (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.
8. 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.
Import correlation rules from a file
You can import a number of correlation rules from a JSON file. This facilitates the sharing of correlation rules between tenants.
To import a file containing correlation rules, select Detection Rules → Correlations and click Import at the top right corner of the page.
Displayed in the footer
Page 260 of 952
Cortex XDR Documentation
Displayed in the header
13.1.3.3 | Manage correlation rules
Abstract
View and manage your correlation rules
View and manage your correlation rules in Detection Rules → Correlation Rules. To manage a Correlation Rule, right-click the Correlation Rule and select an
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
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.
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.
Execute Rule: Run the rule now without waiting for the scheduled time.
Preview Rule: View the rule before it's executed.
Save as new: Duplicate the correlation rule and save it as a new correlation rule.
Export: Select one or more rules to export to a JSON file.
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.
Delete the correlation rule.
Copy entire row to copy the text from all the fields in a row of a 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 select in the table.
On certain fields that are null, this option does not display.
Hide rows with ‘<Rule Description>’: Filter the correlation rules list to hide the correlation cules with a specific field value that you select in the table. On
certain fields that are null, this option does not display.
13.1.3.4 | Monitor correlation rules
Abstract
You can monitor your correlation executions with the correlations_auditing dataset.
This functionality is available in Cortex XDR Pro only.
Cortex XDR 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. .
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.
In the dataset, the Query start time and Query end time indicate the time frame 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.
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.
Displayed in the footer
Page 261 of 952
Cortex XDR Documentation
Displayed in the header
Field Description
_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 time frame.
Query end time The end time of the query time frame.
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.
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.
Displayed in the footer
Page 262 of 952
Cortex XDR Documentation
Displayed in the header
Field Description
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.
13.1.4 | Manage existing indicators
Abstract
Edit, export, copy, disable, or remove rules, and add rule exceptions for existing indicators in Cortex XDR.
After you create an indicator rule, you can take the following actions:
For Analytics BIOC rules, you can only disable and enable rules.
View alerts triggered by a rule
As your IOC and BIOC rules trigger alerts, Cortex XDR displays the total # OF ALERTS triggered by the rule in the the BIOC or IOC rules page. For rules with a
high, medium, or low severity that have triggered one or more alerts, you can quickly pivot to a filtered view of those alerts triggered 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 view 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.
Cortex XDR populates a query using the criteria of the BIOC rule.
3. Add or change the query criteria as required.
4. (Optional) Test your query to see the sample results.
5. If you are satisfied with the query, Save it.
For more information, see Edit and rerun queries in Query Center.
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.
Displayed in the footer
Page 263 of 952
Cortex XDR Documentation
Displayed in the header
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. 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.
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.
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. Navigate to 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.
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.
When a BIOC rule is disabled automatically by Cortex XDR, 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.
13.2 | Analytics
Abstract
Cortex XDR uses an Analytics engine to examine logs and data from your sensors.
Analytics uses the Analytics engine, sensors, and rules to keep your network safe.
Safeguarding your network requires a defense-in-depth strategy which utilizes current and patched software and hardware to keep unwanted users out of the
network. Most available strategies are designed to 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 intruders that
may have already penetrated your systems.
Cortex XDR 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.
13.2.1 | Analytics engine
Displayed in the footer
Page 264 of 952
Cortex XDR Documentation
Displayed in the header
Cortex XDR uses its Analytics Engine to examine logs and data retrieved from your sensors on the Cortex XDR 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 XDR tenant, including any firewall
data, and analyzes the information as soon as it arrives. Cortex XDR triggers an Analytics alert when the Analytics Engine determines an anomaly.
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.
The Analytics Engine creates and maintains 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.
13.2.2 | Analytics sensors
To detect anomalous behavior, Cortex XDR can analyze logs and data from a variety of sensors.
Cortex XDR Pro per Endpoint agents without the XTH add-on can enable Analytics and Identity Analytics. Due to the limits and filters applied to the data
collected, results will differ from agents with the XTH add-on. See the Cortex XDR Analytics Alert Reference guide for a complete list of supported sensors.
Sensor Description
Palo Alto Networks sensors
Firewall traffic logs Palo Alto Networks firewalls perform traditional and next-generation firewall
activities. The Cortex XDR 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 XDR.
Types of data collected by EAL include, amongst others, 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 XDR can trigger 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 XDR 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 XDR
can analyze entries for Tthreat logs relating to URLs and trigger alerts that
indicate malicious behavior such as command and control, and exfiltration.
Displayed in the footer
Page 265 of 952
Cortex XDR Documentation
Displayed in the header
Sensor Description
Cortex XDR agent endpoint data With a Cortex XDR 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
trigger 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 XDR 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 XDR with Active Directory
data, the Analytics engine can also trigger 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 XDR, you can increase detection coverage and take advantage of Cortex
XDR analysis capabilities. When Cortex XDR analyzes your firewall logs and
detects anomalous behavior, it triggers 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 trigger alerts such as for credential access and defense evasion.
13.2.3 | Coverage of MITRE Attack tactics
Network attacks follow predictable patterns. If you interfere with any portion of this pattern, you can neutralize the attack. The adversarial behaviors making up
these patterns are collected in a universally accessible, continuously updated knowledge base called the MITRE ATT&CK™ knowledge base of tactics.
The Analytics Engine can trigger an alert for any of the following attack tactics as defined in the MITRE Attack database.
Displayed in the footer
Page 266 of 952
Cortex XDR Documentation
Displayed in the header
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.
Cortex XDR 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.
Cortex XDR 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. Cortex
XDR 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. Cortex XDR 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. Cortex XDR 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.
13.2.4 | Analytics detection time intervals
The Cortex XDR Analytics Engine retrieves logs from the Cortex XDR tenant to create a baseline so that it can trigger alerts when abnormal activity occurs. This
analysis is highly sophisticated and performed on more than a thousand dimensions of data. Internally, Cortex XDR organizes its analytics activity into
algorithms called detectors. Each detector is responsible for triggering an alert when suspicious behavior is detected.
To trigger 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.
Displayed in the footer
Page 267 of 952
Cortex XDR Documentation
Displayed in the header
There are several meaningful time intervals for Cortex XDR Analytics detectors:
Time Interval Description
Activation period The shortest amount of log file time before the app can trigger 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
triggered. 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.
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 XDR
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 XDR.
Deduplication period The amount of time in which additional alerts for the same activity or
behavior are suppressed before Cortex XDR triggers another Analytics
alert.
These time periods are different for every Cortex XDR Analytics detector. The actual amount of logging data (measured in time) required to trigger any given
Cortex XDR Analytics alert is specified in the Cortex XDR Analytics Alert Reference Guide.
13.2.5 | Analytics alerts and Analytics BIOCs
The Cortex XDR Analytics engine triggers an alert when it detects suspicious activity, composed 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 XDR automatically disables alerts
from detectors that reach 5000 or more matches over a 24 hour period.
In addition to standard Analytics alerts, there is another category of alerts triggered by Analytics behavioral indicators of compromise (ABIOCs). 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 XDR tailors each ABIOC to your specific environment after analyzing your logs and data
sources and continually tunes and delivers new ABIOCs with content updates.
13.2.6 | Identity Analytics
Cortex XDR 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.
Displayed in the footer
Page 268 of 952
Cortex XDR Documentation
Displayed in the header
To easily track the alerts and Analytics BIOC rules, Cortex XDR 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 XDR details the active directory group, organizational unit, role,
logins, hosts, alerts, and process executions associated with the user.
To enable Identity Analytics, you must first:
Set Up Could Identity Engine(formally Directory Sync Services (DSS))
Activate Cortex XDR Analytics
After configuring your Cloud Identity Engine instance and Cortex XDR Analytics, select Settings ( ) → Configurations → Cortex XDR - Analytics, and in the
Featured in Analytics section, Enable Identity Analytics.
13.2.7 | 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.
13.3 | 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.
Investigations are comprised of one or more data collections from endpoints within an environment. Grouping the collections within a single location enables
you to focus on the endpoints relevant to your investigation. When searching for data, you can select two types of collections:
Hunt collections enable you to search for a specific activity across a large number of hosts. A hunt collection provides more details about where
something occurred. Examples of this type of collection are, 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 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.
13.3.1 | Manage an investigation
Abstract
Manage an investigation by adding collections, managing alerts, adjusting the timeline, analyzing assets and artifacts.
Forensic investigations streamlines your incident response, data collection, threat hunting and analysis of your endpoint. By using the Forensic Investigation,
you can find the source and scope of the attack and to determine what, if any, data was accessed. It provides a single location for grouping, tracking, and
analyzing all forensic data collections.
Forensic Investigations enables you to do the following:
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.
Displayed in the footer
Page 269 of 952
Cortex XDR Documentation
Displayed in the header
Field Description
Investigation Name of the investigation.
Status 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 Number of completed collections from the total collections.
collections
New alerts Total count of alerts for the collection where the Resolution Status=New.
Total alerts Total number of alerts for data collected in the investigation
You can click the link to open the investigation on the Alerts tab.
Created Timestamp of when the investigation was created.
13.3.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 relevant forensics data. This includes adding collections (hunts and triages), exporting the data collections,
managing alerts and evaluating key assets & artifacts.
1. Select Incident Response → Investigation → Forensics → Forensic Investigations.
2. Click New Investigation.
3. In the Create New Investigation wizard, enter a name and description (optional) for the investigation.
4. In the Permissions table, select the users to whom you want to grant access to the investigation data.
To set up user permissions, you must have Scope-Based Access Control (SBAC) enabled.
Refer to User permissions for detailed information on permissions.
5. Click Save to save the investigation in the Forensic Investigations table or click Save & Start A Collection to start the process of adding collections.
6. In the New Collection widget, select Triage or Hunt.
7. The investigation is saved to the Forensic investigations table.
8. Click UTC Timezone to configure the timezone and timestamp format. Refer to Configure server settings for information on setting up your timezone.
13.3.1.2 | Edit an investigation
Abstract
Edit an existing investigation from the Forensic Investigations page.
From the list of active 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 more information, refer to User permissions.
Displayed in the footer
Page 270 of 952
Cortex XDR Documentation
Displayed in the header
13.3.1.3 | Close an investigation
Abstract
Close an existing investigation from the Forensic Investigations page.
From the list of ongoing investigations, you can close an investigation. You might want to close an investigation if resolved, or if you want to cancel the
investigation.
When you close an investigation, Palo Alto Networks has a grace period of 24 hours before deleting any collections associated with the investigation. During
this 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, you can view all evidence collections exported for the investigation.
3. In the Forensic Investigation table, the status of the investigation changes to Close Pending, and the timestamp displays the time the investigation
expires and the investigation data is deleted.
4. Right-click an investigation pending closure to display the following options::
Edit: Update the investigation name, description, or adjust user permissions.
Open: Cancel the close request.
Permanently delete: Delete the investigation and all associated data immediately. This action can't be canceled.
13.3.1.4 | User permissions
Abstract
You can assign users to the investigation for them to view and manage the investigation.
By default, investigation permissions utilize the role-based access control (RBAC) settings configured in the system. Users must have a role with the Forensic
permissions set to View in order to view forensic investigations. In order to create investigations or collections, a user must have a role where the Forensics
permissions is set to View/Edit. Without either role, a user cannot interact with the forensics interface.
If Scope-Based Access Control (SBAC) is enabled on your system, from the Permissions table, you can select the users from which to assign permissions to
the investigation.
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.
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 using an
XQL query.
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 XDR 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 XDR access permissions that are assigned specifically to them, the field displays No-Role.
Permissions Options are None, View, View/Edit
Displayed in the footer
Page 271 of 952
Cortex XDR Documentation
Displayed in the header
13.3.2 | Data collection
Abstract
This section includes information related to each collection type.
The data collection section includes information related to each collection type.
13.3.2.1 | Hunting
Abstract
Search for specific data across a large number of hosts.
Hunting enables investigators to search for specific data across a large number of hosts. Hunt collections provide more details about where something
occurred. Hunting examples include finding which endpoints executed a piece of malware, which users accessed a particular file, or which endpoints were
accessed by a specific user.
13.3.2.1.1 | Create a hunt
Abstract
Hunt collections enable you to search endpoints for suspicious activity to contribute to helping resolve the investigation.
Select hunt collections when you want to search for a specific activity across a large number of hosts. Hunt Collections gather more details about where
something occurred. For example, use a hunt to find 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, you can select from various artifact types for Windows and macOS.
1. In the New Hunt Collection wizard, in the Hunt Collection Name, enter a name that will be easy to find in the collections table.
2. Select the Platform, Windows or macOS.
3. Select one of the time range options:
One Time Collection: Run the hunt collection only once.
Repeat Collection Every: Run the hunt collection every x hours set.
Schedule: Range of days during the week and time frame.
4. In Description , enter information that is relevant to the collection you are creating.
5. In Maximum Concurrent Endpoints, 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.
You can save hunts in an incomplete state and edit them later. After a hunt has run, you cannot edit it. Instead, you can duplicate to create a new hunt with the
same configuration in order to edit.
Configuration for hunt collection
When search fields are specified, the results of the search are limited based upon those filters. If more than one entry in a search filter field, 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 and the Windows folder.
If you specify multiple search fields, the search returns entries that match all the selected criteria. 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.
In a hunt collection, you can create a search query adding any of the following artifacts.
Displayed in the footer
Page 272 of 952
Cortex XDR Documentation
Displayed in the header
Category Default Timeout Artifacts Collected From Endpoint(S) Supported Filters
Archive 60 minutes (Windows) 7-Zip Folder History: File Name: regular expression (case-insensitive)
History A registry key containing a list of
Example: [0-9A-F]{8}\.exe
(Windows archive files accessed using 7-
only) Zip. File Path: path (wildcards ? * ** supported)
(Windows) WinRAR ArcHistory:
Example: C:Windows\Temp\**\*.exe
A registry key containing a list of
archive files accessed using
WinRAR.
Browser 60 minutes (Windows, macOS) Chrome URL: goog*.\.com
History
(Windows, macOS) Chromium- History File Path: path (wildcards ? * ** supported)
Based
Example: C:\Users\*\AppData\Local\BraveSoftware\Brave-Browser\*\History
(Windows, macOS) Firefox
(Windows) Edge-Anaheim
(Windows) Edge-Spartan
(Windows) Internet Explorer
(macOS) Quarantine
(macOS) Safari
Command 60 minutes (Windows) PSReadline: A record Search Regex: regular expression (case-insensitive)
History of commands typed into a
Example: [0-9A-F]{8}\.exe
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.
Deleted 180 minutes (Windows) Recycle Bin: Folder File Name: regular expression (case-insensitive)
Files used by Windows as temporary
Example: [0-9A-F]{8}\.exe
(Windows storage for deleted files prior to
only) permanent deletion. File Path: path (wildcards ? * ** supported)
Example: C:Windows\Temp\**\*.exe
User Search: User SID or User Name selector.
Example: ACME\jsmith
Displayed in the footer
Page 273 of 952
Cortex XDR Documentation
Displayed in the header
Category Default Timeout Artifacts Collected From Endpoint(S) Supported Filters
File Access 60 minutes (Windows) Jumplists: A feature Target File Name: regular expression (case-insensitive)
of the Windows Task bar that
Example: [0-9A-F]{8}\.exe
provides shortcuts to users for
recently accessed files or Target File Path: path (wildcards ? * ** supported)
applications.
Example: C:Windows\Temp\**\*.exe
(Windows) OpenSavePidlMRU:
A registry key containing a list of User Search: User SID or User Name selector.
recently opened and saved files
for a user’s account. Example: ACME\jsmith
(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.
File Search 180 minutes (Windows, macOS) File Search: File Path: path (wildcards ? * ** supported)
Search for a file across
endpoints by specifying a file Example: C:Windows\Temp\**\*.exe
path that can include wildcards,
File Name: regular expression (case-insensitive)
and then filter those results
based on the file size, the file Example: [0-9A-F]{8}\.exe
name (supports regular
expressions), or file hash (MD5, File Hash: Supports MD5, SHA1, and SHA256.
SHA1, or SHA256).
Example:
f9d9b9ded9a67aa3cfdbd5002f3b524b265c4086c188e1be7c936ab25627bf01
Size
Example: >= 100 MB
Displayed in the footer
Page 274 of 952
Cortex XDR Documentation
Displayed in the header
Category Default Timeout Artifacts Collected From Endpoint(S) Supported Filters
Log Search 180 minutes (Windows) Event Log: A Event Log Channel: Does not support wildcards.
component of Microsoft
Example: Security
Windows, where the user can
view record of events that Event ID:
occurred within a system or
process. Example: 4624
(macOS) Apple Unified Logs: Providers: Does not support wildcards.
Predicate is a custom filter
component for Apple Unified Example: Security
Logs.
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
Network 60 minutes (Windows) ARP Cache: A cache IP Address: IPv4 or IPv6 addresses.
Data of Address Resolution Protocol
(ARP) records for resolved MAC Example: 10.0.0.5
and IP addresses. Domain: regular expression (case-insensitive)
(Windows) DNS Cache: A cache Example: goo.*\.com
of Domain Name System (DNS)
records for resolved domains Path: path (wildcards ? * ** supported)
and IP addresses.
Example: /Volumes/VMware*
(Windows.macOS) Hosts File:
Listing of entries from the User Search: User SID or User Name selector.
etc/hosts file.
Example: ACME\jsmith
(macOS) Recent Places: A plist
file located within a user's
Library directory that contains a
list of recently accessed servers
and hosts.
Displayed in the footer
Page 275 of 952
Cortex XDR Documentation
Displayed in the header
Category Default Timeout Artifacts Collected From Endpoint(S) Supported Filters
Persistence 60 minutes (Windows) Drivers: Windows Registry Path: path (wildcards ? * ** supported)
device drivers installed on each
Example: HKEY_USERS\*\Software\Microsoft\Windows\CurrentVersion\Run\*
endpoint.
(Windows) Registry Persistence: Executable Path: path (wildcards ? * ** supported)
A collection of registry keys that
Example: C:Windows\Temp\**\test.exe
can be used for malware
persistence. User Search: User SID or User Name selector.
(Windows) Scheduled Tasks: Example: ACME\jsmith
Tasks used to execute Windows
programs or scripts at specified SHA256: Supports SHA256 hashes.
intervals. Example:
f9d9b9ded9a67aa3cfdbd5002f3b524b265c4086c188e1be7c936ab25627bf01
(Windows) Services: Windows
applications that run in the Command: regular expression (case-insensitive)
background and do not require
user interaction. Example: /bin/sh /private/etc/periodic/weekly/.*
(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.
Displayed in the footer
Page 276 of 952
Cortex XDR Documentation
Displayed in the header
Category Default Timeout Artifacts Collected From Endpoint(S) Supported Filters
Process 60 minutes (Windows) Amcache: A registry Executable File Name: regular expression (case-insensitive)
Execution hive used by the Application
Example: [0-9A-F]{8}\.exe
Compatibility Infrastructure to
cache the details of executed or Executable Path: path (wildcards ? * ** supported)
installed programs.
Example: C:Windows\Temp\**\test.exe
(Windows) Background Activity
Monitor: Per-user registry keys User Search: User SID or User Name selector.
created by Background Activity
Monitor (BAM) service to store Example: ACME\jsmith
the full paths of executable files
SHA256: Supports SHA256 hashes.
and a timestamp, indicating
when they were last executed. Example:
f9d9b9ded9a67aa3cfdbd5002f3b524b265c4086c188e1be7c936ab25627bf01
(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
Displayed in the footer
Page 277 of 952
Cortex XDR Documentation
Displayed in the header
Category Default Timeout Artifacts Collected From Endpoint(S) Supported Filters
Library directory that contains a
list of applications opened by
that user.
Registry 180 minutes (Windows) Registry Search: Path: path (wildcards ? * ** supported)
Search Registry listings collected during
(Windows Forensic investigation. Example: HKEY_USERS\*\Software\Microsoft\Windows\CurrentVersion\Run\*
only)
Data: regular expression (case-insensitive)
Example: [0-9A-F]{8}\.exe
Remote 60 minutes (Windows) AnyDesk Connection IP Address: IPv4 or IPv6 addresses
Access Logs: Records of activity found
(Windows in the AnyDesk connection logs. Example: 10.0.0.5
only) User Search: User SID or User Name selector.
(Windows) AnyDesk Trace Logs:
Records of activity found in the Example: ACME\jsmith
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.
System 60 - 120 minutes (Windows) Application Resource Application: path (wildcards ? * ** supported)
Statistics Usage: A table in the System
(Windows Resource Usage database that Example: C:Windows\Temp\**\test.exe
only) stores statistics pertaining to User Search: User SID or User Name selector.
resource usage by running
applications. Example: ACME\jsmith
(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.
Displayed in the footer
Page 278 of 952
Cortex XDR Documentation
Displayed in the header
Category Default Timeout Artifacts Collected From Endpoint(S) Supported Filters
User 60 minutes (Windows) WordWheelQuery: User Search: User SID or User Name selector.
Searches Registry key containing a list of
Example: PANW\jsmith
terms that a user searched for in
Windows Explorer. Search Regex: regular expression (case-insensitive)
(macOS) Spotlights Shortcuts: A
Example: [0-9A-F]{8}\.exe
plist file that contains the
Spotlight search terms entered
by each user and the items that
they selected from the search
results.
13.3.2.1.2 | Hunt results
Abstract
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 results
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:
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.
Field Description
Context Contextual details relating to the executed process such as files opened,
command line arguments, or process run count.
Executable Name Name of the executable.
Executable Path Path of the executable.
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.
Timestamp Timestamp associated with the executable file or process execution.
Type Type of process artifact.
Displayed in the footer
Page 279 of 952
Cortex XDR Documentation
Displayed in the header
Field Description
User User name associated with the execution artifact.
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
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 results
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:
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.
Displayed in the footer
Page 280 of 952
Cortex XDR Documentation
Displayed in the header
Field Description
Command Command to be executed.
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.
File SHA256 SHA256 value of the file.
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.
Registry Path Path of the registry value.
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.
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 results
Abstract
Manage the different network artifacts collected on the endpoints.
Displayed in the footer
Page 281 of 952
Cortex XDR Documentation
Displayed in the header
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 results
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.
Connection Type Type of 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 results
Abstract
Displayed in the footer
Page 282 of 952
Cortex XDR Documentation
Displayed in the header
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
Path Path of archive history file.
User User account associated with archive history file.
13.3.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, go to Incident Response → Investigation → Forensics. From the investigation table, click the investigation link. From
the Collections tab, select Hunt and from the Status column of the hunt, click Actions. This launches 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
Displayed in the footer
Page 283 of 952
Cortex XDR Documentation
Displayed in the header
Field Description
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 Latest time results were received for this action.
Parameters The string that describes the search parameters.
Example: C:\Users\* File Name Regex: *\.exe
Creation time Timestamp when the search was created.
13.3.2.2 | Triage
Abstract
Triage collection gathers a wide range of artifacts that can be used to help understand the event that occurred on an endpoint.
Triage enables you to do a in-depth analysis of a specific endpoint to fully understand the activities that occurred on that endpoint. The triage functionality is
configurable and supports the collection of all 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.
13.3.2.2.1 | Create a 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.
Use triage collections 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.
Displayed in the footer
Page 284 of 952
Cortex XDR Documentation
Displayed in the header
9. Click Save Collection and Exit or click Next to continue.
13.3.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 XDR, 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.
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.
13.3.2.2.3 | Offline triage collection
Abstract
Offline triage collection is supported for endpoints with no network connection or no Cortex XDR agent currently installed.
The Forensics add-on provides a triage collection option for endpoints with no network connection or no Cortex XDR agent currently installed.
Note that the procedure is different for Windows and macOS.
Windows
1. Select Incident Response → Investigation → Forensics → Forensics Investigations.
2. Click the investigation link and from the Collections tab, find the triage and click the menu options button ( )/ Depending on the system type of the
endpoint, select Download 32-bit Collector or Download 64-bit Collector .
3. Copy the downloaded file to a destination of which is accessible from the targeted endpoint.
4. From the endpoint, open the folder containing the offline triage collector and right-click on the executable file cortex-xdr-payload.exe and select Run as
administrator.
The cortex-xdr-payload.exe opens a command window that displays the status of each artifact collection.
After the collection is completed, a zip file with the hostname and a timestamp in the file name is created in the same directory as the executable.
5. From the the Collections page, select the triage and click the menu options button ( ) and select Upload Offline Package.
6. In the Import Offline Triage dialog, browse for or drag and drop the zip file and click Done.
The triage file is ingested and the results are available for review.
Security software running on the endpoint (including the Cortex agent) can interfere or block the execution of the offline triage collector. Disable any
security software on the endpoint while the collector is running or whitelist the collector in your security software before running the offline triage collector.
macOS
1. Select Incident Response → Investigation → Forensics → Forensics Investigations.
2. Click the investigation link and from the Collections tab, find the triage and click the menu options button ( ) and select Download Collector.
3. Open the folder containing the zip file and run the command xattr -c <triage_configuration_name>.zip, to remove any extended
attributes that macOS might have applied to the file.
4. Copy the downloaded zip file to a destination of which is accessible from the targeted endpoint.
Displayed in the footer
Page 285 of 952
Cortex XDR Documentation
Displayed in the header
5. From the endpoint, open the folder containing the offline triage collector and run the cortex-xdr-payload.exe file or from a command line, enter: sudo
cortex-xdr-payload.
After the collection is completed, a zip file with the hostname and a timestamp in the file name is created in the same directory as the executable.
6. From the the Collections page, select the triage and click the menu options button ( ) and select Upload Offline Package.
7. In the Import Offline Triage dialog, browse for or drag and drop the zip file and click Done.
The triage file is ingested and the results are available for review.
Security software running on the endpoint (including the Cortex agent) can interfere or block the execution of the offline triage collector. Disable any
security software on the endpoint while the collector is running or whitelist the collector in your security software before running the offline triage collector.
13.3.2.2.4 | 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.
The triage results page is divided by the following tabs:
Alerts: Refer to Featured fields in Overview of the Alerts page for descriptions of the fields.
Artifacts: Display all of the artifact categories collected. You can select the item to add to a timeline.
Host Timeline: Displays a list of normalized, per-host timelines that include multiple forensic artifacts in a single table.
13.3.2.2.5 | 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.
Displayed in the footer
Page 286 of 952
Cortex XDR Documentation
Displayed in the header
Field Description
Status Displays 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.
Collection Type Collection type.
Triage ID Unique ID associated with this triage data.
13.3.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
13.3.3.1 | Review alerts
Abstract
The alerts table displays all the collections within the investigation that has identified suspicious or malicious activity within the forensics data sets.
The alerts table displays all the collections within the investigation that has identified suspicious or malicious activity within the forensics data sets.
Refer to Featured fields in Overview of the Alerts page for the descriptions of the table fields.
The following actions are available for a selected alert.
Displayed in the footer
Page 287 of 952
Cortex XDR Documentation
Displayed in the header
Change status
Change severity
Investigate causality chain
Run playbook
Manage alerts
13.3.3.2 | Investigation timeline
Abstract
Investigation timeline shows the tagged forensic artifacts that were tagged. The tags display 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 display 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.
Tags There are three default tags to choose from.
legitimate
malicious
suspicious
You can also create your own tags.
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.
Displayed in the footer
Page 288 of 952
Cortex XDR Documentation
Displayed in the header
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.
13.3.3.3 | Key assets & artifacts
Abstract
Displays 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: Displays all the items that have been tagged in the File Access tables.
The following table for Endpoints displays the endpoints that have at least one or more items tagged:
Field Description
Endpoint Name Name of the endpoint.
Endpoint Type Displays the endpoint type:
Mobile
Server
Workstation
Kubernetes Node
Endpoint Status Displays the status of the endpoint:
Connected
Connected Lost
Deleted
Disconnected
Uninstalled
VDI Pending Login
Forensics Offline
Partial Registration
Earliest Activity Timestamp of the earliest tagged item in the incident timeline for the endpoint.
Latest Activity 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.
Displayed in the footer
Page 289 of 952
Cortex XDR Documentation
Displayed in the header
Field Description
Last Seen Timestamp of last seen.
Endpoint Isolated Displays the status of endpoint isolation:
Pending Isolation Cancellation
Pending Isolation
Isolated
Not Isolated
Isolation Date 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.
Field Description
File Name Name of the artifact collected from the endpoint.
Path Executable path.
Tags Assigned tags of the artifact.
SHA256 SHA256 value of the executable file.
Verdicts WildFire verdicts.
User User name of the person who ran the process.
Mitre ATT&CK Tactic Tactic selected during tagging.
Mitre ATT&CK Technique Technique selected during tagging.
Platform Operating system of the endpoint:
Windows
macOS
Linux
Android
Created Creation timestamp of the file accessed.
Accessed Accessed timestamp of the file accessed.
Modified Modified timestamp of the file accessed.
Displayed in the footer
Page 290 of 952
Cortex XDR Documentation
Displayed in the header
The following table forUsers displays any artifact data with a non-null user field that has been tagged.
Field Description
Username Username of the person who ran the process.
Domain Domain of the user's computer.
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 displays the event logs with the IP addresses that have been tagged.
Field Description
Indicator Data field that was tagged.
Type IP Address
Hostname
URL
Country Geolocation data for IP addresses.
Flag Flag of geolocated country.
Organization Organization associated with IP address.
The following table for Data Access displays 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.
Created Creation timestamp of the file accessed.
Accessed Accessed timestamp of the file accessed.
Displayed in the footer
Page 291 of 952
Cortex XDR Documentation
Displayed in the header
Field Description
Modified Modified timestamp of the file accessed.
Size Size of the file.
13.3.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.
You can export a collection more than once.
To view the status of the export, click the Exports button.
The Investigation Exports table displays 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 Displays the name of the triage or hunt. For triage, the endpoint name of the triaged host is displayed.
Exported Displays the time when the exported package was created (compressed).
Exported by Displays the name of the user who requested the export.
Export expiration Displays 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 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.
13.4 | Asset management
13.4.1 | Vulnerability Assessment
Abstract
Perform a vulnerability assessment of all endpoints in your network using Cortex XDR. This includes CVE, endpoint, and application analysis.
Cortex XDR 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
Displayed in the footer
Page 292 of 952
Cortex XDR Documentation
Displayed in the header
For a comprehensive understanding of the vulnerability severity, Cortex XDR retrieves the latest data for each Common Vulnerabilities and Exposures (CVE)
from the NIST National Vulnerability Database, including CVE severity and metrics.
The following are prerequisites for Cortex XDR to perform a vulnerability assessment of your endpoints.
Requirement Description
Licenses and Add-ons Cortex XDR Pro per Endpoint license.
Host Insights Add-on.
Supported Platforms Windows
Cortex XDR agent 7.1 or a later release.
Cortex XDR lists only CVEs relating to the operating system, and not CVEs relating
to applications provided by other vendors.
Cortex XDR retrieves the latest data for each CVE from the NIST National
Vulnerability Database as well as from the Microsoft Security Response Center
(MSRC).
Cortex XDR 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 XDR cannot guarantee an accurate
CVE assessment.
Cortex XDR 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 XDR 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 XDR collects only the applications list from MacOS without CVE calculation.
If Cortex XDR 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 XDR 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 XDR as the Enhanced Vulnerability Assessment engine is
initialized.
The following are prerequisites for Cortex XDR to perform an Enhanced Vulnerability Assessment of your endpoints.
Requirement Description
Licenses and Add-ons Cortex XDR Pro per Endpoint license.
Host Insights Add-on.
Displayed in the footer
Page 293 of 952
Cortex XDR Documentation
Displayed in the header
Requirement Description
Supported Platforms Windows
Cortex XDR agent 8.3 or a later release.
Cortex XDR 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 XDR 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 XDR 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 XDR and view all the endpoints and
applications in your environment that are impacted by the CVE. Cortex XDR 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 XDR 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.
You can click each individual CVE to view in-depth details about it on a
panel that appears on the right.
Displayed in the footer
Page 294 of 952
Cortex XDR Documentation
Displayed in the header
Value Description
Description The general NIST description of the CVE.
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 XDR 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.
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 XDR 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 XDR that identifies the endpoint.
Endpoint name Hostname of the endpoint.
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 XDR.
MAC address The MAC address associated with the endpoint.
Displayed in the footer
Page 295 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR 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, and version, of applications on the endpoint. If an installed application has known vulnerabilities, Cortex XDR 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 XDR agent to communicate only with Cortex XDR .
(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 XDR 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 XDR within 24 hours. Alternatively, you can re-scan the endpoint to retrieve the most updated list.
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 XDR 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.
13.4.2 | Network configuration
Abstract
Cortex XDR Network Configuration provides a representation of your network assets by collecting and analyzing your network resources.
Network asset visibility is a crucial investigative tool for discovering rogue devices and preventing malicious activity within your network. The number of
managed and unmanaged assets in your network provides vital information for assessing security exposure and tracking network communication effectively.
Cortex XDR Network Configuration accurately represents 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 XDR Agent Logs.
ARP Cache
Broker VM Network Mapper
Pathfinder Data Collector
Displayed in the footer
Page 296 of 952
Cortex XDR Documentation
Displayed in the header
In addition to the network resources, Cortex XDR allows you to configure a Windows Agent Profile to scan your endpoints using Ping. This scan provides
updated identifiers of your network assets, such as IP addresses and OS platforms. The scan is automatically distributed by Cortex XDR to all the agents
configured in the profile and cannot be initiated by request.
With the data aggregated by Cortex XDR 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.
Monitor network data communications both within and outside your network.
13.4.2.1 | Configure your network parameters
Abstract
Define the IP address ranges and domain names used by Cortex XDR to identify your network assets.
Internal IP address ranges and domain names must be defined in order to track and identify assets in the network. This enables Cortex XDR to analyze, locate,
and display your network assets.
Define internal IP address ranges
1. In Cortex XDR, select Assets Network Configuration.
2. Define an IP address range.
By default, Cortex XDR creates Private Network ranges that specify reserved industry-approved ranges. These ranges can only be renamed.
To Add New Range, select either:
Create New.
1. In the Create IP Address Range dialog box, enter the IP address Name and IP Address, Range or CIDR values.
You can add a range that is fully contained in an existing range, however, you cannot add a new range that partially intersects with another
range.
2. Click Save.
Upload from File
1. In the Upload IP Address Range dialogue box, drag and drop or search for a CSV file listing the IP address ranges. Download example file
to view the correct format.
2. Click Add.
Define domain names
1. In Cortex XDR , 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.
IP address ranges fields
FIELD DESCRIPTION
Range Name Name of the IP address range defined.
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 within the defined range that have reported Cortex Agent logs or appeared in your Network Firewall Logs.
Displayed in the footer
Page 297 of 952
Cortex XDR Documentation
Displayed in the header
FIELD DESCRIPTION
Active Managed Assets Number of assets within the defined range reported Cortex XDR Agent logs.
Modified By Username of the user who last changed the range.
Modification Time The timestamp shows when this range was last changed.
13.4.3 | Cloud Compliance
Abstract
Learn more about Cloud Compliance in Cortex XDR.
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 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, configure your Linux agent settings profile to collect this data by selecting the enable cloud compliance
collection option in XDR Pro . The endpoints require this data collection option enabled for around 12 hours to set the benchmarks and display the results on
the Cloud Compliance page.
13.4.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.
The Asset Scores page is available if the Identity Threat Module add-on is enabled.
Cortex XDR aggregates Workday and Active Directory data to create a list of user and host assets within your network. When alerts and incidents occur, they
are associated with a host or user asset and Cortex XDR calculates a score that represents the risk level of each asset. This score helps to identify high-risk
assets in your organization and detect compromised accounts and malicious activities.
To Include System Users in the table, select the Include System Users checkbox: system users are SYSTEM, administrators, NT authority, and others.
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:
1. Select Assets → Asset Scores. Use the toggle in the page header to switch between the Users and Hosts tabs.
2. Filter and review your assets.
The fields in the Users tab
Field Description
Starred Whether the user is included in the watchlist.
Score Represents the Cortex XDR 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 XDR.
Displayed in the footer
Page 298 of 952
Cortex XDR Documentation
Displayed in the header
Field Description
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.
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 XDR.
Asset role Asset roles that the user is associated with.
The fields in the Hosts tab
Field Description
Starred Whether the host is included in the watchlist.
Hostname Unique ID of the 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.
Displayed in the footer
Page 299 of 952
Cortex XDR Documentation
Displayed in the header
Field Description
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. To investigate further, right-click on a selected host or user and click Open User Risk View or Host Risk View. For more information, see Investigate a user
and Investigate a host.
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.
13.4.5 | Asset Inventory
Abstract
From the Cortex XDR management console, you can manage your different network assets.
Cortex XDR provides a central location from which you can view and investigate information relating to assets in your network. Using your defined internal
network configurations, Broker VM Network Mapper, Cortex XDR agent, EDR data collected from firewall logs, and logs from third-party vendors, Cortex XDR is
able to aggregate and display a list of all the assets located within your network. As soon as Cortex XDR begins receiving network assets, you can view the
data in Assets → Asset Inventory.
The following are some of the main features available 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 section heading names and data displayed change depending on the source of the assets.
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.
You can toggle between the Legacy View and Advanced View on the page. The Legacy View displays a list of all the assets located within your network
according to their IP address., while the
Advanced View (default)—Includes the following features:
You can view the data in a table format by accessing the pages for All Assets and Specific Assets, including On-Prem Assets and Cloud Compute
Instances.
The table columns provide newly structured data with updated filtering capabilities to improve your asset visibility.
When any row in a 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.
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.
To easily investigate your asset inventory using the Legacy View.
Displayed in the footer
Page 300 of 952
Cortex XDR Documentation
Displayed in the header
Select Assets → Asset Inventory.
In the Page layout notification, toggle to the Legacy view.
Filter and review your assets.
By default, the Assets table is filtered according to unmanaged assets over the last 7 days. The following table describes both the default and optional
fields in the table, and the network prerequisites required by Cortex XDR to retrieve the data.
Field Description Prerequisites
IP address IP address related to the last asset associated
with it.
MAC address Mac address of the asset. The asset requires at least one of the following:
An installed Cortex XDR agent
A running Cortex XDR collector
For Mac endpoints, a Global Protect
client 9.1 or a later release, configured to
send HIP Match logs
Associated DHCP logs covering this
asset are sent to Cortex XDR
MAC address vendor Vendor name of the Mac address of the asset. The asset requires at least one of the following:
An installed Cortex XDR agent
A running Cortex XDR collector
For Mac endpoints, a Global Protect
client 9.1 or a later release, configured to
send HIP Match logs
Associated DHCP logs covering this
asset are sent to Cortex XDR
Host name Host name of the asset, if available. The asset requires at least one of the following.
An installed Cortex XDR agent
A running Cortex XDR collector
A Global Protect client 9.1 or a later
release, configured to send HIP Match
logs
Associated DHCP logs covering this
asset are sent to Cortex XDR
First time seen Timestamp of when the IP address was first
seen in the logs.
Last time seen Timestamp of when the IP address was last
seen in the logs.
Agent Installed Whether or not the asset has an agent
installed.
Displayed in the footer
Page 301 of 952
Cortex XDR Documentation
Displayed in the header
Field Description Prerequisites
Agent ID The ID of the agent installed on the asset.
Cortex XDR only displays agents that send
EDR data captured in the firewall logs.
Collector running Whether or not a Pathfinder Data Collector is
currently running on the asset.
Range names Name of the IP address range allocated to the
IP address.
Agent version The version of the agent installed on the asset.
Cortex XDR only displays agents that send
EDR data captured in the firewall logs.
Platform Platform running on the asset. The asset requires at least one of the following:
An installed Cortex XDR agent
A running Cortex XDR collector
A Global Protect client 9.1 or a later
release, configured to send HIP Match
logs
You can export your filtered results to a TSV file.
13.4.5.1 | All Assets
Abstract
Cortex XDR enables you to view all external assets from the various asset categories on the All Assets page.
Ingesting and Viewing Cloud Compute Instances for Cloud Inventory Assets requires a Cortex XDR Pro per GB license.
The All Assets page enables you to view all your assets from various asset categories. Each asset is available in Cortex XDR in different ways depending on
the asset category and Cortex XDR license as explained in the following table.
Asset Category Availability In Cortex XDR License Required
On-prem Automatically available Any license
Cloud compute Requires configuring either a Cloud Inventory data collector or Agents that are installed on the Cortex XDR Pro TB
instance Cloud Compute Instances. license
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.
Displayed in the footer
Page 302 of 952
Cortex XDR Documentation
Displayed in the header
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.
This field only displays with a Cortex XDR Pro TB license.
Cloud ID* Displays the Resource ID as provided by the cloud provider.
This field only displays with a Cortex XDR Pro TB license.
Externally detected The provider of the asset is determined by an external assessment.
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 inventory
services* 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 XDR 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.
This field only displays with a Cortex XDR Pro TB license.
Sources* An array column that displays all the sources that provided observations for this asset.
Displayed in the footer
Page 303 of 952
Cortex XDR Documentation
Displayed in the header
Field Description
Type* Type of asset, which can be defined as one of the following.
The options available are dependent on your Cortex XDR license.
Cloud Compute Instance
On-Prem
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.
13.4.5.2 | Specific Assets
Abstract
Cortex XDR enables you to view specific external assets from a designated assets category in the Specific Assets page.
The Asset Categories listed are dependent on your Cortex XDR license. For more information, see All Assets.
Asset Category: the name of the specific asset category.
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.
Asset Category Description Unique Fields
Cloud compute Include assets managed by Agents, where the agent reported that the assets are No specific unique fields are displayed in
instance in a cloud environment. In addition, the assets can be Cloud Compute Instances addition to the common fields.
that were reported by a Cloud integration (i.e. Cloud Inventory data collector) with
or without a Cortex agent.
Cortex XDR 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.
Does not include devices that are in the cloud. For 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
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
trusted party. The most common use of certificates is for SSL/TLS, HTTPS, FTPS, Certificate algorithm
SSH, and VPN connections. The most common use of certificates is for HTTPS-
Certificate classification
based websites, which allow a web browser to validate that an HTTPS web server
is an authentic website. Cortex XDR 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.
Displayed in the footer
Page 304 of 952
Cortex XDR Documentation
Displayed in the header
Asset Category Description Unique Fields
Domain A domain name attributed to an organization by Cortex XDR . Subdomains of Resolves: indicates whether the domain has a
attributed Domains are also tracked as Domains. When there are too many (>1k) DNS resolution.
recent subdomains for one domain, Cortex XDR collapses them into the parent
domain.
Responsive IP An IP that currently or has previously exposed an External Service which was No specific unique fields are displayed in
detected by Cortex XDR and associated with the organization. addition 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”.
13.4.6 | 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.
Asset Roles are available only if the Identity Threat Module add-on is enabled.
Cortex XDR continuously analyzes your users and endpoints, and automatically classifies them based on their activities under asset roles, for example, Domain
Controller, Administrator, and 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 XDR Analytics in the following areas.
Enhancement of the accuracy of the analytics that runs 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 hosts 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.
13.4.6.1 | Manage Asset Roles for Users
Abstract
Learn how to edit the user lists assigned to asset roles.
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
XDR 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.
Displayed in the footer
Page 305 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR 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 XDR 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 XDR 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.
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.4.6.1.1 | Honey user
Abstract
Honey users are decoy users designed to attract potential attackers.
The honey user role is available only if the Identity Threat Module add-on is enabled.
A honey user is a decoy account designed to mimic a legitimate user within your environment. This kind of user looks attractive to potential attackers, with
access to many assets, and is used for triggering alerts if accessed.
One of the techniques used by an attacker trying to gain access to your network is attempting to use the credentials of accounts in your organization. By
setting up honey users, you can detect these access attempts as soon as they occur. Unlike genuine user accounts, honey users have no legitimate purpose
within the organization, making any activity involving them inherently suspicious. Cortex XDR uses its out-of-the-box Identity Threat Module to automatically
detect activity on the honey user role for identifying suspicious activities.
To use a honey user account for detection, you must configure it manually.
Configure a honey user
1. In Assets → Asset Roles Configuration, right click to select Honey User.
2. Click Edit Asset Role.
3. Select Add User → Add New and enter the honey user account details in the NetBIOS\SAM Account format.
13.4.6.2 | Manage Asset Roles for Endpoints
Abstract
Learn how to edit the host lists assigned to asset roles.
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 XDR 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.
Displayed in the footer
Page 306 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR 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 XDR 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 XDR 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.
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.
13.4.7 | Cloud Inventory Assets
Abstract
Cortex XDR provides a unified, normalized asset inventory for cloud assets to provide deeper visibility and context for incident investigation.
Cortex XDR 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 XDR . As soon as Cortex XDR begins receiving cloud assets, you can view the data in Assets → Cloud
Inventory, where and pages display the data in a table format.
The following are some of the main features available 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 selected row 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.
13.4.7.1 | All Cloud Assets
Abstract
Cortex XDR enables you to view all your cloud assets from the various cloud assets categories on the All Cloud Assets page.
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.
Displayed in the footer
Page 307 of 952
Cortex XDR Documentation
Displayed in the header
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 seven days.
The following table describes the fields available when viewing All Cloud Assets.
Certain fields are exposed and hidden by default. An asterisk (*) is beside every field that is exposed by default.
Field Description
Avaiblitity 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.
Hierarchy* Displays the hierarchy of the associated Project in the cloud provider separated by a forward slash (/) similar to a file path.
The Project is called something else in each cloud provider. For more information, see the Project description.
Integration key Internal Cortex XDR 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.
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.
Displayed in the footer
Page 308 of 952
Cortex XDR Documentation
Displayed in the header
Field Description
Raw asset Internal Cortex XDR 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 Rserouce 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 XDR 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.
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.
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 XDR does not always match the AWS Console as Cortex XDR displays the actual time.
13.4.7.2 | Specific Cloud Assets
Abstract
Cortex XDR enables you to view specific cloud assets from a designated cloud assets category in the Specific Cloud Asset pages.
Displayed in the footer
Page 309 of 952
Cortex XDR Documentation
Displayed in the header
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.
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 this
(VPCs) 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
13.4.7.3 | Manage Your Cloud Inventory Assets
Abstract
Cortex XDR provides a central location to view and investigate information relating to inventory assets in the cloud.
Ingesting and viewing Cloud Inventory Assets requires a Cortex XDR Pro per GB license.
Displayed in the footer
Page 310 of 952
Cortex XDR Documentation
Displayed in the header
1. 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 asset 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.
Displayed in the footer
Page 311 of 952
Cortex XDR Documentation
Displayed in the header
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.
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.
Displayed in the footer
Page 312 of 952
Cortex XDR Documentation
Displayed in the header
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
Displayed in the footer
Page 313 of 952
Cortex XDR Documentation
Displayed in the header
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.
Displayed in the footer
Page 314 of 952
Cortex XDR Documentation
Displayed in the header
Side Panel Component Description Example Image
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.
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.
Displayed in the footer
Page 315 of 952
Cortex XDR Documentation
Displayed in the header
Side Panel Component Description Example Image
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
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.
2. (Optional) Manage cloud inventory assets, as needed.
Displayed in the footer
Page 316 of 952
Cortex XDR Documentation
Displayed in the header
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.
14 | Configure incidents and alerts
The topics in this section provide information about configuration options for your incidents and alerts.
14.1 | External integrations
Abstract
Gain additional verification on key artifacts by integrating Cortex XDR with other Palo Alto Networks and third-party security products.
External integrations are available in Cortex XDR Pro only.
You can integrate external threat intelligence services with Cortex XDR that provide additional verification sources for each key artifact in an incident. Cortex
XDR supports the following integrations:
Threat intelligence
Integration Description
WildFire Cortex XDR 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 is displayed next to
relevant Key Artifacts in the incidents details page. See Review WildFire analysis details for more
information.
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. 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 XDR incidents, you must obtain the license key for
the service and add it to the Cortex XDR Configuration. When you add the service, the relevant
VirusTotal (VT) score is displayed in the incident details page under Key Artifacts.
Incident management
Displayed in the footer
Page 317 of 952
Cortex XDR Documentation
Displayed in the header
Integration Description
Third-party ticketing systems To manage incidents from the application of your choice, you can use the Cortex XDR 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 XDR, external apps can receive incident 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.
14.2 | Prioritize incidents with starring and scoring
Abstract
Prioritize and filter your incidents by using incident starring and incident scoring.
Cortex XDR provides incident starring and incident scoring to help you to prioritize your incidents.
Incident starring enables you to highlight and filter the incidents that you deem most important. Incident scoring assigns a numerical value to each incident to
reflect its severity. Using these functions, you can easily compare incident scores, filter starred incidents, and prioritize your most urgent incidents.
Incident scoring is available in Cortex XDR Pro only.
14.2.1 | Incident starring
Abstract
Starring incidents can help you to prioritize and filter your incidents.
To help you focus on the most important incidents, you can star an incident. Starring incidents enables you to narrow down the scope of incidents on the
Incidents page and in the Incident management dashboard. Cortex XDR identifies starred incidents with a purple star.
You can star incidents manually, or create an incident starring configuration. An incident starring configuration automatically categorizes and stars incidents
that contain alerts with specific attributes. In a starring configuration you define attributes or assets for alerts that you want to star. If an alert matches the
attributes in the starring configuration, the alert and incident containing the alert are starred. You can manage all starring configurations under Incident
Response → Incident Configuration → Starred Alerts.
Scope-Based Access Control considerations
Incident starring supports Scope-Based Access Control (SBAC). The following parameters are considered when editing a starring configuration:
If Scoped Sever Access is enabled and set to restrictive mode, you can edit a configuration if you are scoped to all tags in the configuration.
If Scoped Sever Access is enabled and set to permissive mode, you can edit a configuration if you are scoped to at least one tag listed in the
configuration.
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
You can manually star an incident during or after investigation:
1. Select Incident Response → Incidents.
2. In the list of incidents, locate the incident you want to star.
3. Select the star icon.
Create a starring configuration
You can proactively star alerts and incidents containing alerts by creating a starring configuration:
1. Select Incident Response → Incident Configuration → Starred Alerts.
2. Select Add Starring Configuration.
3. Under Configuration Name, enter a name to identify your starring configuration.
4. (Optional) Under Comment, enter a descriptive comment.
5. In the alert table, use the filters to define the alert attributes you want to include in the match criteria.
Displayed in the footer
Page 318 of 952
Cortex XDR Documentation
Displayed in the header
You can also right-click a specific value in the alert to add it as match criteria.
6. Click Create.
14.2.2 | Incident scoring
Abstract
Learn about the different incident scoring methods.
Incident scoring is available in Cortex XDR Pro only.
An incident score is a numeric value that indicates the urgency of an incident. Incident scoring can help you to streamline the process of prioritizing and
investigating your incidents, and help you to identify the incidents that require immediate attention.
Types of scoring
Cortex XDR uses the following scoring methods:
Rule-based scoring: The score is determined by user-defined scoring rules that match the alerts triggered in the incident.
Read more...
You create scoring rules that define scores for alerts with specific attributes or assets. You can base scoring rules on:
Hostnames
IP addresses
Users
Active Directory, or Azure groups and organization units
(Requires the Cloud Identity Engine to be configured).
When an alert is triggered, Cortex XDR searches for scoring rules that match the alert. An alert can match multiple rules or sub-rules. If a match is found,
Cortex XDR assigns the scores of the matching rules to the alert. If multiple rules match the alert, the alert score is an aggregation of the rule scores. By
default, a score is applied only to the first alert in the incident that matches the defined rule and sub-rule.
You can create a rule hierarchy by setting up sub-rules. If an alert matches one or more sub-rules, the sub-rule scores are also aggregated in the alert
score. However, a sub-rule score is only applied to an alert if the top-level rule was a match.
To determine the incident score, Cortex XDR calculates the combined alert scores total for all alerts in the incident. You can see a breakdown of the
score by clicking on the score in the details pane.
SmartScore: The score is automatically calculated, 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 XDR calculates the SmartScore according to the compiled data.
Manual scoring: The score is defined by the user.
How Cortex XDR assigns the score
For Cortex XDR to provide effective rule-based scores, you must define accurate scoring rules that are suitable for your environment and workflows. In
addition, SmartScore requires sufficient data to calculate and display the score. On first activation, this can take up to 48 hours. If sufficient data is not
available, no score is assigned.
When an incident is created, Cortex XDR searches for a match between your scoring rules and the alerts in an incident. If a match is found, a rule based score
is assigned. If no match is found and there is sufficient data available, Cortex XDR assigns a SmartScore. If Cortex XDR doesn't have sufficient data to assign
a score, you can manually assign a score.
To enable Cortex XDR to automatically assign a score to an incident, you must enable SmartScore and define scoring rules. For more information, see Set up
incident scoring.
You can see the assigned incident score on the Incidents page, under Incident Response → Incidents.
14.2.2.1 | Set up incident scoring
Abstract
Set up incident scoring by enabling SmartScore and defining scoring rules.
To set up incident scoring you need to enable SmartScore, and enable and define scoring rules.
Enable SmartScore
Displayed in the footer
Page 319 of 952
Cortex XDR Documentation
Displayed in the header
1. Select Settings → Configurations → Cortex XDR- Analytics and click Enable.
2. Select to Incident Response → Incident Configuration → Incident Scoring and enable SmartScore.
On the first activation, it can take up to 48 hours for SmartScore to calculate and display the score.
Enabling SmartScore subsequently impacts the User Score.
Enable and define scoring rules
1. Selec Incident Response → Incident Configuration → Scoring Rules and enable User Scoring Rules.
The Scoring Rules table displays the user-defined rules and sub-rules.
2. Click Add Scoring Rule.
3. In the Create New Scoring Rule dialog, define the rule criteria:
1. Under Rule Name, enter a unique name for your rule.
2. Under Score, define the score that Cortex XDR should apply to alerts that matching the rule criteria.
3. Under Base Rule, select whether to create a top-level rule (labeled Root) or a sub-rule (labeled Rule Name (ID:#)). By default, rules are defined at
the root level.
4. Select or deselect 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. By default, a score is applied only to the first alert that matches the defined rule and sub-rule.
5. In the alert table, use the filters to define the alert attributes you want to include in the rule match criteria.
Example 18. Example
With this rule, Cortex XDR assigns a score of 30 to any XDR BIOC alerts with a severity level of Critical:
Score = 30
Base Rule = Root
Filters:
Alert Source=XDR BIOC AND Severity=Critical
4. Click Create.
You are automatically redirected to the Scoring Rules table.
5. In the Scoring Rules table, click Save to save your scoring rule.
For scoped users, a small lock icon indicates that you don't have permissions to edit a rule.
What to do next
After setting up your scoring rules, you can take the following actions:
See a breakdown of the score
You can see details about the scoring method and the assigned score.
1. Select Incident Response → Incidents.
2. On the Incidents page, click on the menu icon to switch to the detailed view.
3. Click on the assigned score.
If you are not satisfied with the score, you can change the scoring method, or overwrite the score by setting the score manually. If you see a discrepancy with
the assigned score, consider the following:
For rule-based scores, revise your scoring rules.
For SmartScores, help to improve the accuracy of SmartScore. Give feedback by hovering over the displayed score.
Change the scoring method or set the score manually
You can change the default scoring method. In addition, if Cortex XDR was unable to assign a score, you can set the score manually.
1. Select Incident Response → Incidents.
Displayed in the footer
Page 320 of 952
Cortex XDR Documentation
Displayed in the header
2. On the Incidents page, click on the menu icon to switch to the detailed view.
3. Click on the assigned score.
If no score was assigned, in the incident pane click the more options icon and select Manage Score.
4. Select a different scoring method, or click Set score manually and define a new score.
Revise existing scoring rules
In the Scoring Rules table, take the following actions to review your rules and sub-rules:
Use the arrows to rearrange rule priorities. Make sure to click Save after any changes.
Select one or more rules and right-click to see the available actions.
Scope-Based Access Control considerations
Incident Scoring supports Scope-Based Access Control (SBAC). If you're a scoped user, a small lock icon indicates that you don't have permissions to edit a
rule. The following parameters are considered when editing a scoring 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.
To change the order of a rule, you must have permissions to the other rules 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.
14.3 | Automation rules
Abstract
Automation rules enable you to create rules comprised of alert conditions that trigger an action.
This functionality requires a Cortex XDR Pro license.
Cortex XDR provides an easy way to automate the day to day activities of SOC analysts. Automation rules enable you to define alert conditions that trigger the
action that you specify within the rule. As alerts are created, Cortex XDR checks if the alert matches any of the alert conditions from the automated rules, and if
there is a match, the corresponding action is triggered. The automation rules only apply to new alerts which will either create a new incident or be combined
with an existing one.
Automation rules only apply to alerts that are grouped into incidents by the system. Most alerts with low and informational severity do not allow an automation
rule to be automatically executed on them.
The automation rules run in the order they're created. You can drag the rules to change the order. If you select the setting Stop processing after this rule within
a rule, the rule is still processed, but the rules following are not processed if alert conditions are met.
Automation rules 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.
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.
The Automation Rules page displays a table of all the rules created. The following table describes the fields.
Read more...
Displayed in the footer
Page 321 of 952
Cortex XDR Documentation
Displayed in the header
Field Description
Action Action that is triggered when the alert matches the condition configured within the automation rule.
The options are:
Communication
Send email
Send Slack message
Syslog forwarding
Alert and Incident Management
Assign incident
Set alert severity
Set alert status
Forensics
Forensic Triage
Requires the Forensics Add-on.
Endpoint Response
Isolate endpoint
Retrieve File
Run endpoint script
Run malware scan
Terminate Causality (CGO)
Action Parameters Required information for the action. For example, for the action Send email, you must enter the email of the person receiving the
notification.
Conditions Rule condition defined for the automation rule. For example Severity=Critical, where the rule triggers the action on all alerts where
Severity=Critical.
Triggering Alerts Number of alerts triggered by the automation rule.
Stop Processing Indicates whether the Stop processing after this rule is selected.
Status If the automation rule is enabled or disabled.
Excluded Endpoint IDs excluded from the automation rule.
Endpoints
Created by Name of the user that created the automation rule.
Modification Time Time when the automation rule was last modified.
14.3.1 | Automation settings
Abstract
Displayed in the footer
Page 322 of 952
Cortex XDR Documentation
Displayed in the header
Threshold limits may be implemented for settings of automation rules.
Before you begin creating automation rules, consider setting thresholds for the following endpoint actions:
Only the administrator can configure these settings.
Endpoint Action Limit Thresholds Description
Isolate endpoint on up to _ endpoints in _ hour/s When an alert condition is triggered, and the action specified is to isolate the endpoint, the
limit threshold defined enables the set number of endpoints to be isolated for the period of
time defined. This is to prevent an overflow of endpoints isolated from the network at the
same time.
If the setting is turned off, there is no threshold for the isolation of endpoints.
Run endpoint script on up to _ endpoints in _ hour/s When an alert condition is triggered, and the action specified is to run the endpoint script,
the limit threshold defined enables the set number of endpoints to run the script for the
period of time defined. This is to prevent an overflow of endpoints running scripts at the
same time.
If the setting is turned off, there is no threshold for the running scripts on the endpoints.
Terminate Causality (CGO) on up to _ endpoints in _ hour/s When an alert condition is triggered, and the action specified is to terminate causality, the
limit threshold defined enables the set number of endpoints to terminate the causality chain
of processes for the period of time defined. This is to prevent an overflow of endpoints
terminating causality chain of processes at the same time.
If the setting is turned off, there is no threshold for terminating causality on the endpoints.
Forensic Triage on up to _ endpoints in _ hour/s When an alert condition is triggered, and the action specified is set to Forensic Triage, the
limit threshold defined enables the set number of endpoints to triage for the period of time
defined. This is to prevent an overflow of endpoints to triage at the same time.
If the setting is turned off, there is no threshold for the running scripts on the endpoints.
This option is only accessible to users that have the forensics add-on license.
Automation Rule Notifications Description
Distribution List Enter the email of the people to notify
Slack Enter the slack contact to notify.
14.3.2 | Automation rule actions
Abstract
Includes the list of actions to take when the alert condition of the automation rule is triggered for Cortex XDR.
When creating the automation rule, the action is triggered when an alert matches the condition of the automation rule.
You can configure the following types of actions:
Displayed in the footer
Page 323 of 952
Cortex XDR Documentation
Displayed in the header
Action Settings
Communication Choose one of the options to receive notifications to keep up with alerts.
Send email
Send Slack message
Syslog forwarding—The list of servers displayed are the servers
integrated with the Cortex XDR tenant.
Alert and Incident Management
Assign Incident Assign the incident that is linked to the alert.
Assign Condition
(Default) Assign only to unassigned incidents
Always assign
Assign To—Select the person from the list to assign the incident.
Set alert status Alert Status—Select alert status to override the present status of the alert.
New
Under Investigation
Resolved
Set alert severity Alert Severity—Select alert severity to override the present severity of the
alert.
Critical
High
Medium
Low
Forensics
Forensics Triage Triage Configuration
Select the triage configuration from the list.
Endpoint Response
Displayed in the footer
Page 324 of 952
Cortex XDR Documentation
Displayed in the header
Action Settings
Run endpoint script Run the Action On.
Alert initiator host—The host specified under Host of the alert from the
Alerts table.
Alert remote host—The host specified under Remote Host of the alert
in the Alerts table.
Script.
Script Library
Script—Select the script from the list to run on the endpoint.
The scripts listed are from the Script Library.
Script Timeout (Seconds)—Enter seconds for timeout.
Code Snippet
Script—Add commands to create a script to run on the
endpoint.
Script Timeout (Seconds)—Enter seconds for timeout
Isolate endpoint/Run malware scan Run the action on.
Alert initiator host—The host specified under Host of the alert from the
Alerts table.
Alert remote host—The host specified under Remote Host of the alert
in the Alerts table.
Retrieve File Retrieve File from.
Alert initiator file—The file specified under Initiator Path of the alert
from the Alerts table.
Alert causality group owner path—The path specified under CGO
path of the alert from the Alerts table.
Terminate Causality (CGO) Select this option to terminate the causality chain of processes associated
with the alert/s of the automation rule.
Stop processing after this rule The current rule is the last to be processed only if triggered.
14.3.3 | Automation audit log
Abstract
Includes the list of fields included in the automation audit log for Cortex XDR.
The Automation Audit Log shows all the records of all the automation rule executions, included successful, failed and paused actions.
Right-click on a record and select View triggering alert to view the details of the alert in the Alerts table. Only If the record is an Endpoint Response action, you
can select View in Action Center, to view details of the action in the Action Center.
The Automation Audit Log fields includes the following information.
Displayed in the footer
Page 325 of 952
Cortex XDR Documentation
Displayed in the header
Field Description
Timestamp The date and time of the last time the automation rule was triggered.
Action The action that was triggered.
Trigger Status The status of the action— Success, fail, or pause.
Description Details of the trigger status.
Triggering Alert ID The ID of the alert that was triggered by the automation rule.
Automation Rule ID The ID of the automation rule.
Automation Rule Version The version number that is updated every time the rule's conditions or actions are modified.
15 | Investigate and respond to incidents
Abstract
Learn about the Cortex XDR investigation and response operations.
Investigate and respond to malicious activity in your network using different actions.
15.1 | Incident handling
Abstract
Learn about how incidents are created, the information contained in an incident, and how to prioritize and manage incidents.
In the following topics you will learn about how incidents are created, the information contained in an incident, and how to prioritize and manage incidents.
15.1.1 | What are incidents?
Abstract
Learn about how incidents are created, incident terminology, incident thresholds, and incident planning and response
An incident represents a single, self-contained attack.
An incident is a container object to group related alerts, assets, and artifacts, that originate from a single root cause. The root cause might be a self-contained
cyberattack that brings multiple actors together to attack (such as attackers, tools, and processes), or it might be a combination of malware and exploits.
Incidents comprise the following objects:
Alerts: Notification objects to report suspicious activity or events
Assets: Names of affected endpoints and users
Artifacts: Attributes of attacking objects such as filenames, file signers, processes, domains, and IP addresses
Each incident is individually configured and requires its own independent investigation. To see a list of all Incidents, navigate to the Incidents page.
Incident thresholds
To keep incidents fresh and relevant, Cortex XDR implements the following thresholds. When the incident reaches a threshold, it stops accepting alerts and
groups subsequent related alerts in a new incident.
30 days after incident creation
14 days since the last alert in the incident was detected (excludes backward scan alerts).
An incident reaches the 1,000 alert limit.
Displayed in the footer
Page 326 of 952
Cortex XDR Documentation
Displayed in the header
You can track the threshold status in the Alerts Grouping Status field in the Incidents table.
15.1.2 | Understanding the Incidents page
Abstract
Use the Incidents page to review incident details and take remedial action.
The Incidents page is the first stop for investigating incidents. On the Incidents page you can see information about all incidents in your environment. You can
track and manage your incidents, investigate incident details, and take remedial action.
By default open incidents are displayed, but you can change the filters to browse through resolved incidents too. To make it easy for you to identify the most
critical incidents, Cortex XDR provides color coded icons that indicate severity, incident scores, and incident starring.
You can access the page from Incident Response → Incidents. The page is available in the following modes, and any changes that you make to the incident
fields will persist between modes.
Detailed view (default)
Displays incidents in a split pane format that provides key details of each incident and makes it easy to prioritize the most urgent incidents.
Table view
Displays incidents in a table format. For more information about the fields in the table view, see Incidents table view reference information.
From the Incidents page you can also access the Alerts Table to see a full list of alerts in the system.
Overview of the Incidents detailed view
The detailed view is a split paned format consisting of the list pane and the details pane. The list pane consolidates key information for each incident based on
filtering options. From the list you can identify the most critical attacks and start prioritizing your incidents. Click an incident in the list pane to see its full details
in the details pane.
The details pane includes two views, Advanced view and Legacy view. Use the Legacy view to view incidents from earlier versions. To change the view, select
Page View from the more options icon.
The details pane is split into the following sections and tabs:
Section Or Tab Description
Incident header Displays detailed key information and provides administration actions for the incident, such as assigning an analyst and
setting the status. Hover and click on a field for more information, and edit where required.
Overview Displays the main incident information including the MITRE ATT&CK tactics and techniques identified in the incident, the
number of alerts triggered, automation information about playbooks, and key artifacts and assets involved in the incident.
You can click any of the widgets to start your investigation.
Key Assets & Artifacts Displays the incident asset and artifact information of the key artifacts, hosts, and users associated with the incident. Hover
over an icon for more information, or click the more options icon to see the available views and actions. For more
information about investigating key assets and artifacts, see Investigate artifacts and assets.
Alerts & Insights Displays a table of alerts and insights associated with the incident. Click on an alert or insight to see more information in the
Details panel, or use the pivot menu to see the options for further investigation.
Timeline Displays a chronological representation of alerts and actions relating to the incident. Each timeline entry represents 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. Click on an entry to view additional details in the Details panel. You can also filter the timeline by action type.
Depending on the type of action, you can select the entry to further investigate and take action on the entry.
Executions Displays the alert causality chains associated with the incident. On this tab you can investigate a causality chain and take
actions on a host. For more information about investigating causality chains, see Causality view.
Displayed in the footer
Page 327 of 952
Cortex XDR Documentation
Displayed in the header
Select the pin icon next to a tab to set it as the default tab to open each time you investigate an incident.
15.1.2.1 | Incidents table view reference information
Abstract
Describes the fields in the table view.
The following table describes the fields in the Incidents page table view.
Read more...
Field Description
Alert Categories Alert categories that were triggered by the incident's alerts
Alerts Grouping Status Whether Alert Grouping is currently enabled
Alerts Breakdown Total number of alerts, broken down by severity
Assignee Email Email address of the incident assignee
Assigned To Incident assignee
Creation Time Date and time that the incident was created
Critical/High/Medium/Low Severity Alerts Number of critical, high, medium, or low severity alerts included in the incident
Hosts Hosts affected by the incident
Incident Description Description generated from the alert name of the first alert that was added to the
incident, the host and user affected, or number of users and hosts affected
Incident ID ID assigned to the incident
Incident Name User-defined incident name
Incident Sources List of sources that raised high and medium severity alerts in the incident
Last Updated Last time that a user took an action on the incident, or an alert was added to the
incident
MITRE ATT&CK Tactic Types of MITRE ATT&CK tactics that were triggered by the alerts in the incident
MITRE ATT&CK Technique Types of MITRE ATT&CK techniques and sub-techniques that were triggered by
the alerts in the incident
Resolve Comment User-added comment when setting the incident status to Resolved
Resolved Timestamp Date and time that the incident status was set to Resolved
Displayed in the footer
Page 328 of 952
Cortex XDR Documentation
Displayed in the header
Field Description
Severity Highest severity of the alerts in the incident, or the user-defined severity
Starred Whether the incident is starred.
Incidents are automatically starred if they include alerts that match your incident
prioritization policy.
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 Tag family and the corresponding tags. If SBAC is enabled, you can view and
manage the incident according your scope settings.
When you view incidents as a scoped user and the tenant is set to permissive
mode, you can view the incident but you do not have access to entities outside of
your scope.
When you view incidents as a scoped user and the tenant is set to restrictive
mode, the incident content is not visible. You can send the incident ID to your
administrator and request an updated user scope that enables you to view the
incident.
Total Alerts Total number of alerts in the incident
Users Users affected by the alerts in the incident
WildFire Hits Number of Malware, Phishing, and Grayware artifacts that are part of the incident
15.1.3 | Manage incidents
Abstract
Lean how to investigate and manage your incidents.
On the Incident view you can track incidents, investigate incident details, and take remedial action. Navigate to Incident Response → Incidents and locate the
incident you want to investigate.
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
The incident list provide a short summary of each incident to help you to quickly assess and prioritize your incidents:
1. Review the incident severity, score, and assignee. Select whether to Star the incident.
2. Review the status of the incident and when it was last updated.
3. Review the incident ID and incident summary.
4. Review the incident assets and alert sources:
Displayed in the footer
Page 329 of 952
Cortex XDR Documentation
Displayed in the header
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
Click on an incident to open the incident in the right panel. In the incident header 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.
3. Edit the incident description.
Hover over the incident description and select the pencil icon to edit the incident description.
4. Update the incident score.
Click on the assigned score to investigate how the score was calculated.
In the Manage Incident Score dialog displays all rules that contributed to the incident total score, including rules that have been deleted. Deleted scores
appear with a N/A.
You can override the Rule based score by selecting Set score manually or change the scoring method. For more information, see Incident scoring.
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. By updating the status you can 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 you think belong together. Click the more options icon and select Merge Incidents.
Read more...
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.
Read more...
1. Click the more options icon and select Create Exclusion.
2. Enter a rule name and description.
3. Filter the Alerts table to defined the alerts that you want to include in the policy.
4. Select whether to apply the rule to existing alerts.
5. Click Create.
9. Review the remediation suggestions. Click the more options icon to open the Remediation Suggestions dialog.
Remediation suggestions require a Cortex XDR Pro license.
10. Review the incident assets.
Displayed in the footer
Page 330 of 952
Cortex XDR Documentation
Displayed in the header
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.
Review the 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.
Cortex XDR 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.
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. Investigate information about the Alerts, Alert Sources, and Assets associated with the incident.
Requires a Cortex XDR Pro license.
Read more...
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 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.
3. Review the artifacts and asset that are associated with the incident.
You can click the more options icon next to an asset or artifact to open an associated view, or you can see more details in the Key Assets & Artifacts tab.
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. Investigate artifacts.
In the Artifacts section, search for and review the artifacts associated with the incident. Each artifact displays, if available, the artifact information and
available actions according to the type of artifact; File, IP Address, and Domain.
2. Investigate hosts.
In the Hosts section, search for and review the hosts associated with the incident. Each host displays, if available, host information and available actions.
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. If the Details
panel is not available, click the more options icon next to a host name to see the available options.
Displayed in the footer
Page 331 of 952
Cortex XDR Documentation
Displayed in the header
3. Investigate users.
In the Users section, search for and review the users associated with the incident. Each user displays, if available, the user information and available
actions
Investigate incident alerts and insights
The Alerts & Insights tab displays a table of the alerts and insights associated with the incident.
1. Use the table tabs to switch between alerts and insights, and add filters to the table to refine the displayed entries.
2. Click an alert or insight to open the Details panel.
Use the available actions listed in the top right-hand corner to take remedial actions.
Investigate the incident timeline
The incident Timeline tab is a chronological representation of alerts and actions relating to the incident.
1. Navigate to the Timeline tab and filter the actions according to the action type.
2. Investigate a 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:
For Response Actions and Incident Management Actions, you can add and view comments relating to the action.
For Alerts, click the action to open 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 the endpoint data, if available.
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.
15.1.3.1 | Resolution reasons for incidents and alerts
Abstract
Describes the resolution reasons for incidents and alerts.
When you resolve an incident or alert you must also specify a resolution reason. The following table describes the resolution reasons available for selection.
Resolution Reason Description
Resolved - True Positive The incident was correctly identified by Cortex XDR as a real threat, and the incident was successfully handled and resolved.
Incidents resolved as True Positive and False Positive help Cortex XDR 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
Incidents resolved as True Positive and False Positive help Cortex XDR 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.
Displayed in the footer
Page 332 of 952
Cortex XDR Documentation
Displayed in the header
Resolution Reason Description
Resolved - Security The incident is related to security testing or simulation activity such as a BAS, pentest, or red team activity.
Testing
Resolved - Known Issue The incident is related to an existing issue or an issue that is already being handled.
Resolved - Duplicate The incident is a duplicate of another incident.
Incident
15.2 | Investigate artifacts and assets
Abstract
You can investigate specific artifacts and assets on dedicated views related to IP address, Network Assets, and File and Process Hash information.
From the Incidents view, open the Key Assets & Artifact tab to see the assets and artifacts that are associated with the incident, including hosts, IP addresses,
and users. Icons represent properties of the artifacts and assets. Hover over an icon for more information. Click the more options icon to drill down in
dedicated views, or take actions on the asset or artifact. The Key Assets & Artifact tab shows the following information:
Artifacts
To aid you with threat investigation, Cortex XDR displays the WildFire-issued verdict for each key artifact in an incident. To provide additional verification
sources, you can integrate external threat intelligence services with Cortex XDR. For more information, see External integrations.
Assets
Displays Hosts and Users details. For hosts with a Cortex XDR agent installed, click on the host name to see more information in the Details panel.
15.2.1 | Investigate an IP address
Abstract
Investigate incidents, connections, and threat intelligence reports related to a specific IP address on the IP View.
Drilldown on an IP address on the IP View. On this view you can investigate and take actions on IP addresses, and see detailed information about an IP
address over a defined 24-hour or 7-day time frame. In addition, to help you determine whether an IP address is malicious, the IP View displays an interactive
visual representation of the collected activity for a specific IP address.
How to investigate an IP address
1. Open the IP View.
Right-click the IP address that you want to investigate and select Open IP View.
2. In the left panel, review the overview of the IP address.
The overview displays network operations, incidents, actions, and threat intelligence information relating to the selected IP address, and provides a
summary of the network operations and processes related to the IP address.
The displayed information and available actions are context specific.
a. Add an Alias or Comment to the IP address.
b. 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.
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 endpoint
identified by the IP address had an agent installed at that point in time.
c. Identify the IOC severity.
The color of the IP address value is color-coded to indicate the IOC severity.
d. Review threat intelligence for the IP address.
Depending on the threat intelligence sources that are integrated with Cortex XDR, the following threat intelligence might be available:
Displayed in the footer
Page 333 of 952
Cortex XDR Documentation
Displayed in the header
Virus Total score and report
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.
e. Review the related incidents.
Related Incidents lists the most recent incidents that contain the IP address as part of the incident’s 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 a specific incident, select the Incident ID.
3. In the right hand view, use the filter criteria to refine the scope of the IP address information that you want to visualize in the map.
In the Type field, select Host Insights to pivot to the Asset View of the host associated with the IP address, or select Network Connections to display the
IP View of the network connections made with the IP address.
4. Review the selected data.
Select each node for additional information.
Select Recent Outgoing Connections to view the most recent connections made by the IP address. Search all Outgoing Connections to run a
Network Connections query on all the connections made by the IP address.
5. Perform actions on IOC or EDL.
Depending on the current IOC and EDL status, the Actions button is displayed.
15.2.2 | Investigate an asset
Abstract
Investigate host assets and view host insights on the Asset View.
Drilldown on an asset on the Asset View. On this view you can investigate host assets, view host insights, and see a list of incidents related to a host.
The Asset view is available for hosts with a Cortex XDR agent installed.
How to investigate an asset
1. Open the Asset View.
Identify a host with a Cortex XDR agent installed and select Open Asset View.
2. In the left panel, review the overview of the host asset.
The overview displays the host name and any related incidents.
a. Add an Alias or Comment to the host name.
b. Review the related incidents.
Related Incidents lists the most recent incidents that contain the host as part of the incident’s key artifacts, according to the Last Updated
timestamp. To dive deeper into a specific incident, select the Incident ID.
3. In the right hand view, use the filter criteria to refine the scope of the host information that you want to display.
In the Type field, select one of the following:
Host Insights: View a list of the host artifacts.
Network Connections: Pivot to the IP view displaying the IP addresses associated with the host.
Host Risk View: View insights and profiling information. Available with the the Identity Threat Module.
4. Review the data.
Select Run insights collection to initiate a new collection. The next time the Cortex XDR agent connects, the insights are collected and displayed.
5. Perform actions on the host.
Displayed in the footer
Page 334 of 952
Cortex XDR Documentation
Displayed in the header
15.2.3 | Investigate a host
Abstract
Investigate host assets associated with your incidents
The Host Risk View requires the Identity Threat Module add-on.
Drilldown on a host on the Host Risk View. On this view you can see insights and profiling information about a host. When investigating alerts and incidents, you
can view anomalies in the context of the host that can help you to make better and faster decisions about risks. On the Host View View you can take the
following actions:
Assess the host's behavior and score.
Analyze the host's behavior over time, and compare it to peer hosts with the same asset role.
Review related incidents and past alerts for the host.
Star the host to be included in the watchlist.
How to investigate a host
1. Right-click the host that you want to investigate and select Open Host Risk View.
You can also see a list of all hosts under Assets → Asset Scores.
2. In the left panel, review the overview of the host.
The overview displays network operations, incidents, actions, and threat intelligence information relating to the selected host. You can see the host
score, the metadata aggregated by Cortex XDR, and review the CVEs breakdown by severity. The displayed information and available actions are
context specific.
Common Vulnerabilities and Exposures (CVE) are grouped by severity. For more information on each of the CVEs, refer to Related CVEs.
3. Review the Score Trend graph.
The graph is based on new incidents created within the selected time frame, and updates on past incidents that are still active. The straight line
represents the host score, which is based on the scores of the incidents associated with the host.
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.
4. Drilldown on a score for a specific day by clicking a bubble. Alternatively, review the host information for the selected timeframe (Last 7D, 30D, or
custom timeframe). The widgets in the right panel reflect the selected timeframe.
5. Review the Related Incidents for the selected timeframe or score selected in the Score Trend graph. If you are drilling down on a score, you can see the
incidents that contributed to the total score on the selected day. Review the following data:
The Status column provides visibility into the reason for the score change. For example, if an incident is resolved, its score will decrease, bringing
down the host score.
The Points column displays the risk score that the incident contributed to the host score. The points are calculated according to SmartScore or
Incident Scoring Rules.
6. Review the Related Alerts and Insights for the selected timeframe or score selected in the Score Trend graph.
The timeline displays all detection activities associated with the host. The alerts are grouped into buckets according to MITRE ATT&CK tactics. Click on a
tactic to filter the alerts in the table. To further investigate an alert, click the alert to open the Alert Panel and click Investigate.
7. Review the Latest Logins to Host during the selected timeframe or on the day selected in the Score Trend graph.
You can see details of the related login attempts, and whether the attempts were successful. To further investigate login activity for the host, click View In
XQL to link to a prefilled query in the Query Builder. Using Cortex Query Language you can create queries to refine your search.
8. Review the host's Latest Authentication Attempts during the selected timeframe or on the day selected in the Score Trend graph.
You can see details of the related authentication attempts, and whether the attempts were successful. To further investigate authentication attempts by
the host, click View In XQL to link to a prefilled query in the Query Builder. Using Cortex Query Language you can create queries to refine your search.
9. Review the Related CVEs during the selected timeframe or on the day selected in the Score Trend graph.
You can see details of the specified CVEs. This information can help you to access and prioritize security threats on each of the endpoints. To further
investigate related CVEs, click View In XQL to link to a prefilled query in the Query Builder. Using Cortex Query Language you can create queries to
refine your search.
10. For hosts with associated asset roles, compare the data with other peer hosts with the same asset role. In the Score Trend graph click Compare To and
select an asset role to which you want to compare the data.
Displayed in the footer
Page 335 of 952
Cortex XDR Documentation
Displayed in the header
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.
11. (Optional) Take actions on the host.
In the left panel, click Actions to see a list of available actions. Actions are context specific.
15.2.4 | Investigate a file and process hash
Abstract
Investigate incidents, actions, and threat intelligence reports related to a specific file or process hash on the Hash View.
Drilldown on a file or process hash on the Hash View. On this view you can investigate and take actions on SHA256 hash processes and files, and see
information about a specific SHA256 hash over a defined 24-hour or 7-day time frame. In addition, you can drill down on each of the process executions, file
operations, incidents, actions, and threat intelligence reports relating to the hash.
How to investigate a file or process hash
1. Open the Hash View.
Identify the file or process hash that you want to investigate and select Open Hash View.
2. In the left panel, review the overview of the hash.
a. Review the signature of the hash, if available.
b. Identify the WildFire verdict.
The color of the hash value is color-coded to indicate the WildFire report verdict:
WildFire color key
Blue—Benign
Yellow—Grayware
Red—Malware
Light gray—Unknown verdict
Dark gray—The verdict is inconclusive
c. Add an Alias or Comment to the hash value.
d. Review threat intelligence for the hash.
Depending on the threat intelligence sources that are integrated with Cortex XDR, the following threat intelligence might be available:
Virus Total score and report.
Requires a license key. Go to Settings → Configurations → Integrations → Threat Intelligence.
IOC Rule, if applicable, including the IOC Severity, Number of hits, and Source according to the color-coded values:
WildFire analysis report.
e. 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.
f. Review the recent open incidents that contain the hash as part of the incident's Key Artifacts according to the Last Updated timestamp. To dive
deeper into specific incidents, select the Incident ID.
3. In the right hand view, use the filter criteria to refine the scope of the IP address information that you want to visualize.
Filter criteria
Displayed in the footer
Page 336 of 952
Cortex XDR Documentation
Displayed in the header
Filter Description
Event Type Main set of values that you want to display. The values depend on the
selected type of process or file.
Primary Set of values that you want to apply as the primary set of aggregations.
Values depend on the selected Event Type.
Secondary Set of values that you want to apply as the secondary set of
aggregations.
Showing Number of Primary and Secondary aggregated values to display.
Timeframe Time period over which to display your defined set of values.
4. Review the selected data.
To view the most recent processes executed by the hash, select Recent Process Executions. To run a query on the hash, select Search all Process
Executions.
5. (Optional) Perform actions on the hash.
15.2.5 | Investigate a user
Abstract
Investigate user assets associated with your incidents.
Drilldown on a user in the User Risk View or the User View. On this view Cortex XDR aggregates all of the data collected for a user, displays the information in
graphs and tables, and provides further drilldown options for easy investigation. Cortex XDR uses Identity Analytics to aggregate information on a user and
displays insights about the user.
If the Identity Threat module is enabled you can open the User Risk View. 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.
If the Identity Threat module is not enabled you can open the User View. This view displays an overview of the user and information about the user's score and
activity.
You can take the following actions to investigate a user:
Assess the user's behavior and score.
Star the user to be included in the watchlist.
(User Risk View only) Review the user's working hours and related alerts.
(User Risk View only) Analyze the user's behavior over time and compare to their peers with the same asset role.
How to investigate a user
1. Right-click a user name and select Open User Risk View or Open User Card.
You can also see a list of all users under Assets → Asset Scores.
2. Select the timeframe to view the user's details.
Cortex XDR 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.
3. Investigate the user.
User Risk View
Review the sections of the User Risk View. Depending on your permissions, some information might be limited by your scope.
1. In the left panel, review the overview of the user:
Displayed in the footer
Page 337 of 952
Cortex XDR Documentation
Displayed in the header
User Score: Displays the 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.
Common Locations: Displays the countries from which the user connected most in the past few weeks.
Common UAs: Displays the user agents that the user used most in the past few weeks.
Regular Activity Hours: This data is based on the preceding several weeks and takes into account holidays and seasonality to present an
accurate picture. Cortex XDR leverages endpoint telemetry to provide the activity data.
2. Review the Score Trend graph.
The graph is based on new incidents created within the selected time frame, and updates on past incidents that are still active. The straight line
represents the user score, which is based on the scores of the incidents associated with the user.
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.
3. Drilldown on a score for a specific day by clicking a bubble. Alternatively, review the user information for the selected timeframe (Last 7D, 30D, or
custom timeframe). The widgets in the right panel reflect the selected timeframe.
4. Review the Related Incidents for the selected timeframe or score selected in the Score Trend graph. If you are drilling down on a score, you can
see the incidents that contributed to the total score on the selected day. Review the following data:
The Status column provides visibility into the reason for the score change. For example, if an incident is resolved, its score will decrease,
bringing down the host score.
The Points column displays the risk score that the incident contributed to the host score. The points are calculated according to SmartScore
or Incident Scoring Rules.
5. Review the Related Alerts and Insights for the selected timeframe or score selected in the Score Trend graph.
The timeline displays all detection activities associated with the user. The alerts are grouped into buckets according to MITRE ATT&CK tactics.
Click on a tactic to filter the alerts in the table. To further investigate an alert, click the alert to open the Alert Panel and click Investigate.
6. Review the user activity per day in the Actual Activity widget.
In this widget Cortex XDR compares the user's actual activity data with the Regular Activity Hours, and highlights any differences or anomalies in
the user's expected activity.
The cells are marked according to the activity that took place:, and a dashed frame indicates that Cortex XDR detected uncommon activity in the
time slot.
A dashed ribbon highlights discrepancies between regular activity hours and actual activity.
A colored ribbon indicates the level of activity on a specific day/hour.
A numbered ribbon indicates the number of alerts and insights that occurred on a specific day/hour.
7. Review the user's Login Attempts during the selected timeframe or on the day selected in the Score Trend graph.
You can see details of the related login attempts, and whether the attempts were successful. To further investigate login activity for the user, click
View In XQL to link to a prefilled query in the Query Builder. Using Cortex Query Language you can create queries to refine your search.
8. Review the user's Latest Authentication Attempts during the selected timeframe or on the day selected in the Score Trend graph.
You can see details of the related authentication attempts, and whether the attempts were successful. To further investigate authentication
attempts by the user, click View In XQL to link to a prefilled query in the Query Builder. Using Cortex Query Language you can create queries to
refine your search.
9. Review the user's SAAS Log activity during the selected timeframe or on the day selected in the Score Trend graph. You can see details of the
SaaS logs that were ingested into the platform in context of the user.
To further investigate SaaS log activity for the user, click View In XQL to link to a prefilled query in the Query Builder. Using Cortex Query Language
you can refine your search.
10. For users with associated asset roles, compare the data with other peers with the same asset role. In the Score Trend graph click Compare To and
select an asset role to which you want to compare the data.
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 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 user
name and pivot to additional views for further investigation.
User View
Review the sections of the User View. Depending on your permissions, some information might be limited by your scope.
Displayed in the footer
Page 338 of 952
Cortex XDR Documentation
Displayed in the header
1. In the left panel, review the overview of the user. The displayed information is aggregated by Cortex XDRfrom incidents, Workday, and Active
Directory data.
The User Score displays the score that is currently assigned to the user and is updated continuously as new alerts are associated with incidents.
2. Review the Score Trend graph.
The graph is based on new incidents created within the selected time frame, and updates on past incidents that are still active. The straight line
represents the user score, which is based on the scores of the incidents associated with the user.
Select a score to display in the Incidents table the incidents that contributed to the total user score on a specific day.
3. Click a score to drilldown on the score for a specific day. Alternatively, review the user information for the selected timeframe (Last 7D, 30D, or
custom timeframe).
The widgets in the right panel reflect the selected timeframe.
4. Review the Related Incidents for the selected timeframe or score selected in the Score Trend graph. If you are drilling down on a score, you can
see the incidents that contributed to the total score on the selected day. Review the following data:
The Status column provides visibility into the reason for the score change. For example, if an incident is resolved, its score will decrease,
bringing down the host score.
The Points column displays the risk score that the incident contributed to the host score. The points are calculated according to SmartScore
or Incident Scoring Rules.
5. Review the following additional widgets:
User Associated Insights
Top 5 Hosts Logged Into
Top 5 Authentication Target Hosts
Top 5 Authentication Source Hosts
Recent Login
Recent Authentications
15.3 | Investigate alerts
Abstract
Cortex XDR generates alerts to bring your attention to security risks in your framework.
Alerts help you to monitor and control the security of your system framework by alerting you to security risks in your framework. Cortex XDR generates alerts
from the following:
Rules that you set up, such as BIOC, IOC, correlation rules, etc.
Agents
Firewalls
Analytics
Integrations
Integrations enable you to ingest events, such as phishing emails, SIEM events, from third party security and management vendors. You might need to
configure the integrations to determine how events are classified as events. For example, for email integrations, you might want to classify items based
on the subject field, but for SIEM events, you want to classify by event type.
15.3.1 | Overview of the Alerts page
Abstract
The Alerts page consolidates all non-informational alerts from your detection sources, and helps you to analyze and triage the alerts on your system.
The Alerts page consolidates all non-informational alerts from your detection sources. This helps you efficiently triage the events you see each day. By
analyzing an alert, you can better understand the cause of the alert, and take actions where required. The default alert retention period in Cortex XDR is 186
days.
To access the Alerts page, go to Incident Response → Incidents → Alerts Table.
By default, the Alerts page displays the security alerts received over the last seven days. Every 12 hours, the system enforces a cleanup policy to remove the
oldest alerts once the maximum limit is exceeded.
Displayed in the footer
Page 339 of 952
Cortex XDR Documentation
Displayed in the header
To see detailed information about an alert, click an alert to open the alert panel. To investigate further, from the alert panel click Investigate or Investigate
Causality Chain. For more information, see Triage and investigate alerts.
Standardized format of user names in alerts
Cortex XDR processes and displays the names 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 XDR Analytics and Cortex XDR Analytics BIOC, including BIOC, and IOC alerts triggered on one of these event
types.
Featured fields
You can 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. For more information, see Create a featured alert field.
Alert field descriptions
The following table describes both the default fields and additional optional fields that you can add to the alerts table using the column manager.
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.
ACTION Action taken by the alert sensor, either Detected or Prevented with action
status displayed in parenthesis.
AGENT OS SUB TYPE Operating system subtype of the agent from which the alert was triggered.
ALERT ARRIVAL TIMESTAMP Time that the alert was stored in Cortex XDR.
ALERT ID Unique identifier that Cortex XDR assigns to each alert.
ALERT NAME Module that triggered the alert. Alerts that match an alert starring policy also
display a purple star.
ALERT SOURCE Source of the alert.
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.
Displayed in the footer
Page 340 of 952
Cortex XDR Documentation
Displayed in the header
Field Description
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 Cortex XDR agent
alert category is Exploit Modules.
CGO CMD Command-line arguments of the Causality Group Owner.
CGO MD5 MD5 value of the CGO that initiated the alert.
CGO NAME Name of the process that started the causality chain is based on Cortex XDR
causality logic.
CGO SHA256 SHA256 value of the CGO that initiated the alert.
CGO SIGNATURE Signing status of the CGO
CGO SIGNER Name of the software publishing vendor that signed the file in the causality chain
that led up to the alert.
Cortex XDR 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 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 Name of the cloud provider where the alert occurred.
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.
Displayed in the footer
Page 341 of 952
Cortex XDR Documentation
Displayed in the header
Field Description
CLOUD RESOURCE SUB-TYPE Specific classification is used to map the types of resources. For example,
DISK, VPC, and Subnet are all mapped to Compute.
CONTAINS FEATURED HOST Whether the alert includes a host name that has been flagged as a Featured
Alert Field.
CONTAINS FEATURED USER Whether the alert includes a user name that has been flagged as a Featured
Alert Field.
CONTAINS FEATURED IP ADDRESS 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 XDR .
DESCRIPTION Text summary of the event including the alert source, alert name, severity, and
file path.
DESTINATION ZONE NAME Destination zone of the connection for firewall alerts.
DNS Query Name Domain name is queried in the DNS request.
EMAIL RECIPIENT Email recipient value of a firewall alerts triggered on the content of a malicious
email.
EMAIL SENDER Email sender value of a firewall alerts triggered on the content of a malicious
email.
EMAIL SUBJECT Email subject value of a firewall alerts triggered on the content of a malicious
email.
EVENT TYPE Type of event on which the alert was triggered.
EXCLUDED Whether the alert is excluded by an exclusion configuration.
EXTERNAL ID Alert ID as recorded in the detector from which this alert was sent.
FILE PATH Path to the file on the endpoint, for alerts that are triggered on a file (the Event
Type is File).
FILE MACRO SHA256 SHA256 hash value of a Microsoft Office file macro.
FILE MD5 MD5 hash value of the file.
FILE SHA256 SHA256 hash value of the file.
Displayed in the footer
Page 342 of 952
Cortex XDR Documentation
Displayed in the header
Field Description
FW NAME Name of firewall on which a firewall alert was raised.
FW RULE ID Firewall rule ID that triggered the firewall alert.
FW RULE NAME Firewall rule name that matches the network traffic that triggered the firewall
alert.
FW SERIAL NUMBER Serial number of the firewall that raised the firewall alert.
HOST 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 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 ID of any incident that includes the alert.
INITIATED BY Name of the process that initiated an activity such as a network connection or
registry change.
INITIATOR MD5 MD5 value of the process which initiated the alert.
INITIATOR SHA256 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.
INITIATOR PATH Path of the initiating process.
INITIATOR PID Process ID (PID) of the initiating process.
Displayed in the footer
Page 343 of 952
Cortex XDR Documentation
Displayed in the header
Field Description
INITIATOR SIGNER Signer of the process that triggered the alert.
Cortex XDR can display both the O (Organization) value and the CN (Common
Name).
INITIATOR TID Thread ID (TID) of the initiating process.
IS PHISHING Whether a firewall alert is classified as phishing.
LOCAL IP IP address of the host that triggered the alert, for alerts that are triggered on
network activity (the Event Type is Network Connection).
LOCAL PORT Port on the endpoint that triggered the alert, for alerts that are triggered on
network activity (the Event Type is Network Connection).
MAC ADDRESS MAC address on which the alert was triggered.
MISC Miscellaneous information about the alert.
MITRE ATT&CK TACTIC Type of MITRE ATT&CK tactic on which the alert was triggered.
MITRE ATT&CK TECHNIQUE Type of MITRE ATT&CK technique and sub‑technique on which the alert was
triggered.
MODULE For Cortex 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.
OS PARENT SIGNATURE Signing status of the operating system of the activity.
OS PARENT SIGNER Parent operating system signer.
Cortex XDR 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.
Displayed in the footer
Page 344 of 952
Cortex XDR Documentation
Displayed in the header
Field Description
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.
PROCESS EXECUTION SIGNER Signer of the process that triggered the alert.
Cortex XDR can display both the O (Organization) value and the CN (Common
Name).
REGISTRY DATA Registry data that triggered the alert, for alerts that are triggered on registry
modifications (the Event Type is Registry).
REGISTRY FULL KEY Full registry key that triggered the alert, for alerts that are triggered on registry
modifications (the Event Type is Registry).
REMOTE HOST Remote host name that triggered the alert, for alerts that are triggered on
network activity (the Event Type is Network Connection).
REMOTE IP Remote IP address of a network operation that triggered the alert.
REMOTE PORT Remote port of a network operation that triggered the alert.
RESOLUTION STATUS Status that was assigned to this alert when it was triggered (or modified). Right-
click an alert to change the status. If you set the status to Resolved, select a
resolution reason.
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 XDR continues to group alerts to an Auto-Resolved Incident
for up to six hours. In the case where an alert is triggered during this duration,
Cortex XDR re-opens the incident.
RULE ID ID that matches the rule that triggered the alert.
SEVERITY Severity that was assigned to this alert when it was triggered (or modified).
STARRED Whether the alert is starred by starring configuration.
SOURCE ZONE NAME Source zone name of the connection for firewall alerts.
Displayed in the footer
Page 345 of 952
Cortex XDR Documentation
Displayed in the header
Field Description
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.
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 SHA256 hash value of an external DLL file that triggered the alert.
TARGET PROCESS CMD Command line of the process whose creation triggered the alert.
TARGET PROCESS NAME Name of the process whose creation triggered the alert.
TARGET PROCESS SHA256 SHA256 value of the process whose creation triggered the alert.
TIMESTAMP Date and time when the alert occurred in the source origin. For example, when
the alert occurred in the XDR agent.
Right-click to show rows 30 days prior or 30 days after the selected timestamp
field value.
URL URL destination address of the domain triggering the firewall alert.
USER NAME 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.
15.3.2 | Triage and investigate alerts
Abstract
You can triage, investigate, and take actions on alerts from the Alerts page.
Displayed in the footer
Page 346 of 952
Cortex XDR Documentation
Displayed in the header
All alerts are displayed 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.
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.
3. If deemed malicious, consider responding by isolating the endpoint from the network.
4. Remediate the endpoint and return the endpoint from isolation.
15.3.2.1 | Copy alerts
Abstract
You can copy an alert into memory.
You can copy alert text into memory and paste them into an email. This is helpful if you need to share or discuss a specific alert with someone. If you copy a
field value, you can also paste it into a search or begin a query.
How to copy an alert value
1. From the Alerts page, right-click the alert you want to send.
2. Select one of the following options: Copy alert URL.
Copy text to clipboard
Copy entire row
Copy alert URL
Cortex XDR saves the copied text to memory.
3. Paste the URL into an email or use it as needed to share the information.
15.3.2.2 | Analyze an alert
Abstract
Learn more about analyzing alerts in the alert side panel and the causality view.
To help you understand the full context of an alert, Cortex XDR provides the alert side panel 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.
How to view alert analysis
1. From the Alerts page, locate the alert you want to analyze.
2. Click the alert and review the information in the alert side panel. If you want to see more information about the alert, click Investigate to open the alert
investigation panel.
3. Right-click anywhere in the alert, and select Investigate Causality Chain.
You can also view the causality chain over time using the Timeline view.
4. Review the chain of execution and available data for the process and, if available, navigate through the process tree.
15.3.2.3 | Create profile exceptions
Abstract
You can create profile exceptions for agent alerts.
For Cortex XDR agent alerts, you can create profile exceptions for Window processes, BTP, and JAVA deserialization alerts directly from the Alerts table.
1. Identify an XDR Agent alert which has a category of Exploit, right-click and select Create alert exception.
Displayed in the footer
Page 347 of 952
Cortex XDR Documentation
Displayed in the header
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. Click Add to add the scope.
4. (Optional) View your profile exceptions.
a. Go 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.
15.3.2.4 | Add a file path to a malware profile allow list
Abstract
You can add a file path to an existing malware profile.
During investigation, if you deem a file path to be safe you can add the 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. Go 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.
For more information about malware prevention profiles, see Set up malware prevention profiles.
15.3.2.5 | Create a featured alert field
Abstract
You can label specific alert attributes as featured alert fields.
Featured alert fields require a Cortex XDR Pro license.
To help you to track alerts involving specific hosts, users, and IP addresses, you can label specific alert attributes as featured fields. Alerts that contain a
matching featured field value are identified with a flag in the Alert Name field of the Alerts table. After setting up featured fields, you can use them filter the
Alerts table and to create incident scoring rules.
Featured Active Directory values are displayed in the User and Host fields accordingly.
How to create a featured alert field
1. Go to Incident Response → Incident Configuration → Featured Fields and select a type of featured field.
2. Click Add featured <field-type> and select one of the following options:
Create New
To create a new featured alert field from scratch, enter one or more field-type values and click Add.
Upload from File
To upload field values from a CSV file, upload your file and click Import. Click Download example file to ensure you are using the correct format.
3. Find alerts containing featured alert fields.
In the Alerts table, use the Contains Featured filters.
4. (Optional) Create an incident scoring rule using the Contains Featured fields to further highlight and prioritize alerts containing the Host, User, and IP
address attributes. For more information, see Set up incident scoring.
Displayed in the footer
Page 348 of 952
Cortex XDR Documentation
Displayed in the header
15.3.2.6 | View generating BIOC or IOC rule
Abstract
You can view the BIOC or IOC rules that generated alerts directly from the Alerts table.
This functionality requires a Cortex XDR Pro license.
You can easily view and edit the BIOC and 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 XDR 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.
15.3.2.7 | Retrieve additional alert details
Abstract
Access additional information relating to an alert, including related files and memory content analysis.
To help you with alert analysis, Cortex XDR can provide related files and memory content analysis.
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 XDR can provide related files and additional analysis of the memory contents when an exploit protection module
raises an alert.
This option requires the XTH add-on to be enabled.
For tenants without XTH, select Get Causlity Data to analyze additional data.
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 XDR to automatically retrieve alert data for every relevant alert. After Cortex XDR 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.
Retrieve related files: To further examine files that are involved in an alert, you can request the agent send them to the Cortex XDR 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 XDR. 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.
If you require assistance from Palo Alto Networks support to investigate the alert, make sure to provide the downloaded ZIP file.
15.3.2.8 | 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 XDR exports the filtered result set to the TSV file.
Displayed in the footer
Page 349 of 952
Cortex XDR Documentation
Displayed in the header
15.3.2.9 | Exclude an alert
Abstract
You can exclude alerts that are not deemed to be a threat.
This functionality requires a Cortex XDR Pro license.
During the process of triaging and investigating alerts, you might determine that an alert does not indicate threat. You can choose to exclude the alert, which
hides the alert, excludes it from incidents, and excludes it from search query results.
You can also set up alert exclusion rules that automatically exclude alerts that match certain criteria. For more information, see Alert exclusions.
How 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.
15.3.2.10 | Investigate contributing events
Abstract
You can investigate the events created by an alert.
This functionality requires a Cortex XDR Pro license.
When investigating an alert generated by a correlation rule, you can view all of the events created for the alert. You can have up to 1000 events per correlation
rule.
In addition, if the correlation rule includes a drilldown query you can run the query in the Query Builder. The drilldown query provides additional information
about an alert for further investigation.
How to investigate contributing events
1. From the Alerts page, locate an alert created by a correlation rule.
2. Right-click the row, and select Manage Alert → Investigate Contributing Events.
3. (Optional) Open the drilldown query, if available.
Right-click the row and select Manage Alert → Open Drilldown Query.
The drilldown query can accept parameters from the alert output for the correlation rule. In addition, the alert time frame used to run the drilldown query
provides more 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.
15.3.2.11 | Query incident and alert data
Abstract
You can run queries on incident and alert data with the incidents and alerts datasets.
XQL queries are available in Cortex XDR Pro only.
You can query incident and alert data in the incidents and alerts datasets. When using the alerts dataset, keep in mind the following:
Info alerts are not included in the this dataset.
Alert fields are limited to certain fields available in the API. For the full list, see Get Alerts Multi-Events v2 API.
15.3.2.12 | Manage automation rules
Abstract
Procedure of how to manage the automation rules of Cortex XDR as needed, which includes to edit, save as new, disable, delete or copy.
This functionality requires a Cortex XDR Pro license.
Before you create or manage automation rules, go to Settings → Configuration → Automation Settings and configure the settings for Endpoint Action Limit
Thresholds and Automation Rules Notifications.
Displayed in the footer
Page 350 of 952
Cortex XDR Documentation
Displayed in the header
You can add or edit an automation rule to trigger an action when the alert matches the condition of the rule created.
1. Navigate to Incident Response → Response → Automation and select Automation Rules.
2. Click Add Automation Rule, or to edit and existing rule hover over the rule and select the edit icon.
3. Define 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. From list, select the relevant action to initiate when the alert condition is triggered.
5. In the Exclude Endpoints page, select the endpoints to exclude and click Next.
This option is only accessible to Action type Endpoint Response.
6. In the Summary page, verify the settings and click Done.
7. Manage the automation rule, as needed. Right-click a rule to see the available actions.
15.3.3 | Alert investigation views
Abstract
From the Alerts page, you can pivot on an alert to open the alert investigation views.
On the Alerts page, click on an alert to open the alert panel, or right-click to pivot to an investigation view.
15.3.3.1 | Alert side panel
Abstract
The alert side panel provides detailed information about alerts at a glance and in the context of the incident.
The alert side panel provides detailed information about alerts at a glance and in the context of the incident. To open the alerts panel, on the Alerts page 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. The panel displays the name
and description of the alert, the source that triggered the alert, and the following details where applicable:
Displayed in the footer
Page 351 of 952
Cortex XDR Documentation
Displayed in the header
General: Displays general information about the alert.
Read more...
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 XDR 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: As applied by Cortex XDR
Behavioral analytics: Displays graphs that visualize the anomalies that were observed by the detector.
Read more...
The Behavioral Analytics section is available only when the Identity Threat Module add-on is enabled. Cortex XDR displays Behavioral Analytics widgets
for selected alerts and is continuously adding widgets to more alerts.
You can use this section 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.
MITRE ATT&CK: Displays the MITRE ATT&CK tactics and techniques.
Host: Displays the Host platform, Host name, Host IP, Host MAC address, Host FQDN.
Rule: Displays details about the alert that triggered the rule.
Connection details: Displays information about network connections, login, process execution, RPC calls, system calls, or registry events.
Cloud audit log: Displays the audit log details for alerts generated on cloud hosts.
15.3.3.2 | Causality view
Abstract
See the causality of an alert—the entire process execution chain that led up to the alert in the Cortex XDR 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 XDR or sent to Cortex XDR 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 provides information to help you understand
what happened around the alert.
The causality view comprises the following sections:
Information overview
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.
There are no CGOs in the cloud causality view, when investigating cloud Cortex XDR 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:
Displayed in the footer
Page 352 of 952
Cortex XDR Documentation
Displayed in the header
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.
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 XDR 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. 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 XDR 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.
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.
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.
All Events table
The All 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 XDR 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:
Displayed in the footer
Page 353 of 952
Cortex XDR Documentation
Displayed in the header
Add <path type> to malware profile allow list from the Process and File table. 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.
To view statistics for files on VirusTotal, you can pivot from the Initiator MD5 or SHA256 value of the file on the Files tab.
15.3.3.3 | Network causality view
Abstract
The network causality view shows a chain of individual network processes that together and in a particular sequence of operation triggered an alert.
Requires a Cortex XDR Pro license.
The network causality view provides a powerful way to analyze and respond to the stitched firewall and endpoint alerts. The scope of the network causality
view is the Causality Instance (CI) to which this alert pertains. The network causality view presents the network processes that triggered the alert, generated by
Cortex XDR, 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 XDR 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.
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 the following 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 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.
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 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 XDR 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.
Displayed in the footer
Page 354 of 952
Cortex XDR Documentation
Displayed in the header
Blue: Benign.
Yellow: Grayware.
Red: Malware.
Light gray: Unknown verdict.
Dark gray: The verdict is inconclusive.
You can view and download the WildFire report in the Entity Data section.
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.
All 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.
To view statistics for files on VirusTotal, you can pivot from the Initiator MD5 or SHA256 value of the file on the Files tab.
15.3.3.4 | 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 XDR app.
Requires a Cortex XDR Pro license.
The cloud causality view provides a powerful way to analyze and respond to Cortex XDR 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 XDR provides information to help you understand what happened
around the event.
The cloud 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 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.
The causality view provides an interactive way to view the CI chain for an alert. You can extend the CI chain, modify it, and move the chain around by selecting
and dragging it. You can also enlarge or shrink the chain by using the size controls. To return the chain to its original position and size, click in the lower-right
of the CI graph.
Causality data is displayed as follows:
Displayed in the footer
Page 355 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR displays information on the following
resources:
Read more...
Icon Type Of Resource
Compute instance resource
Disk resource
General resource
Image 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.
All Events table
Displays up to 100,000 related events and up to 1,000 related alerts. In the All Events table, Cortex XDR displays detailed information about each of the related
events. To simplify your investigation, Cortex XDR scans your Cortex XDR 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.
Displayed in the footer
Page 356 of 952
Cortex XDR Documentation
Displayed in the header
To continue the investigation, in the Alerts table, right-click an alert to see the available actions.
15.3.3.5 | 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.
Requires a Cortex XDR Pro license.
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 XDR 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 XDR 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 XDR alerts
generated from any IOC, BIOC, or correlation rules, including SaaS events. The SaaS causality view is available from the Alerts table, or from the Query Results
after running a query on the SaaS related data. 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 XDR provides information to help you
understand what happened around the event.
The SaaS causality view contains the following sections:
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.
Displayed in the footer
Page 357 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR displays information on the following resources.
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.
Types of resource
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
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.
All Events table
Displays up to 100,000 related events and up to 1,000 related alerts. In the All Events table, Cortex XDR displays detailed information about each of the related
events. To simplify your investigation, Cortex XDR scans your Cortex XDR 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.
To continue the investigation, in the Alerts table, right-click an alert to see the available actions.
Displayed in the footer
Page 358 of 952
Cortex XDR Documentation
Displayed in the header
15.3.3.6 | Analytics alert view
Abstract
From the Cortex XDR management console, you can view a detailed summary of the behavior that triggered analytics alerts.
Requires a Cortex XDR Pro license.
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.
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.
Alert summary
(Analytics alerts only) Describes the behavior that triggered the alert and activity impact.
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.
Right-click on a node to view additional information.
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: Displays all the event types associated with the alert in the in the All Events table.
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.
All 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.
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.
Displayed in the footer
Page 359 of 952
Cortex XDR Documentation
Displayed in the header
15.3.3.7 | Timeline
Abstract
From the Cortex XDR tenant you can view the sequence (or timeline) of events and alerts that are involved in any particular threat.
Requires a Cortex XDR Pro license.
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 XDR identifies as important or interesting, the Timeline displays all related events,
alerts, and informational BIOCs and correlation rules over time.
The Timeline view is not available when investigating cloud Cortex XDR 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.
The Timeline comprises the following parts:
CGO and process instances that are part of the CGO
Cortex XDR displays the Causality Group Owner (CGO) and the host on which the CGO ran in the top left of the timeline. The CGO is the parent process in the
execution chain that Cortex XDR 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 XDR 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 BIOCs
Cortex XDR displays up to 100,000 alerts, BIOCs and Correlation Rules (triggered and informational), and events. Click on a node in the activity area of the
Timeline to filter the results. You also can create filters to search for specific events.
15.4 | Investigate endpoints
Abstract
You can investigate and take actions on your endpoints in the Action Center.
Endpoint investigation requires either a Cortex XDR Prevent or a Cortex XDR Pro per Endpoint license.
You can investigate and take actions on your endpoints in the Action Center.
15.4.1 | Overview of the Action Center
Abstract
From the Action Center, you can track the progress of all investigation, response, and maintenance actions performed on your endpoints.
The Action Center is a central location from which you can track the progress of all investigation, response, and maintenance actions performed on your Cortex
XDR protected endpoints. The main All Actions tab displays the most recent actions initiated in your deployment. To narrow down the results, use the table
filters.
Displayed in the footer
Page 360 of 952
Cortex XDR Documentation
Displayed in the header
You can also choose from the filtered Action Center views to see details of the following actions:
File 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 and Allow List: View files that are permitted and blocked from running on your endpoints regardless of file verdict.
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.
Endpoint Isolation: View the endpoints in your organization that have been isolated from the network. For more information, see 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 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 XDR 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 XDR and is no longer displayed in the Action Center.
You cannot delete actions manually.
15.4.1.1 | Initiate and monitor endpoint actions
Abstract
Take these steps to initiate and monitor actions on your endpoints.
In the Action Center you can initiate and monitor actions on your endpoints. In addition, you can initiate endpoint actions when viewing details about an
endpoint on the All Endpoints page.
Initiate an endpoint action from the Action Center
Create new administrative actions using the Action Center wizard:
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 XDR displays only the endpoints eligible for the action you want to perform.
3. Review the action summary and click Done.
Cortex XDR will inform you if any of the agents in your action scope will be skipped.
4. Track your action.
Track the new action in the Action Center. The action status is updated according to the action progress.
Monitor endpoint actions
1. Go to Incident Response → Response → Action Center.
2. Select the relevant view from the left-side menu on the Action Center page.
3. Use the table filters to filter the results.
4. Take further actions. Right-click the action to see the available options:
Additional data: Display additional 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.
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.
Displayed in the footer
Page 361 of 952
Cortex XDR Documentation
Displayed in the header
15.4.1.2 | Action Center reference information
Abstract
See descriptions of the fields in 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.
Read more...
Field Description
Action Type Type of action initiated on the endpoint.
Agent Restart Status of the restart action on the endpoint.
Statuses:
In progress: Action initiated, but no start indication from agent after stop.
Failed: Agent reports failed back to the Cortex XDR server if it was
started after more than 10 minutes after restart initiation.
Expired: After 4 days.
Success: Agent reports success to the Cortex XDR server if it was
started within 10 minutes after restart initiation.
Created By Name of the user who initiated the action.
Creation Timestamp Date and time the action was created.
Description Action scope of affected endpoints and additional data relevant to each of the
specific actions, such as agent version, file path, and file hash.
Expiration Date Time the action will expire. To set an expiration date, the action must apply to
one or more endpoints.
By default, Cortex XDR 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 Current status of the action.
Additional data: If additional details are available for an action or for specific endpoints, you can pivot 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.
Displayed in the footer
Page 362 of 952
Cortex XDR Documentation
Displayed in the header
Field Description
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.
Advanced Analysis For Retrieve alert data requests related to Cortex XDR alerts triggered by
exploit protection modules, Cortex XDR 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.
15.4.2 | Manage endpoints
Abstract
You can view and take actions on endpoints on the All Endpoints page.
The 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 accurate list of endpoints, you can perform a one-time or periodic cleanup of duplicated entities. After
the cleanup, duplicated entities are removed leaving only one endpoint entry, which is 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.
Go to Settings → Configurations → General → Agent Configurations → Endpoint Administration Cleanup. Enable the Periodic duplicate cleanup and select
either One-time cleanup or define a periodic cleanup to run according to the Host Name, Host IP Address, and/or MAC Address fields at a specific time
interval.
Endpoint actions
The right-click pivot menu displays the actions you can perform on your endpoints. For more information about these actions, see the topics in this section, and
the topics under Manage endpoint protection.
For the Include endpoints from auto upgrade action, you cannot enable auto upgrade for Mobile, VDI, and TS installations.
All Endpoints reference information
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.
Field Description
Active Directory Active Directory Groups and Organizational Units to which the user belongs.
Assigned Extensions Policy Policy related to extensions and devices connected to the endpoint.
Displayed in the footer
Page 363 of 952
Cortex XDR Documentation
Displayed in the header
Field Description
Assigned Prevention Policy Policy assigned to the endpoint.
Agent Version Agent version that is installed on the endpoint.
Auto Upgrade Status When Cortex XDR agent auto upgrades are enabled, this field indicates the action status.
If an endpoint is excluded, the auto upgrade profile configuration is not available.
If you exclude the endpoint from auto upgrade while the auto upgrade action is In progress, the ongoing upgrade
will still take place.
Cloud Info IBM and Alibaba Cloud metadata reported by the endpoint.
Content Auto Update Whether automatic content updates are Enabled or Disabled for the endpoint in the agent settings profile.
Content Release Timestamp 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.
Content Status Status of the content version on the relevant endpoint. The Cortex XDR 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 XDR 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.
Content Status is calculated every 30 minutes. Therefore, there might be a delay of up to 30 minutes in displaying
the data.
Content Version Content update version used with the agent.
Disabled Capabilities List of capabilities that were disabled on the endpoint. Options are Live Terminal, Script Execution, and File
Retrieval.
You can disable these capabilities during agent installation on the endpoint or through Endpoint Administration.
Disabling any of these actions is irreversible. 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.
Only supported for Windows and macOS.
Endpoint Alias If you assigned an alias to represent the endpoint in Cortex XDR, 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 that identifies the endpoint.
Displayed in the footer
Page 364 of 952
Cortex XDR Documentation
Displayed in the header
Field Description
Endpoint Isolated Isolation status, either:
Isolated: The endpoint has been isolated from the network with communication permitted to only Cortex XDR
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.
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.
Endpoint Version Versions of the agent that runs on the endpoint.
First Seen Date and time the agent first checked in (registered) with Cortex XDR.
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.
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.
Displayed in the footer
Page 365 of 952
Cortex XDR Documentation
Displayed in the header
Field Description
Installation Package Installation package name used to install the agent.
Installation Type Type of installation.
IP Address Last known IPv4 address of the endpoint.
IPv6 Address Last known IPv6 address of the endpoint.
Is EDR Enabled Whether EDR data is enabled on the endpoint.
Last Certificate Enforcement (For Windows and MacOS Endpoints.) If Certificate Enforcement is Enabled, this column shows the date and time
Fallback of use of a fallback certificate from the local store. If no fallback is used, this will remain empty.
Last Content Update Time Time and date when the agent last deployed a content update.
Last Origin IP Last IPv4 address from which the XDR agent connected.
Last Origin IPv6 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 XDR receives a periodic status
report from the agent (once an hour), a user performed a manual Check In, or a security event occurred.
Changes to the agent status can take up to ten minutes to display on Cortex XDR .
Last Used Proxy IP address and port number of proxy that was last used for communication between the agent and Cortex XDR.
Last Used Proxy Port Last proxy port used on endpoint.
Linux Operation Mode (Agent 7.7 and later for Linux) Type of operation mode your Linux endpoint is running by the agent.
Last Upgrade Failure Reason Reason an upgrade failed.
Last Upgrade Source Source of the upgrade installation file.
Last Upgrade Status Status of the last upgrade.
Last Upgrade Status Time Date and time of the last upgrade.
MAC Address Endpoint MAC address that corresponds to the IP address. Currently, this information is available only for IPv4
addresses.
Displayed in the footer
Page 366 of 952
Cortex XDR Documentation
Displayed in the header
Field Description
Mobile ID Unique identifier of the agent located on an Android or iOS mobile.
Network Interface 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.
Operating System Name of the operating system.
Operational Status Cortex XDR agent operational status:
Protected: The agent is running as configured and did not report any exceptions.
Partially protected: The agent reported one or more exceptions. Clicking on the row shows in the detailed
view why an endpoint may be partially protected.
Unprotected: 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.
Managed Device Whether an iOS device has a corporate profile installed on it and is to some extent controlled and managed by the
corporation.
Tags 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 XDR tenant identifies the user from
the email prefix specified during app activation.
15.4.3 | Retrieve files from an endpoint
Abstract
You can retrieve files from one or more endpoints by initiating a files retrieval request.
During an investigation, you can retrieve files from one or more endpoints by initiating a files retrieval request. For each file retrieval request, Cortex XDR
supports up to:
Displayed in the footer
Page 367 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR. 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.
How to retrieve files from an endpoint
1. Go to Incident Response → Response → Action Center → New Action.
2. Select Files Retrieval.
3. Select the operating system and enter the paths for the files you want to retrieve. Press ADD after each completed path.
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 and click Next.
6. Review the action summary and click Done.
To track the status of a file retrieval action, return to the Action Center. Cortex XDR 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.
7. 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.
8. When the action status is Completed Successfully, right-click the action and download the retrieved files logs.
If the Password Protection (for downloaded files) setting under Settings → Configuration → General → Server Settings is enabled, enter the password
'suspicious' to download the file.
Disable file retrieval
If you want to prevent Cortex XDR from retrieving files from an endpoint running the agent, you can disable this capability during agent installation or later on
from the All Endpoints page. 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.
Disabling File Retrieval does not take effect on file retrieval actions that are in progress.
15.4.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 the support logs and alert data dump files from an
endpoint. After Cortex XDR receives the logs, you can download the log files or generate a secured link to access them on the Cortex XDR server.
How to retrieve support files
1. Retrieve support files.
1. Go to Incident Response → Response → Action Center → + New Action.
2. Select Retrieve Support File and click Next.
3. Select the target endpoints (up to 10) from which you want to retrieve logs and click Next.
4. Review the action summary and click Done.
In the next heartbeat, the agent will retrieve the request to package and send all logs to Cortex XDR .
You can also retrieve support files from the All Endpoints table by right-clicking and selecting Endpoint Control+Retrieve Support File.
2. In the Action Center, locate your Support File Retrieval action type and wait for the Status field to display Completed Successfully.
Displayed in the footer
Page 368 of 952
Cortex XDR Documentation
Displayed in the header
If 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 XDR 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.
To open the file you will need the support file password. For more information, see Retrieve support file password.
15.4.5 | 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 Cortex XDR agent version 7.8 and later, 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 XDR 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.
a. At the top of the page, click Tokens and Passwords and select Retrieve Support File Password.
b. In the Retrieve Support File Password dialog box, 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.
c. 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.
a. Right-click the relevant action of action type Support File Retrieval and select Additional Data.
b. Right-click the action and select Retrieve Support File Password.
c. In the Retrieve Support File Password dialog box, in the Encrypted Password field, paste the token that you copied from the metadata file located
in the download file.
d. Click the copy button to copy the password displayed and then click Ok. Use the password to unzip the TSF file.
15.4.6 | 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 XDR 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
XDR so you can manually take action to remove the malware before it is triggered and attempts to harm the endpoint.
You can scan the endpoint in the following ways:
System scan: Initiate a full system scan on demand from Endpoints Administration for an endpoint, as explained in the following procedure.
Periodic scan: Configure periodic full scans that run on the endpoint as part of the malware security profile. To configure periodic scans, see Set up
malware prevention profiles.
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 system scan
You can initiate full scans of one or more endpoints from the All Endpoints table or the Action Center. After initiating a scan, you can monitor the scan progress
in the Action Center. Scan time varies depending on the number of endpoints, connectivity to those endpoints, and the number of files for which Cortex XDR
Displayed in the footer
Page 369 of 952
Cortex XDR Documentation
Displayed in the header
needs to obtain verdicts.
1. 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 XDR automatically filters out any endpoints for which scanning is not supported.
Scanning is also not available for inactive endpoints.
5. Click Next.
6. Review the action summary and click Done. Cortex XDR 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 XDR. To view the scan results for an endpoint:
a. In the Action Center, right-click the scan action and select Additional data.
Cortex XDR 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 XDR displays a filtered list of malware alerts for files that were detected on the endpoint during the scan.
15.5 | Investigate files
You can take actions to manage and investigate files, including:
Manage file execution on your endpoints by adding file hashes to your allow and block lists.
Quarantine files and manage the files automatically quarantined by Cortex XDR.
Review the file verdict and the WildFire Analysis Report for a file.
Import hashes from the Endpoint Security Manager or from external feeds.
15.5.1 | Manage file execution
Abstract
Set rules for the execution (or running) of particular files on your endpoints in Cortex XDR.
You can manage file execution on your endpoints by adding file hashes to your allow and block lists. If you trust a certain file and know it to be benign, you can
add the file hash to the allow list. This allows the file to be executed on all your endpoints regardless of the WildFire or local analysis verdict. Similarly, if you
want to always block a file from running on your endpoints, you can add the associated hash to the block list.
Adding files to the allow and block lists takes precedence over any other policy rules that are applied to these files. In the Action Center, you can monitor the
allow and block list actions performed in your network, and add or remove files from these lists.
Supported file types are:
Operating System Supported File Types
Windows PE, PE64
doc, docx, xls, xlsx (only if they contain macro files)
PS1
Mac macho, DMG
Displayed in the footer
Page 370 of 952
Cortex XDR Documentation
Displayed in the header
Operating System Supported File Types
Linux ELF
How to add a file to the allow or block list or allow list
1. Go to Incident Response → Response → Action Center → New Action.
2. Select Add to Block List or Add to Allow List.
3. Enter the SHA-256 hash of the file and click .
You can add up to 100 file hashes at one time. If you add a comment, it is added to all the hashes you added in this action.
4. Click Next.
5. Review the summary and click Done.
In the next heartbeat, the agent retrieves the updated lists from Cortex XDR.
6. You are automatically redirected to the Block List or Allow List that corresponds to the action in the Action Center.
7. To manage the file hashes on the Block List or the Allow List, right-click a file to see the available actions.
15.5.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
How to quarantine a file
You can quarantine a file in the following ways:
Enable the agent to automatically quarantine malicious executables by configuring quarantine settings in a Malware prevention profile. For more
information, see Set up malware prevention profiles.
Right-click a specific file from the causality view and select Quarantine. For more information, see Causality view.
View and manage quarantined files
1. To view the quarantined files in your network, go to Incident Response → Response → Action Center → File Quarantine.
Toggle between the Detailed and Aggregated By SHA256 tabs to see information on your quarantined files.
2. Review details about quarantined files.
In the Detailed view, filter and review the Endpoint Name, Domain, File Path, Quarantine Source, and Quarantine Date of all the quarantined files. You
can take the following actions:
Reinstate a quarantined file: Right-click one or more rows and select Restore all files by SHA256.
This will restore all files with the same hash on all of your endpoints.
Review the quarantined file inspection results on VirusTotal: Right-click the Hash field and select Open in VirusTotal.
Drill down on the hash value: Right-click the Hash field and select Open Hash View. You can see each of the process executions, file operations,
incidents, actions, and threat intelligence reports relating to the hash value.
Search for where the hash value appears in Cortex XDR: Right-click the Hash field and select Open in Quick Launcher.
Export to file: Click the icon on the top right corner to download a detailed list of the quarantined hashes in a TSV format.
Displayed in the footer
Page 371 of 952
Cortex XDR Documentation
Displayed in the header
3. In the Aggregated by SHA256 view, filter and review the Hash, File Name, File Path, and Scope of all the quarantined files. You can take the following
actions:
Open the Quarantine Details page: Right-click a row and select Additional Data to open the page detailing the Endpoint Name, Domain, File Path,
Quarantine Source, and Quarantine Date of a specific file hash.
Reinstate a file hash: Right-click and select Restore.
Permanently delete quarantined files on the endpoint: Right-click and select Delete all files by SHA256.
15.5.3 | Review WildFire analysis details
Abstract
For each file, Cortex XDR 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 XDR 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.
Drill down into 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.
1. Open the WildFire report.
If you are analyzing an incident in the incident detail view you can see artifact details on the Key Assets & Artifacts tab. Under Artifacts, identify a file with
a WildFire verdict and click Wildfire Analysis Report ( ). If you are analyzing an alert, hover over the alert and Investigate. You can open ( ) the WildFire
report of any file included in the alert Causality Chain.
Cortex XDR displays the preview of WildFire reports that were generated within the last couple of years. To view a report that was generated more than
two years ago, you can download the report.
2. Analyze the WildFire report.
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 to review the summary and additional details. To learn
more about the behavior summary, see WildFire Analysis Reports—Close Up.
3. (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.
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 Cortex XDR to request the verdict change.
1. Open the WildFire report and verify the verdict that you are reporting.
2. Click Report Verdict as Incorrect ( ).
3. Under Suggested Verdict, suggest a new verdict.
4. Under Comment, enter any details that can help us to better understand why you disagree with the verdict.
5. Under Email, verify your email address.
6. Click OK.
The threat team will perform further analysis of the sample to determine whether 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. 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.
15.5.4 | Import file hash exceptions
Abstract
You can import file hash exceptions from the Endpoint Security Manager or from external feeds.
The Action Center displays information on files that are quarantined, or included in the allow list and block list. To import hashes from the Endpoint Security
Manager or from external feeds, take the following steps:
Displayed in the footer
Page 372 of 952
Cortex XDR Documentation
Displayed in the header
1. From Cortex XDR , select Incident Response → Response → Action Center → New Action.
2. Select Import Hash Exceptions.
3. Drag your file to the drop area.
Files must be in csv format, for example Verdict_Override_Exports.csv. If necessary, resolve any conflicts encountered during the upload and
retry.
4. Click Next.
5. Review the action summary, and click Done.
Cortex XDR imports your hashes. Depending on the assigned verdict, Cortex XDR then distributes them to the allow list or block list.
15.6 | Response actions
Abstract
As a result of an incident investigation, different response actions are possible.
To assist you with your investigation, Cortex XDR provides response actions for investigating and remediating endpoints. For example, if you detect a
compromised endpoint you can isolate it from your network. This action prevents the endpoint from communicating with other internal or external devices, and
thereby reducing an attacker’s mobility on your network.
For response actions that rely on the Cortex XDR agent, the following table describes the supported platforms and minimum agent version. A dash (—)
indicates that the setting is not supported.
Module Windows Mac Linux
Initiate a Live Terminal Session ✓ ✓ ✓
Initiates a remote connection to an Agent 6.1 and later Agent 7.0 and later Agent 7.0 and later
endpoint, enabling you to investigate
and respond to security events. Using
Live Terminal you can manage files
in the file system, manage active
processes, and run operating system
or Python commands.
Isolate an Endpoint ✓ ✓ ✓
Halts all network access on the Agent 6.0 and later Agent 7.3 and later on macOS Agent 7.7 and later
endpoint except for traffic to Cortex 10.15.4 and later
XDR. This prevents a compromised
endpoint from communicating with
other internal or external devices.
Available for Cortex XDR Pro only. ✓ ✓ ✓
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
XDR, including out-of-the-box scripts or
your own Python scripts and code
snippets.
Displayed in the footer
Page 373 of 952
Cortex XDR Documentation
Displayed in the header
Module Windows Mac Linux
Available for Cortex XDR Pro only. ✓ — —
Remediate Changes from Malicious Agent 7.2 and later
Activity
Investigates suspicious causality
process chains and incidents on your
endpoints, and provides suggested
actions for remediating processes, files
and registry keys on your endpoint that
were changed as a result of malicious
activity.
Available for Cortex XDR Pro only. ✓ ✓ —
Search and Destroy Malicious Files Agent 7.2 and later Agent 7.3 and later on macOS
10.15.4 and later
Searches for the presence of known
and suspected malicious files on
endpoints, and destroys the file on
endpoints where it exists.
Response actions are not supported for Android endpoints.
15.6.1 | Initiate a Live Terminal session
Abstract
Initiate a Live Terminal session from the Cortex XDR 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 remote
connection is facilitated by the Cortex XDR agent by using a remote procedure call. With the Live Terminal you can manage remote endpoints, and perform
investigation and response actions on endpoints. Actions include:
Navigating and managing files in the file system.
Managing active processes.
Running operating system commands and Python commands.
Downloading files of up to 200 MB and uploading 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).
Displayed in the footer
Page 374 of 952
Cortex XDR Documentation
Displayed in the header
Operating System Requirements
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).
You can run PowerShell 5.0 or a later release on Live Terminal of Windows.
Initiate a Live Terminal session
1. You can initiate a Live Terminal session from the All Endpoints page. Right-click an endpoint and select Security Operations → Initiate Live Terminal. It
might take the Cortex XDR agent a few minutes to facilitate the connection.
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.
2. Use the Live Terminal to investigate and take action on the endpoint.
You can fine-tune the Live Terminal session visibility on the endpoint by adjusting the User Interface options in your Agent Settings Profile.
3. When you are finished, Disconnect the Live Terminal session.
After you terminate the Live Terminal session, you can save a session report that logs all actions from the Live Terminal session. The report is available for
download as a text file report when you close the live terminal session.
Example 19.
The following example displays a sample session report:
Live Terminal Session Summary
Initiated by user username@paloaltonetworks.com 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 from a Live Terminal session
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. Right-click the process to take the following actions:
Displayed in the footer
Page 375 of 952
Cortex XDR Documentation
Displayed in the header
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 so that you can easily locate the process in the session report.
Remove from Interesting: If no threats are found, you can remove the Interesting tag.
Copy Value: Copy the cell value to your clipboard.
3. To end the Live Terminal session, select Disconnect.
Choose whether to save the session report including files and tasks marked as interesting. Administrator actions are not saved to the endpoint.
Manage files from a Live Terminal session
The File Explorer enables you to navigate the file system on the remote endpoint and take the following actions:
Create, move, delete, or download files, folders, and drives, including connected external drives and devices such as USB drives and CD-ROM.
Network drives are not supported.
View file attributes, creation and last modified dates, and the file owner.
Investigate files for malicious content.
How to manage files from a Live Terminal
1. From the Live Terminal session, open the File Explorer.
2. Navigate through the file directory on the endpoint and manage your files. To locate a specific file, you can search for any filename rows on the screen
from the search bar, or you can double-click a folder to explore its contents.
3. Perform basic management actions on a file, such as:
View file attributes.
Rename files and folders.
Export the table as a CSV file.
Move and delete files and folders.
4. Investigate files for malware. Right-click a file to see the available 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 a file or directory so that you can easily locate the file in the session report.
Remove from Interesting: If no threats are found, you can remove the Interesting tag.
Copy Value: Copy 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 from a Live Terminal session
The Live Terminal provides a command line interface for running operating system commands on a remote endpoint. Each command runs independently and
is not persistent.
Displayed in the footer
Page 376 of 952
Cortex XDR Documentation
Displayed in the header
On Windows endpoints, you cannot run GUI-based cmd commands like winver or appwiz.cpl.
How to run operating system commands
1. From the Live Terminal session, select Command Line.
2. Run commands to manage the endpoint. For example, you can manage files or launch batch files.
You can enter or paste the commands into the command line interface, or you can upload a script. To chain multiple commands together use &&, as
shown in the following example:
Example 20.
cd c:\windows\temp\ && <command1> && <command2>
3. When you are finished, 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 from a Live Terminal session
The Live Terminal provides a Python command line interface for running Python commands and scripts. The Python command interpreter uses Unix command
syntax and supports Python 3 with standard Python libraries.
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 required.
You can enter or paste the commands into the command line interface, or you can upload a script.
3. When you are finished, 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
If you want to prevent Cortex XDR from initiating Live Terminal remote sessions on an endpoint that is running the Cortex XDR agent, you can disable this
capability during agent installation or through Cortex XDR 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.
Disabling Live Terminal does not take effect on sessions that are in progress.
15.6.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 XDR. 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 XDR shows an Isolated status. To ensure an endpoint remains in isolation, agent upgrades are not available for isolated
endpoints.
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. For more information, see Set up agent settings profiles.
Displayed in the footer
Page 377 of 952
Cortex XDR Documentation
Displayed in the header
Operating System Prerequisites
Mac Agent 7.3 or later.
MacOS 10.15.4 or later.
Cortex XDR 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.
How to isolate an endpoint
1. 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. Enter a Comment to provide additional background or other information that explains why you isolated the endpoint.
After you isolate an endpoint, Cortex XDR displays the Isolation Comment under Action Center → Isolation. If needed, you can edit the comment from
the right-click pivot menu.
3. Click Next.
4. Select the target endpoint that you want to isolate from your network.
If needed, Filter the list of endpoints.
5. Click Next.
6. Review the action summary and click Done when finished.
In the next heartbeat, the agent will receive the isolation request from Cortex XDR.
7. To track the status of an isolation action, go to Incident Response → Response → Action Center → Currently Applied Actions → Endpoint Isolation.
If after initiating an isolation action, you can cancel the action by right-clicking the action and selecting 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.
8. After you remediate the endpoint, cancel endpoint isolation to resume normal communication.
You can cancel isolation from Actions Center → Isolation or from Endpoints → Endpoint Management → Endpoint Administration. From either place
right-click the endpoint and select Endpoint Control → Cancel Endpoint Isolation.
If file system operations become unresponsive during isolation, such as being unable to list folder content, unmount the mounted network shares.
15.6.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 XDR. 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.
When you are ready, you can resume the endpoint protection.
Displayed in the footer
Page 378 of 952
Cortex XDR Documentation
Displayed in the header
Pausing your endpoint protection modules leaves your machines exposed to risks.
How to pause endpoint protection modules
1. Go to Endpoints → All Endpoints.
2. In the All Endpoints page, select the endpoints on which you want to pause protection, 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.
Paused endpoints display a pause icon in the Endpoint Name field, and one of the following the action statuses in Manual Protection Pause field:
Protection Active
Pending Pause
Protection Paused
Pending Activation
4. When you are ready to resume protection, select the paused 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. Track your pause and resume endpoint protection actions.
Go to Incident Response → Response → Action Center and locate Action Type Pause Endpoint Protection or Resume Endpoint Protection.
15.6.4 | Remediate changes from malicious activity
Abstract
You can obtain action remediation suggestions from Cortex XDR about malicious causality chains that have been detected.
This functionality requires a Cortex XDR Pro license.
When investigating suspicious incidents and causality chains you might 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 remediation suggestions.
To initiate remediation suggestions, you must have the following system requirements:
Cortex XDR 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 or above on Windows endpoints.
How to initiate remediation suggestions
1. You can initiate a remediation suggestions analysis from the following places:
In the Incidents view, click the more options icon in the incident panel and select Remediation Suggestions.
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:
Right-click any process node involved in the causality chain and select Remediation Suggestion.
Select Actions → Remediation Suggestions.
Analysis can take a few minutes. You can minimize the analysis pop-up if desired while navigating to other pages.
2. Review the remediation suggestion summary and details.
Field descriptions
Field Description
Original Event Description Summary of the initial event that triggered the malicious causality chain.
Displayed in the footer
Page 379 of 952
Cortex XDR Documentation
Displayed in the header
Field Description
Original Event Timestamp Timestamp of the initial event that triggered the malicious causality chain.
Endpoint Name Hostname of the endpoint.
IP Address IP address associated with the endpoint.
Endpoint Status Connectivity status of the endpoint.
Domain Domain or workgroup to which the endpoint belongs, if applicable.
Endpoint ID Unique ID assigned by Cortex XDR that identifies the endpoint.
Suggested Remediation Action suggested by the remediation scan for you 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.
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 rows, right-click and select Remediate.
4. Track your remediation process.
Go to Response → Action Center → All Actions and locate your remediation process in the Action Type field. Right-click Additional data to open the
Detailed Results window.
15.6.5 | Run scripts on an endpoint
Abstract
Displayed in the footer
Page 380 of 952
Cortex XDR Documentation
Displayed in the header
Execute Python scripts from Cortex XDR directly on the endpoint to perform actions, retrieve data, and retrieve files.
This functionality requires a Cortex XDR Pro license.
For enhanced endpoint remediation and endpoint management, you can run Python 3.7 scripts on your endpoints directly from Cortex XDR. For commonly
used actions, Cortex XDR provides out-of-the-box scripts. You can also write and upload your own Python scripts and code snippets into Cortex XDR for
custom actions. Cortex XDR enables you to manage, run, and track the script execution on the endpoints, and store and display the execution results per
endpoint.
To run scripts on an endpoint, you must have the following system requirements:
Cortex XDR 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)
Running snippets requires both Run High-risk scripts and Script configuration permissions. Additionally, all scripts are executed as System User on the
endpoint.
Manage scripts in the Scripts Library
Your scripts are available in the Action Center → Scripts Library, including out-of-the-box scripts and custom scripts. From the Scripts Library, you can view the
script code and metadata, and perform the following actions from the right-click pivot menu:
Download script: Download the Python code file locally.
View/Download definitions file: View or download the script metadata.
Run: Run the selected script. Cortex XDR redirects you to the Action Center where the details of this script are populated in the new action fields.
Edit: Edit the script code or metadata. This option is not available for the out-of-the-box scripts.
The following table describes the default and optional fields that you can view in the Scripts Library. The fields are in alphabetical order.
Field Description
Compatible OS Operating systems with which the script is compatible.
Created By User who created the script. For out-of-the-box scripts, the user name is Palo
Alto Networks.
Description Script description is an optional field that can be completed when creating,
uploading, or editing a script.
Id Unique ID assigned by Cortex XDR to identify the script.
Modification Date Date and time in which the script or its attributes were last edited.
Name 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.
Displayed in the footer
Page 381 of 952
Cortex XDR Documentation
Displayed in the header
Field Description
Script FileSHA256 SHA256 of the code file.
Out-of-the-box scripts
Palo Alto Networks provides out-of-the-box scripts. You can view the scripts, download the script code and metadata, and duplicate the scripts, 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
XDR 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 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)
*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
You can write and upload scripts to the Scripts Library.
1. Go to Action Center → Agent Script Library and select New Script.
Drag your script file into the window, or browse and select it. During upload, Cortex XDR parses the script to ensure you are using only supported Python
modules. Click supported modules 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 XDR.
2. Add metadata to your script.
Displayed in the footer
Page 382 of 952
Cortex XDR Documentation
Displayed in the header
You can enter the field definitions manually, or upload a definitions file to automatically enter the definitions. The definitions file must use exact script
manifest format. To view the manifest format and create your own, see Create a script manifest.
Complete the following fields:
General: Specify the general script definitions including 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, specify the output type. Cortex XDR displays this 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 multiple values, select Dictionary. By default, Cortex XDR displays the dictionary value as is in the script
results table.
To improve the display of the script results table and enable filtering, you can assign user-friendly names and types to your dictionary keys.
To retrieve files from the endpoint, add the files_to_get key to the dictionary. This key includes an array of paths from which files will be
retrieved from the endpoint.
3. When you are finished, create the new script. The script is uploaded to the Scripts Library.
Create a script manifest
You can create a script manifest to automatically enter file definitions for a script. For more information see Step 2 in Upload your scripts.
The script manifest file that you upload into Cortex XDR 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.
Example 21.
This is an example of the manifest file structure and content.
In 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.
{
"name":"script name",
"description":"script description",
"outcome":"High Risk|Standard",
"platform":"Windows,macOS,Linux",
"timeout":600,
"entry_point":"entry_point_name",
"entry_point_definition":{
Displayed in the footer
Page 383 of 952
Cortex XDR Documentation
Displayed in the header
"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"}]
}
}
Always use lowercase for variable names.
How to create a script manifest
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 XDR 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 the Entry_point and Entry_point_definitions empty:
Example 22.
{
"name":"script name",
"description":"script description",
"outcome":"High Risk|Standard",
"platform":"Windows,macOS,Linux",
"timeout":600,
"entry_point":"",
"entry_point_definition":{}
}
Track script execution
When you run a script, you can see the script execution in the Action Center and track the script execution status. The Status indicates the action's 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:
Displayed in the footer
Page 384 of 952
Cortex XDR Documentation
Displayed in the header
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 before the agent pulled the request
from the server.
Completed Successfully The script was executed successfully on the endpoint with no exceptions.
Expired The 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.
In Progress The agent pulled the script execution request.
Pending The agent has not yet pulled the script execution request from the server.
Pending Abort The agent is in the process of executing the script, and has not pulled the
abort request from the server yet.
Timeout The script execution reached its configured time out and the agent stopped
the execution on the endpoint.
Open script in Interactive Mode
You can use Interactive Mode 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 a script that is already running, in the Action Center, right-click the execution action of the relevant script and select Open in
interactive mode.
Cancel or abort script execution
You can cancel or abort a script execution action for Pending and In Progress actions:
When the script execution action is Pending, the agent has not yet pulled the request from the Cortex XDR server. When you cancel a pending action,
the server pulls back the request and updates the action status to 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, 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 action that is in progress,
the agent halts the script execution on the endpoint and updates the action status to 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, go to Action Center → Additional data → Detailed Results, right-click the endpoints and Abort for endpoint in
progress.
View script execution results
Cortex XDR logs all script execution actions, including the script results and the parameters specified when running the script. To view full details about the
run, including returned values, right-click the script and select Additional data.
The script results are divided into the upper bar and the main view. The upper bar displays the script meta-data including 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.
Displayed in the footer
Page 385 of 952
Cortex XDR Documentation
Displayed in the header
The main view displays the script execution results as follows:
Main results view: Displays a table listing all target endpoints and their details.
In addition to the endpoint details (name, IP, domain, etc), the following table describes 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 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 Number of files the agent failed to retrieve from the endpoint.
Retention date Date after which the retrieved file will no longer be available for download.
The value is 90 days from the execution date.
Retrieved files Number of files that were successfully retrieved from the endpoint.
Status See the list of statuses and their descriptions in Track script execution.
Standard output The returned stdout
For each endpoint, you can right-click to download the script stdout, download retrieved files, and view returned exceptions. You can also Export to file
to download the detailed results table in TSV format.
Aggregated results: A visualization of the script results. Cortex XDR 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.
Rerun a script
You can select a script execution action in the Action Center and rerun it. When you rerun a script, the same parameter values, target endpoints, and defined
timeout are used, as defined in the previous run. However, you can make changes to the script before rerunning it. In addition, if the target endpoints in the
original run were defined using a filter, the filter will be recalculated when you rerun the script.
Cortex XDR uses the current version of the script. If the script has been deleted or the supported operating system definition has been modified the since the
previous run, 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
To understand why a script returned Failed execution status, you can take the following actions:
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: If a custom script that 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 XDR or 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.
Displayed in the footer
Page 386 of 952
Cortex XDR Documentation
Displayed in the header
Disable script execution
If you want to prevent Cortex XDR from running scripts on an agent, you can disable this capability during agent installation, or through Endpoint
Administration. Disabling script execution is irreversible. If you want to re-enable this capability on the endpoint, you must reinstall the agent. For more
information, see the Cortex XDR Agent Administrator’s Guide.
Disabling Script Execution does not take effect on scripts that are in progress.
15.6.6 | Search and destroy malicious files
Abstract
Cortex XDR enables you to effectively hunt down any identified malicious file that may exist on any of your endpoints.
This functionality requires the following licenses and add-ons:
Cortex XDR Pro per Endpoint license.
Hosts Endpoint license enabled on your tenant.
Host Insights add-on enabled on your tenant.
To take immediate action on known and suspected malicious files, you can search and destroy the files. After identifying 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 the disk size of each endpoint, it can take a few days for Cortex XDR 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, 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. When you find the file, you can select it in the search results and destroy the file by hash or by path. If you already know the path or hash, you can also
destroy a file from the Action Center without performing a search. 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.
The Cortex XDR 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 XDR agent was installed.
Information about files where the file size exceeds the maximum file size for hash calculations that are pre-configured in Cortex XDR .
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 XDR to search and destroy files on your endpoints:
Supported platforms:
Windows: Cortex XDR agent version 7.2 or a later. If you plan to enable Search and Destroy on VDI sessions, you must perform the initial scan on
the Golden Image.
Mac: Cortex XDR agent version 7.3 or a later release running on macOS version 10.15.4 or later.
Linux: Not supported.
Setup and permissions:
Ensure File Search and Destroy is enabled for your Cortex XDR agent.
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 destroy
all of the file instances on the endpoint, or upload the file to Cortex XDR for further investigation.
You can search for a file using the Query Builder, 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:
Displayed in the footer
Page 387 of 952
Cortex XDR Documentation
Displayed in the header
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 on which you want to search for the file. Cortex XDR displays only endpoints eligible for file search. Click Next.
4. Review the summary and initiate the search.
Cortex XDR 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 XDR 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 XDR 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 XDR 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.
6. (Optional) Destroy a file.
After you located the malicious file instances on all your endpoints, proceed to 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 XDR for further examination.
Destroy a file
When you know a file is malicious, you can destroy all of its instances on your endpoints, directly from Cortex XDR. 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 XDR agent deletes all the file instances on the
endpoint. To destroy a file from the file search results, see Search 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 from which you want to remove the file. Cortex XDR displays only endpoints eligible for file destroy. When you’re done, click
Next.
4. Review the summary and initiate the action.
Cortex XDR 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.
15.6.7 | Manage external dynamic lists
Abstract
Configure and manage your external dynamic lists in Cortex XDR.
This functionality requires a Cortex XDR Pro license.
An External Dynamic List (EDL) is a text file hosted on an external web server that your Palo Alto Networks firewall uses to provide control over user access to
IP addresses and domains that the Cortex XDR has found to be associated with an alert.
Cortex XDR hosts two external dynamic lists you can configure and manage.
IP Addresses EDL
Domain Names EDL
Displayed in the footer
Page 388 of 952
Cortex XDR Documentation
Displayed in the header
To maintain an EDL, you must meet the following requirements:
Cortex XDR Pro per GB or Cortex Pro per Endpoint license
An App Administrator, Privileged Investigator, or Privileged Security Admin role which includes EDL permissions
Palo Alto Networks firewall running PAN-OS 9.0 or a later release
Access to your Palo Alto Networks firewall configuration
1. Enable EDL.
a. Navigate to Settings → Configurations → Integrations → External Dynamic List Integration.
b. Enable External Dynamic List and enter the Username and Password that the Palo Alto Networks firewall should use to access the EDL.
2. Test the URL connection.
Testing is currently only available using the following curl and Windows PowerShell commands:
For Linux/OS/Windows
curl https://edl-<tenant-name>.xdr.<region>.paloaltonetworks.com/block_list?type=ip -u <user>:<password>
For Windows PowerShell version 5 and later
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12$username = "username"$password =
"password"$base64AuthInfo = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(("{0}:{1}" -f
$username,$password)))
3. Record the IP Addresses EDL URL and the Domains EDL URL. You will need these URLs in the coming steps to point the firewall to these lists.
4. Save the EDL configuration.
5. Enable the firewall to authenticate the EDL.
a. Download and save the following root certificate: https://certs.godaddy.com/repository/gd-class2-root.crt.
b. On the firewall, select Device → Certificate Management → Certificates and Import the certificate. Make sure to give the device certificate a
descriptive name, and select OK to save the certificate.
c. Select Device → Certificate Management → Certificate Profile and Add a new certificate profile.
d. Give the profile a descriptive name and Add the certificate to the profile.
e. Select OK to save the certificate profile.
6. Set the Cortex XDR EDL as the source for a firewall EDL.
For more detailed information about how Palo Alto Networks firewall EDLs work, how you can use EDLs, and how to configure them, review how to Use
an External Dynamic List in Policy.
a. On the firewall, select Objects → External Dynamic Lists and Add a new list.
b. Define the list Type as either IP List or Domain List.
c. Enter the IP Addresses Block List URL or the Domains Block List URL that you recorded in the last step as the list Source.
d. Select the Certificate Profile that you created in the last step.
e. Select Client Authentication and enter the username and password that the firewall must use to access the EDL.
f. Use the Repeat field to define how frequently the firewall retrieves the latest list from Cortex XDR .
g. Click OK to add the new EDL.
7. Select Policies → Security and Add or edit a security policy rule to add the Cortex XDR EDL as match criteria to a security policy rule.
Review the different ways you can Enforce Policy on an External Dynamic List; this topic describes the complete workflow to add an EDL as match
criteria to a security policy rule.
a. Select Policies → Security and Add or edit a security policy rule.
b. In the Destination tab, select Destination Zone and select the external dynamic list as the Destination Address.
c. Click OK to save the security policy rule and Commit your changes.
You do not need to perform an additional commit or make any subsequent configuration changes for the firewall to enforce the EDL as part of your
security policy; even as you update the Cortex XDR EDL, the firewall will enforce the list most recently retrieved from Cortex XDR .
You can also use the IP list and URL lists as part of a URL Filtering policy, or the domain list as part of a custom Anti-Spyware profile.
Displayed in the footer
Page 389 of 952
Cortex XDR Documentation
Displayed in the header
8. Add an IP address or Domain to your EDL.
You can add to your IP address or Domain lists as you triage alerts from the Action Center or throughout Cortex XDR .
Ensure EDL sizes don’t exceed your firewall model limit.
To add an IP address or Domain from the Action Center, select Add to EDL. You can choose to enter the IP address or Domain you want to add Manually
or choose to Upload File.
During investigation, you can also Add to EDL from the Actions menu that is available from investigation pages such as the Incidents View, Causality
View, IP View, or Quick Launcher.
9. At any time, you can view and make changes to the IP addresses and domain name lists.
a. Navigate to Incident Response → Response → Action Center → Currently Applies Actions → External Dynamic List.
b. Review your IP addresses and domain names lists.
c. If desired, select New Action to add additional IP addresses and domain names.
d. If desired, select one or more IP addresses or domain names, right-click and Delete any entries that you no longer want included on the lists.
15.6.8 | Collect a memory image
Abstract
Collect a memory image from a Windows endpoint.
This functionality has the following license requirements:
Cortex XDR Pro license
Forensics add-on license.
Certain forensic artifacts exist only in the computer’s memory, such as volatile data created by running processes. The Memory Collection option enables
Cortex XDR to capture the memory of a Windows endpoint. After the memory image has been captured from the Cortex XDR endpoint, the image is available
to download. Use the image to perform a full analysis using industry-standard tools.
This feature is not currently supported on Windows 11.
How to collect a memory image
1. From the Action Center select New Action → Memory Collection.
2. Select the target Windows endpoint from which you want to collect the memory image (only one endpoint at a time). Click Next.
3. Review the summary and initiate the action.
A summary of the memory collection action is displayed. If you need to change your settings, click 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 XDR displays the action, timestamp, and real-time status of the action on the target endpoint.
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.
15.7 | Build XQL queries
Abstract
Learn more about how to build Cortex Query Language (XQL) queries using 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 predefined queries for different types of entities.
15.7.1 | About the Query Builder
Abstract
Displayed in the footer
Page 390 of 952
Cortex XDR Documentation
Displayed in the header
The Query Builder facilitates threat detection, incident expansion, and data analytics for suspected threats.
Building Cortex Query Language (XQL) queries in the Query Builder requires a Cortex XDR Pro license.
The Query Builder aids in the detection of threats by allowing you to search for indicators of compromise and suspicious patterns within data sources. It assists
in expanding incident investigations by identifying related events and entities, such as activities associated with specific user accounts or network lateral
movement. In addition, the Query Builder enables data analytics on suspected threats, helping organizations analyze large volumes of data to identify trends,
anomalies, and correlations that may indicate potential security issues.
To support investigation and analysis, you can search all of the data ingested by Cortex XDR 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 XDR 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 xdr_data
dataset. With XQL Search you create queries based on stages, functions, and operators. To help you build your queries, Cortex XDR provides tools in
the interface that provide suggestions as you type, or you can look up predefined queries, common stages and examples.
Predefined queries for different types of entities
15.7.2 | How to build XQL queries
Abstract
Learn more about how to build XQL queries in the Query Builder.
Building Cortex Query Language (XQL) queries in the Query Builder requires a Cortex XDR Pro license.
The Cortex Query Language (XQL) enables you to query data ingested into Cortex XDR for rigorous endpoint and network event analysis returning up to 1M
results. 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. Unless otherwise specified, the query runs against the xdr_data dataset, which contains all log information that Cortex XDR collects
from all Cortex product agents, including EDR data, and PAN NGFW data. In XDM queries, you must specify the dataset mapped to the XDM that you want to
run your query against.
Forensic datasets are not inlcuded by default in XQL query results, unless the dataset query is explicitly defined to use a forensic dataset.
Dataset query syntax
In a dataset query, unless otherwise specified, the query runs against the xdr_data dataset, which contains all log information that Cortex XDR collects from
all Cortex product agents, including EDR data, and PAN NGFW data. 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.
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
XDR. 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> ...
| <stage2> ...
| <stage3> ...
You can specify a dataset using one of the following formats, which is based on the data retention offerings available in Cortex XDR.
Displayed in the footer
Page 391 of 952
Cortex XDR Documentation
Displayed in the header
Hot Storage queries use the format dataset = <dataset name>. This is the default option.
Example 23.
dataset = xdr_data
Cold Storage queries use the format cold_dataset = <dataset name>.
Example 24.
cold_dataset = xdr_data
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 XDR 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 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.
Additional components
XQL queries can contain different components, such as functions and stages, depending on the type of query you want to build.
15.7.2.1 | Get started with XQL queries
Abstract
Learn more about some important information before getting started with XQL queries.
Building Cortex Query Language (XQL) queries in the Query Builder requires a Cortex XDR Pro license.
Before you begin running XQL queries, consider the following information:
Use the interface to help you build queries
Cortex XDR offers features in the XQL search interface to help you to build queries. For more information see Useful XQL user interface features.
Understand query defaults and limitations
Before you run a query, review this list to better understand query behavior and results. For more information, see Expected results when querying fields.
Translate Splunk queries to XQL
If you have existing Splunk queries, you can translate them to XQL. For more information, see Translate to XQL.
15.7.2.2 | Useful XQL user interface features
Abstract
Learn about useful XQL query features in the user interface.
Building Cortex Query Language (XQL) queries in the Query Builder requires a Cortex XDR Pro license.
The user interface contains several useful features for querying data, and for viewing results:
Displayed in the footer
Page 392 of 952
Cortex XDR Documentation
Displayed in the header
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. For more information, see Manage your personal
query library.
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. Contains the list of all the fields of all the datasets that were involved in the query.
15.7.2.3 | XQL Query best practices
Abstract
Learn about best practices for streamlining XQL queries.
Building Cortex Query Language (XQL) queries in the Query Builder requires a Cortex XDR Pro license.
Cortex XDR includes built-in mechanisms for mitigating long-running queries, such as default limits for the maximum number of allowed alerts. The following
suggestions can help you to streamline your queries:
Add a smaller limit to queries by using a limit stage.
The default results for any query is a maximum of 1,000,000 results, when no limit is explicitly stated in the query. Queries based on XQL query entities
are limited to 10,000 results. Adding a smaller limit can greatly reduce the response time.
Example 25.
dataset = microsoft_windows_raw
| fields *host*
| limit 100
Use a small time frame for queries by specifying the specific date and time in the custom option, instead of picking the nearest larger option available.
Use filters that exclude data, along with other possible filters.
Select the specific fields that you would like to see in the query results.
15.7.2.4 | Expected results when querying fields
Abstract
Learn what to expect in the query results when querying fields.
Building Cortex Query Language (XQL) queries in the Query Builder requires a Cortex XDR Pro license.
The following are returned when querying fields:
If specific fields are stated in the fields stage, those exact fields will be returned.
The _time system field will not be added to queries that contain the comp stage.
All current system fields will be returned, even if they are not stated in the query.
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 1,000,000 results are returned (default). When this limit is applied to results using
the limit stage, it will be indicated in the user interface.
Displayed in the footer
Page 393 of 952
Cortex XDR Documentation
Displayed in the header
15.7.2.5 | Create XQL query
Abstract
Learn how to create queries using the Cortex Query Language (XQL).
Building Cortex Query Language (XQL) queries in the Query Builder requires a Cortex XDR Pro license.
Review the following topics:
How to build XQL queries
Build Cortex Query Language (XQL) queries to analyze raw log data stored in Cortex XDR. You can query the Cortex Data Model (XDM) or datasets using
specific syntax.
How to create a dataset query
1. From Cortex XDR, select Incident Response → Investigation → Query BuilderXQL Search.
2. (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.
Whenever the time period is changed in the query window, the config timeframe is automatically set to the time period defined, but this won't be
visible as part of the query. Only if you manually type in the config timeframe will this be seen in the query.
3. (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 5.
4. 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. (Optional) Specify a dataset.
You only need to specify a dataset if you are running your query against a dataset that you have not set as default. Otherwise, the query runs
against the xdr_data dataset. For more information, see How to build XQL queries.
Example 26.
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.
Example 27.
dataset = xdr_data
| filter agent_os_type = ENUM.AGENT_OS_MAC
| limit 250
5. 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 ( ).
6. (Optional) The Save As options save your query for future use:
BIOC Rule: When compatible, saves the query as a BIOC rule. The XQL query must contain a filter for the event_type field.
Correlation Rule: When compatible, saves the query as a Correlation Rule. For more information, see What's a correlation rule?.
Query to Library: Saves the query to your personal query library. For more information, see Manage your personal query library.
Widget to Library: For more information, see Create custom XQL widgets.
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.
15.7.2.6 | Review XQL query results
Abstract
Learn more about reviewing the results returned from an XQL query.
Displayed in the footer
Page 394 of 952
Cortex XDR Documentation
Displayed in the header
Building Cortex Query Language (XQL) queries in the Query Builder requires a Cortex XDR Pro license.
Review the following topics:
How to build XQL queries
Create XQL query
The results of a Cortex Query Language (XQL) query are displayed in a tab called Query Results.
It's also possible to graph the results displayed. For more information, see Graph query results.
Understanding the options available to investigate results
Use the following options in the Query Results tab 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 Show
tab 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.
Export to File Exports the results to a TSV (tab-separated values) 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 text
search search field.
Displayed in the footer
Page 395 of 952
Cortex XDR Documentation
Displayed in the header
Option Use
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 XDR displays the top ten results from which you can choose to build your filter. This
option is only available in the Table and Advanced tabs,
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.
In order for Cortex XDR to provide a histogram for a field, the field must not contain an array or a JSON object.
Available options for saving results
The Save As options save your query for future use:
BIOC Rule: When compatible, saves the query as a BIOC rule. The XQL query must contain a filter for the event_type field.
Correlation Rule: When compatible, saves the query as a Correlation Rule. For more information, see What's a correlation rule?.
Query to Library: Saves the query to your personal query library. For more information, see personal query library.
Widget to Library: For more information, see Create custom XQL widgets.
Investigating results in the Causality View or Timeline View
You can continue investigating the query results in the Causality View or Timeline by right-clicking the event and selecting 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
System authentication logs for linux
For network stories, you can pivot to the Causality View only. For cloud Cortex XDR 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.
Add file path to Malware Profile allowed list
Add a file path to your existing Malware Profile allowed list by right-clicking a <path> field, such as target_process_path, and select Add <path type> to
malware profile allow list.
15.7.2.7 | Translate to XQL
Abstract
Learn how to translate your Splunk queries to XQL queries in Cortex XDR.
Displayed in the footer
Page 396 of 952
Cortex XDR Documentation
Displayed in the header
Building Cortex Query Language (XQL) queries in the Query Builder requires a Cortex XDR Pro license.
To help you easily convert your existing Splunk queries to the Cortex Query Language (XQL) syntax, Cortex XDR includes a toggle called Translate to XQL in
the query field in the user interface. When building your XQL query and this option is selected, both a SPL query field and XQL query field are displayed, so
you can easily add a Splunk query, which is converted to XQL in the XQL query field. This option is disabled by default, so only the XQL query field is
displayed.
This feature is still in a Beta state and you will find that not all Splunk queries can be converted to XQL. This feature will be improved upon in the upcoming
releases to support greater Splunk query translations to XQL.
Supported functions in Splunk
The following table details the supported functions in Splunk that can be converted to XQL in Cortex XDR with an example of a Splunk query and the resulting
XQL query. In each of these examples, the xdr_data dataset is used.
Splunk Function/Stage Splunk Query Example Resulting XQL Q
avg index=xdr_data | stats dataset in (xdr_data) | comp avg(dst_association_streng
avg(dst_association_strength)
bin index = xdr_data | bin _time span=5m dataset in (xdr_data) | bin _time span=5m
coalesce index= xdr_data | eval dataset in (xdr_data) | alter product_or_vendor_not_nul
product_or_vendor_not_null=coalesce(_product,
_vendor )
count index=xdr_data | stats count(_product) BY _time dataset in (xdr_data) | comp count(_product) by _time
ctime index=xdr_data | convert ctime(field) as field dataset in (xdr_data) | alter field = format_timestamp(
earliest index = xdr_data earliest=24d dataset in (xdr_data) | filter _time >= to_timestamp(ad
eval index=xdr_data | eval field = "test" dataset in (xdr_data) | alter field = "test"
fillnull index=xdr_data | fillnull value = "missing dataset in (xdr_data) | replacenull agent_ip_addresses_
ipv6" agent_ip_addresses_v6
floor index=xdr_data | eval floor_test = floor(1.9) dataset in (xdr_data) | alter floor_test = floor(1.9)
iplocation index=xdr_data | inputlookup append=true dataset in (xdr_data) | union (dataset=my_lookup | limi
my_lookup.csv
iplocation index = xdr_data | iplocation dataset in (xdr_data) | iploc agent_ip_addresses loc_co
agent_ip_addresses loc_region AS Region, loc_city AS City, loc_latlon AS l
isnotnull index=xdr_data | eval x = dataset in (xdr_data)\n | alter x = if(agent_hostname !
isnotnull(agent_hostname)
isnull index=xdr_data | eval x = dataset in (xdr_data)\n | alter x = if(agent_hostname =
isnull(agent_hostname)
json_extract index= xdr_data | eval dataset in (xdr_data) | alter London = dfe_labels -> df
London=json_extract(dfe_labels,"dfe_labels{0}")
Displayed in the footer
Page 397 of 952
Cortex XDR Documentation
Displayed in the header
Splunk Function/Stage Splunk Query Example Resulting XQL Q
join join agent_hostname [index = xdr_data] join type=left conflict_strategy=right (dataset in (xdr
latest index = xdr_data latest=-24d dataset in (xdr_data) |filter _time <=
to_timestamp(add(to_epoch(date_floor(current_time(),"d"
len index = xdr_data | where uri != null | eval dataset in (xdr_data) | filter agent_ip_addresses != nu
length = len(agent_ip_address) len(agent_ip_addresses)
ltrim(<str>, index=xdr_data | eval dataset in (xdr_data) | alter trimed_agent = ltrim("age
<trim_chars>) trimed_agent=ltrim("agent_hostname", "agent_")
lower index = xdr_data | eval field = lower("TEST") dataset in (xdr_data) | alter field = lowercase("TEST")
max index =xdr_data | stats max(action_file_size) dataset in (xdr_data) | comp max(action_file_size) by _
by _product
md5 index=xdr_data | eval md5_test = md5("test") dataset in (xdr_data) | alter md5_test = md5("test")
median index = xdr_data | stats dataset in (xdr_data) | comp median(actor_process_file_
median(actor_process_file_size) by _time
min index =xdr_data | stats min(action_file_size) dataset in (xdr_data) | comp min(action_file_size) by _
by _product
mvcount index = xdr_data | where http_data != null | dataset in (xdr_data) | filter http_data != null | alte
eval http_data_array_length =
mvcount(http_data)
mvdedup index = xdr_data | eval dataset in (xdr_data) | alter s = arraydistinct(action_
s=mvdedup(action_app_id_transitions)
mvexpand index = xdr_data | mvexpand dfe_labels limit = dataset in (xdr_data) | arrayexpand dfe_labels limit 10
100
mvfilter index = xdr_data | eval x = dataset in (xdr_data) | alter x = arrayfilter(dfe_label
mvfilter(isnull(dfe_labels))
mvindex index=xdr_data | eval field = dataset in (xdr_data) | alter field = arrayindex(action
mvindex(action_app_id_transitions, 0)
mvjoin index=xdr_data | eval dataset in (xdr_data) | alter n = arraystring(action_ap
n=mvjoin(action_app_id_transitions, ";")
pow index=xdr_data | eval pow_test = pow(2, 3) dataset in (xdr_data) | alter pow_test = pow(2, 3)
Displayed in the footer
Page 398 of 952
Cortex XDR Documentation
Displayed in the header
Splunk Function/Stage Splunk Query Example Resulting XQL Q
relative_time(X,Y) index ="xdr_data" | where _time > dataset in (xdr_data) | filter _time >
relative_time(now(),"-7d@d") to_timestamp(add(to_epoch(date_floor(current_time(
index ="xdr_data" | where _time > dataset in (xdr_data)| filter _time >
relative_time(now(),"+7d@d") to_timestamp(add(to_epoch(date_floor(current_time(
replace index= xdr_data | eval description = dataset in (xdr_data) | alter description = replace(age
replace(agent_hostname,"\("."NEW")
rex index=xdr_data action_local_ip!="0.0.0.0" | rex dataset in (xdr_data) |filter (action_local_ip != "0.0.
field=action_local_ip "(? arrayindex(regextract(action_local_ip, "(\d+\.\d+\.\d+\
<src_ip>\d+\.\d+\.\d+\.48)" | where src_ip != action_local_ip, src_ip
"" | table action_local_ip src_ip
round index=xdr_data | eval round_num = round(3.5) dataset in (xdr_data) | alter round_num = round(3.5)
rtrim index=xdr_data | eval dataset in (xdr_data) | alter trimed_hostname = rtrim("
trimed_hostname=rtrim("agent_hostname",
"hostname")
search index = xdr_data | eval ip="192.0.2.56" | dataset in (xdr_data) | alter ip = "192.0.2.56" | filte
search ip="192.0.2.0/24"
sha256 index = xdr_data | eval sha256_test = dataset in (xdr_data) | alter sha256_test = sha256("tes
sha256("test")
sort (ascending index = xdr_data | sort action_file_size dataset in (xdr_data) | sort asc action_file_size | lim
order)
sort (descending index = xdr_data | sort -action_file_size dataset in (xdr_data) | sort desc action_file_size | li
order)
spath index = xdr_data | spath output=myfield dataset in (xdr_data) | alter myfield = json_extract(ac
input=action_network_http path=headers.User-
Agent
split index = xdr_data | where mac != null | eval dataset in (xdr_data)\n | filter mac != null\n | alter
split_mac_address = split(mac, ":")
stats index=xdr_data | stats count(event_type) by dataset in (xdr_data) | comp count(event_type) by _time
_time
stats dc index = xdr_data | stats dc(_product) BY _time dataset in (xdr_data) | comp count_distinct(_product) b
strcat index=xdr_data | strcat story_id "/" dataset in (xdr_data) | alter
http_req_before_method comboIP comboIP=concat(if(story_id!=null,story_id,""),"/",if(ht
sum index=xdr_data | where action_file_size != null dataset in (xdr_data) | filter action_file_size != null
| stats sum(action_file_size) by _time
Displayed in the footer
Page 399 of 952
Cortex XDR Documentation
Displayed in the header
Splunk Function/Stage Splunk Query Example Resulting XQL Q
table index = xdr_data | table _time, agent_hostname, dataset in (xdr_data) | fields _time, agent_hostname, a
agent_ip_addresses, _product
tonumber index=xdr_data | eval tonumber_test = dataset in (xdr_data) | alter tonumber_test = to_number
tonumber("90210")
top The following Splunk functions can be translated to XQL: limit
limit dataset in (xdr_data) | filter action_app_id_risk
top_percent as percent
index = xdr_data | where
action_app_id_risk > 0 | top limit=20 countfield
action_app_id_risk
dataset in (xdr_data) |top 10 agent_hostname by _t
countfield percent
index = xdr_data | top showcount
countfield=count_agent_hostname
agent_hostname by _time dataset in (xdr_data) | filter action_app_id_risk
top_percent as percent
showcount
showperc
index = xdr_data | where
action_app_id_risk > 0 | top 3 showcount=t dataset in (xdr_data) | filter action_app_id_risk
action_app_id_risk top_percent as percent
showperc percentfield
dataset in (xdr_data) | top 10 agent_hostname by _
index = xdr_data | where
agent_hostname_percentage
action_app_id_risk > 0 | top 3 showperc=t
action_app_id_risk
percentfield
index = xdr_data | top
percentfield=agent_hostname_percentage
agent_hostname by _time
upper index=xdr_data | eval field = upper("test") dataset in (xdr_data) | alter field = uppercase("test")
var index=xdr_data | stats var (event_type) by dataset in (xdr_data) | comp var(event_type) by _time
_time
How to translate a Splunk query to XQL syntax
1. Select Incident Response → Investigation → Query Builder → XQL Search.
2. Toggle to Translate to XQL, where both a SPL query field and XQL query field are displayed.
3. Add your Splunk query to the SPL query field.
4. Click the arrow ( ).
The XQL query field displays the equivalent Splunk query using the XQL syntax.
You can now decide what to do with this query based on the instructions explained in Create XQL query.
15.7.2.8 | Graph query results
Abstract
Cortex XDR enables you to generate helpful visualizations of your XQL query results.
Building Cortex Query Language (XQL) queries in the Query Builder requires a Cortex XDR Pro license.
Displayed in the footer
Page 400 of 952
Cortex XDR Documentation
Displayed in the header
To help you better understand your Cortex Query Language (XQL) query results and share your insights with others, Cortex XDR enables you to generate
graphs and outputs of your query data directly from query results page.
1. Select Incident Response → Investigation → Query Builder → XQL.
2. Run an XQL query.
Example 28.
Enter the following query:
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 graph the results either:
Use Chart Editor
Navigate to Query Results → Chart Editor ( ) to manually build and view the graph using the selected graph parameters:
Main
Graph Type: Type of graphs and output options available: 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.
Use XQL query
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.
Example 29.
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. The custom widgets you create can be used in your
custom dashboards and reports. For more information, see Create custom XQL widgets.
Select Save to Widget Library to pivot to the Widget Library and generate a custom widget based on the query results.
15.7.3 | XQL query entities
Abstract
Learn more about the Cortex Query Language (XQL) entities available in the Query Builder.
With Query Builder, you can build complex queries for entities and entity attributes so that you can surface and identify connections between them. Cortex XDR
provides Cortex Query Language (XQL) queries for different types of entities in the Query Builder that search predefined datasets. The Query Builder searches
the raw data and logs stored in Cortex XDR tenant and for the entities and attributes you specify, it returns up to 1,000,000 results.
The Query Builder provides queries for the following types of entities:
Displayed in the footer
Page 401 of 952
Cortex XDR Documentation
Displayed in the header
Process: Search on process execution and injection by process name, hash, path, command line arguments, and more. See Create process query.
File: Search on file creation and modification activity by file name and path. See Create file query.
Network: Search network activity by IP address, port, host name, protocol, and more. See Create network query.
Image Load: Search on module load into process events by module IDs and more. See Create image load query.
Registry: Search on registry creation and modification activity by key, key value, path, and data. See Create 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 event log query.
Network Connections: Search security event logs by firewall logs, endpoint raw data over your network. See Create network connections query.
Authentications: Search on authentication events by identity, target outcome, and more. See Create authentication 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.
15.7.3.1 | Create authentication query
Abstract
Learn more about creating a query to investigate any authentication activity.
Building Cortex Query Language (XQL) queries in the Query Builder requires a Cortex XDR Pro license.
From the Query Builder, you can investigate authentication activity across all ingested authentication logs and data.
Some examples of authentication queries you can run include:
Authentication logs by severity
Authentication logs by the event message
Authentication logs for a specific source IP address
How to build an authentication query
1. From Cortex XDR , select INVESTIGATION → Query Builder.
2. Select AUTHENTICATION.
3. Enter the search criteria for the authentication query.
By default, Cortex XDR will return the activity that matches all the criteria you specify. To exclude a value, toggle the = option to =!.
4. 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.
5. When you are ready, view the results of the query. For more information, see Review XQL query results.
15.7.3.2 | Create event log query
Abstract
Learn more about creating a query to investigate Windows and Linux event log attributes and investigate event logs across endpoints.
Building Cortex Query Language (XQL) queries in the Query Builder requires a Cortex XDR Pro license.
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.
Some examples of event log queries you can run include:
Critical level messages on specific endpoints.
Message descriptions with specific keywords on specific endpoints.
How to build an event log query
1. From Cortex XDR , select INVESTIGATION → Query Builder.
Displayed in the footer
Page 402 of 952
Cortex XDR Documentation
Displayed in the header
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 the query. For more information, see Review XQL query results.
15.7.3.3 | Create file query
Abstract
Learn more about creating a query to investigate the connections between file activity and endpoints.
Building Cortex Query Language (XQL) queries in the Query Builder requires a Cortex XDR Pro license.
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, build an XQL query. For more information, see How to build XQL
queries.
Some examples of file queries you can run include:
Files modified on specific endpoints.
Files related to process activity that exist on specific endpoints.
How to build a file query
1. From Cortex XDR, select Incident Response → Investigation → Query Builder.
2. Select FILE.
3. Enter the search criteria for the file events query.
Displayed in the footer
Page 403 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR 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 +PROCESS 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.
5. (Optional) Limit the scope to an endpoint or endpoint attributes:
Select +Host 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.
Displayed in the footer
Page 404 of 952
Cortex XDR Documentation
Displayed in the header
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 the query. For more information, see Review XQL query results.
15.7.3.4 | Create image load query
Abstract
Learn more about create a query to investigate the connections between image load activity, acting processes, and endpoints.
Building Cortex Query Language (XQL) queries in the Query Builder requires a Cortex XDR Pro license.
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.
How to build an image load query
1. From Cortex XDR , 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 XDR 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.
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.
Displayed in the footer
Page 405 of 952
Cortex XDR Documentation
Displayed in the header
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 the query. For more information, see Review XQL query results.
15.7.3.5 | Create network connections query
Abstract
Learn more about creating a query to investigate the connections between firewall logs, endpoints, and network activity.
Building Cortex Query Language (XQL) queries in the Query Builder requires a Cortex XDR Pro license.
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.
How to build a network connections query
1. From Cortex XDR , select INVESTIGATION → Query Builder.
2. Select NETWORK CONNECTIONS.
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 XDR 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.
Displayed in the footer
Page 406 of 952
Cortex XDR Documentation
Displayed in the header
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.
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 the query. For more information, see Review XQL query results.
15.7.3.6 | Create network query
Abstract
Learn more about creating a query to investigate the connections between network activity, acting processes, and endpoints.
Building Cortex Query Language (XQL) queries in the Query Builder requires a Cortex XDR Pro license.
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.
How to build a network query
Displayed in the footer
Page 407 of 952
Cortex XDR Documentation
Displayed in the header
1. From Cortex XDR , 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 XDR 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.
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, view the results of the query. For more information, see Review XQL query results.
Displayed in the footer
Page 408 of 952
Cortex XDR Documentation
Displayed in the header
15.7.3.7 | Create process query
Abstract
Learn more about creating a query to investigate connections between processes, child processes, and endpoints.
Building Cortex Query Language (XQL) queries in the Query Builder requires a Cortex XDR Pro license.
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.
How to build a process query
1. From Cortex XDR , select Incident Response → Investigation → Query Builder.
2. Select PROCESS.
3. Enter the search criteria for the process query.
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 XDR 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 +PROCESS and specify one or more of the following attributes for the acting (parent) process.
Displayed in the footer
Page 409 of 952
Cortex XDR Documentation
Displayed in the header
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 +HOST 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. For more information about the data collector applet, Activate Pathfinder.
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 the query. For more information, see Review XQL query results.
15.7.3.8 | Create registry query
Abstract
Learn more about creating a query to investigate connections between registry activity, processes, and endpoints.
Building Cortex Query Language (XQL) queries in the Query Builder requires a Cortex XDR Pro license.
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.
How to build a registry query
1. From Cortex XDR , select INVESTIGATION → Query Builder.
2. Select REGISTRY.
3. Enter the search criteria for the registry events query.
Displayed in the footer
Page 410 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR 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, view the results of the query. For more information, see Review XQL query results.
15.7.3.9 | Query across all entities
Abstract
From the Cortex XDR management console, you can search for endpoints and processes across all endpoint activity.
Building Cortex Query Language (XQL) queries in the Query Builder requires a Cortex XDR Pro license.
Displayed in the footer
Page 411 of 952
Cortex XDR Documentation
Displayed in the header
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
How to build a query
1. From Cortex XDR , 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.
Field 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.
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.
Displayed in the footer
Page 412 of 952
Cortex XDR Documentation
Displayed in the header
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.
15.7.4 | Edit and rerun queries in Query Center
Abstract
Learn more about viewing the results of a query, modifying a query, and rerunning queries from Query Center.
Building Cortex Query Language (XQL) queries in the Query Builder requires a Cortex XDR Pro license.
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 XDR 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
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 XDR 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 XDR 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.
Displayed in the footer
Page 413 of 952
Cortex XDR Documentation
Displayed in the header
15.7.4.1 | Query Center reference information
Abstract
Descriptions of the fields in the Query Center table.
Building Cortex Query Language (XQL) queries in the Query Builder requires a Cortex XDR Pro license.
The table below lists the common fields in the Query Center.
Certain fields are exposed and hidden by default. An asterisk (*) is beside every field that is exposed by default.
Query Center table
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 XDR 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.
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.
Displayed in the footer
Page 414 of 952
Cortex XDR Documentation
Displayed in the header
Field Description
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. The default results for any query is a maximum
of 1,000,000 results, when no limit is explicitly stated in the query. Queries
based on XQL query entities are limited to 10,000 results. 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.
15.7.5 | Manage scheduled queries
Abstract
Learn how to manage your scheduled and recurring queries.
Building Cortex Query Language (XQL) queries in the Query Builder requires a Cortex XDR Pro license.
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 XDR filters the queries on the Query Center.
Edit the query frequency
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.
Displayed in the footer
Page 415 of 952
Cortex XDR Documentation
Displayed in the header
4. Adjust the schedule settings, and then click OK.
15.7.5.1 | Scheduled Queries reference information
Abstract
Descriptions of the fields in the Scheduled Queries table.
Building Cortex Query Language (XQL) queries in the Query Builder requires a Cortex XDR Pro license.
The table below ists the common fields in the Scheduled Queries page.
Certain fields are exposed and hidden by default. An asterisk (*) is beside every field that is exposed by default.
Scheduled Queries table
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.
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.
15.7.6 | Manage your personal query library
Abstract
Cortex XDR provides as part of the Query Library a personal library for saving and managing your own queries.
Building Cortex Query Language (XQL) queries in the Query Builder requires a Cortex XDR Pro license.
Cortex XDR 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
Displayed in the footer
Page 416 of 952
Cortex XDR Documentation
Displayed in the header
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.
How 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.
Displayed in the footer
Page 417 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR , 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 the 3 vertical dots.
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 the 3 vertical dots 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 the 3 vertical dots 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 the 3 vertical dots.
15.8 | Dashboards
Abstract
Cortex XDR dashboards help you to monitor system activity in your environment. You can use any of the predefined dashboards that are provided in Cortex
XDR, or you can create your own custom dashboards. You can also save any dashboard as a report template.
15.8.1 | About dashboards
Abstract
Dashboards help you to monitor system activity in your environment. Select a dashboard from the drop-down menu, or take actions on your dashboards from
the Dashboard Manager.
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 XDR 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.
Click the dashboard menu to see additional actions, including the option to save the dashboard as a report template, set it as your default dashboard, and
disable the background animation.
Widget specific time frames are are only supported in Cortex XDR Pro and Cortex XSIAM.
Types of dashboards
Cortex XDR provides the following types of dashboards:
Displayed in the footer
Page 418 of 952
Cortex XDR Documentation
Displayed in the header
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 Custom
dashboards.
Manage your dashboards
You can see all of your predefined and custom dashboards in the Dashboard Manager, and take the following actions:
Create, edit, and delete custom dashboards
You cannot edit the predefined dashboards but you can create a new dashboard that is based on a dashboard template.
Select your default dashboard
Create a report template based on a dashboard
Import and export dashboards
You can import and export dashboards in a JSON format, which enables you to transfer your configurations between environments for onboarding,
migration, backup, and sharing. You can also bulk export and import multiple dashboards at a time.
Dashboards that are based on custom infrastructure cannot be exported.
If you import a dashboard template that already exists in the system, the imported template will overwrite the existing template. If you do not want
to overwrite the existing template, duplicate and rename the existing template before importing the new template.
15.8.2 | Predefined dashboards
Abstract
Predefined dashboards are set up to help you monitor different aspects of your environment.
Cortex XDR provides predefined dashboards that display widgets tailored to the dashboard type. The dashboards can help you to monitor different aspects of
your environment. To access your default dashboard, select Dashboards & Reports → Dashboard. From the dashboard header, a drop-down menu lists all
available predefined and custom dashboards. The available dashboards depend on your license type.
To change your default dashboard, go to Dashboards & Reports → Dashboard Manager. In the Dashboard Manager you can also create custom dashboards
based on existing dashboards, and save dashboards as report templates.
The following predefined dashboards are available:
Dashboard Name Description Other Details
Agent management Provides an overview of the deployed agents in your Requires a Cortex XDR Prevent or Cortex XDR Pro per Endpoint
organization, their statuses and content versions, and a license.
breakdown by OS type.
Cloud inventory Provides an overview of your cloud-based assets. Requires a Cortex XDR Pro per GB license.
Data ingestion Provides an overview of data ingestion by product and Requires a Cortex XDR Pro license.
vendor, the daily quota consumption, and your data
ingestion rate. 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 Query Language (XQL) queries on the metrics_center data
set.
Displayed in the footer
Page 419 of 952
Cortex XDR Documentation
Displayed in the header
Dashboard Name Description Other Details
Incident Provides a breakdown of the top incidents and hosts in Select the star in the the right corner of a widget to filter the data for
management your environment, and an overview of the top incident incidents that match incident starring policies.
assignees.
A purple star indicates that the widget is displaying only starred
incidents. The starring filter is persistent and continues to show the
filtered results until you clear the star.
My dashboard Provides an overview of the incidents and MTTR for the
logged-in user.
Network traffic Provides an overview of network traffic analysis, and Requires a Cortex XDR Pro license.
analysis (NTA) highlights key pieces of information.
NGFW ingestion Provides an overview of ingestion status for all log types, Requires a Cortex XDR Pro per GB license.
the daily quota consumption for NGFW, and a
breakdown by log type.
Risk management Provides alert and incident information to aid in risk Requires a Cortex XDR Pro license and the Identity Threat Module
assessment by highlighting information about add-on to be enabled.
compromised accounts and insider threats.
The alerts displayed in this dashboard are tagged by the
research as Identity Threat alerts or Identity Analytics
alerts. An incident is displayed if any of its associated
alerts are tagged as an Identity threat or an Identity
Analytics threat.
Security admin Provides an overview of the incidents in your
organization, and the status of resolved and overdue
incidents.
Security manager Provides general information about Cortex XDR Requires a Cortex XDR Pro per Endpoint license.
incidents and agents.
15.8.3 | Custom dashboards
Abstract
Custom dashboards can support your day-to-day operations by providing options that are tailored to your unique workflow.
You can create custom dashboards that are tailored to your unique workflow and support your day-to-day operations. Cortex XDR provides dashboard
templates that are based on the predefined dashboards, or you can build dashboards from scratch by selecting widgets and choosing their placement on the
dashboard.
You can see all predefined and custom XQL widgets in the Widget Library. Custom XQL widgets are built on Cortex Query Language (XQL) queries and
provide the flexibility to query specific data, and select the graphical format you require (such as table, line graph, or pie chart).
To enhance the functionality of your dashboards, you can also configure fixed filters and dashboard drilldowns that enabling dashboard users to filter and
manipulate the displayed data as follows:
Fixed filters enable dashboard users to alter the scope of the dashboard by selecting predefined or dynamic input values from the filters in the
dashboard header.
Dashboard drilldowns provide dashboard users with interactive data insights when clicking on data points in widgets. Drilldowns can trigger contextual
changes on the dashboard, or they can link to an XQL search, a custom URL, another dashboard, or a report. Users can hover over a widget to see
details about the drilldown, and click a value to trigger the drilldown.
Displayed in the footer
Page 420 of 952
Cortex XDR Documentation
Displayed in the header
Fixed filters and drilldowns are based on parameters that you define in custom XQL widgets, and are available on custom dashboards with XQL widgets only.
For more information, see Configure fixed dashboard filters and Configure dashboard drilldowns.
Custom XQL widgets, fixed filters, and dashboard drilldowns are supported in Cortex XDR Pro and Cortex XSIAM only.
15.8.3.1 | Build a custom dashboard
Abstract
Build customized dashboards to display and filter the information that is most relevant to you.
You can build custom dashboards based on predefined dashboard templates, or you can build a new dashboard from scratch.
1. Select Dashboards & Reports → Customize → Dashboards Manager → + New Dashboard.
2. In the Dashboard Builder, under Dashboard Name enter a unique name for the dashboard.
3. Under Dashboard Type, choose a built-in dashboard template or a blank template, and click Next.
4. Customize your dashboard.
To get a feel for how the data will look, Cortex XDR provides mock data. To see how the dashboard would look with real data in your environment,
change the toggle to Real Data.
5. Add widgets to the dashboard. From the widget library, drag widgets on to the dashboard.
Notes for agent-related widgets and incident-related widgets
For agent-related widgets, you can 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.
For incident-related widgets, you can limit your incidents to only those that match an incident starring configuration on your dashboard. A purple
star indicates that the widget is displaying only starred incidents. For more information, see Incident starring.
6. (Optional) Configure fixed filters and inputs.
What are fixed filters and inputs?
Add fixed filters to your dashboard to provide dashboard users with useful dashboard filters that are based on predefined or dynamic input values. Any
defined filters are displayed in the dashboard header.
Fixed filters are based on XQL widgets with dynamic parameters. If a dashboard contains these widgets, the Add Filters & Inputs option is displayed. For
more information, see Configure fixed dashboard filters.
This feature requires a Cortex XDR Pro or Cortex XSIAM license.
7. (Optional) Configure dashboard drilldowns.
What are dashboard drilldowns?
Add drilldowns to your dashboard to provide interactive data insights when clicking on data points, table rows, or other visualization elements.
Dashboard drilldowns are based on XQL widgets. To add a drilldown to an XQL widget, click on the widget menu, and select Add drilldown. For more
information, see Configure dashboard drilldowns.
This feature requires a Cortex XDR Pro or Cortex XSIAM license.
8. Under Time Range, set a time range for your dashboard.
By default, the widgets use the dashboard time frame. You can change the widget time frame from the widget menu.
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.
Otherwise, the dashboard is public and visible to all Cortex XDR users with the appropriate roles to view dashboards.
12. Click Generate to complete your dashboard.
15.8.3.2 | Manage your Widget Library
Abstract
Create, search, and view custom widgets in Cortex XDR, or use predefined widgets.
Displayed in the footer
Page 421 of 952
Cortex XDR Documentation
Displayed in the header
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.
From the Widget Library you can take the following actions:
Create custom widgets based on XQL search queries. For more information see Create custom XQL widgets.
Search for custom and predefined widgets. Widgets are grouped by category.
Edit or delete custom widgets.
Any dashboards or reports that include the widget are affected by the changes.
15.8.3.3 | Create custom XQL widgets
Abstract
You can create custom XQL widgets based on a Cortex Query Language (XQL) query, and add parameters that you can configure as fixed filters or
dashboard drilldowns.
Custom XQL widgets are supported in Cortex XDR Pro and Cortex XSIAM only.
With custom XQL widgets you can personalize the information that you display on your custom dashboards and reports. You can build widgets that query
specific information that is unique to your workflow, and define the graphical format you require (such as table, line graph, or pie chart).
All of your predefined and custom XQL widgets are available in the Widget Library under Dashboards & Reports → Customize → Widget Library. From the
Widget Library, you can browse all widgets by category, create new XQL widgets, and edit and delete existing XQL widgets.
How to create a custom XQL widget
1. In the Widget Library, select Create custom XQL widget.
2. Enter a widget name and an optional description.
3. Define an XQL query that searches for the data you require. Select XQL Helper to view XQL search and schema examples. For more information, see
How to build XQL queries.
4. Select Preview to review the search results.
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 parameters to filter widget data on a dashboard or report, and create drilldowns on dashboards. Base your filters on fields and values in the
query results.
Take the following steps
1. In the search results, identify a field by which you want to filter.
2. Using the filter stage, define parameters prefixed with $.
To specify parameters with a single predefined value, use the = operator. To specify parameters with multiple values (predefined or dynamic), use
the IN operator.
Example of a single value parameter
Example 30. Single value parameters
The following query defines the $domain parameter for filtering dashboard data by domain, based on the domain field in the agent_auditing
dataset.
Single value parameters are based on static predefined values. In this example, the dashboard user will be able to select a domain from a list of
predefined domains.
dataset = agent_auditing | filter domain = $domain
Example of a multiple value parameter
Example 31. Multiple value parameters
The following query defines the $endpointname parameter for filtering dashboard data by one or more endpoint names, based on the
endpoint_name field in the agent_auditing dataset.
You can configure this parameter with static predefined values, or dynamic values that are pulled from an XQL query.
Displayed in the footer
Page 422 of 952
Cortex XDR Documentation
Displayed in the header
dataset = agent_auditing | filter endpoint_name IN ($endpointname)
3. (Optional) Under Assign Parameters (default values), define default values for the parameters. When you add the widget to a dashboard or report,
the data will be automatically populated. Alternatively, you can configure all input values when you set up a dashboard or report.
7. (Optional) Specify a time frame. The default time frame is 1M.
8. Save the widget.
The custom widget appears in the list of existing widgets.
15.8.3.4 | Configure fixed dashboard filters
Abstract
Configure fixed filters that enable dashboard users to alter the scope of the dashboard by selecting predefined and dynamic values.
Fixed dashboard filters are supported in Cortex XDR Pro and Cortex XSIAM only.
Define fixed filters on your dashboards to enable dashboard users to alter the scope of the dashboard by selecting from predefined or dynamic values. You
can define filters with free text, single select, and multiple select input values. After configuration, anyone who views your dashboard can use the fixed filters in
the dashboard header.
Fixed filters are based on parameters that are defined in custom XQL widgets. Before you can configure fixed filters, take the following steps:
1. Create custom XQL widgets with parameters. For more information, see Create custom XQL widgets.
2. Add the widgets to a Custom dashboard. For more information, see Custom dashboards.
How to configure fixed dashboard filters
1. Open a custom dashboard, and select Edit dashboard.
2. Click Add Filters & Inputs.
This option only appears if the dashboard contains custom XQL widgets with defined parameters.
3. Under Parameter Title enter a name that identifies the parameter.
4. On the FILTERS & INPUTS panel, click +Add an input and select one of the following options:
To specify a single predefined value, select Single Select.
To specify multiple predefined or dynamic values, select Multi Select.
To specify a single free text value, select Free text/number.
Guidelines
Select an option that corresponds with the parameter configured in the XQL widget. Parameters with single predefined or free text values use the =
operator, and parameters with multiple values, use the IN operator.
Predefined values are most suitable for filtering fields that have static values, such as status fields with a limited number of available options.
Dynamic values help you to filter with values that change often. You can configure an XQL query that extracts all of the values that are available for
that field. For example, in the endpoints dataset, the endpoint_name field values can change frequently.
5. Click Parameter and select the parameter that you want to configure.
The parameters are extracted from the XQL queries of the widgets on the dashboard. You can define up to four parameter filters on a report or
dashboard.
6. If you selected Single Select or Multi Select values, click Dropdown Options and specify input values. When you generate the dashboard, these input
values appear in a dropdown list for selection.
Displayed in the footer
Page 423 of 952
Cortex XDR Documentation
Displayed in the header
To configure Predefined inputs for Single Select and Multi Select values, manually type the list values.
Guidelines
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".
To configure Dynamic inputs for Multi Select values, click XQL Query to fetch dynamic values.
Guidelines
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.
Example 32. Example
In this example, the endpoint_name field is configured. The dashboard user will be able to filter by one or more values from the endpoint_name
field.
dataset =endpoints | fields endpoint_name
If you specify more than one field, only the first field value is used.
7. Under Default Value, select a value from the list of defined values. Specifying a default value ensures that the widget is automatically populated when
you open the dashboard.
8. Click Save Filters & Inputs and save your dashboard.
After the initial setup, when you access your dashboard the filters and inputs might need further refinement. You can make changes to the configured
parameters in the XQL widgets, and update the Filters & Inputs on your dashboard until you are satisfied with the results.
15.8.3.5 | Configure dashboard drilldowns
Abstract
Configure drilldowns on custom dashboards to provide users with interactive data insights when clicking on data points in a widget
Dashboard drilldowns are supported in Cortex XDR Pro and Cortex XSIAM only.
Dashboard drilldowns can trigger contextual changes on the dashboard, or they can link to an XQL search, a custom URL, another dashboard, or a report.
You configure drilldowns on individual widgets. After a drilldown is configured, clicking the widget triggers the drilldown.
To configure drilldowns your dashboard must contain custom XQL widgets. In addition, if you want to configure in-dashboard drilldowns your custom XQL
widget must contain one or more parameters. For more information about configuring parameters in custom XQL widgets, see Create custom XQL widgets.
How to configure dashboard drilldowns
1. Open a custom dashboard and select Edit dashboard.
2. Identify 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:
Displayed in the footer
Page 424 of 952
Cortex XDR Documentation
Displayed in the header
In-Dashboard Drilldown: Interactively filters the dashboard data. Filters are based on the parameters defined in the custom XQL widgets on the
dashboard.
Define the following values:
Field Action
Parameters Select the parameter by which to filter. You can choose any parameter that is defined in the XQL query of the widget.
If the selected parameter is configured in other XQL widgets on the dashboard, these widgets are also affected by the
drilldown.
Value When a user clicks the widget, the dashboard is filtered by this value.
Type your own value.
Select a variable from which to capture the clicked value, for example, the $y-axis.value in a chart. For more information,
see Variables in drilldowns.
Link to dashboard: Opens a target dashboard.
Define the following values:
Field Action
Dashboard Select the target dashboard.
(Optional) Select parameters by which to filter the data on the target dashboard. Parameters are only available if there are
Parameter parameters defined in the widgets on the target dashboard.
(Optional) Value When a user clicks the widget, this value is configured as a parameter on the target dashboard.
Type your own value.
Select a variable from which to capture the clicked value in the source dashboard, for example, the $y-axis.value in
a chart. For more information, see Variables in drilldowns.
Open XQL Search: Runs an XQL query based on the clicked value.
Define the following values:
Field Action
XQL Define the query that you want to run on drilldown.
Query
Type $ to see autocomplete options for variables that are available in the widget drilldown. For example, in a table widget
$first.name selects the leftmost column name in the table. 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: Opens an external URL based on a clicked value.
Displayed in the footer
Page 425 of 952
Cortex XDR Documentation
Displayed in the header
Define the following values:
Field Action
URL Type the URL.
Address
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: Runs a report from a clicked value.
15.8.3.5.1 | Variables in drilldowns
Abstract
Learn about the widget variable values that you can use in dashboard 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.
Displayed in the footer
Page 426 of 952
Cortex XDR Documentation
Displayed in the header
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...
Displayed in the footer
Page 427 of 952
Cortex XDR Documentation
Displayed in the header
$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.
15.8.4 | Reports
Abstract
Create, edit, and customize reports in Cortex XDR. 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 XDR, 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.
15.8.4.1 | Report templates
Abstract
View, import, export, create, and modify report templates
On the Report Templates page, you can view, delete, import, export, create, and modify report templates. You can also select and generate multiple reports.
15.8.4.2 | Run or schedule reports
Abstract
You can run reports that are based on dashboard templates, or you can create reports from scratch.
You can generate reports using pre-designed dashboard templates, or create custom reports from scratch with widgets from the Widget Library. You can also
schedule your reports to run regularly or just once. All reports are saved under Dashboards & Reports → Reports.
To take actions on existing report templates, go to Dashboards & Reports → Customize → Report Templates. On this page you can also import and export
report templates in a JSON format, which enables you to transfer your configurations between environments for onboarding, migration, backup, and sharing.
You can bulk export and import multiple report templates at a time.
Report templates that are based on custom infrastructure cannot be exported.
If you import a report template that already exists in the system, the imported template will overwrite the existing template. If you do not want to overwrite
the existing template, duplicate and rename the existing template before importing the new 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 name for the report and an optional description, and click Save.
4. Select Dashboards & Reports → Customize → Report Templates.
5. Locate your report and take one of the following actions:
To run the report without make any modifications, hover over the report name, and select Generate Report.
To modify or schedule the report, hover over the report name, and select Edit.
6. After your report completes, you can download it from the Dashboards & Reports → Reports page.
Create a new report template
You can base your report on an existing template, or you can start with a blank template.
1. Select Dashboards & Reports → Customize → Reports Templates → + New Template.
2. Enter a unique name for the report and an optional description.
3. Under Data Timeframe, select the time frame from which to run the report. Custom time frames are limited to one month.
Displayed in the footer
Page 428 of 952
Cortex XDR Documentation
Displayed in the header
4. Under Report Type select the report template on which to base the report, or select a blank template to build the report from scratch.
5. Customize your report.
Cortex XDR offers mock data to help you visualize the data's appearance. To see how the report would look with real data in your environment, switch to
Real Data. Select Preview in A4 to see how the report is displayed in an A4 format.
6. Add or remove widgets to the report. From the widget library, drag widgets on to the report.
Notes for agent-related widgets and incident-related widgets
For agent-related widgets, you can 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.
For incident-related widgets, you can limit your incidents to only those that match an incident starring configuration on your dashboard. A purple
star indicates that the widget is displaying only starred incidents.
7. (Optional) Include filters in the report.
Filters are supported only in Cortex XDR Pro and Cortex XSIAM.
For reports that include Custom XQL widgets with predefined parameters, the FILTERS & INPUTS option is displayed. Defining filters and inputs for the
report gives you the flexibility to filter the report data based on default values that you define.
Steps to configure filters and inputs
1. Select + Add Filters & Inputs.
2. On the FILTERS & INPUTS panel, click +Add an input and select one of the following options:
To specify a single predefined value, select Single Select.
To specify multiple predefined values, select Multi Select.
To specify a single free text value, select Free text/number.
3. Under Parameter Title enter a name that identifies the parameter.
4. Under Parameter, select the parameter that you want to configure.
The parameters are extracted from the XQL queries of the widgets on the dashboard. You can define up to four parameter filters on a report or
dashboard.
5. Under Default Value, specify a value for the selected parameters. This value overwrites any predefined default values in the XQL query.
The values must support the parameter type. For example, for $name specify characters and for $num specify numbers.
6. Click 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, or define options for scheduling the report.
10. (Optional) Under Email Distribution and Slack workspace add the recipients that you want to receive a PDF version of your report.
Select Add password used to access report sent by email and Slack to set password encryption. Password encryption is only available in PDF format.
11. (Optional) Select Attach CSV to attach CSV files of your XQL query widgets to the report.
From the menu, select one or more of your custom widgets to attach to the report. The CSV files of the widgets are attached to the report along with the
report 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 20 MB.
Slack: Sent within a ZIP file that includes the PDF file.
12. Click Save Template.
13. After your report completes, you can download it from the Dashboards & Reports → Reports page.
In the Name field, icons indicate the number of attached files for each report. Reports with multiple PDF and CSV files are marked with a zip icon.
Reports with a single PDF are marked with a PDF icon.
Configure the notification rule for a failed report
You can receive an email alert if a report fails to run due to a timeout or fails to upload to the GCP bucket.
1. Under Settings → Configurations → General → Notifications, click + Add Forwarding Configuration.
2. Enter a name and a description for your rule, and under Log Type, select Management Audit Logs.
Displayed in the footer
Page 429 of 952
Cortex XDR Documentation
Displayed in the header
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.
15.9 | 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 XDR. 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.
For hosts, Cortex XDR 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 the Asset Inventory for a specific asset name or IP address. In addition, the following 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 XDR 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 open the Quick Launcher by clicking the Quick Launcher icon located in the top navigation bar, or from the application menus, or by using the default
keyboard shortcut: Ctrl-Shift+X on Windows or CMD+Shift+X on macOS. 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.
15.10 | Research a known threat
Abstract
Cortex XDR enables you to investigate any threat, also referred to as a lead, which has been detected.
Requires a Cortex XDR Pro license.
This topic describes the 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.
Users or hosts that have been reported as acting abnormally.
Information from online articles or other external threat intelligence that provides well-defined characteristics of the threat.
To research a known threat
1. Use threat intelligence to build a Cortex Query Language (XQL) query using the Query Builder.
For example, if external threat intelligence indicates a confirmed threat involving specific files or behaviors, search for those characteristics.
2. Review and refine the query results by using filters and running follow-up queries to find the information you are looking for.
3. Select an event of interest, and open the Causality view.
Displayed in the footer
Page 430 of 952
Cortex XDR Documentation
Displayed in the header
Review the chain of execution and data, navigate through the processes on the tree, and analyze the information. For more information, see Causality
view.
4. Open the Timeline to view the sequence of events over time. If deemed malicious, take action using one or more of the response actions. For more
information, see Timeline.
5. Inspect the information again, and identify any characteristics you can use to create a BIOC or correlation rule.
If you can create a BIOC or correlation rule, test and tune it as needed. For more information, see Create a correlation rule and Create a BIOC rule.
16 | Data management
16.1 | Broker VM
Abstract
Set up a Broker VM to establish a secure connection in which you can route your endpoints, and collect and forward logs and files for analysis.
Set up and configure the Broker VM to create a secure connection for routing endpoints, collecting logs, and forwarding logs and files for analysis. Learn how
to manage the Broker VM, and implement it within a high availability (HA) cluster setup.
16.1.1 | What is the Broker VM?
Abstract
Learn about the Cortex XDR Broker virtual machine (VM) and why use it in your network configuration.
The Palo Alto Networks Broker VM is a secured virtual machine, integrated with Cortex XDR, that bridges your network and Cortex XDR. 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.
Cortex XDR 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 XDR, providing you with new capabilities without having to install a new
VM or manually update the existing VM.
According to your Cortex XDR license, the following figure illustrates the different Broker VM features that could be available on your organization side:
Displayed in the footer
Page 431 of 952
Cortex XDR Documentation
Displayed in the header
16.1.2 | Set up and configure Broker VM
Abstract
Learn more about how to set up and configure a Broker VM as a standalone broker or add the broker to a high availability (HA) cluster.
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. For more information, see
Broker VM High Availability Cluster.
Setup
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.
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 with a Cortex XDR Pro license, the optimal outgoing bandwidth into the Cortex XDR server should be about 25% of the
incoming data traffic into the Broker VM applets.
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 XDR, 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 Broker Image Installation
Alibaba Cloud QCOW2 Set up Broker VM on Alibaba Cloud
Displayed in the footer
Page 432 of 952
Cortex XDR Documentation
Displayed in the header
Infrastructure Image Type Broker Image Installation
Amazon Web Services (AWS) VMDK Set up Broker VM on Amazon Web Services
Google Cloud Platform VMDK Set up Broker VM on Google Cloud Platform
(GCP)
KVM QCOW2 Set up Broker VM on KVM using Ubuntu
Microsoft Azure VHD (Azure) Set up Broker VM on Microsoft Azure
Microsoft Hyper-V 2012 VHD Hyper-V 2012 or later
Set up Broker VM on Microsoft Hyper-V
Nutanix Hypervisor QCOW2 Nutanix AHV 2021
Set up Broker VM on Nutanix Hypervisor
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
time.google.com can 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 XDR 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 XDR
Enable access to Cortex XDR from the Broker VM to allow communication between agents and collectors and Cortex XDR.
Displayed in the footer
Page 433 of 952
Cortex XDR Documentation
Displayed in the header
For more information on enabling access to Cortex XDR, see Enable access to required PANW resources.
Collectors are only supported with a Cortex XDR Pro per GB license.
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. For more information on adding a trusted self-signed certificate authority, see Update the Trusted CA Certificate for the Broker VM in Task 1.
Configure the Broker VM settings.
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.
You'll paste this token after configuring settings and the Broker VM is registered in Task 2. Register your Broker VM.
Task 2. Open the Broker VM URL
Depending on the Broker VM version, navigate to either of the following URLs:
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>/
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
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.
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 interfaces 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.
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 earlier, Cortex XDR will only accept 172.17.0.0/16.
3. (Optional) Configure a proxy server address and other related details to route Broker VM communication.
Proxy Server
Displayed in the footer
Page 434 of 952
Cortex XDR Documentation
Displayed in the header
1. Select the proxy Type as HTTP, SOCKS4, or SOCKS5.
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
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 XDR support who need the private key. You must have Instance Administrator role permissions to configure
SSH access.
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]
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
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, Cortex XDR automatically updates them in the tenant UI. Cortex XDR validates that the
certificate and key match, but does not validate the Certificate Authority (CA).
The Palo Alto Networks Broker VM 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
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.
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 XDR 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 XDR 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.
16.1.2.1 | Broker VM image installations
Abstract
Learn more about the Broker VM image types available that are compatible with your viirtual machine (VM).
Displayed in the footer
Page 435 of 952
Cortex XDR Documentation
Displayed in the header
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 Broker Image Installation
Alibaba Cloud QCOW2 Set up Broker VM on Alibaba Cloud
Amazon Web Services (AWS) VMDK Set up Broker VM on Amazon Web Services
Google Cloud Platform VMDK Set up Broker VM on Google Cloud Platform
(GCP)
KVM QCOW2 Set up Broker VM on KVM using Ubuntu
Microsoft Azure VHD (Azure) Set up Broker VM on Microsoft Azure
Microsoft Hyper-V 2012 VHD Hyper-V 2012 or later
Set up Broker VM on Microsoft Hyper-V
Nutanix Hypervisor QCOW2 Nutanix AHV 2021
Set up Broker VM on Nutanix Hypervisor
VMware ESXi OVA VMware ESXi 6.5 or later
Set up Broker VM on VMware ESXi using
vSphere Client
16.1.2.1.1 | Set up Broker VM on Alibaba Cloud
Abstract
Learn how to set up your Cortex XDR Broker virtual machine (VM) on Alibaba Cloud.
After you download your Cortex XDR 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.
Download a Cortex XDR Broker VM QCOW2 image. For more information, see the virtual machine compatability requirements in Set up and configure Broker
VM.
Perform the following procedures in the order listed below.
Task 1. Download the ossutil utility file provided by Alibaba Cloud
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)
Displayed in the footer
Page 436 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR
-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 XDR
-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 XDR
-broker-vm-14.0.1.qcow2
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.
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:
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...
Displayed in the footer
Page 437 of 952
Cortex XDR Documentation
Displayed in the header
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.
Task 5. Reboot the Broker VM
Reboot the Broker VM before logging in for the first time.
16.1.2.1.2 | Set up Broker VM on Amazon Web Services
Abstract
Learn how to set up your Cortex XDR Broker virtual machine (VM) on AWS.
After you download your Cortex XDR 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.
Download a Cortex XDR Broker VM VMDK image. For more information, see the virtual machine compatability requirements in Set up and configure
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
Displayed in the footer
Page 438 of 952
Cortex XDR Documentation
Displayed in the header
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.
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:
Displayed in the footer
Page 439 of 952
Cortex XDR Documentation
Displayed in the header
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.
Task 3. Create an AMI Image
To create an AMI image, you need to download Broker VM VMDK file from the Cortex XDR 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 XDR 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 XDR 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.
Displayed in the footer
Page 440 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR 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>/*"
]
},
Displayed in the footer
Page 441 of 952
Cortex XDR Documentation
Displayed in the header
{
"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 XDR Broker VM <Version>" --disk-containers
"file://configuration.json"
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.
A t2.medium (4GB RAM) is the lowest machine type that can be used as an instance type. Usually, the lowest machine type is sufficient with the Local Agent
Settings applet. Yet, when enabling more applets, 8 GB is required.
1. To view the AMI image that you added, select Services → EC2 → Images → AMIs.
2. Select EC2 → Instances, and click Launch instances to create an instance of the AMI image.
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.
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 XDR is performed from the Broker VM Web Console.
Displayed in the footer
Page 442 of 952
Cortex XDR Documentation
Displayed in the header
1. Obtain a registration token from the Cortex XDR 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.
16.1.2.1.3 | Set up Broker VM on Google Cloud Platform (GCP)
Abstract
Learn more about how to set up your Cortex XDR 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 XDR.
Download a Cortex XDR Broker VM VMDK image. For more information, see the virtual machine compatability requirements in Set up and configure
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.
The import tool uses Cloud Build API, which must be enabled in your project. For the 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
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
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.
Displayed in the footer
Page 443 of 952
Cortex XDR Documentation
Displayed in the header
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 specific 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 with https over port 4443 using the format https://<ip
address>:4443.
16.1.2.1.4 | Set up Broker VM on KVM using Ubuntu
Abstract
Learn set up your Cortex XDR Broker virtual machine (VM) on a KVM using Ubuntu.
After you download your Cortex XDR 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.
Download a Cortex XDR Broker VM QCOW2 image. For more information, see the virtual machine compatability requirements in Set up and configure 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.
6. Define the Step 3 screen of the wizard:
Displayed in the footer
Page 444 of 952
Cortex XDR Documentation
Displayed in the header
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.
16.1.2.1.5 | Set up Broker VM on Microsoft Azure
Abstract
Learn how to set up your Cortex XDR Broker virtual machine (VM) on Microsoft Azure.
After you download your Cortex XDR Broker VHD (Azure) image, you need to upload it to Azure as a storage blob.
Download a Cortex XDR Broker VM VHD (Azure) image. For more information, see the virtual machine compatability requirements in Set up and configure
Broker VM.
Perform the following procedures in the order listed below.
Task 1. Extract the downloaded VHD (Azure) image
Make sure you extract the zipped hard disk file on a server that has more then 512 GB of free space.
Extraction can take up to a few hours.
Task 2. Create a new storage blob on your Azure account by uploading the VHD file
Upload 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 run 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>.
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.
Displayed in the footer
Page 445 of 952
Cortex XDR Documentation
Displayed in the header
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
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:
Read more...
Heading Parameter
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 XDR 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:
Read more...
Heading Parameter
Instance (Optional) Virtual machine name: Enter the same name as the disk name you defined.
details
Size: Select the size according to your company guidelines.
Select Next to navigate to the Networking tab.
Network NIC network security group—Select Advanced.
interface
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.
Displayed in the footer
Page 446 of 952
Cortex XDR Documentation
Displayed in the header
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.
Creating the VM can take up to 15 minutes. The Broker VM Web UI is not accessible during this time.
6. Ensure that the VM you created contains an Outbound port rule that allows the broker to reach the Azure Instance Metadata Service using the IP
address 169.254.169.254 and port 80. For more information about the Azure Instance Metadata Service, see the Azure Documentation.
To configure an outbound rule on your VM, select Networking → Network settings, and under the Rules → Outbound port rules section, you can either:
For more information on creating a rule in an Azure VM, see Create a Security Rule in the Azure Documentation.
Configure a new outbound port rule by selecting Create port rule → Outbound port rule and setting the following settings in the Add outbound
security rule dialog box:
Destination: Select IP Addresses.
Destination IP addresses/CIDR ranges: Enter the IP address as 169.254.169.254.
Destination port ranges: Enter the port as 80.
Protocol: Select TCP.
Name: Enter a unique name for this new outbound port rule, such as AzureInstanceMetadataService.
Click Add to create the new outbound port rule.
Edit an existing outbound port rule and ensure that the settings provided above for creating a new outbound port rule match what is already
configured in the rule.
16.1.2.1.6 | Set up Broker VM on Microsoft Hyper-V
Abstract
Learn how to set up your Cortex XDR Broker virtual machine (VM) on Microsoft Hyper-V.
To set up a Broker virtual machine (VM) image on Microsoft Hyper-V, you need to download a Cortex XDR Broker VM VHD image, and then upload it to your
newly created Microsoft Hyper-V VM. Microsoft Hyper-V 2012 or later is supported.
Download a Cortex XDR Broker VM VHD image. For more information, see the virtual machine compatability requirements in Set up and configure Broker VM.
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.
16.1.2.1.7 | Set up Broker VM on Nutanix Hypervisor
Abstract
Learn how to set up your Cortex XDR Broker virtual machine (VM) on Nutanix Hypervisor.
Displayed in the footer
Page 447 of 952
Cortex XDR Documentation
Displayed in the header
After you download your Cortex XDR Broker virtual machine (VM) QCOW2 image, you need to upload it to a Nutanix hypervisor. The Nutanix AHV 2021 version
is supported.
Download a Cortex XDR Broker VM QCOW2 image. For more information, see the virtual machine compatability requirements in Set up and configure 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.
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:
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.
Displayed in the footer
Page 448 of 952
Cortex XDR Documentation
Displayed in the header
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.
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.
16.1.2.1.8 | Set up Broker VM on VMware ESXi using vSphere Client
Abstract
Learn more about how to set up you Cortex XDR Broker VM on VMware ESXi.
To set up the Broker VM on VMware ESXi, you deploy the OVA image provided in Cortex XDR. VMware ESXi 6.5 or later is supported. The instructions below
provide an example of doing this using vSphere Client 7.0.3.01400.
Ensure you have a virtualization platform installed that is compatible with an OVA image, and have an authenticated user account.
Download a Cortex XDR Broker VM OVA image. For more information, see the virtual machine compatibility requirements in Set up and configure 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.
16.1.2.2 | Broker VM data collector applets
Abstract
Learn more about the different Broker VM data collector applets available to configure.
Data collector applets, except for the Local Agent Settings applet, require a Cortex XDR Pro per GB license. Pathfinder requires a Cortex XDR Pro per
Endpoint or Cortex XDR Pro per GB license.
The Broker VM has a number of data collector applets that you can configure to ingest different types of data. These data collector applets are in addition to
the others that are available in the Settings → Configurations → Data Collection → Collection Integrations page with a Cortex XDR Pro license.
Displayed in the footer
Page 449 of 952
Cortex XDR Documentation
Displayed in the header
16.1.2.2.1 | Activate Apache Kafka Collector
Abstract
Learn more about activating the Broker VM with an Apache Kafka Collector applet.
Ingesting logs and data from external sources requires a Cortex XDR Pro per GB license.
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.
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.
Set up and configure Broker VM
How to activate the Kafka Collector
1. Select Settings → Configurations → Data Broker → Broker VMs.
2. Do one of the following:
On the Brokers tab, find the Broker VM, and in the APPS column, left-click Add → Kafka Collector.
On the Clusters tab, find the Broker VM, and in the APPS column, left-click Add → Kafka Collector.
3. 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.
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.
Displayed in the footer
Page 450 of 952
Cortex XDR Documentation
Displayed in the header
4. 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 XDR 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).
For CEF and LEEF logs, Cortex XDR takes the vendor and product names from the log itself, regardless of what you configure on this page.
(optional) Add Query
Click 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.
5. (Optional) Click Add Connection to create another Kafka Connection for collecting data.
6. (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.
7. Activate the Kafka Collector applet. The Activate button 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.
8. (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 XDR displays Resources, including the amount of CPU, Memory, and Disk space the applet is using.
9. Manage the Kafka Collector.
Displayed in the footer
Page 451 of 952
Cortex XDR Documentation
Displayed in the header
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.
16.1.2.2.2 | Activate CSV Collector
Abstract
Learn more about activating the Broker VM with a CSV Collector applet.
Ingesting logs and data from external sources requires a Cortex XDR Pro per GB license.
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 XDR
using a username and password.
Before activating the CSV Collector applet, review and perform the following:
Set up and configure 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. Do one of the following:
On the Brokers tab, find the Broker VM, and in the APPS column, left-click Add → CSV Collector.
On the Clusters tab, find the Broker VM, and in the APPS column, left-click Add → CSV Collector.
3. 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
XDR. You must also specify a username and password.
Mounted Folders
Define the folders mounted onto the Broker VM:
Field Description
Folder Specify the complete file path to the Windows directory containing the shared CSV files using the format: //host/<folder_path>.
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
Displayed in the footer
Page 452 of 952
Cortex XDR Documentation
Displayed in the header
Field Description
Folder Path Select the monitored Windows directory and specify the name of the CSV file. Use a wildcard file search using these characters in
+ Name the name of the directory, CSV file name, and Path Exclusion.
?: 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.
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.
Path Specify the complete file path for any files from the Windows directory that you do not want included. The same wildcard file search
Exclusion characters are allowed in this field as explained above for the FOLDER PATH +NAME field. For example, if you want to exclude any
(Optional) CSV file prefixed with 'exclude_' in the directory and subdirectories of //host/<folder_path>, use the syntax
//host/<folder_path>/**/exclude_*.csv.
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
(Optional) the format <data>_<tag>.
Target Either select the target dataset for the CSV data or create a new dataset by specifying the name for the new dataset.
Dataset
4. Activate the CSV Collector applet.
After a successful activation, the APPS field displays CSV with a green dot indicating a successful connection.
The CSV Collector checks for new CSV files every 10 minutes.
5. (Optional) To view metrics about the CSV Collector, left-click the CSV connection in the APPS field for your Broker VM.
Cortex XDR displays Resources, including the amount of CPU, Memory, and Disk space the applet is using.
6. 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.
16.1.2.2.3 | Activate Database Collector
Abstract
Learn more about activating a Broker VM with a Database Collector applet.
Ingesting logs and data from external sources requires a Cortex XDR Pro per GB license.
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 XDR 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 XDR .
Before activating the Database Collector applet, review and perform the following:
Set up and configure Broker VM
How to activate the Database Collector
Displayed in the footer
Page 453 of 952
Cortex XDR Documentation
Displayed in the header
1. Select Settings → Configurations → Data Broker → Broker VMs.
2. Do one of the following:
On the Brokers tab, find the Broker VM, and in the APPS column, left-click Add → DB Collector.
On the Clusters tab, find the Broker VM, and in the APPS column, left-click Add → DB Collector.
3. Configure your Database Collector settings.
Database Connection
Field Description
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 Enter the username to access the database.
Password Enter the password to access the database.
Test Select to validate the database connection.
Connection
Database Query
Field Description
Rising Specify a column for the Database Collector applet to keep track of new rows from one input execution to the next. This column must
Column be included in the query results.
Retrieval Specify a Retrieval Value for the Database Collector applet to determine which rows are new from one input execution to the next.
Value Cortex XDR 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.
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
(Optional) 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 (>).
Displayed in the footer
Page 454 of 952
Cortex XDR Documentation
Displayed in the header
Field Description
Collect Specify the execution frequency of collection by designating a number and then selecting the unit as either Seconds, Minutes,
Every Hours, or Days.
Vendor and Specify the Vendor and Product for the type of data being collected. The vendor and product are used to define the name of your
Product 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 Select Generate Preview to display up to 10 rows from the SQL Query and Preview the results. The Preview works based on the
Preview Database Collector settings, which means that if after running the query no results are returned, then the Preview returns no records.
Add Query To define another Query for data collection on the configured database connection, select Add Query. Another Query section is
(Optional) displayed for you to configure.
4. (Optional) Click Add Connection to define another database connection to collect data from another client relational database.
5. (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.
6. Activate the Database Collector applet.
After a successful activation, the APPS field displays DB with a green dot indicating a successful connection.
7. (Optional) To view metrics about the Database Collector, left-click the DB connection in the APPS field for your Broker VM.
Cortex XDR displays Resources, including the amount of CPU, Memory, and Disk space the applet is using.
8. 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.
16.1.2.2.4 | Activate Files and Folders Collector
Abstract
Learn more about activating a Broker VM with a Files and Folders Collector applet.
Ingesting logs and data from external sources requires a Cortex XDR Pro per GB license.
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.
Displayed in the footer
Page 455 of 952
Cortex XDR Documentation
Displayed in the header
Details of the folder path on the network share containing the files that you want to monitor and upload to Cortex XDR.
Settings related to the list of files to monitor and upload to Cortex XDR, where the log format is either Raw (default), JSON, CSV, TSV, PSV, CEF, LEEF,
Corelight, or Cisco.
Cortex XDR only supports ingestion of files encoded in UTF-8 format.
Before activating the Files and Folders Collector applet, review and perform the following:
Set up and configure Broker VM.
Know the complete path to the files and folders that you want Cortex XDR 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. Do one of the following:
On the Brokers tab, find the Broker VM, and in the APPS column, left-click Add → Files and Folder Collector.
On the Clusters tab, find the Broker VM, and in the APPS column, left-click Add → Files and Folder Collector.
3. Configure the Files and Folder Collector settings.
Shared Folder Connection
Field Description
Folder Path Specify the path to the files and folders that you want Cortex XDR 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>
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 Select to validate the connection and permissions.
Connection
File and Folder Settings
Displayed in the footer
Page 456 of 952
Cortex XDR Documentation
Displayed in the header
Field Description
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.
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 This option is only displayed in Batch Mode. Select what to do with the files after they are uploaded to the Cortex XDR server. You
Uploaded 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 XDR. 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 33.
log*.jsonlog*.json includes any JSON file starting with 'log'.
Exclude Specify the files and folders that must match to not be monitored by Cortex XDR . Multiple values are allowed with commas
(Optional) 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 34.
*.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.
When uploading JSON files, Cortex XDR only parses the first level of nesting and only supports single line JSON format, such that
every new line means a separate entry.
# of Lines to Specify the number of lines to skip at the beginning of the file. This is set to 0 by default.
Skip
(Optional) 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. The Lines to Skip are not part of the file format. For example, in CSV files,
there is no need to skip lines.
Data Source Mapping
Displayed in the footer
Page 457 of 952
Cortex XDR Documentation
Displayed in the header
Field Description
Storage 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
Method 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.
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 This option is only displayed in Batch Mode when the storing method is Replace. Select the name of an existing Lookup dataset or
Dataset 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.
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 Specify the Vendor and Product for the type of data being collected. The vendor and product are used to define the name of your
and Cortex Query Language (XQL) dataset (<Vendor>_<Product>_raw).
Product
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.
4. (Optional) Click Add Connection to define another Files and Folders connection for collecting logs from files and folders in a shared resource.
5. (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.
6. Activate the Files and Folders Collector applet.
After a successful activation, the APPS field displays File with a green dot indicating a successful connection.
7. (Optional) To view metrics about the Files and Folders, left-click the File connection in the APPS field for your Broker VM.
Cortex XDR displays Resources, including the amount of CPU, Memory, and Disk space the applet is using.
8. 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:
Displayed in the footer
Page 458 of 952
Cortex XDR Documentation
Displayed in the header
Configure to redefine the Files and Folders Collector configurations.
Deactivate to disable the Files and Folders Collector.
16.1.2.2.5 | Activate FTP Collector
Abstract
Learn more about activating a Broker VM with a FTP Collector applet.
Ingesting logs and data from external sources requires a Cortex XDR Pro per GB license.
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 XDR .
Settings related to the list of files to monitor and upload to Cortex XDR , where the log format is either Raw (default), JSON, CSV, TSV, PSV, CEF, LEEF,
Corelight, or Cisco. Once the files are uploaded to Cortex XDR , you can define whether in the source directory the files are renamed or deleted.
Before activating the FTP Collector applet, review and perform the following:
Set up and configure 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. Do one of the following:
On the Brokers tab, find the Broker VM, and in the APPS column, left-click Add → FTP Collector.
On the Clusters tab, find the Broker VM, and in the APPS column, left-click Add → FTP Collector.
3. Configure the FTP Collector settings.
FTP Connection
Field Description
Type Select the type of FTP connection as FTP, SFTP, or FTPS.
Host Enter the hostname, IP address, or FQDN of the FTP server. When configuring a FTPS Collector, you must specify the FQDN.
Port Enter the FTP port number.
Username Enter the username to login to the FTP server.
Password Enter the password to login to the FTP server.
Displayed in the footer
Page 459 of 952
Cortex XDR Documentation
Displayed in the header
Field Description
SSH Key-Based This checkbox is only displayed when setting a SFTP Collector, which works with both Username and Password authentication
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.
When configuring an SFTP connection, Cortex XDR expects the private key to be in the RSA format that is included in the ----
-BEGIN RSA PRIVATE KEY----- tag. Cortex XDR 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
Field Description
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 Select what to do with the files after they are uploaded to the Cortex XDR server. You can either select Rename files with a suffix
Uploaded (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 XDR . 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 35.
log*.json includes any JSON file starting with 'log'.
Exclude Specify the files and folders that must match to not be monitored by Cortex XDR . Multiple values are allowed with commas
(Optional) 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 36.
*.backup excludes any file ending with '.backup'.
Displayed in the footer
Page 460 of 952
Cortex XDR Documentation
Displayed in the header
Field Description
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 XDR 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.
When uploading JSON files, Cortex XDR only parses the first level of nesting and only supports single line JSON format, such that
every new line means a separate entry.
# of Lines to Enter the number of lines to skip at the beginning of the file. This is set to 0 by default.
Skip
Use this option only in cases where your files contain some sort of "header" lines, such as a general description, an introduction, a
(Optional)
disclaimer, or similar, and you want to skip ingesting them. The Lines to Skip are not part of the file format. For example, in CSV files,
there is no need to skip lines.
Data Source Mapping
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).
The Vendor and Product defaults to Auto-Detect when the Log Format is set to CEF or LEEF.
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.
4. (Optional) Click Add Connection to define another FTP connection for collecting logs from files and folders via FTP, FTPS, or SFTP.
5. (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.
6. Activate the FTP Collector applet.
After a successful activation, the APPS field displays FTP with a green dot indicating a successful connection.
7. (Optional) To view metrics about the FTP Collector, left-click the FTP connection in the APPS field for your Broker VM.
Cortex XDR displays Resources, including the amount of CPU, Memory, and Disk space the applet is using.
8. 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.
16.1.2.2.6 | Activate Local Agent Settings
Abstract
Learn more about activating a 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 XDR 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 XDR management server and XDR agents/XDR Collectors via a centralized and controlled access point. This enables your
Displayed in the footer
Page 461 of 952
Cortex XDR Documentation
Displayed in the header
agents and XDR Collectors to receive security policy updates, upgrades, and send logs and files to Cortex XDR 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
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 XDR Broker VM. The
Broker VM retrieves from Cortex XDR 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 XDR
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.
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.
Broker VMs can act as as a proxy for routing XDR Collector traffic to the Cortex XDR 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. For more information, see Set up
and configure Broker VM.
Download source: Requires adding the Broker VM as a download source in your 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 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. For
more information, see Set up and configure Broker VM.
Download source: Requires adding the cluster as a download source in your 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 Enable access to required PANW resources.
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.
2. In either the Brokers tab or the Clusters tab, locate your Broker VM.
Displayed in the footer
Page 462 of 952
Cortex XDR Documentation
Displayed in the header
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 Set up and configure Broker VM.
b. 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.
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 Set up and configure 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.
A FQDN must be configured for 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.
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. 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 XDR 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.
16.1.2.2.7 | Activate NetFlow Collector
Abstract
Learn more about activating a Broker VM with a NetflFlow Collector applet.
Ingesting records from external sources requires a Cortex XDR Pro per GB license.
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
Displayed in the footer
Page 463 of 952
Cortex XDR Documentation
Displayed in the header
The following setups are required to meet your performance needs:
4 CPUs for up to 50K flows per second (FPS).
8 CPUs for up to 100K FPS.
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.
Set up and configure Broker VM
How to activate the NetFlow Collector
1. Select Settings → Configurations → Data Broker → Broker VMs.
2. Do one of the following:
On the Brokers tab, find the Broker VM, and in the APPS column, left-click Add → NetFlow Collector.
On the Clusters tab, find the Broker VM, and in the APPS column, left-click Add → NetFlow Collector.
3. Click +Add New.
4. Configure your NetFlow Collector.
General Settings
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 XDR discards logs for non-configured flow records without an “Any” rule.
Since Cortex XDR 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
Field Description
Source Specify the IP address or a Classless Inter-Domain Routing (CIDR) of the source network device that sends the flow records to Cortex
Network XDR . 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 XDR 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 Specify a particular vendor and product to be associated with each dataset entry or leave the default IP Flow setting.
and
The Vendor and Product values are used to define the name of your Cortex Query Language (XQL) dataset
Product
<Vendor>_<Product>_raw. If you do not define a vendor or product, Cortex XDR 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.
5. (Optional) Make additional changes to the NetFlow Collector data sources.
Displayed in the footer
Page 464 of 952
Cortex XDR Documentation
Displayed in the header
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.
The options available change, according to the set Source Network value.
Option Description
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 To search for information using the Quick Launcher shortcut . This option is only available when the Source Network
Launcher 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.
6. Activate the NetFlow collector applet.
After successful activation, the APPS field displays NetFlow with a green dot indicating a successful connection.
7. (Optional) To view NetFlow Collector metrics, left-click the NetFlow connection in the APPS field for your Broker VM.
Cortex XDR displays the following information:
Option Description
Connectivity Status Whether the applet is connected to Cortex XDR.
Logs Received and Number of logs that the applet received and sent per second over the last 24 hours. If there are more logs received than
Logs Sent sent, this can indicate a connectivity issue.
Resources Displays the amount of CPU, Memory, and Disk space the applet uses.
8. 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.
16.1.2.2.8 | Activate Network Mapper
Abstract
Learn more about activating the Network Mapper to scan your network.
Activating the Network Mapper requires a Cortex XDR Pro per Endpoint or Cortex XDR Pro per GB license.
Displayed in the footer
Page 465 of 952
Cortex XDR Documentation
Displayed in the header
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. For more information, see Asset Inventory.
1. Select Settings → Configurations → Data Broker → Broker VMs.
2. Do one of the following:
On the Brokers tab, find the Broker VM, and in the APPS column, left-click Add → Network Mapper.
On the Clusters tab, find the Broker VM, and in the APPS column, left-click Add → Network Mapper.
3. In the Activate Network Mapper window, define the following parameters:
Field Description
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 Define the maximum number of scan requests you want to send on your network per second. By default, the number of
Second scan requests are defined as 1000.
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.
IP address ranges are displayed according to what you defined as your Network Parameters.
4. Activate the applet.
After a successful activation, the APPS field displays Network Mapper with a green dot indicating a successful connection.
5. In the APPS field, left-click the Network Mapper connection to view the following scan and applet metrics:
Scan Details
Field Description
Connectivity Status Whether the applet is connected to Cortex XDR .
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
Displayed in the footer
Page 466 of 952
Cortex XDR Documentation
Displayed in the header
Resources: Displays the amount of CPU, Memory, and Disk space the applet is using.
6. Manage the Network Mapper.
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.
16.1.2.2.9 | Activate Pathfinder
Abstract
Learn how to activate Pathfinder, an applet that deploys a non-persistent data collector on endpoints that are not managed by a Cortex XDR agent.
Pathfinder requires a Cortex XDR Pro per Endpoint or Cortex XDR Pro per GB license.
The Pathfinder applet isn't supported when configuring Broker VMs in high availability (HA) clusters.
Pathfinder is a highly recommended, but optional component integrated with the Broker VM that deploys a non-persistent data collector on network hosts,
servers, and workstations that are not managed by a Cortex XDR agent. The collector is automatically triggered by analytics-type alerts with a severity of high
and medium and provides insights into assets that you couldn't scan previously. For more information about analytics alerts, see Cortex XDR Analytics Alert
Reference.
When an alert is triggered, the data collector can run for up to two weeks gathering EDR data from unmanaged hosts. You can track and manage the collector
directly from Cortex XDR, and investigate the EDR data by running a query from the Query Center.
Before activating Pathfinder, review and perform the following:
Configure and register a Broker VM.
Except for Vanilla Windows 7, Cortex XDR supports activating Pathfinder on Windows operating systems with PowerShell version 3 and later. Verify these
requirements wherever you want to activate Pathfinder.
The Pathfinder configuration must contain at least one IP address range to run. Make sure that your internal IP address ranges are defined on your
network. To avoid a collision, IP address ranges can only be associated with one Pathfinder applet. For more information, see Configure Cortex XDR
network parameters.
When using Kerberos as the authentication method for the Pathfinder credentials, confirm that you have a reverse DNS zone and reverse DNS records
on your DNS server. The Broker VM has access to domain controllers over port 88 and is able to acquire the authentication ticket. It is recommended to
use Kerberos for better security.
Verify connectivity between all your networks.
The Broker VM requires a Service Account (SA) that has administrator privileges on all Windows workstations and servers in your environment. Cortex
XDR recommends that you limit the number of users granted access to the SA account as it poses a credential compromise security threat.
How to activate Pathfinder
1. Select Settings → Configurations → Data Broker → Broker VMs.
2. Do one of the following:
On the Brokers tab, find the Broker VM, and in the APPS column, left-click Add → Pathfinder.
On the Clusters tab, find the Broker VM, and in the APPS column, left-click Add → Pathfinder.
Pathfinder isn't supported when configuring Broker VMs in high availability (HA) clusters.
3. Do one of the following to define the Pathfinder credentials:
Define the domain access credentials. Make sure to enter the user name and password using the Service Account with Local Admin privileges on
the remote endpoint.
(Broker VM version 9.0 and later) Define Pathfinder to access target hosts using credentials stored in your CyberArk vault. Credentials are not
stored on the Broker VM; Pathfinder queries CyberArk each time according to the defined parameters.
4. Click Test to run a test on the credentials and Pathfinder permissions. Testing may take a few minutes to complete but ensures that Pathfinder can
deploy a data collector.
5. Click Next, and define the data collector settings.
Displayed in the footer
Page 467 of 952
Cortex XDR Documentation
Displayed in the header
By default the proxy settings are disabled, and data collected is sent directly to the cloud. For Agent Proxy Settings, collected data is routed using the
settings provided in the Local Agent Settings applet, which must be enabled for these settings to work.
6. Click Next, and select the IP address ranges to scan from your defined network configurations.
By default, every IP address range will use the Pathfinder credentials and settings you defined in the Credentials section and is labeled as an Applet
Configuration.
If you want to configure other credentials for a specific range, override the settings in the right pane. IP address ranges you edit are labeled as Custom
Configuration. Make sure to test the credentials for this specific range.
7. Activate Pathfinder. After the activation is complete, Pathfinder is displayed in the APPS column with a green dot indicating a successful connection.
Hovering over the Pathfinder connection shows details such as the connectivity status, handled and failed tasks, and the resources the applet is using.
16.1.2.2.10 | Activate Syslog Collector
Abstract
Learn how to set up and activate the Syslog Collector applet on a Broker VM within your network.
Ingesting logs and data from external sources requires a Cortex XDR Pro per GB license.
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.
Set up and configure 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. Do one of the following:
On the Brokers tab, find the Broker VM, and in the APPS column, left-click Add → Syslog Collector.
On the Clusters tab, find the Broker VM, and in the APPS column, left-click Add → Syslog Collector.
Task 2. Configure the Syslog Collector
Cortex XDR 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.
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:
Displayed in the footer
Page 468 of 952
Cortex XDR Documentation
Displayed in the header
Field Description
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.
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 XDR 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 XDR 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 XDR 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 Specify a particular vendor and product for the Syslog format defined or leave the default Auto-Detect setting.
and
Product
Source Specify the IP address or Classless Inter-Domain Routing (CIDR). If you leave this blank, Cortex XDR will allow receipt of logs from any
Network 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.
When configuring the Protocol as Secure TCP, these additional General Settings are available:
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.
The server certificate and private key pair is expected in a PEM format.
Cortex XDR will notify you when your certificates are about to expire.
Port
Choose a port on which the Syslog Collector will listen for logs.
Because some port numbers are reserved by Cortex XDR , 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:
Displayed in the footer
Page 469 of 952
Cortex XDR Documentation
Displayed in the header
Field Description
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 Enter a particular vendor and product for the Syslog format defined or leave the default Auto-Detect setting.
and
Product
Source Specify the IP address or Classless Inter-Domain Routing (CIDR). If you leave this blank, Cortex XDR will allow receipt of logs from any
Network 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 XDR displays the following information:
Metric Description
Connectivity Status Whether the applet is connected to Cortex XDR.
Logs Received and Number of logs received and sent by the applet per second over the last 24 hours. If the number of incoming logs received is
Logs Sent 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
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.
16.1.2.2.11 | Activate Windows Event Collector
Abstract
Set up your Windows Event Collector to connect with the Cortex XDR Broker VM and collect events.
Ingesting logs and data from external sources requires a Cortex XDR Pro per GB license.
After you have configured and registered your Broker VM, activate your Windows Event Collector application.
Displayed in the footer
Page 470 of 952
Cortex XDR Documentation
Displayed in the header
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.
You can also activate the Windows Event Collector on Windows Core. For more information, see Activate Windows Event Collector on Windows Core.
Ensure you meet the following prerequisites before activating the Windows Event Collector applet:
Set up and configure Broker VM
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 Configure High
Availability Cluster.
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 High Availability Cluster.
Windows Server 2012 r2 or later.
After ingestion, Cortex XDR 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.
Perform the following procedures in the order listed below.
Task 1. Add, configure, and activate a Windows Event Collector
1. Select Settings → Configurations → Data Broker → Broker VMs.
2. Do one of the following:
On the Brokers tab, find the Broker VM, and in the APPS column, left-click Add → Windows Event Collector.
On the Clusters tab, find the Broker VM, and in the APPS column, left-click Add → Windows Event Collector.
3. In the Activate Windows Event Collector window, define the Collected Events to configure the events collected by the applet. This lists event sources
from which you want to collect events.
Field Description
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 Minimum severity level of events that are collected.
Level
Event IDs Whether to Include, Exclude, or collect All event ID groups.
Group
Displayed in the footer
Page 471 of 952
Cortex XDR Documentation
Displayed in the header
Field Description
Minimal TLS Select either 1.0 or 1.2 (default) as the minimum TLS version allowed. Ensure that you verify that all Windows event forwarders are
Version supporting the minimal defined TLS version.
Example 37.
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
By default, Cortex XDR collects Palo Alto Networks predefined Security events that are used by the Cortex XDR detectors. Removing the Security
collector interferes with the Cortex XDR detection functionality. Restore to Default to reinstate the Security event collection.
4. Click Activate. After a successful activation, the APPS field displays WEC with a green dot indicating a successful connection.
Task 2. Configure the Windows Event Collector settings
1. In the APPS column, left-click the WEC connection to display the Windows Event Collector settings, and select Configure.
2. In the Windows Event Forwarder Configuration window, perform the following tasks:
a. In the Subscription Manager URL field, click (copy) . This will be used when you configure the subscription manager in the GPO (Global Policy
Object) on your domain controller.
b. Enter a password in the Define Client Certificate Export Password field to be used to secure the downloaded WEF certificate that establishes 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 XDR 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.
Task 3. Install your WEF Certificate on the WEF to establish connection
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 XDR console and double-click to open the Certificate Import Wizard.
2. In the Certificate Import Wizard:
a. Select Local Machine, and then click Next.
b. Verify the File name field displays the PFX certificate file you downloaded and click Next.
c. In the Passwords field, specify the Client Certificate Export Password you defined in the Cortex XDR console followed by Next.
d. Select Automatically select the certificate store based on the type of certificate, and then click 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 is displayed.
In the Trusted Root Certification Authorities → Certificates folder, ensure the CA ca.wec.paloaltonetworks.com is displayed.
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, and then click Check Names to verify the
object name. The object name is displayed with an underline when valid. and then click OK.
Displayed in the footer
Page 472 of 952
Cortex XDR Documentation
Displayed in the header
8. Click OK, verify the Group or user names that are displayed, and then click Apply Permissions for private keys.
Task 4. Add the Network Service account to the domain controller Event Log Readers group.
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. 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.
2. Grant access to view the security event logs.
a. Run wevtutil gl security and take note of your channelAccess value.
Example 38.
`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)
logging:
logFileName: %SystemRoot%\System32\Winevt\Logs\security.evtx
retention: false
autoBackup: false
maxSize: 134217728
Displayed in the footer
Page 473 of 952
Cortex XDR Documentation
Displayed in the header
publishing:
fileMax: 1
Take note of value: channelAccess: O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)
b. Run wevtutil sl security "/ca:<channelAccess value>(A;;0x1;;;S-1-5-20)"
Example 39.
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.
Task 5. Create a WEF Group Policy that applies to every Windows server you want to configure as a WEF
1. In a command prompt, open gpmc.msc.
2. In the Group Policy Management window, navigate to Domains → your domain name → Group Policy Object, right-click and select New.
3. In the New GPO window, enter your group policy Name: as Windows Event Forwarding, and click OK.
4. Navigate to Domains → your domain name → Group Policy Objects → Windows Event Forwarding, right-click and select Edit.
5. In the Group Policy Management Editor:
Displayed in the footer
Page 474 of 952
Cortex XDR Documentation
Displayed in the header
Set the Windows Remote Management Service for automatic startup.
1. Select Computer Configuration → Policies → Windows Settings → Security Settings → System Services, and in the view panel locate and
double-click Windows Remote Management (WS-Management).
2. Mark the Define this policy setting checkbox, select Automatic, and then click 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 XDR to apply grouping and analytics inspection.
This step overrides any local policy settings.
Example 40.
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.
1. Select Computer Configuration → Policies → Windows Settings → Security Settings → Advanced Audit Policy Configuration → Audit Policies
→ Account Logon.
2. 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:, and click Success and Failure followed by Apply and OK.
Repeat for Audit Kerberos Service Ticket Operations.
6. 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, perform the following:
a. Mark Configure target Subscription Manager as Enabled.
b. In the Options section, select Show and in the Show Contents window, paste the Subscription Manage URL you copied from the Cortex XDR
console, and then click OK.
c. Click Apply and OK to save your changes.
7. 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.
Displayed in the footer
Page 475 of 952
Cortex XDR Documentation
Displayed in the header
In the New Local Group Properties window:
a. In the Group name field, select Event Log Readers (built-in).
b. In the Members section, click Add and enter in the Name filed Network Service followed by OK.
You must type out the name, do not select the name from the browse button.
c. Click Apply and OK to save your changes, and close the Group Policy Management Editor window.
8. Configure the Windows Firewall.
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:
a. Rule Type: Select Port followed by Next.
b. Protocols and Ports: Select TCP and in the Specific Remote Ports field enter 5986 followed by Next.
c. Action: Select Allow the connection followed by Next.
d. Profile: Select Domain and disable Private and Public followed by Next.
e. Name: Specify Windows Event Forwarding.
f. To save your changes, click Finish.
Task 6. 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.
1. Select Group Policy Management → <your domain name> → Domain Controllers, right-click and select Link an existing GPO....
2. In the Select GPO window, click Windows Event Forwarding followed by OK.
3. In an administrative PowerShell console, execute the following commands:
a. PS C:\Users\Administrator> gpupdate /force
Verify that the Computer Policy update has completed successfully. User Policy update has completed successfully.
confirmation message is displayed.
b. PS C:\Users\Administrator> Restart-Service WinRM
Task 7. Verify Windows Event Forwarding
1. In an administrative PowerShell console, run the following command:
PS C:\Users\Administrator> Get-WinEvent Microsoft-windows-WinRM/operational -MaxEvents 10
Displayed in the footer
Page 476 of 952
Cortex XDR Documentation
Displayed in the header
2. Look for WSMan operation EventDelivery completed successfully confirmation messages. These indicate events forwarded successfully.
Task 8. Manage the Window Event Collector (Optional)
After the Windows Event Collector has been activated in the Cortex XDR 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.
Task 9. View Windows Event Collector metrics (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 XDR.
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.
16.1.2.2.11.1 | Activate 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 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.
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 Windows Event Collector applet on Windows Core:
Set up and configure Broker VM
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 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 High Availability Cluster.
Windows Server 2012 r2 or later.
After ingestion, Cortex XDR 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.
Perform the following procedures in the order listed below.
Task 1. Add, configure, and activate a Windows Event Collector
1. Select Settings → Configurations → Data Broker → Broker VMs.
2. Do one of the following:
Displayed in the footer
Page 477 of 952
Cortex XDR Documentation
Displayed in the header
On the Brokers tab, find the Broker VM, and in the APPS column, left-click Add → Windows Event Collector.
On the Clusters tab, find the Broker VM, and in the APPS column, left-click Add → Windows Event Collector.
3. In the Activate Windows Event Collector window, define the Collected Events to configure the events collected by the applet. This lists event sources
from which you want to collect events.
Field Description
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 Minimum severity level of events that are collected.
Level
Event IDs Whether to Include, Exclude, or collect All event ID groups.
Group
Minimal TLS Select either 1.0 or 1.2 (default) as the minimum TLS version allowed. Ensure that you verify that all Windows event forwarders are
Version supporting the minimal defined TLS version.
Example 41.
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
By default, Cortex XDR collects Palo Alto Networks predefined Security events that are used by the Cortex XDR detectors. Removing the Security
collector interferes with the Cortex XDR detection functionality. Restore to Default to reinstate the Security event collection.
4. Click Activate. After a successful activation, the APPS field displays WEC with a green dot indicating a successful connection.
Task 2. Configure the Windows Event Collector settings
1. In the APPS column, left-click the WEC connection to display the Windows Event Collector settings, and select Configure.
2. In the Windows Event Forwarder Configuration window, perform the following tasks.:
a. In the Subscription Manager URL field, click (copy) . This will be used when you configure the subscription manager in the GPO (Global Policy
Object) on your domain controller.
b. Enter a password in the Define Client Certificate Export Password field to be used to secure the downloaded WEF certificate that establishes 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 XDR 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.
Task 3. Install your WEF Certificate on the WEF to establish connection
1. Start PowerShell with elevated privileges.
a. Run PowerShell with the following command:
PowerShell
Displayed in the footer
Page 478 of 952
Cortex XDR Documentation
Displayed in the header
b. From inside a PowerShell command run the following command:
Start-Process -Verb RunAs PowerShell
2. Copy the PFX file that you downloaded to the local Core machine in one of the following ways:
(Recommended) 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
Example 42.
$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>
Example 43.
Copy-Item –Path C:\Downloads\forwarder.wec.paloaltonetworks.com.pfx –Destination '\\windows-core-server\c$\forwarder.wec.paloaltonetworks.com.pfx
3. Import the PFX file from PowerShell.
Use the following command to import the PFX file:
certutil -f -importpfx '<path to PFX file from Destination>'
Example 44.
certutil -f -importpfx '.\forwarder.wec.paloaltonetworks.com.pfx'
You will need to enter the Client Certificate Export Password you defined in the Cortex XDR console.
When the import is complete, the following message is displayed:
CertUtil: -importPFX command completed successfully.
4. Verify that the certificates are in the correct locations.
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
5. Manage the private key of the forwarder.wec.paloaltonetworks.com.pfx certificate.
This entails applying permissions for the NETWORK SERVICE user.
a. 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.
b. 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>.
Displayed in the footer
Page 479 of 952
Cortex XDR Documentation
Displayed in the header
$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
c. After the script runs, validate the permissions are now set correctly.
Task 4. Add the Network Service account to the domain controller Event Log Readers group.
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. 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.
2. Grant access to view the security event logs.
a. Run wevtutil gl security and take note of your channelAccess value.
Example 45.
`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)
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)
b. Run wevtutil sl security "/ca:<channelAccess value>(A;;0x1;;;S-1-5-20)"
Example 46.
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.
Displayed in the footer
Page 480 of 952
Cortex XDR Documentation
Displayed in the header
Task 5. 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.
1. 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.
2. Run cmd as an administrator.
3. Run the following command:
gpmc.msc /gpcomputer: <computer name.Domain>
Example 47.
gpmc.msc /gpcomputer: WIN-SI2SVDOKIMV.ENV21.LOCAL
4. In the Group Policy Management window, navigate to Domains → your domain name → Group Policy Object, right-click and select New.
5. In the New GPO window, enter your group policy Name: as Windows Event Forwarding, and click OK.
6. Navigate to Domains → your domain name → Group Policy Objects → Windows Event Forwarding, right-click and select Edit.
7. In the Group Policy Management Editor:
Displayed in the footer
Page 481 of 952
Cortex XDR Documentation
Displayed in the header
Set the Windows Remote Management Service for automatic startup.
1. Select Computer Configuration → Policies → Windows Settings → Security Settings → System Services, and in the view panel locate and
double-click Windows Remote Management (WS-Management).
2. Mark the Define this policy setting checkbox, select Automatic, and then click 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 XDR to apply grouping and analytics inspection.
This step overrides any local policy settings.
Example 48.
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.
1. Select Computer Configuration → Policies → Windows Settings → Security Settings → Advanced Audit Policy Configuration → Audit Policies
→ Account Logon.
2. 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:, and click Success and Failure followed by Apply and OK.
Repeat for Audit Kerberos Service Ticket Operations.
8. 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:
a. Mark Configure target Subscription Manager as Enabled.
b. In the Options section, select Show and in the Show Contents window, paste the Subscription Manage URL you copied from the Cortex XDR
console, and then click OK.
c. Click Apply and OK to save your changes.
9. 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.
Displayed in the footer
Page 482 of 952
Cortex XDR Documentation
Displayed in the header
In the New Local Group Properties window:
a. In the Group name field, select Event Log Readers (built-in).
b. In the Members section, click Add and enter in the Name filed Network Service followed by OK.
You must type out the name, do not select the name from the browse button.
c. Click Apply and OK to save your changes, and close the Group Policy Management Editor window.
10. Configure the Windows Firewall.
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:
a. Rule Type: Select Port followed by Next.
b. Protocols and Ports: Select TCP and in the Specific Remote Ports field enter 5986 followed by Next.
c. Action: Select Allow the connection followed by Next.
d. Profile: Select Domain and disable Private and Public followed by Next.
e. Name: Specify Windows Event Forwarding.
f. To save your changes, click Finish.
Task 6. 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.
1. Select Group Policy Management → <your domain name> → Domain Controllers, right-click and select Link an existing GPO....
2. In the Select GPO window, click Windows Event Forwarding followed by OK.
3. In an administrative PowerShell console, execute the following commands:
a. PS C:\Users\Administrator> gpupdate /force
Verify that the Computer Policy update has completed successfully. User Policy update has completed successfully.
confirmation message is displayed.
b. PS C:\Users\Administrator> Restart-Service WinRM
Task 7. Verify Windows Event Forwarding
1. In an administrative PowerShell console, run the following command:
PS C:\Users\Administrator> Get-WinEvent Microsoft-windows-WinRM/operational -MaxEvents 10
Displayed in the footer
Page 483 of 952
Cortex XDR Documentation
Displayed in the header
2. Look for WSMan operation EventDelivery completed successfully confirmation messages. These indicate events forwarded successfully.
Task 8. Manage the Window Event Collector (Optional)
After the Windows Event Collector has been activated in the Cortex XDR 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.
Task 9. View Windows Event Collector metrics (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 XDR.
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.
16.1.2.2.11.2 | Renew WEC certificates
Abstract
Learn more about renewing your WEC certificates in Cortex XDR.
Renewing your WEC certificates in Cortex XDR 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.
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 XDR 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.
Perform the following procedures in the order listed below.
Task 1. Renew your WEF client certificate in Cortex XDR
1. Select Settings → Configurations → Data Broker → Broker VMs.
2. Do one of the following:
On the Brokers tab, find the Broker VM, and in the APPS column, left-click the WEC connection to display the Windows Event Collector settings,
and select Configure.
On the Clusters tab, find the Broker VM, and in the APPS column, left-click the WEC connection to display the Windows Event Collector settings,
and select Configure.
3. In the Windows Event Forwarder Configuration window, perform the following tasks:
a. In the Subscription Manager URL field, click (copy) . This will be used when you configure the subscription manager in the GPO (Global Policy
Object) on your domain controller.
b. Enter a password in the Define Client Certificate Export Password field to be used to secure the downloaded WEF certificate that establishes 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.
4. Install your WEF Certificate on the WEF to establish connection.
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 XDR console and double-click to open the Certificate Import Wizard.
Displayed in the footer
Page 484 of 952
Cortex XDR Documentation
Displayed in the header
b. In the Certificate Import Wizard:
1. Select Local Machine, and then click Next.
2. Verify the File name field displays the PFX certificate file you downloaded and click Next.
3. In the Passwords field, enter the Client Certificate Export Password you defined in the Cortex XDR console followed by Next.
4. Select Automatically select the certificate store based on the type of certificate, and then click 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 is displayed.
In the Trusted Root Certification Authorities → Certificates folder, ensure the CA ca.wec.paloaltonetworks.com is displayed.
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.
e. Navigate to Certificates Personal Certificates.
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, enter NETWORK SERVICE, and then click Check Names to verify
the object name. The object name is displayed with an underline when valid. and then click OK.
h. Click OK, verify the Group or user names that are displayed, and then click Apply Permissions for private keys.
Displayed in the footer
Page 485 of 952
Cortex XDR Documentation
Displayed in the header
5. Configure the subscription manager.
a. Navigate to Computer Configuration → Policies → Administrative Templates: Policy definitions → Windows Components → Event Forwarding,
right-click Configure target Subscription Manager and select Edit.
b. In the Configure target Subscription Manager window, perform the following:
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 XDR
console, and then click OK.
3. Click Apply and OK to save your changes.
6. Complete the WEF Client certificate renewal.
On every WEF DC, perform the following from a command prompt:
a. Run gpupdate /force to update the group policy.
b. To apply the configurations, Restart-Service WinRM.
Task 2. Renew your WEC server certificate in Cortex XDR
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 XDR console.
1. Select Settings → Configurations → Data Broker → Broker VMs.
2. Do one of the following:
Displayed in the footer
Page 486 of 952
Cortex XDR Documentation
Displayed in the header
On the Brokers tab, find the Broker VM, and in the APPS column, left-click the WEC connection to display the Windows Event Collector settings,
and select Renew WEC Server Certificate.
On the Clusters tab, find the Broker VM, and in the APPS column, left-click the WEC connection to display the Windows Event Collector settings,
and select Renew WEC Server Certificate.
3. Click Renew.
Once Cortex XDR 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 you run the following XQL query to verify that your event logs are being captured:
dataset = xdr_data
| filter _product = "Windows"
| fields _vendor,_product,action_evtlog_level,action_evtlog_event_id
| sort desc _time
| limit 20
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.
16.1.3 | Manage Broker VM
Abstract
Learn more about managing your Broker VMs from the management console.
After you configure the Broker VMs, you can manage these brokers from the Cortex XDR 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.
Maintenance Releases
Cortex XDR 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
16.1.3.1 | View Broker VM details
Abstract
Learn more about viewing the details of any particular Broker VM.
In Cortex XDR , 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...
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.
Displayed in the footer
Page 487 of 952
Cortex XDR Documentation
Displayed in the header
Field Description
Status Indicator ( Identifies in the following columns:
Device Name
Whether the Broker machine is registered and connected to Cortex XDR.
)*
Version
Whether the Broker VM is running the latest version.
APPS
Whether the available applications are connected to Cortex XDR.
Colors depict the following statuses:
Black
Disconnected to Cortex XDR
Red
Disconnected from Cortex XDR
Orange
Past Version
Green
Connected, Current Version
Checkbox 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.
Displayed in the footer
Page 488 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR console have
been applied.
in progress
Broker VM configuration changes made through the Cortex XDR console are
being applied.
submitted
Broker VM configuration changes made through the Cortex XDR console have
reached the Broker VM and awaiting implementation.
failed
Broker VM configuration changes made through the Cortex XDR console have
failed. Need to open a Palo Alto Networks support ticket.
DEVICE ID Device ID allocated to the Broker VM by Cortex XDR 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 from the total allocated for data caching in the Broker VM as a
percentage. Inside the brackets is displayed how much this is in GB from the total
disk size in GB.
A notification is added to the Notification Center whenever the disk space is low
disk and whenever the disk size is increased.
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 XDR appear in the
Notification Center.
UPGRADE TIME Timestamp of when the Broker VM was upgraded.
Displayed in the footer
Page 489 of 952
Cortex XDR Documentation
Displayed in the header
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.
16.1.3.2 | Edit 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.
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.
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 XDR 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 Broker VM using Prometheus.
(Optional) SSH Access
Displayed in the footer
Page 490 of 952
Cortex XDR Documentation
Displayed in the header
Broker VM 7.4.5 and earlier
Enable/Disable ssh Palo Alto Networks support team SSH access by using a Cortex XDR 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.
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 XDR automatically updates them in the Broker VM UI, even when the Broker VM UI is disabled.
Cortex XDR validates that the certificate and key match, but does not validate the Certificate Authority (CA).
When you are done, Save your changes.
16.1.3.3 | Increase Broker VM storage allocated for data caching
Abstract
Learn more about increasing the storage allocated for data caching in the Broker VM.
The storage allocated for data caching in the Broker VM is fixed at around 346.4 GB using a Logical Volume Manager (LVM). You can increase the disk space
allocated to attain better resilience during network and connectivity issues by adding a new disk. The disk needs to be added manually to an applicable
hypervisor that your broker supports, so that the Broker VM automatically detects the physical disk and allows you to connect to it. Extending the existing disk
is not supported.
When allocating storage for data caching, ensure you are aware of the following:
You must allocate the entire disk as opposed to portions of the disk.
You can connect multiple disks to increase the data caching space according to your requirements.
Once a disk is connected, It's not possible to dismiss a disk that has already been allocated, or to reduce the disk space of the data caching.
Adding a disk requires formatting and deleting all its contents.
This operation is irreversible, and will make the disk become an integral part of the broker, where disconnecting the disk will result in errors and data loss.
How to increase the Broker VM disk size
1. Gracefully shutdown the applicable Broker VM in the hypervisor to manually add a disk.
2. Add a disk manually through the hypervisor portal. This step involves accessing the portal and attaching a new disk to the VM.
Follow your hypervisor documentation to understand how to add a persistent disk storage to your VM.
3. Select Settings → Configurations → Data Broker → Broker VMs.
4. In the Broker VMs table, locate your Broker VM, right-click, and select Configure.
5. Scroll down to the Storage section, verify that your disk is detected with a new line that reads New disk detected with the correct disk name and disk
size, and click Add to data caching space.
If your disk is not listed and you didn't shutdown your Broker VM in your hypervisor before manually adding a disk to the VM, you'll need to reboot the
Broker VM before the disk details are detected by the Broker VM. This can be performed either in the hypervisor or directly in the Broker VMs page.
6. In the ARE YOU SURE? dialog box that is displayed, confirm that you want to add the new disk to the broker's data caching space and are aware of all
the ramifications by clicking Yes,add.
7. To apply your changes, click Save.
Once completed, a notification is added to the Notification Center indicated whether the disk size was increased successfully. If not, the notification
includes the errors encountered during the process.
Displayed in the footer
Page 491 of 952
Cortex XDR Documentation
Displayed in the header
In addition, when the disk is added successfully, the total size of the disk space availalble is updated in the DISK USAGE column on the Broker VMs
page.
16.1.3.4 | Monitor 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.
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:
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
Displayed in the footer
Page 492 of 952
Cortex XDR Documentation
Displayed in the header
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
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.
Displayed in the footer
Page 493 of 952
Cortex XDR Documentation
Displayed in the header
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)
16.1.3.5 | Collect Broker VM Logs
Abstract
Learn more about collecting logs from a Broker VM to review them as part of an investigation.
Cortex XDR enables you to collect your Broker VM logs directly from the Cortex XDR 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 either Generate New Logs or Download Logs (<TIMESTAMP>).
The Download Logs (<TIMESTAMP>) 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.
16.1.3.6 | Upgrade Broker VM
Abstract
Learn more about upgrading the Broker VM from the Cortex XDR management console.
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, 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.
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
XDR console Notification Center.
16.1.3.7 | Import Broker VM Configuration
Abstract
Learn more about importing one Broker VM configuration to another.
This option can only be used on Broker VMs with version 20.0 and later, and is only suitable for importing a configuration of brokers in the same version, or from
a broker in an older version to a broker in a newer version.
Importing Broker VM configurations allows you to copy, including applet settings, the configuration of one Broker VM to another. The import overrides the
Broker VM and applet settings in the target Broker VM.
1. To replace the Broker VM configuration, right-click the Broker VM and select Import Configuration.
2. Select the Broker VM that has the configuration that you want to import.
3. (Optional) After the import is complete and the new configurations are applied to the target Broker VM, you can choose to shutdown the original Broker
VM (default configuration). This step ensures that there are no conflicts in data collection and applets operation.
4. Select the confirmation checkbox.
5. Click Import.
After a successful import, the new configurations are immediately applied to the target Broker VM.
Displayed in the footer
Page 494 of 952
Cortex XDR Documentation
Displayed in the header
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.
16.1.3.8 | Open Live Terminal
Abstract
Learn more about remotely connecting to a Cortex XDR Broker VM.
Cortex XDR enables you to connect remotely to a Broker VM directly from Cortex XDR.
1. In Cortex XDR, 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 XDR opens a CLI window where you can perform the following commands:
Logs
Broker VM logs are located in /data/logs/folder and contain the applet name in the file name.
Example 49.
Folder /data/logs/[applet name], containing container_ctrl_[applet name].log
Ubuntu commands
The Broker VM allows commands which do not require Sudo.
Example 50.
route or ifconfig -a
Sudo commands
Broker VM supports the commands listed in the following table. All the commands are located in the /home/admin/sbin folder.
Cortex XDR requires you use the following values when running commands:
The only applet that is available with a Cortex XDR Prevent license is the Local Agent Settings. The rest of the applets are only available with a Cortex
XDR Pro license.
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
Displayed in the footer
Page 495 of 952
Cortex XDR Documentation
Displayed in the header
Upgrade: zenith_upgrade
Frontend service: webui
Sync with Cortex XDR: cloud_sync
Internal messaging service (RabbitMQ): rabbitmq-server
Upload metrics to Cortex XDR: 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
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. You can either restart_routes or reboot
the Broker VM for the changes in the
The /etc/network/routes configuration file /etc/network/routes file to take affect.
is a standard Ubuntu routes configuration file
and 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
Displayed in the footer
Page 496 of 952
Cortex XDR Documentation
Displayed in the header
Command Description Example
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.
16.1.3.9 | 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 either the Brokers tab or Clusters tab.
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. Add a Broker VM in one of the following tabs:
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 propagate 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.
16.1.3.10 | 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.
Displayed in the footer
Page 497 of 952
Cortex XDR Documentation
Displayed in the header
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.
16.1.3.11 | 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.
If you've enabled a Load Balancer Health-Check on the cluster, you need to exclude this Broker VM from your Load Balancer settings.
16.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 XDR 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 XDR 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.
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...
Displayed in the footer
Page 498 of 952
Cortex XDR Documentation
Displayed in the header
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 applets are:
redistributed to the remaining nodes in the HA cluster.
Syslog
For load balancing, you must install a Load Balancer in your network which will distribute the incoming data Collector
between the nodes.
Netflow
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
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 XDR 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 XDR 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:
1. Standby nodes are upgraded one by one.
Displayed in the footer
Page 499 of 952
Cortex XDR Documentation
Displayed in the header
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.
16.1.4.1 | Configure 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.
Guidelines
Note the following guidelines:
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.
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 XDR 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 XDR
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.
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
Displayed in the footer
Page 500 of 952
Cortex XDR Documentation
Displayed in the header
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).
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 applet to cluster.
16.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).
Displayed in the footer
Page 501 of 952
Cortex XDR Documentation
Displayed in the header
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.
16.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.
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 Average CPU utilization between all nodes in the cluster as a percentage.
USAGE
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
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
Displayed in the footer
Page 502 of 952
Cortex XDR Documentation
Displayed in the header
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.
16.1.4.2.2 | Edit 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.
An HA cluster is always configurable no matter what the status of the cluster or whether it has any Broker VM nodes added.
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. For more information on each of these settings, see
Configure High Availability Cluster.
4. Update the cluster with your changes.
16.1.4.2.3 | Add applet to 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.
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 in the Cortex XDR Admin Guide.
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
propagate so that the applet is active on all cluster nodes, including Primary and standby.
16.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 either the Brokers tab or Clusters tab.
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.
Displayed in the footer
Page 503 of 952
Cortex XDR Documentation
Displayed in the header
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. Add a Broker VM in one of the following tabs:
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 propagate 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.
16.1.4.2.5 | Remove 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 XDR 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.
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.
16.1.5 | Broker VM notifications
Abstract
Learn about the notifications that are relevant to Cortex XDR Broker VMs.
To help you monitor your Broker VM version, connectivity, and high availability clusters, Cortex XDR sends notifications to your Cortex XDR console Notification
Center.
Cortex XDR 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.
Displayed in the footer
Page 504 of 952
Cortex XDR Documentation
Displayed in the header
Broker VM Connectivity
Notifies when the Broker VM has lost connectivity to Cortex XDR .
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.
Disk space allocation on <name of broker> broker
Notifies whether the disk space allocated for data caching in the Broker VM has been increased successfully. If not, the notification includes the errors
encountered during the process. For more information on allocating disk space to the Broker VM, see Increase Broker VM storage allocated for data caching.
<Device ID> 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.
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.
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 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 Broker VM Activity in the Cortex XDR Administrator Guide.
16.1.6 | Monitor Broker VM activity
Abstract
Learn more about the monitored Cortex XDR Broker VM activities.
Cortex XDR logs entries for events related to the Broker VM monitored activities. Cortex XDR stores the logs for 365 days. To view the Broker VM audit logs,
select Settings → Management Audit Logs.
Displayed in the footer
Page 505 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR Management Audit Logs table:
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.
Displayed in the footer
Page 506 of 952
Cortex XDR Documentation
Displayed in the header
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
Rolling Upgrades
Subscription Created
Subscription Deleted
Subscription Edited
Broker API:
Authentication failed
User Name* Name of the user who performed the action.
16.2 | XDR Collectors
Abstract
Displayed in the footer
Page 507 of 952
Cortex XDR Documentation
Displayed in the header
Learn how XDR Collectors can be used for on-premise data collection on Windows and Linux machines.
Ingesting logs and data requires a Cortex XDR Pro per GB license.
Ingestion of log events larger than 5 MB is not supported.
Cortex XDR provides an XDR Collectors (XDRC) configuration that is dedicated for on-premise data collection on Windows and Linux machines. The XDRC
includes a dedicated installer, a collector upgrade configuration, content updates, and policy management. The XDRC is a data collector that gathers and
processes logs and events from multiple sources. It leverages Elasticsearch Filebeat, a lightweight log shipper, to collect log data from various systems and
applications. Additionally, Winlogbeat gathers Windows event logs, ensuring comprehensive visibility into Windows environments. These components facilitate
centralized analysis, threat detection, and investigation across the Cortex XDR ecosystem.
16.2.1 | XDR Collector audit logs
Abstract
Learn more about XDR Collector audit logs.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
Cortex XDR logs entries for events related to the XDR Collector monitored activities. Cortex XDR stores the logs for 365 days. To view the XDR Collector audit
logs, select Settings → XDR Collector Audit Logs.
16.2.2 | XDR Collector machine requirements and supported operating systems
Abstract
Learn about the supported operating systems and requirements for the collector machines used for the Cortex XDR Collectors.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
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
Displayed in the footer
Page 508 of 952
Cortex XDR Documentation
Displayed in the header
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
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 and
Oracle Linux 6: policycoreutils-
python
Red Hat Enterprise Linux 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
Networking Allow communication from the XDR
Collector TCP port to the server (the
default is port 443).
Displayed in the footer
Page 509 of 952
Cortex XDR Documentation
Displayed in the header
Machine Operating System Requirement Specifications
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
Displayed in the footer
Page 510 of 952
Cortex XDR Documentation
Displayed in the header
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
Displayed in the footer
Page 511 of 952
Cortex XDR Documentation
Displayed in the header
Machine Operating System Requirement Specifications
Datacenter
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
16.2.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.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
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.
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 and prepare.
Throughout this topic, <xdr-tenant> refers to the chosen subdomain of your Cortex XDR 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.
The following table shows the required resources by region.
Displayed in the footer
Page 512 of 952
Cortex XDR Documentation
Displayed in the header
FQDN IP Addresses And Port App-ID Coverage
<xdr-tenant>.xdr. IP address by region: cortex-xdr
<region>.paloaltonetworks.com
US (United States): 35.244.250.18
Used to connect to the Cortex XDR management
console. EU (Europe): 35.227.237.180
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
ES (Spain): 34.111.188.248
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-
<xdr-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.
Displayed in the footer
Page 513 of 952
Cortex XDR Documentation
Displayed in the header
FQDN IP Addresses And Port App-ID Coverage
ch-<xdr- 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 its
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
ES (Spain): 34.120.102.147
Port: 443
Displayed in the footer
Page 514 of 952
Cortex XDR Documentation
Displayed in the header
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
ES (Spain): 34.175.30.176
Port: 443
Log forwarding to a syslog receiver
See Integrate a syslog receiver for information about
log forwarding IP addresses per region for syslog
receivers.
The following table lists the 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-
fed.traps.paloaltonetworks.com 104.198.132.24 service
Used for the first request in registration flow where the Port: 443
agent passes the distribution ID and obtains the ch-
<xdr-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.
Displayed in the footer
Page 515 of 952
Cortex XDR Documentation
Displayed in the header
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-<xdr- IP address: traps-management-
tenant>.traps.paloaltonetworks.com 130.211.195.231 service
Used for all other requests between the agent and its Port: 443
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 for information about
log forwarding IP addresses per region for syslog
receivers.
16.2.4 | Manage XDR Collectors
Abstract
Manage Cortex XDR collectors.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
On the XDR Collectors Administration page, you can view the list of collectors and perform additional tasks such as changing the alias of the collector,
upgrading the collector version, and setting a proxy address and port for the collector.
16.2.4.1 | Configure the XDR Collector upgrade scheduler
Abstract
You can configure the Cortex XDR Collector upgrade scheduler and the number of parallel upgrades.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
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 XDR, 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.
Displayed in the footer
Page 516 of 952
Cortex XDR Documentation
Displayed in the header
16.2.4.2 | Create an XDR Collector installation package
Abstract
Learn how to create an XDR Collector installation package for a Windows or Linux collector machine.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
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 XDR .
To move existing XDR Collectors between Cortex XDR 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 XDR, 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 XDR 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 displays Completed, right-click the Collector Version row, and click Download.
Displayed in the footer
Page 517 of 952
Cortex XDR Documentation
Displayed in the header
For a Windows installation, select Download 64 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.
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.
Since Cortex XDR 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.
16.2.4.3 | Install the XDR Collector installation package for Windows
Abstract
Learn about the Cortex XDR Collector installation options on Windows collector machines.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
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.
16.2.4.3.1 | Install the XDR Collector on Windows using the MSI
Abstract
Learn how to install the Cortex XDR Collector on Windows using the MSI.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
Use the following workflow to install the XDR Collector using the MSI file.
Before completing this task, ensure that you create and download a Cortex XDR Collector installation package in Cortex XDR.
To install a XDR Collector installation package on Windows using the MSI.
When the package is executed using the MSI, an installation log is generated in %TEMP%\MSI<Random characters>.log by default.
1. With Administrator level privileges, run the MSI file that you downloaded in Cortex XDR on the collector machine.
The installer displays a welcome dialog.
2. Click Next.
3. Select I accept the terms in the License Agreement and click Next.
4. Install the XDR Collector.
The installer displays a User Account Control dialog.
5. Click Yes.
6. After you complete the installation, verify the Cortex XDR Collector can establish a connection.
If the XDR Collector does not connect to Cortex XDR, 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 XDR management console.
Displayed in the footer
Page 518 of 952
Cortex XDR Documentation
Displayed in the header
16.2.4.3.2 | Install the XDR Collector on Windows using Msiexec
Abstract
Learn how to install the Cortex XDR Collectors on Windows using the Msiexec.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
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.
/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 XDR .
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 keys.
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
16.2.4.4 | Install the XDR Collector installation package for Linux
Abstract
Learn how to install the Cortex XDR Collector on Linux collector machines.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
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.
Displayed in the footer
Page 519 of 952
Cortex XDR Documentation
Displayed in the header
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.
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 root@ubuntu.example.com
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.
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:
When performing a XDR Collector installation or upgrade in Linux using a shell installer, the /tmp folder cannot be marked as noexec. Otherwise, the
installation or upgrade fails. As a workaround, before the installation or upgrade, use the following command:
mount -o remount,exec /tmp
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 or Oracle yum install ./<file_name>.rpm
rpm -i ./<file_name>.rpm
Displayed in the footer
Page 520 of 952
Cortex XDR Documentation
Displayed in the header
Distribution Install Command
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:
1. 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.
2. 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
Created symlink /etc/systemd/system/multi-user.target.wants/xdr-collector.service→ /lib/systemd/system/xdr-collector.service.
If the XDR Collector does not connect to Cortex XDR, 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 XDR management console.
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.
The XDR Collector does not support proxy communication in environments
where proxy authentication is required.
Displayed in the footer
Page 521 of 952
Cortex XDR Documentation
Displayed in the header
Option Description
--data-path <directory path> Directory path
The path for persistence, content, Filebeat application data, and transaction
data.
--data–path=/tmp/xdrLog
16.2.4.5 | XDR Collectors installation resource for Windows and Linux
Abstract
Cortex XDR Collectors installation resource for Windows and Linux.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
The following table provides important information about the XDR Collectors installation for Windows and Linux.
Installation Component Default Path Description Related Files/Services
Installation folder Windows: The default installation path for the Windows
XDR Collector. Contains all
%PROGRAMFILES%\Palo Alto Service name: XDR
Program Core files and
Networks\XDR Collector Collector
executables.
Linux: Process name:
xdrcollectorsvc.exe
/opt/paloaltonetworks/xdr-
collector Linux
Service name: xcd
Process name: xdr-
collector.service
Logs Windows: Windows: Contains the Windows
XDR Collector application
%PROGRAMDATA%\XDR Log, the Filebeat scouter.log
Collector\logs application log, and the
filebeat
Winlogbeat application log.
Linux:
Indicates information, winlogbeat
/opt/paloaltonetworks/xdr- warnings, and errors related
collector/logs to the XDR Collector Linux
application.
scouter.log
Linux: Contains the XDR filebeat
Collector application Log as
well as the Filebeat
application log. 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.
Displayed in the footer
Page 522 of 952
Cortex XDR Documentation
Displayed in the header
Installation Component Default Path Description Related Files/Services
Configuration Windows: Contains the XML configuration For both Windows and Linux, the file
file of the XDR Collector for both name is XDR_Collector.xml.
%PROGRAMFILES%\Palo Alto
Windows and Linux.
Networks\XDR
Collector\config Any change in this XML
configuration file is saved to the
Linux: XDR Collector database and the
settings are taken from this file.
/opt/paloaltonetworks/xdr-
collector/config In some circumstances, such as
after an XDR Collectors upgrade,
the configured settings in the XML
configuration file can be erased.
Yet, this won't affect the saved
settings in the XDR Collectors
database.
Persistence Windows: Contains the Operating System For both Windows and Linux, the file
persistence file for the XDR name is .scouter.json.
%PROGRAMDATA%\XDR Collector, which issued as part of
Collector\OSPersistence the registration process.
Linux:
/etc/panw/OSPersistence/
16.2.4.6 | 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.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
In environments where Cortex XDR Collectors communicate with the Cortex XDR 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 XDR
Collectors Administration page in Cortex XDR 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 XDR 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 XDR directly.
1. In Cortex XDR, 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. Click 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 XDR 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 XDR server. If neither a wide-system proxy nor direct communication exist and you disable the proxy, the
XDR Collector disconnects from Cortex XDR .
Displayed in the footer
Page 523 of 952
Cortex XDR Documentation
Displayed in the header
16.2.4.7 | Upgrade XDR Collectors
Abstract
You can upgrade the Cortex XDR Collector software by using the appropriate method for the collector machine operating system.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
After you install the Cortex XDR Collector and the XDR Collector registers with Cortex XDR, 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 XDR.
1. Create an XDR Collector Installation Package for each operating system version where 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.
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).
16.2.4.8 | Uninstall the XDR Collector
Abstract
You can uninstall the Cortex XDR Collector from one or more Windows or Linux collector machines at any time.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
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 XDR 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.
16.2.4.9 | Set an alias for an XDR Collector machine
Abstract
Displayed in the footer
Page 524 of 952
Cortex XDR Documentation
Displayed in the header
Configure an alias to identify one or more collector machines by a name that is different from the collector machine hostname.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
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.
16.2.5 | Define XDR Collector machine groups
Abstract
To easily apply policy rules and manage specific collector machines, you can define a collector machine group.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
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 XDR 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 XDR , 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.
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 XDR displays any registered collector machine matches to help you validate your filter criteria.
XDR Collectors only support 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 XDR that has registered with Cortex XDR .
Disconnecting Directory Sync in your Cortex XDR 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.
Displayed in the footer
Page 525 of 952
Cortex XDR Documentation
Displayed in the header
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.
16.2.6 | 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.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
To quickly resolve any issues in policy, Palo Alto Networks can seamlessly deliver software packages for Cortex XDR 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 XDR notifies the XDR Collectors. The XDR Collectors then randomly choose a time within a six-hour window during
which they retrieve the content update from Cortex XDR.
16.2.7 | XDR Collector profiles
Abstract
Add an XDR collector profile to define the type of data to collect from a Linux or Windows platform.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
You can add XDR collector profiles that define the type of data that is collected from Linux or Windows platforms.
16.2.8 | 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, and defines automatic XDR Collector upgrade
settings.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
Ingestion of log events larger than 5 MB is not supported.
XDR Collector profiles define the data that is collected from a Windows collector machine, and define automatic upgrade settings for the XDR collector. For
Windows, you can configure a Filebeat profile, a Winlogbeat profile, or a Settings profile.
The Filebeat and Winlogbeat profiles use configuration files in YAML format. To facilitate the configuration of the YAML file, you can add out-of-the-box
collection templates. Templates save you time, and don'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.
Displayed in the footer
Page 526 of 952
Cortex XDR Documentation
Displayed in the header
Use an XDR Collector Windows Filebeat profile to collect file and log data using the Elasticsearch Filebeat default configuration file, called
filebeat.yml.
Cortex XDR supports using Filebeat version 8.8.1 with the operating systems listed in the Elasticsearch support matrix that conform with the collector
machine operating systems supported by Cortex XDR. Cortex XDR supports the input types and modules available in Elasticsearch Filebeat.
Fileset validation is enforced. You must enable at least one fileset in the module, because filesets are disabled by default.
Cortex XDR collects all logs in either an uncompressed JSON or text format. Compressed files, such as the gzip format, are not supported.
Cortex XDR supports logs in single line format or multiline format. For more information about handling messages that span multiple lines of text in
Elasticsearch Filebeat, see Manage Multiline Messages.
Related Information
Elasticsearch Filebeat Overview Documentation
Configure Filebeat Inputs in Elasticsearch
Configure Filebeat Modules in Elasticsearch
Elasticsearch Support Matrix
XDR Collector machine requirements and supported operating systems
Collection of Windows DHCP logs and Windows DNS Debug logs:
Windows DHCP logs
Windows DNS Debug logs
Use an XDR Collector Windows Winlogbeat profile to collect event log data, using the Elasticsearch Winlogbeat default configuration file, called
winlogbeat.yml.
Cortex XDR supports using Winlogbeat version 8.8.1 with the Windows versions listed in the Elasticsearch support matrix that conform with the collector
machine operating systems supported by Cortex XDR. Cortex XDR supports the modules available in Elasticsearch Winlogbeat.
After ingestion, Cortex XDR 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 otherwise, in
microsoft_windows_raw. You can search the data using Cortex Query Language XQL queries, build correlation rules, and generate dashboards
based on the data.
Related information
Elasticsearch Winlogbeat Overview Documentation
Winlogbeat Modules in ElasticSearch
Elasticsearch Support Matrix
Cortex XDR, see XDR Collector machine requirements and supported operating systems
Use an XDR Collector Settings profile to configure automatic upgrade settings for XDR Collector releases.
To map your XDR Collector profile to a collector machine, you must use an XDR Collector policy. After you have created your profile, map it to a new or existing
policy.
How to configure XDR Collector profiles
Filebeat profile
In the Filebeat Configuration File editor, you can define the data collection for your Elasticsearch Filebeat configuration file called filebeat.yml.
Cortex XDR provides YAML templates for DHCP, DNS, IIS, XDR Collector Logs, and NGINX.
1. In Cortex XDR, select Settings → Configurations → XDR Collectors → Profiles → +Add Profile → Windows.
2. Select Filebeat, then click Next.
3. Configure the General Information parameters.
Profile Name: Enter a unique name to identify the profile. The name can contain only letters, numbers, or spaces, and must be no more than 30
characters. The name that you enter here will be displayed in the list of profiles when you configure a policy.
(Optional) Add description here: To provide additional context for the purpose or business reason for your new profile, enter a profile description.
4. In the Filebeat Configuration File editing box, type or paste the contents of your configuration file, or use a template. To add a template, select one from
the list, and click Add.
Displayed in the footer
Page 527 of 952
Cortex XDR Documentation
Displayed in the header
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.
5. Cortex XDR supports all sections in the filebeat.yml configuration file, such as support for Filebeat fields and tags. You can use the "Add fields"
processor to identify the product/vendor for the data collected by the XDR Collectors, so that the collected events go through the ingestion flow (Parsing
Rules). To configure the product/vendor, ensure that you use the default fields attribute (do not use the target attribute), as shown in the following
example:
processors:
- add_fields:
fields:
vendor: <Vendor>
product: <Product>
For more information about the "Add fields" processor, see Add_fields.
6. To finish creating your new profile, click Create.
Your new profile will be listed under the applicable platform on the XDR Collectors Profiles page.
7. Apply profiles to XDR Collector machine policies by performing one of the following:
Right-click a profile, and select Create a new policy rule using this profile.
Launch the new policy wizard from XDR Collectors → Policies → XDR Collectors Policies.
Winlogbeat profile
In the Winlogbeat Configuration File editor, you can define the data collection for your Elasticsearch Winlogbeat configuration file called winlogbeat.yml.
Cortex XDR provides a YAML template for Windows Security. To add a template, select it and click Add.
1. In Cortex XDR, select Settings → Configurations → XDR Collectors → Profiles → +Add Profile → Windows.
2. Select Winlogbeat profile, then click Next.
3. Configure the General Information parameters.
Profile Name: Enter a unique name to identify the profile. The name can contain only letters, numbers, or spaces, and must be no more than 30
characters. The name that you enter here will be displayed in the list of profiles when you configure a policy.
(Optional) Add description here: To provide additional context for the purpose or business reason for your new profile, enter a profile description.
4. In the Winlogbeat Configuration File editing box, type or paste the contents of your configuration file, or use the template. To add the template, click
Select template, and then click Windows Security. Click Add.
5. Cortex XDR supports all sections in the winlogbeat.yml configuration file, such as support for Winlogbeat fields and tags. You can use the "Add
fields" processor to identify the product/vendor for the data collected by the XDR Collectors, so that the collected events go through the ingestion flow
(Parsing Rules). To configure the product/vendor, ensure that you use the default fields attribute (do not use the target attribute), as shown in the
following example:
processors:
- add_fields:
fields:
vendor: <Vendor>
product: <Product>
For more information about the "Add fields" processor, see Add_fields.
6. To finish creating your new profile, click Create.
Your new profile will be listed under the applicable platform on the XDR Collectors Profiles page.
7. Apply profiles to XDR Collector machine policies by performing one of the following:
Right-click a profile, and select Create a new policy rule using this profile.
Launch the new policy wizard from XDR Collectors → Policies → XDR Collectors Policies.
Settings profile
You can configure automatic upgrades for XDR Collector releases. By default, this is disabled, and the Use Default (Disabled) option is selected. To implement
automatic upgrades, follow these steps:
1. In Cortex XDR, select Settings → Configurations → XDR Collectors → Profiles → +Add Profile → Windows.
2. Select Settings profile, then click Next.
3. Configure the General Information parameters.
Displayed in the footer
Page 528 of 952
Cortex XDR Documentation
Displayed in the header
Profile Name: Enter a unique name to identify the profile. The name can contain only letters, numbers, or spaces, and must be no more than 30
characters. The name that you enter here will be displayed in the list of profiles when you configure a policy.
(Optional) Add description here: To provide additional context for the purpose or business reason for your new profile, enter a profile description.
4. Clear the Use Default (Disabled) checkbox.
5. For Collector Auto-Upgrade, select Enabled.
Additional fields are displayed for defining the scope of the automatic upgrade.
6. Configure the scope of automatic upgrades:
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 Auto Upgrade Scope, select one of the following options:
Option More Details
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 Configures the scope of the automatic upgrade to whenever a new XDR Collector maintenance release
in a specific version is available for a specific version. When this option is selected, you can select the specific Release
Version.
7. To finish creating your new profile, click Create.
Your new profile will be listed under the applicable platform on the XDR Collectors Profiles page.
8. Apply profiles to XDR Collector machine policies by performing one of the following:
Right-click a profile, and select Create a new policy rule using this profile.
Launch the new policy wizard from XDR Collectors → Policies → XDR Collectors Policies.
Additional XDR Collector profile management 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 an
XDR Collector profile row, and select the desired action:
Option More Details
Edit Lets you edit the XDR Collector profile
Save As New Copies the existing profile with its current settings, so that you can make modifications, and save it as a new profile with a unique
name
Delete Deletes the XDR Collector profile
View Collector Opens a new tab that displays the XDR Collectors Policies page, showing the policies that are currently associated with your XDR
Policies Collector profiles
Displayed in the footer
Page 529 of 952
Cortex XDR Documentation
Displayed in the header
Option More Details
Copy text to Copies the text from a specific field in the row of a XDR Collector profile
clipboard
Copy entire row Copies the text from the entire row of a XDR Collector profile
16.2.8.1 | Ingest logs from Windows DHCP using Elasticsearch Filebeat
Abstract
Learn how to configure Cortex XDR to receive Windows DHCP logs.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
You can extend visibility into logs from Windows DHCP, and enrich network logs with Windows DHCP data by using one of the following data collectors with
Elasticsearch Filebeat :
XDR Collector profile (recommended)
Windows DHCP collector
When Cortex XDR begins receiving logs, it automatically creates a Windows DHCP dataset (microsoft_dhcp_raw). Cortex XDR uses Windows DHCP logs
to enrich your network logs with hostnames and MAC addresses. Using XQL Search, you will be able to search for these items in the microsoft_dhcp_raw
dataset.
Although this enrichment is available when configuring a Windows DHCP collector for a cloud data collection integration, we recommend configuring Cortex
XDR to receive Windows DHCP logs with an XDR Collector Windows Filebeat profile, because it is simpler to set up.
Related information
For more information about configuring the filebeat.yml file, see Elasticsearch Filebeat documentation.
Ingest Windows DHCP Logs with an XDR Collector Profile
When you add an 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. You can further enrich network logs with Windows DHCP
data by setting vendor to “microsoft”, and product to “dhcp” in the filebeat.yml file.
Configuration activities include editing the filebeat.yml file. To avoid formatting issues in this file, use the template provided by Cortex XDR to make your
customizations. We recommend that you edit the file inside the user interface, instead of copying it and editing it elsewhere. Validate the syntax of the YML file
before you finish creating your profile.
Configure Cortex XDR to receive logs from Windows DHCP using an XDR Collector Windows Filebeat profile:
1. In Cortex XDR, select Settings → Configurations → XDR Collectors → Profiles → +Add Profile → Windows.
2. Select Filebeat, then click Next.
3. Configure the General Information parameters:
Profile Name: Enter a unique name to identify the profile. The name can contain only letters, numbers, or spaces, and must be no more than 30
characters. The name that you enter here will be displayed in the list of profiles when you configure a policy.
(Optional) Add description here: To provide additional context for the purpose or business reason for your new profile, enter a profile description.
4. In the Filebeat Configuration File editing box, select the DHCP template, and click Add.
The template's content is displayed in the editing area.
5. Edit the template text as necessary for your system.
6. To finish creating your new profile, click Create.
Your new profile will be listed under the applicable platform on the XDR Collectors Profiles page.
7. Apply profiles to XDR Collector machine policies by performing one of the following:
Right-click a profile, and select Create a new policy rule using this profile.
Launch the new policy wizard from XDR Collectors → Policies → XDR Collectors Policies.
Ingest Windows DHCP Logs with the Windows DHCP Collector
Displayed in the footer
Page 530 of 952
Cortex XDR Documentation
Displayed in the header
To receive Windows DHCP logs with this collector, you must configure data collection from Windows DHCP via Elasticsearch Filebeat. This is configured by
setting up a Windows DHCP Collector in Cortex XDR and installing and configuring an Elasticsearch Filebeat agent on your Windows DHCP Server. Cortex
XDR 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
Collection Integrations settings in Cortex XDR for the Windows DHCP Collector. To help you configure the filebeat.yml file correctly, Cortex XDR provides
an example file that you can download and customize. After you set up collection integration, Cortex XDR begins receiving new logs and data from the source.
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.
Configuration activities include editing the filebeat.yml file. To avoid formatting issues in this file, use the example file provided by Cortex XDR to make your
customizations. Do not copy and paste the code syntax examples provided later in this procedure into your filebeat.yml file. Validate the syntax of the YML
file before you finish creating your profile.
Configure Cortex XDR to receive logs from Windows DHCP via Elasticsearch Filebeat with the Windows DHCP collector:
1. In Cortex XDR, configure the Windows DHCP Collector.
a. Select Settings → Configurations → Data Collection → Collection Integrations.
b. Click Add Instance to begin a new configuration.
c. Search for Windows DHCP.
d. In the Windows DHCP collector box, click Connect.
The Enable Windows DHCP Log Collection dialog box is displayed.
e. (Optional, but recommended) Download the example filebeat.yml file.
To help you configure your filebeat.yml file correctly, Cortex XDR provides an example filebeat.yml file that you can download and
customize. To download this file, click the filebeat.yml link provided in this dialog box.
f. In the Name field, specify a descriptive name for your log collection configuration.
g. Click Save & Generate Token. A key is displayed.
Click the copy icon next to the key, and save the copy 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.
h. Click Done to close the dialog box.
i. Expand the Windows DHCP collector that you just created. Click the Copy api url icon, and save the copy 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. On your Windows DHCP Server, configure an Elasticsearch Filebeat agent.
a. Navigate to the Elasticsearch Filebeat installation directory, and open the filebeat.yml file to configure data collection with Cortex XDR. We
recommend that you use the download example file provided by Cortex XDR.
b. Update the following sections and tags in the filebeat.yml file. The following code examples detail the specific sections to make these
changes in the file.
Displayed in the footer
Page 531 of 952
Cortex XDR Documentation
Displayed in the header
Filebeat inputs: Define the paths to crawl and fetch. The code in the example below shows how to configure the Filebeat inputs section in
the filebeat.yml file with these paths configured.
Example 51. Example
# ============================== 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 were obtained when you configured the Windows DHCP
Collector in Cortex XDR, as explained in Step #1. The following code example shows how to configure the Elasticsearch Output section in
the filebeat.yml file, and indicates which settings need to be obtained from Cortex XDR.
Example 52. Example
# ---------------------------- 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 in the
example below shows how to configure the Processors section in the filebeat.yml file and indicates which settings need to be obtained
from Cortex XDR.
The tokenizer definition is dependent on the Windows server version that you are using, because 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 later, use "%{id},%{date},%{time},%{description},%{ipAddress},%{hostName},%
{macAddress},%{userName},%{transactionID},%{qResult},%{probationTime},%{correlationID},%{dhcid},%
{vendorClassHex},%{vendorClassASCII},%{userClassHex},%{userClassASCII},%{relayAgentInformation},%
{dnsRegError}"
Example 53. Example
# ================================= 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 in Cortex XDR, and view the statistics for the log collection configuration.
4. After Cortex XDR begins receiving logs from Windows DHCP via Elasticsearch Filebeat, you can use XQL Search to search for logs in the new
microsoft_dhcp_raw dataset.
Displayed in the footer
Page 532 of 952
Cortex XDR Documentation
Displayed in the header
16.2.8.2 | Ingest Windows DNS debug logs using Elasticsearch Filebeat
Abstract
Extend Cortex XDR visibility into Windows DNS Debug logs using Elasticsearch Filebeat with an XDR Collectors profile.
Extend Cortex XDR visibility into Windows DNS Debug logs using an XDR Collector Windows Filebeat profile.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
During configuration of an XDR Collector Windows Filebeat profile, you can configure the profile to enrich network logs with Windows DNS Debug log data.
You do this by editing the Elasticsearch Filebeat default configuration file called filebeat.yml. In this file, you can define whether the collected data
undergoes follow-up processing in the backend for Windows DNS Debug log data. Cortex XDR uses Windows DNS Debug logs to enrich network logs. These
logs can be searched, using XQL Search. You can search the Windows DNS Debug Cortex Query Language dataset (microsoft_dns_raw) for raw data,
and the normalized stories using the xdr_data dataset with the preset called network_story.
1. Enable DNS debug logging in your Windows DNS server settings:
a. In Windows, open DNS Manager, right-click your Windows DNS Server, and select Properties.
b. Select Debug Logging → Log packets for debugging, and keep the settings that are automatically configured for collecting regular Windows DNS
logs in the Packet direction and Packet contents sections.
c. (Optional) To collect detailed Windows DNS logs, under the Other options section, select Details.
Detailed logs are significantly larger, because more information is added to the logs.
d. In the Log file section, for File path and name , enter the file path and log name of your Windows DNS logs, such as
c:\Windows\System32\dns\DNS.log. This path will also be configured in your filebeat.yml file, as explained in a later step (see
Example 54, “Example”).
e. Click OK.
2. In Cortex XDR, go to Settings → Configurations → XDR Collectors → Profiles → +Add Profile → Windows.
3. Select Filebeat, then click Next.
4. Configure the General Information parameters:
Profile Name: Enter a unique name to identify the profile. The name can contain only letters, numbers, or spaces, and must be no more than 30
characters. The name that you enter here will be displayed in the list of profiles when you configure a policy.
(Optional) Add description here: To provide additional context for the purpose or business reason for your new profile, enter a profile description.
5. In the Filebeat Configuration File editing box, select the DNS template of your choice (detailed, or non-detailed). If you configured detailed collection in
the Windows DNS Manager, select the detailed DNS template here. Click Add.
The template's content is displayed in the editing area.
6. Configure the filebeat.yml file to collect Windows DNS Debug log data.
a. In the filebeat.inputs: section of the file, for paths:, configure the file path to your Windows DNS Debug logs. This file path must be the
same as the one configured in your Windows DNS server settings, as explained in an earlier step.
b. Set vendor to “microsoft” and product to “dns”.
The following examples show how to configure the filebeat.yml file to normalize Windows DNS Debug logs with an XDR Collector.
To avoid formatting issues in your filebeat.yml file, we recommend that you validate the syntax of the file.
Example 54. Example
Example for non-detailed (regular) Windows DNS log collection:
filebeat.inputs:
- type: filestream
enabled: true
paths:
- c:\Windows\System32\dns\DNS.log
processors:
- add_fields:
fields:
vendor: "microsoft"
product: "dns"
Example 55. Example
Example for detailed Windows DNS log collection:
filebeat.inputs:
- type: log
Displayed in the footer
Page 533 of 952
Cortex XDR Documentation
Displayed in the header
enabled: true
paths:
- c:\Windows\System32\dns\DNS.log
multiline.type: pattern
multiline.pattern: '^(?:\d{1,2}\/){2}\d{4}\s(?:\d{1,2}\:){2}\d\d\s(?:AM|PM)'
multiline.negate: true
multiline.match: after
processors:
- add_fields:
fields:
vendor: "microsoft"
product: "dns"
7. To finish creating your new profile, click Create.
Your new profile will be listed under the applicable platform on the XDR Collectors Profiles page.
8. Apply profiles to XDR Collector machine policies by performing one of the following:
Right-click a profile, and select Create a new policy rule using this profile.
Launch the new policy wizard from XDR Collectors → Policies → XDR Collectors Policies.
16.2.9 | Add an XDR Collector profile for Linux
Abstract
Add a Cortex XDR Collector profile, which defines the data that is collected from a Linux collector machine, and defines automatic XDR Collector upgrade
settings.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
Ingestion of log events 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 and a Settings
profile.
The Filebeat profile uses a configuration file in YAML format. To facilitate the configuration of the YAML file, you can add an out-of-the-box collection templates.
The templates save you time, and don'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.
Use an XDR Collector Linux Filebeat profile to collect file and log data using the Elasticsearch Filebeat default configuration file, called
filebeat.yml.
Cortex XDR supports using Filebeat version 8.8.1 with the operating systems listed in the Elasticsearch Support Matrix that conform with the collector
machine operating systems supported by Cortex XDR. Cortex XDR supports the input types and modules available in Elasticsearch Filebeat.
Fileset validation is enforced. You must enable at least one fileset in the module, because filesets are disabled by default.
Cortex XDR collects all logs in either an uncompressed JSON or text format. Compressed files, such as the gzip format, are not supported.
Cortex XDR supports logs in single line format or multiline format. For more information about handling messages that span multiple lines of text in
Elasticsearch Filebeat, see Manage Multiline Messages.
Related Information
Elasticsearch Filebeat Overview Documentation
Configure Filebeat Inputs in Elasticsearch
Configure Filebeat Modules in Elasticsearch
Elasticsearch Support Matrix
XDR Collector machine requirements and supported operating systems
Use an XDR Collector Settings profile to configure automatic upgrade settings for XDR Collector releases.
To map your XDR Collector profile to a collector machine, you must use an XDR Collector policy. After you have created your profile, map it to a new or existing
policy.
How to configure XDR Collector profiles
Filebeat profile
In the Filebeat Configuration File editor, you can define the data collection for your Elasticsearch Filebeat configuration file called filebeat.yml.
Cortex XDR provides YAML templates for XDR Collector Logs, Linux (RHEL/CentOS), NGINX (Linux), and Linux (Debian/Ubuntu).
Displayed in the footer
Page 534 of 952
Cortex XDR Documentation
Displayed in the header
1. In Cortex XDR, select Settings → Configurations → XDR Collectors → Profiles → +Add Profile → Linux.
2. Select Filebeat, then click Next.
3. Configure the General Information parameters.
Profile Name: Enter a unique name to identify the profile. The name can contain only letters, numbers, or spaces, and must be no more than 30
characters. The name that you enter here will be displayed in the list of profiles when you configure a policy.
(Optional) Add description here: To provide additional context for the purpose or business reason for your new profile, enter a profile description.
4. In the Filebeat Configuration File editing box, type or paste the contents of your configuration file, or use a template. To add a template, select one from
the list, and click Add.
5. Cortex XDR supports all sections in the filebeat.yml configuration file, such as support for Filebeat fields and tags. You can use the "Add fields"
processor to identify the product/vendor for the data collected by the XDR Collectors, so that the collected events go through the ingestion flow (Parsing
Rules). To configure the product/vendor, ensure that you use the default fields attribute (do not use the target attribute), as shown in the following
example:
processors:
- add_fields:
fields:
vendor: <Vendor>
product: <Product>
For more information about the "Add fields" processor, see Add_fields.
6. To finish creating your new profile, click Create.
Your new profile will be listed under the applicable platform on the XDR Collectors Profiles page.
7. Apply profiles to XDR Collector machine policies by performing one of the following:
Right-click a profile, and select Create a new policy rule using this profile.
Launch the new policy wizard from XDR Collectors → Policies → XDR Collectors Policies.
Settings profile
You can configure automatic upgrades for XDR Collector releases. By default, this is disabled, and the Use Default (Disabled) option is selected. To implement
automatic upgrades, follow these steps:
1. In Cortex XDR, select Settings → Configurations → XDR Collectors → Profiles → +Add Profile → Linux.
2. Select Settings profile, then click Next.
3. Configure the General Information parameters.
Profile Name: Enter a unique name to identify the profile. The name can contain only letters, numbers, or spaces, and must be no more than 30
characters. The name that you enter here will be displayed in the list of profiles when you configure a policy.
(Optional) Add description here: To provide additional context for the purpose or business reason for your new profile, enter a profile description.
4. Clear the Use Default (Disabled) checkbox.
5. For Collector Auto-Upgrade, select Enabled.
Additional fields are displayed for defining the scope of the automatic upgrade.
6. Configure the scope of automatic upgrades:
Displayed in the footer
Page 535 of 952
Cortex XDR Documentation
Displayed in the header
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 Auto Upgrade Scope, select one of the following options:
Option More Details
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 Configures the scope of the automatic upgrade to whenever a new XDR Collector maintenance release
in a specific version is available for a specific version. When this option is selected, you can select the specific Release
Version.
7. To finish creating your new profile, click Create.
Your new profile will be listed under the applicable platform on the XDR Collectors Profiles page.
8. Apply profiles to XDR Collector machine policies by performing one of the following:
Right-click a profile, and select Create a new policy rule using this profile.
Launch the new policy wizard from XDR Collectors → Policies → XDR Collectors Policies.
Additional XDR Collector profile management 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 an
XDR Collector profile row, and select the desired action:
Option More Details
Edit Lets you edit the XDR Collector profile
Save As New Copies the existing profile with its current settings, so that you can make modifications, and save it as a new profile with a unique
name
Delete Deletes the XDR Collector profile
View Collector Opens a new tab that displays the XDR Collectors Policies page, showing the policies that are currently associated with your XDR
Policies Collector profiles
Copy text to Copies the text from a specific field in the row of a XDR Collector profile
clipboard
Copy entire row Copies the text from the entire row of a XDR Collector profile
16.2.10 | Apply profiles to collection machine policies
Abstract
Enable a Cortex XDR Collector profile by mapping it to a policy.
Displayed in the footer
Page 536 of 952
Cortex XDR Documentation
Displayed in the header
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
Enable a Cortex XDR Collector profile by mapping it to a policy. Each policy that you create must apply to one or more collector machines or collector machine
groups.
1. In Cortex XDR, do one of the following:
To create a policy from scratch on the XDR Collectors Policies page, select Settings → Configurations → XDR Collectors → Policies → +Add
Policy.
To add a profile to an existing policy, select Settings → Configurations → XDR Collectors → Policies, then right-click the policy that you want to
edit, and select Edit.
To create a new policy from a profile on the XDR Collectors Profiles page, select Settings → Configurations → XDR Collectors → Profiles, right-
click the profile, and select Create a new policy rule using this profile.
2. Configure the General settings for the policy:
a. Policy Name: Enter a unique name to identify the policy. The name can contain only letters, numbers, or spaces, and must be no more than 30
characters. The name that you enter here will be displayed when you view and configure policies.
b. (Optional) Description: To provide additional context for the purpose or business reason for your policy, enter a policy description.
c. Platform: Select the operating system of the XDR Collector machines that will use the policy.
d. Select the profiles that you want to map to the policy. If you do not specify a profile, the XDR Collector uses the Default profile.
e. Click Next.
3. On the XDR Collectors Endpoints page, select the XDR Collectors (endpoints) or XDR Collector groups to which you want to map the policy. You can use
the provided filters to find XDR Collectors listed on this page.
Cortex XDR automatically applies a filter for the platform that you selected in the previous step. To change the platform, go Back to the general policy
settings.
4. Click Next.
5. On the Summary page, review the settings that you configured for the new policy.
If everything is correct, click Done. Otherwise, click Back to make changes.
6. (Optional) If necessary, change a policy's position relative to other policies in the table on the XDR Collectors Policies page.
The XDR Collector evaluates policies from top to bottom. When an XDR Collector finds the first match, it applies that policy as the active policy. To
change the policy order, click and drag the arrows in the Name cell of a policy to the desired location in the policy hierarchy.
Additional XDR Collector policy management options
As needed, you can return to the XDR Collectors Policies page to manage your XDR Collector policies. To manage a specific policy, right-click anywhere in an
XDR Collector policy row, and select the desired action. You cannot delete or disable default policies.
Option More Details
Disable Disables the selected XDR Collector policy
Delete Deletes the selected XDR Collector policy
View Policy Details Opens a new dialog box that displays details about the profiles mapped to the policy
Save As New Copies the existing policy with its current settings, so that you can make modifications, and save it as a new policy with a different
name
Edit Lets you edit the XDR Collector policy
Copy text to Copies the text from a specific field in the row of a XDR Collector policy
clipboard
Displayed in the footer
Page 537 of 952
Cortex XDR Documentation
Displayed in the header
Option More Details
Copy entire row Copies the text from the entire row of a XDR Collector policy
16.2.11 | XDR Collector datasets
Abstract
After Cortex XDR begins receiving data from your XDR Collectors configuration, the app automatically creates an XQL dataset.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
After Cortex XDR begins receiving data from your XDR Collectors configuration that are dedicated for on-premises 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 XDR 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 XDR 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 XDR creates the dataset, you can search for your XDR Collector data using XQL Search.
16.3 | Data Ingestion
Abstract
Data can be ingested both from Palo Alto Networks products, and from third-party vendor products.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
Data can be ingested both from Palo Alto Networks products, and from third-party vendor products.
16.3.1 | Visibility of logs and alerts from external sources
Abstract
Cortex XDR provides visibility into your external logs. The availability of logs and alerts varies by the data source.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
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
Vendor And Device Type Raw Data Visibility Normalized Log Visibility Cortex XDR Alert Visibility Vendor Alert Visibility
Amazon S3 (flow logs) —
Raw data is Option to ingest network Cortex XDR can raise Cortex XDR alerts
searchable in XQL flow logs as Cortex (Analytics, IOC, BIOC, and Correlation
Search. XDR network connection Rules) when relevant from logs.
stories that are searchable
While Correlation Rules alerts are raised
in the Query Builder and in
on non-normalized and normalized
XQL Search.
logs, Analytics, IOC and BIOC alerts
are only raised on normalized logs.
Displayed in the footer
Page 538 of 952
Cortex XDR Documentation
Displayed in the header
Vendor And Device Type Raw Data Visibility Normalized Log Visibility Cortex XDR Alert Visibility Vendor Alert Visibility
Amazon S3 (Route 53 —
logs) Raw data is Option to ingest network Cortex XDR can raise Cortex XDR alerts
searchable in XQL Route 53 DNS logs (Analytics, IOC, BIOC, and Correlation
Search. as Cortex XDR network Rules) when relevant from logs.
connection stories that are
While Correlation Rules alerts are raised
searchable in the Query
on non-normalized and normalized
Builder and in XQL
logs, Analytics, IOC and BIOC alerts
Search.
are only raised on normalized logs.
Azure Event Hub — —
Raw data is Cortex XDR can raise Cortex XDR alerts
searchable in XQL (Correlation Rules only) when relevant
Search. from flow logs.
Azure Network Watcher —
(flow logs) Raw data is Option to ingest network Cortex XDR can raise Cortex XDR alerts
searchable in XQL flow logs as Cortex (Analytics, IOC, BIOC, and Correlation
Search. XDR network connection Rules) when relevant from flow logs.
stories that are searchable
in the Query Builder and in While Correlation Rules alerts are raised
XQL Search. 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 XDR can raise Cortex XDR alerts Alerts from Check Point
searchable in XQL include Check Point (Analytics, IOC, BIOC, and Correlation firewalls are raised
Search. network connection logs Rules) when relevant from logs. throughout Cortex
are searchable in the XDR when relevant.
Logs with sessionid Query Builder and in XQL While Correlation Rules alerts are raised
= 0 are dropped. Search. on non-normalized and normalized
logs, Analytics, IOC and BIOC alerts
Logs with sessionid = are only raised on normalized logs.
0 are dropped.
Corelight Zeek —
Raw data is Network stories that Cortex XDR can raise Cortex XDR alerts
searchable in XQL include Corelight Zeek (Analytics, IOC, BIOC, and Correlation
Search. network connection logs Rules) when relevant from logs.
are searchable in the
Query Builder and in XQL While Correlation Rules alerts are raised
Search. 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 XDR can raise Cortex XDR alerts
searchable in XQL include Cisco network (Analytics, IOC, BIOC, and Correlation
Search. connection logs are Rules) when relevant from logs.
searchable in the Query
Builder and in XQL While Correlation Rules alerts are raised
Search. on non-normalized and normalized
logs, Analytics, IOC and BIOC alerts
are only raised on normalized logs.
Displayed in the footer
Page 539 of 952
Cortex XDR Documentation
Displayed in the header
Vendor And Device Type Raw Data Visibility Normalized Log Visibility Cortex XDR Alert Visibility Vendor Alert Visibility
Fortinet Fortigate
Raw data is Network stories that Cortex XDR can raise Cortex XDR alerts Alerts from Fortinet
searchable in XQL include Fortinet network (Analytics, IOC, BIOC, and Correlation firewalls are raised
Search. connection logs are Rules) when relevant from logs. throughout Cortex
searchable in the Query XDR when relevant.
While Correlation Rules alerts are raised
Builder and in XQL
on non-normalized and normalized
Search.
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 XDR can raise Cortex XDR alerts
searchable in XQL flow logs as Cortex (Analytics, IOC, BIOC, and Correlation
Search. XDR network connection Rules) when relevant from logs.
stories and Google Cloud
While Correlation Rules alerts are raised
DNS logs that are
on non-normalized and normalized
searchable in the Query
logs, Analytics, IOC and BIOC alerts
Builder and in XQL
are only raised on normalized logs.
Search.
Okta — —
Raw data is Cortex XDR can raise Cortex XDR alerts
searchable in XQL (Analytics, IOC, BIOC, and Correlation
Search. Rules) when relevant from logs.
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 XDR uses Windows
searchable in XQL DHCP logs to enrich your
Search. network logs with
hostnames and MAC
addresses that are
searchable in XQL Search.
Displayed in the footer
Page 540 of 952
Cortex XDR Documentation
Displayed in the header
Vendor And Device Type Raw Data Visibility Normalized Log Visibility Cortex XDR Alert Visibility Vendor Alert Visibility
Zscaler Internet Access —
(ZIA) Raw data is Network stories that Cortex XDR can raise Cortex XDR alerts
searchable in XQL include ZIA network (Analytics, IOC, BIOC, and Correlation
Search. connection and firewall Rules) when relevant from logs.
logs are searchable in the
While Correlation Rules alerts are
Query Builder and in XQL
raised on non-normalized and
Search.
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 XDR can raise Cortex XDR alerts
searchable in XQL include ZPA network (Analytics, IOC, BIOC, and Correlation
Search. connection logs are Rules) when relevant from logs.
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.
The Zscaler Nanolog Streaming
Service (NSS) feed for web logs
is only used for Correlation Rules
and threat hunting.
Authentication services/Audit logs
Vendor And Device Type Raw Data Visibility Normalized Log Visibility Cortex XDR Alert Visibility Vendor Alert Visibility
Amazon S3 (audit logs) —
Logs and stories are Option to stitch audit logs Cortex XDR can raise Cortex XDR alerts
searchable in XQL with authentication stories (Analytics, IOC, BIOC, and Correlation
Search that are searchable in the Rules) when relevant from logs.
Query Builder and 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.
Azure Event Hub (audit —
logs, AKS logs) Logs and stories are Option to stitch audit logs Cortex XDR can raise Cortex XDR alerts
searchable in XQL with authentication stories (Analytics, IOC, BIOC, and Correlation
Search that are searchable in the Rules) when relevant from logs.
Query Builder and 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.
Displayed in the footer
Page 541 of 952
Cortex XDR Documentation
Displayed in the header
Vendor And Device Type Raw Data Visibility Normalized Log Visibility Cortex XDR Alert Visibility Vendor Alert Visibility
Google Cloud Platform —
(audit logs, GKE logs) Raw data is Option to stitch audit logs Cortex XDR can raise Cortex XDR alerts
searchable in XQL with authentication stories (Analytics, IOC, BIOC, and Correlation
Search. that are searchable in the Rules) when relevant from logs.
Query Builder and XQL
While Correlation Rules alerts are raised
Search.
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 XDR can
searchable in XQL Google drive, SAML, raise Cortex XDR 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.
Microsoft 365 email —
Email logs are Microsoft 365 normalized For Microsoft 365 email logs, Cortex
searchable in XQL email stories XDR can also raise Cortex XDR alerts
Search (Analytics, IOC, BIOC, and Correlation
Rules) when relevant from the email
logs.
Microsoft Office 365 —
Logs and stories Azure AD authentication For all Microsoft Office 365 logs, Cortex
(Azure AD logs and Azure AD Sign-in XDR can also raise Cortex XDR alerts
authentication and logs normalized into (Analytics, IOC, BIOC, and Correlation
audit logs only) are authentication stories. Rules) when relevant from Office 365
searchable in XQL Azure AD audit logs logs.
Search normalized to cloud audit
logs stories. Exchange While Correlation Rules alerts are raised
Online, SharePoint Online, on non-normalized and normalized
and General audit logs logs, Analytics, IOC and BIOC alerts
normalized into stories. All are only raised on normalized logs.
are searchable in the
Query Builder.
Okta —
Logs and stories are Logs stitched with Cortex XDR can raise Cortex XDR alerts
searchable in XQL authentication stories are (Analytics, IOC, BIOC, and Correlation
Search searchable in the Query Rules only) when relevant from logs.
Builder.
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.
Displayed in the footer
Page 542 of 952
Cortex XDR Documentation
Displayed in the header
Vendor And Device Type Raw Data Visibility Normalized Log Visibility Cortex XDR Alert Visibility Vendor Alert Visibility
OneLogin —
Raw data is All log types are Cortex XDR can raise Cortex XDR alerts
searchable in XQL normalized into (Analytics, IOC, BIOC, and Correlation
Search. authentication stories, and Rules) when relevant from logs.
are searchable in the
While Correlation Rules alerts are raised
Query Builder.
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 XDR can raise Cortex XDR alerts
searchable in XQL authentication stories are (Analytics, IOC, BIOC, and Correlation
Search searchable in the Query Rules) when relevant from logs.
Builder.
While Correlation Rules alerts are raised
on non-normalized and normalized
logs, Analytics, IOC and BIOC alerts
are only raised on normalized logs.
PingOne for Enterprise —
Raw data is Logs stitched with Cortex XDR can raise Cortex XDR alerts
searchable in XQL authentication stories are (Analytics, IOC, BIOC, and Correlation
Search searchable in the Query Rules) when relevant from logs.
Builder.
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 XDR Alert Visibility Vendor Alert Visibility
Amazon S3 (generic logs) — —
Raw data is searchable in Cortex XDR can
XQL Search. raise Cortex XDR alerts
(Correlation Rules only)
when relevant from logs.
Amazon CloudWatch —
(generic logs, EKS logs) Raw data is searchable in Cortex XDR can
XQL Search. raise Cortex XDR alerts
(Analytics, IOC, BIOC, and
Correlation Rules) when
relevant from logs.
While Correlation Rules
alerts are raised on non-
normalized and normalized
logs, Analytics, IOC and
BIOC alerts are only raised
on normalized logs.
Displayed in the footer
Page 543 of 952
Cortex XDR Documentation
Displayed in the header
Vendor And Device Type Raw Data Visibility Normalized Log Visibility Cortex XDR Alert Visibility Vendor Alert Visibility
Azure Event Hub — —
Raw data is searchable in Cortex XDR can
XQL Search. raise Cortex XDR alerts
(Correlation Rules only)
when relevant from logs.
Google Cloud Platform — —
Raw data is searchable in Cortex XDR can
XQL Search. raise Cortex XDR alerts
(Correlation Rules only)
when relevant from logs.
Google Kubernetes Engine — —
Raw data is searchable in Cortex XDR can
XQL Search. raise Cortex XDR alerts
(Correlation Rules only)
when relevant from logs.
Okta — —
Raw data is searchable in Cortex XDR can
XQL Search. raise Cortex XDR alerts
(Analytics, IOC, BIOC, and
Correlation Rules) when
relevant from logs.
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 (alerts)
Raw data is searchable in Prisma Cloud alerts are Cortex XDR can Alerts from Prisma Cloud
XQL Search. stitched with Cloud Provider raise Cortex XDR alerts are raised
logs when relevant. (Correlation Rules only) throughout Cortex
when relevant from logs. XDR when relevant.
Prisma Cloud Compute —
(alerts) Raw data is searchable in Cortex XDR can Alerts from Prisma Cloud
XQL Search. raise Cortex XDR alerts Compute are raised
(Correlation Rules only) throughout Cortex
when relevant from logs. XDR when relevant.
Endpoint logs
Displayed in the footer
Page 544 of 952
Cortex XDR Documentation
Displayed in the header
Vendor And Device Type Raw Data Visibility Normalized Log Visibility Cortex XDR Alert Visibility Vendor Alert Visibility
Windows Event Collector —
Windows event logs are available Windows event logs are stitched Cortex XDR can
with agent EDR data and are with agent EDR data and are raise Cortex XDR alerts
searchable in XQL Search. searchable in the Query Builder. (Analytics, IOC, BIOC, and
Correlation Rules) when
The normalized Windows event log The Windows event logs are also
relevant from logs.
data is also available normalized into the common
in microsoft_windows_raw and Cortex Windows event 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 XDR 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
Custom external sources
Vendor And Device Type Raw Data Visibility Normalized Log Visibility Cortex XDR Alert Visibility Vendor Alert Visibility
Any Vendor Sending CEF, —
LEEF, CISCO, CORELIGHT, Raw data is searchable in Cortex XDR can To enable Cortex XDR to
or RAW formatted Syslog XQL Search. raise Cortex XDR alerts display alerts from other
(Analytics, IOC, BIOC, and vendors, you must map
Correlation Rules) when your alert fields to
relevant from logs. the Cortex XDR field format
(see Ingest external 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 XDR can
XQL Search. raise Cortex XDR alerts
(Correlation Rules only)
when relevant from logs.
Displayed in the footer
Page 545 of 952
Cortex XDR Documentation
Displayed in the header
Vendor And Device Type Raw Data Visibility Normalized Log Visibility Cortex XDR Alert Visibility Vendor Alert Visibility
Any vendor logs stored in a — —
database Raw data is searchable in Cortex XDR can
XQL Search. raise Cortex XDR alerts
(Correlation Rules only)
when relevant from logs.
Any vendor logs stored in — —
files on a network share Raw data is searchable in Cortex XDR can
XQL Search. raise Cortex XDR alerts
(Correlation Rules only)
when relevant from logs.
Any vendor logs from a — —
third party source over FTP, Raw data is searchable in Cortex XDR can
FTPS, or SFTP XQL Search. raise Cortex XDR alerts
(Correlation Rules only)
when relevant from logs.
Any vendor sending —
NetFlow flow records Raw data is searchable in NetFlow events are stitched Cortex XDR can
XQL Search. with the Agent’s EDR data raise Cortex XDR 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.
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 sending logs —
over HTTP Raw data is searchable in Cortex XDR can To enable Cortex XDR to
XQL Search. raise Cortex XDR alerts display alerts from other
(Correlation Rules only) vendors, you must map
when relevant from logs. your alert fields to
the Cortex XDR field format
(see Ingest external alerts).
Apache Kafka — —
Raw data is searchable in Cortex XDR can
XQL Search. raise Cortex XDR alerts
(Analytics, IOC, BIOC, and
Correlation Rules) when
relevant from logs.
While Correlation Rules
alerts are raised on non-
normalized and normalized
logs, Analytics, IOC and
BIOC alerts are only raised
on normalized logs.
Displayed in the footer
Page 546 of 952
Cortex XDR Documentation
Displayed in the header
Vendor And Device Type Raw Data Visibility Normalized Log Visibility Cortex XDR Alert Visibility Vendor Alert Visibility
BeyondTrust Privilege — —
Management Cloud Raw data is searchable in Cortex XDR can
XQL Search. raise Cortex XDR alerts
(Correlation Rules only)
when relevant from logs.
Box —
Raw data is searchable in Selected Box audit event Cortex XDR can
XQL Search. logs are normalized into raise Cortex XDR alerts
stories and are searchable (Analytics, IOC, BIOC, and
in the Query Builder and in Correlation Rules) when
XQL. relevant from logs.
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 XDR can
XQL Search. logs are normalized into raise Cortex XDR alerts
stories and are searchable (Analytics, IOC, BIOC, and
in the Query Builder and in Correlation Rules) when
XQL. relevant from logs.
While Correlation Rules
alerts are raised on non-
normalized and normalized
logs, Analytics, IOC and
BIOC alerts are only raised
on normalized logs.
Elasticsearch Filebeat — —
Raw data is searchable in Cortex XDR can
XQL Search. raise Cortex XDR alerts
(Correlation Rules only)
when relevant from logs.
Forcepoint DLP — —
Raw data is searchable in Cortex XDR can
XQL Search. raise Cortex XDR alerts
(Correlation Rules only)
when relevant from logs.
Displayed in the footer
Page 547 of 952
Cortex XDR Documentation
Displayed in the header
Vendor And Device Type Raw Data Visibility Normalized Log Visibility Cortex XDR Alert Visibility Vendor Alert Visibility
IoT Security —
Raw data is searchable in Cortex XDR uses IoT Cortex XDR can
XQL Search. Security information to raise Cortex XDR alerts
improve analytics detection (Analytics, IOC, BIOC, and
and assets management Correlation Rules) when
information. relevant from logs.
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 XDRCortex XDR
XQL Search. alerts (Correlation Rules
only) when relevant from
logs.
Salesforce.com — —
Raw data is searchable in Cortex XDR can
XQL Search. raise Cortex XDR alerts
(Correlation Rules only)
when relevant from logs.
ServiceNow CMDB — —
Raw data is searchable in Cortex XDRCortex XDR
XQL Search. alerts (Correlation Rules
only) when relevant from
logs.
Strata Logging Service
Raw data is searchable in Detection events are Cortex XDR can Alerts from NGFW are
XQL Search. stitched with other Palo Alto raise Cortex XDR alerts raised throughout Cortex
Networks product logs to (Analytics, IOC, BIOC, and XDR when relevant.
stories, and are searchable Correlation Rules) when
in the Query Builder and in relevant from logs.
XQL.
While Correlation Rules
alerts are raised on non-
normalized and normalized
logs, Analytics, IOC and
BIOC alerts are only raised
on normalized logs.
Workday — —
Raw data is searchable in Cortex XDRCortex XDR
XQL Search. alerts (Correlation Rules
only) when relevant from
logs.
Displayed in the footer
Page 548 of 952
Cortex XDR Documentation
Displayed in the header
Vendor And Device Type Raw Data Visibility Normalized Log Visibility Cortex XDR Alert Visibility Vendor Alert Visibility
Any vendor sending alerts — — —
Alerts are surfaced
throughout Cortex XDR
when relevant. To
enable Cortex XDR to
display your alerts, you
must map your alert fields
to the Cortex XDR field
format (see Ingest external
alerts).
Datasets created from ingesting data
When ingesting data from an external source, Cortex XDR 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.
16.3.2 | Visibility of Cortex XDR audit and authentication logs
Abstract
Monitor Cortex XDR authentication and audit logs for detecting attacks on Cortex XDR.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
You can audit and query Cortex XDR authentication logs and activity logs to track and trigger alerts about malicious activity on Cortex XDR.
A indicates support and a dash (—) indicates the feature is not supported.
LOG TYPE RAW DATA VISIBILITY NORMALIZED LOG VISIBILITY Cortex XDR ALERT VISIBILITY
Cortex XDR
authentication
logs Logs and stories are Cortex XDR authentication logs normalized into Cortex XDR can raise Cortex XDR alerts
searchable in XQL Search. authentication stories, which are searchable in (Analytics, IOC, BIOC, and Correlation Rules)
the Query Builder. when relevant from logs.
Cortex XDR can raise Cortex XDR alerts
(Analytics, IOC, BIOC, and Correlation Rules)
when relevant from logs.
Cortex XDR audit
logs
Logs and stories are Cortex XDR authentication logs are normalized Cortex XDR can raise Cortex XDR alerts
searchable in XQL Search. into SaaS stories which are searchable in the (Analytics, IOC, BIOC, and Correlation Rules)
Query Builder. when relevant from logs.
Cortex XDR can raise Cortex XDR alerts
(Analytics, IOC, BIOC, and Correlation Rules)
when relevant from logs.
Displayed in the footer
Page 549 of 952
Cortex XDR Documentation
Displayed in the header
16.3.3 | External data ingestion vendor support
Abstract
To augment your Cortex XDR data, you can set up Cortex XDR to ingest data from a variety of external third-party sources.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
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 XDR.
Cortex XDR can receive logs, or both logs and alerts, from the source. Depending on the data source, Cortex XDR 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 XDR, such as in the alerts table, incidents, and views.
Alerts raised by Cortex XDR 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.
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 via Elasticsearch Filebeat
Zscaler Internet Access (ZIA)
Zscaler Private Access (ZPA)
Authentication Services/Audit Logs Amazon S3 (audit logs)
Azure Event Hub (audit logs, AKS logs)
Google Cloud Platform (audit logs, GKE logs)
Google Workspace
Microsoft 365 (email)
Microsoft Office 365
Okta
OneLogin
PingFederate
PingOne for Enterprise
Displayed in the footer
Page 550 of 952
Cortex XDR Documentation
Displayed in the header
Log/Data Type Vendor Support
Operation and System Logs from Cloud Providers Amazon S3 (generic logs)
Amazon CloudWatch (generic logs, EKS logs)
Azure Event Hub
Google Cloud Platform
Google Kubernetes Engine
Okta
Prisma Cloud (alerts)
Prisma Cloud Compute (alerts)
Endpoint Logs Windows Event Collector
Cloud Assets AWS
Google Cloud Platform
Microsoft Azure
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
16.3.4 | Palo Alto Networks integrations
Abstract
Displayed in the footer
Page 551 of 952
Cortex XDR Documentation
Displayed in the header
Cortex XDR supports Palo Alto Networks data ingestion.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
Cortex XDR supports streaming data directly from Prisma Access accounts, Next-Generation Firewalls (NGFW), and Panorama devices to your Cortex XDR
tenants using the Strata Logging Service.
New tenants (and tenants upgraded from XDR to XSIAM) will work with the new direct integration of Next-Generation Firewall and Panorama into Cortex. For
such tenants, there’s no option to use the Strata Logging Service integration.
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 XDR 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 Collection Integrations page. Make sure you select all your devices to connect directly to Cortex XDR.
Two weeks prior to the end of your Strata Logging Service license, Cortex XDR will automatically migrate your integrations to your Strata Logging
Service.
Roll-back of Strata Logging Service integration migration is not supported.
16.3.4.1 | About Palo Alto Networks integrations
Abstract
Stream data directly from other Palo Alto Networks products to Cortex XDR.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
Cortex XDR supports streaming data directly from Prisma Access accounts, Next-Generation Firewalls (NGFW), and Panorama devices to your Cortex XDR
tenants using the Strata Logging Service.
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 Collection Integrations page to configure your integrations. All devices and accounts allocated to your
CSP accounts are available to integrate.
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.
New tenants (and tenants upgraded from XDR to XSIAM) will work with the new direct integration of Next-Generation Firewall and Panorama into Cortex. For
such tenants, there’s no option to use the Strata Logging Service integration.
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 XDR 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 Collection Integrations page. Make sure you select all your devices to connect directly to Cortex XDR.
Two weeks prior to the end of your Strata Logging Service license, Cortex XDR will automatically migrate your integrations to your Strata Logging
Service.
Roll-back of Strata Logging Service integration migration is not supported.
16.3.4.2 | Ingest data from Next-Generation Firewall
Abstract
Learn how to ingest detection data from Next-Generation Firewall and Panorama.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
You can forward firewall data from your Next-Generation Firewall (NGFW) and Panorama devices to Cortex XDR.
Collection of firewall data from multiple accounts is supported. Super User permissions on both the Cortex XDR tenant accounts and the NGFW or Panorama
accounts are required for this use case. Additionally, the CSP accounts must be in the same account; linked accounts are not supported.
New tenants (and tenants upgraded from XDR to XSIAM) will work with the new direct integration of Next-Generation Firewall and Panorama into Cortex. For
such tenants, there’s no option to use the Strata Logging Service integration.
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 XDR in either of the following ways before the license expires:
Displayed in the footer
Page 552 of 952
Cortex XDR Documentation
Displayed in the header
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 Collection Integrations page. Make sure you select all your devices to connect directly to Cortex XDR.
Two weeks prior to the end of your Strata Logging Service license, Cortex XDR will automatically migrate your integrations to your Strata Logging
Service.
Roll-back of Strata Logging Service integration migration is not supported.
Ensure that you have completed the following on the NGFW or Panorama side:
For Panorama only, ensure that the Panorama Cloud Services plugin is installed.
Enable log forwarding profiles on firewall rules.
On the Cortex XDR side, ensure that you have user role permissions for Data Collection > Log Collections.
Configuration of data ingestion from multiple accounts requires Super User permissions on both the Cortex XDR tenant and on the device accounts.
Additionally, the CSP accounts must be in the same account; linked accounts are not supported.
If your firewalls are located in a different region, or bandwidth issues are encountered due to large log size, you can ingest NGFW logs in CEF format,
using the Syslog collector. This solution provides similar protection, out-of-the-box data modeling and analytics to logs ingested into Strata Logging
Service. For more information, see Ingest Next-Generation Firewall logs using the Syslog collector.
In the following procedure, general information is provided for NGFW and Panorama. For detailed instructions, consult the documentation for your
specific devices and Panorama version.
Set up detection data ingestion
1. In the user interface for setting up firewalls, for Strata Logging Service/Cloud Logging, enable the following options directly, or using device templates.
(For example, go to Device → Setup → Management → Cloud Logging section)
a. Select Enable Strata Logging Service.
b. Select Enable Enhanced Application Logging.
c. (Optional, depending on your organization's requirements) Select Enable Duplicate Logging (Cloud and On-Premise).
2. 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.
Cortex XDR 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.
3. Onboard the certificates.
4. Define a Log Forwarding profile.
5. Map the Log Forwarding profile to a Security Policy Rule.
6. Verify that the connection between the firewalls and Strata Logging Service is valid.
7. Push the configuration changes to the firewalls.
8. In Cortex XDR, select Settings → Configurations → Data Collection → Collection Integrations.
9. On the Collection Integrations page, locate your NGFW data source and select Add Instance to begin a new connection.
10. Select Add NGFW Device or Add Panorama Device, and then do one of the following:
For devices in your account, select one or more devices from Select FW/Panorama devices.
To include devices from other accounts, select Select devices from other accounts, and then select one or more FW or Panorama devices from
other accounts. For cross-account connections, you must have Super User permissions on the Cortex tenant account and the device account.
Devices already connected are listed at the end. A device may be connected via Strata Logging Service, or via Cortex XDR. Rectify any streaming
issues that may arise by checking configurations for the relevant connection type (Strata Logging Service or Cortex XDR).
11. To complete the onboarding process of your devices, on the Next Steps to Connect Your Devices page, expand the relevant device version, and follow
the corresponding instructions.
12. Click 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.
13. Validate that your data is streaming. It might be necessary to create traffic before you verify data streaming.
Displayed in the footer
Page 553 of 952
Cortex XDR Documentation
Displayed in the header
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]"
14. (Optional) Manage your Instance.
After you create the NGFW instance, on the Collection Integrations 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.
It might take an hour or longer after connecting the firewall in Cortex XDR until you start seeing notifications that the certificate has been approved, and that the
logging service license has appeared on the firewall.
When Cortex XDR 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 XDR can also raise Cortex XDR 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.
IOC and BIOC alerts are applicable on stitched data only and are not available on raw data.
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.
16.3.4.2.1 | Ingest Next-Generation Firewall logs using the Syslog collector
Abstract
Use the Syslog collector to ingest NGFW logs in CEF format. This method is useful when your firewalls are located in a different region, or bandwidth issues are
encountered due to large log size.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
Use the Syslog collector to ingest Next-Generation Firewall (NGFW) logs in CEF format. This method is useful when your firewalls are located in a different
region, or bandwidth issues are encountered due to large log size. This solution provides similar protection, out-of-the-box data modeling and analytics to logs
ingested into Strata Logging Service.
In the following procedure, general information is provided for NGFW and Panorama. For detailed instructions, consult the documentation for your specific
devices and Panorama version, to ensure that you have configured log forwarding correctly for all the log types that you would like to forward to Cortex XDR.
The following steps only cover configuration of the custom log schema (CEF) for a given syslog server. They do not replace the administrator guide’s
configuration coverage of log forwarding.
Configure the firewall/Panorama for log forwarding to Cortex XDR
1. To configure the device to include its IP address in the header of Syslog messages, select Panorama/Device → Setup → Management, click the Edit
icon in the Logging and Reporting Settings section, and navigate to the Log Export and Reporting tab.
2. From the Syslog HOSTNAME Format menu, select ipv4-address or ipv6-address, and click OK.
3. Select Device → Server Profiles → Syslog, and click Add.
4. Enter a server profile Name and Location (Location refers to a virtual system, if the device is enabled for virtual systems).
5. On the Servers tab of the Syslog Server Profiles window, click Add, and enter the following information for the Syslog server:
Displayed in the footer
Page 554 of 952
Cortex XDR Documentation
Displayed in the header
Name
Syslog Server (IP address)
Transport, Port (default 514 for UDP)
Facility (default LOG_USER)
6. Select the Custom Log Format tab and click configure the log formats as follows:
To avoid the possible effects of line formatting, do not copy/paste the message formats directly into the PAN-OS web interface. Instead, paste into a text
editor, remove any carriage return or line feed characters, and then copy and paste into the web interface.
From version 10.0 and later, the log format documented for log types (Traffic, Threat, and URL) exceeds the maximum supported 2048 characters in the
Custom Log Format tab on the firewall and Panorama. Select the CEF keys and values to limit the number of characters to 2048, as per your
requirements.
Log Type Custom Format
Traffic CEF:0|PANW|NGFW_CEF|$sender_sw_version|$subtype|$type|1| __firewall_type=firewall.traffic __timestamp=$start
__tz=$high_res_timestamp log_type=$type subtype=$subtype log_time=$cef-formatted-receive_time
time_generated=$cef-formatted-time_generated log_source_id=$serial log_source_name=$device_name
sequence_no=$seqno source_ip=$src dest_ip=$dst source_port=$sport dest_port=$dport nat_source=$natsrc
nat_dest=$natdst nat_source_port=$natsport nat_dest_port=$natdport protocol=$proto action=$action
source_user=$srcuser dest_user=$dstuser xff_ip=$xff_ip app=$app app_category=$category_of_app
app_sub_category=$subcategory_of_app rule_matched=$rule rule_matched_uuid=$rule_uuid severity=1 vsys=$vsys
vsys_name=$vsys_name from_zone=$from to_zone=$to inbound_if=$inbound_if outbound_if=$outbound_if
session_id=$sessionid source_device_category=$src_category source_device_profile=$src_profile
source_device_model=$src_model source_device_vendor=$src_vendor source_device_osfamily=$src_osfamily
source_device_osversion=$src_osversion source_device_mac=$src_mac dest_device_category=$dst_category
dest_device_profile=$dst_profile dest_device_model=$dst_model dest_device_vendor=$dst_vendor
dest_device_osfamily=$dst_osfamily dest_device_osversion=$dst_osversion dest_device_mac=$dst_mac
bytes_sent=$bytes_sent bytes_received=$bytes_received packets_received=$pkts_received
packets_sent=$pkts_sent total_time_elapsed=$elapsed session_end_reason=$session_end_reason
url_category=$category
Threat CEF:0|PANW|NGFW_CEF|$sender_sw_version|$threatid|$type|$number-of-severity| __firewall_type=firewall.threat
__timestamp=$cef-formatted-time_generated __tz=$high_res_timestamp log_type=$type subtype=$subtype
log_time=$cef-formatted-receive_time time_generated=$cef-formatted-time_generated log_source_id=$serial
log_source_name=$device_name sequence_no=$seqno source_ip=$src dest_ip=$dst source_port=$sport
dest_port=$dport nat_source=$natsrc nat_dest=$natdst nat_source_port=$natsport nat_dest_port=$natdport
protocol=$proto action=$action source_user=$srcuser dest_user=$dstuser xff=$xff xff_ip=$xff_ip app=$app
app_category=$category_of_app app_sub_category=$subcategory_of_app rule_matched=$rule
rule_matched_uuid=$rule_uuid severity=$number-of-severity vsys=$vsys vsys_name=$vsys_name from_zone=$from
to_zone=$to inbound_if=$inbound_if outbound_if=$outbound_if session_id=$sessionid
source_device_category=$src_category source_device_profile=$src_profile source_device_model=$src_model
source_device_vendor=$src_vendor source_device_osfamily=$src_osfamily
source_device_osversion=$src_osversion source_device_mac=$src_mac dest_device_category=$dst_category
dest_device_profile=$dst_profile dest_device_model=$dst_model dest_device_vendor=$dst_vendor
dest_device_osfamily=$dst_osfamily dest_device_osversion=$dst_osversion dest_device_mac=$dst_mac
misc=$misc threat_id=$threatid threat_name=$threat_name threat_category=$thr_category direction=$direction
user_agent=$user_agent
Displayed in the footer
Page 555 of 952
Cortex XDR Documentation
Displayed in the header
Log Type Custom Format
URL CEF:0|PANW|NGFW_CEF|$sender_sw_version|$subtype|$type|$number-of-severity| __firewall_type=firewall.url
__timestamp=$cef-formatted-time_generated __tz=$high_res_timestamp log_type=$type subtype=$subtype
log_time=$cef-formatted-receive_time time_generated=$cef-formatted-time_generated log_source_id=$serial
log_source_name=$device_name sequence_no=$seqno source_ip=$src dest_ip=$dst source_port=$sport
dest_port=$dport nat_source=$natsrc nat_dest=$natdst nat_source_port=$natsport nat_dest_port=$natdport
protocol=$proto action=$action source_user=$srcuser dest_user=$dstuser xff=$xff xff_ip=$xff_ip app=$app
app_category=$category_of_app app_sub_category=$subcategory_of_app rule_matched=$rule
rule_matched_uuid=$rule_uuid severity=$number-of-severity vsys=$vsys vsys_name=$vsys_name from_zone=$from
to_zone=$to inbound_if=$inbound_if outbound_if=$outbound_if session_id=$sessionid
source_device_category=$src_category source_device_profile=$src_profile source_device_model=$src_model
source_device_vendor=$src_vendor source_device_osfamily=$src_osfamily
source_device_osversion=$src_osversion source_device_mac=$src_mac dest_device_category=$dst_category
dest_device_profile=$dst_profile dest_device_model=$dst_model dest_device_vendor=$dst_vendor
dest_device_osfamily=$dst_osfamily dest_device_osversion=$dst_osversion dest_device_mac=$dst_mac uri=$misc
threat_id=$threatid threat_name=$threat_name threat_category=$thr_category direction=$direction
user_agent=$user_agent url_category=$category url_category_list=$url_category_list content_type=$contenttype
http_method=$http_method http_headers=$http_headers http2_connection=$http2_connection referer=$referer
pcap_id=$pcap_id
File Data CEF:0|PANW|NGFW_CEF|$sender_sw_version|$threatid|$type|$number-of-severity| __firewall_type=firewall.filedata
__timestamp=$cef-formatted-time_generated __tz=$high_res_timestamp log_type=$type subtype=$subtype
log_time=$cef-formatted-receive_time time_generated=$cef-formatted-time_generated log_source_id=$serial
log_source_name=$device_name sequence_no=$seqno source_ip=$src dest_ip=$dst source_port=$sport
dest_port=$dport nat_source=$natsrc nat_dest=$natdst nat_source_port=$natsport nat_dest_port=$natdport
protocol=$proto action=$action source_user=$srcuser dest_user=$dstuser xff=$xff xff_ip=$xff_ip app=$app
app_category=$category_of_app app_sub_category=$subcategory_of_app rule_matched=$rule
rule_matched_uuid=$rule_uuid severity=$number-of-severity vsys=$vsys vsys_name=$vsys_name from_zone=$from
to_zone=$to inbound_if=$inbound_if outbound_if=$outbound_if session_id=$sessionid
source_device_category=$src_category source_device_profile=$src_profile source_device_model=$src_model
source_device_vendor=$src_vendor source_device_osfamily=$src_osfamily
source_device_osversion=$src_osversion source_device_mac=$src_mac dest_device_category=$dst_category
dest_device_profile=$dst_profile dest_device_model=$dst_model dest_device_vendor=$dst_vendor
dest_device_osfamily=$dst_osfamily dest_device_osversion=$dst_osversion dest_device_mac=$dst_mac
misc=$misc threat_id=$threatid threat_name=$threat_name threat_category=$thr_category direction=$direction
user_agent=$user_agent file_url=$file_url filedigest=$filedigest filetype=$filetype pcap_id=$pcap_id
7. Configure Escaping characters as follows:
Escaped Characters: \=
Escape Character: \
Displayed in the footer
Page 556 of 952
Cortex XDR Documentation
Displayed in the header
Configure Syslog collection
Set up a Syslog collector for the logs, as explained in Activate Syslog Collector. In Task 4, ensure that you set Format to CEF.
16.3.4.3 | Ingest data from Prisma Access
Abstract
Learn how to ingest detection data from Prisma Access.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
You can forward data from Prisma Access to Cortex XDR. When your Cortex XDR 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.
Collection of data from multiple accounts is supported. Super User permissions on both the Cortex XDR tenant accounts and the Prisma Access accounts are
required for this use case.
New tenants (and tenants upgraded from XDR to XSIAM) will work with the new direct integration of Next-Generation Firewall and Panorama into Cortex. For
such tenants, there’s no option to use the Strata Logging Service integration.
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 XDR 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 Collection Integrations page. Make sure you select all your devices to connect directly to Cortex XDR.
Two weeks prior to the end of your Strata Logging Service license, Cortex XDR will automatically migrate your integrations to your Strata Logging
Service.
Roll-back of Strata Logging Service integration migration is not supported.
Configuration of data ingestion from multiple accounts requires Super User permissions in both Cortex XDR tenant and Prisma Access accounts.
To ingest detection data from Prisma Access:
1. Select Settings → Configurations → Data Collection → Collection Integrations.
Displayed in the footer
Page 557 of 952
Cortex XDR Documentation
Displayed in the header
2. In the Prisma Access configuration, click Add Instance.
Cortex XDR 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, you can choose to connect Prisma Access to this account or other accounts:
To connect Prisma Access to this account, click Connect.
To connect Prisma Access to other accounts, click Connect Prisma Access from other accounts and select the account from the accounts listed.
Click Connect.
Connection can take up to several minutes.
On the Collection Integrations 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 Collection Integrations page, expand the Prisma Access integration to track the connection, or, if you
want, to Delete the instance.
16.3.4.4 | Ingest alerts from Prisma Cloud Compute
Abstract
Configure Data Collection Settings to receive alerts from Prisma Cloud Compute.
Ingestion of alerts from Prisma Cloud Compute requires a Cortex XDR Pro per GB license.
To receive alerts from Prisma Cloud Compute, first configure the Collection Integrations settings in Cortex XDR. In Prisma Cloud, you then must create a
webhook, which provides the mechanism to interface Prisma Cloud’s alert system with Cortex XDR . After you set up your webhook, Cortex XDR begins
receiving alerts from Prisma Cloud Compute.
Cortex XDR then groups these alerts into incidents and adds them to the Alerts table. When Cortex XDR 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 XDR to receive alerts from Prisma Cloud Compute.
1. Select Settings → Configurations → Data Collection → Collection Integrations.
2. In the Prisma Cloud Compute configuration, click Add Instance.
3. Specify the Name for the Prisma Cloud Compute Collector displayed in Cortex XDR.
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 Collection Integrations 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.
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 XDR, 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.
Displayed in the footer
Page 558 of 952
Cortex XDR Documentation
Displayed in the header
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.
Edit the Prisma Cloud Compute Collector settings.
Disable the Prisma Cloud Compute Collector.
Delete the Prisma Cloud Compute Collector.
8. After Cortex XDR 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 XDR 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.
16.3.4.5 | Ingest alerts from Prisma Cloud
Abstract
Configure Data Collection Settings in Cortex XDR to receive alerts from Prisma Cloud.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
To receive alerts from Prisma Cloud, first configure the Collection Integrations settings in Cortex XDR. After you set up collection integration, Cortex XDR begins
to receive alerts from Prisma Cloud every 30 seconds.
Cortex XDR then groups these alerts into incidents and adds them to the Alerts table. When Cortex XDR 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 XDR 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 XDR 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]. Prisma
Cloud System Admin privileges are required for this task.
Copy or download the Access Key ID and Secret Key as you will need them when configuring the Prisma Cloud Collector in Cortex XDR.
Configure Cortex XDR to receive alerts from Prisma Cloud.
1. Select Settings → Configurations → Data Collection → Collection Integrations.
2. In the Prisma Cloud Collector configuration, click Add Instance.
3. Set the following parameters.
Specify a Name to identify the connection.
Specify the Domain URL for Prisma Cloud.
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 create Cortex XDR alerts from the ingested Prisma Cloud alerts, click Advanced Settings, and select the desired options:
Incidents: Create Cortex XDR alerts for runtime alerts detected by Prisma Cloud.
Risks: Create Cortex XDR alerts for Prisma Cloud findings and vulnerabilities that could be exploited by threat actors.
5. Click Test to validate the connection, and then click Enable.
In Cortex XDR, once alerts start to come in, a green check mark appears underneath the Prisma Cloud Collector configuration with the amount of data
received.
6. (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.
Displayed in the footer
Page 559 of 952
Cortex XDR Documentation
Displayed in the header
Edit the Prisma Cloud Collector settings.
Disable the Prisma Cloud Collector.
Delete the Prisma Cloud Collector.
7. After Cortex XDR 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 XDR Alerts table, the Prisma Cloud alerts are listed as Prisma Cloud in the ALERT SOURCE column.
16.3.4.6 | Ingest detection data from Strata Logging Service
Abstract
Learn how to ingest detection data from Strata Logging Service.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
To streamline the connection and management of all Palo Alto Networks generated logs across products in Cortex XDR with a Strata Logging Service, Cortex
XDR can ingest detection data from Strata Logging Service in a more flexible manner 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 1 or more existing Strata
Logging Service.
Cortex XDR supports streaming data directly from Prisma Access accounts and New-Generation Firewalls (NGFW) and Panorama devices to your Cortex XDR
tenants using the Cortex Native Data Lake. Existing integrations should be migrated to the Cortex Native Data Lake. Make sure you select all your devices to
connect directly to Cortex XDR. Integrations not migrated manually will be migrated automatically 2 weeks before the end of the contract with Strata Logging
Service.
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 XDR can also raise Cortex XDR 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.
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 the Strata Logging Service.
You can configure Cortex XDR to take Palo Alto generated firewall logs from other Palo Alto Networks products already logging to an existing Strata
Logging Service.
2. Select Settings → Configurations → Data Collection → Collection Integrations.
3. In the Strata Logging Service configuration, click Add Instance.
4. Select Data Lake 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 XDR begins receiving data from a Strata Logging Service, you can use XQL Search to search for specific data, using the xdr_data
dataset.
16.3.4.7 | Ingest alerts and assets from IoT Security
Abstract
Ingest alerts and device data from IoT Security.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
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 XDR IoT Security integration enables you to ingest alerts and device
information from your IoT Security instance.
Displayed in the footer
Page 560 of 952
Cortex XDR Documentation
Displayed in the header
To receive data, configure the Collection Integrations settings in Cortex XDR for the IoT Security data collector in Settings → Configurations → Data Collection
→ Collection Integrations.
As soon as data collection begins, Cortex XDR displays the IoT Security alerts in the Cortex XDR 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 XDR table. Cortex XDR adds
device activities detected by IoT Security into the Cortex XDRCortex XDR Assets table. Device activities are updated every five minutes.
Cortex XDR 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 XDR.
1. Select Settings → Configurations → Data Collection → Collection Integrations.
2. In the IoT Security Collector configuration, click Add Instance.
3. Specify the following parameters.
Customer ID: Tenant domain part of the FQDN used for your IoT Security account. For example, in yourcorp.iot.paloaltonetworks.com,
the customer ID is yourcorp. The customer ID is unique and case sensitive. After you save the integration instance, you can't edit the Customer
ID.
Access Key and Key ID previously generated for the integration.
Integration Scope: Select at least one of the two values, Alerts and Devices depending on which information you want to ingest.
4. Click Test to validate access, and then click Enable.
When events start to come in, a green check mark appears underneath the IoT Security Collector configuration with the data and time that the data was
last synced.
5. (Optional) Manage your IOT Security Collector.
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 XDR 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.
16.3.4.8 | Collecting URL and File log types
Abstract
Learn about the implications of turning off or on collection of URL and File logs.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
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
Predefined dashboards.
You can turn on or off URL and File log types collection on the Collection Integrations page.
Displayed in the footer
Page 561 of 952
Cortex XDR Documentation
Displayed in the header
16.3.4.8.1 | Detectors connected to URL and File log types
Abstract
A list of detectors connected to URL and File log types.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
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.
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
16.3.5 | External data ingestion
Abstract
Cortex XDR supports external data ingestion for a variety of service types and vendors.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
Displayed in the footer
Page 562 of 952
Cortex XDR Documentation
Displayed in the header
Cortex XDR supports external data ingestion for a variety of service types and vendors.
16.3.5.1 | External applications
Abstract
Learn more about integrating Slack and a Syslog Receiver to Cortex XDR.
You can integrate the following external applications to manage notifications:
Slack: To send outbound notifications to Slack. For more information, see Integrate Slack for outbound notifications.
Syslog server: To send Cortex XDR notifications to your Syslog server. For more information, see Integrate a syslog receiver.
16.3.5.2 | Ingest network connection logs
Abstract
Cortex XDR can ingest network connection logs from different third-party sources.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
You can ingest network connection logs from different third-party sources.
16.3.5.2.1 | Ingest network flow logs from Amazon S3
Abstract
Take advantage of Cortex XDR investigation capabilities and set up network flow log ingestion for your Amazon S3 logs using an AWS CloudFormation Script.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
You can forward network flow logs to Cortex XDR 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 Collection Integrations
settings in Cortex XDR for Amazon S3. After you set up collection integration, Cortex XDR 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 XDR to receive network flow logs from Amazon S3 using SQS. To perform these
steps manually, see Configure Data Collection from Amazon S3 Manually.
For more information on configuring data collection from Amazon S3, see the Amazon S3 Documentation.
As soon as Cortex XDR 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 XDR to ingest network flow logs as Cortex XDR network connection stories, which you can query with XQL Search using the
xdr_data dataset with the preset called network_story. Cortex XDR can also raise Cortex XDR 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.
Displayed in the footer
Page 563 of 952
Cortex XDR Documentation
Displayed in the header
Ensure that you have the proper permissions to run AWS CloudFormation with the script provided in Cortex XDR. 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 XDR 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 XDR by selecting Access
Key.
Create an assumed role in AWS to delegate permissions to a Cortex XDR AWS service. This role grants Cortex XDR 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 XDR. For more information on creating an assumed role for Cortex XDR, 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 XDR 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 XDR to receive network flow logs from Amazon S3 using the CloudFormation Script.
1. Download the CloudFormation Script in Cortex XDR .
a. Select Settings → Configurations → Data Collection → Collection Integrations.
b. In the Amazon S3 configuration, click Add Instance.
c. To provide access to Cortex XDR 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 XDR.
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
XDR , 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.
Displayed in the footer
Page 564 of 952
Cortex XDR Documentation
Displayed in the header
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.
Displayed in the footer
Page 565 of 952
Cortex XDR Documentation
Displayed in the header
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, because you
will need to access information in the stack for other steps detailed below.
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.
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.
Displayed in the footer
Page 566 of 952
Cortex XDR Documentation
Displayed in the header
3. Configure the following Flow log settings:
Displayed in the footer
Page 567 of 952
Cortex XDR Documentation
Displayed in the header
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:
Displayed in the footer
Page 568 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR uses for API operations.
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 XDR.
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 XDR. If you forget to record the keys and close the window, you will
need to generate new keys and repeat this process.
For more information, see Managing access keys for IAM users.
5. When you create an Assumed Role in Cortex XDR, 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.
Displayed in the footer
Page 569 of 952
Cortex XDR Documentation
Displayed in the header
Skip this step if you are using an Access Key to provide access to Cortex XDR.
6. Configure the Amazon S3 collection in Cortex XDR.
a. Select Settings → Configurations → Data Collection → Collection Integrations.
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 XDR 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.
16.3.5.2.1.1 | Create an assumed role
Abstract
Learn about creating an AWS Assumed Role for Cortex XDR.
If you do not designate a separate AWS IAM user to provide access to Cortex XDR to your logs and to perform API operations, you can create an assumed
role in AWS to delegate permissions to a Cortex XDR AWS service. This role grants Cortex XDR access to your logs. For more information, see Creating a role
to delegate permissions to an AWS service.
When setting up any type of Amazon S3 Collector in Cortex XDR, these instructions explain setting up an Assumed Role.
1. Log in to the AWS Management Console to create a role for Cortex XDR.
Refer to the AWS instructions for guidance.
a. Create the role in the same region as your AWS account, and use the following values and options when creating the role.
Type of Trusted → Another AWS Account, and specify the Account ID as 006742885340. When using a Cortex XDR FedRAMP
environment, specify the Account ID as 685269782068.
Select Options for the Require external ID, which is a unique alphanumeric string, and generate a secure UUIDv4 using an Online UUID
Generator. Copy the External ID as you will use this when configuring the Amazon S3 Collector in Cortex XDR .
In AWS this is an optional field to configure, but this must be configured to set up the Amazon S3 Collector in Cortex XDR .
Do not enable MFA. Verify that Require MFA is not selected.
Displayed in the footer
Page 570 of 952
Cortex XDR Documentation
Displayed in the header
b. Click Next and add the AWS Managed Policy for Security Audit.
Displayed in the footer
Page 571 of 952
Cortex XDR Documentation
Displayed in the header
Then, add a role name and create the role. In this workflow, later, you will create the granular policies and edit the role to attach the additional
policies.
2. Create the policy that defines the permissions for the Cortex XDR role.
a. Select IAM on the AWS Management Console.
b. In the navigation pane on the left, select Access Management → Policies → Create Policy.
c. Select the JSON tab.
Copy the following JSON policy and paste it within the editor window.
The <s3-arn> and <sqs-arn> placeholders. These will be filled out later depending on which Amazon S3 logs you are configuring, including
network flow logs, audit logs, or generic logs.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "<s3-arn>/*"
},
{
"Effect": "Allow",
"Action": [
"sqs:ReceiveMessage",
"sqs:DeleteMessage",
"sqs:ChangeMessageVisibility"
],
"Resource": "<sqs-arn>"
}
]
}
d. Review and create the policy.
3. Edit the role you created in Step 1 and attach the policy to the role.
4. Copy the Role ARN.
5. Continue with the task for the applicable Amazon S3 logs you want to configure.
The following type of logs are available.
Ingest network flow logs from Amazon S3.
Ingest network Route 53 logs from Amazon S3
Ingest audit logs from AWS Cloud Trail.
Ingest generic logs from Amazon S3.
Displayed in the footer
Page 572 of 952
Cortex XDR Documentation
Displayed in the header
16.3.5.2.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).
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
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 XDR. 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 XDR 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 XDR to ingest network flow logs as Cortex XDR network connection stories, which you can query with XQL Search using the
xdr_dataset dataset with the preset called network_story. Cortex XDR can also raise Cortex XDR 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.
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.
It is your 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 XDR 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 XDR AWS service. This role grants Cortex XDR 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 XDR , 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 XDR 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 XDR 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.
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).
Ensure that you create your Amazon S3 bucket and Amazon SQS queue in the same region.
Displayed in the footer
Page 573 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR uses for API operations. For more information, see Managing access keys for IAM users.
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 XDR.
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.
Skip this step if you are using an Assumed Role for Cortex XDR.
8. Configure the Amazon S3 collection in Cortex XDR.
a. Select Settings → Configurations → Data Collection → Collection Integrations.
b. In the Amazon S3 configuration, click Add Instance.
c. Set these parameters, where the parameters change depending on whether you configured an Access Key or Assumed Role.
To provide access to Cortex XDR 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 XDR before continuing with these
instructions. In addition, when you create an Assumed Role for Cortex XDR, 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 XDR in AWS.
External Id: Specify the External Id for the Assumed Role for Cortex XDR 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 XDR ingests the network flow logs as Cortex
XDR 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.
16.3.5.2.2 | Ingest network Route 53 logs from Amazon S3
Abstract
Take advantage of Cortex XDR investigation capabilities and set up network Route 53 ingestion for your Amazon S3 logs using an AWS CloudFormation Script.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
You can forward network AWS Route 53 DNS logs to Cortex XDR 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 XDR for Amazon S3. After you set up collection integration, Cortex XDR 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 XDR to receive network Route 53 DNS logs from Amazon S3 using SQS.
For more information on configuring data collection from Amazon S3 for Route 53 DNS logs, see the AWS Documentation.
As soon as Cortex XDR 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
Displayed in the footer
Page 574 of 952
Cortex XDR Documentation
Displayed in the header
enhanced cloud protection, you can also configure Cortex XDR to ingest network Route 53 DNS logs as Cortex XDR network connection stories, which you
can query with XQL Search using the xdr_data dataset with the preset called network_story. Cortex XDR can also raise Cortex XDR 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.
Ensure that you have the proper permissions to run AWS CloudFormation with the script provided in Cortex XDR. 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 XDR 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 XDR AWS service. This role grants Cortex XDR 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 XDR. For more information on creating an assumed role for Cortex XDR, 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 XDR 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 XDR to receive network Route 53 DNS logs from Amazon S3 using the CloudFormation Script.
1. Download the CloudFormation Script in Cortex XDR.
a. Select Settings → Configurations → Data Collection → Collection Integrations.
b. In the Amazon S3 configuration, click Add Instance.
c. To provide access to Cortex XDR 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 XDR.
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
XDR , 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.
Displayed in the footer
Page 575 of 952
Cortex XDR Documentation
Displayed in the header
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.
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.
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 XDR uses for API operations.
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 XDR.
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 XDR. If you forget to record the keys and close the window, you will
need to generate new keys and repeat this process.
For more information, see Managing access keys for IAM users.
Displayed in the footer
Page 576 of 952
Cortex XDR Documentation
Displayed in the header
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.
Skip this step if you are using an Access Key to provide access to Cortex XDR.
6. Configure the Amazon S3 collection in Cortex XDR.
a. Select Settings → Configurations → Data Collection → Collection Integrations.
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 Cortex XDRin AWS.
External Id: Specify the External Id for the Assumed Role you created for Cortex XDR 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 XDR 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.
16.3.5.2.3 | Ingest logs from Check Point firewalls
Abstract
To take advantage of Cortex XDR investigation and detection capabilities while using Check Point firewalls, forward your firewall logs to Cortex XDR.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
If you use Check Point FW1/VPN1 firewalls, you can still take advantage of Cortex XDR investigation and detection capabilities by forwarding your Check Point
firewall logs to Cortex XDR. 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 XDR 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 XDR can also return raw data from Check Point firewalls in XQL queries.
Logs with sessionid = 0 are dropped.
Destination Port data is available only in the raw logs.
In terms of alerts, Cortex XDR can both surface native Check Point firewall alerts and raise its own alerts on network activity. Alerts are displayed throughout
Cortex XDR 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 XDR starts to receive logs, the app can begin stitching network connection logs with other logs to form network stories. Cortex XDR 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.
Displayed in the footer
Page 577 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR.
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.
16.3.5.2.4 | Ingest logs from Cisco ASA firewalls and AnyConnect
Abstract
Extend Cortex XDR visibility into logs from Cisco ASA firewalls and Cisco AnyConnect VPN.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
If you use Cisco ASA firewalls or Cisco AnyConnect VPN, you can take advantage of Cortex XDR investigation and detection capabilities by forwarding your
firewall and AnyConnect VPN logs to Cortex XDR. This enables Cortex XDR to examine your network traffic to detect anomalous behavior. Cortex XDR 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 XDR to collect and alert on endpoint data.
As soon as Cortex XDR starts to receive logs, the app can begin stitching network connection logs with other logs to form network stories. Cortex XDR 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 XDR.
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 XDR 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.
16.3.5.2.5 | Ingest logs from Corelight Zeek
Abstract
Extend Cortex XDR visibility into logs from Corelight Zeek.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
If you use Corelight Zeek sensors for network monitoring, you can still take advantage of Cortex XDR investigation and detection capabilities by forwarding
your network connection logs to Cortex XDR . This enables Cortex XDR to examine your network traffic to detect anomalous behavior. Cortex XDR 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 XDR to collect and alert on endpoint data.
As soon as Cortex XDR starts to receive logs, the app can begin stitching network connection logs with other logs to form network stories. Cortex XDR 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.
Displayed in the footer
Page 578 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR log storage. For
more information, see Manage Your Log Storage within Cortex XDR.
3. Forward logs to the Syslog Collector.
Cortex XDR can receive logs from Corelight Zeek sensors that use the Syslog export option of RFC5424 over TCP.
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.
16.3.5.2.6 | Ingest logs from Fortinet Fortigate firewalls
Abstract
Extend Cortex XDR visibility into logs from Fortinet Fortigate firewalls.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
If you use Fortinet Fortigate firewalls, you can still take advantage of Cortex XDR investigation and detection capabilities by forwarding your firewall logs to
Cortex XDR . This enables Cortex XDR to examine your network traffic to detect anomalous behavior. Cortex XDR 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 XDR to collect and alert on endpoint data.
As soon as Cortex XDR starts to receive logs, the app can begin stitching network connection logs with other logs to form network stories. Cortex XDR 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 XDR.
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
XDR 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.
16.3.5.2.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 XDR.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
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 XDR. Data from
GCP is then searchable in Cortex XDR to provide additional information and context to your investigations using the GCP Cortex Query Language (XQL)
Displayed in the footer
Page 579 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR to normalize different GCP logs as part of the enhanced cloud protection, which you can query with XQL Search using the
applicable dataset. Cortex XDR can also raise Cortex XDR 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 XDR 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 XDR 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.
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 XDR. The setup
process requires the subscription name and authentication key from your GCP instance.
After you set up log collection, Cortex XDR immediately begins receiving new logs and data from GCP.
Set up log forwarding using the GCP web interface
Displayed in the footer
Page 580 of 952
Cortex XDR Documentation
Displayed in the header
Displayed in the footer
Page 581 of 952
Cortex XDR Documentation
Displayed in the header
In Cortex XDR, set up Data Collection.
a. Select Settings → Configurations → Data Collection → Collection Integrations.
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.
Displayed in the footer
Page 582 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR ingests the
network flow logs as Cortex XDR 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 XDR 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.
For a Log Format set to CEF or LEEF, Cortex XDR 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 XDR 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 XDR
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 XDR 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 XDR 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 XDR 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 XDR ingests the Google Cloud DNS
logs as Cortex XDR 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.
1. Log in to your GCP account.
2. Set up log forwarding from GCP to Cortex XDR.
a. Select Logging → Logs Router.
Displayed in the footer
Page 583 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR, 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 XDR.
4. Create a service account and authentication key.
You will use the key to enable Cortex XDR to authenticate with the subscription service.
a. Select the menu icon, 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. After Cortex XDR begins receiving information from the GCP Pub/Sub service, you can use the XQL Query language to search for specific data.
Set up log forwarding using the GCP cloud shell terminal
Displayed in the footer
Page 584 of 952
Cortex XDR Documentation
Displayed in the header
Displayed in the footer
Page 585 of 952
Cortex XDR Documentation
Displayed in the header
In Cortex XDR, set up Data Collection.
a. Select Settings → Configurations → Data Collection → Collection Integrations.
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.
Displayed in the footer
Page 586 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR ingests the
network flow logs as Cortex XDR 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 XDR 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.
For a Log Format set to CEF or LEEF, Cortex XDR 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 XDR 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 XDR
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 XDR 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 XDR 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 XDR 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 XDR ingests the Google Cloud DNS
logs as Cortex XDR 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.
1. Launch the GCP cloud shell terminal or use your preferred shell with gcloud installed.
Displayed in the footer
Page 587 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR.
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 XDR 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 XDR 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. After Cortex XDR begins receiving information from the GCP Pub/Sub service, you can use the XQL Query language to search for specific data.
16.3.5.2.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 XDR authentication stories.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
Cortex XDR 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 settings in Cortex XDR based on your Microsoft Azure Event Hub configuration. After you set up data collection, Cortex
Displayed in the footer
Page 588 of 952
Cortex XDR Documentation
Displayed in the header
XDR begins receiving new logs and data from the source.
When Cortex XDR 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 XDR to normalize Azure Event Hub audit logs, including
Azure Kubernetes Service (AKS) audit logs, with other Cortex XDR 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 XDR to normalize, you can change the default
dataset. Cortex XDR can also raise Cortex XDR 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
Misconfiguration of Event Hub resources could cause ingestion delays.
In an existing Event Hub integration, do not change the mapping to a different Event Hub.
Do not use the same Event Hub for more than two purposes.
The following table provides a brief description of the different types of Azure audit logs you can collect.
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.
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 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 Microsoft 365 data collector, because it is easier to configure. In addition, ensure that you don't
configure both collectors to collect the same types of logs, because if you do so, you will be creating duplicate data in
Cortex XDR.
Resource logs, including Retrieves events related to operations that were performed within an Azure resource.
AKS audit logs
These logs are from the data plane.
Ensure that you do the following tasks before you begin configuring data collection from Azure Event Hub.
Before you set up an Azure Event Hub, calculate the quantity of data that you expect to send to Cortex XDR, taking into account potential data spikes
and potential increases in data ingestion, because partitions cannot be modified after creation. Use this information to ascertain the optimal number of
partitions and Throughput Units (for Azure Basic or Standard) or Processing Units (for Azure Premium). Configure your Event Hub accordingly.
Create an Azure Event Hub. We recommend using a dedicated Azure Event Hub for this Cortex XDR integration. For more information, see Quickstart:
Create an event hub using Azure portal.
Each partition can support a throughput of up to 1 MB/s.
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 XDR:
1. In the Microsoft Azure console, open the Event Hubs page, and select the Azure Event Hub that you created for collection in Cortex XDR.
2. Record the following parameters from your configured event hub, which you will need when configuring data collection in Cortex XDR.
Displayed in the footer
Page 589 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR 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 XDR.
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.
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:
Displayed in the footer
Page 590 of 952
Cortex XDR Documentation
Displayed in the header
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 Select from the list of applicable Azure AD Activity and Azure Sign-in Logs Categories, the ones that you want
logs and Azure Sign- to configure your designated resource to collect. You can select any of the following categories to collect these
in logs types of Azure logs.
Azure AD Activity logs:
AuditLogs
Azure Sign-in logs:
SignInLogs
NonInteractiveUserSignInLogs
ServicePrincipalSignInLogs
ManagedIdentitySignInLogs
ADFSSignInLogs
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 XDR.
a. Select Settings → Configurations → Data Collection → Collection Integrations.
b. In the Azure Event Hub configuration, click Add Instance to begin a new configuration.
c. Set these parameters.
Displayed in the footer
Page 591 of 952
Cortex XDR Documentation
Displayed in the header
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 storage account’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.
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.
For a Log Format set to CEF or LEEF, Cortex XDR 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 XDR 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 XDR 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.
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 XDR normalizes and enriches Azure Event Hub audit logs with other Cortex XDR 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.
When events start to come in, a green check mark appears underneath the Azure Event Hub configuration with the amount of data received.
16.3.5.2.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 XDR network stories.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
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 XDR. This Azure Function requires a token that is generated when you configure your Azure Network Watcher
Collector in Cortex XDR. After you have configured the Cortex XDR collector and successfully deployed the Azure Function to your Azure account, Cortex XDR
will start receiving and ingesting network flow logs from Azure Network Watcher.
Displayed in the footer
Page 592 of 952
Cortex XDR Documentation
Displayed in the header
The Azure Network Watcher Collector is deployed using an ARM template. During deployment, the template retrieves keys using the listKeys function, and
your app can bind to the blob storage using the connection string generated from those keys. After deployment, this binding works without the need to provide
any connection string manually, because the keys were already retrieved and injected during deployment.
In addition to the user-specified storage account that captures the log blobs, the template also creates a secondary, internal storage account for internal
operations related to the function app. This internal storage account is used by the function app for operations such as storing function state, and intermediate
processing. To enhance security, public network access is disabled, and the account is restricted to private endpoints only. This additional internal storage
account allows the function app to securely store data without relying on the user-specified storage account for internal processes. This separation enhances
data security and isolation between user-facing storage and internal application operations. VNet integration is required only for the internal storage account's
internal operations. The user-specified storage account used for NSG flow logs does not require VNet integration.
When Cortex XDR 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 XDR to ingest network flow logs as Cortex XDR network
connection stories, which you can query with XQL Search using the xdr_dataset dataset with the preset called network_story. Cortex XDR can also raise
Cortex XDR 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
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.
Ensure that you have an Azure subscription with user role permissions to deploy ARM templates and create the required resources.
The listKeys function in an Azure Resource Manager (ARM) template retrieves the storage account keys, and it requires special permissions to
execute. Specifically, the user or identity running the ARM template needs the following permission:
Microsoft.Storage/storageAccounts/listKeys/action. If the user or service principal running the ARM template has the necessary user role
(such as Owner or Storage Account Contributor), permission is implicitly granted for the template to retrieve the storage account keys.
Perform this procedure in the order shown below, because you need to save a token and a URL from Cortex XDR in earlier steps, and use them in Azure
in later steps.
1. Configure the Azure Network Watcher collection in Cortex XDR.
a. Select Settings → Configurations → Data Collection → Collection Integrations.
b. In the Azure Network Watcher configuration, click Add Instance to begin a new configuration.
c. Set these parameters:
Name: Specify a meaningful name for your log collection configuration.
Enhanced Cloud Protection: (Optional) For enhanced cloud protection, you can normalize and enrich flow logs by selecting the Use flow
logs in analytics checkbox. If selected, Cortex XDR ingests network flow logs as Cortex XDR network connection stories, which you can
query with XQL Search using the xdr_dataset dataset with the preset called network_story.
d. Click Save & Generate Token. The token is displayed in a popup.
Click the copy icon next to the key and save the copy of this token somewhere safe. You will need to provide this token when you configure the
Azure Function and set the Cortex Access Token value. If you forget to record the token and close the window, you will need to generate a new
one and repeat this process. When you are finished, click Done to close the window.
e. On the Integrations page for the Azure Network Watch Collector that you created, click the Copy API URL icon and save a copy of the URL
somewhere safe. You will need to provide this URL when you configure the Azure Function and set the Cortex Http Endpoint value.
2. Configure the Azure Function provided by Cortex XDR.
a. Open the Azure Function provided by Cortex XDR.
b. Click Deploy to Azure.
c. Log in to Azure, and if necessary, complete authentication procedures.
d. Set these parameters, where some fields are mandatory to set and others may already be populated for you.
Displayed in the footer
Page 593 of 952
Cortex XDR Documentation
Displayed in the header
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.
Unique Name: Enter a unique name for the function app. The name that you provide will be concatenated to some of the resource names, to
make it easier to locate the related resources later on. The name must only contain alphanumeric characters (letters and numbers, no
special symbols) and must contain no more than 10 characters.
Cortex Access Token: Cortex HTTP authorization key that you recorded when you configured the Azure Network Watcher collection in Cortex
XDR in an earlier step.
Target Storage Account Name: Enter the name of the Azure Storage Account that was created during the NSG flow logs setup in Azure
Network Watcher, where the log blobs are being stored.
Target Container Name: This field should be left empty for most use cases. The default value insights-logs-
networksecuritygroupflowevent is the name that is automatically created for the container during configuration of the network
watcher.
Location: The region where all the resources will be deployed (leave blank to use the same region as the resource group).
Cortex Http Endpoint: Specify the API URL that you recorded when you configured the Azure Network Watcher collection in Cortex XDR.
Remote Package: The URL of the remote package ZIP file containing the Azure Function code. Leave this field empty unless instructed
otherwise.
e. Click Review + Create to confirm your settings for the Azure Function.
f. Click Create. It can take a few minutes until the deployment is complete.
In addition to your storage account, the template automatically creates another storage account that is required by the function app for internal use only.
The internal storage account name is prefixed with cortex and is followed by a unique suffix based on the resource group, storage account, and
container names.
After events start to come in, a green check mark appears underneath the Azure Network Watcher configuration that you created in Cortex XDR, and the
amount of data received is displayed.
16.3.5.2.10 | Ingest logs and data from Okta
Abstract
Ingest authentication logs and data from Okta for use in Cortex XDR authentication stories.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
To receive logs and data from Okta, you must configure the Collection Integrations settings in Cortex XDR. After you set up data collection, Cortex XDR
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 XDR , 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 XDR:
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.
Displayed in the footer
Page 594 of 952
Cortex XDR Documentation
Displayed in the header
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 → Collection Integrations.
4. In the Okta configuration, click Add Instance.
5. Integrate the Okta authentication service with Cortex XDR.
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.
6. After Cortex XDR 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.
16.3.5.2.11 | Ingest logs from Windows DHCP using Elasticsearch Filebeat
Abstract
Learn how to configure Cortex XDR to receive Windows DHCP logs.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
You can configure Cortex XDR to receive Windows DHCP logs using Elasticsearch Filebeat with the following data collectors.
Ingest Windows DHCP logs with an XDR Collector profile
Abstract
Extend Cortex XDR visibility into logs from Windows DHCP using an XDR Collector Windows Filebeat profile.
Extend Cortex XDR 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 XDR 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).
Displayed in the footer
Page 595 of 952
Cortex XDR Documentation
Displayed in the header
While this enrichment is also available when configuring a Windows DHCP Collector for a cloud data collection integration, we recommend configuring Cortex
XDR to receive Windows DHCP logs with an XDR Collector Windows Filebeat profile because it’s the ideal setup configuration.
Configure Cortex XDR 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.
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 XDR visibility into logs from Windows DHCP using Elasticsearch Filebeat with the Windows DHCP data collector.
Extend Cortex XDR 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 XDR and installing and configuring an Elasticsearch Filebeat agent on your Windows DHCP Server. Cortex XDR 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
Collection Integrations settings in Cortex XDR for the Windows DHCP Collector. To help you configure the filebeat.yml correctly, Cortex XDR provides an
example file that you can download and customize. After you set up collection integration, Cortex XDR begins receiving new logs and data from the source.
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 XDR begins receiving logs, the app automatically creates a Windows DHCP XQL dataset (microsoft_dhcp_raw). Cortex XDR 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 XDR to receive logs from Windows DHCP via Elasticsearch Filebeat with the Windows DHCP collector.
1. Configure the Windows DHCP Collector in Cortex XDR.
a. Select Settings → Configurations → Data Collection → Collection Integrations.
b. In the Windows DHCP configuration, click Add Instance.
c. (Optional) Download example filebeat.yml file.
To help you configure your filebeat.yml file correctly, Cortex XDR provides an example filebeat.yml file that you can download and
customize. To download this file, use the link provided in this dialog box.
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 XDR. We
recommend that you use the download example file provided by Cortex XDR.
Displayed in the footer
Page 596 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR 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 XDR.
# ---------------------------- 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 XDR.
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 XDR 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).
16.3.5.2.12 | Ingest logs from Zscaler Internet Access
Abstract
Displayed in the footer
Page 597 of 952
Cortex XDR Documentation
Displayed in the header
Extend Cortex XDR visibility into logs from Zscaler Internet Access (ZIA).
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
If you use Zscaler Internet Access (ZIA) in your network, you can forward your firewall and network logs to Cortex XDR for analysis. This enables you to take
advantage of Cortex XDR anomalous behavior detection and investigation capabilities. Cortex XDR 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 XDR 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 XDR automatically maps the fields in your traffic
logs to the Cortex XDR log format.
As soon as Cortex XDR starts to receive logs, the app performs these actions.
Begins stitching network connection and firewall logs with other logs to form network stories. Cortex XDR 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 XDR 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.
Displayed in the footer
Page 598 of 952
Cortex XDR Documentation
Displayed in the header
Displayed in the footer
Page 599 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR. See Activate the Syslog Collector.
SIEM IP Address: Specify the IP that you set when activating the Syslog Collector in Cortex XDR. 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.
16.3.5.2.13 | Ingest logs from Zscaler Private Access
Abstract
Extend Cortex XDR visibility into logs from Zscaler Private Access (ZPA).
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
If you use Zscaler Private Access (ZPA) in your network as an alternative to VPNs, you can forward your network logs to Cortex XDR for analysis. This enables
you to take advantage of Cortex XDR anomalous behavior detection and investigation capabilities. Cortex XDR 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 XDR starts to receive logs, the following actions are performed:
Stitching network connection logs with other logs to form network stories. Cortex XDR 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 XDR automatically maps the fields in your traffic
logs to the Cortex XDR log format.
Displayed in the footer
Page 600 of 952
Cortex XDR Documentation
Displayed in the header
Prerequisite Step
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.
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 on the 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 XDR. See Activate Syslog Collector.
TCP Port: Specify the TCP port number used by the log receiver that you set when activating the Syslog Collector in Cortex XDR. See
Activate Syslog Collector.
TLS Encryption: Toggle to Enabled to encrypt traffic between the log receiver and your Syslog Collector in Cortex XDRusing 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:
Displayed in the footer
Page 601 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR:
You can only configure a ZPA log receiver to collect one type of log with your Syslog Collector in Cortex XDR. 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
Displayed in the footer
Page 602 of 952
Cortex XDR Documentation
Displayed in the header
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.
16.3.5.3 | Ingest authentication logs and data
Abstract
Ingest authentication logs from external authentication services—such as Okta and Azure AD—into authentication stories with Cortex XDR.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
When you ingest authentication logs and data from an external source, Cortex XDR 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 XDR can ingest authentication logs and data from various authentication services.
16.3.5.3.1 | Ingest audit logs from AWS Cloud Trail
Abstract
Take advantage of Cortex XDR investigation capabilities and set up audit log ingestion for your AWS CloudTrail logs.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
You can forward audit logs for the relative service to Cortex XDR 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 Collection Integrations settings in Cortex XDR for Amazon S3. After you set up collection integration, Cortex XDR begins receiving new logs
and data from the source.
For more information on configuring data collection from Amazon S3 using AWS CloudTrail, see the AWS CloudTrail Documentation.
As soon as Cortex XDR 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 XDR to stitch Amazon S3 audit logs with other Cortex XDR authentication stories across all
cloud providers using the same format, which you can query with XQL Search using the cloud_audit_logs dataset. Cortex XDR can also raise Cortex XDR
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.
Displayed in the footer
Page 603 of 952
Cortex XDR Documentation
Displayed in the header
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
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 XDR 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 XDR AWS service. This role grants Cortex XDR 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 XDR 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 XDR 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.
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.
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.
The CloudWatch Logs - optional settings are not supported and should be left disabled.
c. Click Next, and configure the following Choose log events settings.
Displayed in the footer
Page 604 of 952
Cortex XDR Documentation
Displayed in the header
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).
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.
Displayed in the footer
Page 605 of 952
Cortex XDR Documentation
Displayed in the header
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.
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.
Displayed in the footer
Page 606 of 952
Cortex XDR Documentation
Displayed in the header
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.
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 XDR uses for API operations.
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 XDR.
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 XDR. If you forget to record the keys and close the window, you will
need to generate new keys and repeat this process.
For more information, see Managing access keys for IAM users.
7. Update the Access policy of your Amazon SQS queue.
Skip this step if you are using an Assumed Role for Cortex XDR.
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:
Displayed in the footer
Page 607 of 952
Cortex XDR Documentation
Displayed in the header
“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”.
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 XDR.
a. Select Settings → Configurations → Data Collection → Collection Integrations.
b. In the Amazon S3 configuration, click Add Instance.
c. Set these parameters, where the parameters change depending on whether you configured an Access Key or Assumed Role.
To provide access to Cortex XDR 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 XDR before continuing with these
instructions. In addition, when you create an Assumed Role for Cortex XDR, 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 XDR stitches Amazon S3 audit logs with other
Cortex XDR 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.
Displayed in the footer
Page 608 of 952
Cortex XDR Documentation
Displayed in the header
16.3.5.3.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 XDR authentication stories.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
Cortex XDR 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 settings in Cortex XDR based on your Microsoft Azure Event Hub configuration. After you set up data collection, Cortex
XDR begins receiving new logs and data from the source.
When Cortex XDR 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 XDR to normalize Azure Event Hub audit logs, including
Azure Kubernetes Service (AKS) audit logs, with other Cortex XDR 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 XDR to normalize, you can change the default
dataset. Cortex XDR can also raise Cortex XDR 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
Misconfiguration of Event Hub resources could cause ingestion delays.
In an existing Event Hub integration, do not change the mapping to a different Event Hub.
Do not use the same Event Hub for more than two purposes.
The following table provides a brief description of the different types of Azure audit logs you can collect.
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.
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 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 Microsoft 365 data collector, because it is easier to configure. In addition, ensure that you don't
configure both collectors to collect the same types of logs, because if you do so, you will be creating duplicate data in
Cortex XDR.
Resource logs, including Retrieves events related to operations that were performed within an Azure resource.
AKS audit logs
These logs are from the data plane.
Ensure that you do the following tasks before you begin configuring data collection from Azure Event Hub.
Before you set up an Azure Event Hub, calculate the quantity of data that you expect to send to Cortex XDR, taking into account potential data spikes
and potential increases in data ingestion, because partitions cannot be modified after creation. Use this information to ascertain the optimal number of
partitions and Throughput Units (for Azure Basic or Standard) or Processing Units (for Azure Premium). Configure your Event Hub accordingly.
Create an Azure Event Hub. We recommend using a dedicated Azure Event Hub for this Cortex XDR integration. For more information, see Quickstart:
Create an event hub using Azure portal.
Each partition can support a throughput of up to 1 MB/s.
Ensure the format for the logs you want collected from the Azure Event Hub is either JSON or raw.
Displayed in the footer
Page 609 of 952
Cortex XDR Documentation
Displayed in the header
Configure the Azure Event Hub collection in Cortex XDR:
1. In the Microsoft Azure console, open the Event Hubs page, and select the Azure Event Hub that you created for collection in Cortex XDR.
2. Record the following parameters from your configured event hub, which you will need when configuring data collection in Cortex XDR.
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 XDR 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 XDR.
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.
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:
Displayed in the footer
Page 610 of 952
Cortex XDR Documentation
Displayed in the header
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 Select from the list of applicable Azure AD Activity and Azure Sign-in Logs Categories, the ones that you want
logs and Azure Sign- to configure your designated resource to collect. You can select any of the following categories to collect these
in logs types of Azure logs.
Azure AD Activity logs:
AuditLogs
Azure Sign-in logs:
SignInLogs
NonInteractiveUserSignInLogs
ServicePrincipalSignInLogs
ManagedIdentitySignInLogs
ADFSSignInLogs
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 XDR.
a. Select Settings → Configurations → Data Collection → Collection Integrations.
b. In the Azure Event Hub configuration, click Add Instance to begin a new configuration.
c. Set these parameters.
Displayed in the footer
Page 611 of 952
Cortex XDR Documentation
Displayed in the header
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 storage account’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.
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.
For a Log Format set to CEF or LEEF, Cortex XDR 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 XDR 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 XDR 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.
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 XDR normalizes and enriches Azure Event Hub audit logs with other Cortex XDR 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.
When events start to come in, a green check mark appears underneath the Azure Event Hub configuration with the amount of data received.
16.3.5.3.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 XDR.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
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 XDR. Data from
GCP is then searchable in Cortex XDR 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.
Displayed in the footer
Page 612 of 952
Cortex XDR Documentation
Displayed in the header
You can also configure Cortex XDR to normalize different GCP logs as part of the enhanced cloud protection, which you can query with XQL Search using the
applicable dataset. Cortex XDR can also raise Cortex XDR 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 XDR 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 XDR 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.
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 XDR. The setup
process requires the subscription name and authentication key from your GCP instance.
After you set up log collection, Cortex XDR immediately begins receiving new logs and data from GCP.
Set up log forwarding using the GCP web interface
Displayed in the footer
Page 613 of 952
Cortex XDR Documentation
Displayed in the header
Displayed in the footer
Page 614 of 952
Cortex XDR Documentation
Displayed in the header
In Cortex XDR, set up Data Collection.
a. Select Settings → Configurations → Data Collection → Collection Integrations.
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.
Displayed in the footer
Page 615 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR ingests the
network flow logs as Cortex XDR 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 XDR 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.
For a Log Format set to CEF or LEEF, Cortex XDR 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 XDR 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 XDR
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 XDR 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 XDR 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 XDR 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 XDR ingests the Google Cloud DNS
logs as Cortex XDR 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.
1. Log in to your GCP account.
2. Set up log forwarding from GCP to Cortex XDR.
a. Select Logging → Logs Router.
Displayed in the footer
Page 616 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR, 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 XDR.
4. Create a service account and authentication key.
You will use the key to enable Cortex XDR to authenticate with the subscription service.
a. Select the menu icon, 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. After Cortex XDR begins receiving information from the GCP Pub/Sub service, you can use the XQL Query language to search for specific data.
Set up log forwarding using the GCP cloud shell terminal
Displayed in the footer
Page 617 of 952
Cortex XDR Documentation
Displayed in the header
Displayed in the footer
Page 618 of 952
Cortex XDR Documentation
Displayed in the header
In Cortex XDR, set up Data Collection.
a. Select Settings → Configurations → Data Collection → Collection Integrations.
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.
Displayed in the footer
Page 619 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR ingests the
network flow logs as Cortex XDR 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 XDR 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.
For a Log Format set to CEF or LEEF, Cortex XDR 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 XDR 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 XDR
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 XDR 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 XDR 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 XDR 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 XDR ingests the Google Cloud DNS
logs as Cortex XDR 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.
1. Launch the GCP cloud shell terminal or use your preferred shell with gcloud installed.
Displayed in the footer
Page 620 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR.
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 XDR 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 XDR 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. After Cortex XDR begins receiving information from the GCP Pub/Sub service, you can use the XQL Query language to search for specific data.
16.3.5.3.4 | Ingest logs and data from Google Workspace
Abstract
Ingest logs and data from Google Workspace for use in Cortex XDR.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
Cortex XDR 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.
Displayed in the footer
Page 621 of 952
Cortex XDR Documentation
Displayed in the header
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).
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 steps below and then enable
the Google Workspace Gmail API. Once implemented, you can then configure the Collection Integrations settings in Cortex XDR. After you set up data
collection, Cortex XDR begins receiving new logs and data from the source.
When Cortex XDR 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 XDR can raise Cortex XDR 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
Admin google_workspace_admin_console_raw Google Workspace When relevant, Cortex XDR normalizes Admin Console
console Admin audit logs into authentication stories. All SaaS audit logs
Console 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_chat_raw Google Workspace —
Chat Chat
Displayed in the footer
Page 622 of 952
Cortex XDR Documentation
Displayed in the header
Data Type Dataset Vendor Product Normalized Data
Enterprise google_workspace_enterprise_groups_raw Google Workspace When relevant, Cortex XDR normalizes Enterprise Group
groups Enterprise audit logs into authentication stories. All SaaS audit logs
Groups 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.
Login google_workspace_login_raw Google Workspace When relevant, Cortex XDR 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 XDR 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 XDR normalizes Google drive
Drive Drive audit 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 XDR 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 XDR 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
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.
Displayed in the footer
Page 623 of 952
Cortex XDR Documentation
Displayed in the header
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 admin@organization.com.
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).
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.
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 menu icon → 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.
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.
Displayed in the footer
Page 624 of 952
Cortex XDR Documentation
Displayed in the header
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, because 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 XDR.
b. When collecting alerts, enable the Alert Center API to create a service account and set credentials for this service account.
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 two 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 menu icon → 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
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.
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 menu icon → 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.
Displayed in the footer
Page 625 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR .
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://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
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.
Displayed in the footer
Page 626 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR.
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 XDR .
6. In Cortex XDR, select Settings → Configurations → Data Collection → Collection Integrations.
7. In the Google Workspace configuration, click Add Instance to begin a new configuration.
8. Integrate the applicable Google Workspace service with Cortex XDR.
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.
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).
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.
Displayed in the footer
Page 627 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR then tests the connection settings for the selected log types.
e. If successful, Enable Google Workspace log collection.
16.3.5.3.5 | Ingest logs and data from Microsoft 365
Abstract
The Microsoft 365 email collector fetches emails through Microsoft Graph API, using an authorized app. A compliance mailbox is not required.
The Microsoft 365 email collector fetches emails through Microsoft Graph API, using an authorized app. A compliance mailbox is not required.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
A user account with the Microsoft Azure Account Administrator role is required to set up a new Microsoft 365 email collector.
The following Microsoft Graph API permissions are required:
Mailbox access (read-write)
Read and write mail in all mailboxes
Read contacts in all mailboxes
Read all user mailbox settings
User information, groups, and directory data (read-only)
Read directory data
Read all groups
Read all users' full profiles
The Microsoft 365 collector ingests emails and attachment metadata, including email subject and body. Attachment metadata includes data such as name,
type, size, and hash. The actual attached files are not saved.
You can narrow down the scope of ingested mailboxes by:
Microsoft 365 Group
Distribution List
Mail-enabled Security Group
Mail-enabled Users
Datasets
The Microsoft 365 collector ingests data into the following datasets:
msft_o365_emails_raw
msft_o365_users_raw
msft_o365_groups_raw
msft_o365_devices_raw
msft_o365_mailboxes_raw
msft_o365_rules_raw
Encryption
Cortex XDR stores email metadata as plain text, and encrypts emails' subject and body. The email body is saved for 48 hours, and then deleted. Analytical
detectors analyze raw and encrypted email data, and when necessary, create alerts. When an alert is created for a malicious email, the raw email, include its
subject and body (decrypted), is attached to the alert as an artifact. Therefore, you will not be able to perform threat hunting based on email subject and body.
Only email metadata such as date, From, or To, are available for threat hunting purposes.
Displayed in the footer
Page 628 of 952
Cortex XDR Documentation
Displayed in the header
Configure ingestion into Cortex XDR
1. On the Collection Integrations page, locate Microsoft 365, and select Add Instance to begin a new connection.
2. In the wizard that opens, ensure that you have configured the items listed on the Permissions page, and then click Next.
3. To confirm that you know that API authorization consent is required, click OK.
4. Select the Microsoft account from which you want to collect email data.
5. Click Next.
6. Enter your password for the Microsoft account, and click Sign in.
7. If you are asked to perform authentication using your organization's authentication tools, do so.
8. For the list of of permissions that Cortex Email Security requires, click Accept.
9. On the Scope page, select one of the following:
Entire organization: Emails will be collected from all mailboxes in your organization.
Specific groups: Enter the email addresses of group names, such as Microsoft 365 Groups, Mail-enabled Security Groups, Distribution Lists, or
Mail-enabled Users.
10. Click Next.
11. On the Details page, enter a meaningful instance name, and click Next.
12. On the Summary page, check your configurations, and then click Create.
After data starts to come in, a green check mark appears below the Microsoft 365 configuration, along with the amount of data received.
16.3.5.3.6 | Ingest logs from Microsoft Office 365
Abstract
Ingest logs and data from Microsoft Office 365 Management Activity API and Microsoft Graph API for use in Cortex XDR.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
Ingesting Microsoft Entra ID (formerly known as Azure AD) authentication and audit events from Microsoft Graph API requires a Microsoft Azure Premium 1 or
Premium 2 license. Alternatively, if the directory type is Azure AD B2C, the sign-in reports are accessible through the API without any additional license
requirement.
Cortex XDR can ingest the following logs and data from Microsoft Office 365 Management Activity API and Microsoft Graph API using the Office 365 data
collector. Alerts are collected with a delay of 5 minutes. If your organization requires collection that is closer to real-time collection, we recommend using the
Microsoft Azure Event Hub integration instead.
To ingest email logs and data from Microsoft Office 365, use the dedicated data collector. For more information, see Ingest logs and data from Microsoft 365.
Displayed in the footer
Page 629 of 952
Cortex XDR Documentation
Displayed in the header
Microsoft Office 365 audit events from Management Activity API, which provides information about various user, administrator, system, and policy actions
and events from Office 365, Microsoft Entra ID (formerly known as Azure AD) and MDO activity logs.
When auditing is turned off from the default setting, you need to first turn on auditing for your organization to collect Microsoft Office 365 audit events
from the Management Activity API. Log duplication of up to 5% in Microsoft products is considered normal. In some cases, such as login to a portal
using MFA, two log entries are recorded by design.
Microsoft Entra ID (Azure AD) authentication and audit events from Microsoft Graph API.
When collecting Azure AD Authentication Logs, Cortex XDR also collects by default all sign-in event types from a beta version of Microsoft Graph API,
which is still subject to change. In addition to classic interactive user sign-ins, selecting this option allows you to collect.
Non-interactive user sign-ins.
Service principal sign-ins.
Managed Identities for Azure resource sign-ins.
To address Azure reporting latency, there is a 10-minute latency period for Cortex XDR to receive Azure AD logs.
Microsoft 365 alerts from Microsoft Graph Security API are available for different products.
Microsoft Graph Security API v1: Alerts from the following products are available via the Microsoft Graph Security API v1:
Microsoft Defender for Cloud, Azure Active Directory Identity Protection, Microsoft Defender for Cloud Apps, Microsoft Defender for
Endpoint, Microsoft Defender for Identity, Microsoft 365, Azure Information Protection, and Azure Sentinel.
Microsoft Graph Security API v2: Alerts (alerts_v2) from the following products are available via the Microsoft Graph Security API v2 beta version,
which is still subject to change:
Microsoft 365 Defender unified alerts API, which serves alerts from Microsoft 365 Defender, Microsoft Defender for Endpoint, Microsoft
Defender for Office 365, Microsoft Defender for Identity, Microsoft Defender for Cloud Apps, and Microsoft Purview Data Loss Prevention
(including any future new signals integrated into M365D).
To view alerts from the various products via the Microsoft Graph Security API versions, you need to ensure that you've set up the applicable licenses in
Office 365. The table below lists the various licenses required for the different Microsoft Defender products. For more information on other Microsoft
product licenses, see the Microsoft documentation.
Product Standalone License E3 License E3 + Security Add-On License E5 License E5 Security License E5 Compliance Licence
Microsoft ✓ ✓ ✓ — — —
Defender
for
Endpoint
Plan 1
Microsoft — — ✓ ✓ ✓ —
Defender
for
Endpoint
Plan 2
Microsoft — — ✓ ✓ ✓ —
Defender
for
Identity
Microsoft ✓ — — — — —
Defender
for Office
365 Plan
1
Displayed in the footer
Page 630 of 952
Cortex XDR Documentation
Displayed in the header
Product Standalone License E3 License E3 + Security Add-On License E5 License E5 Security License E5 Compliance Licence
Microsoft ✓ — ✓ ✓ ✓ —
Defender
for Office
365 Plan
2
Microsoft — — ✓ ✓ ✓ ✓
Defender
for Cloud
Apps
For more information, see the Office 365 Management Activity API schema.
To receive logs from Microsoft Office 365, you must first configure the Collection Integrations settings in Cortex XDR. After you set up data collection, Cortex
XDR begins receiving new logs and data from the source.
When Cortex XDR begins receiving logs, the app creates a new dataset for the different types of logs and 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 Microsoft Office 365 logs, Cortex XDR can also raise Cortex XDR
alerts (Analytics, IOC, BIOC, and Correlation Rules) when relevant from Office 365 logs. While Correlation Rules alerts are raised on non-normalized and
normalized logs, Analytics, IOC, and BIOC alerts are only raised on normalized logs.
For the different types of data you can collect using the Office 365 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
Microsoft Office 365 audit events from Management Activity API
Microsoft Entra ID msft_o365_azure_ad_raw msft O365 Azure —
(Azure AD) AD
Exchange Online msft_o365_exchange_online_raw msft O365 Cortex XDR supports normalizing Exchange
Exchange Online audit logs into stories, which are
Online collected in a dataset called
saas_audit_logs*.
SharePoint Online msft_o365_sharepoint_online_raw msft O365 Cortex XDR supports normalizing SharePoint
Sharepoint Online audit logs into stories, which are
Online collected in a dataset called
saas_audit_logs*.
DLP msft_o365_dlp_raw msft O365 DLP —
General msft_o365_general_raw msft O365 General Cortex XDR supports normalizing General
audit logs into stories, which are collected in
a dataset called saas_audit_logs*.
Microsoft Entra ID (Azure msft_azure_ad_raw msft Azure AD When relevant, Cortex XDR normalizes Azure
AD) authentication events AD authentication logs and Azure AD Sign-in
from Microsoft Graph API logs to authentication stories.
Displayed in the footer
Page 631 of 952
Cortex XDR Documentation
Displayed in the header
Data Type Dataset Vendor Product Normalized Data
Microsoft Entra ID (Azure msft_azure_ad_audit_raw msft Azure AD When relevant, Cortex XDR normalizes Azure
AD) audit events from Audit AD audit logs to cloud audit logs stories.
Microsoft Graph API
Alerts from Microsoft Graph msft_graph_security_alerts_raw msft Security —
Security API v1 and v2 Alerts
*Note: For the saas_audit_logs dataset, the Vendor is saas and Product is Audit Logs.
In FedRAMP environments, Azure sign-in logs are not supported, due to vendor technical constraints.
To set up the Office 365 integration:
1. From the Microsoft Entra ID console (formerly Azure AD console), create an app for Cortex XDR with the applicable API permissions for the logs and
data you want to collect as detailed in the following table.
Log Type And Data API/Permission Name
Microsoft Office 365 audit events from Management Activity API
-Azure AD Office 365 Management APIs → ActivityFeed.Read
-Exchange Online Office 365 Management APIs → ActivityFeed.Read
-Sharepoint Online Office 365 Management APIs → ActivityFeed.Read
-DLP Office 365 Management APIs → ActivityFeed.ReadDlp
-General Office 365 Management APIs → ActivityFeed.Read
Microsoft Office 365 emails via Microsoft’s Graph API Microsoft Graph → Mail.ReadWrite
Azure AD authentication and audit events from Microsoft Graph API Microsoft Graph → AuditLog.Read.All
Microsoft Graph → Directory.Read.All
Alerts from Microsoft Graph Security API v1 and v2 Microsoft Graph → SecurityAlert.Read.All
Microsoft Graph → SecurityEvents.Read.All
For more information on Microsoft Azure, see the following instructions in the Microsoft documentation portal.
Register an app.
Add API permissions with type Application.
Create an application secret.
2. In Cortex XDR, select Settings → Configurations → Data Collection → Collection Integrations.
3. In the Office 365 configuration, click Add Instance.
4. Integrate the applicable Microsoft Entra ID (Azure AD) service with Cortex XDR.
a. Specify the Tenant Domain of your Microsoft Entra ID tenant.
Displayed in the footer
Page 632 of 952
Cortex XDR Documentation
Displayed in the header
b. Obtain the Application Client ID and Secret for your Microsoft Entra ID (Azure AD) service from the Microsoft Entra ID console, and specify the
values in Cortex XDR.
These values enable Cortex XDR to authenticate with your Microsoft Entra ID (Azure AD) service.
c. Select the types of logs that you want to receive from Office 365.
The following options are available.
Office 365 Management Activity API
Azure AD: Includes subset of Azure AD audit events and Azure AD authentication events. There can be significant overlap between
these and the Azure AD Authentication Logs originating from Microsoft Graph API.
Use this option when you don’t want to grant permissions for Azure AD Authentication and Azure AD Audit.
Exchange Online: Includes audit logs on Azure Exchange mailboxes and Exchange admin activities on the Office 365 Exchange.
Sharepoint Online: Includes audit events on Sharepoint and OneDrive activities.
DLP: Includes Microsoft 365 DLP events for Exchange, Sharepoint, and OneDrive.
General: Includes audit logs for various Microsoft 365 applications, such as Power BI and Microsoft Forms.
Microsoft Graph API
Azure AD Authentication Logs and Collect all sign-in event types: Azure AD Sign-in logs includes by default all sign-in event types
from a beta version of Microsoft Graph API, which is still subject to change. In addition to classic interactive user sign-ins, selecting the
Collect all sign-in event types allows you to collect.
-Non-interactive user sign-ins.
-Service principal sign-ins.
-Managed Identities for Azure resource sign-ins.
Azure AD Audit Logs: Azure AD Audit logs includes different categories, such as User Management, Group Management and
Application Management.
Alerts: When this checkbox is selected, alerts from the following products are collected via the Microsoft Graph Security API v1:
Microsoft Defender for Cloud, Azure Active Directory Identity Protection, Microsoft Defender for Cloud Apps, Microsoft Defender
for Endpoint, Microsoft Defender for Identity, Microsoft 365, Azure Information Protection, and Azure Sentinel.
Use Microsoft Graph API v2: When this checkbox is also selected, alerts (alerts_v2) from the following products are only
collected via the Microsoft Graph Security API v2 beta version, which is still subject to change:
Microsoft 365 Defender unified alerts API, which serves alerts from Microsoft 365 Defender, Microsoft Defender for
Endpoint, Microsoft Defender for Office 365, Microsoft Defender for Identity, Microsoft Defender for Cloud Apps, and
Microsoft Purview Data Loss Prevention (including any future new signals integrated into M365D).
Emails: Deprecated. Use the dedicated email collector instead. For more information, see Ingest logs and data from Microsoft 365.
d. Test the connection settings.
To test the connection, you must select one or more log types. Cortex XDR then tests the connection settings for the selected log types.
e. If successful, Enable Office 365 log collection.
16.3.5.3.7 | Ingest logs and data from Okta
Abstract
Ingest authentication logs and data from Okta for use in Cortex XDR authentication stories.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
To receive logs and data from Okta, you must configure the Collection Integrations settings in Cortex XDR. After you set up data collection, Cortex XDR
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 XDR , 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.
Displayed in the footer
Page 633 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR:
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 → Collection Integrations.
4. In the Okta configuration, click Add Instance.
5. Integrate the Okta authentication service with Cortex XDR.
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.
6. After Cortex XDR 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.
16.3.5.3.8 | Ingest logs and data from OneLogin
Abstract
Learn how to ingest different types of logs and data from OneLogin.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
Cortex XDR can ingest different types of data from OneLogin accounts using the OneLogin data collector.
Displayed in the footer
Page 634 of 952
Cortex XDR Documentation
Displayed in the header
To receive logs and data from OneLogin via the OneLogin REST APIs, you must configure the Collection Integrations settings in Cortex XDR based on your
OneLogin credentials. After you set up data collection, Cortex XDR begins receiving new logs and data from the source.
When Cortex XDR 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 XDR can raise Cortex XDR 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.
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 XDR 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 XDR to access the OneLogin account and generate the OAuth 2.0
access token.
A Cortex XDR user account with permissions to Read Log Collections, for example an Instance Administrator.
Configure Cortex XDR 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 XDR .
4. Select Settings → Configurations → Data Collection → Collection Integrations.
5. In the OneLogin configuration, click Add Instance.
6. Configure the following parameters.
Displayed in the footer
Page 635 of 952
Cortex XDR Documentation
Displayed in the header
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.
Event data is collected every 30 seconds.
Directory
Users: Retrieves lists of users.
Groups: Retrieves lists of groups.
Apps: Retrieves lists of apps.
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.
16.3.5.3.9 | Ingest authentication logs from PingFederate
Abstract
Ingest authentication logs and data from PingFederate for use in Cortex XDR authentication stories.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
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 XDR to receive the logs. After you set up log collection, Cortex XDR immediately begins receiving new authentication logs from the source.
Cortex XDR 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.
16.3.5.3.10 | Ingest authentication logs and data from PingOne
Abstract
Ingest authentication logs and data from PingOne for Enterprise for use in Cortex XDR authentication stories.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
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 XDR. After you set up collection integration, Cortex XDR immediately begins receiving new authentication logs and data from the
source. These logs and data are then searchable in Cortex XDR.
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.
Displayed in the footer
Page 636 of 952
Cortex XDR Documentation
Displayed in the header
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 → Collection Integrations.
3. In the PingOne configuration, click Add Instance.
4. Connect Cortex XDR 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 XDR begins receiving information from the authentication service. From the Integrations page, you can view the
log collection summary.
5. To search for specific authentication logs or data, you can Create an Authentication Query or Create an XQL Query.
16.3.5.4 | Ingest operation and system logs from cloud providers
Abstract
Learn how to ingest operation and system logs from supported cloud providers into Cortex XDR.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
You can ingest operation and system logs from supported cloud providers into Cortex XDR.
16.3.5.4.1 | Ingest generic logs from Amazon S3
Abstract
Take advantage of Cortex XDR investigation capabilities and set up generic log ingestion for your Amazon S3 logs.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
You can forward generic logs for the relative service to Cortex XDR 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 Collection Integrations settings in Cortex XDR for Amazon S3. After you set up collection integration, Cortex XDR begins receiving new logs and data from
the source.
For more information on configuring data collection from Amazon S3, see the Amazon S3 Documentation.
As soon as Cortex XDR 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 XDR can also raise Cortex XDR alerts (Correlation Rules only) when relevant from Amazon S3 logs.
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.
Displayed in the footer
Page 637 of 952
Cortex XDR Documentation
Displayed in the header
Prerequisites
Perform the following tasks before you begin configuring data collection from Amazon S3:
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.
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 XDR 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 XDR AWS service. This role grants Cortex XDR 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 XDR. For more information on creating an assumed role for Cortex XDR, 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 XDR 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 XDR 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).
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.
Displayed in the footer
Page 638 of 952
Cortex XDR Documentation
Displayed in the header
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.
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:
Displayed in the footer
Page 639 of 952
Cortex XDR Documentation
Displayed in the header
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.
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.
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 XDR.
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 XDR. If you forget to record the keys and close the window, you will
need to generate new keys and repeat this process.
For more information, see Managing access keys for IAM users.
6. Update the Access policy of your Amazon SQS queue.
Skip this step if you are using an Assumed Role for Cortex XDR.
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.
Displayed in the footer
Page 640 of 952
Cortex XDR Documentation
Displayed in the header
“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”.
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 XDR.
a. Select Settings → Configurations → Data Collection → Collection Integrations.
b. In the Amazon S3 configuration, click Add Instance.
c. Set these parameters, where the parameters change depending on whether you configured an Access Key or Assumed Role.
Displayed in the footer
Page 641 of 952
Cortex XDR Documentation
Displayed in the header
To provide access to Cortex XDR 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 XDR before continuing with these
instructions. In addition, when you create an Assumed Role for Cortex XDR, 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 XDR in AWS.
External Id: Specify the External Id for the Assumed Role you created for Cortex XDR 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.
-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 XDR 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 XDR 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 XDR 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 are 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 XDR 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 XDR 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 XDR 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.
Displayed in the footer
Page 642 of 952
Cortex XDR Documentation
Displayed in the header
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.
16.3.5.4.2 | Ingest logs from Amazon CloudWatch
Abstract
Take advantage of Cortex XDR investigation capabilities and set up generic or EKS log ingestion for your Amazon CloudWatch logs.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
You can forward generic and Elastic Kubernetes Service (EKS) logs to Cortex XDR 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 XDR to provide additional information and context to your
investigations.
As soon as Cortex XDR 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 XDR to normalize EKS audit logs, which you can query with XQL Search using the cloud_audit_logs dataset. Cortex XDR can also
raise Cortex XDR 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 XDR.
a. Select Settings → Configurations → Data Collection → Collection Integrations.
b. In the Amazon CloudWatch configuration, click Add Instance.
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:
Displayed in the footer
Page 643 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR , 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 XDR 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 XDR 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 XDR.
HTTP endpoint URL: Copy the API URL associated with your log collection from the Cortex XDR 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 XDR 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
XDR integration.
Displayed in the footer
Page 644 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR begins receiving logs from your Amazon services, you can use the XQL Search to search for logs in the new dataset.
16.3.5.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 XDR.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
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 XDR. Data from
GCP is then searchable in Cortex XDR 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 XDR to normalize different GCP logs as part of the enhanced cloud protection, which you can query with XQL Search using the
applicable dataset. Cortex XDR can also raise Cortex XDR 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
Displayed in the footer
Page 645 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR 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 XDR 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.
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 XDR. The setup
process requires the subscription name and authentication key from your GCP instance.
After you set up log collection, Cortex XDR immediately begins receiving new logs and data from GCP.
Set up log forwarding using the GCP web interface
Displayed in the footer
Page 646 of 952
Cortex XDR Documentation
Displayed in the header
Displayed in the footer
Page 647 of 952
Cortex XDR Documentation
Displayed in the header
In Cortex XDR, set up Data Collection.
a. Select Settings → Configurations → Data Collection → Collection Integrations.
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.
Displayed in the footer
Page 648 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR ingests the
network flow logs as Cortex XDR 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 XDR 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.
For a Log Format set to CEF or LEEF, Cortex XDR 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 XDR 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 XDR
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 XDR 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 XDR 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 XDR 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 XDR ingests the Google Cloud DNS
logs as Cortex XDR 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.
1. Log in to your GCP account.
2. Set up log forwarding from GCP to Cortex XDR.
a. Select Logging → Logs Router.
Displayed in the footer
Page 649 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR, 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 XDR.
4. Create a service account and authentication key.
You will use the key to enable Cortex XDR to authenticate with the subscription service.
a. Select the menu icon, 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. After Cortex XDR begins receiving information from the GCP Pub/Sub service, you can use the XQL Query language to search for specific data.
Set up log forwarding using the GCP cloud shell terminal
Displayed in the footer
Page 650 of 952
Cortex XDR Documentation
Displayed in the header
Displayed in the footer
Page 651 of 952
Cortex XDR Documentation
Displayed in the header
In Cortex XDR, set up Data Collection.
a. Select Settings → Configurations → Data Collection → Collection Integrations.
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.
Displayed in the footer
Page 652 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR ingests the
network flow logs as Cortex XDR 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 XDR 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.
For a Log Format set to CEF or LEEF, Cortex XDR 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 XDR 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 XDR
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 XDR 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 XDR 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 XDR 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 XDR ingests the Google Cloud DNS
logs as Cortex XDR 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.
1. Launch the GCP cloud shell terminal or use your preferred shell with gcloud installed.
Displayed in the footer
Page 653 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR.
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 XDR 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 XDR 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. After Cortex XDR begins receiving information from the GCP Pub/Sub service, you can use the XQL Query language to search for specific data.
16.3.5.4.4 | Ingest logs from Google Kubernetes Engine
Abstract
Forward your Google Kubernetes Engine (GKE) logs directly to Cortex XDR using Elasticsearch Filebeat.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
Instead of forwarding Google Kubernetes Engine (GKE) logs directly to Google StackDrive, Cortex XDR 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.
Displayed in the footer
Page 654 of 952
Cortex XDR Documentation
Displayed in the header
After Cortex XDR 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 XDR assigns the dataset a name of
container_container_raw.
After Cortex XDR 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 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.
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.
Displayed in the footer
Page 655 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR tenant. You can copy the URL from the Filebeat Collector instance
you set up for GKE in the Cortex XDR 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.
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>.
Displayed in the footer
Page 656 of 952
Cortex XDR Documentation
Displayed in the header
After you deploy your configuration, the Filebeat DameonSet runs throughout your containers to forward logs to Cortex XDR. You can review the
configuration from the Kubernetes Engine console: Workloads → Filebeat → YAML.
Cortex XDR 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 XDR begins receiving logs from GKE, you can use the XQL Search to search for logs in the new dataset.
16.3.5.4.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 XDR authentication stories.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
Cortex XDR 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 settings in Cortex XDR based on your Microsoft Azure Event Hub configuration. After you set up data collection, Cortex
XDR begins receiving new logs and data from the source.
When Cortex XDR 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 XDR to normalize Azure Event Hub audit logs, including
Azure Kubernetes Service (AKS) audit logs, with other Cortex XDR 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 XDR to normalize, you can change the default
dataset. Cortex XDR can also raise Cortex XDR 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
Misconfiguration of Event Hub resources could cause ingestion delays.
In an existing Event Hub integration, do not change the mapping to a different Event Hub.
Do not use the same Event Hub for more than two purposes.
The following table provides a brief description of the different types of Azure audit logs you can collect.
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.
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 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 Microsoft 365 data collector, because it is easier to configure. In addition, ensure that you don't
configure both collectors to collect the same types of logs, because if you do so, you will be creating duplicate data in
Cortex XDR.
Resource logs, including Retrieves events related to operations that were performed within an Azure resource.
AKS audit logs
These logs are from the data plane.
Ensure that you do the following tasks before you begin configuring data collection from Azure Event Hub.
Displayed in the footer
Page 657 of 952
Cortex XDR Documentation
Displayed in the header
Before you set up an Azure Event Hub, calculate the quantity of data that you expect to send to Cortex XDR, taking into account potential data spikes
and potential increases in data ingestion, because partitions cannot be modified after creation. Use this information to ascertain the optimal number of
partitions and Throughput Units (for Azure Basic or Standard) or Processing Units (for Azure Premium). Configure your Event Hub accordingly.
Create an Azure Event Hub. We recommend using a dedicated Azure Event Hub for this Cortex XDR integration. For more information, see Quickstart:
Create an event hub using Azure portal.
Each partition can support a throughput of up to 1 MB/s.
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 XDR:
1. In the Microsoft Azure console, open the Event Hubs page, and select the Azure Event Hub that you created for collection in Cortex XDR.
2. Record the following parameters from your configured event hub, which you will need when configuring data collection in Cortex XDR.
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 XDR 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 XDR.
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.
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:
Displayed in the footer
Page 658 of 952
Cortex XDR Documentation
Displayed in the header
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 Select from the list of applicable Azure AD Activity and Azure Sign-in Logs Categories, the ones that you want
logs and Azure Sign- to configure your designated resource to collect. You can select any of the following categories to collect these
in logs types of Azure logs.
Azure AD Activity logs:
AuditLogs
Azure Sign-in logs:
SignInLogs
NonInteractiveUserSignInLogs
ServicePrincipalSignInLogs
ManagedIdentitySignInLogs
ADFSSignInLogs
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 XDR.
a. Select Settings → Configurations → Data Collection → Collection Integrations.
b. In the Azure Event Hub configuration, click Add Instance to begin a new configuration.
c. Set these parameters.
Displayed in the footer
Page 659 of 952
Cortex XDR Documentation
Displayed in the header
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 storage account’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.
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.
For a Log Format set to CEF or LEEF, Cortex XDR 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 XDR 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 XDR 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.
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 XDR normalizes and enriches Azure Event Hub audit logs with other Cortex XDR 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.
When events start to come in, a green check mark appears underneath the Azure Event Hub configuration with the amount of data received.
16.3.5.4.6 | Ingest logs and data from Okta
Abstract
Ingest authentication logs and data from Okta for use in Cortex XDR authentication stories.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
To receive logs and data from Okta, you must configure the Collection Integrations settings in Cortex XDR. After you set up data collection, Cortex XDR
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 XDR , 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
Displayed in the footer
Page 660 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR:
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 → Collection Integrations.
4. In the Okta configuration, click Add Instance.
5. Integrate the Okta authentication service with Cortex XDR.
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.
6. After Cortex XDR 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.
16.3.5.5 | Ingest endpoint data
Abstract
Cortex XDR enables you to ingest endpoint data.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
Displayed in the footer
Page 661 of 952
Cortex XDR Documentation
Displayed in the header
Cortex XDR enables you to ingest endpoint data.
Cortex XDR does not support ingestion of EDR data from third party vendors. Consider upgrading to Cortex XSIAM in order to ingest EDR data from third party
vendors.
The following endpoint data can be ingested by Cortex XDR:
Windows Events and other data using other Broker VM data collector applets
16.3.5.6 | Ingest cloud assets
Abstract
You can ingest cloud assets from different third-party sources using Cortex XDR.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
You can ingest cloud assets from different third-party sources.
16.3.5.6.1 | Ingest cloud assets from AWS
Abstract
Extend Cortex XDR visibility into cloud assets from AWS.
Ingestion of cloud assets from AWS requires a Cortex XDR Pro per GB license.
Cortex XDR 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 Collection Integrations settings in Cortex XDR 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 XDR
begins receiving new data from the source.
As soon as Cortex XDR 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 XDR.
1. Open the AWS wizard in Cortex XDR.
a. Select Settings → Configurations → Data Collection → Collection Integrations.
b. In the Cloud Inventory configuration, click Add Instance.
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.
Displayed in the footer
Page 662 of 952
Cortex XDR Documentation
Displayed in the header
c. Create a stack called XDRCloudApp using the preset Cortex XDR template in AWS.
The following details are automatically filled in for you in the AWS CloudFormation stack template:
Stack Name: The default name for the stack is XDRCloudApp.
CortexXDRRoleName: The name of the role that will be used by Cortex XDR to authenticate and access the resources in your AWS account.
External ID: The Cortex XDR 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 XDR. 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 XDR.
This step is only relevant if you’ve configured the Organization Level as Organization in the Account Details screen in Cortex XDR. 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 XDR.
h. Set the Organization Unit ID in Cortex XDR.
This step is only relevant if you’ve configured the Organization Level as Organization Unit in the Account Details screen in Cortex XDR. 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 XDR.
i. Define the following remaining connection parameters in the Account Details screen in Cortex XDR:
Displayed in the footer
Page 663 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR 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.
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 XDR. 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. Use one of the following methods:
Define the account credentials using Amazon CLI
1. On the Configure Member Accounts page, select the Amazon CLI tab, which is displayed by default.
2. Open the Amazon CLI.
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.
5. Review the Summary screen of the wizard.
If something needs to be corrected, click Back to correct it.
6. 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.
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 XDR.
Define the account credentials using AWS CloudFormation
1. On the Configure Member Accounts page, select the Cloud Formation tab.
2. In the on-screen step Download the CloudFormation template, click template. Download the template file. The name of the downloaded file is 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.
Displayed in the footer
Page 664 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR .
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.
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.
12. Review the Summary screen of the wizard.
If something needs to be corrected, click Back to correct it.
13. 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.
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 XDR.
After Cortex XDR 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.
16.3.5.6.2 | Ingest cloud assets from Google Cloud Platform
Abstract
Extend Cortex XDR visibility into cloud assets from Google Cloud Platform.
Ingestion of cloud assets from Google Cloud Platform requires a Cortex XDR Pro per GB license.
Cortex XDR 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 Collection Integrations settings in Cortex XDR 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 XDR
begins receiving new data from the source.
As soon as Cortex XDR 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 XDR.
1. Open the GCP wizard in Cortex XDR.
a. Select Settings → Configurations → Data Collection → Collection Integrations.
b. In the Cloud Inventory configuration, click Add Instance.
c. Click Google Cloud Platform.
Displayed in the footer
Page 665 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR - Project, Folder,
or Organization.
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 XDR . The field in Cortex XDR 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 XDR.
-Folder: Contains a folder icon ( ) beside it, and the ID should be pasted in the Folder ID field in Cortex XDR.
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
XDR.
f. Select the menu icon → 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 XDR.
h. Define the following remaining connection parameters in the Configure Account screen in Cortex XDR.
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 XDR 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.
Displayed in the footer
Page 666 of 952
Cortex XDR Documentation
Displayed in the header
c. Click Continue to open the Cloud Shell Editor.
d. Select File → Open, and Open the Terraform script that you downloaded from Cortex XDR.
e. Use the following commands to upload the Terraform script, which you can copy from the Account Details screen in Cortex XDR 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.
Displayed in the footer
Page 667 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR. 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.
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.
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 XDR by selecting the copy icon ( ), and paste in the gcloud CLI tool.
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.
Displayed in the footer
Page 668 of 952
Cortex XDR Documentation
Displayed in the header
<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 XDR.
<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 XDR. 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 XDR , and
click Next.
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.
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 XDR.
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 XDR 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.
16.3.5.6.3 | Ingest cloud assets from Microsoft Azure
Abstract
Extend Cortex XDR visibility into cloud assets from Microsoft Azure.
Ingestion of Cloud Assets from Microsoft Azure requires a Cortex XDR Pro per GB license.
Cortex XDR 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 Collection Integrations settings in Cortex XDR 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 XDR begins receiving new data from the source.
As soon as Cortex XDR 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 XDR.
1. Open the Microsoft Azure wizard in Cortex XDR.
a. Select Settings → Configurations → Data Collection → Collection Integrations.
Displayed in the footer
Page 669 of 952
Cortex XDR Documentation
Displayed in the header
b. In the Cloud Inventory configuration, click Add Instance.
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 XDR.
This step is only relevant if you’ve configured the Organization Level as Subscription in the Configure Account screen in Cortex XDR. 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 XDR.
This step is only relevant if you’ve configured the Organization Level as Management Group in the Configure Account screen in Cortex XDR.
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 XDR.
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
To run the Terraform script 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 XDR 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.
Displayed in the footer
Page 670 of 952
Cortex XDR Documentation
Displayed in the header
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.
Before running this command, ensure that your Azure CLI client is logged in by running az login. From the returned message from the
login command, copy the code provided, go to the website mentioned in the message, and use the code to authenticate.
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 ID that 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
XDR.
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 XDR.
Displayed in the footer
Page 671 of 952
Cortex XDR Documentation
Displayed in the header
g. Download the JSON file from Cloud Shell using the upload/download icon ( ), so you have output field values for future reference.
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 be displayed.
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 XDR.
6. After Cortex XDR 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.
16.3.5.7 | Additional log ingestion methods
Abstract
Cortex XDR supports custom log ingestion methods.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
In addition to native log ingestion support, Cortex XDR also supports a number of custom log ingestion methods.
16.3.5.7.1 | Ingest logs from a Syslog receiver
Abstract
To extend visibility, Cortex XDR can receive Syslog from additional vendors that use CEF or LEEF formatted over Syslog (TLS not supported).
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
Cortex XDR can receive Syslog from a variety of supported vendors (see External data ingestion vendor support). In addition, Cortex XDR can receive Syslog
from additional vendors that use CEF, LEEF, CISCO, CORELIGHT, or RAW formatted over Syslog.
After Cortex XDR begins receiving logs from the third-party source, Cortex XDR 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.
16.3.5.7.2 | Ingest Apache Kafka events as datasets
Abstract
Cortex XDR can receive logs and data from Apache Kafka directly to your log repository for query and visualization purposes.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
Cortex XDR 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 XDR, you can collect events as datasets.
After Cortex XDR begins receiving topic events from the Kafka clusters, Cortex XDR 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 XDR 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.
Displayed in the footer
Page 672 of 952
Cortex XDR Documentation
Displayed in the header
16.3.5.7.3 | Ingest CSV files as datasets
Abstract
Cortex XDR can receive CSV log files from a shared Windows directory, where the CSV log files must conform to specific guidelines.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
Cortex XDR 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 XDR (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 XDR begins receiving logs from the shared Windows directory, Cortex XDR 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 XDR 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.
16.3.5.7.4 | Ingest database data as datasets
Abstract
Cortex XDR can receive data from a client relational database directly to your log repository.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
Cortex XDR 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 XDR, you can collect data as datasets. For more information about activating this
collector applet, see Activate the Database Collector.
After Cortex XDR begins receiving data from a client relational database, Cortex XDR 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 XDR 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.
16.3.5.7.5 | Ingest logs in a network share as datasets
Abstract
Cortex XDR can receive logs from files and folders in a network share directly to your log repository for query and visualization purposes.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
Cortex XDR 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 XDR, you can collect files as datasets.
After Cortex XDR begins receiving logs from files and folders in a network share, Cortex XDR 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
Displayed in the footer
Page 673 of 952
Cortex XDR Documentation
Displayed in the header
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.
The Files and Folders Collector applet only starts to collect files that are more than 256 bytes.
Configure Cortex XDR 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.
16.3.5.7.6 | Ingest FTP files as datasets
Abstract
Cortex XDR can receive logs from files and folders via FTP, FTPS, and SFTP directly to your log repository for query and visualization purposes.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
Cortex XDR 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 XDR, you can collect files as datasets.
After Cortex XDR begins receiving logs from files and folders via FTP, FTPS, or SFTP, Cortex XDR 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 XDR 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.
16.3.5.7.7 | Ingest NetFlow flow records as datasets
Abstract
Cortex XDR can receive NetFlow flow records and IPFIX from a UDP port directly to your log repository for query and visualization purposes.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
Cortex XDR 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 XDR begins receiving flow records from the UDP port, Cortex XDR 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 XDR can also analyze your logs to raise Analytics
alerts.
Configure Cortex XDR 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.
16.3.5.7.8 | Set up an HTTP log collector to receive logs
Abstract
You can set up Cortex XDR to receive logs from third-party sources, and automatically parse and process these logs.
Displayed in the footer
Page 674 of 952
Cortex XDR Documentation
Displayed in the header
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
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 XDR begins receiving logs from the third-party source, Cortex XDR 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 XDR.
a. Select Settings → Configurations → Data Collection → Custom Collectors.
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.
e. Select the Log Format as Raw, JSON, CEF, or LEEF.
Cortex XDR 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.
-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 XDR 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 XDR uses these values even if you specified a value in the Vendor and Product fields in the HTTP
collector settings. However, when the values are blank in the event log row, Cortex XDR 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 XDR 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.
Displayed in the footer
Page 675 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR. Separate records with a \n (new line) delimiter. The request body can
contain up to 10 Mib records, but 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.
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 failed to process the request"}
be 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 → Collection Integrations page to monitor the status of your HTTP Log Collection
configuration. For each instance, Cortex XDR 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 XDR begins receiving logs, use the XQL Search to search your logs.
16.3.5.7.9 | Ingest logs from BeyondTrust Privilege Management Cloud
Abstract
Extend Cortex XDR visibility into logs from BeyondTrust Privilege Management Cloud.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
If you use BeyondTrust Privilege Management Cloud, you can take advantage of Cortex XDR investigation and detection capabilities by forwarding your logs to
Cortex XDR. This enables Cortex XDR 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 XDR starts to receive logs, Cortex XDR can analyze your logs in XQL Search and you can create new Correlation Rules.
Displayed in the footer
Page 676 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR 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 XDR.
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 XDR using an Amazon S3 data collector for generic data.
Ensure your Amazon S3 data collector is configured with the following settings.
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.
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 XDR 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.
16.3.5.7.10 | Ingest logs and data from Box
Abstract
Ingest logs and data from Box enterprise accounts via the Box REST APIs.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
Cortex XDR 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 Collection Integrations settings in Cortex XDR based on your Box enterprise account credentials. After
you set up data collection, Cortex XDR begins receiving new logs and data from the source.
When Cortex XDR 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 XDR can raise Cortex XDR 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 XDR to query the data using XQL Search, and whether the data is normalized.
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 XDR
(admin_logs) file/folder management, normalizes SaaS audit event
permission changes, logs into stories, which are
access and login activities, collected in a dataset
user/groups management, called saas_audit_logs.
folder collaboration,
file/folder sharing, security
settings changes, tasks,
permission changes on
folders, storage expiration
and data retention, and
workflows.
Displayed in the footer
Page 677 of 952
Cortex XDR Documentation
Displayed in the header
Type Of Data Description Collection Method Fetch Interval Dataset Name Normalized Data
Box Shield Retrieves security alerts Appends data 60 seconds box_shield_alerts_raw —
Alerts related to suspicious
locations, suspicious
sessions, anomalous
download, and malicious
content.
Collecting Box Shield Alerts
requires implementing Box
Shield,
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 —
1. Set up an Enterprise Box plan.
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 XDR 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 XDR to receive logs and data from Box.
1. Complete the prerequisites mentioned above 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.
Displayed in the footer
Page 678 of 952
Cortex XDR Documentation
Displayed in the header
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
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
XDR 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.
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
options menu → Authorize App.
c. Click Authorize.
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 XDR, select Settings → Configurations → Data Collection → Collection Integrations.
5. In the Box configuration, click Add Instance.
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:
Displayed in the footer
Page 679 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR.
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 XDR.
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 XDR.
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
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.
16.3.5.7.11 | Ingest logs and data from Dropbox
Abstract
Ingest logs and data from Dropbox Business accounts via the Dropbox Business API.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
Cortex XDR 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 Collection Integrations settings in Cortex XDR based on your Dropbox Business
Account credentials. After you set up data collection, Cortex XDR begins receiving new logs and data from the source.
When Cortex XDR 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 XDR can raise Cortex XDR 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 XDR to query the data using XQL Search, and whether the data is normalized.
The Fetch Interval is non-configurable.
Type Of Data Description Collection Method Fetch Interval Dataset Name Normalized Data
Log collection
Displayed in the footer
Page 680 of 952
Cortex XDR Documentation
Displayed in the header
Type Of Data Description Collection Method Fetch Interval Dataset Name Normalized Data
Events Retrieves team events, including Appends data 60 seconds dropbox_events_raw When relevant, Cortex XDR
access events, administrative normalizes SaaS audit
events, file/folders events, security event logs into stories,
settings events, and more. 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
1. Set up an Advanced Dropbox plan.
2. Create a Dropbox Business admin account with Security admin permissions, which is required to authorize Cortex XDR to access the Dropbox Business
account and generate the OAuth 2.0 access token.
Configure Cortex XDR to receive logs and data from Dropbox.
1. Complete the prerequisite steps mentioned above 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
Team Data team_data.member All types of data
Members members.read Users
groups.read Groups
Sessions sessions.list Member Devices
events.read Events
Displayed in the footer
Page 681 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR.
6. In Cortex XDR, select Settings → Configurations → Data Collection → Collection Integrations.
7. In the Dropbox configuration, click Add Instance.
8. Set the following parameters:
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%&token_access_type=offline&response_type=code, where the %APP_KEY% is replaced with the App
Key value specified.
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 XDR. The access code is valid for around four minutes
from when it is generated.
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.
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.
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.
16.3.5.7.12 | Ingest logs from Elasticsearch Filebeat
Abstract
Cortex XDR can ingest logs from Elasticsearch Filebeat, a file system logger that logs file activity on your endpoints and servers.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
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 XDR. To facilitate log ingestion, Cortex XDR supports the same protocols that Filebeat and Elasticsearch
use to communicate. Cortex XDR supports using Filebeat up to version 8.2 with the Filebeat data collector. Cortex XDR 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 XDR 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.
Displayed in the footer
Page 682 of 952
Cortex XDR Documentation
Displayed in the header
processors:
- add_fields:
fields:
vendor: <Vendor>
product: <Product>
To provide additional context during investigations, Cortex XDR 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 XDR received from Filebeat.
To receive logs, you configure collection settings for Filebeat in Cortex XDR and output settings in your Filebeat installations. As soon as Cortex XDR begins
receiving logs, the data is visible in XQL Search queries.
1. In Cortex XDR, set up Data Collection.
a. Select Settings → Configurations → Data Collection → Collection Integrations.
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 XDR 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 XDR 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 XDR.
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 XDR 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 → Custom Collectors page to monitor the status of your Filebeat configuration. For
each instance, Cortex XDR 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.
Displayed in the footer
Page 683 of 952
Cortex XDR Documentation
Displayed in the header
16.3.5.7.13 | Ingest logs from Forcepoint DLP
Abstract
Extend Cortex XDR visibility into logs from Forcepoint DLP.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
If you use Forcepoint DLP to prevent data loss over endpoint channels, you can take advantage of Cortex XDR investigation and detection capabilities by
forwarding your logs to Cortex XDR. This enables Cortex XDR 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 XDR starts to receive logs, Cortex XDR 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 XDR.
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 XDR begins receiving data from Forcepoint DLP, you can use XQL Search to search your logs using the forcepoint_dlp_endpoint
dataset.
16.3.5.7.14 | Ingest logs from Proofpoint Targeted Attack Protection
Abstract
Ingest logs from Proofpoint Targeted Attack Protection (TAP).
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
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 XDR based on your Proofpoint TAP configuration. After you set up data collection, Cortex XDR begins receiving new
logs and data from the source.
When Cortex XDR 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 XDR.
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 XDR. For more information on generating TAP service credentials, see Generate TAP Service Credentials.
2. Configure the Proofpoint TAP collection in Cortex XDR.
a. Select Settings → Configurations → Data Collection → Collection Integrations.
b. In the Proofpoint Targeted Attack Protection configuration, click Add Instance.
c. Set these parameters:
Displayed in the footer
Page 684 of 952
Cortex XDR Documentation
Displayed in the header
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.
16.3.5.7.15 | Ingest logs and data from Salesforce.com
Abstract
Use the Cortex XDR data collector to collect Audit Trail and Security Monitoring event logs from Salesforce.com.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
The Cortex XDR 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 XDR, 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 XDR begins receiving logs, it creates new datasets for them, called salesforce_<object>_raw. Examples of <object> include:
Displayed in the footer
Page 685 of 952
Cortex XDR Documentation
Displayed in the header
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.
To manage collection integration in Cortex XDR, 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.
To use the client credentials flow required for Salesforce.com–Cortex XDR integration, you must create a connected app for Cortex XDR in Salesforce.com,
and configure its OAuth settings and access policies. Following these activities, configure Cortex XDR.
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/integrations
on separate lines, where {tenant external URL} is the name of your tenant as it appears in the URL of your Cortex XDR tenant.
7. For OAuth Scopes, select Full access (full) and Perform requests at any time (refresh_token, offline_access).
8. In the next options after OAuth Scopes, ensure that only the following checkboxes are selected:
Displayed in the footer
Page 686 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR). 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 XDR 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 XDR). 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 XDR
1. In Cortex XDR, create a Salesforce.com data collector instance:
Select Settings → Configurations → Data Collection → Collection Integrations.
In the Salesforce.com configuration, click Add Instance.
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.
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.
A Salesforce data collection instance is created, and an authorization token is created and returned to Cortex XDR. Data collection begins.
Displayed in the footer
Page 687 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR. 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 XDR, 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.
16.3.5.7.16 | Ingest data from ServiceNow CMDB
Abstract
Extend Cortex XDR visibility into data from ServiceNow CMDB.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
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 XDR 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 XDR 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 XDR 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
XDR. Record the credentials for this user as you will need them when configuring the ServiceNow CMDB Collector in Cortex XDR.
Configure Cortex XDR to receive data from ServiceNow CMDB:
1. Select Settings → Configurations → Data Collection → Collection Integrations.
2. In the ServiceNow CMDB configuration, click Add Instance.
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 XDR.
Password: Specify the password for your ServiceNow CMDB user designated in Cortex XDR.
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.
Displayed in the footer
Page 688 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR 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.
16.3.5.7.17 | Ingest report data from Workday
Abstract
Extend Cortex XDR visibility into reports data from Workday.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
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 XDR and configuring report data collection via this Workday custom report that you set up.
As soon as Cortex XDR 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 XDR 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.
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.
1. Create an Integration System User that is designated to access the custom report from Workday for data collection in Cortex XDR.
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 XDR. Record these credentials as you will need them when configuring the Workday Collector in Cortex XDR.
For more information on completing any of the prerequisite steps, see the Workday documentation.
Configure Cortex XDR 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:
Displayed in the footer
Page 689 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR.
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
XDR.
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 XDR, map the required fields from the Data Source configured by selecting the applicable Field
that you want to map to the Cortex XDR 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.
The Business Object changes depending on the Data Source selected.
For the incident and card views in Cortex XDR, map the following fields in the table by selecting the applicable Field that contains the data
representing the Cortex XDR 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 XDR field name.
Displayed in the footer
Page 690 of 952
Cortex XDR Documentation
Displayed in the header
Cortex XDR 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
XDR.
j. Complete the report by clicking Done.
2. Configure the Workday collection in Cortex XDR.
a. Select Settings( ) → Configurations → Data Collection → Collection Integrations.
b. In the Workday configuration, click Add Instance.
c. Set the following parameters.
Displayed in the footer
Page 691 of 952
Cortex XDR Documentation
Displayed in the header
Name: Specify the name for the Workday Collector that is displayed in Cortex XDR.
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 XDR begins receiving report data from Workday, you can use the XQL Search to search for logs in the new dataset
(workday_workday_raw).
16.3.5.7.18 | Ingest external alerts
Abstract
For a more complete and detailed picture of the activity involved in an incident, Cortex XDR can ingest alerts from any external source.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
For a more complete and detailed picture of the activity involved in an incident, Cortex XDR can ingest alerts from any external source. Cortex XDR 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 XDR APIs.
After Cortex XDR begins receiving external alerts, you must map the following required fields to the Cortex XDR format.
TIMESTAMP
SEVERITY
ALERT NAME
In addition, these optional fields are available, if you want to map them to the Cortex XDR format.
Displayed in the footer
Page 692 of 952
Cortex XDR Documentation
Displayed in the header
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
If you send pre-parsed alerts using the Cortex XDR API, additional mapping is not required.
Storage of external alerts is determined by your Cortex XDR tenant retention policy. For more information, see Dataset Management.
1. Send alerts from an external source to Cortex XDR.
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
XDR format before sending them to Cortex XDR. If you use the API to send logs, you do not need to perform the additional mapping step in Cortex
XDR.
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 XDR, select Settings → Configurations → External Alerts Mapping.
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 XDR displays a limited sample of results during the mapping rule creation. As you define your filters, Cortex XDR 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 XDR field to a field in your alert source.
If needed, use the field converter ( ) to translate the source field to the Cortex XDR syntax.
For example, if you use a different severity system, you need to use the converter to map your severities fields to the Cortex XDR 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 XDR format. For example, if 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.
Displayed in the footer
Page 693 of 952
Cortex XDR Documentation
Displayed in the header
16.3.6 | Verifying collector connectivity
Abstract
Verify collector connectivity and troubleshoot collector errors.
Ingestion of logs and data requires a Cortex XDR Pro per GB license.
You can verify the connectivity status of a collector instance on the Collection Integrations 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 Collection Integrations 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.
Example 56.
This example searches for status changes on Strata IOT integrations:
dataset = collection_auditing
|filter collector_type = "STRATA_IOT"
How can I set up correlation rules to trigger collection alerts?
You can create correlation rules that are based on the fields in the collection_auditing dataset.
Example 57. Example: Trigger collection alerts for error statuses on the STRATA_IOT collector
In this example, a correlation rule triggers an alert if an integration of the Strata IOT collector changes to error status.
Example XQL:
dataset = collection_auditing
|filter classification = "Error" and collector_type = "STRATA_IOT"
Additional fields to specify in the correlation rule:
Field Value
Time Schedule Hourly
Query time frame 1 Hour
Alert Suppression Select Enable alert suppression.
Action Select Generate alert.
Severity Medium
Category Collection
16.4 | Dataset management
Abstract
Displayed in the footer
Page 694 of 952
Cortex XDR Documentation
Displayed in the header
Learn more about managing your datasets and understanding your overall data storage, period based retention.
This feature requires a Cortex XDR Pro license.
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 XDR licenses
and retention add-ons by selecting Settings → Cortex XDR License. For more information on license retention and the defaults provided per license, see
License retention in Cortex XDR.
Cortex XDR 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.
Cold storage, in addition to a cold storage license, requires compute units (CU) to run cold storage queries. For more information on CU, see Manage compute
units. For information on the CU add-on license, see Understand Cortex XDR license plans.
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.
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 XDR, 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:
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.
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 What are datasets?.
*LOG UPDATE Event logs are updated either continuously (Logs) or the current state is updated periodically (State) as detailed in the Last Updated
TYPE column.
Displayed in the footer
Page 695 of 952
Cortex XDR Documentation
Displayed in the header
Field Description
*LAST UPDATED Last time the data in the dataset logs were updated.
This column is updated once a day. Therefore, if the dataset was created or updated by the target or lookup flows, it's possible that
the Last Updated value is a day behind when the queries or reports were run as it was before this column was 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 XDRtenant, which is comprised of the HOT RANGE + the COLD RANGE.
STORED
*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 XDR tenant. This number is dependent on the events stored in the hot storage. For
STORED 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 XDR 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 XDR 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 XDR 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 the
EVENT SIZE 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. The possible values are:
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.
For more information, see Set time to live for lookup datasets.
DEFAULT QUERY Details whether the dataset is configured to use as your default query target in XQL Search, so when you write your queries you do
TARGET not 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 XDR 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
Displayed in the footer
Page 696 of 952
Cortex XDR Documentation
Displayed in the header
Field Description
TOTAL COLD Total cold storage retention configured for the dataset in months, where a month is calculated as 31 days.
RETENTION
16.4.1 | What are datasets?
Abstract
Learn how to import, delete, and interact with custom or third-party datasets in Cortex XDR.
This feature requires a Cortex XDR Pro per GB license.
Cortex XDR 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 XDR runs the query against the default datasets configured, which is by default xdr_data. The xdr_data dataset contains all of the
endpoint and network data that Cortex XDR collects. 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 the following 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 XDR 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
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:
The dataset formats supported are dependent on the data retention offerings available in Cortex XDR 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 XDR 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. For more information, see Create 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.
Managing datasets
Displayed in the footer
Page 697 of 952
Cortex XDR Documentation
Displayed in the header
You can manage your datasets in Cortex XDR from the Settings → Configurations → Data Management → Dataset Management page.
Below are some of the main tasks available for all dataset types by right-clicking a particular dataset listed in the Datasets table. Only tasks that need further
explanation are explained below. Datasets can only be deleted if there are no other dependencies. For example, if a Correlation Rule is based on a dataset,
you wouldn't be able to delete the dataset until you removed the dataset view from the XQL query of the Correlation Rule.
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 XDR 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 XDR 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.
16.4.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, and threat hunting.
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.
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 XDR 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.
A lookup dataset can only be deleted if there are no other dependencies. For example, if a Correlation Rule is based on a lookup dataset, you wouldn't be able
to delete the lookup dataset until you removed the dataset from the XQL query of the Correlation Rule.
16.4.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 XDR.
This feature requires a Cortex XDR Pro license.
You can import data from CSV, TSV, or JSON files into Cortex XDR to create or update lookup datasets.
Displayed in the footer
Page 698 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR 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.
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.
16.4.2.2 | Download JSON file of lookup dataset
Abstract
Learn more about downloading a lookup dataset as a JSON file.
This feature requires a Cortex XDR Pro license.
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.
16.4.2.3 | Set time to live for lookup datasets
Abstract
Learn more about setting the time to live (TTL) for lookup datasets in Cortex XDR.
This feature requires a Cortex XDR Pro license.
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.
Displayed in the footer
Page 699 of 952
Cortex XDR Documentation
Displayed in the header
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.
16.4.3 | Monitor datasets activity
Abstract
Learn more about the monitored Cortex XDR datasets and dataset views activities.
Cortex XDR logs entries for events related to datasets monitored activities. Cortex XDR stores the logs for 365 days. To view the datasets audit logs, select
Settings → Management Audit Logs.
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 XDR Management Audit Logs table:
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* This field is not applicable for datasets logs.
ID Unique ID of the action.
Reason This field is not applicable for datasets 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.
Type* and Sub-Type* Additional classifications of dataset logs (Type and Sub-Type):
Datasets:
Create Dataset
Delete Dataset
Update Dataset
User Name* Name of the user who performed the action.
Displayed in the footer
Page 700 of 952
Cortex XDR Documentation
Displayed in the header
16.5 | Parsing Rules
Abstract
Learn more about Cortex XDR Parsing Rules.
Learn more about Cortex XDR Parsing Rules.
16.5.1 | What are Parsing Rules?
Abstract
Learn more about what are Parsing Rules and what they are used for.
Parsing Rules requires a Cortex XDR Pro per GB license and a user with Cortex Account Administrator or Instance Administrator permissions.
Cortex XDR 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 XDR 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.
16.5.2 | Parsing Rules editor views
Abstract
Learn about the Parsing Rules editor User Defined Rules, Default Rules, Both, and Simulate views.
Parsing Rules requires a Cortex XDR Pro per GB license and a user with Cortex Account Administrator or Instance Administrator permissions.
The Parsing Rules editor contains the following views:
Displayed in the footer
Page 701 of 952
Cortex XDR Documentation
Displayed in the header
User Defined (default): Displays an editor for writing your own custom parsing rules that override 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 XDR in read-only mode and a List of Errors section to view any errors in
your Parsing 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.
16.5.3 | 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.
Parsing Rules requires a Cortex XDR Pro per GB license and a user with Cortex Account Administrator or Instance Administrator permissions.
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 XDR 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 XDR 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].
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, 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).
For more information on the XQL syntax, see Cortex XQL Language Reference.
The COLLECT, CONST, INGEST, and RULE syntax is derived from XQL, but with the following modifications for XQLp:
Displayed in the footer
Page 702 of 952
Cortex XDR Documentation
Displayed in the header
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.
An inner type of join stage is only supported in CONST, INGEST, and RULE sections and is not supported in a COLLECT section.
Only the following XQL functions are permitted in all sections: parse_timestamp, parse_epoch, and regexcapture.
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 */
Every statement in the Parsing Rules file must end with a semicolon (;).
16.5.3.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).
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).
Displayed in the footer
Page 703 of 952
Cortex XDR Documentation
Displayed in the header
Parameter Description
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:
Example 58.
[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:
Displayed in the footer
Page 704 of 952
Cortex XDR Documentation
Displayed in the header
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:
Example 59.
[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 tag to the ingested data as part of the ingestion flow that you can easily query. 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:
Example 60.
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:
Example 61.
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";
16.5.3.2 | COLLECT
Abstract
Understand 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
XDR 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 XDR server. While this rule is optional to configure, once added, this rule runs before the INGEST section.
Displayed in the footer
Page 705 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR 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:
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.
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 XDR 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.
Example 62.
[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;
Displayed in the footer
Page 706 of 952
Cortex XDR Documentation
Displayed in the header
A few more points to keep in mind when writing COLLECT rules:
There are no COLLECT rules by default, so all collected events are forwarded by the Broker VM to the Cortex XDR server.
To reduce the amount of data transmitted to Cortex XDR from the broker, use filters to drop logs. Yet, be aware that once the logs are modified using
alter or fields stages, the Broker VM will convert the original log into a JSON format, which could increase the data size being sent from the broker
to Cortex XDR.
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 XDR 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 XDR 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 XDR server.
16.5.3.3 | CONST
Abstract
Learn 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.
Example 63.
[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:
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
...
Only quoted or integer terminal values are considered valid for CONST sections.
Example 64.
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:
Displayed in the footer
Page 707 of 952
Cortex XDR Documentation
Displayed in the header
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.
16.5.3.4 | RULE
Abstract
Understanding how to write a [RULE] section in a Parsing Rules file and the syntax to use.
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.
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.
Displayed in the footer
Page 708 of 952
Cortex XDR Documentation
Displayed in the header
Rules are defined by [rule:ruleName] as depicted in the following example:
Example 65.
[rule:filter_alerts]
filter raw_log not contains "alert";
Rules are invoked by using a call keyword as depicted in the following example:
Example 66.
[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 tag to the ingested data as part of the ingestion flow that you can easily query. You can add tags using both the INGEST and RULE
sections.
Example 67.
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";
Example 68.
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";
You can also add tags using only the INGEST section. For more information, see INGEST.
16.5.4 | Create Parsing Rules
Abstract
Cortex XDR includes an editor for creating 3rd party Parsing Rules.
Parsing Rules requires a Cortex XDR Pro per GB license and a user with Cortex Account Administrator or Instance Administrator permissions.
Cortex XDR provides a number of default Parsing Rules that you can easily override 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
How to create Parsing Rules
1. In Cortex XDR , 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.
Displayed in the footer
Page 709 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR 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.
You need Cortex XDR administrator or Instance Administrator permissions to access the Simulate view and perform these tests.
a. Select the Simulate view.
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.
16.5.5 | Troubleshooting Parsing rules errors
Abstract
Learn how to easily identify and resolve parsing errors.
Parsing Rules requires a Cortex XDR Pro per GB license and a user with Cortex Account Administrator or Instance Administrator permissions.
To help you easily identify and resolve parsing errors in Cortex XDR, 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.
Some errors can only be found after the applicable logs are collected in Cortex XDR.
Read more...
Displayed in the footer
Page 710 of 952
Cortex XDR Documentation
Displayed in the header
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
_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 are Parsing Rule
configured to be ingested or not. By default, null fields are ingested.
Displayed in the footer
Page 711 of 952
Cortex XDR Documentation
Displayed in the header
Field Description Source
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
RAW_LOG Displays the raw log for the Parsing Rule error or parsed log for the Data Model Rule error. Raw log
_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 error. Log Metadata
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
16.5.6 | 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.
Parsing Rules requires a Cortex XDR Pro per GB license and a user with Cortex Account Administrator or Instance Administrator permissions.
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.
Example 69.
The following syntax overrides the panw_ngfw_raw automatic Parsing Rule:
[ingest:vendor=panw, product=ngfw, dataset=panw_ngfw_raw]
filter ... | alter ...;
Displayed in the footer
Page 712 of 952
Cortex XDR Documentation
Displayed in the header
16.6 | Manage Event Forwarding
Abstract
Save your ingested, parsed data in an external location by exporting your event logs to a temporary GCP storage bucket.
This feature requires a Cortex XDR Pro license and 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 XDR 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 XDR data layer, for compliance requirements and machine learning purposes. The exported logs are
raw data, without any stories. Cortex XDR exports all the data without filtering or configuration options.
Enable Endpoints Event Forwarding to export raw endpoint data for Cortex XDR Pro EP and Cloud Endpoints. The exported logs are raw data,
without any stories. Cortex XDR 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 XDR, 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.
16.6.1 | Endpoints Event Forwarding - included/excluded fields by event type
Abstract
Learn more about the included/excluded fields by event type for Endpoint Event Forwarding in Cortex XDR.
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 XDR exports the data without filtering or configuration options. The tables below list the fields that are included and excluded for:
Types of events exported for the endpoints
Common fields for all event types
Types of events exported for the endpoints
Displayed in the footer
Page 713 of 952
Cortex XDR Documentation
Displayed in the header
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
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
Displayed in the footer
Page 714 of 952
Cortex XDR Documentation
Displayed in the header
Exported Event Type Included Field Excluded Field
action_process_image_command_line action_process_container_id
action_process_signature_product action_process_is_container_root
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
Displayed in the footer
Page 715 of 952
Cortex XDR Documentation
Displayed in the header
Exported Event Type Included Field Excluded Field
action_file_name action_file_yara_file_scan_result
action_file_previous_file_path action_file_dir_query
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
Displayed in the footer
Page 716 of 952
Cortex XDR Documentation
Displayed in the header
Exported Event Type Included Field Excluded Field
action_file_signature_status
action_file_pe_info
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
Displayed in the footer
Page 717 of 952
Cortex XDR Documentation
Displayed in the header
Exported Event Type Included Field Excluded Field
action_remote_process_signature_vendor action_remote_process_file_info
action_remote_process_signature_is_embedded
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
Displayed in the footer
Page 718 of 952
Cortex XDR Documentation
Displayed in the header
Exported Event Type Included Field Excluded Field
action_module_system_properties
action_module_code_integrity
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
The table below lists the common fields for all event types and the fields that are included and excluded.
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
Displayed in the footer
Page 719 of 952
Cortex XDR Documentation
Displayed in the header
Common Fields For All Event Types Included Field Excluded Field
agent_os_sub_type source_message_id
agent_os_type zip_id
agent_version agent_request_time
agent_id server_request_time
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
Displayed in the footer
Page 720 of 952
Cortex XDR Documentation
Displayed in the header
Common Fields For All Event Types Included Field Excluded Field
event_rpc_inteface_version_minor
event_rpc_protocol
event_address_mapped
event_user_presence_status
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
Displayed in the footer
Page 721 of 952
Cortex XDR Documentation
Displayed in the header
Common Fields For All Event Types Included Field Excluded Field
actor_process_device_info
actor_process_execution_time
actor_process_file_create_time
actor_process_file_mod_time
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
16.7 | Manage compute units
Abstract
Learn more about managing and tracking your compute units usage for API and Cold Storage XQL queries.
Cortex XDR uses compute units (CU) for these types of queries:
Displayed in the footer
Page 722 of 952
Cortex XDR Documentation
Displayed in the header
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.
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.
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.
16.7.1 | Compute units usage
Abstract
Learn more about how to compute units (CU) works according to your license and available options after reaching your quota.
Cortex XDR provides a free daily quota of compute units (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 XDR 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
XDR 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.
How 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.
Displayed in the footer
Page 723 of 952
Cortex XDR Documentation
Displayed in the header
For Managed Security tenants, the values calculated are the total daily usage of parent and child tenants.
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.
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 in the query field of the Query Builder where you can view the query results. For more information, see How to build XQL queries.
17 | Cortex XDR XQL
17.1 | Get started with XQL
Abstract
XQL is the Palo Alto Networks Cortex Query Language used in Cortex XDR.
XQL is the Cortex Query Language. It allows you to form complex queries against data stored in Cortex XDR. This section introduces XQL, and it provides
reference information on the various stages, functions, and aggregates that XQL supports.
17.1.1 | XQL language features
Abstract
Learn more about the Cortex Query Language features to query for raw network and endpoint data.
The Cortex Query Language (XQL) enables you to query for information contained in a wide variety of data sources in Cortex XDR for rigorous endpoint and
network event analysis. Queries require a dataset, or data source, to run against. Unless otherwise specified, the query runs against the xdr_data dataset,
which contains all raw log information that Cortex XDR collects from all Cortex product agents, including EDR data, and PAN NGFW data. You can also import
data from third parties and then query against those datasets as well.
You submit XQL queries to Cortex XDR using the Incident Response → Investigation → Query Builder → XQL Search user interface.
XQL is similar to other query languages, and it uses some of the same functions as can be found in many SQL implementations, but it is not SQL. XQL forms
queries in stages. Each stage performs a specific query operation and is separated by a pipe (|) character. 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. For example, the following query uses three stages to
identify the dataset to query, identify the field to be retrieved from the dataset, and then set a filter that identifies which records should be retrieved as part of
the query:
dataset = xdr_data
| fields os_actor_process_file_size as osapfs
| filter to_string(osapfs) = "12345"
XQL supports:
Displayed in the footer
Page 724 of 952
Cortex XDR Documentation
Displayed in the header
Simple queries.
Filters that identify a subset of records to return in the result set.
Joins and Unions.
Aggregations.
Queries against standard datasets.
Queries against presets, which are collections of information that are specific to a given type of network or endpoint activity, such as authentication or file
transfers.
Queries against custom imported datasets.
17.1.2 | XQL Language Structure
Abstract
Learn more about the Cortex Query Language structure when creating a query.
Cortex Query Language (XQL) queries usually begin by defining a data source, be it a dataset or a preset. After that, you use zero or more stages to form the
XQL query. Each stage is delimited using a pipe (|). The function performed by each stage is identified by the stage keyword that you provide.
Specifying a dataset is not required because Cortex XDR uses xdr_data as the default dataset. If 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.
In the simplest case, you can specify a dataset using one of the following formats.
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
You can also build a query that investigates data in both a cold dataset and 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 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 XDR instance over the time range that you provide to
the Query Builder user interface. This can be a large amount of data, which might take a long time to retrieve. You can use a limit stage to specify how many
records you want to retrieve.
dataset = xdr_data | limit 5
The records resulting from this query, or the result set, are returned in unsorted order. Every time you run the query, it will probably return a different set of
records in no specific order. To create a predictable result set, use other stages to define sort order, filter the result set to identify exactly what records you want
returned, to create fields containing aggregations , and more.
There is no practical limit to the number of stages that you can specify. See Stages 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. We recommend
that you use these normalized_user fields when building your queries to ensure the most accurate results.
17.1.2.1 | Adding comments in queries
Abstract
Learn more about adding comments in Cortex Query Language queries.
You can add comments in any section when building a query in Cortex Query Language (XQL).
Displayed in the footer
Page 725 of 952
Cortex XDR Documentation
Displayed in the header
Comments are added on a single line using the following syntax.
//<comments>
For example,
dataset = xdr_data
| filter event_type=1
//ENUM.process
and event_sub_type = 1
//ENUM.execution
To write a comment that extends over multiple lines use the following syntax.
/*multi-line <comments> */
For example,
dataset = xdr_data
| filter
/*multi-line Adding comments is a great thing.
Here is an example */
event_type=1
17.1.3 | Supported operators
Abstract
Cortex Query Language supports specific comparison, boolean, and set operators in Cortex XDR.
Cortex Query Language (XQL) queries support the following comparison, boolean, string, range, and add operators.
Operator Description
Comparison operators
=, != Equal, Not equal
<, <= Less than, Less than or equal to
>, >= Greater than, Greater than or equal to
Boolean operators
and Boolean and
or Boolean or
not Boolean not
String and range operators
IN, NOT IN Returns true if the integer or string field value is one of the options specified. For example:
action_local_port in(5900,5999)
For string field values, wildcards are supported. In this example a wildcard (*) is used to search if the value contains the strings
"word_1" or "word_2" anywhere in the output, or exactly matches the string "word":
str_field in ("*word_1*", "*word_2*", "word")
In some cases, using an IN or NOT IN operator combined with a dataset and filter stage can be a better alternative to using a join
stage.
Displayed in the footer
Page 726 of 952
Cortex XDR Documentation
Displayed in the header
Operator Description
CONTAINS, Performs a search for an integer or string. Returns true if the specified string is contained in the field. Contains and Not Contains are
NOT also supported within arrays for integers and strings.
CONTAINS
Example 70.
lowercase(actor_process_image_name) contains "psexec"
~= Matches a regular expression.
Example 71.
action_process_image_name ~= ".*?\.(?:pdf|docx)\.exe"
INCIDR, NOT Performs a search for an IPv4 address or IPv4 range using CIDR notation, and returns true if the address is in range.
INCIDR
Example 72.
action_remote_ip incidr "192.1.1.1/24"
It is also possible to define multiple CIDRs with comma separated syntax when building a XQL query with the Query Builder or in
Correlation Rules. When defining multiple CIDRs, the logical OR is used between the CIDRS listed, so as long as one address is in range
the entire statement returns true. The same logic is used when using the incidr() function. For more information on how this logic
works to determine whether the incidr or not incidr operators return true or false, see incidr.
Example 73.
action_remote_ip incidr "192.168.0.0/24, 1.168.0.0/24"
Both the IPv4 address and CIDR ranges can be either an explicit string using quotes (""), such as "192.168.0.1", or a string field.
INCIDR6, Performs a search for an IPv6 address or IPv6 range using CIDR notation, and returns true if the address is in range.
NOT INCIDR6
Example 74.
action_remote_ip incidr6 “3031:3233:3435:3637:0000:0000:0000:0000/64”
It is also possible to define multiple CIDRs with comma separated syntax when building a XQL query with the Query Builder or in
Correlation Rules. When defining multiple CIDRs, the logical OR is used between the CIDRS listed, so as long as one address is in range
the entire statement returns true. The same logic is used when using the incidr6() function. For more information on how this logic
works to determine whether the incidr6 or not incidr6 operators return true or false, see incidr6.
Example 75.
action_remote_ip incidr6 "2001:0db8:85a3:0000:0000:8a2e:0000:0000/64, fe80::/10"
Both the IPv6 address and CIDR ranges can be either an explicit string using quotes (""), such
as “3031:3233:3435:3637:0000:0000:0000:0000/64”, or a string field.
Add operator for tagging
Displayed in the footer
Page 727 of 952
Cortex XDR Documentation
Displayed in the header
Operator Description
add The add operator is used in combination with the tag command to add a single tag or list of tags to a field that you can easily query in
the dataset.
Example 76.
Adding a Single Tag
dataset = xdr_data
| tag add "test"
Adding a List of Tags
dataset = xdr_data
| tag add "test1", "test2", "test3"
17.1.4 | Datasets and presets
Abstract
The Cortex Query Language supports built-in datasets, custom datasets, and presets.
Every Cortex Query Language (XQL) dataset query begins by identifying a data source that the query will run against. Each data source has a unique name,
and a series of fields. Your query specifies the data source, and then provides stages that identify fields of interest and perform operations against those fields.
You can query against either datasets or Presets in a dataset query. XQL supports using different languages for dataset and field names. In addition, the
dataset formats supported are dependent on the data retention offerings available in Cortex XDR according to whether you want to query hot storage (default)
or cold storage. For more information, see XQL Language Structure.
Datasets
The standard, built-in data source that is available in every Cortex XDR instance is the xdr_data dataset. This is a very large dataset with many available
fields. For more information about this dataset, see Cortex XDR XQL Schema Reference. Cortex Query Language (XQL) supports using different languages for
dataset and field names. In addition, the dataset formats supported are dependent on the data retention offerings available in Cortex XDR according to
whether you want to query hot storage (default) or cold storage. For more information, see XQL Language Structure.
This dataset is comprised of both raw Endpoint Detection and Response (EDR) events reported by the Cortex XDR agent, and of logs from different sources
such as third-party logs. To help you investigate events more efficiently, Cortex XDR also stitches these logs and events together into common schemas called
stories. These stories are available using the Cortex XDR Presets.
Building queries in XQL
When building queries in XQL, keep the following in mind with respect to datasets:
Use the dataset keyword to specify a dataset on your query.
Create custom datasets using the target stage.
Dataset names can use uppercase characters, but in queries dataset names are always treated as if they are lowercase. In addition, dataset names are
supported using different languages, numbers (0-9), and underscores (_). Yet, underscores cannot be the first character of the name.
Upon ingestion, all fields are retained even fields with a null value. You can also use XQL to query parsing rules for null values.
Available datasets
Depending on your integrations, you can have the following datasets available for queries:
Data Dataset
Active Directory via Cloud Identity Engine pan_dss_raw
To set up this Cloud Identity Engine (previously called Directory Sync Service (DSS)) dataset, you need to
set up a Cloud Identity Engine. Otherwise, you will not have a pan_dss_raw dataset. For more information,
see Set up Cloud Identity Engine.
Displayed in the footer
Page 728 of 952
Cortex XDR Documentation
Displayed in the header
Data Dataset
Alerts table in Cortex XDR alerts
INFO alerts are not included in this dataset.
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.
Amazon S3 Audit logs
All logs: aws_s3_raw
Normalize and enrich audit logs: cloud_audit_logs
Generic logs
<Vendor>_<Product>_raw
Network flow logs
All logs: aws_s3_raw
Normalize and enrich flow logs: xdr_dataset dataset with a preset called network_story
Authentication logs (subset of xdr_data) Authentication logs, such as Okta: auth_logs
The fields contained in this dataset are a subset of the fields in the xdr_data dataset.
AWS CloudTrail and Amazon CloudWatch <Vendor>_<Product>_raw
Azure Event Hub All logs: MSFT_Azure_raw
Normalize and enrich audit logs: cloud_audit_logs
Azure Network Watcher All logs: MSFT_Azure_raw
Normalize and enrich flow logs: xdr_dataset dataset with a preset called network_story
BeyondTrust Privilege Management Cloud beyondtrust_privilege_management_raw
Box Events (admin_logs)
box_admin_logs_raw
Box Shield Alerts
box_shield_alerts_raw
Users
box_users_raw
Groups
box_groups_raw
Checkpoint FW1/VPN1 <Vendor>_<Product>_raw
Cisco ASA Cisco ASA firewalls or Cisco AnyConnect VPN
cisco_asa_raw
Displayed in the footer
Page 729 of 952
Cortex XDR Documentation
Displayed in the header
Data Dataset
Collector status change audit for collection collection_auditing
integrations, custom collectors, and
marketplace collectors.
Corelight Zeek corelight_zeek_raw
Correlation rule executions correlations_auditing
Cortex Data Lakes xdr_data
Cortex XDR Collectors panw_xdrc_raw
Cortex XDR Host Firewall enforcement host_firewall_events
events
CSV files in shared Windows directory Custom datasets: Select from pre-existing user-created datasets or add a new dataset.
Database data (MySQL, PostgreSQL, <Vendor>_<Product>_raw
MSSQL, and Oracle)
Data ingestion health metrics Datasets:
metrics_source
Dropbox Events
dropbox_events_raw
Member Devices
dropbox_members_devices_raw
Users
dropbox_users_raw
Groups
dropbox_groups_raw
Elasticsearch Filebeat <Vendor>_<Product>_raw
Elasticsearch Winlogbeat <Vendor>_<Product>_raw
If the vendor and product are not specified in the Winlogbeat profile’s configuration file, Cortex XDR creates
a default dataset called microsoft_windows_raw.
Errors related to Parsing Rules parsing_rules_errors
Forcepoint DLP forcepoint_dlp_endpoint_raw
Displayed in the footer
Page 730 of 952
Cortex XDR Documentation
Displayed in the header
Data Dataset
Fortinet Fortigate <Vendor>_<Product>_raw
GlobalProtect access authentication logs xdr_data
To ensure GlobalProtect access authentication logs are sent to Cortex XDR, verify that your PANW firewall’s
Log Settings for GlobalProtect has the Cortex Data Lake checkbox selected.
Google Cloud Platform (GCP) logs All log types: google_cloud_logging_raw
Normalize and enrich audit and flow logs: cloud_audit_logs
Audit logs: cloud_audit_logs
Network flow logs: xdr_dataset dataset with a preset called network_story
Google Kubernetes Engine (GKE) <Vendor>_<Product>_raw
Google Workspace Google Chrome: google_workspace_chrome_raw
Admin Console: google_workspace_admin_console_raw
Google Chat: google_workspace_chat_raw
Enterprise Groups: google_workspace_enterprise_groups_raw
Login: google_workspace_login_raw
Rules: google_workspace_rules_raw
Google drive: google_workspace_drive_raw
Token: google_workspace_token_raw
User Accounts: google_workspace_user_accounts_raw
SAML: google_workspace_saml_raw
Alerts: google_workspace_alerts_raw
Emails: google_gmail_raw
Displayed in the footer
Page 731 of 952
Cortex XDR Documentation
Displayed in the header
Data Dataset
Host Inventory and Vulnerability Datasets
Assessment
host_inventory
va_cves
va_endpoints
Presets
host_inventory
host_inventory_accessibility
host_inventory_applications
host_inventory_auto_runs
host_inventory_cpus
host_inventory_daemons
host_inventory_disks
host_inventory_drivers
host_inventory_endpoints
host_inventory_extensions
host_inventory_groups
host_inventory_kbs
host_inventory_mounts
host_inventory_services
host_inventory_shares
host_inventory_users
host_inventory_volumes
host_inventory_vss
Incidents table in Cortex XDR incidents
JSON or text logs from third-party source <Vendor>_<Product>_raw
over HTTP
Login logs (subset of xdr_data) Login logs, such as WEC: login_logs
The fields contained in this dataset are a subset of the fields in the xdr_data dataset.
Logs from third party source over FTP, <Vendor>_<Product>_raw
FTPS, or SFTP
Displayed in the footer
Page 732 of 952
Cortex XDR Documentation
Displayed in the header
Data Dataset
Microsoft 365 (email) msft_o365_emails_raw
msft_o365_users_raw
msft_o365_groups_raw
msft_o365_devices_raw
msft_o365_mailboxes_raw
msft_o365_rules_raw
Microsoft Office 365 Microsoft Office 365 audit events from Management Activity API:
Azure AD Activity Logs: msft_o365_azure_ad_raw
Exchange Online: msft_o365_exchange_online_raw
Sharepoint Online: msft_o365_sharepoint_online_raw
DLP: msft_o365_dlp_raw
General: msft_o365_general_raw
Microsoft Office 365 emails via Microsoft’s Graph API: msft_o365_emails_raw
Azure AD authentication events from Microsoft Graph API: msft_azure_ad_raw
Azure AD audit events from Microsoft Graph API: msft_azure_ad_audit_raw
Alerts from Microsoft Graph Security API: msft_graph_security_alerts_raw
NetFlow ip_flow_ip_flow_raw (default)
When configured, uses the format <Vendor>_<Product>_raw
Network Share logs <Vendor>_<Product>_raw
Okta okta_sso_raw
OneLogin Log collection
onelogin_events_raw
Directory
onelogin_users_raw
onelogin_groups_raw
onelogin_apps_raw
PANW EDR xdr_data
PANW IOT Security Alerts
panw_iot_security_alerts_raw
Devices
panw_iot_security_devices_raw
Displayed in the footer
Page 733 of 952
Cortex XDR Documentation
Displayed in the header
Data Dataset
PANW NGFW panw_ngfw_*_raw
Supports the following logs.
Authentication Logs: panw_ngfw_auth_raw
Configuration Logs: panw_ngfw_config_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.
PingFederate ping_identity_pingfederate_raw
PingOne for Enterprise pingone_sso_raw
Prisma Cloud prisma_cloud_raw
Prisma Cloud Compute prisma_cloud_compute_raw
Proofpoint Targeted Attack Protection proofpoint_tap_raw
ServiceNow CMDB A ServiceNow CMDB dataset is created for each table configured for data collection using the format
servicenow_cmdb_<table name>_raw.
Displayed in the footer
Page 734 of 952
Cortex XDR Documentation
Displayed in the header
Data Dataset
Salesforce.com salesforce_connectedapplication_raw
salesforce_permissionset_raw
salesforce_profile_raw
salesforce_groupmember_raw
salesforce_group_raw
salesforce_user_raw
salesforce_userrole_raw
salesforce_document_raw
salesforce_contentfolder_raw
salesforce_attachment_raw
salesforce_contentdistribution_raw
salesforce_tenantsecuritylogin_raw
salesforce_useraccountteammember_raw
salesforce_tenantsecurityuserperm_raw
salesforce_account_raw
salesforce_audit_raw
salesforce_login_raw
salesforce_eventlogfile_raw
Syslog/CEF <CEFVendor>_<CEFProduct>_raw
USB devices connect and disconnect xdr_data
events reported by the agent
You can query in XQL for this data and build widgets based on the xdr_data dataset or using the
preset device_control.
To view in an XQL query these events, the Device Configuration of the endpoint profile 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] in Device control.
VPN logs (subset of xdr_data) VPN logs, such as GlobalProtect: vpn_logs
The fields contained in this dataset are a subset of the fields in the xdr_data dataset.
Displayed in the footer
Page 735 of 952
Cortex XDR Documentation
Displayed in the header
Data Dataset
Windows Endpoints using Cortex XDR forensics_amcache
Forensics Add-on
forensics_application_resource_usage
forensics_arp_cache
forensics_background_activity_monitor
forensics_chrome_history
forensics_cid_size_mru
forensics_command_history
forensics_dns_cache
forensics_edge_anaheim_history
forensics_edge_spartan_history
forensics_event_log
forensics_file_access
forensics_file_listing
forensics_firefox_history
forensics_handles
forensics_hosts_file
forensics_internet_explorer_history
forensics_jumplist
forensics_last_visited_pidl_mru
forensics_log_me_in
forensics_net_sessions
forensics_network
forensics_network_connectivity_usage
forensics_network_data_usage
forensics_open_save_pidl_mru
forensics_port_listing
forensics_prefetch
forensics_process_execution
forensics_process_listing
forensics_psreadline
forensics_recent_files
forensics_recentfilecache
forensics_recycle_bin
forensics_registry
forensics_remote_access
forensics_seven_zip_folder_history
forensics_shellbags
forensics_shimcache
forensics_team_viewer
Displayed in the footer
Page 736 of 952
Cortex XDR Documentation
Displayed in the header
Data Dataset
forensics_typed_paths
forensics_typed_urls
forensics_user_access_logging
forensics_user_assist
forensics_windows_activities
forensics_winrar_arc_history
forensics_word_wheel_query
Windows event logs via Cortex XDR microsoft_windows_raw
Windows agents
Windows Event Collector (WEC) xdr_data
microsoft_windows_raw
Windows DHCP using Elasticsearch microsoft_dhcp_raw
Filebeat
Windows DNS Debug using Elasticsearch Raw Data
Filebeat
microsoft_dns_raw
Normalized Stories
xdr_data with the preset called network_story.
Workday workday_workday_raw
Zscaler Cloud Firewall ZIA
Firewall logs: zscaler_nssfwlog_raw
Web logs: zscalar_nssweblog_raw
ZPA
zscaler_zpa_raw
Presets
Presets offer groupings of xdr_data fields that are useful for analyzing specific areas of network and endpoint activity. All of the fields available for a preset
are also available on the larger xdr_data dataset, but by using the preset your query can run more efficiently. Presets are sorted at random by the first one
million results found.
Two of the available presets are stories. These contain information stitched together from Cortex XDR agent events and log files to form a common schema.
They are authentication_story and network_story.
You use the preset keyword to specify a dataset in your query.
17.1.5 | About examples
Abstract
Learn more about the Cortex Query Language (XQL) examples provided.
The examples included in topics are intended to illustrate the behavior or usage of a particular stage or function. While these examples can be based on real
data that you could use on real-world queries, you may need to tweak these queries to perform investigations or otherwise solve real world problems.
Displayed in the footer
Page 737 of 952
Cortex XDR Documentation
Displayed in the header
For examples of queries that illustrate useful investigative queries, see the example Query Library that is available from the product user interface:
Incident Response → Investigation → Query Builder → XQL Search → Query Library
17.1.6 | JSON functions
Abstract
Learn more about how Cortex XDR treats JSON functions in the Cortex Query Language.
The Cortex Query Language (XQL) includes a number of JSON functions. Before using any of these functions, it's important to understand how Cortex XDR
treats a JSON so you can accurately formulate your queries using the correct syntax.
JSON field names are case sensitive, so the key to field pairing must be identical in an XQL query for results to be found. For example, if a field value is
"TIMESTAMP" and your query is defined to look for "timestamp", no results will be found.
<json_path>
Each JSON function includes defining a <json_path> in both the regular syntax or when using the syntatic sugar format. The <json_path> argument
identifies the data of the JSON object you want to extract using dot-notation. When using the regular syntax, the beginning of the object is represented by a $.
This $ is not required when using the syntatic sugar format.
Example 77.
If you have the following object:
{
"a_field" : "This is a_field value",
"b_field" : {
"c_field" : "This is c_field value"
}
}
Then the path using the regular syntax:
$.a_field
Returns "This is a_field value", while the path using the regular syntax:
$.b_field.c_field
Returns "This is c_field value".
Field in <json_path> contains characters
In the regular syntax
When using the regular syntax to write your XQL queries and a field in the <json_path> contains characters, such as a dot (.) or colon (:), the syntax needs
to be tweaked slightly to account for the <json_field>.
For example, when using the json_extract function, the previous regular syntax would need to be changed to an updated syntax to account for the field in
the <json_path> containing characters.
Previous regular syntax for the json_extract function:
json_extract(<json_object_formatted_string>, <json_path>)
Updated regular syntax for the json_extract function, where the <json_field> now includes single quotation marks as '<json_field>':
json_extract(<json_object_formatted_string>, "['<json_field>']")
For each JSON function, the regular syntax can change slightly, but the "['<json_field>']" format is the same. The "['<json_field>']" identifies the
data you want to extract using dot-notation, where the data extracted is dependent on your syntax.
Example 78.
If you have the following JSON object defined:
{"a.b":
{"inn":
{"one":1}
}
}
To extract the data {"one":1}, the "['<json_field>']" would need to be defined as "$['a.b'].inn" for all JSON functions. For example, when using
the json_extract function, the regular syntax is:
json_extract(field_json_1, "$['a.b'].inn")
Displayed in the footer
Page 738 of 952
Cortex XDR Documentation
Displayed in the header
To extract the data {"inn": {"one":1}}, the "['<json_field>']" would need to be defined as "$['a.b']" for all JSON functions. For example, when
using the json_extract function, the regular syntax is:
json_extract(field_json_1, "$['a.b']")
Example 79.
If you have the following JSON object defined:
{"a.b":
{"inn.inn":
{"one":1}
}
}
To extract the data {"one":1}, the "['<json_field>']" would need to be defined as "$['a.b']['inn.inn']" for all JSON functions. For example,
when using the json_extract function, the regular syntax is:
json_extract(json_field, "$['a.b']['inn.inn']")
In the syntatic sugar format
To make it easier for you to write your XQL queries, each JSON function includes an optional syntatic sugar format as opposed to using the regular syntax.
When defining the syntatic sugar format and a field in the <json_path> contains characters, such as a dot (.) or colon (:), the syntax needs to be tweaked
slightly to account for the <json_field>.
For example, when using the json_extract function, the previous syntatic sugar format would need to be changed to an updated syntax to account for the
field in the <json_path> containing characters.
Previous syntatic sugar format for the json_extract function:
<json_object_formatted_string> -> <json_path>{}
Updated syntatic sugar format for the json_extract function, where the <json_field> now includes quotations as "<json_field>":
<json_object_formatted_string> -> ["<json_field>"]{}
For each JSON function, the syntax of the syntatic sugar format can change slightly, but the ["<json_field>"] format is the same. The ["
<json_field>"] identifies the data you want to extract using dot-notation, where the data extracted is dependent on your syntax.
Example 80.
If you have the following JSON object defined:
{"a.b":
{"inn":
{"one":1}
}
}
To extract the data {"one":1}, the ["<json_field>"] would need to be defined as ["a.b"].inn for all JSON functions. For example, when using the
json_extract function, the syntatic sugar format is:
json_field -> ["a.b"].inn{}
To extract the data {"inn": {"one":1}}, the ["<json_field>"] would need to be defined as ["a.b"] for all JSON functions. For example, when using
the json_extract function, the syntatic sugar format is:
json_field -> ["a.b"]{}
Example 81.
If you have the following json_object defined:
{"a.b":
{"inn.inn":
{"one":1}
}
}
To extract the data {"one":1}, the ["<json_field>"] would need to be defined as ["a.b"]["inn.inn"] for all JSON functions. For example, when
using the json_extract function, the syntatic sugar format is:
json_field -> ["a.b"]["inn.inn"]{}
Displayed in the footer
Page 739 of 952
Cortex XDR Documentation
Displayed in the header
17.1.7 | How to filter for empty values in the results table
Abstract
Learn how to filter for empty values in the results table in Cortex Query Language.
When building a query you can filter for empty values in the results table, which can include or exclude null or empty strings. In the query syntax, empty strings
are represented as "", while null fields are represented as null.
Exclude null and empty strings using the following syntax:
<name of field> != null and <field name> != ""
Include null or empty strings using the following syntax:
<name of field> = null or <field name> = ""
Example 82.
Below is an example of filtering your endpoint data in the results table to exclude all null values and any empty strings for a user.
config timeframe = 90d
| dataset = endpoints
| filter endpoint_status in (CONNECTED, DISCONNECTED)
| filter user != null and user != ""
| fields user, group_names, endpoint_name
17.2 | Build XQL queries
Abstract
Learn more about how to build Cortex Query Language (XQL) queries using 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 predefined queries for different types of entities.
17.2.1 | About the Query Builder
Abstract
The Query Builder facilitates threat detection, incident expansion, and data analytics for suspected threats.
Building Cortex Query Language (XQL) queries in the Query Builder requires a Cortex XDR Pro license.
The Query Builder aids in the detection of threats by allowing you to search for indicators of compromise and suspicious patterns within data sources. It assists
in expanding incident investigations by identifying related events and entities, such as activities associated with specific user accounts or network lateral
movement. In addition, the Query Builder enables data analytics on suspected threats, helping organizations analyze large volumes of data to identify trends,
anomalies, and correlations that may indicate potential security issues.
To support investigation and analysis, you can search all of the data ingested by Cortex XDR 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 XDR 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 xdr_data
dataset. With XQL Search you create queries based on stages, functions, and operators. To help you build your queries, Cortex XDR provides tools in
the interface that provide suggestions as you type, or you can look up predefined queries, common stages and examples.
Predefined queries for different types of entities
17.2.2 | How to build XQL queries
Abstract
Learn more about how to build XQL queries in the Query Builder.
Building Cortex Query Language (XQL) queries in the Query Builder requires a Cortex XDR Pro license.
The Cortex Query Language (XQL) enables you to query data ingested into Cortex XDR for rigorous endpoint and network event analysis returning up to 1M
results. 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.
Displayed in the footer
Page 740 of 952
Cortex XDR Documentation
Displayed in the header
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. Unless otherwise specified, the query runs against the xdr_data dataset, which contains all log information that Cortex XDR collects
from all Cortex product agents, including EDR data, and PAN NGFW data. In XDM queries, you must specify the dataset mapped to the XDM that you want to
run your query against.
Forensic datasets are not inlcuded by default in XQL query results, unless the dataset query is explicitly defined to use a forensic dataset.
Dataset query syntax
In a dataset query, unless otherwise specified, the query runs against the xdr_data dataset, which contains all log information that Cortex XDR collects from
all Cortex product agents, including EDR data, and PAN NGFW data. 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.
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
XDR. 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> ...
| <stage2> ...
| <stage3> ...
You can specify a dataset using one of the following formats, which is based on the data retention offerings available in Cortex XDR.
Hot Storage queries use the format dataset = <dataset name>. This is the default option.
Example 23.
dataset = xdr_data
Cold Storage queries use the format cold_dataset = <dataset name>.
Example 24.
cold_dataset = xdr_data
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 XDR 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 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.
Additional components
XQL queries can contain different components, such as functions and stages, depending on the type of query you want to build.
17.2.2.1 | Get started with XQL queries
Abstract
Displayed in the footer
Page 741 of 952
Cortex XDR Documentation
Displayed in the header
Learn more about some important information before getting started with XQL queries.
Building Cortex Query Language (XQL) queries in the Query Builder requires a Cortex XDR Pro license.
Before you begin running XQL queries, consider the following information:
Use the interface to help you build queries
Cortex XDR offers features in the XQL search interface to help you to build queries. For more information see Useful XQL user interface features.
Understand query defaults and limitations
Before you run a query, review this list to better understand query behavior and results. For more information, see Expected results when querying fields.
Translate Splunk queries to XQL
If you have existing Splunk queries, you can translate them to XQL. For more information, see Translate to XQL.
17.2.2.2 | Useful XQL user interface features
Abstract
Learn about useful XQL query features in the user interface.
Building Cortex Query Language (XQL) queries in the Query Builder requires a Cortex XDR Pro license.
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. For more information, see Manage your personal
query library.
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. Contains the list of all the fields of all the datasets that were involved in the query.
17.2.2.3 | XQL Query best practices
Abstract
Learn about best practices for streamlining XQL queries.
Building Cortex Query Language (XQL) queries in the Query Builder requires a Cortex XDR Pro license.
Cortex XDR includes built-in mechanisms for mitigating long-running queries, such as default limits for the maximum number of allowed alerts. The following
suggestions can help you to streamline your queries:
Add a smaller limit to queries by using a limit stage.
The default results for any query is a maximum of 1,000,000 results, when no limit is explicitly stated in the query. Queries based on XQL query entities
are limited to 10,000 results. Adding a smaller limit can greatly reduce the response time.
Example 25.
dataset = microsoft_windows_raw
| fields *host*
| limit 100
Use a small time frame for queries by specifying the specific date and time in the custom option, instead of picking the nearest larger option available.
Use filters that exclude data, along with other possible filters.
Select the specific fields that you would like to see in the query results.
Displayed in the footer
Page 742 of 952
Cortex XDR Documentation
Displayed in the header
17.2.2.4 | Expected results when querying fields
Abstract
Learn what to expect in the query results when querying fields.
Building Cortex Query Language (XQL) queries in the Query Builder requires a Cortex XDR Pro license.
The following are returned when querying fields:
If specific fields are stated in the fields stage, those exact fields will be returned.
The _time system field will not be added to queries that contain the comp stage.
All current system fields will be returned, even if they are not stated in the query.
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 1,000,000 results are returned (default). When this limit is applied to results using
the limit stage, it will be indicated in the user interface.
17.2.2.5 | Create XQL query
Abstract
Learn how to create queries using the Cortex Query Language (XQL).
Building Cortex Query Language (XQL) queries in the Query Builder requires a Cortex XDR Pro license.
Review the following topics:
How to build XQL queries
Build Cortex Query Language (XQL) queries to analyze raw log data stored in Cortex XDR. You can query the Cortex Data Model (XDM) or datasets using
specific syntax.
How to create a dataset query
1. From Cortex XDR, select Incident Response → Investigation → Query BuilderXQL Search.
2. (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.
Whenever the time period is changed in the query window, the config timeframe is automatically set to the time period defined, but this won't be
visible as part of the query. Only if you manually type in the config timeframe will this be seen in the query.
3. (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 5.
4. 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. (Optional) Specify a dataset.
You only need to specify a dataset if you are running your query against a dataset that you have not set as default. Otherwise, the query runs
against the xdr_data dataset. For more information, see How to build XQL queries.
Example 26.
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.
Example 27.
dataset = xdr_data
| filter agent_os_type = ENUM.AGENT_OS_MAC
| limit 250
Displayed in the footer
Page 743 of 952
Cortex XDR Documentation
Displayed in the header
5. 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 ( ).
6. (Optional) The Save As options save your query for future use:
BIOC Rule: When compatible, saves the query as a BIOC rule. The XQL query must contain a filter for the event_type field.
Correlation Rule: When compatible, saves the query as a Correlation Rule. For more information, see What's a correlation rule?.
Query to Library: Saves the query to your personal query library. For more information, see Manage your personal query library.
Widget to Library: For more information, see Create custom XQL widgets.
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.
17.2.2.6 | Review XQL query results
Abstract
Learn more about reviewing the results returned from an XQL query.
Building Cortex Query Language (XQL) queries in the Query Builder requires a Cortex XDR Pro license.
Review the following topics:
How to build XQL queries
Create XQL query
The results of a Cortex Query Language (XQL) query are displayed in a tab called Query Results.
It's also possible to graph the results displayed. For more information, see Graph query results.
Understanding the options available to investigate results
Use the following options in the Query Results tab 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 Show
tab 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.
Displayed in the footer
Page 744 of 952
Cortex XDR Documentation
Displayed in the header
Option Use
Export to File Exports the results to a TSV (tab-separated values) 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 text
search 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 XDR displays the top ten results from which you can choose to build your filter. This
option is only available in the Table and Advanced tabs,
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.
In order for Cortex XDR to provide a histogram for a field, the field must not contain an array or a JSON object.
Available options for saving results
The Save As options save your query for future use:
BIOC Rule: When compatible, saves the query as a BIOC rule. The XQL query must contain a filter for the event_type field.
Correlation Rule: When compatible, saves the query as a Correlation Rule. For more information, see What's a correlation rule?.
Query to Library: Saves the query to your personal query library. For more information, see personal query library.
Widget to Library: For more information, see Create custom XQL widgets.
Investigating results in the Causality View or Timeline View
You can continue investigating the query results in the Causality View or Timeline by right-clicking the event and selecting the desired view. This option is
available for the following types of events:
Displayed in the footer
Page 745 of 952
Cortex XDR Documentation
Displayed in the header
Process (except for those with an event sub-type of termination)
Network
File
Registry
Injection
Load image
System calls
Event logs for Windows
System authentication logs for linux
For network stories, you can pivot to the Causality View only. For cloud Cortex XDR 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.
Add file path to Malware Profile allowed list
Add a file path to your existing Malware Profile allowed list by right-clicking a <path> field, such as target_process_path, and select Add <path type> to
malware profile allow list.
17.2.2.7 | Translate to XQL
Abstract
Learn how to translate your Splunk queries to XQL queries in Cortex XDR.
Building Cortex Query Language (XQL) queries in the Query Builder requires a Cortex XDR Pro license.
To help you easily convert your existing Splunk queries to the Cortex Query Language (XQL) syntax, Cortex XDR includes a toggle called Translate to XQL in
the query field in the user interface. When building your XQL query and this option is selected, both a SPL query field and XQL query field are displayed, so
you can easily add a Splunk query, which is converted to XQL in the XQL query field. This option is disabled by default, so only the XQL query field is
displayed.
This feature is still in a Beta state and you will find that not all Splunk queries can be converted to XQL. This feature will be improved upon in the upcoming
releases to support greater Splunk query translations to XQL.
Supported functions in Splunk
The following table details the supported functions in Splunk that can be converted to XQL in Cortex XDR with an example of a Splunk query and the resulting
XQL query. In each of these examples, the xdr_data dataset is used.
Splunk Function/Stage Splunk Query Example Resulting XQL Q
avg index=xdr_data | stats dataset in (xdr_data) | comp avg(dst_association_streng
avg(dst_association_strength)
bin index = xdr_data | bin _time span=5m dataset in (xdr_data) | bin _time span=5m
coalesce index= xdr_data | eval dataset in (xdr_data) | alter product_or_vendor_not_nul
product_or_vendor_not_null=coalesce(_product,
_vendor )
count index=xdr_data | stats count(_product) BY _time dataset in (xdr_data) | comp count(_product) by _time
ctime index=xdr_data | convert ctime(field) as field dataset in (xdr_data) | alter field = format_timestamp(
earliest index = xdr_data earliest=24d dataset in (xdr_data) | filter _time >= to_timestamp(ad
Displayed in the footer
Page 746 of 952
Cortex XDR Documentation
Displayed in the header
Splunk Function/Stage Splunk Query Example Resulting XQL Q
eval index=xdr_data | eval field = "test" dataset in (xdr_data) | alter field = "test"
fillnull index=xdr_data | fillnull value = "missing dataset in (xdr_data) | replacenull agent_ip_addresses_
ipv6" agent_ip_addresses_v6
floor index=xdr_data | eval floor_test = floor(1.9) dataset in (xdr_data) | alter floor_test = floor(1.9)
iplocation index=xdr_data | inputlookup append=true dataset in (xdr_data) | union (dataset=my_lookup | limi
my_lookup.csv
iplocation index = xdr_data | iplocation dataset in (xdr_data) | iploc agent_ip_addresses loc_co
agent_ip_addresses loc_region AS Region, loc_city AS City, loc_latlon AS l
isnotnull index=xdr_data | eval x = dataset in (xdr_data)\n | alter x = if(agent_hostname !
isnotnull(agent_hostname)
isnull index=xdr_data | eval x = dataset in (xdr_data)\n | alter x = if(agent_hostname =
isnull(agent_hostname)
json_extract index= xdr_data | eval dataset in (xdr_data) | alter London = dfe_labels -> df
London=json_extract(dfe_labels,"dfe_labels{0}")
join join agent_hostname [index = xdr_data] join type=left conflict_strategy=right (dataset in (xdr
latest index = xdr_data latest=-24d dataset in (xdr_data) |filter _time <=
to_timestamp(add(to_epoch(date_floor(current_time(),"d"
len index = xdr_data | where uri != null | eval dataset in (xdr_data) | filter agent_ip_addresses != nu
length = len(agent_ip_address) len(agent_ip_addresses)
ltrim(<str>, index=xdr_data | eval dataset in (xdr_data) | alter trimed_agent = ltrim("age
<trim_chars>) trimed_agent=ltrim("agent_hostname", "agent_")
lower index = xdr_data | eval field = lower("TEST") dataset in (xdr_data) | alter field = lowercase("TEST")
max index =xdr_data | stats max(action_file_size) dataset in (xdr_data) | comp max(action_file_size) by _
by _product
md5 index=xdr_data | eval md5_test = md5("test") dataset in (xdr_data) | alter md5_test = md5("test")
median index = xdr_data | stats dataset in (xdr_data) | comp median(actor_process_file_
median(actor_process_file_size) by _time
min index =xdr_data | stats min(action_file_size) dataset in (xdr_data) | comp min(action_file_size) by _
by _product
Displayed in the footer
Page 747 of 952
Cortex XDR Documentation
Displayed in the header
Splunk Function/Stage Splunk Query Example Resulting XQL Q
mvcount index = xdr_data | where http_data != null | dataset in (xdr_data) | filter http_data != null | alte
eval http_data_array_length =
mvcount(http_data)
mvdedup index = xdr_data | eval dataset in (xdr_data) | alter s = arraydistinct(action_
s=mvdedup(action_app_id_transitions)
mvexpand index = xdr_data | mvexpand dfe_labels limit = dataset in (xdr_data) | arrayexpand dfe_labels limit 10
100
mvfilter index = xdr_data | eval x = dataset in (xdr_data) | alter x = arrayfilter(dfe_label
mvfilter(isnull(dfe_labels))
mvindex index=xdr_data | eval field = dataset in (xdr_data) | alter field = arrayindex(action
mvindex(action_app_id_transitions, 0)
mvjoin index=xdr_data | eval dataset in (xdr_data) | alter n = arraystring(action_ap
n=mvjoin(action_app_id_transitions, ";")
pow index=xdr_data | eval pow_test = pow(2, 3) dataset in (xdr_data) | alter pow_test = pow(2, 3)
relative_time(X,Y) index ="xdr_data" | where _time > dataset in (xdr_data) | filter _time >
relative_time(now(),"-7d@d") to_timestamp(add(to_epoch(date_floor(current_time(
index ="xdr_data" | where _time > dataset in (xdr_data)| filter _time >
relative_time(now(),"+7d@d") to_timestamp(add(to_epoch(date_floor(current_time(
replace index= xdr_data | eval description = dataset in (xdr_data) | alter description = replace(age
replace(agent_hostname,"\("."NEW")
rex index=xdr_data action_local_ip!="0.0.0.0" | rex dataset in (xdr_data) |filter (action_local_ip != "0.0.
field=action_local_ip "(? arrayindex(regextract(action_local_ip, "(\d+\.\d+\.\d+\
<src_ip>\d+\.\d+\.\d+\.48)" | where src_ip != action_local_ip, src_ip
"" | table action_local_ip src_ip
round index=xdr_data | eval round_num = round(3.5) dataset in (xdr_data) | alter round_num = round(3.5)
rtrim index=xdr_data | eval dataset in (xdr_data) | alter trimed_hostname = rtrim("
trimed_hostname=rtrim("agent_hostname",
"hostname")
search index = xdr_data | eval ip="192.0.2.56" | dataset in (xdr_data) | alter ip = "192.0.2.56" | filte
search ip="192.0.2.0/24"
sha256 index = xdr_data | eval sha256_test = dataset in (xdr_data) | alter sha256_test = sha256("tes
sha256("test")
sort (ascending index = xdr_data | sort action_file_size dataset in (xdr_data) | sort asc action_file_size | lim
order)
Displayed in the footer
Page 748 of 952
Cortex XDR Documentation
Displayed in the header
Splunk Function/Stage Splunk Query Example Resulting XQL Q
sort (descending index = xdr_data | sort -action_file_size dataset in (xdr_data) | sort desc action_file_size | li
order)
spath index = xdr_data | spath output=myfield dataset in (xdr_data) | alter myfield = json_extract(ac
input=action_network_http path=headers.User-
Agent
split index = xdr_data | where mac != null | eval dataset in (xdr_data)\n | filter mac != null\n | alter
split_mac_address = split(mac, ":")
stats index=xdr_data | stats count(event_type) by dataset in (xdr_data) | comp count(event_type) by _time
_time
stats dc index = xdr_data | stats dc(_product) BY _time dataset in (xdr_data) | comp count_distinct(_product) b
strcat index=xdr_data | strcat story_id "/" dataset in (xdr_data) | alter
http_req_before_method comboIP comboIP=concat(if(story_id!=null,story_id,""),"/",if(ht
sum index=xdr_data | where action_file_size != null dataset in (xdr_data) | filter action_file_size != null
| stats sum(action_file_size) by _time
table index = xdr_data | table _time, agent_hostname, dataset in (xdr_data) | fields _time, agent_hostname, a
agent_ip_addresses, _product
tonumber index=xdr_data | eval tonumber_test = dataset in (xdr_data) | alter tonumber_test = to_number
tonumber("90210")
Displayed in the footer
Page 749 of 952
Cortex XDR Documentation
Displayed in the header
Splunk Function/Stage Splunk Query Example Resulting XQL Q
top The following Splunk functions can be translated to XQL: limit
limit dataset in (xdr_data) | filter action_app_id_risk
top_percent as percent
index = xdr_data | where
action_app_id_risk > 0 | top limit=20 countfield
action_app_id_risk
dataset in (xdr_data) |top 10 agent_hostname by _t
countfield percent
index = xdr_data | top showcount
countfield=count_agent_hostname
agent_hostname by _time dataset in (xdr_data) | filter action_app_id_risk
top_percent as percent
showcount
showperc
index = xdr_data | where
dataset in (xdr_data) | filter action_app_id_risk
action_app_id_risk > 0 | top 3 showcount=t
top_percent as percent
action_app_id_risk
showperc percentfield
index = xdr_data | where dataset in (xdr_data) | top 10 agent_hostname by _
action_app_id_risk > 0 | top 3 showperc=t agent_hostname_percentage
action_app_id_risk
percentfield
index = xdr_data | top
percentfield=agent_hostname_percentage
agent_hostname by _time
upper index=xdr_data | eval field = upper("test") dataset in (xdr_data) | alter field = uppercase("test")
var index=xdr_data | stats var (event_type) by dataset in (xdr_data) | comp var(event_type) by _time
_time
How to translate a Splunk query to XQL syntax
1. Select Incident Response → Investigation → Query Builder → XQL Search.
2. Toggle to Translate to XQL, where both a SPL query field and XQL query field are displayed.
3. Add your Splunk query to the SPL query field.
4. Click the arrow ( ).
The XQL query field displays the equivalent Splunk query using the XQL syntax.
You can now decide what to do with this query based on the instructions explained in Create XQL query.
17.2.2.8 | Graph query results
Abstract
Cortex XDR enables you to generate helpful visualizations of your XQL query results.
Building Cortex Query Language (XQL) queries in the Query Builder requires a Cortex XDR Pro license.
To help you better understand your Cortex Query Language (XQL) query results and share your insights with others, Cortex XDR enables you to generate
graphs and outputs of your query data directly from query results page.
1. Select Incident Response → Investigation → Query Builder → XQL.
2. Run an XQL query.
Example 28.
Displayed in the footer
Page 750 of 952
Cortex XDR Documentation
Displayed in the header
Enter the following query:
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 graph the results either:
Use Chart Editor
Navigate to Query Results → Chart Editor ( ) to manually build and view the graph using the selected graph parameters:
Main
Graph Type: Type of graphs and output options available: 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.
Use XQL query
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.
Example 29.
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. The custom widgets you create can be used in your
custom dashboards and reports. For more information, see Create custom XQL widgets.
Select Save to Widget Library to pivot to the Widget Library and generate a custom widget based on the query results.
17.2.3 | XQL query entities
Abstract
Learn more about the Cortex Query Language (XQL) entities available in the Query Builder.
With Query Builder, you can build complex queries for entities and entity attributes so that you can surface and identify connections between them. Cortex XDR
provides Cortex Query Language (XQL) queries for different types of entities in the Query Builder that search predefined datasets. The Query Builder searches
the raw data and logs stored in Cortex XDR tenant and for the entities and attributes you specify, it returns up to 1,000,000 results.
The Query Builder provides queries for the following types of entities:
Displayed in the footer
Page 751 of 952
Cortex XDR Documentation
Displayed in the header
Process: Search on process execution and injection by process name, hash, path, command line arguments, and more. See Create process query.
File: Search on file creation and modification activity by file name and path. See Create file query.
Network: Search network activity by IP address, port, host name, protocol, and more. See Create network query.
Image Load: Search on module load into process events by module IDs and more. See Create image load query.
Registry: Search on registry creation and modification activity by key, key value, path, and data. See Create 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 event log query.
Network Connections: Search security event logs by firewall logs, endpoint raw data over your network. See Create network connections query.
Authentications: Search on authentication events by identity, target outcome, and more. See Create authentication 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.
17.2.3.1 | Create authentication query
Abstract
Learn more about creating a query to investigate any authentication activity.
Building Cortex Query Language (XQL) queries in the Query Builder requires a Cortex XDR Pro license.
From the Query Builder, you can investigate authentication activity across all ingested authentication logs and data.
Some examples of authentication queries you can run include:
Authentication logs by severity
Authentication logs by the event message
Authentication logs for a specific source IP address
How to build an authentication query
1. From Cortex XDR , select INVESTIGATION → Query Builder.
2. Select AUTHENTICATION.
3. Enter the search criteria for the authentication query.
By default, Cortex XDR will return the activity that matches all the criteria you specify. To exclude a value, toggle the = option to =!.
4. 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.
5. When you are ready, view the results of the query. For more information, see Review XQL query results.
17.2.3.2 | Create event log query
Abstract
Learn more about creating a query to investigate Windows and Linux event log attributes and investigate event logs across endpoints.
Building Cortex Query Language (XQL) queries in the Query Builder requires a Cortex XDR Pro license.
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.
Some examples of event log queries you can run include:
Critical level messages on specific endpoints.
Message descriptions with specific keywords on specific endpoints.
How to build an event log query
1. From Cortex XDR , select INVESTIGATION → Query Builder.
Displayed in the footer
Page 752 of 952
Cortex XDR Documentation
Displayed in the header
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 the query. For more information, see Review XQL query results.
17.2.3.3 | Create file query
Abstract
Learn more about creating a query to investigate the connections between file activity and endpoints.
Building Cortex Query Language (XQL) queries in the Query Builder requires a Cortex XDR Pro license.
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, build an XQL query. For more information, see How to build XQL
queries.
Some examples of file queries you can run include:
Files modified on specific endpoints.
Files related to process activity that exist on specific endpoints.
How to build a file query
1. From Cortex XDR, select Incident Response → Investigation → Query Builder.
2. Select FILE.
3. Enter the search criteria for the file events query.
Displayed in the footer
Page 753 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR 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 +PROCESS 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.
5. (Optional) Limit the scope to an endpoint or endpoint attributes:
Select +Host 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.
Displayed in the footer
Page 754 of 952
Cortex XDR Documentation
Displayed in the header
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 the query. For more information, see Review XQL query results.
17.2.3.4 | Create image load query
Abstract
Learn more about create a query to investigate the connections between image load activity, acting processes, and endpoints.
Building Cortex Query Language (XQL) queries in the Query Builder requires a Cortex XDR Pro license.
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.
How to build an image load query
1. From Cortex XDR , 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 XDR 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.
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.
Displayed in the footer
Page 755 of 952
Cortex XDR Documentation
Displayed in the header
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 the query. For more information, see Review XQL query results.
17.2.3.5 | Create network connections query
Abstract
Learn more about creating a query to investigate the connections between firewall logs, endpoints, and network activity.
Building Cortex Query Language (XQL) queries in the Query Builder requires a Cortex XDR Pro license.
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.
How to build a network connections query
1. From Cortex XDR , select INVESTIGATION → Query Builder.
2. Select NETWORK CONNECTIONS.
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 XDR 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.
Displayed in the footer
Page 756 of 952
Cortex XDR Documentation
Displayed in the header
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.
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 the query. For more information, see Review XQL query results.
17.2.3.6 | Create network query
Abstract
Learn more about creating a query to investigate the connections between network activity, acting processes, and endpoints.
Building Cortex Query Language (XQL) queries in the Query Builder requires a Cortex XDR Pro license.
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.
How to build a network query
Displayed in the footer
Page 757 of 952
Cortex XDR Documentation
Displayed in the header
1. From Cortex XDR , 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 XDR 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.
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, view the results of the query. For more information, see Review XQL query results.
Displayed in the footer
Page 758 of 952
Cortex XDR Documentation
Displayed in the header
17.2.3.7 | Create process query
Abstract
Learn more about creating a query to investigate connections between processes, child processes, and endpoints.
Building Cortex Query Language (XQL) queries in the Query Builder requires a Cortex XDR Pro license.
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.
How to build a process query
1. From Cortex XDR , select Incident Response → Investigation → Query Builder.
2. Select PROCESS.
3. Enter the search criteria for the process query.
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 XDR 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 +PROCESS and specify one or more of the following attributes for the acting (parent) process.
Displayed in the footer
Page 759 of 952
Cortex XDR Documentation
Displayed in the header
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 +HOST 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. For more information about the data collector applet, Activate Pathfinder.
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 the query. For more information, see Review XQL query results.
17.2.3.8 | Create registry query
Abstract
Learn more about creating a query to investigate connections between registry activity, processes, and endpoints.
Building Cortex Query Language (XQL) queries in the Query Builder requires a Cortex XDR Pro license.
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.
How to build a registry query
1. From Cortex XDR , select INVESTIGATION → Query Builder.
2. Select REGISTRY.
3. Enter the search criteria for the registry events query.
Displayed in the footer
Page 760 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR 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, view the results of the query. For more information, see Review XQL query results.
17.2.3.9 | Query across all entities
Abstract
From the Cortex XDR management console, you can search for endpoints and processes across all endpoint activity.
Building Cortex Query Language (XQL) queries in the Query Builder requires a Cortex XDR Pro license.
Displayed in the footer
Page 761 of 952
Cortex XDR Documentation
Displayed in the header
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
How to build a query
1. From Cortex XDR , 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.
Field 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.
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.
Displayed in the footer
Page 762 of 952
Cortex XDR Documentation
Displayed in the header
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.
17.2.4 | Edit and rerun queries in Query Center
Abstract
Learn more about viewing the results of a query, modifying a query, and rerunning queries from Query Center.
Building Cortex Query Language (XQL) queries in the Query Builder requires a Cortex XDR Pro license.
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 XDR 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
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 XDR 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 XDR 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.
Displayed in the footer
Page 763 of 952
Cortex XDR Documentation
Displayed in the header
17.2.4.1 | Query Center reference information
Abstract
Descriptions of the fields in the Query Center table.
Building Cortex Query Language (XQL) queries in the Query Builder requires a Cortex XDR Pro license.
The table below lists the common fields in the Query Center.
Certain fields are exposed and hidden by default. An asterisk (*) is beside every field that is exposed by default.
Query Center table
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 XDR 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.
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.
Displayed in the footer
Page 764 of 952
Cortex XDR Documentation
Displayed in the header
Field Description
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. The default results for any query is a maximum
of 1,000,000 results, when no limit is explicitly stated in the query. Queries
based on XQL query entities are limited to 10,000 results. 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.
17.2.5 | Manage scheduled queries
Abstract
Learn how to manage your scheduled and recurring queries.
Building Cortex Query Language (XQL) queries in the Query Builder requires a Cortex XDR Pro license.
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 XDR filters the queries on the Query Center.
Edit the query frequency
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.
Displayed in the footer
Page 765 of 952
Cortex XDR Documentation
Displayed in the header
4. Adjust the schedule settings, and then click OK.
17.2.5.1 | Scheduled Queries reference information
Abstract
Descriptions of the fields in the Scheduled Queries table.
Building Cortex Query Language (XQL) queries in the Query Builder requires a Cortex XDR Pro license.
The table below ists the common fields in the Scheduled Queries page.
Certain fields are exposed and hidden by default. An asterisk (*) is beside every field that is exposed by default.
Scheduled Queries table
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.
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.
17.2.6 | Manage your personal query library
Abstract
Cortex XDR provides as part of the Query Library a personal library for saving and managing your own queries.
Building Cortex Query Language (XQL) queries in the Query Builder requires a Cortex XDR Pro license.
Cortex XDR 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
Displayed in the footer
Page 766 of 952
Cortex XDR Documentation
Displayed in the header
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.
How 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.
Displayed in the footer
Page 767 of 952
Cortex XDR Documentation
Displayed in the header
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 XDR , 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 the 3 vertical dots.
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 the 3 vertical dots 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 the 3 vertical dots 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 the 3 vertical dots.
17.3 | Stages
Abstract
Learn more about the Cortex Query Language supported stages.
Stages perform certain operations in evaluating queries. For example, the dataset stage specifies a dataset to run the query. Commonly used stages include
dataset, fields, filters, join, and sort. The stages supported in Cortex Query Language are detailed below.
17.3.1 | alter
Abstract
Learn more about the Cortex Query Language alter stage.
Syntax
alter <field1> = <function value1> [, <field2> = <function value2>, ...]
Description
The alter stage is used to change the values of an existing field (column) or to create a new field (column) based on constant values or existing fields
(columns). The alter stage does this by assigning a value to a field name based on the returned value of the specified function. The field does not have to be
known to the dataset or preset schema that you are querying. Further, you can overwrite the current value for a known field using this stage.
After defining a field using the alter stage, you can apply other stages, such as filtering, to the new field or field value.
Examples
Given three username fields, use the coalesce function to return a username value in the default_username field, making sure to never have a
default_username that is root.
dataset = xdr_data
| fields actor_primary_username,
os_actor_primary_username,
causality_actor_primary_username
| alter default_username = coalesce(actor_primary_username,
os_actor_primary_username,
causality_actor_primary_username)
| filter default_username != "root"
17.3.2 | arrayexpand
Abstract
Learn more about the Cortex Query Language arrayexpand stage.
Syntax
arrayexpand <array_field> [limit <limit number>]
Displayed in the footer
Page 768 of 952
Cortex XDR Documentation
Displayed in the header
Description
The arrayexpand stage expands the values of a mulit-value array field into separate events and creates one record in the result set for each item in the array,
up to a <limit number> of records.
Example
Suppose you have a dataset with a single row like this:
Uid Username Array_values
123456 ajohnson [1,2,3,4,5,6,7,8,9,0]
Then if you run an arrayexpand stage using the array_values field, with a limit of 3, the result set includes the following records:
dataset=my_dataset
| arrayexpand array_values limit 3
Uid Username Array_values
123456 ajohnson 2
123456 ajohnson 1
123456 ajohnson 3
The result records created by arrayexpand are in no particular order. However, you can use the sort stage to sort the results:
dataset=my_dataset
| arrayexpand array_values
| sort asc array_values
17.3.3 | bin
Abstract
Learn more about the Cortex Query Language bin stage to group events by quantity or time span.
Syntax
Quantity
bin <field> bins = <number>
Time Span
bin <field> span = <time> [timeshift = <epoch time> [timezone = "<time zone>"]]
Description
The bin stage enables you to group events by quantity or time span. The most common use case is for timecharts.
You can add the bin stage to your queries using two different formats depending on whether you are grouping events by quantity or time span. Currently, the
bin stage is only supported using the equal sign (=) operator in your queries without any boolean operators (and, or).
When you group events of a particular field by quantity, the bin stage is used with bins to define how to divide the events.
When you group events of a particular field by time, the bin stage is used with span = <time>, where <time> is a combination of a number and time suffix.
Set one time suffix from the list of available options listed in the table below. In addition, you can define a particular start time for grouping the events in your
query according to the Unix epoch time by setting timeshift = <epoch time> timezone = "<time zone>", which are both optional. You can
configure the <time zone> offset using an hours offset, such as “+08:00”, or using a time zone name from the List of Supported Time Zones, such as
"America/Chicago". The query still runs without defining the epoch time or time zone. If no timeshift = <epoch time> timezone = "<time
zone>" is set, the query runs according to last time set in the log.
When you group events by quantity, the <field> in the bin stage must be a number, and when you group by time, the <field> must be a date type.
Otherwise, your query will fail.
Displayed in the footer
Page 769 of 952
Cortex XDR Documentation
Displayed in the header
Time Suffixes
Time Suffix Description
MS milliseconds
S seconds
M minutes
H hours
D days
W weeks
MO months
Y years
The time suffix is not case sensitive.
Examples
Quantity Example
Return a maximum of 1,000 xdr_data records with the events of the action_total_upload field grouped by 50MB. Records with the
action_total_upload value set to 0 or null are not included in the results.
dataset = xdr_data
| filter action_total_upload != 0 and action_total_upload != null
| bin action_total_upload bins = 50
| limit 1000
Time Span Examples
With a time zone configured using an hours offset:
Return a maximum of 1,000 xdr_data records with the events of the _time field grouped by 1-hour increments starting from the epoch time
1615353499, and includes a time zone using an hours offset of “+08:00”.
dataset = xdr_data
| bin _time span = 1h timeshift = 1615353499 timezone = “+08:00”
| limit 1000
With a time zone name configured:
Return a maximum of 1,000 xdr_data records with the events of the _time field grouped by 1-hour increments starting from the epoch time
1615353499, and includes an "America/Los_Angeles" time zone.
dataset = xdr_data
| bin _time span = 1h timeshift = 1615353499 timezone = “America/Los_Angeles”
| limit 1000
17.3.4 | call
Abstract
Learn more about the Cortex Query Language call stage to reference a predefined query from the Query Library.
Syntax
call "<name of predefined query>" [<param_name1> = <value1> <param_name2> = <value2>....]
Displayed in the footer
Page 770 of 952
Cortex XDR Documentation
Displayed in the header
Description
The call stage is used to reference a predefined query from the Query Library, including your Personal Query Library. In addition, if your query includes
parameters you can reference them in the call stage using the syntax <param_name1> = <value1> <param_name2> = <value2>.... When using
parameters in your call stage, you need to ensure that a query already exists that uses these parameters.
Example without Parameters
For the predefined query called "CreateRole operation parsed to fields", returns a maximum of 100 records, where the accessKeyId equals "1234".
call "CreateRole operation parsed to fields"
| filter accessKeyId = "1234"
| limit 100
Example with Parameters
Using the same example above, this example shows how to use the same call stage with parameters. This example assumes that there is a query that is
already saved with a parameter $key_id = "1234".
Saved query:
dataset = dataset_name
| filter field_name = $key_id
Query to run with using parameters:
call "CreateRole operation parsed to fields" key_id = "1234"
| limit 100
17.3.5 | comp
Abstract
Learn more about the Cortex Query Language comp stage that precedes functions calculating statistics.
Syntax
comp <aggregate function1> (<field>) [as <alias>][,<aggregate function2>(<field>) [as <alias>],...] [by <field1>[,<field2>...]]
[addrawdata = true|false [as <target field>]]
Description
The comp stage precedes functions calculating statistics for results to compute values over a group of rows and return a single result for a group of rows.
Aggregation functions, such as sum, min, and max
Approximate aggregate functions, such as approx_count or approx_top
At least one of the comp aggregate functions or comp approximate aggregate functions must be used. Yet, it's also possible to define a comp stage with both
types of aggragate functions.
Use approximate aggregate functions to produce approximate results, instead of exact results used with regular aggregate functions, which are more scalable
in terms of memory usage and time.
Use the alias clause to provide a column label for the comp results, and is optional.
The by clause identifies the rows in the result set that will be aggregated. This clause is optional. Provide one or more fields to this clause. All fields with
matching values are used to perform the aggregation. For example, if you had records such as:
number,id,product
100,"se1","A55"
50,"se1","A60"
50,"se1","A60"
25,"se2","A55"
25,"se2","A60"
The you can aggregate on the number column, and perform aggregation based on matching values in the id and/or product column. So if you sum the number
column by the id column, you would get two results:
200 for "se1"
50 for "se2"
If you summed by id and product, you would get:
Displayed in the footer
Page 771 of 952
Cortex XDR Documentation
Displayed in the header
100 for "se1" and "A55" (there are no matching pairs).
100 for "se1" and "A60" (there is one matching pair).
25 for "se2" and "A55" (there are no matching pairs).
25 for "se2" and "A60" (there are no matching pairs).
In addition, you can configure whether the raw data events are displayed by setting addrawdata to either true or false (default), which are used to
configure the final comp results. When including raw data events in your query, the query runs for up to 50 fields that you define and displays up to 100 events.
Wildcard Aggregates
You can use a wildcard to perform an aggregate for every field contained in the result set, except for the field(s) specified in the by clause.
Wildcards are only supported with aggregate functions and not approximate aggregate functions.
The syntax for this is:
comp <aggregate function>(*) as * [by [asc|desc] <field1>[,<field2>...]]
[addrawdata = true|false as <target field>]
For wildcards to work, all of the fields contained in the result set that are not identified in the by clause must be aggregatable.
Examples
Sum the action_total_download values for all records with matching pairs of values for the actor_process_image_path and
actor_process_command_line fields. The query calculates a maximum of 100 xdr_data records and includes a raw_data column listing the raw data
events used to display the final comp results.
dataset = xdr_data
| fields actor_process_image_path as Process_Path,
actor_process_command_line as Process_CMD,
action_total_download as Download
| filter Download > 0
| limit 100
| comp sum(Download) as total by Process_Path, Process_CMD addrawdata = true as raw_data
Using the panw_ngfw_traffic_raw dataset, sum the bytes_total, bytes_received, and bytes_sent values for every record contained in the result
set with a matching value for source_ip. The query calculates a maximum of 1000 xdr_data records and includes a raw_data column listing the raw data
events used to display the final comp results.
The comp stage runs on 1000 raw data events, but only a 100 will be displayed in the raw_data column.
dataset = panw_ngfw_traffic_raw
| fields bytes_total, bytes_received, bytes_sent, source_ip
| limit 1000
| comp sum(*) as * by source_ip addrawdata = true as raw_data
comp Aggregate Functions
The aggregate functions you can use with the comp stage are:
Displayed in the footer
Page 772 of 952
Cortex XDR Documentation
Displayed in the header
avg
count
count_distinct
earliest
first
last
latest
list
max
median
min
stddev_population
stddev_sample
sum
values
var
comp Approximate Aggregate Functions
The approximate aggregate functions you can use with the comp stage are:
approx_count
approx_quantiles
approx_top
17.3.6 | config
Abstract
Learn more about the Cortex Query Language config stage that configures the query behavior.
Syntax
config <function>
Description
The config stage configures the query behavior. It must be used with one of the config Functions. This stage must be presented as the first stage in the
query.
config Functions
These functions you can use with the config stage:
case_sensitive
timeframe
17.3.6.1 | case_sensitive
Abstract
Learn more about the Cortex Query Language case_sensitive config stage.
Syntax
config case_sensitive = true | false
Displayed in the footer
Page 773 of 952
Cortex XDR Documentation
Displayed in the header
Description
The case_sensitive configuration identifies whether field values are evaluated as case sensitive or case insensitive. The config case_sensitive stage
must be added at the beginning of the query. You can also add another config case_sensitive stage when adding a join or union stage to a query.
If you do not provide this stage in your query, the default behavior is false, and case is not considered when evaluating field values.
Things to keep in mind about before implementing this stage
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.
From Cortex XDR version 3.3, the default case sensitivity setting was changed to case insensitive (config case_sensitive = false). If you've
been using Cortex XDR before this version was released, the default case sensitivity setting is still configured to be case sensitive (config
case_sensitive = true).
The config case_sensitive stage can't be used to compare a field to an inner query. In this situation, ensure to use the lowercase or uppercase
functions on the field and inner query stages and functions syntax.
Example 90.
This query won't provide the correct results of comparing the agent_hostname field with the inner query:
config case_sensitive = false
| dataset = xdr_data
| fields agent_hostname
| filter agent_hostname in (dataset = <lookup dataset> | fields agent_hostname)
This query will provide the correct output:
config case_sensitive = false
| dataset = xdr_data
| fields agent_hostname
| filter lowercase(agent_hostname) in (dataset = <lookup dataset> | alter lower_agent_hostname = lowercase(agent_hostname) | fields lower_agent_hostname)
The config case_sensitive stage can't be used to compare a field to an array that contains non-literal strings, for example a field name or function.
Example 91.
The results of this example are true, where the left side (uppercase("a")) is lowercase as it's not an array, and the right side (("x", "A")) is also an
array that contains only literal strings.
| alter field_name = if(uppercase("a") in ("x", "A"), true, false)
Example 92.
The results of this example are false, where the left side (uppercase("a")) is lowercase as it's not an array, and the right side ("x",
uppercase("a"))) is an array that contains a function (uppercase("a")).
| alter field_name = if(uppercase("a") in ("x", uppercase("a")),true, false)
Examples
config case_sensitive = true
| dataset = xdr_data
| fields actor_process_image_name as apin
| filter apin != NULL and apin contains "python"
| limit 100
17.3.6.2 | timeframe
Abstract
Cortex Query Language timeframe configuration enables performing searches within a specific time frame from the query execution.
Displayed in the footer
Page 774 of 952
Cortex XDR Documentation
Displayed in the header
Syntax
Exact Time
config timeframe between "<Year-Month-Day H:M:S ±Timezone>" and "<Year-Month-Day H:M:S ±Timezone>"
Relative Time
config timeframe = <number><time unit>
config timeframe between "<+|-><number><time unit>" and "now"
config timeframe between "begin" and "<+|-><number><time unit>"
config timeframe between "<+|-><number><time unit>" and "<+|-><number><time unit>"
Description
The timeframe configuration enables you to perform searches within a specific time frame from the query execution. The results for the time frame are based
on times listed in the _Time column in the results table.
You can add the timeframe configuration to your queries using different formats depending on whether the time frame you are setting is an exact time or
relative time.
When you set an exact time, include the config timeframe details: between "<Year-Month-Day H:M:S ±Timezone>" and "<Year-Month-Day
H:M:S ±Timezone>". The ±Timezone format is: ±xxxx. When you do not configure a timezone, the default is UTC. The exact time is based on a static time
frame according to when the query is sent.
When you set a relative time, you have a few options for setting the config timeframe, where the syntax <+|-> indicates whether to go back (-) or forward
(+) in time. The default is back (-).
<number><time unit>
Enables setting a static time frame according to when the query is sent, where you choose the <time unit> from the available time unit options listed
in the table below.
between "<+|-><number><time unit>" and "now"
Enables setting a time frame between a defined start time, where you choose the <time unit> from the available time unit options listed in the table
below, and the end time as the time the query is run with the preset keyword "now".
between "begin" and "<+|-><number><time unit>"
Enables setting a time frame between a preset start time according to the Unix epoch time 00:00:00 UTC on 1 January 1970 with the "begin" keyword,
and a defined ending time, where you choose the <time unit> from the available time unit options listed in the table below.
between "<+|-><number><time unit>" and "<+|-><number><time unit>"
Enables setting a time frame between a defined starting and ending time, where you choose the <time unit> from the available time unit options listed
in the table below.
When a query includes any inner queries, the inner queries receives its time frame from the outer query unless the inner query has a separate time frame
defined.
Connection to the time period in the Query Builder
When using the Query Builder to define a query, the time period can be set at the top right of the query window using the time picker, and the default is 24
hours. Whenever the time period is changed in the query window, the config timeframe is automatically set to the time period defined, but this won't be
visible as part of the query. Only if you manually type in the config timeframe will this be seen in the query.
Available time units
Time Unit Description
S seconds
M minutes
H hours
D days
Displayed in the footer
Page 775 of 952
Cortex XDR Documentation
Displayed in the header
Time Unit Description
W weeks
MO months
Y years
The time unit is not case sensitive.
Examples
Relative Time
Example of <number><time unit>
For the last 10 hours from when the query is sent, return a maximum of 100 xdr_data records.
config timeframe = 10h
| dataset = xdr_data
| limit 100
Example of between "<+|-><number><time unit>" and "now"
Since the last two days until now when the query is run, return a maximum of 100 xdr_data records.
config timeframe between "2d" and "now"
| dataset = xdr_data
| limit 100
Example of between "begin" and "<+|-><number><time unit>"
Since the Unix epoch time 00:00:00 UTC on 1 January 1970 until the past 2 years when the query is run, return a maximum of 100 xdr_data records.
config timeframe between "begin" and "2y"
| dataset = xdr_data
| limit 100
Example of between "<+|-><number><time unit>" and "<+|-><number><time unit>"
Since the last four days until the next 5 days when the query is run, return a maximum of 100 xdr_data records.
config timeframe between "-4d" and "+5d"
| dataset = xdr_data
| limit 100
Exact Time
From April 1, 2021 at 9:00 a.m. UTC -02:00 until April 2, 2021 at 10:00 a.m. UTC -02:00, return a maximum of 100 xdr_data records.
config timeframe between "2021-04-01 09:00:00 -0200" and "2021-04-02 10:00:00 -0200"
| dataset = xdr_data
| limit 100
17.3.7 | dedup
Abstract
Learn more about the Cortex Query Language dedup stage that removes duplicate occurrences of field values.
Syntax
dedup <field1>[,<field2>, ...] by asc | desc <field>
Description
The dedup stage removes all records that contain duplicate values (or duplicate sets of values) from the result set. The record that is returned is identified by
the by clause, which selects the record by either the first or last occurance of the field specified in this clause.
The dedup stage can only be used with fields that contain numbers or strings.
Displayed in the footer
Page 776 of 952
Cortex XDR Documentation
Displayed in the header
Examples
Return unique values for the actor_primary_username field. For any given field value, return the first chronologically occurring record.
dataset = xdr_data
| fields actor_primary_username as apu
| filter apu != null
| dedup apu by asc _time
Return the last chronologically occurring record for any given actor_primary_username value.
dataset = xdr_data
| fields actor_primary_username as apu
| filter apu != null
| dedup apu by desc _time
Return the first occurrence seen by for any given actor_primary_username. field value.
dataset = xdr_data
| fields actor_primary_username as apu
| filter apu != null
| dedup apu by asc apu
Return unique groups of actor_primary_username and os_actor_primary_username field values. For each unique grouping, return the pair that first
appears on a record with a non-NULL action_file_size field.
dataset = xdr_data
| fields actor_primary_username as apu,
os_actor_primary_username as oapu,
action_file_size as afs
| filter apu != null and afs != null
| dedup apu, oapu by asc afs
17.3.8 | fields
Abstract
Learn more about the Cortex Query Language fields stage that defines the fields returned in the result set.
Syntax
fields [-] <field_1> [as <name1>], <field_2> [as <name2>], ...
Description
The fields stage declares which fields are returned in the result set, including name changes. If this stage is used, then subsequent stages can operate only
on the fields identified by this stage.
Use a wildcard (*) to include all fields that match the pattern. Use a minus character (-) to exclude a field from the result set. The following system fields
cannot be excluded and are always displayed:
_time
_insert_time
_raw_log
_product
_vendor
_tag
_snapshot_id
_snapshot_log_count
_snapshot_collection_ts
_id
Use the as clause to set an alias for a field. If you use the as clause, then subsequent stages must use that alias to refer to the field.
Examples
Return the action_country field from all xdr_data records where the action_country field is both not null and not "-". Also include all fields with names
that match event_* except for event_type.
dataset = xdr_data
| fields action_country as ac
| fields event_*
Displayed in the footer
Page 777 of 952
Cortex XDR Documentation
Displayed in the header
| fields - event_type
| filter ac != null and ac != "-"
17.3.9 | filter
Abstract
Learn more about the Cortex Query Language filter stage that narrows down the displayed results.
Syntax
filter <boolean expr>
Description
The filter stage identifies which data records should be returned by the query. Filters are boolean expressions that can use a wide range of functions and
operators to express the filter. If a record matches the filter as the filter expression returns true when applied to the record, the record is returned in the
query's result set.
The functions you can use with a filter are described in Functions. For a list of supported operators, see Supported operators.
Single vs triple double quotes behavior
Cortex XDR enables you to use single or triple double quotes in a filter stage with or without wildcards.
Single double quotes
Using single double quotes with the filter stage, returns the results that contain the <text> specified. Here are a few examples:
| filter <field> = "<text>*"
| filter <field> in ("<text>*", "<text>", "<text>*")
Triple double quotes
When using triple double quotes with the filter stage, the query results only include results that exactly match the <text> results. Here are a few examples:
| filter <field> = """<text>*"""
| filter <field> in ("""<text>*""", "<text>", "<text>*")
Examples
Return xdr_data records where the event_type is NETWORK and the event_sub_type is NETWORK_HTTP_HEADER.
dataset = xdr_data
| filter event_type = NETWORK and event_sub_type = NETWORK_HTTP_HEADER
When entering filters to the XQL Search user interface, possible field values for fields of type enum are available using the auto-complete feature. However, the
autocomplete can only show enum values that are known to the schema. In some cases, on data import an enum value is included that is not known to the
defined schema. In this case, the value will appear in the result set as an unknown value, such as event_type_unknown_4. Be aware that even though this
value appears in the result set, you cannot create a filter using it. For example, this query will fail, even if you know the value appears in your result set:
dataset = xdr_data
| filter event_type = event_type_unknown_4
When using fields of type enum, the following syntax is supported.
Syntax format A
| filter event_type = ENUM.FILE
Syntax format B
| filter event_type = FILE
17.3.10 | getrole
Abstract
Learn more about the Cortex Query Language getrole stage that enriches events with specific roles associated with usernames or endpoints.
This stage requires an Identity Threat Module license to view the results.
This stage is unsupported in BIOCs and real-time Correlation Rules.
Displayed in the footer
Page 778 of 952
Cortex XDR Documentation
Displayed in the header
Syntax
getrole <field> [as <alias>]
Description
The getrole stage enriches events with specific roles associated with usernames or endpoints. The getrole stage receives as an input a string field that is
either a username in the NETBIOS\SAM format, such as mydomain\myuser, or the agent ID of a host. The agent ID can be found in the endpoints dataset
as endpoint_id or in the xdr_data dataset as agent_id.
The roles for this field are displayed in a column called asset_roles in the results table. If there is one or more roles associated with the field, the values are
represented as a string array, such as ['ADMIN', 'USER'], and are listed in the asset_roles column. If there are no roles, the resulting column is an empty
array.
You can also change the name of the column using as in the syntax to define an alias: getrole <field> as <alias>.
In addition, it is possible to use the filter stage with a new ROLE prefix to display the results of a particular role using the syntax:
To include one specific role:
filter <field> = ROLE.<role name>
filter array_length(arrayfilter(<field>, "@element" = ROLE.<role name> )) > 0
To include more than one specific role:
filter <field> in (ROLE.<role name1>, ROLE.<role name2>, ....)
To exclude one specific role:
filter array_length(arrayfilter(<field>, "@element" = ROLE.<role name> )) = 0
To exclude more than one specific role:
filter array_length(arrayfilter(<field>, "@element" in (ROLE.<role name1>, ROLE.<role name2>, ....))) = 0
Examples
Return a maximum of 100 xdr_data records with the enriched events including specific roles associated with usernames. If there are one or more roles
associated with the value of the user_id string field column, the output is displayed in the asset_roles column in the results table. Otherwise, the field is
empty.
dataset = xdr_data
| limit 100
| getrole user_id
Return a maximum of 100 xdr_data records of all the powershell executions made by the SERVICE_ACCOUNTS user role in the organization. The first filter
stage indicates how to filter for the parent process, which is powershell.exe. The fields stage indicates the field columns to include in the results table and
which ones are renamed in the table: action_process_image_name to process_name and action_process_image_command_line to process_cmd.
The getrole stage indicates the enriched events to include for the specific roles associated with usernames. If the ROLE.SERVICE_ACCOUNTS role is
associated with any values in the actor_effective_username string field column, the row is displayed in the results table. Otherwise, the entire row is
excluded from the results table.
dataset = xdr_data
| filter event_type = ENUM.PROCESS and event_sub_type = ENUM.PROCESS_START and lowercase(actor_process_image_name) = "powershell.exe"
| fields action_process_image_name as process_name, action_process_image_command_line as process_cmd, event_id, actor_effective_username
| getrole actor_effective_username as user_roles
| filter user_roles = ROLE.SERVICE_ACCOUNTS
| limit 100
17.3.11 | iploc
Abstract
Learn more about the Cortex Query Language iploc stage that associates IPv4 addresses of fields to a list of predefined attributes related to the geolocation.
Syntax
iploc <field>
Description
The iploc stage associates the IPv4 address of any field to a list of predefined attributes related to the geolocation. By default, when using this stage in your
queries, the geolocation data is added to the results table in these predefined column names: LOC_ASN_ORG, LOC_ASN, LOC_CITY, LOC_CONTINENT,
LOC_COUNTRY, LOC_LATLON, LOC_REGION, and LOC_TIMEZONE.
Displayed in the footer
Page 779 of 952
Cortex XDR Documentation
Displayed in the header
The loc_latlon field contains a string that is a combination of two floating numbers representing the latitude and longitude separated by a comma, for
example, “32.0695,34.7621".
The following options are available to you when using this stage in your queries:
You can specify the geolocation fields that you want added to the results table.
You can append a suffix to the name of the geolocation field column in the results table.
You can change the name of the geolocation field column in the results table.
You can also view the geolocation data on a graph type called map, where the xaxis is set to either loc_country or loc_latlon, and the yaxis is
a number field.
The iploc stage can only be used with fields that contain numbers or strings.
To improve your query performance, we recommend that you filter the data in your query before the iploc stage is run. In addition, limiting the
number of fields in the results table further improves the performance.
Examples
Return a maximum of 1000 xdr_data records with the specific geolocation data associated with the action_remote_ip field, where no record with a null
value for action_remote_ip is included, and displays the name of the city in a column called city and a combination of the latitude and longitude in a
column called loc_latlon with comma-separated values of latitude and longitude.
dataset = xdr_data
| limit 1000
| filter action_remote_ip != null
| iploc action_remote_ip loc_city as city, loc_latlon
Return a maximum of 1000 xdr_data records with all the available geolocation data with the predefined column names, and add the specified suffix
_remote_id to each predefined column name, where no record with a null value for action_remote_ip is included.
dataset = xdr_data
| limit 1000
| filter action_remote_ip != null
| iploc action_remote_ip suffix=_remote_id
Return a maximum of 1000 xdr_data records with the specific geolocation data associated with the action_remote_ip field that includes the name of the
country (contained in loc_country) in a column called country, where no record with a null value for either country or action_remote_ip is included.
The comp stage is used to count the number of IP addresses per country. The results are displayed in a graph type of kind map, where the x-axis
represents the country and the y-axis the action_remote_ip.
dataset = xdr_data
| limit 1000
| iploc action_remote_ip loc_country as country
| filter country != null and action_remote_ip != null
| comp count() as ip_count by country
| view graph type = map xaxis = country yaxis = ip_count
17.3.12 | join
Abstract
Learn more about the Cortex Query Language join stage that combines the results of two queries into a single result set.
Syntax
join conflict_strategy = both|left|right
type = inner|left|right
((<xql query>)
as <execution_name>
<boolean_expr>)
Description
The join() stage combines the results of two queries into a single result set. This stage is conceptually identical to a SQL join.
Displayed in the footer
Page 780 of 952
Cortex XDR Documentation
Displayed in the header
Parameter/Clause Description
conflict_strategy Identifies the join conflict strategy when there is a conflict in the column names between the 2 result sets
which one should be chosen, either:
right: The column from the inner join query is used (default), which implements a right outer join.
left: The column from the orignal result set in the dataset is used, which implements a left outer join.
both: Both columns are used. The original result set column from the dataset keeps the current
name, while the inner join query result set column name includes the following suffix added to the
current name _joined_10, such as <original column name>_joined_10, and depending on
the number of conflicted fields the suffix increases to _joined_11, _joined_12....
type Identifies the join type.
inner
Returns all the records in common between the queries that are being joined. This is the default join
type.
right
Returns all records from the join result set, plus any records from the parent result set that intersect
with the join result set.
left
Returns all records from the parent result set, plus any records from the join result set that intersect
with the parent result set.
<xql query> Provides the XQL query to be joined with the parent query.
as <execution_name> Provides an alias for the join query's result set. For example, if you specify an execution name of join1,
and in the join query you return field agent_id, then you can subsequently refer to that field as
join1.agent_id.
<boolean_expr> Identifies the conditions that must be met in order to place a record in the join result set.
This stage does not preserve sort order. If you are combing this stage with a sort stage, specify the sort stage after the join.
Examples
Return microsoft_windows_raw records, which are combined with the xdr_data records to include a new column called edr. For the event_type set to
EVENT_LOG, the actor_process_image_name and event_id fields are returned from all xdr_data records, which are then compared to the fields inside
the microsoft_windows_raw dataset, where edr.event_id = edr_event_id, and the results are added to the new edr column.
dataset = microsoft_windows_raw
| join (dataset = xdr_data | filter event_type = EVENT_LOG | fields actor_process_image_name, event_id )
as edr edr.event_id = edr_event_id
Return a maximum of 100 xdr_data records with the events of the agent_id, event_id , and _product fields, where the _product field is displayed as
product. The agent_id, event_id, and _product fields are returned from all xdr_data records and are then compared to the fields inside the
panw_ngfw_filedata_raw dataset, where _time = panw.time, and the results are added to the new panw column. When there is a conflict in the
column names between the 2 result sets both columns are used.
dataset = xdr_data
| fields agent_id, event_id, _product as product
| join conflict_strategy = both (dataset = panw_ngfw_filedata_raw | fields _product as product)
as panw _time = panw._time
| limit 100
17.3.13 | limit
Abstract
Learn more about the Cortex Query Language limit stage that sets the maximum number of records that can be returned in the result set.
Displayed in the footer
Page 781 of 952
Cortex XDR Documentation
Displayed in the header
Syntax
limit <number>
Description
The limit stage sets the maximum number of records that can be returned in the result set. If this stage is not specified in the query, 1,000,000 is used.
Using a small limit can greatly increase the performance of your query by reducing the number of records that Cortex XDR can return in the result set.
Examples
Set the maximum number of records returned by the query to 10.
dataset = xdr_data | limit 10
17.3.14 | replacenull
Abstract
Learn more about the Cortex Query Language replacenull stage that replaces null field values with a text string.
Syntax
replacenull <field> = <text string>
Description
The replacenull stage replaces null field values with the specified text string. This guarantees that every field in your result set will contain a value.
If you use the replacenull stage, then all subsequent stages that refer to the field's null value must use the replacement text string.
Examples
Return the action_country field from every xdr_data records where the action_country field is null, using the text string N/A in the place of an empty
field value.
dataset = xdr_data
| fields action_country as ac
| replacenull ac = "N/A"
| filter ac = "N/A"
17.3.15 | sort
Abstract
Learn more about the Cortex Query Language sort stage that identifies the sort order for records returned in the result set.
Syntax
sort asc|desc <field1>[, asc|desc <field2>...]
Description
The sort stage identifies the sort order for records returned in the result set. Records can be returned in ascending (asc) or descending (desc) order. If you
include more than one field in the sort stage, records are sorted in field specification order.
Keep the following points in mind before running a query with the sort stage:
To acheive the correct sorting results when a query includes strings representing numbers, it's recommend to sort by integer fields and to convert all
string fields to integers; for example, by using the to_integer function.
When sorting by multiple columns, the sort is saved correctly, but the user interface will only display the results according to the first sorted column.
Examples
Return the action_boot_time and event_timestamp fields from all xdr_data records. Sort the result set first by the action_boot_time field value in
descending order, then by event_timestamp field in ascending order.
dataset = xdr_data
| fields action_boot_time as abt, event_timestamp as et
| sort desc abt, asc et
| limit 1
Displayed in the footer
Page 782 of 952
Cortex XDR Documentation
Displayed in the header
17.3.16 | Tag
Abstract
Learn more about the Cortex Query Language tag stage that adds a single tag or list of tags to the _tag system field.
Syntax
Add a single tag:
| tag add <tag name>
Add a list of tags:
| tag add "<tag name1>", "<tag name2>", "<tag name3>",.....
Description
The tag stage is used in combination with the add operator to append a single tag or list of tags to the _tag system field, which you can easily query in the
dataset.
Examples
In the xdr_data dataset, add a single tag called "test" to the _tag system field.
dataset = xdr_data
| tag add "test"
In the xdr_data dataset, add a list of tags, "test1", "test2", and "test3", to the _tag system field.
dataset = xdr_data
| tag add "test1", "test2", "test3"
17.3.17 | target
Abstract
Learn more about the Cortex Query Language target stage that saves query results to a dataset or lookup dataset.
Syntax
target type=dataset|lookup [append=true|false] <dataset name>
Description
The target() stage saves query results to a named dataset or lookup. These are persistent and can be used in subsequent queries. This stage must be the
last stage specified in the query.
The type argument defines the type of dataset to create, when a new one needs to be created. The following types are supported:
dataset: A regular dataset of type USER. Use dataset if you are saving the query results for use in future queries.
lookup: A small lookup table with a 50MB limit. This lookup table can be used with parsing rules and downloaded as a JSON file. Use lookup if you
want to export the query results to a disk.
Optional Append
Use append to define whether the data from the current query should be appended to the dataset (true) or re-created as a new dataset (false). If no
append is included, the default is false. This means that after the query runs the data in an existing dataset is replaced with the new data.
Example 1
Save the results of a simple query to a named dataset.
dataset = xdr_data
| fields action_boot_time as abt
| filter abt != null
| target type=dataset abt_dataset
Subsequently, you can query the new dataset. Notice that the field names used by the new dataset conform to the aliases that you used when you created the
dataset:
dataset = abt_dataset
| filter abt = 1603986614040
Example 2
The following example creates a dataset with the number of agents per country.
Displayed in the footer
Page 783 of 952
Cortex XDR Documentation
Displayed in the header
dataset = xdr_data
| fields agent_id, action_country
| comp count_distinct(agent_id) as count by action_country
| target type=dataset append=false agents_per_country
This results in the following XQL JSON:
{
"tables": [
"xdr_data"
],
"original_query": "\n
dataset=xdr_data\n
| fields agent_id, action_country \n
| comp count_distinct(agent_id) as count by action_country\n
| target type=dataset append=false agents_per_country\n
", "stages":
[
{
"FIELD_SELECT": {
"fields": [
{ "name": "agent_id", "as": None
},
{ "name": "action_country", "as": None
}
],
"exclude": []
}
},
{
"GROUP": {
"aggregations": [
{
"function": "count_distinct",
"parameters": [
"$agent_id"
],
"name": "count"
}
],
"key": [
"action_country"
]
}
}
],
"output": [
{
"TARGET": {
"type": "dataset",
"target": "agents_per_country",
"append": False
}
}
]
}
17.3.18 | top
Abstract
Learn more about the Cortex Query Language top stage that returns the approximate count of top elements for a field and percentage of the count results.
This stage is unsupported with Correlation Rules.
Syntax
top <integer> <field> [by <field1> ,<field2>...] [top_count as <column name>, top_percent as <column name>]
Description
The top stage returns the approximate count of top elements for a given field and the percentage of the count results relative to the total number of values for
the designated field. Use this top stage to produce approximate results, which are more scalable in terms of memory usage and time.
The <integer> in the syntax represents the number of top elements to return. If a number is not specified, up to 10 elements are returned by default. The
approximate count is listed in the results table in a column called TOP_COUNT and the percentage in a column called TOP_PERCENT. You can update the
column names for both tables by defining top_count as <column name> , top_percent as <column name> in the syntax. If you only define one column
name to update in the syntax, the results table displays that column without displaying the other column.
Examples
Returns a table with 3 columns called EVENT_ID, TOP_COUNT, and TOP_PERCENT with up to 10 unique values for event_id with the corresponding counts
and percentages.
Displayed in the footer
Page 784 of 952
Cortex XDR Documentation
Displayed in the header
dataset = xdr_data
| top event_id
Returns a table with 3 columns called ACTION_COUNTRY, EVENT_ID, and TOTAL with a single unique value for the event_id for each action_country
with the corresponding count in the TOTAL column.
dataset = xdr_data
| top 1 event_id by action_country top_count as total
17.3.19 | transaction
Abstract
Learn more about the Cortex Query Language transaction stage used to find transactions based on events that meet certain constraints.
Syntax
transaction <field_1, field_2, ...> [span = <time> [timeshift = <epoch time> [timezone = "<time zone>"]] | startswith = <condition> endswith = <condition>
allowunclosed= true|false] maxevents = <number of events per transaction>
Description
The transaction stage is used to find transactions based on events that meet certain constraints. This stage aggregates all fields in a JSON string array by
fields defined as transaction fields. For example, using the transaction stage to find transactions based on the user and user_ip fields will make the
aggregation of json strings of all fields by the user and user_ip fields. A maximum of 50 fields can be aggregated in a transation stage.
You can also configure whether the transactions falls within a certain time frame, which is optional to define. You can set one of the following:
span=<time>: Use this command to set a time frame per transaction, where <time> is a combination of a number and time suffix. Set one time suffix
from the list of available options listed in the table below. In addition, you can define a particular start time for grouping the events in your query
according to the Unix epoch time by setting timeshift = <epoch time> timezone = "<time zone>", which are both optional. You can
configure the <time zone> offset using an hours offset, such as “+08:00”, or using a time zone name from the List of Supported Time Zones, such as
"America/Chicago". The query still runs without defining the epoch time or time zone. If no timeshift = <epoch time> timezone = "<time
zone>" is set, the query runs according to last time set in the log.
startswith and endswith: Use these commands to set a condition for the beginning or end of the transaction, where the condition can be a logical
expression or free text search.
Set the allowunclosed flag to true to include transactions which don't contain an ending event. The last event will be 12 hours after the starting event. By
default, this is set to true and transactions without an ending event are included.
Use the maxevents command to define the maximum number of events to include per transaction. If this command is not set, the default value is 100.
When using the transaction stage, 5 additional fields are added to the results displayed:
_start_time: Indicates the initial timestamp of the transaction.
_end_time: Indicates the last timestamp for the transaction.
_duration: Displays the difference in seconds between the timestamps for the first and last events in the transaction.
_num_of_rows: Indicates the number of events in the transaction.
_transaction_id: Displays the unique transaction ID.
Time Suffix Description
MS milliseconds
S seconds
M minutes
H hours
D days
Displayed in the footer
Page 785 of 952
Cortex XDR Documentation
Displayed in the header
Time Suffix Description
W weeks
MO months
Y years
Example using Span
Return a maximum of 10 events per transaction from the xdr_data records based on the user and agent_id fields, where the transaction time frame is 1
hour.
dataset=xdr_data
|transaction user, agent_id span=1h timeshift = 1615353499
timezone = “+08:00” maxevents=10
This query results in the following XQL JSON:
{'TRANSACTION': {'fields': ['user', 'agent_id'], 'maxevents': 10, 'span': {'amount': 1, 'units': 'h', 'timeshift': None}}}
Example using Startswith and Endswith
Return a maximum of 99 events per transaction from the xdr_data records based on the f1 and f2 fields. The starting event of each transaction is an event,
where one of the fields contains a string "str_1", and the ending event of each transaction is an event, where one of the fields contains a string "str_2".
dataset=xdr_data
| transaction f1, f2 startswith="str_1" endswith="str2" maxevents=99
This query results in the following XQL JSON:
{'TRANSACTION': {'fields': ['f1', 'f2'], 'search': {'startswith': {'filter': {'free_text': 'str_1'}}, 'endswith': {'filter': {'free_text': 'str2'}}}, 'maxevents':
99}}
17.3.20 | union
Abstract
Learn more about the Cortex Query Language union stage that combines two result sets into a single result set.
Syntax
union <datasetname>
union (<inner xql query>)
Description
The union() stage combines two result sets into one result. It can be used in two different ways.
If a dataset name is provided with no other arguments, the two datasets are combined for the duration of the query, and the fields in both datasets are
available to subsequent stages.
If a Cortex Query Language (XQL) query is provided to this stage, the result set from that XQL union query is combined with the result set from the rest of the
query. This is effectively an inner join statement.
Examples
First, create a dataset using the target stage. This results in a persistent stage that we can use later with a union stage.
dataset = xdr_data
| filter event_type = FILE and event_sub_type = FILE_WRITE
| fields agent_id, action_file_sha256 as file_hash, agent_hostname
| target type=dataset file_event
Then run a second query, using union so that the query can access the contents of the file_event dataset. Notice that this second query uses the
file_hash alias that was defined for the file_event dataset.
dataset = xdr_data
| filter event_type = PROCESS and event_sub_type = PROCESS_START
| union file_event
| fields agent_id, agent_hostname, file_hash,
actor_process_image_path as executed_by,
Displayed in the footer
Page 786 of 952
Cortex XDR Documentation
Displayed in the header
actor_process_signature_vendor as executor_signer
| filter file_hash != null and executed_by != null
17.3.21 | view
Abstract
Lear more about the Cortex Query Language view stage that configures the display of the result set.
Syntax
view highlight fields = <field1>[,<field2>,...] values = <value1>[,<value2>,...]
view graph type = column|line|pie xaxis = <field1>
yaxis = <field2> [<optional parameters>]
view column order = default|populated
Description
The view() stage configures the display of the result set in the following ways:
highlight: Highlights specified strings that Cortex XDR finds on specified fields. The highlight values that you provide are performed as a substring
search, so only partial value can be highlighted in the final results table.
graph type: Creates a column, line, or pie chart based on the values found for the fields specified in the xaxis and yaxis parameters. In this mode,
view also offers a large number of parameters that allow you to control colors, decorations, and other behavior used for the final chart. You can also
define a graph subtype, when setting the graph type to either column or pie.
If you use graph type, the fields specified for xaxis and yaxis must be collatable or the query will fail.
column order: Enables you to list the query results by popularity, where the most non-null returned fields are displayed first using the syntax view
column order = populated. By default, if column order is not defined (or view column order=default), the original column order is used.
This option does not apply to Cortex Query Language (XQL) queries in widgets, Correlation Rules, public APIs, reports, and dashboards. If you include
the view column order syntax in these types of queries, Cortex XDR disregards the stage from the query and completes the rest of the query.
Examples
Use the dedup stage collect unique combinations of event_type and event_sub_type values. Highlight the word "STREAM" when it appears in the result
set.
dataset = xdr_data
| fields event_type, event_sub_type
| dedup event_type, event_sub_type by asc _time
| view highlight fields = event_sub_type values = "STREAM"
Count the number of unique files accessed by each user, and show a column graph of the results. This query uses comp count_distinct to calculate the
number of unique files per username.
dataset = xdr_data
| fields actor_effective_username as username, action_file_path as file_path
| filter file_path != null and username != null
| comp count_distinct(file_path) as file_count by username
| view graph type = column xaxis = username yaxis = file_count
Count the number of unique files accessed by each user, and display the results by popularity according to the most non-null values returned fields. This
query uses comp count_distinct to calculate the number of unique files per username.
dataset = xdr_data
| fields actor_effective_username as username, action_file_path as file_path
| filter file_path != null and username != null
| comp count_distinct(file_path) as file_count by username
| view column order = populated
17.3.22 | windowcomp
Abstract
Learn more about the Cortex Query Language windowcomp stage that precedes functions calculating statistics.
Syntax
windowcomp <analytic function> (<field>)[by <fieldA> [,<fieldB>,...]] [sort [asc|desc] <field1> [, [asc|desc] <field2>,...]] [between 0|null|<number>|-<number>
[and 0|null|<number>|-<number>] [frame_type=range]] [as <alias>]
Defining a field with an analytic function is optional when using a count function. For rank and row_number functions, it's not allowed.
Displayed in the footer
Page 787 of 952
Cortex XDR Documentation
Displayed in the header
Description
The windowcomp stage precedes functions calculating statistics. The results compute values over a group of rows and return a single result for each row, for
all records that contain matching values for the fields identified using a combination of the by clause, sort, and range. Only one function can be defined per
field, while the other parameters are optional. Yet, it's possible to define multiple fields.
Example 93.
| windowcomp sum(field_1) by field_2 sort field_3 as field_4, min(field_5) by field_6 sort field_7 as field_8
Supported functions
This stage includes the following functions:
Function Type Function
Numbering functions rank
row_number
Navigation functions first_value
lag
last_value
Statistical aggregate functions stddev_sample
stddev_population
Aggregate functions avg
count
max
median
min
sum
Optional parameters
The optional parameters available to define in the windowcomp function are explained in the following table:
Optional Parameters Syntax Description
By clause [by <fieldA> [, The by clause is used to break up the input field rows into separate partitions, over which
<fieldB>,...] the windowcomp function is independently evaluated.
Multiple partition fields are allowed when using a partition by clause.
When this optional clause is omitted, all rows in the input table comprise a single
partition.
Sort [sort [asc|desc] <field1> Defines how field rows are ordered within a partition as either ascending (asc) or
[,[asc|desc] descending (desc). This clause is optional in most situations, but is required in some
<field2>,...]] cases for navigation functions and rank function.
Displayed in the footer
Page 788 of 952
Cortex XDR Documentation
Displayed in the header
Optional Parameters Syntax Description
Between window frame [between 0|null| Sets the window frame around the current row within a partition, over which the window
clause <number>|-<number> [and function is evaluated. Numbering functions and the lag function can't be used in the
0|null|<number>|- window frame clause. Creates a window frame with a lower and upper boundary. The first
<number>] boundary represents the lower boundary. The second boundary represents the upper
boundary. Every boundary can include the following options:
null: Starts at the beginning or at the end of the partition, depending on the
placement of the null.
0: Is set to the current row, where the window frame starts or ends at the current row.
positive/negative <number>: The end of the window frame or the start of the window
frame relative to the current row.
If only a start <number> is defined, only a negative number is allowed: -
<number>.
If a start <number> and end <number> are defined, the end <number> must
be greater than the start <number>.
If the sort is included, but the window frame clause isn't, the following window frame
clause is used by default:
between null and 0
frame_type [frame_type=rows| range] Defines the option of the frame as either:
rows (default): Computes the window frame based on physical offsets from the
current row. For example, you could include two rows before and after the current
row. To apply the default frame_type=rows, nothing needs to be added to the
windowcomp stage syntax as it's automatically built into the query.
range: Computes the window frame based on a logical range of rows around the
current row, based on the current row’s sort key value. The provided range value is
added or subtracted to the current row's key value to define a starting or ending
range boundary for the window frame. Setting the range with start or end numeric,
nonzero boundaries requires using exactly one numeric type of sort field.
When setting frame_type=range, the sort must be included in the windowcomp
stage syntax; otherwise, only between null and null is supported.
Example 94.
This is unsupported:
| windowcomp sum(field_a) between -2 and 0 frame_type = range
Yet, the following is supported:
| windowcomp sum(field_a) sort desc field_b between -1 and 1 frame_type = range
Or
| windowcomp sum(field_a) between null and null frame_type = range
Alias clause [as <alias>] Use the alias clause to provide a column label (field name) for the windowcomp results.
When the new field name already exists in the schema, it's replaced with the new name.
Example 95.
If the xdr_data dataset already has a field in the schema called existing_field, the
new existing_field replaces the old one.
dataset = xdr_data
| windowcomp sum(field_a) as existing_field
Displayed in the footer
Page 789 of 952
Cortex XDR Documentation
Displayed in the header
Examples
Data table for ips dataset
The examples provided are based on the following data table for a dataset called ips:
Ip Category Logins
192.168.10.1 pc 23
192.168.10.2 server 2
192.168.20.1 pc 9
192.168.20.4 server 8
192.168.20.5 pc 2
192.168.30.1 pc 10
Query 1: Compute thetotal logins for all IPs
dataset = ips
| windowcomp sum(logins) as total_logins
Output results table
Ip Logins Category Total_logins
192.168.10.2 2 server 54
192.168.20.5 2 pc 54
192.168.20.4 8 server 54
192.168.20.1 9 pc 54
192.168.30.1 10 pc 54
192.168.10.1 23 pc 54
Query 2: Compute a subtotal for each category
dataset = ips
| windowcomp sum(logins) by category sort asc logins between null and null as total_logins
Output results table
Ip Logins Category Total_logins
192.168.10.2 2 server 10
Displayed in the footer
Page 790 of 952
Cortex XDR Documentation
Displayed in the header
Ip Logins Category Total_logins
192.168.20.4 8 server 10
192.168.20.5 2 pc 44
192.168.20.1 9 pc 44
192.168.30.1 10 pc 44
192.168.10.1 23 pc 44
Query 3: Compute a cumulative sum for each category
The sum is computed with respect to the order defined using the sort clause. These two queries produce the same results:
dataset = ips
| windowcomp sum(logins) by category sort asc logins between null and 0 as total_logins
OR
dataset = ips
| windowcomp sum(logins) by category sort asc logins between null as total_logins
Output results table
Ip Logins Category Total_logins
192.168.10.2 2 server 2
192.168.20.4 8 server 10
192.168.20.5 2 pc 2
192.168.20.1 9 pc 11
192.168.30.1 10 pc 21
192.168.10.1 23 pc 44
Query 4: Compute a cumulative sum, where only preceding rows are analyzed.
The analysis starts two rows before the current row in the partition.
dataset = ips
| windowcomp sum(logins) sort asc logins between null and -2 as total_logins
Output results table
Ip Logins Category Total_logins
192.168.10.2 2 server NULL
192.168.20.5 2 pc NULL
Displayed in the footer
Page 791 of 952
Cortex XDR Documentation
Displayed in the header
Ip Logins Category Total_logins
192.168.20.4 8 server 2
192.168.20.1 9 pc 4
192.168.30.1 10 pc 12
192.168.10.1 23 pc 21
Query 5: Compute a changing average
The lower boundary is 1 row before the current row. The upper boundary is 1 row after the current row.
dataset = ips
| windowcomp avg(logins) sort asc logins between -1 and 1 as avg_logins
Output results table
Ip Logins Category Avg_logins
192.168.10.2 2 server 2
192.168.20.5 2 pc 4
192.168.20.4 8 server 6.33333
192.168.20.1 9 pc 9
192.168.30.1 10 pc 14
192.168.10.1 23 pc 16.5
Query 6: Retrieve the most popular IP in each category
Defines how rows in a window are partitioned and ordered in each partition.
dataset = ips
| windowcomp last_value(ip) by category sort asc logins between null and null as most_popular
Output results table
Ip Logins Category Most_popular
192.168.10.2 2 server 192.168.20.4
192.168.20.4 8 server 192.168.20.4
192.168.20.5 2 pc 192.168.10.1
192.168.20.1 9 pc 192.168.10.1
Displayed in the footer
Page 792 of 952
Cortex XDR Documentation
Displayed in the header
Ip Logins Category Most_popular
192.168.30.1 10 pc 192.168.10.1
192.168.10.1 23 pc 192.168.10.1
Query 7: Calculate the rank of each IP within the category based on the login
dataset = ips
| windowcomp rank() by category sort asc logins as rank
Output results table
Ip Logins Category Rank
192.168.10.2 2 server 1
192.168.20.4 8 server 2
192.168.20.5 2 pc 1
192.168.20.1 9 pc 2
192.168.30.1 10 pc 3
192.168.10.1 23 pc 4
Query 8: Retrieve the most popular IP in a specific window frame by range and not category
The window frame analyzes up to three rows at a time.
dataset = ips
| windowcomp last_value(ip) by category sort asc logins between -1 and 1 as most_popular
Output results table
Ip Logins Category Most_popular
192.168.10.2 2 server 192.168.20.4
192.168.20.4 8 server 192.168.20.4
192.168.20.5 2 pc 192.168.20.1
192.168.20.1 9 pc 192.168.30.1
192.168.30.1 10 pc 192.168.10.1
192.168.10.1 23 pc 192.168.10.1
Query 9: Retrieve the number of IPs that have similar logins
Displayed in the footer
Page 793 of 952
Cortex XDR Documentation
Displayed in the header
Count in range of -1 and 1 from their login value.
dataset = ips | fields ip, category , logins
| windowcomp count() sort asc logins between -1 and 1 frame_type = range as similar_logins
Output results table
Ip Logins Category Similar_logins
192.168.10.5 2 pc 2
192.168.10.2 2 server 2
192.168.20.4 8 server 2
192.168.20.1 9 pc 3
192.168.30.1 10 pc 2
192.168.10.1 23 pc 1
17.4 | Functions
Abstract
Learn more the functions that can be used with Cortex Query Language (XQL) stages in Cortex XDR.
Some Cortex Query Language (XQL) stages can call XQL functions to convert the data to a desired format. For example, the current_time() function
returns the current timestamp, while the extract_time() function can obtain the hour information in the timestamp. Functions may or may not need input
parameters. The filter and alter stages are the two stages that can use functions for data transformations.
17.4.1 | add
Abstract
Learn more about the Cortex Query Language add() function that adds two integers.
Syntax
add (<string> | <integer>, <string> | <integer>)
Description
The add() function adds two positive integers. Parameters can be either integer literals, or integers as a string type, such as might be contained in a data
field.
Example
dataset = xdr_data
| alter mynum = add(action_file_size, 3)
| fields action_file_size, mynum
| filter action_file_size > 0
| limit 1
17.4.2 | approx_count
Abstract
Learn more about the Cortex Query Language approx_count approximate aggregate comp function.
Syntax
comp approx_count(<field>) [as <alias>] [by <field1>[,<field2>...]] [addrawdata = true|false [as <target field>]]
Displayed in the footer
Page 794 of 952
Cortex XDR Documentation
Displayed in the header
Description
The approx_count approximate aggregate is a comp function that counts the number of distinct values in the given field over a group of rows. For the group
of rows, the function returns an approximate result as a single interger value, for all records that contain matching values for the fields identified in the by
clause. Use this approximate aggregate function to produce approximate results, instead of exact results used with regular aggregate functions, which are
more scalable in terms of memory usage and time. This approximate aggregate function is used in combination with a comp stage.
In addition, you can configure whether the raw data events are displayed by setting addrawdata to either true or false (default), which are used to configure
the final comp results. When including raw data events in your query, the query runs for up to 50 fields that you define and displays up to 100 events.
Example
Returns a single integer value after approximately counting the number of distinct values in the event_id field over a group of rows.
dataset = xdr_data
| fields event_id
| comp approx_count(event_id)
17.4.3 | approx_quantiles
Abstract
Learn more about the Cortex Query Language approx_quantiles approximate aggregate comp function.
Syntax
comp approx_quantiles(<field>, <number>, <true|false>) [as <alias>] [by <field1>[,<field2>...]][addrawdata = true|false [as <target field>]]
Description
The approx_quantiles approximate aggregate is a comp function returns the approximate boundaries as a single value for a group of distinct or non-
distinct values (default false) for the specified field over a group of rows, for all records that contain matching values for the fields identified in the by clause.
This function returns an array of <number> + 1 elements, where the first element is the approximate minimum and the last element is the approximate
maximum. Use this approximate aggregate function to produce approximate results, instead of exact results used with regular aggregate functions, which are
more scalable in terms of memory usage and time. This approximate aggregate function is used in combination with a comp stage.
In addition, you can configure whether the raw data events are displayed by setting addrawdata to either true or false (default), which are used to
configure the final comp results. When including raw data events in your query, the query runs for up to 50 fields that you define and displays up to 100 events.
Examples
Distinct Values Example
Returns the approximate boundaries for a group of distinct values in the event_id field.
dataset = xdr_data
| fields event_id
| comp approx_quantiles(event_id, 100, true)
Non-Distinct Values Example
Returns the approximate boundaries for a group of non-distinct values in the event_id field.
dataset = xdr_data
| fields event_id
| comp approx_quantiles(event_id, 100)
17.4.4 | approx_top
Abstract
Learn more about the Cortex Query Language approx_top approximate aggregate comp function.
Syntax
comp approx_top as count
comp approx_top(<string field>, <number>) [as <alias>] [by <field1>[,<field2>...]][addrawdata = true|false [as <target field>]]
comp approx_top as sum
comp approx_top(<string field>, <number>, <weight string field>) [as <alias>] [by <field1>[,<field2>...]][addrawdata = true|false [as <target field>]]
Displayed in the footer
Page 795 of 952
Cortex XDR Documentation
Displayed in the header
Description
The approx_top approximate aggregate is a comp function that, depending on the number of parameters, returns either an approximate count or sum of top
elements. This approximate aggregate function returns a single value for the given field over a group of rows, for all records that contain matching values for
the fields identified in the by clause. This function is used in combination with a comp stage. When a third parameter is specified, it references a field that
contains a numeric value (weight) that is used to calculate a sum. The return value is an array with up to <number> of JSON strings. Each string represents an
object (struct) containing 2 keys and corresponding values. The keys depend on whether a third parameter has been supplied or not.
When defining approx_top to count and the third parameter is omitted, each struct will have these keys: "value" and "count", where the "value" specifies a
unique field value and "count" specifies the number of occurrences. When the third parameter is specified in approx_top, it has to be a name of a field that
contains a numeric value that is used to calculate the final sum for each unique value in the first specified field. Each struct in this case will have these keys:
"value" and "sum".
In addition, you can configure whether the raw data events are displayed by setting addrawdata to either true or false (default), which are used to
configure the final comp results. When including raw data events in your query, the query runs for up to 50 fields that you define and displays up to 100 events.
Use this approximate aggregate function to produce approximate results, instead of exact results used with regular aggregate functions, which are more
scalable in terms of memory usage and time.
Examples
comp approx_top as count
Returns an approximate count of the top 10 agent IDs in the agent_id field that appear the most frequently. The return value is an array containing 10 JSON
strings with a "value" and "count".
dataset = xdr_data
| fields agent_id
| comp approx_top(agent_id, 10)
comp approx_top as sum
Returns an approximate sum of the top 10 agent IDs in the agent_id field by their action_session_duration. The return value is an array containing 10
JSON strings with a "value" and "sum" for each agent_id.
dataset = xdr_data
| fields agent_id, action_session_duration
| comp approx_top(agent_id, 10, action_session_duration)
17.4.5 | array_all
Abstract
Learn more about the Cortex Query Language array_all() function.
Syntax
array_all(<array>, "@element"<operator>"<array element>")
The <operator> can be any of the ones supported, such as = and !=.
Description
The array_all() function returns true when all the elements in a particular array match the condition in the specified array element. Otherwise, the function
returns false.
Example
When the dfe_labels array is not empty, use the alter stage to create a new column called x that returns true when all the elements in the dfe_labels
array is equal to network; otherwise, the function returns false.
dataset = xdr_data
| filter dfe_labels != null
| alter x = array_all(dfe_labels , "@element" = "network")
| fields x, dfe_labels
| limit 100
17.4.6 | array_any
Abstract
Learn more about the Cortex Query Language array_any() function.
Displayed in the footer
Page 796 of 952
Cortex XDR Documentation
Displayed in the header
Syntax
array_any(<array>, "@element"<operator>"<array element>")
The <operator> can be any of the ones supported, such as = and !=.
Description
The array_any() function returns true when at least 1 element in a particular array matches the condition in the specified array element. Otherwise, the
function returns false.
Example
When the dfe_labels array is not empty, use the alter stage to create a new column called x that returns true when at least 1 element in the dfe_labels
array is equal to network; otherwise, the function returns false.
dataset = xdr_data
| filter dfe_labels != null
| alter x = array_any(dfe_labels , "@element" = "network")
| fields x, dfe_labels
| limit 100
17.4.7 | arrayconcat
Abstract
Learn more about the Cortex Query Language arrayconcat() function that returns an array containing unique values found in the original array.
Syntax
arrayconcat (<array1>,<array2>[,<array3>...])
Description
The arrayconcat() function accepts two or more arrays, and it joins them into a single array.
Example
Given three arrays:
first_array : [1,2,3]
second_array : [44,55]
third_array : [4,5,6]
Using this query:
alter all_arrays = arrayconcat(first_array, second_array, third_array)
Results in an all_arrays field containing:
[1,2,3,44,55,4,5,6]
17.4.8 | arraycreate
Abstract
Learn more about the Cortex Query Language arraycreate() function that returns an array based on the given parameters defined for the array elements.
Syntax
arraycreate ("<array element1>", "<array element2>",...)
Description
The arraycreate() function returns an array based on the given parameters defined for the array elements.
Example
Returns a final array to a field called x that is comprised of the elements [1,2].
dataset = xdr_data
| alter x = arraycreate("1", "2")
| fields x
Displayed in the footer
Page 797 of 952
Cortex XDR Documentation
Displayed in the header
17.4.9 | arraydistinct
Abstract
Learn more about the Cortex Query Language arraydistinct() function that returns an array containing unique values found in the original array.
Syntax
arraydistinct (<array>)
Description
The arraydistinct() function accepts an array, and it returns a new array containing only unique elements found in the original array. That is, given the
array:
[0,1,1,1,4,5,5]
This function returns:
[0,1,4,5]
17.4.10 | arrayfilter
Abstract
Learn more about the Cortex Query Language arrayfilter() function.
Syntax
arrayfilter(<array>, <condition>)
arrayfilter(<array>, "@element"<operator>"<array element>")
The <operator> can be any of the ones supported, such as = and !=.
Description
The arrayfilter() function returns a new array with the elements which meet the given condition. The function does this by filtering the results of an array in
one of the following ways:
Returns the results when a certain condition is applied to the array.
Returns the results when a particular array is set to a specified array element.
Though it's possible to define the arrayfilter() function with any condition, the examples below focus on conditions using the @element that are based
on the current element being tested.
Basic Example
When the dfe_labels array is not empty, use the alter stage to assign a value to a field called x that returns the value of the arrayfilter function. The
arrayfilter function filters the dfe_labels array for the array element set to network.
dataset = xdr_data
| filter dfe_labels != null
| alter x = arrayfilter(dfe_labels , "@element" = "network")
| fields x, dfe_labels
| limit 100
Advanced Example
This queries below illustrate how to check whether any IPs are included or not included in the blocked list called CIDRS. The Query Results tables are also
included to help explain what happens as the arrayfilter() function is slightly modified.
Return Non-Matching CIDRS
This query returns results for each IP that don't match anything in the CIDRS array blocked list:
dataset = xdr_data
| limit 1
| alter cidrs = arraycreate("10.0.0.0/8","172.16.0.0/16"), ip = arraycreate("192.168.1.1", "172.16.20.18")
| fields cidrs, ip
| arrayexpand ip
| alter non_matching_cidrs = arrayfilter(cidrs, ip not incidr "@element")
Results:
The following table details for each IP the logic that is first performed before the final results for the query are displayed:
Displayed in the footer
Page 798 of 952
Cortex XDR Documentation
Displayed in the header
IP Statement TRUE/FALSE
192.168.1.1 not in 10.0.0.0/8 TRUE
192.168.1.1 not in 172.16.0.0/16 TRUE
172.16.20.18 not in 10.0.0.0/8 TRUE
172.16.20.18 not in 172.16.0.0/16 FALSE
For each IP, an array of CIDRS is returned in the NON_MATCHING_CIDRS column, which doesn't match the CIDRS array. In addition, from the above table,
arrayfilter() only returns anything that resolves as TRUE. This explains the query results displayed in the following table:
IP CIDRS NON_MATCHING_CIDRS
192.168.1.1 10.0.0.0/8,172.16.0.0/16 10.0.0.0/8,172.16.0.0/16
172.16.20.18 10.0.0.0/8,172.16.0.0/16 10.0.0.0/8
Return Matching CIDRS
Now, let's update the query to return results for each IP that match anything in the CIDRS array:
dataset = xdr_data
| limit 1
| alter cidrs = arraycreate("10.0.0.0/8","172.16.0.0/16"), ip = arraycreate("192.168.1.1", "172.16.20.18")
| fields cidrs, ip
| arrayexpand ip
| alter matching_cidrs = arrayfilter(cidrs, ip incidr "@element")
Results:
The following table details for each IP the logic that is first performed before the final results for the query are displayed:
IP Statement TRUE/FALSE
192.168.1.1 in 10.0.0.0/8 FALSE
192.168.1.1 in 172.16.0.0/16 FALSE
172.16.20.18 in 10.0.0.0/8 FALSE
172.16.20.18 in 172.16.0.0/16 TRUE
For each IP, an array of CIDRS is returned in the MATCHING_CIDRS column, which matches the CIDRS array. In addition, from the above table,
arrayfilter() only returns anything that resolves as TRUE. This explains the query results displayed in the following table:
IP CIDRS MATCHING_CIDRS
192.168.1.1 10.0.0.0/8,172.16.0.0/16 empty array
Displayed in the footer
Page 799 of 952
Cortex XDR Documentation
Displayed in the header
IP CIDRS MATCHING_CIDRS
172.16.20.18 10.0.0.0/8,172.16.0.0/16 172.16.0.0/16
17.4.11 | arrayindex
Abstract
Learn more about the Cortex Query Language arrayindex() function that returns the array element contained at the specified index.
Syntax
arrayindex(<array>, <index>)
Description
The arrayindex() function returns the value contained in the specified array position. Arrays are 0-based, and negative indexing is supported.
Examples
Use the split function to split IP addresses into an array of octets. Return the 3rd octet contained in the IP address.
dataset = xdr_data
| fields action_local_ip as alii
| alter ip_third_octet = arrayindex(split(alii, "."), 2)
| filter alii != null and alii != "0.0.0.0"
| limit 10
17.4.12 | arrayindexof
Abstract
Learn more about the Cortex Query Language arrayindexof() function that returns the index value of an array.
Syntax
arrayindexof(<array>, <condition>)
arrayindexof(<array>, "@element"<operator>"<array element>")
The <operator> can be any of the ones supported, such as = and !=.
Description
The arrayindexof() function enables you to return a value related to an array in one of the following ways.
Returns 0 if a particular array is not empty and the specified condition is true. If the condition is not met, a NULL value is returned.
Returns the 0-based index of a particular array element if a particular array is not empty and the specified condition using an @element is true. If the
condition is not met, a NULL value is returned.
Examples
Condition
Use the alter stage to assign a value returned by the arrayindexof function to a field called x. The arrayindexof function reviews the dfe_labels array
and returns 0 if the array is not empty and the backtrace_identities array contains more than 1 element. Otherwise, a NULL value is assigned to the x
field.
dataset in (xdr_data)
| alter x = arrayindexof(dfe_labels , array_length(backtrace_identities) > 1)
| fields x, dfe_labels
| limit 100
@Element
When the dfe_labels array is not empty, use the alter stage to assign the 0-based index value returned by the arrayindexof function to a field called x.
The arrayindexof function reviews the dfe_labels array and looks for the array element set to network. Otherwise, a NULL value is assigned to the x
field.
dataset = xdr_data
| filter dfe_labels != null
Displayed in the footer
Page 800 of 952
Cortex XDR Documentation
Displayed in the header
| alter x = arrayindexof(dfe_labels , "@element" = "network")
| fields x, dfe_labels
| limit 100
17.4.13 | array_length
Abstract
Learn more about the Cortex Query Language array_length() function that returns the length of an array.
Syntax
array_length (<array>)
Description
The array_length() function returns the number of elements in an array.
Example
dataset = xdr_data
| fields action_local_ip as alii
| alter ip_len = array_length(split(alii, "."))
| filter alii != null and alii != "0.0.0.0"
| limit 1
17.4.14 | arraymap
Abstract
Learn more about the Cortex Query Language arraymap() function that applies a callable function to every element of an array.
Syntax
arraymap (<array>, <function()>)
Description
The arraymap() function applies a specified function to every element of an array. For functions that require a fieldname, use "@element".
Examples
Extract the MAC address from the agent_interface_map field. This example uses the json_extract_scalar, to_json_string, json_extract_array, and
arraystring functions to extract the desired information.
dataset = xdr_data
| alter mac =
arraystring (
arraymap (
json_extract_array (to_json_string(agent_interface_map),"$."),
json_extract_scalar ("@element", "$.mac")
), ",")
17.4.15 | arraymerge
Abstract
Learn more about the Cortex Query Language arraymerge() function that returns an array created from a merge of the inner json-string arrays.
Syntax
arraymerge(<field>)
Description
The arraymerge() function returns an array, which is created from a merge of the inner json-string arrays, including merging a number of arraymap() function
arrays. This function accepts a single array of json-strings, which is the <field> in the syntax.
Example 1
Returns a final array called result that is created from a merge of the inner json-string arrays from array x and array y with the values ["a", "b", "c", "d"].
dataset = xdr_data
| alter x= to_json_string(arraycreate("a","b")), y = to_json_string(arraycreate("c","d"))
Displayed in the footer
Page 801 of 952
Cortex XDR Documentation
Displayed in the header
| alter xy = arraycreate(x,y)
| alter xy=arraymerge(xy)
Example 2
Returns a final array that is created from a merge of the arraymap by extracting the IP address from the agent_interface_map field and the first IPV4 address
found in the first element of the agent_interface_map array. This example uses the to_json_string and json_extract_array functions to extract the desired
information.
dataset = xdr_data
| alter a =
arraymerge (arraymap (agent_interface_map, to_json_string (json_extract_array (to_json_string("@element"), "$.ipv4") ) ) )
17.4.16 | arrayrange
Abstract
Learn more about the Cortex Query Language arrayrange() function that returns a portion of an array based on specified array indices.
Syntax
arrayrange (<array>, <start>, <end>)
Description
The arrayrange() function returns a portion, or a slice, of an array given a start and end range. Indices are 0-based, and the start range is inclusive, but the
end range is exclusive.
Example
So if you have an array:
[0,1,2,3,4,5,6]
and you specify:
arrayrange(<array>, 2, 4)
the function will return:
[2,3]
If you specify an end index that is higher than the last element in the array, the resulting array contains the starting element to the end of the array.
arrayrange(<array>, 2, 8)
the function will return:
[2,3,4,5,6]
17.4.17 | arraystring
Abstract
Learn more about the Cortex Query Language arraystring() function that returns a string from an array, where each array element is joined by a defined
delimiter.
Syntax
arraystring (<string>, <delimiter>)
Description
The arraystring() function returns a string from an array, where each array element is joined by a defined delimiter.
Examples
Retrieve all action_app_id_transitions that are not null, combine each array into a string where array elements are delimited by " : ", and then use
dedup the resulting string.
dataset = xdr_data
| fields action_app_id_transitions as aait
| alter transitions_string = arraystring(aait, " : ")
| dedup transitions_string by asc _time
| filter aait != null
Displayed in the footer
Page 802 of 952
Cortex XDR Documentation
Displayed in the header
17.4.18 | avg
Abstract
Learn more about the Cortex Query Language avg used with both comp and windowcomp stages.
Syntax
comp stage
comp avg(<field>) [as <alias>] by <field_1>,<field_2> [addrawdata = true|false [as <target field>]]
windowcomp stage
windowcomp avg(<field>) [by <field> [,<field>,...]] [sort [asc|desc] <field1> [, [asc|desc] <field2>,...]] [between 0|null|<number>|-<number> [and 0|null|
<number>|-<number>] [frame_type=range]] [as <alias>]
Description
The avg() function is used to return the average value of an integer field over a group of rows. The function syntax and application is based on the preceding
stage:
comp stage
When the avg aggregation function is used with a comp stage, the function returns a single average value of an integer field for a group of rows, for all records
that contain matching values for the fields identified in the by clause.
In addition, you can configure whether the raw data events are displayed by setting addrawdata to either true or false (default), which are used to
configure the final comp results. When including raw data events in your query, the query runs for up to 50 fields that you define and displays up to 100 events.
windowcomp stage
When the avg aggregate function is used with a windowcomp stage, the function returns a single average value of an integer field for each row in the group of
rows, for all records that contain matching values for the fields identified using a combination of the by clause, sort, and between window frame clause. The
results are provided in a new column in the results table.
Examples
comp example
Return a single average value of the action_total_download field for a group of rows, for all records that have matching values for their
actor_process_image_path and actor_process_command_line values. The query calculates a maximum of 100 xdr_data records and includes a
raw_data column listing a single value for the results.
dataset = xdr_data
| fields actor_process_image_path as Process_Path, actor_process_command_line as Process_CMD, action_total_download as Download
| filter Download > 0
| limit 100
| comp avg(Download) as average_download by Process_Path, Process_CMD
addrawdata = true as raw_data
windowcomp example
Return the events that are above average per Process_Path and Process_CMD. The query returns a maximum of 100 xdr_data records in a column called
avg_download.
dataset = xdr_data
| fields actor_process_image_path as Process_Path, actor_process_command_line as Process_CMD, action_total_download as Download
| filter Download > 0
| limit 100
| windowcomp avg(Download) by Process_Path, Process_CMD as avg_download
| filter Download > avg_download
17.4.19 | coalesce
Abstract
Learn more about the Cortex Query Language coalesce() function that returns the first value that is not null from a defined list of fields.
Syntax
coalesce (<field_1>, <field_2>,...<field_n>)
Description
The coalesce() function takes an arbitrary number of arguments and returns the first value that is not NULL.
Displayed in the footer
Page 803 of 952
Cortex XDR Documentation
Displayed in the header
Example
Given a list of fields that contain usernames, select the first one that is not null and display it in the username column.
dataset = xdr_data
| fields actor_primary_username,
os_actor_primary_username,
causality_actor_primary_username
| alter username = coalesce(actor_primary_username,
os_actor_primary_username,
causality_actor_primary_username)
17.4.20 | concat
Abstract
Learn more about the Cortex Query Language concat() function joins multiple strings into a single string.
Syntax
concat (<string1>, <string2>, ...)
Description
The concat() function joins multiple strings into a single string.
Example
Display the first non-NULL action_boot_time field value. In a second column called abt_string, use the concat() function to prepend "str: " to the
value, and then display it.
dataset = xdr_data
| fields action_boot_time as abt
| filter abt != null
| alter abt_string = concat("str: ", to_string(abt))
| limit 1
17.4.21 | convert_from_base_64
Abstract
Learn more about the Cortex Query Language convert_from_base_64 function.
Syntax
convert_from_base_64("<base64-encoded input>")
Description
The convert_from_base_64() function converts the base64-encoded input to the decoded string format.
Example
Returns the decoded string format Hello world from the base64-encoded input "SGVsbG8gd29ybGQ=".
convert_from_base_64("SGVsbG8gd29ybGQ=")
17.4.22 | count
Abstract
Learn more about the Cortex Query Language count function used with both comp and windowcomp stages.
Syntax
comp stage
comp count([<field>]) [as <alias>] by <field_1>,<field_2> [addrawdata = true|false [as <target field>]]
windowcomp stage
windowcomp count([<field>]) [by <field> [,<field>,...]] [sort [asc|desc] <field1> [, [asc|desc] <field2>,...]] [between 0|null|<number>|-<number> [and 0|null|
<number>|-<number>] [frame_type=range]] [as <alias>]
Displayed in the footer
Page 804 of 952
Cortex XDR Documentation
Displayed in the header
Description
The count() function is used to return a single count for the number of rows either for a field over a group of rows, where only the number of non-null values
found are returned, or without a field to count the number of rows, including null values. The function syntax and application is based on the preceding stage:
comp stage
When the count aggregation function is used with a comp stage, the function returns one of the following:
With a field: Returns a single count for the number of non-null rows, for all records that contain matching values for the fields identified in the by clause.
Without a field: Counts the number of rows and includes null values.
In addition, you can configure whether the raw data events are displayed by setting addrawdata to either true or false (default), which are used to
configure the final comp results. When including raw data events in your query, the query runs for up to 50 fields that you define and displays up to 100 events.
Use count_distinct to retrieve the number of unique values in the result set.
windowcomp stage
When the count aggregate function is used with a windowcomp stage, the function returns one of the following:
With a field: Returns a single count for the number of non-null rows for all records that contain matching values for the fields identified using a
combination of the by clause, sort, and between window frame clause. The results are provided in a new column in the results table.
Without a field: Counts the number of rows and includes null values.
Examples
comp example
Return a single count of all values found for the actor_process_image_path field in the group of rows, for all records that have matching values for their
actor_process_image_path and actor_process_command_line values. The query calculates a maximum of 100 xdr_data records and includes a
raw_data column listing a single value for the results.
dataset = xdr_data
| fields actor_process_image_path as Process_Path, actor_process_command_line as Process_CMD, action_total_download as Download
| filter Download > 0
| limit 100
| comp count(Process_Path) as num_process_path by process_path, process_cmd addrawdata = true as raw_data
| sort desc process_path
windowcomp example
Return a single count for the number of values found in the dns_query_name field for each row in the group of rows, for all records that contain matching
values in the agent_ip_addresses field. The query returns a maximum of 100 xdr_data records. The results are provided in the
count_dns_query_name column.
dataset = xdr_data
| limit 100
| windowcomp count(dns_query_name) by agent_ip_addresses as count_dns_query_name
17.4.23 | count_distinct
Abstract
Learn more about the Cortex Query Language count_distinct aggregate comp function that counts the number of unique values found for a field in the
result set.
Syntax
comp count_distinct(<field>) [as <alias>] by <field_1>,<field_2> [addrawdata= true|false [as <target field>]]
Description
The count_distinct aggregation is a comp function that returns a single value for the number of unique values found for a field over a group of rows, for all
records that contain matching values for the fields identified in the by clause. This aggregate function is used in combination with a comp stage.
In addition, you can configure whether the raw data events are displayed by setting addrawdata to either true or false (default), which are used to
configure the final comp results. When including raw data events in your query, the query runs for up to 50 fields that you define and displays up to 100 events.
Use count to retrieve the total number of values in the result set.
Examples
Return a single count of the number of unique values found for the actor_process_image_path field over a group of rows, for all records that have
matching values for their actor_process_image_path and actor_process_command_line values. The query calculates a maximum of 100
Displayed in the footer
Page 805 of 952
Cortex XDR Documentation
Displayed in the header
xdr_data records and includes a raw_data column listing the raw data events used to display the final comp results.
dataset = xdr_data
| fields actor_process_image_path as Process_Path, actor_process_command_line as Process_CMD, action_total_download as Download
| filter Download > 0
| limit 100
| comp count_distinct(Process_Path) as num_process_path by process_path, process_cmd addrawdata = true as raw_data
| sort desc process_path
17.4.24 | current_time
Abstract
Learn more about the Cortex Query Language current_time() function that returns the current time as a timestamp.
Syntax
current_time()
Description
The current_time() function returns a timestamp value representing the current time in the format MMM dd YYYY HH:mm:ss, such as Jul 12th 2023
20:51:34.
Example
From the xdr_data dataset, returns the events of the last 24 hours whose actor process started running more than 30 days ago.
dataset = xdr_data
| filter timestamp_diff(current_time(),to_timestamp(actor_process_execution_time, "MILLIS"), "DAY") > 30
17.4.25 | date_floor
Abstract
Learn more about the Cortex Query Language date_floor() function.
Syntax
date_floor (<timestamp field>, "<time unit>" [, "<time zone>")
Description
The date_floor() function converts a timestamp value for a particular field or function result that contains a number, and returns a timestamp rounded down
to the nearest whole value of a specified <time unit>, including a year (y), month (mo), week (w), day (d), or hour (h). The <time zone> offset is optional
to configure using an hours offset, such as “+08:00”, or using a time zone name from the List of Supported Time Zones, such as "America/Chicago". When you
do not configure a time zone, the default is UTC.
Example
Returns a maximum of 100 xdr_data records with the events of the _time field that are less than equal to a timestamp value. The timestamp value
undergoes a number of different function manipulations. The current time is first rounded to the nearest whole value for the week according to the
America/Los_Angeles time zone. This timestamp value is then converted to the Unix epoch timestamp format in seconds and is added to the -2073600 Unix
epoch time. This Unix epoch time value in seconds is then converted to the final timestamp value that is used to filter the _time fields and return the resulting
records.
dataset = xdr_data
| filter _time < to_timestamp(add(to_epoch(date_floor(current_time(),"w", "America/Los_Angeles")),-2073600))
| limit 100
17.4.26 | divide
Abstract
Learn more about the Cortex Query Language divide() function that divides two integers.
Syntax
divide (<string> | <integer>, <string> | <integer>)
Displayed in the footer
Page 806 of 952
Cortex XDR Documentation
Displayed in the header
Description
The divide() function divides two positive integers. Parameters can be either integer literals, or integers as a string type, such as might be contained in a
data field.
Example
dataset = xdr_data
| alter mynum = divide(action_file_size, 3)
| fields action_file_size, mynum
| filter action_file_size > 3
| limit 1
17.4.27 | earliest
Abstract
Learn more about the Cortex Query Language earliest aggregate comp function that returns the earliest field value found with the matching criteria.
Syntax
comp earliest(<field>) [as <alias>] by <field_1>,<field_2> [addrawdata = true|false [as <target field>]]
Description
The earliest aggregation is a comp function that returns the chronologically earliest value found for a field over a group of rows that has matching values for
the fields identified in the by clause. This function is dependent on a time-related field, so for your query to be considered valid, ensure that the dataset
running this query contains a time-related field. This function is used in combination with a comp stage.
In addition, you can configure whether the raw data events are displayed by setting addrawdata to either true or false (default), which are used to
configure the final comp results. When including raw data events in your query, the query runs for up to 50 fields that you define and displays up to 100 events.
Examples
Return the chronologically earliest timestamp found for any given action_total_download value for all records that have matching values for their
actor_process_image_path and actor_process_command_line fields. The query calculates a maximum of 100 xdr_data records and includes a
raw_data column listing the raw data events used to display the final comp results.
dataset = xdr_data
| fields _time, actor_process_image_path as Process_Path, actor_process_command_line as Process_CMD, action_total_download as Download
| filter Download > 0
| limit 100
| comp earliest(_time) as download_time by Process_Path, Process_CMD addrawdata = true as raw_data
17.4.28 | extract_time
Abstract
Learn more about the Cortex Query Language extract_time() function that returns a specified portion of a timestamp.
Syntax
extract_time (<timestamp>, <part>)
Description
The extract_time() function returns a specified part of a timestamp. The part parameter must be one of the following keywords:
Displayed in the footer
Page 807 of 952
Cortex XDR Documentation
Displayed in the header
DAY
DAYOFWEEK
DAYOFYEAR
HOUR
MICROSECOND
MILLISECOND
MINUTE
MONTH
QUARTER
SECOND
YEAR
Example
dataset = xdr_data
| alter timepart = extract_time(current_time(), "HOUR")
| fields timepart
| limit 1
17.4.29 | extract_url_host
Abstract
Learn more about the Cortex Query Language extract_url_host() function.
Syntax
extract_url_host ("<URL>")
Description
The extract_url_host() function returns the host of the URL. The function always returns a value in lowercase characters even if the URL provided
contains uppercase characters.
Example
Output examples when using the function
Returns paloaltonetworks.com from the complete URL: https://www.paloaltonetworks.com.
extract_url_host ("https://www.paloaltonetworks.com")
Returns a.b for the URL: //user:password@a.b:80/path?query
extract_url_host ("//user:password@a.b:80/path?query")
Returns www.example.co.uk in lowercase for the complete URL: www.Example.Co.UK, which includes uppercase characters.
extract_url_host ("www.Example.Co.UK")
Returns www.test.paloaltonetworks.com for the following URL containing suffixes:
https://www.test.paloaltonetworks.com/suffix/another_suffix
extract_url_host ("https://www.test.paloaltonetworks.com/suffix/another_suffix")
Complete XQL Query Example
Returns one xdr_data record in the results table where the host of the URL https://www.test.paloaltonetworks.com is listed in the URL_HOST
column as www.test.paloaltonetworks.com.
dataset = xdr_data
| alter url_host = extract_url_host("https://www.test.paloaltonetworks.com")
| fields url_host
| limit 1
Displayed in the footer
Page 808 of 952
Cortex XDR Documentation
Displayed in the header
17.4.30 | extract_url_pub_suffix
Abstract
Learn more about the Cortex Query Language extract_url_pub_suffix() function.
Syntax
extract_url_pub_suffix ("<URL>")
Description
The extract_url_pub_suffix() function returns the public suffix of the URL, such as com, org, or net. The function always returns a value in lowercase
characters even if the URL provided contains uppercase characters.
Example
Output examples when using the function
Returns com for the following URL: https://paloaltonetworks.com
extract_url_pub_suffix ("https://paloaltonetworks.com")
Returns com for the following URL containing suffixes: https://www.test.paloaltonetworks.com/suffix/another_suffix
extract_url_pub_suffix ("https://www.test.paloaltonetworks.com/suffix/another_suffix")
Complete XQL Query Example
Returns one xdr_data record in the results table where the public suffix of the URL https://www.paloaltonetworks.com is listed in the
URL_PUB_SUFFIX column as com.
dataset = xdr_data
| alter url_pub_suffix = extract_url_pub_suffix("https://paloaltonetworks.com")
| fields url_pub_suffix
| limit 1
17.4.31 | extract_url_registered_domain
Abstract
Learn more about the Cortex Query Language extract_url_registered_domain() function.
Syntax
extract_url_registered_domain ("<URL>")
Description
The extract_url_registered_domain() function returns the registered domain or registerable domain, the public suffix plus one preceding label, of a
URL. The function always returns a value in lowercase characters even if the URL provided contains uppercase characters.
Examples
Output examples when using the function
Returns paloaltonetworks.com from the complete URL: https://www.paloaltonetworks.com.
extract_url_registered_domain ("https://www.paloaltonetworks.com")
Returns NULL for the URL: //user:password@a.b:80/path?query
extract_url_registered_domain ("//user:password@a.b:80/path?query")
Returns example.co.uk in lowercase for the complete URL: www.Example.Co.UK, which includes uppercase characters.
extract_url_registered_domain ("www.Example.Co.UK")
Returns paloaltonetworks.com for the following URL containing suffixes: https://www.test.paloaltonetworks.com/suffix/another_suffix
extract_url_registered_domain ("https://www.test.paloaltonetworks.com/suffix/another_suffix")
Complete XQL query example
Returns one xdr_data record in the results table where the registered domain of the URL https://www.test.paloaltonetworks.com is listed in the
REGISTERED_DOMAIN column as paloaltonetworks.com.
dataset = xdr_data
| alter registered_domain = extract_url_registered_domain("https://www.test.paloaltonetworks.com")
Displayed in the footer
Page 809 of 952
Cortex XDR Documentation
Displayed in the header
| fields registered_domain
| limit 1
17.4.32 | first
Abstract
Learn more about the Cortex Query Language first aggregate comp function that returns the first field value found in the dataset with the matching criteria.
Syntax
comp first(<field>) [as <alias>] by <field_1>,<field_2> [addrawdata = true|false [as <target field>]]
Description
The first aggregation is a comp function that returns a single first value found for a field in the dataset over a group of rows that has matching values for the
fields identified in the by clause. This function is dependent on a time-related field, so for your query to be considered valid, ensure that the dataset running
this query contains a time-related field. This function is used in combination with a comp stage.
In addition, you can configure whether the raw data events are displayed by setting addrawdata to either true or false (default), which are used to
configure the final comp results. When including raw data events in your query, the query runs for up to 50 fields that you define and displays up to 100 events.
Examples
Return the first timestamp found in the dataset for any given action_total_download value for all records that have matching values for their
actor_process_image_path and actor_process_command_line fields. The query calculates a maximum of 100 xdr_data records and includes a
raw_data column listing the raw data events used to display the final comp results.
dataset = xdr_data
| fields _time,actor_process_image_path as Process_Path, actor_process_command_line as Process_CMD, action_total_download as Download
| filter Download > 0
| limit 100
| comp first(_time) as download_time by Process_Path, Process_CMD addrawdata = true as raw_data
17.4.33 | first_value
Abstract
Learn more about the Cortex Query Language first_value() navigation function that is used with a windowcomp stage.
Syntax
windowcomp first_value(<field>) [by <field> [,<field>,...]] sort [asc|desc] <field1> [, [asc|desc] <field2>,...] [between 0|null|<number>|-<number> [and 0|null|
<number>|-<number>] [frame_type=range]] [as <alias>]
Description
The first_value() function is a navigation function that is used in combination with a windowcomp stage. This function is used to return a single value of a
field for the first row of each row in the group of rows in the current window frame, for all records that contain matching values for the fields identified using a
combination of the by clause, sort (mandatory), and between window frame clause.
Example
Return the first IP address a user authenticated from successfully.
preset = authentication_story
| filter auth_identity not in (null, """""") and auth_outcome = """SUCCESS""" and action_country != UNKNOWN
| alter et = to_epoch(_time), t = _time
| bin t span = 1d
| limit 100
| windowcomp first_value(action_local_ip) by auth_identity, t sort asc et between null and null as first_action_local_ip
| fields auth_identity , *action_local_ip
17.4.34 | floor
Abstract
Learn more about the Cortex Query Language floor() function that rounds a field that contains a number down to the nearest whole integer.
Syntax
floor (<number>)
Displayed in the footer
Page 810 of 952
Cortex XDR Documentation
Displayed in the header
Description
The floor() function converts a field that contains a number, and returns an integer rounded down to the nearest whole number.
Example
17.4.35 | format_string
Abstract
Learn more about the Cortex Query Language format_string() function.
Syntax
format_string("<format string>", <field_1>, <field_2>,...<field_n> )
Description
The format_string() function returns a string from a format string that contains zero or more format specifiers, along with a variable length list of additional
arguments that matches the format specifiers. A format specifier is initiated by the % symbol, and must map to one or more of the remaining arguments.
Usually, this is a one-to-one mapping, except when the * specifier is used.
Examples
STRING
dataset = xdr_data
| alter stylished_action_category_appID = format_string("-%s-", action_category_of_app_id )
| fields stylished_action_category_appID
| limit 100
Simple integer
dataset = xdr_data
| filter action_remote_ip_int != null
| alter simple_int = format_string("%d", action_remote_ip_int)
| fields simple_int
| limit 100
Integer with left blank padding
dataset = xdr_data
| filter action_remote_ip_int != null
| alter int_with_left_blank = format_string("|%100d|", action_remote_ip_int)
| fields int_with_left_blank
| limit 100
Integer with left zero padding
dataset = xdr_data
| filter action_remote_ip_int != null
| alter int_with_left_zero_padding = format_string("+%0100d+", action_remote_ip_int)
| fields int_with_left_zero_padding
| limit 100
17.4.36 | format_timestamp
Abstract
Learn more about the Cortex Query Language format_timestamp() function that returns a string after formatting a timestamp according to a specified
string format.
Syntax
format_timestamp("<format string>", <timestamp field>)
format_timestamp("<format string>", <timestamp field>, "<time zone>")
Description
The format_timestamp() function returns a string after formatting a timestamp according to a specified string format. The <time zone> is optional to
configure using an hours offset, such as “+08:00”, or using a time zone name from the List of Supported Time Zones, such as "America/Chicago". The
format_timestamp() function should include an alter stage. For more information, see the examples below.
Examples
Displayed in the footer
Page 811 of 952
Cortex XDR Documentation
Displayed in the header
Without a time zone configured
Returns a maximum of 100 xdr_data records, which includes a string field called new_time in the format YYYY/MM/dd HH:mm:ss, such as
2021/11/12 12:10:30. This format is detailed in the format_timestamp function, which defines retrieving the new_time (%Y/%m/%d %H:%M:%S) from
the _time field.
dataset = xdr_data
| alter new_time = format_timestamp("%Y/%m/%d %H:%M:%S", _time)
| fields new_time
| limit 100
With a time zone configured using an hours offset
Returns a maximum of 100 xdr_data records, which includes a string field called new_time in the format YYYY/MM/dd HH:mm:ss, such as 2021/11/12
01:53:35. This format is detailed in the format_timestamp function, which defines the retrieving the new_time (%Y/%m/%d %H:%M:%S) from the _time
field and adding +03:00 hours as the time zone format.
dataset = xdr_data
| alter new_time = format_timestamp("%Y/%m/%d %H:%M:%S", _time, "+03:00")
| fields new_time
| limit 100
With a time zone name configured
Returns a maximum of 100 xdr_data records, which includes a string field called new_time in the format YYYY/MM/dd HH:mm:ss, such as
2021/11/12 01:53:35. This format is detailed in the format_timestamp function, which defines the retrieving the new_time (%Y/%m/%d
%H:%M:%S) from the _time field, and includes an "America/Chicago" time zone.
dataset = xdr_data
| fields _time
| alter new_time = format_timestamp("%Y/%m/%d %H:%M:%S", _time, "America/Chicago")
| fields new_time
| limit 100
17.4.37 | if
Abstract
Learn more about the Cortex Query Language if() function that returns a result after evaluating a condition.
Syntax
Regular if statement
if (<boolean expression>, <true return expression>[, <false return expression>])
Nested if/else statement
if(<boolean expression1>, <true return expression1>, <boolean expression2>, <true return expression2>[, <boolean expression3>, <true return
expression3>,...][, <false return expression>])
if(<boolean expression1>, if(<boolean expression2>, <true return expression2> [,<false return expression2>])...[,<false return expression1>])
In the above syntax, if(<boolean expression2>, <true return expression2> [,<false return expression2>]) represents
the <true return expression1>.
Description
The if() function evaluates a single expression or group of expressions depending on the syntax used to define the function. The syntax can be set up in the
following ways:
Regular if statement: A single boolean expression is evaluated. If the expression evaluates as true, the function returns the results defined in the
second function argument. If the expression evaluates as false and a false return expression is defined, the function returns the results of the third
function argument; otherwise, if no false return expression is set, returns null.
Nested if/else statment: At least two boolean expressions and two true return expressions are required when using this option. The first boolean
expression is evaluated. If the first expression evaluates as true, the function returns the results defined in the second function argument. The second
boolean expression is evaluated. If the second expression evaluates as true, the function returns the results defined in the fourth function argument. If
there are any other boolean expressions defined, they are evaluated following the same pattern when evaluated as true. If any of the expressions
evaluates as false and a false return expression is defined, the function returns the results defined in the last function argument for the false return
expression; otherwise, if no false return expression is set, returns null.
Examples
Regular if statement
If '.exe' is present on the action_process_image_name field value, replace that substring with an empty string. This example uses the replace and
lowercase functions, as well as the contains operator to perform the conditional check. When the '.exe' is not present, the value is returned as is.
Displayed in the footer
Page 812 of 952
Cortex XDR Documentation
Displayed in the header
dataset = xdr_data
| fields action_process_image_name as apin
| filter apin != null
| alter remove_exe_process =
if(lowercase(apin) contains ".exe", // boolean expression
replace(lowercase(apin),".exe",""), // return if true
lowercase(apin)) // return if false
| limit 10
Nested if/else statement
Return a maximum of 1 xdr_data record from the past 7 days. The table results include a new column called check_ip, which evaluates and returns the
following:
If the action_local_ip contains an IP address that begins with 10, return Local 10.
If the action_local_ip contains an IP address that begins with 172, return Local 172 ?.
If the action_local_ip contains an IP address that begins with 192.168, return Local 192.
If all the above expressions evaluate as false, return null.
config timeframe = 7d | dataset = xdr_data
| limit 1
| alter
check_ip = if(action_local_ip ~= "^10",//boolean expression1
"Local 10", // true return expression1
action_local_ip ~= "^172", //boolean expression2
"Local 172 ?", //true return expression2
action_local_ip ~= "^192\.168", //boolean expression3
"Local 192") //true return expression3
17.4.38 | incidr
Abstract
Learn more about the Cortex Query Language incidr() function.
Syntax
incidr(<IPv4_address>, <CIDR1_range1> | <CIDR1_range1, CIDR2_range2, ...>)
Description
The incidr() function accepts an IPv4 address, and an IPv4 range or comma separated IPv4 ranges using CIDR notation, and returns true if the address is
in range. Both the IPv4 address and CIDR ranges can be either an explicit string using quotes (""), such as "192.168.0.1", or a string field.
The first parameter must contain an IPv4 address contained in an IPv4 field. For production purposes, this IPv4 address will normally be carried in a field that
you retrieve from a dataset. For manual usage, assign the IPv4 address to a field, and then use that field with this function.
Multiple CIDRs are defined with comma separated syntax when building an XQL query with the Query Builder or in Correlation Rules. When defining multiple
CIDRs, the logical OR is used between the CIDRS listed, so as long as one address is in range the entire statement returns true. Here are a few examples of
how this logic works to determine whether the incidr() function returns true and displays results or false, where no results are displayed:
Function returns true and results are displayed:
dataset = test
| alter ip_address = "192.168.0.1"
| filter incidr(ip_address, "192.168.0.0/24, 1.168.0.0/24") = true
Function returns false and no results are displayed:
dataset = test
| alter ip_address = "192.168.0.1"
| filter incidr(ip_address, "2.168.0.0/24, 1.168.0.0/24") = true
Function returns false and no results are displayed:
dataset = test
| alter ip_address = "192.168.0.1"
| filter incidr(ip_address, "192.168.0.0/24, 1.168.0.0/24") = false
Function returns true and results are displayed:
dataset = test
| alter ip_address = "192.168.0.1"
| filter incidr(ip_address, "2.168.0.0/24, 1.168.0.0/24") = false
The same logic is used when using the incidr and not incidr operators. For more information, see Supported operators.
Examples
Return a maximum of 10 xdr_data records, if the IPV4 address (192.168.10.14) is in range by verifying against a single CIDR (192.168.10.0/24):
Displayed in the footer
Page 813 of 952
Cortex XDR Documentation
Displayed in the header
alter my_ip = "192.168.10.14"
| alter inrange = incidr(my_ip, "192.168.10.0/24")
| fields inrange
| limit 10
Return a maximum of 10 xdr_data records, if the IPV4 address (192.168.0.1) is in range by verifying against multiple CIDRs (192.168.0.0/24 or
1.168.0.0/24):
dataset = xdr_data
| alter ip_address = "192.168.0.1"
| filter incidr(ip_address, "192.168.0.0/24, 1.168.0.0/24") = true
| limit 10
17.4.39 | incidr6
Abstract
Learn more about the Cortex Query Language incidr6() function.
Syntax
incidr6(<IPv6_address>, <CIDR1_range1> | <CIDR1_range1, CIDR2_range2, ...>)
Description
The incidr6() function accepts an IPv6 address, and an IPv6 range or comma separated IPv6 ranges using CIDR notation, and returns true if the address
is in range. Both the IPv6 address and CIDR ranges can be either an explicit string using quotes (""), such as
"3031:3233:3435:3637:3839:4041:4243:4445", or a string field.
The first parameter must contain an IPv6 address contained in an IPv6 field. For production purposes, this IPv6 address will normally be carried in a field that
you retrieve from a dataset. For manual usage, assign the IPv6 address to a field, and then use that field with this function.
Multiple CIDRs are defined with comma separated syntax when building an XQL query with the Query Builder or in Correlation Rules. When defining multiple
CIDRs, the logical OR is used between the CIDRS listed, so as long as one address is in range the entire statement returns true. Here are a few examples of
how this logic works to determine whether the incidr6() function returns true and displays results or false, where no results are displayed:
Function returns true and results are displayed:
dataset = test
| alter ip_address = "3031:3233:3435:3637:3839:4041:4243:4445"
| filter incidr(ip_address, "3031:3233:3435:3637:0000:0000:0000:0000/64, 6081:6233:6435:6637:0000:0000:0000:0000/64") = true
Function returns false and no results are displayed:
dataset = test
| alter ip_address = "3031:3233:3435:3637:3839:4041:4243:4445"
| filter incidr(ip_address, "6081:6233:6435:6637:0000:0000:0000:0000/64, 7081:7234:7435:7737:0000:0000:0000:0000/64, fe80::/10") = true
Function returns false and no results are displayed:
dataset = test
| alter ip_address = "3031:3233:3435:3637:3839:4041:4243:4445"
| filter incidr(ip_address, "3031:3233:3435:3637:0000:0000:0000:0000/64, 7081:7234:7435:7737:0000:0000:0000:0000/64, fe80::/10") = false
Function returns true and results are displayed:
dataset = test
| alter ip_address = "3031:3233:3435:3637:3839:4041:4243:4445"
| filter incidr(ip_address, "6081:6233:6435:6637:0000:0000:0000:0000/64, 7081:7234:7435:7737:0000:0000:0000:0000/64, fe80::/10") = false
The same logic is used when using the incidr6 and not incidr6 operators. For more information, see Supported operators.
Example
Return a maximum of 10 xdr_data records, if the IPV6 address (3031:3233:3435:3637:3839:4041:4243:4445) is in range by verifying against a single
CIDR (3031:3233:3435:3637:0000:0000:0000:0000/64):
alter my_ip = "3031:3233:3435:3637:3839:4041:4243:4445"
| alter inrange = incidr6(my_ip, "3031:3233:3435:3637:0000:0000:0000:0000/64")
| fields inrange
| limit 10
Return a maximum of 10 xdr_data records, if the IPV6 address (3031:3233:3435:3637:3839:4041:4243:4445) is in range by verifying against multiple
CIDRs (2001:0db8:85a3:0000:0000:8a2e:0000:0000/64 or fe80::/10):
dataset = xdr_data
| alter ip_address = "fe80::1"
| filter incidr6(ip_address, "2001:0db8:85a3:0000:0000:8a2e:0000:0000/64, fe80::/10") = true
| limit 10
Displayed in the footer
Page 814 of 952
Cortex XDR Documentation
Displayed in the header
17.4.40 | incidrlist
Abstract
Learn more about the Cortex Query Language incidrlist() function.
Syntax
incidrlist(<IP_address list>, <CIDR_range>)
Description
The incidrlist() function accepts a string containing a comma-separated list of IP addresses, and an IP range using CIDR notation, and returns true if all
the addresses are in range.
Examples
Return true if the list of IP addresses fall within the specified IP range. Note that the input type is a comma-separated list of IP addresses, and not an array of
IP addresses.
alter inrange = incidrlist("192.168.10.16,192.168.10.3",
"192.168.10.0/24")
| fields inrange
| limit 1
If you want to evaluate a true array of IP addresses, convert the array to a comma-separated list using arraystring(). For example, using the
pan_ngfw_traffic_raw dataset:
dataset = panw_ngfw_traffic_raw
| filter dest_ip != null
| comp values(dest_ip) as dips by source_ip,action
| alter dips = arraystring(dips, ", ")
| alter inrange = incidrlist(dips, "192.168.10.0/24")
| fields source_ip, action, dips, inrange
| limit 100
17.4.41 | int_to_ip
Abstract
Learn more about the Cortex Query Language int_to_ip() function that safely converts a signed integer representation of an IPv4 address to a string
equivalent.
Syntax
int_to_ip(<IPv4_integer>)
Description
The int_to_ip() function tries to safely convert a signed integer representation of an IPv4 address into its string equivalent.
Examples
Returns the IPv4 address "4.130.58.140" from the integer representation of the IPv4 address provided as 75643532.
int_to_ip(75643532)
Returns the IPv4 address "251.125.197.116" from the integer representation of the IPv4 address provided as -75643532.
int_to_ip(-75643532)
17.4.42 | ip_to_int
Abstract
Learn more about the Cortex Query Language ip_to_int() function that safely converts a string representation of an IPv4 address to an integer equivalent.
Syntax
ip_to_int(<IPv4_address>)
This function was previously called safe_ip_to_int() and was renamed to ip_to_int().
Description
The ip_to_int() function tries to safely convert a string representation of an IPv4 address into its integer equivalent.
Displayed in the footer
Page 815 of 952
Cortex XDR Documentation
Displayed in the header
Example
Returns the integer 808530483 from the string representation of the IPv4 address provided as "48.49.50.51".
ip_to_int("48.49.50.51")
17.4.43 | json_extract
Abstract
Learn more about the Cortex Query Language json_extract() function that accepts a string representing a JSON object, and returns a field value from that
object.
Before using this JSON function, it's important that you understand how Cortex XDR treats a JSON in the Cortex Query Language. For more information, see
JSON functions.
Syntax
Regular Syntax
json_extract(<json_object_formatted_string>, <json_path>)
When a field in the <json_path> contains characters, such as a dot (.) or colon (:), use the syntax:
json_extract(<json_object_formatted_string>, "['<json_field>']")
Syntactic Sugar Format
To make it easier for you to write your XQL queries, you can also use the following syntactic sugar format.
<json_object_formatted_string> -> <json_path>{}
When a field in the <json_path> contains characters, such as a dot (.) or colon (:), use the syntax:
<json_object_formatted_string> -> ["<json_field>"]{}
Description
The json_extract() function extracts inner JSON objects by retrieving the value from the identified field. The returned datatype is always a string. If the
input string does not represent a JSON object, this function fails to parse. To convert a string field to a JSON object, use the to_json_string function.
JSON field names are case sensitive, so the key to field pairing must be identical in an XQL query for results to be found. For example, if a field value is
"TIMESTAMP" and your query is defined to look for "timestamp", no results will be found.
The field value is always returned as a string. To return the scalar values, which are not an object or an array, use json_extract_scalar.
Examples
Return the storage_device_name value from the action_file_device_info field.
dataset = xdr_data
| fields action_file_device_info as afdi
| alter sdn = json_extract(to_json_string(afdi), "$.storage_device_name")
| filter afdi != null
Using Syntactic Sugar Format
The same example above with a syntactic sugar format.
dataset = xdr_data
| fields action_file_device_info as afdi
| alter sdn = to_json_string(afdi)->storage_device_name{}
| filter afdi != null
17.4.44 | json_extract_array
Abstract
Learn more about the Cortex Query Language json_extract_array() function that accepts a string representing a JSON array, and returns an XQL-native
array.
Before using this JSON function, it's important that you understand how Cortex XDR treats a JSON in the Cortex Query Language. For more information, see
JSON functions.
Syntax
Regular Syntax
Displayed in the footer
Page 816 of 952
Cortex XDR Documentation
Displayed in the header
json_extract_array(<json_array_string>, <json_path>)
When a field in the <json_path> contains characters, such as a dot (.) or colon (:), use the syntax:
json_extract_array(<json_array_string>, "['<json_field>']")
Syntactic Sugar Format
To make it easier for you to write your XQL queries, you can also use the following syntactic sugar format.
<json_array_string> -> <json_path>[]
When a field in the <json_path> contains characters, such as a dot (.) or colon (:), use the syntax:
<json_array_string> -> ["<json_field>"][]
Description
The json_extract_array() function accepts a string representing a JSON array, and returns an XQL-native array. To convert a string field to a JSON
object, use the to_json_string function.
JSON field names are case sensitive, so the key to field pairing must be identical in an XQL query for results to be found. For example, if a field value is
"TIMESTAMP" and your query is defined to look for "timestamp", no results will be found.
Examples
Regular Syntax
Extract the first IPV4 address found in the first element of the agent_interface_map array.
dataset = xdr_data
| fields agent_interface_map as aim
| alter ipv4 = json_extract_array(to_json_string(arrayindex(aim, 0)) , "$.ipv4")
| filter aim != null
| limit 10
Syntactic Sugar Format
The same example above with a syntactic sugar format.
dataset = xdr_data
| fields agent_interface_map as aim
| alter ipv4 = to_json_string(aim)->[0].ipv4[0]
| filter aim != null
| limit 10
17.4.45 | json_extract_scalar
Abstract
Learn more about the Cortex Query Language json_extract_scalar() function.
Before using this JSON function, it's important that you understand how Cortex XDR treats a JSON in the Cortex Query Language. For more information, see
JSON functions.
Syntax
Regular Syntax
json_extract_scalar(<json_object_formatted_string>, <field_path>)
When a field in the <json_path> contains characters, such as a dot (.) or colon (:), use the syntax:
json_extract_scalar(<json_object_formatted_string>, "['<json_field>']")
Syntactic Sugar Format
To make it easier for you to write your XQL queries, you can also use the following syntactic sugar format:
<json_object_formatted_string> -> <field_path>
When a field in the <json_path> contains characters, such as a dot (.) or colon (:), use the syntax:
<json_object_formatted_string> -> ["<json_field>"]
Description
The json_extract_scalar() function accepts a string representing a JSON object, and it retrieves the value from the identified field as a string. This
function always returns a string. If the JSON field is an object or array, it will return a null value. To retrieve an XQL-native datatype, use an appropriate function,
Displayed in the footer
Page 817 of 952
Cortex XDR Documentation
Displayed in the header
such as to_float or to_integer. If the input string does not represent a JSON object, this function fails to parse. To convert a string field to a JSON object,
use the to_json_string function.
JSON field names are case sensitive, so the key to field pairing must be identical in an XQL query for results to be found. For example, if a field value is
"TIMESTAMP" and your query is defined to look for "timestamp", no results will be found.
Examples
Return the storage_device_drive_type value from the action_file_device_info field, and return the record if it is 1.
There are two ways that you can build this query either with a filter using an XQL-native datatype or string.
Option A - Filter using an XQL-native datatype
dataset = xdr_data
| fields action_file_device_info as afdi
| alter sdn = to_integer(json_extract_scalar(to_json_string(afdi), "$.storage_device_drive_type"))
| filter sdn = 1
| limit 10
Option B - Filter using a string
dataset = xdr_data
| fields action_file_device_info as afdi
| alter sdn = json_extract_scalar(to_json_string(afdi), "$.storage_device_drive_type")
| filter sdn = "1"
| limit 10
Using Syntactic Sugar Format
The same example above with a syntactic sugar format.
dataset = xdr_data
| fields action_file_device_info as afdi
| alter sdn = to_integer(to_json_string(afdi)->storage_device_drive_type)
| filter sdn = 1
| limit 10
17.4.46 | json_extract_scalar_array
Abstract
Learn more about the Cortex Query Language json_extract_scalar_array() function.
Before using this JSON function, it's important that you understand how Cortex XDR treats a JSON in the Cortex Query Language. This function doesn't have a
syntatic sugar format. For more information, see JSON functions.
Syntax
json_extract_scalar_array(<json_array_string>, <json_path>)
A field in the <json_path> that contains characters, such as a dot (.) or colon (:) and should be escaped as it's an invalid JSON path, is currently
unsupported. This should be fixed in an upcoming release.
Description
The json_extract_scalar_array() function accepts a string representing a JSON array, and returns an XQL-native array. This function is equivalent to
the json_extract_array except that the final output isn't displayed in double quotes ("..."). To convert a string field to a JSON object, use the to_json_string
function.
JSON field names are case sensitive, so the key to field pairing must be identical in an XQL query for results to be found. For example, if a field value is
"TIMESTAMP" and your query is defined to look for "timestamp", no results will be found.
Example
Extract the first IPV4 address found in the first element of the agent_interface_map array. The values of the IPv4 addresses in the array will not contain any
double quotes.
dataset = xdr_data
| fields agent_interface_map as aim
| alter ipv4 = json_extract_scalar_array(to_json_string(arrayindex(aim, 0)) , "$.ipv4")
| filter aim != null
| limit 10
Final output with 1 row from the results table. Notice that the IPV4 column doesn't contain any double quotes (" ") around the IP address 172.16.15.42:
Displayed in the footer
Page 818 of 952
Cortex XDR Documentation
Displayed in the header
_TIME AIM _PRODUCT _VENDOR INSERT_TIMESTAMP IPV4
Aug 9th 2023 [{"ipv4":["172.16.15.42"], "ipv6": [], "mac": XDR agent PANW Aug 17th 2023 172.16.15.42
10:04:39 "00:50:56:9f:30:a9"}] 19:25:48
In contrast, compare the above results to the same query using the json_extract_array() function. The final output with the same row from the results
table has in the IPV4 column the IP address in double quotes "172.16.15.42".
_TIME AIM _PRODUCT _VENDOR INSERT_TIMESTAMP IPV4
Aug 9th 2023 [{"ipv4":["172.16.15.42"], "ipv6": [], "mac": XDR agent PANW Aug 17th 2023 "172.16.15.42"
10:04:39 "00:50:56:9f:30:a9"}] 19:25:48
17.4.47 | lag
Abstract
Learn more about the Cortex Query Language lag() navigation function that is used with a windowcomp stage.
Syntax
windowcomp lag(<field>) [by <field> [,<field>,...]] sort [asc|desc] <field1> [, [asc|desc] <field2>,...] [as <alias>]
Description
The lag() function is a navigation function that is used in combination with a windowcomp stage. This function is used to return a single value of a field on a
preceding row for each row in the group of rows using a combination of the by clause and sort (mandatory).
Example
Retrieve for each event the timestamp of the previous successful login since the last one.
preset = authentication_story
| filter auth_identity not in (null, """""") and auth_outcome = """SUCCESS"""
| alter ep = to_epoch(_time)
| limit 100
| windowcomp lag(_time) by auth_identity sort asc ep as previous_login
17.4.48 | last
Abstract
Learn more about the Cortex Query Language last aggregate comp function that returns the last field value found in the dataset with the matching criteria.
Syntax
comp last(<field>) [as <alias>] by <field_1>,<field_2> [addrawdata = true|false [as <target field>]]
Description
The last aggregation is a comp function that returns the last value found for a field in the dataset over a group of rows that has matching values for the fields
identified in the by clause. This function is dependent on a time-related field, so for your query to be considered valid, ensure that the dataset running this
query contains a time-related field. This function is used in combination with a comp stage.
In addition, you can configure whether the raw data events are displayed by setting addrawdata to either true or false (default), which are used to
configure the final comp results. When including raw data events in your query, the query runs for up to 50 fields that you define and displays up to 100 events.
Examples
Return the last timestamp found in the dataset for any given action_total_download value for all records that have matching values for their
actor_process_image_path and actor_process_command_line fields. The query calculates a maximum of 100 xdr_data records and includes a
raw_data column listing the raw data events used to display the final comp results.
dataset = xdr_data
| fields _time, actor_process_image_path as Process_Path, actor_process_command_line as Process_CMD, action_total_download as Download
| filter Download > 0
Displayed in the footer
Page 819 of 952
Cortex XDR Documentation
Displayed in the header
| limit 100
| comp last(_time) as download_time by Process_Path, Process_CMD addrawdata = true as raw_data
17.4.49 | last_value
Abstract
Learn more about the Cortex Query Language last_value() navigation function that is used with a windowcomp stage.
Syntax
windowcomp last_value(<field>) [by <field> [,<field>,...]] sort [asc|desc] <field1> [, [asc|desc] <field2>,...] [between 0|null|<number>|-<number> [and 0|null|
<number>|-<number>] [frame_type=range]] [as <alias>]
Description
The last_value() function is a navigation function that is used in combination with a windowcomp stage. This function is used to return a single value of a
field for the last row of each row in the group of rows in the current window frame, for all records that contain matching values for the fields identified using a
combination of the by clause, sort (mandatory), and between window frame clause.
Example
Return the last IP address a user authenticated from successfully.
preset = authentication_story
| filter auth_identity not in (null, """""") and auth_outcome = """SUCCESS""" and action_country != UNKNOWN
| alter et = to_epoch(_time), t = _time
| bin t span = 1d
| limit 100
| windowcomp last_value(action_local_ip) by auth_identity, t sort asc et between null and null as first_action_local_ip
| fields auth_identity , *action_local_ip
17.4.50 | latest
Abstract
Learn more about the Cortex Query Language latest aggregate comp function that returns the latest field value found with the matching criteria.
Syntax
comp latest(<field>) [as <alias>] by <field_1>,<field_2> [addrawdata = true|false [as <target field>]]
Description
The latest aggregation is a comp function that returns a single chronologically latest value found for a field over a group of rows that has matching values for
the fields identified in the by clause. This function is dependent on a time-related field, so for your query to be considered valid, ensure that the dataset
running this query contains a time-related field. This function is used in combination with a comp stage.
In addition, you can configure whether the raw data events are displayed by setting addrawdata to either true or false (default), which are used to
configure the final comp results. When including raw data events in your query, the query runs for up to 50 fields that you define and displays up to 100 events.
Examples
Return the chronologically latest timestamp found for any given action_total_download value for all records that have matching values for their
actor_process_image_path and actor_process_command_line fields. The query calculates a maximum of 100 xdr_data records and includes a
raw_data column listing the raw data events used to display the final comp results.
dataset = xdr_data
| fields _time, actor_process_image_path as Process_Path, actor_process_command_line as Process_CMD, action_total_download as Download
| filter Download > 0
| limit 100
| comp latest(_time) as download_time by Process_Path, Process_CMD addrawdata = true as raw_data
17.4.51 | len
Abstract
Learn more about the Cortex Query Language len function that returns the number of characters contained in a string.
Syntax
len (<string>)
Displayed in the footer
Page 820 of 952
Cortex XDR Documentation
Displayed in the header
Description
The len() function returns the number of characters contained in a string.
Examples
Show domain names that are more than 100 characters in length.
dataset = xdr_data
| fields dns_query_name
| filter len(dns_query_name) > 100
| limit 10
17.4.52 | list
Abstract
Learn more about the Cortex Query Language list aggregate comp function that returns an array for up to 100 values for a field in the result set.
Syntax
comp list(<field>) [as <alias>] by <field_1>,<field_2> [addrawdata = true|false [as <target field>]]
Description
The list aggregation is a comp function that returns a single array of up to 100 values found for a given field over a group of rows, for all records that contain
matching values for the fields identified in the by clause. The array values are all non-null, so null values are filtered out. The values returned in the array are
non-unique, so if a value repeats multiple times it is included as part of the list of up to 100 values. This function is used in combination with a comp stage.
In addition, you can configure whether the raw data events are displayed by setting addrawdata to either true or false (default), which are used to
configure the final comp results. When including raw data events in your query, the query runs for up to 50 fields that you define and displays up to 100 events.
Examples
Return an array containing up to 100 values seen for the action_total_download field over a group of rows, for all records that have matching values for
their actor_process_image_path and actor_process_command_line values. The query calculates a maximum of 100 xdr_data records and
includes a raw_data column listing the raw data events used to display the final comp results.
dataset = xdr_data
| fields actor_process_image_path as Process_Path, actor_process_command_line as Process_CMD, action_total_download Download
| filter Download > 0
| limit 100
| comp list(Download) as list_download by Process_Path, Process_CMD addrawdata = true as raw_data
17.4.53 | lowercase
Abstract
Learn more about the Cortex Query Language lowercase() function that converts a string field to all lowercase letters.
Syntax
lowercase (<string>)
Description
The lowercase() function converts a string field value to all lowercase.
Examples
Convert all actor_process_image_name field values that are not null to lowercase, and return a list of unique values.
dataset = xdr_data
| fields actor_process_image_name as apin
| dedup apin by asc _time
| filter apin != null
| alter apin = lowercase(apin)
17.4.54 | ltrim, rtrim, trim
Abstract
Learn more about the Cortex Query Language ltrim(), rtrim(), and trim() functions that removes spaces or characters from the beginning or end of a
string.
Displayed in the footer
Page 821 of 952
Cortex XDR Documentation
Displayed in the header
Syntax
trim (<string>,[trim_characters])
rtrim (<string>,[trim_characters])
ltrim (<string>,[trim_characters])
Description
The trim() function removes specified characters from the beginning and end of a string. The rtrim() removes specific characters from the end of a string.
The ltrim() function removes specific characters from the beginning of a string.
If you do not specify trim characters, then whitespace (spaces and tabs) are removed.
Examples
Remove '.exe' from the end of the action_process_image_name field value.
dataset = xdr_data
| fields action_process_image_name as apin
| filter apin != null
| alter remove_exe_process = rtrim(apin, ".exe")
| limit 10
See also the replace function example.
17.4.55 | max
Abstract
Learn more about the Cortex Query Language max function used with both comp and windowcomp stages.
Syntax
comp stage
comp max(<field>) [as <alias>] by <field_1>,<field_2> [addrawdata = true|false [as <target field>]]
windowcomp stage
windowcomp max(<field>) [by <field> [,<field>,...]] [sort [asc|desc] <field1> [, [asc|desc] <field2>,...]] [between 0|null|<number>|-<number> [and 0|null|
<number>|-<number>] [frame_type=range]] [as <alias>]
Description
The max() function is used to return the maximum value of an integer field over a group of rows. The function syntax and application is based on the
preceding stage:
comp stage
When the max aggregation function is used with a comp stage, the function returns a single maximum value of an integer field for a group of rows, for all
records that contain matching values for the fields identified in the by clause.
In addition, you can configure whether the raw data events are displayed by setting addrawdata to either true or false (default), which are used to
configure the final comp results. When including raw data events in your query, the query runs for up to 50 fields that you define and displays up to 100 events.
windowcomp stage
When the max aggregate function is used with a windowcomp stage, the function returns a single maximum value of an integer field for each row in the group
of rows, for all records that contain matching values for the fields identified using a combination of the by clause, sort, and between window frame clause.
The results are provided in a new column in the results table.
Examples
comp example
Return a single maximum value of the action_total_download field for a group of rows, for all records that have matching values for their
actor_process_image_path and actor_process_command_line values. The query calculates a maximum of 100 xdr_data records and includes a
raw_data column listing a single value for the results.
dataset = xdr_data
| fields actor_process_image_path as Process_Path, actor_process_command_line as Process_CMD, action_total_download as Download
| filter Download > 0
| limit 100
| comp max(Download) as max_download by Process_Path, Process_CMD addrawdata = true as raw_data
windowcomp example
Return the last login time. The query returns a maximum of 100 authentication_story records in a column called action_user_agent.
Displayed in the footer
Page 822 of 952
Cortex XDR Documentation
Displayed in the header
preset = authentication_story
| limit 100
| windowcomp max(_time) by action_user_agent
17.4.56 | median
Abstract
Learn more about the Cortex Query Language median function used with both comp and windowcomp stages.
Syntax
comp stage
comp median(<field>) [as <alias>] by <field_1>,<field_2> [addrawdata = true|false [as <target field>]]
windowcomp stage
windowcomp median(<field>) [by <field> [,<field>,...]] [as <alias>]
Description
The median() function is used to return the median value of a field over a group of rows. The function syntax and application is based on the preceding
stage:
comp stage
When the median aggregation function is used with a comp stage, the function returns a single median value of a field for a group of rows, for all records that
contain matching values for the fields identified in the by clause.
In addition, you can configure whether the raw data events are displayed by setting addrawdata to either true or false (default), which are used to
configure the final comp results. When including raw data events in your query, the query runs for up to 50 fields that you define and displays up to 100 events.
windowcomp stage
When the median aggregate function is used with a windowcomp stage, the function returns a single median value of a field for each row in the group of rows,
for all records that contain matching values for the fields identified in the by clause. In a median function, the sort and between window frame clause are not
used. The results are provided in a new column in the results table.
Examples
comp example
Return a single median value of the action_total_download field over a group of rows, for all records that have matching values for their
actor_process_image_path and actor_process_command_line values. The query calculates a maximum of 100 xdr_data records and includes a
raw_data column listing a single value for the results.
dataset = xdr_data
| fields actor_process_image_path as Process_Path, actor_process_command_line as Process_CMD, action_total_download as Download
| filter Download > 0
| limit 100
| comp median(Download) as median_download by Process_Path, Process_CMD
addrawdata = true as raw_data
windowcomp example
Return all events where the Download field is greater than the median by reviewing each individual event and how it compares to the median. The query
returns a maximum of 100 xdr_data records in a column called median_download.
dataset = xdr_data
| fields actor_process_image_path as Process_Path, actor_process_command_line as Process_CMD, action_total_download as Download
| filter Download > 0
| limit 100
| windowcomp median(Download) by Process_Path, Process_CMD as median_download
| filter Download > median_download
17.4.57 | min
Abstract
Learn more about the Cortex Query Language min function used with both comp and windowcomp stages.
Syntax
comp stage
comp min(<field>) [as <alias>] by <field_1>,<field_2> [addrawdata = true|false [as <target field>]]
windowcomp stage
Displayed in the footer
Page 823 of 952
Cortex XDR Documentation
Displayed in the header
windowcomp min(<field>) [by <field> [,<field>,...]] [sort [asc|desc] <field1> [, [asc|desc] <field2>,...]] [between 0|null|<number>|-<number> [and 0|null|
<number>|-<number>] [frame_type=range]] [as <alias>]
Description
The min() function is used to return the minimum value of an integer field over a group of rows. The function syntax and application is based on the preceding
stage:
comp stage
When the min aggregation function is used with a comp stage, the function returns a single minimum value of an integer field for a group of rows, for all
records that contain matching values for the fields identified in the by clause.
In addition, you can configure whether the raw data events are displayed by setting addrawdata to either true or false (default), which are used to
configure the final comp results. When including raw data events in your query, the query runs for up to 50 fields that you define and displays up to 100 events.
windowcomp stage
When the min aggregate function is used with a windowcomp stage, the function returns a single minimum value of an integer field for each row in the group of
rows, for all records that contain matching values for the fields identified using a combination of the by clause, sort, and between window frame clause. The
results are provided in a new column in the results table.
Examples
comp example
Return a single minimum value of the action_total_download field for a group of rows, for all records that have matching values for their
actor_process_image_path and actor_process_command_line values. The query calculates a maximum of 100 xdr_data records and includes a
raw_data column listing a single value for the results.
dataset = xdr_data
| fields actor_process_image_path as Process_Path, actor_process_command_line as Process_CMD, action_total_download as Download
| filter Download > 0
| limit 100
| comp min(Download) as min_download by Process_Path, Process_CMD addrawdata = true as raw_data
windowcomp example
Return the first login time. The query returns a maximum of 100 authentication_story records in a column called action_user_agent.
preset = authentication_story
| limit 100
| windowcomp min(_time) by action_user_agent
17.4.58 | multiply
Abstract
Learn more about the Cortex Query Language multiply() function that multiplies two integers.
Syntax
multiply (<string> | <integer>, <string> | <integer>)
Description
The multiply() function multiplies two positive integers. Parameters can be either integer literals, or integers as a string type such as might be contained in
a data field.
Example
dataset = xdr_data
| alter mynum = multiply(action_file_size, 3)
| fields action_file_size, mynum
| filter action_file_size > 0
| limit 1
17.4.59 | object_merge
Abstract
Learn more about the Cortex Query Language object_merge() function.
Syntax
object_merge(<obj1>, <obj2>, <obj3>, ...)
Displayed in the footer
Page 824 of 952
Cortex XDR Documentation
Displayed in the header
Description
The object_merge() function returns a new object, which is created from a merge of a number of objects. When there is a key name that is duplicated in
any of the objects, the value in the new object is determined by the latter argument.
Example
Two objects are created and merged, where some key names are duplicated, including name, last_name, and age. Since the name value is the same for
both objects, the same name is used in the new object. Yet, the last_name and age key values differ, so the values from the second object are used in the
new object.
dataset = xdr_data
| alter
obj1 = object_create("name", "jane", "last_name", "doe", "age", 33),
obj2 = object_create("name", "jane", "last_name", "simon", "age", 34, "city", "new-york")
| alter result = object_merge(obj1, obj2)
| fields result
The function returns the following new object in the RESULT column of the results table:
{"name": "jane", "last_name": "simon", "age": 34, "city": "new-york"}
17.4.60 | object_create
Abstract
Learn more about the Cortex Query Language object_create() function.
Syntax
object_create ("<key1>", "<value1>", "<key2>", "<value2>",...)
Description
The object_create() function returns an object based on the given parameters defined for the key and value pairs. Accepts n > 1 even number of
parameters.
Example
Returns a final object to a field called a that contains the key and value pair {“2”:“password”}, where the "password" value is comprised by joining 2 values
together.
dataset = xdr_data
| alter a = object_create("2", concat("pass", "word"))
| fields a
17.4.61 | parse_epoch
Abstract
Learn more about the Cortex Query Language parse_epoch() function that returns a Unix epoch TIMESTAMP object.
Syntax
parse_epoch("<format string>", <timestamp field>[, "<time zone>",] ["<time unit>"])
Description
The parse_epoch() function returns a Unix epoch TIMESTAMP object after converting a string representation of a timestamp. The <time zone> offset is
optional to configure using an hours offset, such as “+08:00”, or using a time zone name from the List of Supported Time Zones, such as "America/Chicago".
When you do not configure a timezone, the default is UTC. The <time unit> is optional to configure and indicates whether the Unix epoch integer value
represents seconds, milliseconds, or microseconds. These values are supported, and the default is used when none is configured:
SECONDS (default)
MILLIS
MICROS
The order of the <time zone> and <time unit> matters. The <time zone> must be defined first followed by the <time unit>. If the <time zone> is
set after the <time unit>, the default time zone is used and the configured value is ignored.
Displayed in the footer
Page 825 of 952
Cortex XDR Documentation
Displayed in the header
Examples
With a time zone configured:
Returns a maximum of 100 xdr_data records, which includes a timestamp field called new_time in the format MMM dd YYYY HH:mm:ss, such as
Dec 25th 2008 04:30:00. This new_time field is comprised by taking a character string representation of a timestamp "Thu Dec 25 07:30:00 2008"
and adding to it +03:00 hours as the time zone format. This string timestamp is then converted to a Unix epoch TIMESTAMP object in milliseconds using
the parse_epoch function, and this resulting value is converted to the final timestamp using the to_timestamp function.
dataset = xdr_data
| alter new_time = to_timestamp(parse_epoch("%c", "Thu Dec 25 07:30:00 2008", "+3", "millis"))
| fields new_time
| limit 100
Without a time zone or time unit configured:
Returns a maximum of 100 xdr_data records, which includes a timestamp field called new_time in the format MMM dd YYYY HH:mm:ss, such as
Dec 25th 2008 04:30:00. This new_time field is comprised by taking a character string representation of a timestamp "Thu Dec 25 07:30:00 2008"
and adding to it a UTC time zone format (default when none configured). This string timestamp is then converted to a Unix epoch TIMESTAMP object in
seconds (default when none configured) using the parse_epoch function, and this resulting value is converted to the final timestamp using the
to_timestamp function.
dataset = xdr_data
| alter new_time = to_timestamp(parse_epoch("%c", "Thu Dec 25 07:30:00 2008"))
| fields new_time
| limit 100
17.4.62 | parse_timestamp
Abstract
Learn more about the Cortex Query Language parse_timestamp() function that returns a TIMESTAMP object.
Syntax
parse_timestamp("<format time string>", "<time string>" | format_string(<time field>) | <time string field>)
parse_timestamp("<format time string>", "<time string>" | format_string(<time field>) | <time string field>, "<time zone>")
Description
The parse_timestamp() function returns a TIMESTAMP object after converting a string representation of a timestamp. The <time zone> offset is optional
to configure using an hours offset, such as “+08:00”, or using a time zone name from the List of Supported Time Zones, such as "America/Chicago". The
parse_timestamp() function can include both an alter stage and format_string function. For more information, see the examples below. The
format_string function contains the format elements that define how the parse_timestamp string is formatted. Each element in the parse_timestamp
string must have a corresponding element in format_string. The location of each element in the format_string must match the location of each element
in parse_timestamp.
Displayed in the footer
Page 826 of 952
Cortex XDR Documentation
Displayed in the header
Examples
Without a time zone configured
Returns a maximum of 100 microsoft_dhcp_raw records, which includes a TIMESTAMP object in the p_t_test field in the format MMM dd YYYY
HH:mm:ss, such as Jun 25th 2021 18:31:25. This format is detailed in the format_string function, which includes merging both the date and time
fields.
dataset = microsoft_dhcp_raw
| alter p_t_test = parse_timestamp("%m/%d/%Y %H:%M:%S", format_string("%s %s", date, time))
| fields p_t_test
| limit 100
With a time zone name configured
Returns a maximum of 100 microsoft_dhcp_raw records, which includes a TIMESTAMP object in the p_t_test field in the format MMM dd YYYY
HH:mm:ss, such as Jun 25th 2021 18:31:25. This format is detailed in the format_string function, which includes merging both the date and time
fields, and includes a "Asia/Singapore" time zone.
dataset = microsoft_dhcp_raw
| alter p_t_test = parse_timestamp("%m/%d/%Y %H:%M:%S", format_string("%s %s", date, time), "Asia/Singapore")
| fields p_t_test
| limit 100
With a time zone configured using an hours offset
Returns a maximum of 100 microsoft_dhcp_raw records, which includes a TIMESTAMP object in the p_t_test field in the format MMM dd YYYY
HH:mm:ss, such as Jun 25th 2021 18:31:25. This format is detailed in the format_string function, which includes merging both the date and time
fields, and includes a time zone using an hours offset of “+08:00”.
dataset = microsoft_dhcp_raw
| alter p_t_test = parse_timestamp("%m/%d/%Y %H:%M:%S", format_string("%s %s", date, time), “+08:00”)
| fields p_t_test
| limit 100
17.4.63 | pow
Abstract
Learn more about the Cortex Query Language pow() function that returns the value of a number raised to the power of another number.
Syntax
pow (<x,n>)
Description
The pow() function returns the value of a number (x) raised to the power of another number (n).
17.4.64 | rank
Abstract
Learn more about the Cortex Query Language rank() numbering function that is used with a windowcomp stage.
Syntax
windowcomp rank() [by <field> [,<field>,...]] sort [asc|desc] <field1> [, [asc|desc] <field2>,...] [as <alias>]
Description
The rank() function is a numbering function that is used in combination with a windowcomp stage. This function is used to return a single value for the ordinal
(1-based) rank for each row in the group of rows using a combination of the by clause and sort (mandatory).
Example
Return an average ranking for the avgerage CPU usage on metric_type=HOST. Allows you to see changes in the CPU usage compared to all hosts in the
environment. The query returns a maximum of 100 it_metrics records. The results are ordered by ft in decending order in the rank column.
dataset = it_metrics
| filter metric_type = HOST
| alter cpu_avg_str = to_string(cpu_avg)
| alter ft = date_floor(_time, "w")
| alter dt = date_floor(_time, "d")
| limit 100
| windowcomp rank() by ft sort desc cpu_avg_str as rank
| filter (agent_hostname contains $host_name)
| comp avg(rank) by dt
Displayed in the footer
Page 827 of 952
Cortex XDR Documentation
Displayed in the header
17.4.65 | regexcapture
Abstract
Learn more about the Cortex Query Language regexcapture() function used in Parsing Rules to extract data from fields using regular expression named
groups from a given string.
The regexcapture() function is only supported in the XQL syntax for Parsing Rules.
Syntax
regexcapture(<field>, "<pattern>")
Description
In Parsing Rules, the regexcapture() function is used to extract data from fields using regular expression named groups from a given string and returns a
JSON object with captured groups. This function can be used in any section of a Parsing Rule. The regexcapture() function is useful when the regex
pattern is not identical throughout the log, which is required when using the regextract function.
XQL uses RE2 for its regular expression implementation. When using the (?i) syntax for case-insensitive mode in your query, this syntax should be added
only once at the beginning of the inline regular expression.
Example
Parsing Rule to ceate a dataset called my_regexcapture_test, where the vendor and product that the specified Parsing Rules applies to is called
regexcapture_vendor and regexcapture_product. The output results includes a new field called regexcaptureResult, which extract data from the
_raw_log field using regular expression named groups as defined and returns the captured groups.
Parsing Rule:
[INGEST:vendor="regexcapture_vendor", product="regexcapture_product", target_dataset="my_regexcapture_test"]
alter regexcaptureResult = regexcapture(_raw_log,"^(?P<ip>\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}) - (?P<user>\w+) \[(?P<timestamp>.+)\] (?P<request>.+) (?
P<status>\d{3}) (?P<bytes>\d+)");
Log:
192.168.1.1 - john [10/Mar/2024:12:34:56 +0000] GET /index.html HTTP/1.1 200 1234
XQL Query:
For the my_regexcapture_test dataset, returns the regexcaptureResult field output.
dataset = my_regexcapture_test
| fields regexcaptureResult
regexcaptureResult field output:
{
"ip": "192.168.1.1",
"user": "john",
"timestamp": "10/Mar/2024:12:34:56 +0000",
"request": "GET /index.html HTTP/1.1",
"status": "200",
"bytes": "1234"
}
17.4.66 | regextract
Abstract
Learn more about the Cortex Query Language regextract() function that uses regular expressions to assemble an array of matching substrings from a
string.
Syntax
regextract (<string_value>, <pattern>)
Description
The regextract() function accepts a string and a regular expression, and it returns an array containing substrings that match the expression.
Cortex Query Language (XQL) uses RE2 for its regular expression implementation. While capturing multiple groups is unsupported, capturing one group in
queries is supported.
When using the (?i) syntax for case-insensitive mode in your query, this syntax should be added only once at the beginning of the inline regular expression.
Displayed in the footer
Page 828 of 952
Cortex XDR Documentation
Displayed in the header
Capturing multiple groups is supported in Parsing Rules when using the regexcapture function.
Examples
Without a capturing group
Extract the Account Name from the action_evtlog_message. Use the arrayindex and split functions to extract the actual account name from the array
created by regextract.
dataset = xdr_data
| fields action_evtlog_message as aem
| filter aem != null
| alter account_name =
arrayindex(
split(
arrayindex(
regextract(aem, "Account Name:\t\t.*\r\n")
,0)
, ":")
,1)
| filter account_name != null
| limit 10
Using one capturing group
Extract from the log_example field all of the values included for the id objects.
dataset = xdr_data
| limit 1
| alter
log_example = "{\"events\":[{\"id\": \"1\", \"type\": \"process\", \"size\": 123, \"processID\": 40540},{\"id\": \"2\", \"type\": \"request\", \"size\": 456,
\"srcOS\": \"MAC\"}],\"host\": \"LocalHost\",\"date\": {\"day\": 4, \"month\": 7, \"year\": 2024},\"tags\":[\"agent\", \"auth\", \"low\"]}"
| alter
one_capture_group_usage = regextract(log_example, "\"id\":\s*\"([^\"]+)\"")
| fields log_example, one_capture_group_usage
17.4.67 | replace
Abstract
Learn more about the Cortex Query Language replace() function that performs a substring replacement.
Syntax
replace (<field>, "<old_substring>", "<new_string>")
Description
The replace() function accepts a string field, and replaces all occurrences of a substring with a replacement string.
Examples
If '.exe' is present on the action_process_image_name field value, replace that substring with an empty string. This example uses the if and lowercase
functions, as well as the contains operator to perform the conditional check.
dataset = xdr_data
| fields action_process_image_name as apin
| filter apin != null
| alter remove_exe_process = if(lowercase(apin) contains ".exe",
replace(lowercase(apin),".exe",""),
lowercase(apin))
| limit 10
See also the ltrim, rtrim, trim function example.
17.4.68 | replex
Abstract
Learn more about the Cortex Query Language replex() function that uses a regular expression to identify and replace substrings.
Syntax
replex (<string>, <pattern>, <new_string>)
Description
The replex() function accepts a string, and then uses a regular expression to identify a substring, and then replaces matching substrings with a new string.
Displayed in the footer
Page 829 of 952
Cortex XDR Documentation
Displayed in the header
XQL uses RE2 for its regular expression implementation.
Examples
For any agent_id that contains a dotted decimal IP address, mask the IP address. Use the dedup stage to reduce the result set to first-seen agent_id
values.
dataset = xdr_data
| fields agent_id
| alter clean_agent_id = replex(agent_id,
"[\d]+\.[\d]+\.[\d]+\.[\d]+",
"xxx.xxx.xx.xx")
| dedup agent_id by asc _time
17.4.69 | round
Abstract
Learn more about the Cortex Query Language round() function that returns the input value rounded to the nearest integer.
Syntax
round (<float> | <integer>)
Description
The round() function accepts either a float or an integer as an input value, and it returns the input value rounded to the nearest integer.
Example
dataset = xdr_data
| alter mynum = divide(action_file_size, 7)
| alter mynum2 = round(mynum)
| fields action_file_size, mynum, mynum2
| filter action_file_size > 3
| limit 1
17.4.70 | row_number
Abstract
Learn more about the Cortex Query Language row_number() numbering function that is used with a windowcomp stage.
Syntax
windowcomp row_number() [by <field> [,<field>,...]] [sort [asc|desc] <field1> [, [asc|desc] <field2>,...]] [as <alias>]
Description
The row_number() function is a numbering function that is used in combination with a windowcomp stage. This function is used to return a single value for
the sequential row ordinal (1-based) for each row from a group of rows using a combination of the by clause and sort.
Example
Return a single value for the sequential row ordinal (1-based) for each row in the group of rows. The query returns a maximum of 100 xdr_data records. The
results are ordered by the source_ip in ascending order in the row_number_dns_query_name column.
dataset = xdr_data
| limit 100
| windowcomp row_number() sort source_ip as row_number_dns_query_name
17.4.71 | split
Abstract
Learn more about the Cortex Query Language split() function that splits a string and returns an array of string parts.
Syntax
split (<value> [, <string_delimiter>])
Description
The split() function splits a string using an optional delimiter, and returns the resulting substrings in an array. If no delimiter is specified, a space (' ') is used.
Displayed in the footer
Page 830 of 952
Cortex XDR Documentation
Displayed in the header
Examples
Split IP addresses into an array, each element of the array containing an IP octet.
dataset = xdr_data
| fields action_local_ip as alii
| alter ip_octets = split(alii, ".")
| limit 10
17.4.72 | stddev_population
Abstract
Learn more about the Cortex Query Language stddev_population() function used with both comp and windowcomp stages.
Syntax
comp stage
comp stddev_population(<field>) [as <alias>] by <field_1>,<field_2> [addrawdata = true|false [as <target field>]]
windowcomp stage
windowcomp stddev_population(<field>) [by <field> [,<field>,...]] [sort [asc|desc] <field1> [, [asc|desc] <field2>,...]] [between 0|null|<number>|-<number> [and
0|null|<number>|-<number>] [frame_type=range]] [as <alias>]
Description
The stddev_population() function is used to return a single population (biased) variance value of a field for a group of rows. The function syntax and
application is based on the preceding stage:
comp stage
When the stddev_population aggregation function is used with a comp stage, the function returns a single population (biased) variance value of a field
over a group of rows, for all records that contain matching values for the fields identified in the by clause.
In addition, you can configure whether the raw data events are displayed by setting addrawdata to either true or false (default), which are used to
configure the final comp results. When including raw data events in your query, the query runs for up to 50 fields that you define and displays up to 100 events.
windowcomp stage
When the stddev_population statistical aggregate function is used with a windowcomp stage, the function returns a single population (biased) variance
value of a field for each row in the group of rows, for all records that contain matching values for the fields identified using a combination of the by clause,
sort, and between window frame clause. The results are provided in a new column in the results table.
Examples
comp example
Calculates a maximum of 100 metrics_source records, where the _broker_device_id is 655AYUWF, and include a single population (biased) variance
value of the total_size_rate field for a group of rows.
dataset = metrics_source
| filter _broker_device_id = "655AYUWF"
| comp stddev_population(total_size_rate)
| limit 100
windowcomp example
Return maximum of 100 metrics_source records and include a single population (biased) variance value of the total_size_rate field for each row in the
group of rows, for all records that contain matching values in the _broker_device_id field. The results are provided in the stddev_population column.
dataset = metrics_source
| limit 100
| windowcomp stddev_population(total_size_rate) by _broker_device_id as `stddev_population`
17.4.73 | stddev_sample
Abstract
Learn more about the Cortex Query Language stddev_sample() function used with both comp and windowcomp stages.
Syntax
comp stage
comp stddev_sample(<field>) [as <alias>] by <field_1>,<field_2> [addrawdata = true|false [as <target field>]]
Displayed in the footer
Page 831 of 952
Cortex XDR Documentation
Displayed in the header
windowcomp stage
windowcomp stddev_sample(<field>) [by <field> [,<field>,...]] [sort [asc|desc] <field1> [, [asc|desc] <field2>,...]] [between 0|null|<number>|-<number> [and
0|null|<number>|-<number>] [frame_type=range]] [as <alias>]
Description
The stddev_sample() function is used to return a single sample (unbiased) standard deviation value of a field for a group of rows. The function syntax and
application is based on the preceding stage:
comp stage
When the stddev_sample aggregation function is used with a comp stage, the function returns a single sample (unbiased) standard deviation value of a field
over a group of rows, for all records that contain matching values for the fields identified in the by clause.
In addition, you can configure whether the raw data events are displayed by setting addrawdata to either true or false (default), which are used to
configure the final comp results. When including raw data events in your query, the query runs for up to 50 fields that you define and displays up to 100 events.
windowcomp stage
When the stddev_sample statistical aggregate function is used with a windowcomp stage, the function returns a single sample (unbiased) standard
deviation value of a field for each row in the group of rows, for all records that contain matching values for the fields identified using a combination of the by
clause, sort, and between window frame clause. The results are provided in a new column in the results table.
Examples
comp stage example
Calculate a maximum of 100 metrics_source records, where the _broker_device_ip is 172.16.1.25, and include a single sample (unbiased) standard
deviation value of the total_size_bytes field for a group of rows.
dataset = metrics_source
| filter _broker_device_ip = "172.16.1.25"
| comp stddev_sample(total_size_bytes)
| limit 100
windowcomp stage example
Return a maximum of 100 metrics_source records and include a single sample (unbiased) standard deviation value of the total_size_rate field for
each row in the group of rows, for all records that contain matching values in the _broker_device_id field. The results are provided in the stddev_sample
column.
dataset = metrics_source
| limit 100
| windowcomp stddev_sample(total_size_rate) by _broker_device_id as `stddev_sample`
17.4.74 | string_count
Abstract
Learn more about the Cortex Query Language string_count() function that returns the number of times a substring appears in a string.
Syntax
string_count (<string>, <pattern>)
Description
The string_count() function returns the number of times a substring appears in a string.
Example
dataset = xdr_data
| fields actor_primary_username as apu
| filter string_count(apu, "e") > 1
17.4.75 | subtract
Abstract
Learn more about the Cortex Query Language subtract() function that subtracts two integers.
Syntax
subtract (<string1> | <integer1>, <string2> | <integer2>)
Displayed in the footer
Page 832 of 952
Cortex XDR Documentation
Displayed in the header
Description
The subtract() function subtracts two positive integers by subtracting the second argument from the first argument. Parameters may be either integer
literals, or integers as a string type such as might be contained in a data field.
Example
dataset = xdr_data
| alter mynum = subtract(action_file_size, 3)
| fields action_file_size, mynum
| filter action_file_size > 3
| limit 1
17.4.76 | sum
Abstract
Cortex Query Language sum function used with both comp and windowcomp stages.
Syntax
comp stage
comp sum(<field>) [as <alias>] by <field_1>,<field_2> [addrawdata = true|false [as <target field>]]
windowcomp
windowcomp sum(<field>) [by <field> [,<field>,...]] [sort [asc|desc] <field1> [, [asc|desc] <field2>,...]] [between 0|null|<number>|-<number> [and 0|null|
<number>|-<number>] [frame_type=range]] [as <alias>]
Description
The sum() function is used to return the sum of an integer field over a group of rows. The function syntax and application is based on the preceding stage:
comp stage
When the sum aggregation function is used with a comp stage, the function returns a single sum of an integer field for a group of rows, for all records that
contain matching values for the fields identified in the by clause.
In addition, you can configure whether the raw data events are displayed by setting addrawdata to either true or false (default), which are used to
configure the final comp results. When including raw data events in your query, the query runs for up to 50 fields that you define and displays up to 100 events.
windowcomp stage
When the sum aggregate function is used with a windowcomp stage, the function returns a single sum of an integer field for each row in the group of rows, for
all records that contain matching values for the fields identified using a combination of the by clause, sort, and between window frame clause. The results
are provided in a new column in the results table.
Examples
comp example
Return a single sum of the action_total_download field for a group of rows, for all records that have matching values for their
actor_process_image_path and actor_process_command_line values. The query calculates a maximum of 100 xdr_data records and includes a
raw_data column listing a single value for the results.
dataset = xdr_data
| fields actor_process_image_path as Process_Path, actor_process_command_line as Process_CMD, action_total_download as Download
| filter Download > 0
| limit 100
| comp sum(Download) as total_download by Process_Path, Process_CMD addrawdata = true as raw_data
windowcomp
Return the download to upload ratio per process. The query returns a maximum of 100 xdr_data records in new columns called sum_upload and
sum_download.
dataset = xdr_data
| fields actor_process_image_path as Process_Path, actor_process_command_line as Process_CMD, action_total_download as Download, action_total_upload as Upload
| filter Download > 0
| limit 100
| windowcomp sum(Download) by Process_Path, Process_CMD as sum_download
| windowcomp sum(Upload) by Process_Path, Process_CMD as sum_upload
| fields - Download ,Upload
| dedup Process_CMD, Process_Path, sum_download ,sum_upload
| alter ration = divide(sum_download ,sum_upload)
Displayed in the footer
Page 833 of 952
Cortex XDR Documentation
Displayed in the header
17.4.77 | time_frame_end
Abstract
Learn more about the Cortex Query Language time_frame_end() function that returns the end time of the time range specified for the query.
Syntax
time_frame_end(<time frame>)
Description
The time_frame_end() function returns the timestamp object for the string representation of the end of the time frame configured for the query in the format
MMM dd YYYY HH:mm:ss, such as Jun 8th 2022 15:20:06. You can configure the time frame using the config timeframe function, where the range can be
relative or exact.
If the time frame is relative, for example last 24H, the function returns the current_time. This function is useful when the query uses a custom time frame whose
end time is in the past.
Example 1 - Relative Time
For the last 5 days from when the query is sent, returns a maximum of 100 xdr_data records with the events of the _time field with a new field called "x". The
"x" field lists the final timestamp at the end of 5 days from when the query was sent for the events in descending order. For more information on this relative
timeframe range, see the config timeframe function.
config timeframe = 5d
| dataset = xdr_data
| alter x = time_frame_end()
| fields x
| sort desc x
Example 2 - Relative Time
For the last 5 days from when the query is run until now, returns a maximum of 100 xdr_data records with the events of the _time field with a new field called "x".
The "x" field lists the final timestamp at the end of 5 days from when the query runs for the events in descending order. For more information on this relative time
frame range, see the config timeframe function.
config timeframe = between "5d" and "now"
| dataset = xdr_data
| alter x = time_frame_end()
| fields x
| sort desc
17.4.78 | timestamp_diff
Abstract
Learn more about the Cortex Query Language timestamp_diff() function that returns the difference between two timestamp objects.
Syntax
timestamp_diff (<timestamp1>, <timestamp2>, <part>)
Description
The timestamp_diff() function returns the difference between two timestamp objects. The units used to express the difference is identified by the part
parameter. The second timestamp is subtracted from the first timestamp. If the first timestamp is greater than the second, a positive value is returned. If the
result of this function is between 0 and 1, 0 is returned.
Supported parts are:
DAY
HOUR
MINUTE
SECOND
MILLISECOND
MICROSECOND
Example
dataset = xdr_data
| filter story_publish_timestamp != null
| alter ts = to_timestamp(story_publish_timestamp, "MILLIS")
Displayed in the footer
Page 834 of 952
Cortex XDR Documentation
Displayed in the header
| alter ct = current_time()
| alter diff = timestamp_diff(ct, ts, "MINUTE")
| fields ts, ct, diff
| limit 1
17.4.79 | timestamp_seconds
Abstract
Learn more about the Cortex Query Language timestamp_seconds() function.
Syntax
timestamp_seconds (<integer>)
Description
The timestamp_seconds() function converts an epoch time Integer value in seconds to a TIMESTAMP compatible value.
Endpoint Detection and Response (EDR) columns store epoch milliseconds values so this function is more useful for values that you insert.
Example
Display a human-readable timestamp for the action_file_access_time field.
alter access_timestamp = timestamp_seconds(1611882205) | limit 1
17.4.80 | to_boolean
Abstract
Learn more about the Cortex Query Language to_boolean() function that converts a string to a boolean.
Syntax
to_boolean(<string>)
Description
The to_boolean() function converts a string that represents a boolean to a boolean value.
The input value to this string must be either TRUE or FALSE, case insensitive.
Example
17.4.81 | to_epoch
Abstract
Learn more about the Cortex Query Language to_epoch() function that converts a timestamp value for a field or function to the Unix epoch timestamp
format.
Syntax
to_epoch (<timestamp>, <time unit>)
Description
The to_epoch() function converts a timestamp value for a particular field or function to the Unix epoch timestamp format. This function requires a <time
unit> value, which indicates whether the integer value for the Unix epoch timestamp format represents seconds (default), milliseconds, or microseconds. If
no <time unit> is configured, the default is used. Supported values are:
SECONDS
MILLIS
MICROS
Example
Returns a maximum of 100 xdr_data records with the events of the _time field, which includes a timestamp field in the Unix epoch format called ts. The ts
field contains the equivalent Unix epoch values in milliseconds for the timestamps listed in the _time field.
Displayed in the footer
Page 835 of 952
Cortex XDR Documentation
Displayed in the header
dataset = xdr_data
| filter _time != null
| alter ts = to_epoch(_time, "MILLIS")
| fields ts
| limit 100
17.4.82 | to_float
Abstract
Learn more about the Cortex Query Language to_float() function that converts a string to a floating point number.
Syntax
to_float(<string>)
Description
The to_float() function converts a string that represents a number to a floating point number. This function is identical to the to_number function.
Examples
Display the first 10 IP addresses that begin with a value greater than 192. Use the split function to split the IP address by '.', and then use the arrayindex
function to retrieve the first value in the resulting array. Convert this to a number and perform an arithmetic compare to arrive at a result set.
dataset = xdr_data
| fields action_local_ip as alii
| filter to_float(arrayindex(split(alii, "."),0)) > 192
| limit 10
17.4.83 | to_integer
Abstract
Learn more about the Cortex Query Language to_integer() function that converts a string field to an integer.
Syntax
to_integer(<string>)
Description
The to_integer() function converts a string value that represents a number of a given field to an integer. A good application of using the to_integer
function is when querying for USB vendor IDs and USB product IDs, which are usually provided in a hex format.
It is an error to provide a string to this function that contains a floating point number.
Examples
Display the first 10 IP addresses that begin with a value greater than 192. Use the split function to split the IP address by '.', and then use the arrayindex
function to retrieve the first value in the resulting array. Convert this to a number and perform an arithmetic compare to arrive at a result set.
dataset = xdr_data
| fields action_local_ip as alii
| filter to_integer(arrayindex(split(alii, "."),0)) > 192
| limit 10
17.4.84 | to_json_string
Abstract
Learn more about the Cortex Query Language to_json_string() function that accepts all data types and returns its contents as a JSON formatted string.
Syntax
to_json_string(<data type>)
Description
The to_json_string() function accepts all data types, such as integers, booleans, strings, and returns it as a JSON formatted string. This function always
returns a string. When the input is an object or an array, the function returns a JSON formatted string of the input. When the input string is a string, it returns the
string as is. You can then use the JSON formatted string or string returned by this function with the json_extract, json_extract_array, and json_extract_scalar
functions.
Displayed in the footer
Page 836 of 952
Cortex XDR Documentation
Displayed in the header
Examples
Return the action_file_device_info field in JSON format.
dataset = xdr_data
| fields action_file_device_info as afdi
| filter afdi != null
| alter the_json_string = to_json_string(afdi)
| limit 10
17.4.85 | to_number
Abstract
Learn more about the Cortex Query Language to_number() function that converts a string to a number.
Syntax
to_number (<string>)
Description
The to_number() function converts a string that represents a number to a floating point number. This function is identical to the to_float function.
Examples
Display the first 10 IP addresses that begin with a value greater than 192. Use the split function to split the IP address by '.', and then use the arrayindex
function to retrieve the first value in the resulting array. Convert this to a number and perform an arithmetic compare to arrive at a result set.
dataset = xdr_data
| fields action_local_ip as alii
| filter to_number(arrayindex(split(alii, "."),0)) > 192
| limit 10
17.4.86 | to_string
Abstract
Learn more about the Cortex Query Language to_string function that converts a number value to a string.
Syntax
to_string (<field>)
Description
The to_string() function converts a number value of a given field to a string.
Examples
Display the first non-NULL action_boot_time field value. In a second column called abt_string, use the concat function to prepend "str: " to the value,
and then display it.
dataset = xdr_data
| fields action_boot_time as abt
| filter abt != null
| alter abt_string = concat("str: ", to_string(abt))
| limit 1
17.4.87 | to_timestamp
Abstract
Learn more about the Cortex Query Language to_timestamp() function that converts an integer to a timestamp.
Syntax
to_timestamp (<integer>, <units>)
Description
The to_timestamp() function converts an integer to a timestamp. This function requires a units value, which indicates whether the integer represents
seconds, milliseconds, or microseconds since the Unix epoch. Supported values are:
Displayed in the footer
Page 837 of 952
Cortex XDR Documentation
Displayed in the header
SECONDS
MILLIS
MICROS
Example
dataset = xdr_data
| filter story_publish_timestamp != null
| alter ts = to_timestamp(story_publish_timestamp, "MILLIS")
| fields ts
17.4.88 | uppercase
Abstract
Learn more about the Cortex Query Language uppercase() function that converts a string field to all uppercase letters.
Syntax
uppercase (<string>)
Description
The uppercase() function converts a string field value to all uppercase.
Examples
Convert all actor_process_image_name field values that are not null to uppercase, and return a list of unique values.
dataset = xdr_data
| fields actor_process_image_name as apin
| dedup apin by asc _time
| filter apin != null
| alter apin = uppercase(apin)
17.4.89 | values
Abstract
Cortex Query Language comp values aggregate returns an array for all the values seen for the field in the result set.
Syntax
comp values(<field>) [as <alias>] by <field_1>,<field_2> [addrawdata = true|false [as <target field>]]
Description
The values aggregation is a comp function that returns an array of all the values found for a given field over a group of rows, for all records that contain
matching values for the fields identified in the by clause. The array values are all non-null. Each value appears in the array only once, even if a given value
repeats multiple times in the result set. This function is used in combination with a comp stage.
In addition, you can configure whether the raw data events are displayed by setting addrawdata to either true or false (default), which are used to
configure the final comp results. When including raw data events in your query, the query runs for up to 50 fields that you define and displays up to 100 events.
Example
Return an array containing all the values seen for the action_total_download field for all records that have matching values for their
actor_process_image_path and actor_process_command_line values. The query calculates a maximum of 100 xdr_data records and includes a
raw_data column listing the raw data events used to display the final comp results. In addition, this example contains a number of fields defined as aliases:
actor_process_image_path uses the alias Process_Path, actor_process_command_line uses the alias Process_CMD,
action_total_download uses the alias Download, and Download uses the alias values_download.
dataset = xdr_data
| fields actor_process_image_path as Process_Path, actor_process_command_line as Process_CMD, action_total_download as Download
| filter Download > 0
| limit 100
| comp values(Download) as values_download by Process_Path, Process_CMD addrawdata = true as raw_data
17.4.90 | var
Abstract
Displayed in the footer
Page 838 of 952
Cortex XDR Documentation
Displayed in the header
Learn more about the Cortex Query Language var aggregate comp function that returns the variance value of a field in the result set.
Syntax
comp var(<field>) [as <alias>] by <field_1>,<field_2> [addrawdata = true|false [as <target field>]]
Description
The var aggregation is a comp function that returns a single variance value of a field over a group of rows, for all records that contain matching values for the
fields identified in the by clause. This function is used in combination with a comp stage.
In addition, you can configure whether the raw data events are displayed by setting addrawdata to either true or false (default), which are used to
configure the final comp results. When including raw data events in your query, the query runs for up to 50 fields that you define and displays up to 100 events.
Example
Return the variance of the action_total_download field for all records that have matching values for their actor_process_image_path and
actor_process_command_line values. The query calculates a maximum of 100 xdr_data records and includes a raw_data column listing the raw data
events used to display the final comp results.
dataset = xdr_data
| fields actor_process_image_path as Process_Path, actor_process_command_line as Process_CMD, action_total_download as Download
| filter Download > 0
| limit 100
| comp var(Download) as variance_download by Process_Path, Process_CMD
addrawdata = true as raw_data
18 | Reference
18.1 | RBAC permissions
Abstract
Learn more about the RBAC permissions specifically about role permissions by component and the default Palo Alto Networks roles.
Cortex XDR uses role-based access control (RBAC) to manage roles with specific permissions for controlling user access. This section provides reference
information related to role permissions by component and the default Palo Alto Networks roles.
18.1.1 | Role permissions by components
Abstract
Learn how to manage role permissions in Cortex XDR.
You can manage role permissions in Cortex XDR, which are listed by the various components according to the sidebar navigation in Cortex XDR. Dataset
permissions are also included for custom roles. Some components include additional action permissions, such as pivot (right-click) options, to which you can
also assign access to, but only when you’ve given the user View/Edit permissions to the applicable component. Whenever you create a new role or edit an
existing role, these role permissions are configurable for all Cortex XDR apps and services in the Components tab of the Create Role window on the Roles
page. For more information, see Manage user roles.
Cortex XDR provides predefined Palo Alto Networks roles, which have set role permissions. For more information, see Default PANW roles.
The following table explains for each Cortex XDR component and additional action permissions, which are listed according to the sidebar navigation headings,
the pages that can be accessed with this role permission with the detailed edit permissions available on each page, and any additional information you should
know about the role permissions for this component.
Dashboards & Reports
Displayed in the footer
Page 839 of 952
Cortex XDR Documentation
Displayed in the header
Components Additional Action Permissions With View/Edit Permissions Access Permissions To These Pages With Detailed View/Edit Permissions Add
Dashboards — Dashboards & Reports → Dashboard → Data Ingestion dashboard Das
→C
Change mode
Wid
Edit disp
use
Mark as default set
the
Save as report template
Dashboards & Reports → Customize → Dashboards Manager
New
Edit
Save as new
Set as default
Save as a report
Private/public
Disable
Delete
Ingestion — Dashboards & Reports → Dashboard → Data Ingestion Dashboard
Monitoring
No detailed View/Edit permissions
Reports — Dashboards & Reports → Reports Cus
Libr
Delete
whe
Dashboards & Reports → Customize → Reports Templates per
leas
New follo
Delete
Edit
Generate Report
Save as new
Incident Response
Incident & Alerts
Components Additional Action Permissions With View/Edit Permissions Access Permissions To These Pages With Detailed View/Edit Permissions Add
Alerts & — Incident Response → Incidents
Incidents
All actions
Incident Response → Incidents → Alerts Table → Alerts
All actions
Incident Response → Incident Configuration
All actions
Investigation
Displayed in the footer
Page 840 of 952
Cortex XDR Documentation
Displayed in the header
Components Additional Action Permissions With View/Edit Permissions Access Permissions To These Pages With Detailed View/Edit Permissions Add
Query Center — Incident Response → Investigation → Query Builder Edit
Cor
Pivot to XQL Query Builder (editor).
req
Incident Response → Investigation → Query Center per
the
Show results →I
Que
Rename
Det
Save query results Inte
Rul
Schedule queries
Remove queries
Incident Response → Investigation → Scheduled Queries
Show executed queries
Edit
Remove
Rename
Disable
Detection & Threat Intel → Detection Rules → BIOC → BIOC Rules
Add BIOC with View/Edit permissions for the Query Center.
Detection & Threat Intel → Detection Rules → Correlations →
Correlation Rules
Add Correlation with View/Edit permissions for the Query Center.
Settings → Configurations → Data Management → Compute Units
Usage
View only as an informative page with View permissions for the
Query Center.
Personal — Incident Response → Investigation → Query Builder → XQL Search to access
Query your personal queries in the Query Library tab.
Library
Save to library
Edit
Labels
Description
Private/public
Forensics — Incident Response → Investigation → Forensics, where all pages related to
Forensics are accessible and all actions can be performed.
Displayed in the footer
Page 841 of 952
Cortex XDR Documentation
Displayed in the header
Components Additional Action Permissions With View/Edit Permissions Access Permissions To These Pages With Detailed View/Edit Permissions Add
Host Insights — Incident Response → Investigation → Host Inventory
Can open in asset view without being able to perform any actions.
Assets → Vulnerability Assessment
Exclude
Add comment
Asset View from Quick Launcher → IP View, and pivot (right-click) from
a host with a Cortex XDR agent installed.
Response
Components Additional Action Permissions With View/Edit Permissions Access Permissions To These Pages With Detailed View/Edit Permissions Add
Action ✓ Incident Response → Response → Action Center
Center
Isolate Incident Response → Response → Action Center → All Actions → New
Action and from the Define an Action page, select Isolate.
✓
Endpoints → All Endpoints, and pivot (right-click) from a host with a
Cortex XDR agent installed, and select Security Operations → Isolate
Endpoint.
Incident Response → Incidents → Executions tab
All actions
Terminate Process Causality chain view is available from the Alerts table (Incident Response →
Incidents → Alerts Table), or from the Query Results after running a query on
✓ the related data. From both of these places, you can pivot (right-click) to the
causality chain view from any row in the table and select:
Investigate Causality Chain → Open Card in new tab
Investigate Causality Chain → Open Card in same tab
Quarantine Causality chain view is available from the Alerts table (Incident Response →
Incidents → Alerts Table), or from the Query Results after running a query on
✓ the related data. From both of these places, you can pivot (right-click) to the
causality chain view from any row in the table and select:
Investigate Causality Chain → Open Card in new tab
Investigate Causality Chain → Open Card in same tab
File Retrieval Incident Response → Response → Action Center → All Actions → New
Action and from the Define an Action page, select Files Retrieval.
✓
Endpoints → All Endpoints, and pivot (right-click) from a host with a
Cortex XDR agent installed, and select Security Operations → Retrieve
Endpoint Files.
Incident Response → Incidents → Executions tab
Retrieve Support File
Displayed in the footer
Page 842 of 952
Cortex XDR Documentation
Displayed in the header
Components Additional Action Permissions With View/Edit Permissions Access Permissions To These Pages With Detailed View/Edit Permissions Add
File Search Incident Response → Incidents → Key Assets & Artifacts tab, and search for
a file.
✓
Destroy Files Incident Response → Response → Action Center → All Actions → New Action
and from the Define an Action page, select Destroy file.
✓
All actions
Allow List/Block List Incident Response → Response → Action Center → All Actions → New
Action and from the Define an Action page, select either:
✓
Add to block list
Add to allow list
Incident Response → Response → Action Center → Currently Applied
Actions → Block List
Disable
Move to Allow List
Edit Comment
Delete
Incident Response → Response → Action Center → Currently Applied
Actions → Allow List
Disable
Move to Block List
Edit Comment
Delete
Disable Response Actions Endpoints → All Endpoints, and pivot (right-click) an endpoint that isn't an iOS
endpoint, and select Endpoint Control → Disable Capabilities.
✓
Remediation
Delete Quarantined Files Incident Response → Response → Action Center → Currently Applied
Actions → File Quarantine
Delete
EDL — Incident Response → Response → EDL
Add
Delete
Agent Scripts ✓ Incident Response → Response → Action Center → Agent Script Library
Library
Displayed in the footer
Page 843 of 952
Cortex XDR Documentation
Displayed in the header
Components Additional Action Permissions With View/Edit Permissions Access Permissions To These Pages With Detailed View/Edit Permissions Add
Run Standard Script Incident Response → Response → Action Center → Agent Script
Library, and any script from the Scripts Library table, where the
✓ Outcome column is set to Standard, you can select:
Run
Incident Response → Response → Action Center → All Actions+New
Action, and from the Choose page, select Run Endpoint Script.
The standard scripts are available in the Scripts list to select from.
Run High-Risk Script Incident Response → Response → Action Center → Agent Script Library, and
any script from the Scripts Library table, where the Outcome column is set to
✓ High Risk, you can select:
Run
Incident Response → Response → Action Center → All Actions+New
Action, and from the Choose page, select Run Endpoint Script.
The high-risk scripts are available in the Scripts list to select from.
Script Configurations Incident Response → Response → Action Center → Agent Script Library
✓ New Script
Edit
Save as new
Delete
Download definitions file
Live Terminal — Incident Response → Response → Live Terminal
Incident Response → Incidents → Executions tab
Endpoints → All Endpoints, pivot (right-click) from a host with a Cortex
XDR agent installed, and select Security Operations → Initiate Live
Terminal.
Automation — Incident Response → Response → Automation → Automation Rules
Rules
All actions
Detections & Threat Intel
Detections
Displayed in the footer
Page 844 of 952
Cortex XDR Documentation
Displayed in the header
Components Additional Action Permissions With View/Edit Permissions Access Permissions To These Pages With Detailed View/Edit Permissions Add
Rules ✓ Detection & Threat Intel → Detection Rules → IOC → IOC Rules Edit
Cor
Add IOC
req
Edit per
the
Disable →I
Que
Delete
abo
Add to EDL &T
Det
Detection & Threat Intel → Detection Rules → BIOC → BIOC Rules
Add BIOC
Import Rules
Disable
Save as new
Open in Query Builder
Detection & Threat Intel → Detection Rules → Correlations →
Correlation Rules
Add Correlation
Exclude Rule
Disable
Edit
Save as new
Delete
Detection & Threat Intel → Detection Rules → Exceptions
New Exception
Import Exceptions
Edit
Delete
Export
Prevention Rules Detection & Threat Intel → Threat Intel Management → Indicator Rules
✓ Add Rule > Prevention Rule
Add Rule > Detection Rule
Detection Rules → BIOC, select one or more BIOC rules, and right-click:
Add selection to restrictions profile (only agent-supported) rules
Endpoints → Policy Management → Prevention → Profiles, click Add
Profile, and select whether to create a new profile or import a profile
from a file. Select the applicable platform, and Restrictions as the profile
type. When you continue configuring the restrictions profile, the
following section is displayed:
Custom Prevention Rules
Displayed in the footer
Page 845 of 952
Cortex XDR Documentation
Displayed in the header
Components Additional Action Permissions With View/Edit Permissions Access Permissions To These Pages With Detailed View/Edit Permissions Add
Request WildFire Verdict Change From a WildFire report, you can click Report Verdict as Incorrect, and
under Suggested Verdict, suggest a new verdict. Open a WildFire report from:
✓
Incident Response → Incidents → Key Assets & Artifacts tab, and
under Artifacts, identify a file with a WildFire verdict and click Wildfire
Analysis Report
Incident Response → Incidents → Alerts Table → Alerts, hover over the
alert, and Investigate. You can open the WildFire report of any file
included in the alert Causality Chain.
Assets
Components Additional Action Permissions With View/Edit Permissions Access Permissions To These Pages With Detailed View/Edit Permissions Add
Network — Assets → Network Configuration → IP Addresses Ranges You
Configuration dele
Edit
ran
Delete the
add
Assets → Network Configuration → Internal Domain Suffixes
Edit
Compliance — Assets → Cloud Compliance → Compliance Violation table
Dashboards & Reports → Dashboard → Compliance Violation
Asset — Assets → Asset Inventory Ass
Inventory is d
All actions
use
Assets → Asset Scores set
All actions
Assets → Cloud Inventory → All Cloud Assets
All actions
Asset Roles — Assets → Asset Roles Configuration
Configuration
All actions
Endpoints
Components Additional Action Permissions With View/Edit Permissions Access Permissions To These Pages With Detailed View/Edit Permissions Ad
Endpoint ✓ Endpoints → All Endpoints
Administrations
Same actions as View permissions when an action permission is not
selected
Displayed in the footer
Page 846 of 952
Cortex XDR Documentation
Displayed in the header
Components Additional Action Permissions With View/Edit Permissions Access Permissions To These Pages With Detailed View/Edit Permissions Ad
Endpoint Management Endpoints → All Endpoints
✓ Locate one or more endpoints, right-click and select:
Endpoint Control → Perform Heartbeat
Select one or more endpoints that you want to force the check-in of, and
right-click + Alt to open the options menu in advanced mode, and
select Endpoint Control → Force Check-in.
Select one or more agents that you want to restart, and right-click + Alt
to open the options menu in advanced mode, and select Endpoint
Control → Restart Agent.
Endpoint Control → Change Endpoint Alias
Endpoint Control → Upgrade Agent Version
Endpoint Control → Set Agent Proxy
Endpoint Control → Uninstall Agent
Endpoint Control → Delete Endpoint
Endpoint Control → Exclude endpoints from auto upgrade
Endpoint Control → Include endpoints in auto upgrade
Retrieve Endpoint Data Endpoints → All Endpoints
✓ Locate one or more endpoints, right-click and select Endpoint
Control → Retrieve Support File.
Endpoint Scan Endpoints → All Endpoints
✓ Locate one or more endpoints, right-click and select:
Security Operations → Initiate Malware Scan
Security Operations → Abort Malware Scan
Change Managing Server Endpoints → All Endpoints
✓ Select one or more agents that you want to move to the target server,
and right-click + Alt to open the options menu in advanced mode, and
select Endpoint Control → Change managing server.
Pause Protection Endpoints → All Endpoints
✓ Select the endpoints you want to pause protection on, right-click and
select Endpoint Control → Pause Endpoint Protection.
Endpoint Token Management Endpoints → All Endpoints
✓ On the top right corner of the screen, the Tokens and Passwords icon is
displayed, which you can left-click and select:
Retrieve Token
Retrieve Support File Password
Displayed in the footer
Page 847 of 952
Cortex XDR Documentation
Displayed in the header
Components Additional Action Permissions With View/Edit Permissions Access Permissions To These Pages With Detailed View/Edit Permissions Ad
Endpoint — Endpoints → Endpoint Groups
Groups
Add Group
View endpoints
Edit
Delete
Save as new
Export group
Endpoint — Endpoints → Policy Management → Prevention → Policy Rules
Prevention
Policies View Policy Details
Edit
Save As New
Disable
Delete
Global — Endpoints → Policy Management → Prevention → Global Exceptions
Exceptions
All actions
Endpoint — Endpoints → Policy Management → Extensions → Profiles
Profiles
Add Profile
Edit Profile
Save As New
Delete
Displayed in the footer
Page 848 of 952
Cortex XDR Documentation
Displayed in the header
Components Additional Action Permissions With View/Edit Permissions Access Permissions To These Pages With Detailed View/Edit Permissions Ad
Endpoint — Endpoints → Policy Management → Extensions
Extension
Policy Rules:
Policies
View Policy Details
Edit
Save As New
Disable
Delete
Profiles
Add Profile
Edit Profile
Save As New
Delete
Device Permanent Exceptions
All actions
Device Temporary Exceptions
All actions
Endpoint — Endpoints → Agent Installations
Installations
Create
Edit
Delete
64 bit installer
32 bit installer
Hide this row
Show rows
Host Firewall — Endpoints → Host Firewall → Rule Groups U
Ex
New Group w
Edit Group ho
Save As New
Disable Group
Delete Group
Export Group Rules
Import Group Rules
Show rows
Hide rows
Endpoints → Host Firewall → Host Firewall Events
Collect Detailed Host Firewall Logs
Displayed in the footer
Page 849 of 952
Cortex XDR Documentation
Displayed in the header
Components Additional Action Permissions With View/Edit Permissions Access Permissions To These Pages With Detailed View/Edit Permissions Ad
Device Control ✓
Device Control Rules Endpoints → Device Control Violations
✓ Add device to permanent exceptions
Add device to temporary exceptions
Add device to a profile exception
Device Control Exceptions Endpoints → Disk Encryption Visibility
Configurations
General Setting
Components Additional Action Permissions With View/Edit Permissions Access Permissions To These Pages With Detailed View/Edit Permissions Add
Auditing — Settings → Management Audit Logs XDR
Log
No detailed View/Edit permissions
aC
Settings → Agent Audit Logs GB
No detailed View/Edit permissions
Settings → XDR Collector Audit Logs
Alert — Notifications
Notification
General — Settings → Configurations → General → Server Settings
Configuration
Timezone:
Edit timezone
Timestamp Format
Edit timestamp format
Email Contacts
Add
Define the incidents target MTTR per incident severity
Set the days and hours
Impersonation Role
Edit impersonation role
Cortex XDR - Analytics
Displayed in the footer
Page 850 of 952
Cortex XDR Documentation
Displayed in the header
Components Additional Action Permissions With View/Edit Permissions Access Permissions To These Pages With Detailed View/Edit Permissions Add
On-demand — Settings → Configurations → Cortex XDR - Analytics
Analytics
Enable
Identity Analytics
Data Broker
Components Additional Action Permissions With View/Edit Permissions Access Permissions To These Pages With Detailed View/Edit Permissions Add
Broker ✓ Settings → Configurations → Data Broker → Broker VMs
Service
Add Broker → Download any of the broker images
Add Broker → Generate Token
All applet actions
Pathfinder Applet Settings → Configurations → Data Broker → Broker VMs, and in the APPS
column of the Broker VMs page, the Pathfinder applet is displayed.
✓
All actions
Pathfinder — Settings → Configurations → Data Collection → Pathfinder Collection Center To u
Data Col
Collection All actions you
View
for t
and
App
per
Data Collection
Displayed in the footer
Page 851 of 952
Cortex XDR Documentation
Displayed in the header
Components Additional Action Permissions With View/Edit Permissions Access Permissions To These Pages With Detailed View/Edit Permissions Add
Log — Settings → Configurations → XDR Collectors → Configuration Ing
Collections dat
All actions
XDR
Settings → Configurations → XDR Collectors → Administration lice
Change Collector Alias
Upgrade Collector Version
Set Collector Proxy
Uninstall Collector
Delete Collector
Retrieve Support Files
Settings → Configurations → XDR Collectors → Groups
Add Group
Edit
Delete
Save as new
Settings → Configurations → XDR Collectors → Installers
Create
Delete
Hide
Settings → Configurations → XDR Collectors → Profiles
Add Profile
Edit
Save As New
Delete
Settings → Configurations → XDR Collectors → Policies
Add Policy
Disable
Delete
Save As New
Edit
Settings → Configurations → Data Collection → Custom Collectors
All actions
Settings → Configurations → Data Collection → Collection Integrations
All actions
External — Settings → Configurations → Data Collection → External Alert Mapping
Alerts
Mapping Save as new
Disable
Data Management
Displayed in the footer
Page 852 of 952
Cortex XDR Documentation
Displayed in the header
Components Additional Action Permissions With View/Edit Permissions Access Permissions To These Pages With Detailed View/Edit Permissions Add
Data — Settings → Configurations → Data Management → Dataset To s
Management Management Com
use
All actions
Pub
Settings → Configurations → Data Management → Parsing Rules belo
All actions
Settings → Configurations → Data Management → Event Forwarding
All actions
Integrations
Components Additional Action Permissions With View/Edit Permissions Access Permissions To These Pages With Detailed View/Edit Permissions Add
Public API — Settings → Configurations → Data Management → Compute Unit
Usage
Settings → Configurations → Integrations → API Keys
New Key
Edit
Delete
Save as new
Threat — Settings → Configurations → Integrations → Threat intelligence
Intelligence
Create
Delete
Edit
Long —
Running
HTTP
Integrations
configuration
Help
Components Additional Action Permissions With View/Edit Permissions Access Permissions To These Pages With Detailed View/Edit Permissions Add
Support — Help → Submit a Support Caser
18.1.2 | Default PANW roles
Abstract
Learn more about the default Palo Alto Networks user roles included in Cortex XDR.
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. For more information, see Assign user roles and groups.
Displayed in the footer
Page 853 of 952
Cortex XDR Documentation
Displayed in the header
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.
18.1.2.1 | Account Admin
Abstract
Learn more about the Cortex XDR predefined user role called Account Admin.
The Account Admin is a Super User role that is assigned directly to the user in Cortex Gateway and has full access to all Cortex products in your account,
including all tenants added in the future. The Account Admin can assign roles for Cortex instances and activate Cortex tenants specific to the product.
The user who activated the Cortex product is assigned the Account Admin role. You cannot create additional Account Admin roles in the Cortex XDR tenant. If
you do not want the user to have Account Admin permission, you need to remove the Account Admin role in Cortex Gateway.
Dashboards & Reports
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Dashboards — — ✓ —
Ingestion Monitoring — ✓ N/A —
Reports — — ✓ —
Incident Response
Incidents & Alerts
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Alerts & incidents — — ✓ —
Investigation
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Query Center — — ✓ —
Personal Query Library — — ✓ —
Forensics — — ✓ —
Host Insights — — ✓ —
Response
Displayed in the footer
Page 854 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Action Center — — ✓ ✓
Isolate
Terminate Process
Quarantine
File Retrieval
File Search
Destroy Files
Allow List/Block List
Disable Response Actions
Remediation
Delete Quarantined files
EDL — N/A ✓ —
Agent Scripts Library — — ✓ ✓
Run Standard Script
Displayed in the footer
Page 855 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
Run High-Risk Script
Script Configurations
Live Terminal — N/A ✓ —
Automation Rules — — ✓ —
Detections & Threat Intel
Detections
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Rules — — ✓ ✓
Prevention Rules
Request WildFire Verdict Change
Assets
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Network Configuration — — ✓ —
Compliance — ✓ N/A —
Asset Inventory — — ✓ —
Asset Roles Configuration — — ✓ —
Endpoints
Displayed in the footer
Page 856 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Endpoint Administrations — — ✓ ✓
Endpoint Management
Retrieve Endpoint Data
Endpoint Scan
Change Managing Server
Pause Protection
Endpoint Token Management
Endpoint Groups — — ✓ —
Endpoint Prevention Policies — — ✓ —
Global Exceptions — — ✓ —
Endpoint Profiles — — ✓ —
Endpoint Extension Policies — — ✓ —
Endpoint Installations — — ✓ —
Host Firewall — — ✓ —
Device Control — — ✓ ✓
Device Control Rules
Displayed in the footer
Page 857 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
Device Control Exceptions
Configurations
General Settings
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Auditing — ✓ N/A —
Alert Notifications — — ✓ —
General Configuration — — ✓ —
Cortex XDR - Analytics
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
On-demand Analytics — — ✓ —
Data Broker
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Broker Services — — ✓ ✓
Pathfinder Applet
Pathfinder Data Collection — — ✓ —
Data Management
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Displayed in the footer
Page 858 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
Data Management — N/A ✓ —
Integrations
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Public API — — ✓ —
Threat Intelligence — — ✓ —
Long Running HTTP Integrations configuration — — ✓ —
Help
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Support — N/A ✓ —
18.1.2.2 | Deployment Admin
Abstract
Learn more about the Cortex XDR predefined user role called Deployment Admin.
The Deployment Admin role is used to manage and control endpoints and installations, and configure Broker VMs.
Dashboards & Reports
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Dashboards — — ✓ —
Ingestion Monitoring ✓ — N/A —
Reports — — ✓ —
Incident Response
Incidents & Alerts
Displayed in the footer
Page 859 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Alerts & incidents ✓ — — —
Investigation
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Query Center — — ✓ —
Personal Query Library — ✓ — —
Forensics ✓ — — —
Host Insights ✓ — — —
Response
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Action Center ✓ — — ✓
Isolate
Terminate Process
Quarantine
File Retrieval
File Search
Displayed in the footer
Page 860 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
Destroy Files
Allow List/Block List
Disable Response Actions
Remediation
Delete Quarantined files
EDL ✓ N/A — —
Agent Scripts Library ✓ — — ✓
Run Standard Script
Run High-Risk Script
Script Configurations
Live Terminal ✓ N/A — —
Automation Rules ✓ — — —
Detections & Threat Intel
Detections
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Rules ✓ — — ✓
Displayed in the footer
Page 861 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
Prevention Rules
Request WildFire Verdict Change
Assets
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Network Configuration ✓ — — —
Compliance ✓ — N/A —
Asset Inventory — ✓ — —
Asset Roles Configuration ✓ — — —
Endpoints
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Endpoint Administrations — — ✓ ✓
Endpoint Management
Retrieve Endpoint Data
Endpoint Scan
Change Managing Server
Pause Protection
Displayed in the footer
Page 862 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
Endpoint Token Management
Endpoint Groups — — ✓ —
Endpoint Prevention Policies ✓ — — —
Global Exceptions — ✓ — —
Endpoint Profiles ✓ — — —
Endpoint Extension Policies ✓ — — —
Endpoint Installations — — ✓ —
Host Firewall ✓ — — —
Device Control ✓ — — ✓
Device Control Rules
Device Control Exceptions
Configurations
General Settings
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Auditing — ✓ N/A —
Alert Notifications ✓ — — —
General Configuration ✓ — — —
Cortex XDR - Analytics
Displayed in the footer
Page 863 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
On-demand Analytics ✓ — — —
Data Broker
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Broker Services — — ✓ ✓
Pathfinder Applet
Pathfinder Data Collection — — ✓ —
Data Management
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Data Management ✓ N/A — —
Integrations
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Public API ✓ — — —
Threat Intelligence ✓ — — —
Long Running HTTP Integrations configuration ✓ — — —
Help
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Displayed in the footer
Page 864 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
Support — N/A ✓ —
18.1.2.3 | Instance Administrator
Abstract
Learn more about the Cortex XDR predefined user role called Instance Administrator.
The Instance Administrator role provides view and edit permissions for all components and can access all pages in the Cortex XDR tenant. The Instance
Administrator can also make other users an Instance Administrator for the tenant. If the tenant has predefined or custom roles, the Instance Administrator can
assign those roles to other users.
Dashboards & Reports
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Dashboards — — ✓ —
Ingestion Monitoring — ✓ N/A —
Reports — — ✓ —
Incident Response
Incidents & Alerts
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Alerts & incidents — — ✓ —
Investigation
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Query Center — — ✓ —
Personal Query Library — — ✓ —
Forensics — — ✓ —
Displayed in the footer
Page 865 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
Host Insights — — ✓ —
Response
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Action Center — — ✓ ✓
Isolate
Terminate Process
Quarantine
File Retrieval
File Search
Destroy Files
Allow List/Block List
Disable Response Actions
Remediation
Delete Quarantined files
EDL — N/A ✓ —
Displayed in the footer
Page 866 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
Agent Scripts Library — — ✓ ✓
Run Standard Script
Run High-Risk Script
Script Configurations
Live Terminal — N/A ✓ —
Automation Rules — — ✓ —
Detections & Threat Intel
Detections
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Rules — — ✓ ✓
Prevention Rules
Request WildFire Verdict Change
Assets
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Network Configuration — — ✓ —
Compliance — ✓ N/A —
Asset Inventory — — ✓ —
Displayed in the footer
Page 867 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
Asset Roles Configuration — — ✓ —
Endpoints
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Endpoint Administrations — — ✓ ✓
Endpoint Management
Retrieve Endpoint Data
Endpoint Scan
Change Managing Server
Pause Protection
Endpoint Token Management
Endpoint Groups — — ✓ —
Endpoint Prevention Policies — — ✓ —
Global Exceptions — — ✓ —
Endpoint Profiles — — ✓ —
Endpoint Extension Policies — — ✓ —
Endpoint Installations — — ✓ —
Host Firewall — — ✓ —
Displayed in the footer
Page 868 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
Device Control — — ✓ ✓
Device Control Rules
Device Control Exceptions
Configurations
General Settings
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Auditing — ✓ N/A —
Alert Notifications — — ✓ —
General Configuration — — ✓ —
Cortex XDR - Analytics
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
On-demand Analytics — — ✓ —
Data Broker
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Broker Services — — ✓ ✓
Pathfinder Applet
Pathfinder Data Collection — — ✓ —
Data Management
Displayed in the footer
Page 869 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Data Management — N/A ✓ —
Integrations
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Public API — — ✓ —
Threat Intelligence — — ✓ —
Long Running HTTP Integrations configuration — — ✓ —
Help
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Support — N/A ✓ —
18.1.2.4 | Investigation Admin
Abstract
Learn more about the Cortex XDR predefined user role called Investigation Admin.
The Investigation Admin role is used to view and triage alerts and incidents, configure rules, view endpoint profiles and policies, and Analytics management
screens.
Dashboards & Reports
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Dashboards — — ✓ —
Ingestion Monitoring ✓ — N/A —
Reports — — ✓ —
Incident Response
Incidents & Alerts
Displayed in the footer
Page 870 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Alerts & incidents — — ✓ —
Investigation
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Query Center — — ✓ —
Personal Query Library — — ✓ —
Forensics — — ✓ —
Host Insights — — ✓ —
Response
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Action Center — — ✓ ✓
Isolate
Terminate Process
Quarantine
File Retrieval
File Search
Displayed in the footer
Page 871 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
Destroy Files
Allow List/Block List
Disable Response Actions
Remediation
Delete Quarantined files
EDL — N/A ✓ —
Agent Scripts Library ✓ — — ✓
Run Standard Script
Run High-Risk Script
Script Configurations
Live Terminal ✓ N/A — —
Automation Rules ✓ — — —
Detections & Threat Intel
Detections
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Rules — — ✓ ✓
Displayed in the footer
Page 872 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
Prevention Rules
Request WildFire Verdict Change
Assets
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Network Configuration ✓ — — —
Compliance ✓ — N/A —
Asset Inventory ✓ — — —
Asset Roles Configuration ✓ — — —
Endpoints
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Endpoint Administrations ✓ — — ✓
Endpoint Management
Retrieve Endpoint Data
Endpoint Scan
Change Managing Server
Pause Protection
Displayed in the footer
Page 873 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
Endpoint Token Management
Endpoint Groups ✓ — — —
Endpoint Prevention Policies — ✓ — —
Global Exceptions ✓ — — —
Endpoint Profiles — ✓ — —
Endpoint Extension Policies — ✓ — —
Endpoint Installations ✓ — — —
Host Firewall — — ✓ —
Device Control — — ✓ ✓
Device Control Rules
Device Control Exceptions
Configurations
General Settings
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Auditing ✓ — N/A —
Alert Notifications ✓ — — —
General Configuration ✓ — — —
Cortex XDR - Analytics
Displayed in the footer
Page 874 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
On-demand Analytics ✓ — — —
Data Broker
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Broker Services ✓ — — ✓
Pathfinder Applet
Pathfinder Data Collection ✓ — — —
Data Management
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Data Management ✓ N/A — —
Integrations
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Public API ✓ — — —
Threat Intelligence ✓ — — —
Long Running HTTP Integrations configuration — — ✓ —
Help
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Displayed in the footer
Page 875 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
Support — N/A ✓ —
18.1.2.5 | Investigator
Abstract
Learn more about the Cortex XDR predefined user role called Investigator.
The Investigator role is used to view and triage alerts and incidents.
Dashboards & Reports
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Dashboards — — ✓ —
Ingestion Monitoring ✓ — N/A —
Reports — — ✓ —
Incident Response
Incidents & Alerts
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Alerts & incidents — — ✓ —
Investigation
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Query Center — — ✓ —
Personal Query Library — — ✓ —
Forensics — ✓ — —
Host Insights ✓ — — —
Response
Displayed in the footer
Page 876 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Action Center ✓ — — ✓
Isolate
Terminate Process
Quarantine
File Retrieval
File Search
Destroy Files
Allow List/Block List
Disable Response Actions
Remediation
Delete Quarantined files
EDL ✓ N/A — —
Agent Scripts Library ✓ — — ✓
Run Standard Script
Displayed in the footer
Page 877 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
Run High-Risk Script
Script Configurations
Live Terminal ✓ N/A — —
Automation Rules ✓ — — —
Detections & Threat Intel
Detections
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Rules ✓ — — ✓
Prevention Rules
Request WildFire Verdict Change
Assets
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Network Configuration — ✓ — —
Compliance — ✓ N/A —
Asset Inventory — ✓ — —
Asset Roles Configuration ✓ — — —
Endpoints
Displayed in the footer
Page 878 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Endpoint Administrations ✓ — — ✓
Endpoint Management
Retrieve Endpoint Data
Endpoint Scan
Change Managing Server
Pause Protection
Endpoint Token Management
Endpoint Groups ✓ — — —
Endpoint Prevention Policies ✓ — — —
Global Exceptions ✓ — — —
Endpoint Profiles ✓ — — —
Endpoint Extension Policies ✓ — — —
Endpoint Installations ✓ — — —
Host Firewall ✓ — — —
Device Control ✓ — — ✓
Device Control Rules
Displayed in the footer
Page 879 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
Device Control Exceptions
Configurations
General Settings
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Auditing ✓ — N/A —
Alert Notifications ✓ — — —
General Configuration ✓ — — —
Cortex XDR - Analytics
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
On-demand Analytics ✓ — — —
Data Broker
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Broker Services ✓ — — ✓
Pathfinder Applet
Pathfinder Data Collection ✓ — — —
Data Management
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Displayed in the footer
Page 880 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
Data Management ✓ N/A — —
Integrations
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Public API ✓ — — —
Threat Intelligence ✓ — — —
Long Running HTTP Integrations configuration ✓ — — —
Help
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Support — N/A ✓ —
18.1.2.6 | IT Admin
Abstract
Learn more about the Cortex XDR predefined user role called IT Admin.
The IT Admin role is used to manage and control endpoints and installations, configure Broker VMs, view endpoint profiles and policies, and view alerts.
Dashboards & Reports
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Dashboards — — ✓ —
Ingestion Monitoring — ✓ N/A —
Reports — — ✓ —
Incident Response
Incidents & Alerts
Displayed in the footer
Page 881 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Alerts & incidents — ✓ — —
Investigation
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Query Center — — ✓ —
Personal Query Library — ✓ — —
Forensics ✓ — — —
Host Insights — — ✓ —
Response
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Action Center — ✓ — ✓
Isolate
Terminate Process
Quarantine
File Retrieval
File Search
Displayed in the footer
Page 882 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
Destroy Files
Allow List/Block List
Disable Response Actions
Remediation
Delete Quarantined files
EDL ✓ N/A — —
Agent Scripts Library ✓ — — ✓
Run Standard Script
Run High-Risk Script
Script Configurations
Live Terminal ✓ N/A — —
Automation Rules ✓ — — —
Detections & Threat Intel
Detections
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Rules ✓ — — ✓
Displayed in the footer
Page 883 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
Prevention Rules
Request WildFire Verdict Change
Assets
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Network Configuration ✓ — — —
Compliance — ✓ N/A —
Asset Inventory — ✓ — —
Asset Roles Configuration ✓ — — —
Endpoints
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Endpoint Administrations — — ✓ ✓
Endpoint Management
Retrieve Endpoint Data
Endpoint Scan
Change Managing Server
Pause Protection
Displayed in the footer
Page 884 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
Endpoint Token Management
Endpoint Groups — — ✓ —
Endpoint Prevention Policies — ✓ — —
Global Exceptions — — ✓ —
Endpoint Profiles — ✓ — —
Endpoint Extension Policies — ✓ — —
Endpoint Installations — — ✓ —
Host Firewall — ✓ — —
Device Control — ✓ — ✓
Device Control Rules
Device Control Exceptions
Configurations
General Settings
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Auditing ✓ — N/A —
Alert Notifications ✓ — — —
General Configuration — — ✓ —
Cortex XDR - Analytics
Displayed in the footer
Page 885 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
On-demand Analytics ✓ — — —
Data Broker
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Broker Services — — ✓ ✓
Pathfinder Applet
Pathfinder Data Collection — — ✓ —
Data Management
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Data Management ✓ N/A — —
Integrations
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Public API ✓ — — —
Threat Intelligence ✓ — — —
Long Running HTTP Integrations configuration ✓ — — —
Help
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Displayed in the footer
Page 886 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
Support — N/A ✓ —
18.1.2.7 | Privileged Investigator
Abstract
Learn more about the Cortex XDR predefined user role called Privileged Investigator.
The Privileged Investigator role is used to view and triage alerts, incidents, and rules, view endpoint profiles and policies, and Analytics management screens.
Dashboards & Reports
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Dashboards — — ✓ —
Ingestion Monitoring ✓ — N/A —
Reports — — ✓ —
Incident Response
Incidents & Alerts
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Alerts & incidents — — ✓ —
Investigation
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Query Center — — ✓ —
Personal Query Library — — ✓ —
Forensics — — ✓ —
Host Insights — — ✓ —
Response
Displayed in the footer
Page 887 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Action Center — — ✓ ✓
Isolate
Terminate Process
Quarantine
File Retrieval
File Search
Destroy Files
Allow List/Block List
Disable Response Actions
Remediation
Delete Quarantined files
EDL — N/A ✓ —
Agent Scripts Library ✓ — — ✓
Run Standard Script
Displayed in the footer
Page 888 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
Run High-Risk Script
Script Configurations
Live Terminal ✓ N/A — —
Automation Rules ✓ — — —
Detections & Threat Intel
Detections
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Rules — ✓ — ✓
Prevention Rules
Request WildFire Verdict Change
Assets
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Network Configuration — — ✓ —
Compliance — ✓ N/A —
Asset Inventory — ✓ — —
Asset Roles Configuration ✓ — — —
Endpoints
Displayed in the footer
Page 889 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Endpoint Administrations ✓ — — ✓
Endpoint Management
Retrieve Endpoint Data
Endpoint Scan
Change Managing Server
Pause Protection
Endpoint Token Management
Endpoint Groups ✓ — — —
Endpoint Prevention Policies — ✓ — —
Global Exceptions ✓ — — —
Endpoint Profiles — ✓ — —
Endpoint Extension Policies — ✓ — —
Endpoint Installations ✓ — — —
Host Firewall — ✓ — —
Device Control — ✓ — ✓
Device Control Rules
Displayed in the footer
Page 890 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
Device Control Exceptions
Configurations
General Settings
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Auditing ✓ — N/A —
Alert Notifications ✓ — — —
General Configuration ✓ — — —
Cortex XDR - Analytics
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
On-demand Analytics ✓ — — —
Data Broker
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Broker Services ✓ — — ✓
Pathfinder Applet
Pathfinder Data Collection ✓ — — —
Data Management
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Displayed in the footer
Page 891 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
Data Management ✓ N/A — —
Integrations
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Public API ✓ — — —
Threat Intelligence ✓ — — —
Long Running HTTP Integrations configuration — — ✓ —
Help
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Support — N/A ✓ —
18.1.2.8 | Privileged IT Admin
Abstract
Learn more about the Cortex XDR predefined user role called Privileged IT Admin.
The Privileged IT Admin role is used to manage and control endpoints and installations, configure Broker VMs, create profiles and policies, view alerts, and
initiate Live Terminal.
Dashboards & Reports
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Dashboards — — ✓ —
Ingestion Monitoring — ✓ N/A —
Reports — — ✓ —
Incident Response
Incidents & Alerts
Displayed in the footer
Page 892 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Alerts & incidents — — ✓ —
Investigation
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Query Center — — ✓ —
Personal Query Library — — ✓ —
Forensics ✓ — — —
Host Insights — — ✓ —
Response
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Action Center — — ✓ ✓
Isolate
Terminate Process
Quarantine
File Retrieval
File Search
Displayed in the footer
Page 893 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
Destroy Files
Allow List/Block List
Disable Response Actions
Remediation
Delete Quarantined files
EDL ✓ N/A — —
Agent Scripts Library — — ✓ ✓
Run Standard Script
Run High-Risk Script
Script Configurations
Live Terminal — N/A ✓ —
Automation Rules ✓ — — —
Detections & Threat Intel
Detections
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Rules — — ✓ ✓
Displayed in the footer
Page 894 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
Prevention Rules
Request WildFire Verdict Change
Assets
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Network Configuration — — ✓ —
Compliance — ✓ N/A —
Asset Inventory — ✓ — —
Asset Roles Configuration ✓ — — —
Endpoints
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Endpoint Administrations — — ✓ ✓
Endpoint Management
Retrieve Endpoint Data
Endpoint Scan
Change Managing Server
Pause Protection
Displayed in the footer
Page 895 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
Endpoint Token Management
Endpoint Groups — — ✓ —
Endpoint Prevention Policies — ✓ — —
Global Exceptions — — ✓ —
Endpoint Profiles — ✓ — —
Endpoint Extension Policies — — ✓ —
Endpoint Installations — — ✓ —
Host Firewall — — ✓ —
Device Control — — ✓ ✓
Device Control Rules
Device Control Exceptions
Configurations
General Settings
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Auditing ✓ — N/A —
Alert Notifications ✓ — — —
General Configuration — — ✓ —
Cortex XDR - Analytics
Displayed in the footer
Page 896 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
On-demand Analytics ✓ — — —
Data Broker
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Broker Services — — ✓ ✓
Pathfinder Applet
Pathfinder Data Collection — — ✓ —
Data Management
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Data Management ✓ N/A — —
Integrations
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Public API ✓ — — —
Threat Intelligence ✓ — — —
Long Running HTTP Integrations configuration ✓ — — —
Help
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Displayed in the footer
Page 897 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
Support — N/A ✓ —
18.1.2.9 | Privileged Responder
Abstract
Learn more about the Cortex XDR predefined user role called Privileged Responder.
The Privileged Responder role is used toView and triage alerts and incidents, access all response capabilities, and configure rules, policies, and profiles.
Dashboards & Reports
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Dashboards — — ✓ —
Ingestion Monitoring ✓ — N/A —
Reports — — ✓ —
Incident Response
Incidents & Alerts
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Alerts & incidents — — ✓ —
Investigation
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Query Center — — ✓ —
Personal Query Library — ✓ — —
Forensics — — ✓ —
Host Insights — — ✓ —
Response
Displayed in the footer
Page 898 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Action Center — — ✓ ✓
Isolate
Terminate Process
Quarantine
File Retrieval
File Search
Destroy Files
Allow List/Block List
Disable Response Actions
Remediation
Delete Quarantined files
EDL — N/A ✓ —
Agent Scripts Library — — ✓ ✓
Run Standard Script
Displayed in the footer
Page 899 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
Run High-Risk Script
Script Configurations
Live Terminal — N/A ✓ —
Automation Rules ✓ — — —
Detections & Threat Intel
Detections
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Rules — — ✓ ✓
Prevention Rules
Request WildFire Verdict Change
Assets
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Network Configuration — — ✓ —
Compliance — ✓ N/A —
Asset Inventory — ✓ — —
Asset Roles Configuration ✓ — — —
Endpoints
Displayed in the footer
Page 900 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Endpoint Administrations — — ✓ ✓
Endpoint Management
Retrieve Endpoint Data
Endpoint Scan
Change Managing Server
Pause Protection
Endpoint Token Management
Endpoint Groups — ✓ — —
Endpoint Prevention Policies — ✓ — —
Global Exceptions ✓ — — —
Endpoint Profiles — ✓ — —
Endpoint Extension Policies — — ✓ —
Endpoint Installations ✓ — — —
Host Firewall — — ✓ —
Device Control — — ✓ ✓
Device Control Rules
Displayed in the footer
Page 901 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
Device Control Exceptions
Configurations
General Settings
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Auditing ✓ — N/A —
Alert Notifications ✓ — — —
General Configuration — — ✓ —
Cortex XDR - Analytics
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
On-demand Analytics ✓ — — —
Data Broker
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Broker Services ✓ — — ✓
Pathfinder Applet
Pathfinder Data Collection — — ✓ —
Data Management
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Displayed in the footer
Page 902 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
Data Management ✓ N/A — —
Integrations
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Public API ✓ — — —
Threat Intelligence ✓ — — —
Long Running HTTP Integrations configuration — — ✓ —
Help
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Support — N/A ✓ —
18.1.2.10 | Privileged Security Admin
Abstract
Learn more about the predefined user role called Privileged Security Admin.
The Privileged Security Admin role is used to triage and investigate alerts and incidents, and respond to and edit profiles and policies.
Dashboards & Reports
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Dashboards — — ✓ —
Ingestion Monitoring ✓ — N/A —
Reports — — ✓ —
Incident Response
Incidents & Alerts
Displayed in the footer
Page 903 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Alerts & incidents — — ✓ —
Investigation
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Query Center — — ✓ —
Personal Query Library — — ✓ —
Forensics ✓ — — —
Host Insights — — ✓ —
Response
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Action Center — — ✓ ✓
Isolate
Terminate Process
Quarantine
File Retrieval
File Search
Displayed in the footer
Page 904 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
Destroy Files
Allow List/Block List
Disable Response Actions
Remediation
Delete Quarantined files
EDL — N/A ✓ —
Agent Scripts Library — — ✓ ✓
Run Standard Script
Run High-Risk Script
Script Configurations
Live Terminal — N/A ✓ —
Automation Rules ✓ — — —
Detections & Threat Intel
Detections
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Rules — — ✓ ✓
Displayed in the footer
Page 905 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
Prevention Rules
Request WildFire Verdict Change
Assets
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Network Configuration — — ✓ —
Compliance — ✓ N/A —
Asset Inventory — ✓ ✓ —
Asset Roles Configuration V — ✓ —
Endpoints
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Endpoint Administrations — — ✓ ✓
Endpoint Management
Retrieve Endpoint Data
Endpoint Scan
Change Managing Server
Pause Protection
Displayed in the footer
Page 906 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
Endpoint Token Management
Endpoint Groups — ✓ — —
Endpoint Prevention Policies — — ✓ —
Global Exceptions — — ✓ —
Endpoint Profiles — — ✓ —
Endpoint Extension Policies — — ✓ —
Endpoint Installations — ✓ — —
Host Firewall — — ✓ —
Device Control — — ✓ ✓
Device Control Rules
Device Control Exceptions
Configurations
General Settings
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Auditing — ✓ N/A —
Alert Notifications — — ✓ —
General Configuration — — ✓ —
Cortex XDR - Analytics
Displayed in the footer
Page 907 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
On-demand Analytics — — ✓ —
Data Broker
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Broker Services — — ✓ ✓
Pathfinder Applet
Pathfinder Data Collection ✓ — — —
Data Management
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Data Management ✓ N/A — —
Integrations
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Public API ✓ — — —
Threat Intelligence — — ✓ —
Long Running HTTP Integrations configuration — — ✓ —
Help
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Displayed in the footer
Page 908 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
Support — N/A ✓ —
18.1.2.11 | Responder
Abstract
Learn more about the Cortex XDR predefined user role called Responder.
The Responder role is used to view and triage alerts, and access all response capabilities excluding Live Terminal.
Dashboards & Reports
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Dashboards — — ✓ —
Ingestion Monitoring ✓ — N/A —
Reports — — ✓ —
Incident Response
Incidents & Alerts
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Alerts & incidents — ✓ — —
Investigation
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Query Center — — ✓ —
Personal Query Library — ✓ — —
Forensics — ✓ — —
Host Insights ✓ — — —
Response
Displayed in the footer
Page 909 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Action Center — — ✓ ✓
Isolate
Terminate Process
Quarantine
File Retrieval
File Search
Destroy Files
Allow List/Block List
Disable Response Actions
Remediation
Delete Quarantined files
EDL — N/A ✓ —
Agent Scripts Library ✓ — — ✓
Run Standard Script
Displayed in the footer
Page 910 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
Run High-Risk Script
Script Configurations
Live Terminal ✓ N/A — —
Automation Rules ✓ — — —
Detections & Threat Intel
Detections
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Rules — — ✓ ✓
Prevention Rules
Request WildFire Verdict Change
Assets
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Network Configuration ✓ — — —
Compliance ✓ — N/A —
Asset Inventory ✓ — — —
Asset Roles Configuration ✓ — — —
Endpoints
Displayed in the footer
Page 911 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Endpoint Administrations ✓ — — ✓
Endpoint Management
Retrieve Endpoint Data
Endpoint Scan
Change Managing Server
Pause Protection
Endpoint Token Management
Endpoint Groups ✓ — — —
Endpoint Prevention Policies ✓ — — —
Global Exceptions ✓ — — —
Endpoint Profiles ✓ — — —
Endpoint Extension Policies ✓ — — —
Endpoint Installations ✓ — — —
Host Firewall ✓ — — —
Device Control ✓ — — ✓
Device Control Rules
Displayed in the footer
Page 912 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
Device Control Exceptions
Configurations
General Settings
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Auditing ✓ — N/A —
Alert Notifications ✓ — — —
General Configuration ✓ — — —
Cortex XDR - Analytics
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
On-demand Analytics ✓ — — —
Data Broker
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Broker Services ✓ — — ✓
Pathfinder Applet
Pathfinder Data Collection ✓ — — —
Data Management
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Displayed in the footer
Page 913 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
Data Management ✓ N/A — —
Integrations
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Public API ✓ — — —
Threat Intelligence ✓ — — —
Long Running HTTP Integrations configuration ✓ — — —
Help
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Support ✓ N/A — —
18.1.2.12 | Scoped Endpoint Admin
Abstract
Learn more about the Cortex XDR predefined user role called Scoped Endpoint Admin.
The Scoped Endpoint Admin role can only access product areas that support endpoint scoped-based access control (SBAC) - Endpoint Administration, Action
Center, Response, Dashboards, and Reports.
Dashboards & Reports
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Dashboards — — ✓ —
Ingestion Monitoring ✓ — N/A —
Reports — — ✓ —
Incident Response
Incidents & Alerts
Displayed in the footer
Page 914 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Alerts & incidents ✓ — — —
Investigation
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Query Center ✓ — — —
Personal Query Library ✓ — — —
Forensics ✓ — — —
Host Insights ✓ — — —
Response
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Action Center — — ✓ ✓
Isolate
Terminate Process
Quarantine
File Retrieval
File Search
Displayed in the footer
Page 915 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
Destroy Files
Allow List/Block List
Disable Response Actions
Remediation
Delete Quarantined files
EDL ✓ N/A — —
Agent Scripts Library — — ✓ ✓
Run Standard Script
Run High-Risk Script
Script Configurations
Live Terminal — N/A ✓ —
Automation Rules ✓ — — —
Detections & Threat Intel
Detections
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Rules ✓ — — ✓
Displayed in the footer
Page 916 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
Prevention Rules
Request WildFire Verdict Change
Assets
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Network Configuration ✓ — — —
Compliance ✓ — N/A —
Asset Inventory ✓ — — —
Asset Roles Configuration ✓ — — —
Endpoints
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Endpoint Administrations — — ✓ ✓
Endpoint Management
Retrieve Endpoint Data
Endpoint Scan
Change Managing Server
Pause Protection
Displayed in the footer
Page 917 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
Endpoint Token Management
Endpoint Groups ✓ — — —
Endpoint Prevention Policies ✓ — — —
Global Exceptions ✓ — — —
Endpoint Profiles ✓ — — —
Endpoint Extension Policies ✓ — — —
Endpoint Installations ✓ — — —
Host Firewall ✓ — — —
Device Control ✓ — — ✓
Device Control Rules
Device Control Exceptions
Configurations
General Settings
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Auditing ✓ — N/A —
Alert Notifications ✓ — — —
General Configuration ✓ — — —
Cortex XDR - Analytics
Displayed in the footer
Page 918 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
On-demand Analytics ✓ — — —
Data Broker
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Broker Services ✓ — — ✓
Pathfinder Applet
Pathfinder Data Collection ✓ — — —
Data Management
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Data Management ✓ N/A — —
Integrations
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Public API ✓ — — —
Threat Intelligence ✓ — — —
Long Running HTTP Integrations configuration ✓ — — —
Help
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Displayed in the footer
Page 919 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
Support — N/A ✓ —
18.1.2.13 | Security Admin
Abstract
Learn more about the Cortex XDR predefined user role called Security Admin.
The Security Admin role can triage and investigate alerts and incidents, respond (excluding Live Terminal), and edit profiles and policies.
Dashboards & Reports
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Dashboards — — ✓ —
Ingestion Monitoring ✓ — N/A —
Reports — — ✓ —
Incident Response
Incidents & Alerts
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Alerts & incidents — — ✓ —
Investigation
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Query Center — — ✓ —
Personal Query Library — — ✓ —
Forensics ✓ — — —
Host Insights — — ✓ —
Response
Displayed in the footer
Page 920 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Action Center — — ✓ ✓
Isolate
Terminate Process
Quarantine
File Retrieval
File Search
Destroy Files
Allow List/Block List
Disable Response Actions
Remediation
Delete Quarantined files
EDL — N/A ✓ —
Agent Scripts Library — ✓ — ✓
Run Standard Script
Displayed in the footer
Page 921 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
Run High-Risk Script
Script Configurations
Live Terminal ✓ N/A — —
Automation Rules ✓ — — —
Detections & Threat Intel
Detections
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Rules — — ✓ ✓
Prevention Rules
Request WildFire Verdict Change
Assets
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Network Configuration — — ✓ —
Compliance — ✓ N/A —
Asset Inventory — ✓ — —
Asset Roles Configuration ✓ — — —
Endpoints
Displayed in the footer
Page 922 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Endpoint Administrations — — ✓ ✓
Endpoint Management
Retrieve Endpoint Data
Endpoint Scan
Change Managing Server
Pause Protection
Endpoint Token Management
Endpoint Groups — ✓ — —
Endpoint Prevention Policies — — ✓ —
Global Exceptions — ✓ — —
Endpoint Profiles — — ✓ —
Endpoint Extension Policies — — ✓ —
Endpoint Installations — ✓ — —
Host Firewall — ✓ — —
Device Control — ✓ — ✓
Device Control Rules
Displayed in the footer
Page 923 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
Device Control Exceptions
Configurations
General Settings
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Auditing ✓ — N/A —
Alert Notifications ✓ — — —
General Configuration — — ✓ —
Cortex XDR - Analytics
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
On-demand Analytics ✓ — — —
Data Broker
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Broker Services ✓ — — ✓
Pathfinder Applet
Pathfinder Data Collection ✓ — — —
Data Management
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Displayed in the footer
Page 924 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
Data Management ✓ N/A — —
Integrations
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Public API ✓ — — —
Threat Intelligence ✓ — — —
Long Running HTTP Integrations configuration — — ✓ —
Help
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Support — N/A ✓ —
18.1.2.14 | Viewer
Abstract
Learn more about the Cortex XDR predefined user role called Viewer.
The Viewer role can view the majority of the features for this instance and edit reports.
Dashboards & Reports
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Dashboards — ✓ — —
Ingestion Monitoring ✓ — N/A —
Reports — ✓ — —
Incident Response
Incidents & Alerts
Displayed in the footer
Page 925 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Alerts & incidents — ✓ — —
Investigation
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Query Center — ✓ — —
Personal Query Library — ✓ — —
Forensics — ✓ — —
Host Insights — ✓ — —
Response
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Action Center — ✓ — ✓
Isolate
Terminate Process
Quarantine
File Retrieval
File Search
Displayed in the footer
Page 926 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
Destroy Files
Allow List/Block List
Disable Response Actions
Remediation
Delete Quarantined files
EDL ✓ N/A — —
Agent Scripts Library — ✓ — ✓
Run Standard Script
Run High-Risk Script
Script Configurations
Live Terminal ✓ N/A — —
Automation Rules ✓ — — —
Detections & Threat Intel
Detections
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Rules — ✓ — ✓
Displayed in the footer
Page 927 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
Prevention Rules
Request WildFire Verdict Change
Assets
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Network Configuration ✓ — — —
Compliance ✓ — N/A —
Asset Inventory — ✓ — —
Asset Roles Configuration ✓ — — —
Endpoints
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Endpoint Administrations — ✓ — ✓
Endpoint Management
Retrieve Endpoint Data
Endpoint Scan
Change Managing Server
Pause Protection
Displayed in the footer
Page 928 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
Endpoint Token Management
Endpoint Groups — ✓ — —
Endpoint Prevention Policies — ✓ — —
Global Exceptions — ✓ — —
Endpoint Profiles — ✓ — —
Endpoint Extension Policies — ✓ — —
Endpoint Installations — ✓ — —
Host Firewall — ✓ — —
Device Control — ✓ — ✓
Device Control Rules
Device Control Exceptions
Configurations
General Settings
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Auditing — ✓ N/A —
Alert Notifications ✓ — — —
General Configuration — ✓ — —
Cortex XDR - Analytics
Displayed in the footer
Page 929 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
On-demand Analytics ✓ — — —
Data Broker
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Broker Services ✓ — — ✓
Pathfinder Applet
Pathfinder Data Collection — ✓ — —
Data Management
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Data Management ✓ N/A — —
Integrations
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Public API ✓ — — —
Threat Intelligence ✓ — — —
Long Running HTTP Integrations configuration ✓ — — —
Help
Components Permissions Additional Action Permissions
None View View/Edit Edit/None
Displayed in the footer
Page 930 of 952
Cortex XDR Documentation
Displayed in the header
Components Permissions Additional Action Permissions
Support ✓ N/A — —
18.2 | Microsoft Windows security auditing setup
In Traps 6.1.3 and later releases, to enable Cortex XDR to collect Windows event logs, configure the following settings.
18.2.1 | Enable security auditing event IDs
You can enable security auditing events using GPO or set them up on a local server. Active Directory Certificate Services (ADCS) events require additional
setup.
We recommend you configure security auditing using Group Policy Object (GPO). Using GPO simplifies audit management and ensures that auditing settings
are uniformly applied across your network, reducing the risk of misconfigurations on individual machines.
18.2.1.1 | Enable security auditing event IDs with GPO
Use the Group Policy Management Editor to configure security auditing policies across domain controllers or other target machines.
We recommend that you configure the Group Policy Object (GPO) to apply to all endpoints and not just Domain Controllers. This ensures comprehensive
auditing across your entire network.
1. Log in to a Domain Controller (DC) as a domain admin.
2. Open the Group Policy Management Editor using one of the following methods:
Navigate to Server Manager → Tools → Group Policy Management.
On your keyboard, press Win + R, type GPMC.exe, and press Enter.
3. Create or select a GPO using one of the following methods:
Create a new GPO and link it to an Organizational Unit (OU) containing the computers where you want to apply the changes.
Use an existing GPO. For example, to apply changes to domain controllers, expand the Domain Controllers OU, right-click Default Domain
Controllers Policy, and select Edit.
4. In the Group Policy Management Editor, navigate to Computer Configuration → Policies → Windows Settings → Security Settings → Advanced Audit
Policy Configuration → Audit Policies.
Displayed in the footer
Page 931 of 952
Cortex XDR Documentation
Displayed in the header
5. In the Audit Policies settings, enable logging for both successful and failed attempts for the following events.
Event IDs Audit Policy Subcategory Additional Configuration Needed
4776, 4822, 4823 Account Logon Audit Credential Validation
4768, 4771, 4824 Account Logon Audit Kerberos Authentication Service DCs only
4769, 4770, 4821 Account Logon Audit Kerberos Service Ticket Operations DCs only
4741, 4742, 4743 Account Management Audit Computer Account Management DCs only
4727, 4728, 4729, Account Management Audit Security Group Management
4731, 4732, 4733,
4735, 4737, 4754,
4755, 4756, 4757,
4764, 4799
4720, 4722, 4723, Account Management Audit User Account Management
4724, 4725, 4726,
4738, 4740, 4765,
4766, 4767, 4780,
4781
4662 DS Access Audit Directory Service Access Additional setup for Active
Directory Certificate Services
(ADCS) events
DCs only
Displayed in the footer
Page 932 of 952
Cortex XDR Documentation
Displayed in the header
Event IDs Audit Policy Subcategory Additional Configuration Needed
4634, 4647 Logon/Logoff Audit Logoff
4624, 4625, 4648 Logon/Logoff Audit Logon
4649, 4778, 4800, Logon/Logoff Audit Other Logon/Logoff Events
4801, 4802, 4803
4672 Logon/Logoff Audit Special Logon
4880, 4881, 4885, Object Access Audit Certification Services Additional setup for Active
4886, 4887, 4888, Directory Certificate Services
4896, 4898, 4899, (ADCS) events
4900
5140 Object Access Audit File Share
4698, 4702 Object Access Audit Other Object Access Events
4713 Policy Change Audit Authentication Policy Change
4616 System Audit Security State Change
1102 System Other System Events Enabled by default
18.2.1.2 | Set up local machine security auditing without GPO
To enable collection of event logs on a local machine without GPO, use the following command in an administrator command prompt:
auditpol /set /subcategory:[subcategory] /success:enable /failure:enable
Replace [subcategory] with the subcategories in the following table.
Event IDs Audit Policy Subcategory Additional Configuration Needed
4776, 4822, 4823 Account Logon Audit Credential Validation
4768, 4771, 4824 Account Logon Audit Kerberos Authentication Service DCs only
4769, 4770, 4821 Account Logon Audit Kerberos Service Ticket Operations DCs only
4741, 4742, 4743 Account Management Audit Computer Account Management DCs only
4727, 4728, 4729, 4731, Account Management Audit Security Group Management
4732, 4733, 4735, 4737,
4754, 4755, 4756, 4757,
4764, 4799
Displayed in the footer
Page 933 of 952
Cortex XDR Documentation
Displayed in the header
Event IDs Audit Policy Subcategory Additional Configuration Needed
4720, 4722, 4723, 4724, Account Management Audit User Account Management
4725, 4726, 4738, 4740,
4765, 4766, 4767, 4780,
4781
4662 DS Access Audit Directory Service Access Additional setup for Active
Directory Certificate Services
(ADCS) events
DCs only
4634, 4647 Logon/Logoff Audit Logoff
4624, 4625, 4648 Logon/Logoff Audit Logon
4649, 4778, 4800, 4801, Logon/Logoff Audit Other Logon/Logoff Events
4802, 4803
4672 Logon/Logoff Audit Special Logon
4880, 4881, 4885, 4886, Object Access Audit Certification Services Additional setup for Active
4887, 4888, 4896, 4898, Directory Certificate Services
4899, 4900 (ADCS) events
5140 Object Access Audit File Share
4698, 4702 Object Access Audit Other Object Access Events
4713 Policy Change Audit Authentication Policy Change
4616 System Audit Security State Change
1102 System Other System Events Enabled by default
18.2.1.3 | Additional setup for Active Directory Certificate Services (ADCS) events
ADCS events with IDs 4880, 4881, 4886, 4887, 4896, 4898, 4899, 4900 require additional setup.
Enabling auditing for Active Directory Certificate Services (ADCS) restarts (events 4880 and 4881) can significantly slow down the service if you have a large
database. To prevent delays:
Clean up the database: Remove any unnecessary entries to reduce its size.
Skip this audit: If restart speed is critical, consider not enabling auditing for ADCS starts and stops (event IDs 4880 and 4881).
18.2.1.4 | Enable auditing access to AD domain objects - 4662
1. Log in to a Domain Controller as a domain admin.
2. In the Start menu, under Administrative Tools, open Active Directory Users and Computers.
Displayed in the footer
Page 934 of 952
Cortex XDR Documentation
Displayed in the header
3. In the left pane, locate the domain you want to audit. This will typically be the name of your network.
4. To see more details, in the View menu, select Advanced Features.
5. To view detailed information about your domain, right-click its name and select Properties.
6. Click the Security tab, usually located near the top of the Properties window.
7. Click Advanced which is located within the Security tab or near the bottom of the window.
Displayed in the footer
Page 935 of 952
Cortex XDR Documentation
Displayed in the header
8. In the Advanced Security Settings window that opens, select the Auditing tab and click Add.
9. Click Select a principal.
Displayed in the footer
Page 936 of 952
Cortex XDR Documentation
Displayed in the header
10. In the window that opens, under Enter the object name to select, type Everyone, click Check Names, and then OK.
11. In the Auditing Entry window, do the following:
Displayed in the footer
Page 937 of 952
Cortex XDR Documentation
Displayed in the header
Type: To track only successful attempts, select Success.
Applies to: To monitor actions by users within this group and any subgroups, select Descendant User objects.
Permissions: To remove any existing permissions from this audit entry, click Clear all.
Scroll up to Permissions to see view the list of permissions. Click the checkbox next to Full Control which automatically selects all the individual
permissions below it.
Uncheck the boxes next to the following:
List contents
Read all properties
Read permissions
Displayed in the footer
Page 938 of 952
Cortex XDR Documentation
Displayed in the header
Click OK to save the changes.
12. Repeat step 11, with the following values in Applies to:
Descendant Group Objects
Descendant Computer Objects
Descendant msDS-GroupManagedServiceAccount Objects
Descendant msDS-ManagedServiceAccount Objects
18.2.2 | Enable additional event logs using Event Viewer
For the following event IDs, the auditing setup is configured using the Windows Event Viewer. Access the Event Viewer through the search box in the Start
menu.
Event IDs 1511, 1518
In Event Viewer → Expand Applications and Services Logs → Microsoft → Windows → User Profile Service, right click Operational and select Enable Log.
Displayed in the footer
Page 939 of 952
Cortex XDR Documentation
Displayed in the header
Event IDs 11, 70, 90
In Event Viewer → Expand Applications and Services Logs → Microsoft → Windows → CAPI2, right click Operational and select Enable Log.
Displayed in the footer
Page 940 of 952
Cortex XDR Documentation
Displayed in the header
Event ID 3008
In Event Viewer → Expand Applications and Services Logs → Microsoft → Windows → DNS Client Events, right click Operational and select Enable Log.
Event ID 2004
In Event Viewer → Expand Applications and Services Logs → Microsoft → Windows → DriverFrameworks-UserMode, right click Operational and select Enable
Log.
Event IDs 4103, 4104, 4105, 4106
In Event Viewer → Expand Applications and Services Logs → Microsoft → Windows → PowerShell, right click Operational and select Enable Log.
Displayed in the footer
Page 941 of 952
Cortex XDR Documentation
Displayed in the header
Event IDs 1006, 1009, 1116, 1119
In Event Viewer → Expand Applications and Services Logs → Microsoft → Windows → Windows Defender, right click Operational and select Enable Log.
Event ID 1024
In Event viewer → Application and Services Logs → Microsoft → Windows → TerminalServices-ClientActiveXCore → Microsoft-Windows-TerminalServices-
RDPClient, right click Operational and select Enable Log.
Displayed in the footer
Page 942 of 952
Cortex XDR Documentation
Displayed in the header
Event IDs 2005, 2006, 2009, 2033
In Event Viewer → Expand Applications and Services Logs → Microsoft → Windows → Windows Firewall With Advanced Security → Firewall, right click
Operational and select Enable Log.
18.2.3 | Enable LDAP server events logging (1644)
You can enable LDAP server event logging using RegEdit or GPO.
18.2.3.1 | Enable LDAP server events logging using RegEdit
Make the following changes on all LDAP servers in the domain for which you want to configure auditing.
1. Log in as an administrator to a computer in the domain that you want to configure.
2. In the Start menu, type regedit to open the Registry Editor.
3. Add the following values on the Domain controller registry.
Displayed in the footer
Page 943 of 952
Cortex XDR Documentation
Displayed in the header
"15 Field Engineering"=dword:00000005
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters]
"Expensive Search Results Threshold"=dword:00000001
"Inefficient Search Results Threshold"=dword:00000001
"Search Time Threshold (msecs)"=dword:00000001
18.2.3.2 | Enable LDAP server events logging using GPO
1. On a domain controller or a system with Remote Server Administration Tools (RSAT) installed, open the Group Policy Management Console (GPMC).
2. Create a new Group Policy Object (GPO): Right-click on the domain or organizational unit (OU) where your domain controllers reside, then select Create
a GPO in this domain, and Link it here.... Give it a descriptive name, e.g. Domain Controller Registry Settings.
3. Edit the GPO.
1. Right-click on the newly created GPO and select Edit.
2. In the Group Policy Management Editor, navigate to Computer Configuration → Preferences → Windows Settings → Registry.
3. Add Registry Items: Right-click on Registry and select New → Registry Item.
Displayed in the footer
Page 944 of 952
Cortex XDR Documentation
Displayed in the header
4. Configure Registry Keys: For each of the registry keys you want to set, create a new Registry Item.
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics]
Create the following Registry item:
15 Field Engineering
Action: Update
Hive: HKEY_LOCAL_MACHINE
Key Path: SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics
Value name: 15 Field Engineering
Value type: REG_DWORD
Value data: 5
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters]
Create the following Registry items:
Expensive Search Results Threshold
Displayed in the footer
Page 945 of 952
Cortex XDR Documentation
Displayed in the header
Action: Update
Hive: HKEY_LOCAL_MACHINE
Key Path: SYSTEM\CurrentControlSet\Services\NTDS\Parameters
Value name: Expensive Search Results Threshold
Value type: REG_DWORD
Value data: 1
Inefficient Search Results Threshold
Action: Update
Hive: HKEY_LOCAL_MACHINE
Key Path: SYSTEM\CurrentControlSet\Services\NTDS\Parameters
Value name: Inefficient Search Results Threshold
Value type: REG_DWORD
Value data: 1
Search Time Threshold (msecs)
Displayed in the footer
Page 946 of 952
Cortex XDR Documentation
Displayed in the header
Action: Update
Hive: HKEY_LOCAL_MACHINE
Key Path: SYSTEM\CurrentControlSet\Services\NTDS\Parameters
Value name: Search Time Threshold (msecs)
Value type: REG_DWORD
Value data: 1
4. Close the Group Policy Management Editor.
5. To link the GPO to the OU where your domain controllers reside, in Group Policy Management, right-click the OU, select Link an Existing GPO, then
select the GPO you just created.
6. Force Group Policy Update: Force a Group Policy update using the gpupdate /force command on each domain controller or by restarting them.
18.2.3.3 | Validate log collection for LDAP Server events
View the LDAP Server Events logs.
1. From the Start menu, open Event Viewer.
2. Go to Application and Services Logs → Directory Service.
3. Filter for Event ID 1644.
Displayed in the footer
Page 947 of 952
Cortex XDR Documentation
Displayed in the header
19 | Glossary
This glossary includes information about key terms for Cortex products.
19.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.
19.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.
19.3 | 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.
19.4 | Attack Surface Management (ASM)
ASM provides embedded attack surface management (ASM) capabilities for an attacker’s view of your organization, with asset discovery, vulnerability
assessment, and risk management.
19.5 | Behavioral indicators of compromise (BIOCs)
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.
19.6 | Bring Your Own Machine Learning (BYOML)
Cortex XSIAM introduces Bring Your Own Machine Learning (BYOML) with Jupyter Notebooks, which unlocks the full potential of Cortex XSIAM as a primary
data platform.
19.7 | Broker Virtual Machine (Broker 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.
Displayed in the footer
Page 948 of 952
Cortex XDR Documentation
Displayed in the header
19.8 | Broker Virtual Machine Fully Qualified Domain Name (Broker VM 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.
19.9 | 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.
19.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.
19.11 | Cloud Detection and Response (CDR)
CDR analyzes cloud audit, flow, and container host logs together with data from other sources for holistic detection and response across your hybrid
enterprise.
19.12 | 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.
19.13 | Cortex Query Language (XQL)
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.
19.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.
19.15 | Elasticsearch Filebeat
See Filebeat.
19.16 | 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.
19.17 | 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.
Displayed in the footer
Page 949 of 952
Cortex XDR Documentation
Displayed in the header
19.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.
19.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.
19.20 | 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.
19.21 | 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.
19.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.
19.23 | Forensics
Allows you to perform forensic analysis easily by collecting all the artifacts you need and displaying them in an intuitive forensics console.
19.24 | 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).
19.25 | 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 with embedded XTH capabilities.
19.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.
19.27 | Indicators of compromise (IOCs)
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.
Displayed in the footer
Page 950 of 952
Cortex XDR Documentation
Displayed in the header
19.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.
19.29 | 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.
19.30 | Management, Reporting, and Compliance
Simplifies operations, centralizing all configuration, monitoring, and reporting functions, including endpoint policy management, orchestration, and response.
19.31 | 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.
19.32 | Next-Generation Firewall (NGFW)
You can forward firewall data from your NGFW and Panorama devices.
19.33 | 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.
19.34 | 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.
19.35 | 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.
19.36 | 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.
19.37 | 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.
Displayed in the footer
Page 951 of 952
Cortex XDR Documentation
Displayed in the header
19.38 | Security Information and Event Management (SIEM)
Delivers all common SIEM functions, including log management, correlation and alerting, reporting, and long-term data retention.
19.39 | 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.
19.40 | 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.
19.41 | Unified Extensible Firmware Interface Protection (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).
19.42 | 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.
19.43 | Virtual Machine
See Broker Virtual Machine.
19.44 | 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.
19.45 | Windows Event Collector (WEC)
The WEC runs on the Broker VM in Cortex XDR/Cortex XSIAM 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.
19.46 | XDR Collector (XDRC)
The XDRC is dedicated for on-premise data collection on Windows and Linux machines included with Cortex XDR/Cortex XSIAM. The XDR collector includes
a dedicated installer, a collector upgrade configuration, content updates, and policy management. The XDRC is a data collector that gathers and processes
logs and events from multiple sources. It leverages Elasticsearch Filebeat, a lightweight log shipper, to collect log data from various systems and applications.
Additionally, Winlogbeat gathers Windows event logs, ensuring comprehensive visibility into Windows environments. These components facilitate centralized
analysis, threat detection, and investigation across the Cortex XDR/Cortex XSIAM ecosystem. Note that the XDR Collector is distinct from the XDR agent.
19.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.
Displayed in the footer
Page 952 of 952
You might also like
- Kaspersky Security Center Hosted-EnglishNo ratings yetKaspersky Security Center Hosted-English580 pages
- Cisco SD-WAN Hands-On Training - LABs - 6.8-PrintNo ratings yetCisco SD-WAN Hands-On Training - LABs - 6.8-Print39 pages
- Nail Your Next Job Interview Leaked Python Interview Questions50% (2)Nail Your Next Job Interview Leaked Python Interview Questions14 pages
- Roadshow Advanced 7.2 V3.2 230711 Final All GeoNo ratings yetRoadshow Advanced 7.2 V3.2 230711 Final All Geo342 pages
- CIS Palo Alto Firewall 10 Benchmark v1.1.0No ratings yetCIS Palo Alto Firewall 10 Benchmark v1.1.0210 pages
- Cortex Data Lake: Getting Started GuideNo ratings yetCortex Data Lake: Getting Started Guide40 pages
- FortiGate, FortiSwitch, and FortiAP - LAN Edge Deployment GuideNo ratings yetFortiGate, FortiSwitch, and FortiAP - LAN Edge Deployment Guide31 pages
- CIS Cisco Firewall v8.x Benchmark v4.2.0 ARCHIVENo ratings yetCIS Cisco Firewall v8.x Benchmark v4.2.0 ARCHIVE173 pages
- Cisco Application Centric Infrastructure Dual-Fabric Design GuideNo ratings yetCisco Application Centric Infrastructure Dual-Fabric Design Guide132 pages
- PaltoAlto Cortex Guide Automating-Malware-Investigations 122123No ratings yetPaltoAlto Cortex Guide Automating-Malware-Investigations 12212310 pages
- Palo Alto Networks Certified Network Security Engineer (PCNSE) Exam BlueprintNo ratings yetPalo Alto Networks Certified Network Security Engineer (PCNSE) Exam Blueprint8 pages
- PIW Building A NetDevOps CI CD Pipeline Part IINo ratings yetPIW Building A NetDevOps CI CD Pipeline Part II16 pages
- PIW Using PyATS To Build A NetDevOps CI CD PipelineNo ratings yetPIW Using PyATS To Build A NetDevOps CI CD Pipeline59 pages
- AnsibleFest 2020 Automate Your Network Introducing The Modern Approach To Enterprise Network ManagementNo ratings yetAnsibleFest 2020 Automate Your Network Introducing The Modern Approach To Enterprise Network Management92 pages
- Cisco ASA and Firepower Threat Defense Reimage GuideNo ratings yetCisco ASA and Firepower Threat Defense Reimage Guide43 pages
- CP R80.40 CloudGuard Controller AdminGuideNo ratings yetCP R80.40 CloudGuard Controller AdminGuide47 pages
- Prisma Cloud Identity Based MicrosegmentationNo ratings yetPrisma Cloud Identity Based Microsegmentation5 pages
- Network Automation Using Ansible For Cisco Routers Basic ConfigurationNo ratings yetNetwork Automation Using Ansible For Cisco Routers Basic Configuration5 pages
- DeployingF5LoadBalancerswithCiscoISE Techalk Security Dec04 2014No ratings yetDeployingF5LoadBalancerswithCiscoISE Techalk Security Dec04 2014208 pages
- CCIE Enterprise Infrastructure (v1.0) Exam Topics - Practical ExamNo ratings yetCCIE Enterprise Infrastructure (v1.0) Exam Topics - Practical Exam8 pages
- Krishnagatha Malayalam PDF MinikeywordcomNo ratings yetKrishnagatha Malayalam PDF Minikeywordcom2 pages
- Implementing Cisco Application Centric Infrastructure - Advanced v1.0 (300-630)No ratings yetImplementing Cisco Application Centric Infrastructure - Advanced v1.0 (300-630)1 page
- 201-Essentials 1 - Firewall Installation Configuration and Management-5No ratings yet201-Essentials 1 - Firewall Installation Configuration and Management-51 page
- PeopleSoft HRMS Interview Questions, Answers, and Explanations0% (1)PeopleSoft HRMS Interview Questions, Answers, and Explanations6 pages
- Aws-12.12.2024 - Attack-16.1-Enterprise - Aws-12.12.2024 - Attack-16.1-EnterpriseNo ratings yetAws-12.12.2024 - Attack-16.1-Enterprise - Aws-12.12.2024 - Attack-16.1-Enterprise11 pages
- 18Y10-B-300 T1 18Y10-A-300 T1: Software Consultants (Pty) LTDNo ratings yet18Y10-B-300 T1 18Y10-A-300 T1: Software Consultants (Pty) LTD1 page
- VHDL Design of A RISC Processor: Control Unit: Functional DescriptionNo ratings yetVHDL Design of A RISC Processor: Control Unit: Functional Description3 pages
- Administrator (CCSA) R80 156-215-80 Check Point Certified SecurityNo ratings yetAdministrator (CCSA) R80 156-215-80 Check Point Certified Security13 pages
- Mis-0114 Ds Agile Studio 2.8 Release Notes v280 r0No ratings yetMis-0114 Ds Agile Studio 2.8 Release Notes v280 r06 pages
- Winapi - Drawing A Window With A Standard Frame and Transparent Contents - Stack OverflowNo ratings yetWinapi - Drawing A Window With A Standard Frame and Transparent Contents - Stack Overflow2 pages
- VESTA Pallas E9-1-1: Powerful Integrated Call-Handling Solution For Managing Critical ResponseNo ratings yetVESTA Pallas E9-1-1: Powerful Integrated Call-Handling Solution For Managing Critical Response4 pages
- Ultimate AWS Certified Solutions Architect Associate Exam Guide: Master Designing Resilient, Scalable Architectures with Core and Advanced AWS Services to Crack the SAA-C03 Certification (English Edition)From EverandUltimate AWS Certified Solutions Architect Associate Exam Guide: Master Designing Resilient, Scalable Architectures with Core and Advanced AWS Services to Crack the SAA-C03 Certification (English Edition)No ratings yet