Cortex XDR Pro Admin

Cortex® XDR Pro Administrator’s
Guide
3.3
docs.paloaltonetworks.com
Contact Informaon
Corporate Headquarters:
Palo Alto Networks
3000 Tannery Way
Santa Clara, CA 95054
www.paloaltonetworks.com/company/contact-support.html
About the Documentaon

• For the most recent version of this guide or for access to related documentaon, visit the
Technical Documentaon portal docs.paloaltonetworks.com.
• To search for a specific topic, go to our search page docs.paloaltonetworks.com/search.html.
• Have feedback or quesons for us? Leave a comment on any page in the portal, or write to us
at documentaon@paloaltonetworks.com.
Copyright
Palo Alto Networks, Inc.
www.paloaltonetworks.com
©2022 Palo Alto Networks, Inc. Palo Alto Networks is a registered trademark of Palo Alto
Networks. A list of our trademarks can be found at www.paloaltonetworks.com/company/
trademarks.html. All other marks menoned herein may be trademarks of their respecve
companies.
Last Revised
May 27, 2022
Cortex® XDR Pro Administrator’s Guide Version 3.3 2 ©2022 Palo Alto Networks, Inc.
Table of Contents
Cortex XDR Overview.................................................................................... 11
Cortex XDR Architecture........................................................................................................ 12
Cortex XDR Concepts.............................................................................................................. 14
XDR................................................................................................................................... 14
Sensors..............................................................................................................................14
Log Stching....................................................................................................................14
Causality Analysis Engine.............................................................................................15
Causality Chain...............................................................................................................15
Causality Group Owner (CGO)................................................................................... 15
Cortex XDR Licenses................................................................................................................16
Features by Cortex XDR License Type..................................................................... 16
Cortex XDR Endpoint Agent License Allocaon.................................................... 21
Cortex XDR License Expiraon..................................................................................22
Cortex XDR License Monitoring................................................................................ 22
Migrate Your Cortex XDR License.............................................................................23
Get Started with Cortex XDR Pro............................................................... 29

Setup Overview......................................................................................................................... 30
Plan Your Cortex XDR Deployment......................................................................................32
Deploy your Network Devices...............................................................................................34
Acvate Cortex XDR................................................................................................................ 35
Manage User Roles................................................................................................................... 37
Permission Management.............................................................................................. 37
Access Management..................................................................................................... 40
Predefined User Roles for Cortex XDR.................................................................... 48
Manage User Scope....................................................................................................118
Set Up Cloud Identy Engine.............................................................................................. 120
Manage Your Log Storage within Cortex XDR................................................................ 121
Set up Endpoint Protecon..................................................................................................123
Plan Your Agent Deployment...................................................................................124
Enable Access to Cortex XDR..................................................................................125
Proxy Communicaon................................................................................................ 135
Configure Your Network Devices....................................................................................... 137
Set up Network Analysis.......................................................................................................138
Configure Cortex XDR...........................................................................................................139
Integrate External Threat Intelligence Services....................................................140
Set up Your Cortex Environment.............................................................................141
Set up Outbound Integraon...............................................................................................145
Table of Contents
Use the Interface.................................................................................................................... 146

Manage Tables..............................................................................................................150
Endpoint Security.......................................................................................... 155

Endpoint Security Concepts.................................................................................................156
Cortex XDR versus Tradional Endpoint Protecon...........................................156
File Analysis and Protecon Flow........................................................................... 159
Endpoint Protecon Capabilies............................................................................. 163
Endpoint Protecon Modules...................................................................................167
Manage Cortex XDR Agents................................................................................................176
Create an Agent Installaon Package.....................................................................176
Set an Applicaon Proxy for Cortex XDR Agents............................................... 178
Move Cortex XDR Agents Between Managing XDR Servers........................... 179
Upgrade Cortex XDR Agents................................................................................... 181
Set aCortex XDR Agent Crical Environment Version....................................... 183
Delete Cortex XDR Agents.......................................................................................183
Uninstall the Cortex XDR Agent............................................................................. 184
Set an Alias for an Endpoint.....................................................................................185
Manage Endpoint Tags............................................................................................... 185
Manage Agent Tokens................................................................................................187
Define Endpoint Groups........................................................................................................189
About Content Updates........................................................................................................ 191
Endpoint Security Profiles.....................................................................................................193
Add a New Exploit Security Profile........................................................................ 194
Add a New Malware Security Profile..................................................................... 200
Add a New Restricons Security Profile................................................................210
Manage Endpoint Security Profiles......................................................................... 212
Customizable Agent Sengs............................................................................................... 214
Add a New Agent Sengs Profile.......................................................................... 217
Configure Global Agent Sengs............................................................................. 225
Endpoint Data Collected by Cortex XDREndpoint Data Collecon................ 228
Apply Security Profiles to Endpoints................................................................................. 239
Excepons Security Profiles................................................................................................. 241
Add a New Excepons Security Profile................................................................. 242
Add a Global Endpoint Policy Excepon............................................................... 244
Hardened Endpoint Security................................................................................................ 249
Device Control............................................................................................................. 251
Host Firewall.................................................................................................................259
Disk Encrypon............................................................................................................270
Host Inventory............................................................................................................. 276
Vulnerability Assessment...........................................................................................281
Table of Contents
Invesgaon and Response........................................................................ 287

Cortex XDR Rules................................................................................................................... 288
Working with BIOCs...................................................................................................288
Working with IOCs..................................................................................................... 298
Working with Correlaon Rules...............................................................................302
Manage Exisng Indicators....................................................................................... 313
Search Queries.........................................................................................................................317
Cortex XDR Query Builder....................................................................................... 317
Query Center................................................................................................................350
Quick Launcher............................................................................................................ 355
Scheduled Queries...................................................................................................... 356
Research a Known Threat......................................................................................... 358
Invesgate Incidents.............................................................................................................. 360
Incidents.........................................................................................................................360
External Integraons...................................................................................................363
Manage Incident Starring.......................................................................................... 365
Create an Incident Scoring Rule.............................................................................. 366
Triage Incidents............................................................................................................ 367
Manage Incidents........................................................................................................ 368
Invesgate Arfacts and Assets..........................................................................................379
Invesgate an IP Address..........................................................................................379
Invesgate an Asset....................................................................................................382
Invesgate a File and Process Hash....................................................................... 384
Invesgate a User........................................................................................................387
Invesgate Alerts.................................................................................................................... 390
Alerts...............................................................................................................................390
Triage Alerts.................................................................................................................. 401
Manage Alerts.............................................................................................................. 402
Alert Exclusions............................................................................................................408
Causality View..............................................................................................................410
Network Causality View............................................................................................ 412
Cloud Causality View................................................................................................. 415
Timeline View...............................................................................................................417
Analycs Alert View................................................................................................... 418
Invesgate Endpoints.............................................................................................................421
Acon Center............................................................................................................... 421
View Details About an Endpoint............................................................................. 425
Retrieve Files from an Endpoint.............................................................................. 432
Retrieve Support Logs from an Endpoint.............................................................. 433
Scan an Endpoint for Malware.................................................................................434
Table of Contents
Invesgate Files.......................................................................................................................436
Manage File Execuon...............................................................................................436
Manage Quaranned Files........................................................................................ 437
Review WildFire® Analysis Details......................................................................... 438
Import File Hash Excepons.....................................................................................440
Forensic Data Analysis...........................................................................................................441
Forensics Add-on Opons.........................................................................................446
Response Acons....................................................................................................................464
Iniate a Live Terminal Session................................................................................465
Isolate an Endpoint..................................................................................................... 470
Pause Endpoint Protecon........................................................................................472
Remediate Changes from Malicious Acvity........................................................ 473
Run Scripts on an Endpoint...................................................................................... 475
Search and Destroy Malicious Files........................................................................ 491
Manage External Dynamic Lists...............................................................................494
Broker VM....................................................................................................... 497

Broker VM Overview............................................................................................................. 498
Set up Broker VM...................................................................................................................501
Configure the Broker VM..........................................................................................501
Acvate the Local Agent Sengs........................................................................... 521
Acvate the Syslog Collector................................................................................... 524
Acvate the Apache Kaa Collector..................................................................... 527
Acvate the CSV Collector.......................................................................................531
Acvate the Database Collector..............................................................................533
Acvate the Files and Folders Collector................................................................536
Acvate the FTP Collector....................................................................................... 539
Acvate the NetFlow Collector............................................................................... 543
Acvate the Network Mapper................................................................................. 546
Acvate Pathfinder™................................................................................................. 547
Acvate the Windows Event Collector..................................................................552
Manage Your Broker VMs.....................................................................................................578
View Broker VM Details............................................................................................578
Edit Your Broker VM Configuraon........................................................................580
Collect Broker VM Logs.............................................................................................582
Reboot a Broker VM...................................................................................................582
Shut Down a Broker VM...........................................................................................583
Upgrade a Broker VM................................................................................................ 583
Open a Remote Terminal...........................................................................................583
Remove a Broker VM................................................................................................. 586
Broker VM Noficaons....................................................................................................... 587
Table of Contents
Cortex XDR Collectors................................................................................. 589

Collector Machine Requirements and Supported Operang Systems....................... 590
Resources Required to Enable Access to Cortex XDR Collectors............................... 593
Configure the Cortex XDR Collector Upgrade Scheduler............................................. 597
Manage XDR Collectors........................................................................................................ 598
Create a XDR Collector Installaon Package....................................................... 598
Install the XDR Collector Installaon Package for Windows............................ 600
Install the XDR Collector Installaon Package for Linux................................... 602
XDR Collectors Installaon Resource for Windows and Linux.........................605
Set an Applicaon Proxy for XDR Collectors....................................................... 606
Upgrade XDR Collectors............................................................................................607
Uninstall the XDR Collector..................................................................................... 608
Set an Alias for a Collector Machine......................................................................608
Define Collector Machine Groups...................................................................................... 610
About XDR Collector Content Updates............................................................................ 612
Add a XDR Collector Profile................................................................................................ 613
Ingest Logs from Windows DHCP using Elascsearch Filebeat.......................615
Apply Profiles to Collecon Machine Policies................................................................. 622
XDR Collector Datasets........................................................................................................ 624
External Data Ingeson............................................................................... 625

External Data Ingeson Vendor Support.......................................................................... 626
Visibility of Logs and Alerts from External Sources in Cortex XDR............................ 629
Ingest Network Connecon Logs....................................................................................... 643
Ingest Network Flow Logs from Amazon S3........................................................ 643
Ingest Logs from Check Point Firewalls.................................................................657
Ingest Logs from Cisco ASA Firewalls.................................................................... 658
Ingest Logs from Corelight Zeek..............................................................................659
Ingest Logs from Fornet Forgate Firewalls.......................................................660
Ingest Logs and Data from a GCP Pub/Sub..........................................................661
Ingest Logs from Microso Azure Event Hub...................................................... 669
Ingest Network Flow Logs from Microso Azure Network Watcher..............674
Ingest Logs and Data from Okta............................................................................. 677
Ingest Logs from Windows DHCP using Elascsearch Filebeat.......................679
Ingest Logs from Zscaler Cloud Firewall................................................................684
Ingest Authencaon Logs and Data................................................................................ 687
Ingest Audit Logs from AWS Cloud Trail...............................................................687
Ingest Logs and Data from Google Workspace....................................................709
Table of Contents
Ingest Logs from Microso Office 365..................................................................718

Ingest Authencaon Logs from PingFederate....................................................724
Ingest Authencaon Logs and Data from PingOne.......................................... 724
Ingest Operaon and System Logs from Cloud Providers............................................ 726
Ingest Alerts from Prisma Cloud..............................................................................726
Ingest Alerts from Prisma Cloud Compute........................................................... 727
Ingest Generic Logs from Amazon S3.................................................................... 729
Ingest Generic Logs from AWS CloudTrail and Amazon CloudWatch............ 737
Ingest Logs from Google Kubernetes Engine....................................................... 748
Ingest Cloud Assets................................................................................................................760
Ingest Cloud Assets from AWS............................................................................... 760
Ingest Cloud Assets from Google Cloud Plaorm...............................................772
Ingest Cloud Assets from Microso Azure........................................................... 783
Addional Log Ingeson Methods for Cortex XDR........................................................790
Ingest Logs from a Syslog Receiver.........................................................................790
Ingest Apache Kaa Events as Datasets.............................................................. 791
Ingest CSV Files as Datasets.................................................................................... 791
Ingest Database Data as Datasets.......................................................................... 792
Ingest Logs in a Network Share as Datasets........................................................ 792
Ingest FTP Files as Datasets.....................................................................................793
Ingest NetFlow Flow Records as Datasets............................................................793
Set up an HTTP Log Collector to Receive Logs................................................... 794
Ingest Logs from BeyondTrust Privilege Management Cloud........................... 795
Ingest Logs from Elascsearch Filebeat.................................................................796
Ingest Logs from Forcepoint DLP............................................................................798
Ingest Alerts and Assets from PAN IoT Security..................................................799
Ingest Logs from Proofpoint Targeted Aack Protecon.................................. 801
Ingest Data from ServiceNow CMDB.................................................................... 802
Ingest Report Data from Workday..........................................................................803
Ingest External Alerts.............................................................................................................809
Data Management......................................................................................... 811

Dataset Management.............................................................................................................812
Manage Datasets......................................................................................................... 814
Create Parsing Rules.............................................................................................................. 818
Parsing Rules Editor Views....................................................................................... 820
Parsing Rules File Structure and Syntax................................................................ 821
Table of Contents
Error Reporng in Parsing Rules..............................................................................831

Parsing Rules Raw Dataset....................................................................................... 833
Manage Event Forwarding....................................................................................................834
Endpoints Event Forwarding - Exported Event Types........................................ 834
Manage Compute Units Usage............................................................................................843
Analycs...........................................................................................................845
Analycs Concepts................................................................................................................. 846
Analycs Engine...........................................................................................................846
Analycs Sensors.........................................................................................................847
Coverage of MITRE Aack Taccs......................................................................... 849
Analycs Detecon Time Intervals.........................................................................851
Analycs Alerts and Analycs BIOCs.................................................................... 853
Identy Analycs.........................................................................................................853
Asset Management........................................................................................855
Network Configuraon..........................................................................................................856
Configure Your Network Parameters......................................................................856
Vulnerability Assessment...................................................................................................... 859
CVE Analysis.................................................................................................................860
Endpoint Analysis........................................................................................................ 861
Applicaon Analysis....................................................................................................862
Manage User Scores...............................................................................................................864
Asset Inventory........................................................................................................................866
All Assets....................................................................................................................... 869
Specific Assets..............................................................................................................871
Cloud Inventory Assets......................................................................................................... 874
All Cloud Assets...........................................................................................................874
Specific Cloud Assets................................................................................................. 877
Manage Your Cloud Inventory Assets.................................................................... 880
Monitoring....................................................................................................... 891
Cortex XDR Dashboard.........................................................................................................892
Dashboard Widgets.................................................................................................... 892
Manage Your Widget Library....................................................................................902
Predefined Dashboards.............................................................................................. 903
Build a Custom Dashboard....................................................................................... 909
Manage Dashboards................................................................................................... 910
Run or Schedule Reports...........................................................................................911
Monitor Cortex XDRXSIAM Incidents...............................................................................913
Monitor Cortex Gateway Management Acvity............................................................. 914
Monitor Administrave Acvity..........................................................................................915
Table of Contents
Monitor Agent Acvity..........................................................................................................918

Monitor Agent Operaonal Status..................................................................................... 921
Log Forwarding...............................................................................................923
Log Forwarding Data Types..................................................................................................924
Integrate Slack for Outbound Noficaons..................................................................... 925
Integrate a Syslog Receiver.................................................................................................. 926
Configure Noficaon Forwarding..................................................................................... 929
Cortex XDRXSIAM Log Noficaon Formats..................................................................931
Management Audit Log Messages.......................................................................... 931
Alert Noficaon Format.......................................................................................... 972
Agent Audit Log Noficaon Format..................................................................... 982
Management Audit Log Noficaon Format........................................................ 983
Cortex XDR Log Format for IOC and BIOC Alerts..............................................984
Cortex XDR Analycs Log Format.......................................................................... 994
Cortex XDR Log Formats........................................................................................ 1000
Managed Security....................................................................................... 1035

About Managed Security.................................................................................................... 1036
Cortex XDR Managed Security Access Requirements.................................................1037
Switch to a Different Tenant............................................................................................. 1038
Pivot to Another Tenant..........................................................................................1038
Pair a Parent Tenant with Child Tenant.......................................................................... 1039
Pairing a Parent and Child Tenant........................................................................ 1039
Unpairing a Parent and Child Tenant................................................................... 1040
Manage a Child Tenant....................................................................................................... 1041
Track your Tenant Management............................................................................1041
Invesgate Child Tenant Data................................................................................1042
Create and Allocate Configuraons..................................................................... 1044
Create a Security Managed Acon.......................................................................1044
About Managed Threat Hunng.......................................................................................1046
Set up Managed Threat Hunng...................................................................................... 1047
Invesgate Managed Threat Hunng Reports.............................................................. 1048
Cortex XDR Overview
The Cortex XDR app offers you complete visibility over network traffic, user behavior,
and endpoint acvity. It simplifies threat invesgaon by correlang logs from your
sensors to reveal threat causalies and melines. This enables you to easily idenfy
the root cause of every alert. The app also allows you to perform immediate response
acons. Finally, to stop future aacks, you can pro-acvely define Cortex XDR Rules
(BIOCs, IOCs, and Correlaon Rules) to detect and respond to malicious acvity.
> Cortex XDR Architecture

> Cortex XDR Concepts
> Cortex XDR Licenses
11
Cortex XDR Overview
Cortex XDR Architecture
Cortex® XDR consumes data from the Cortex® Data Layer to provide cloud-based storage within
the Cortex XDR tenant including all sources streamed into Cortex XDR— endpoints, firewalls,
cloud sources, and third-party data. Cortex XDR can correlate and stch together this data from
logs across your different log sensors to derive event causality and melines.
A Cortex XDR deployment which uses the full set of sensors can include the following
components.
• Cortex XDR—The Cortex XDR app provides complete visibility into all your data in the Cortex
Data Layer. The app provides a single interface from which you can invesgate and triage
alerts, take remediaon acons, and define policies to detect the malicious acvity in the
future.
• Cortex Data Layer—A data layer within your Cortex XDR tenant that stores the logs from
across all the data types.
• Cortex XDR Pro per TB:
• Analycs engine—The Cortex XDR analycs engine is a security service that ulizes
network data to automacally detect and report on post-intrusion threats. The analycs
engine does this by idenfying good (normal) behavior on your network, so that it can noce
bad (anomalous) behavior.
• Palo Alto Networks next-generaon firewalls—On-premises or virtual firewalls that enforce
network security policies in your campus, branch offices, and cloud data centers.
• Palo Alto Networks Prisma Access and GlobalProtect—If you extend your firewall security
policy to mobile users and remote networks using Prisma Access or GlobalProtect, you can
Cortex XDR Overview
also forward related traffic logs, including IoT logs, to Cortex Data Lake. The analycs engine
can then analyze those logs and raise alerts on anomalous behavior.
• External firewalls and alerts— Cortex XDR can ingest traffic logs from external firewall
vendors—such as Check Point—and use the analycs engine to analyze those logs and raise
alerts on anomalous behavior. For addional context in your incidents, you can also send
alerts from external alert sources.
• Cortex XDR Pro per Endpoint:
• Analycs engine—The Cortex XDR analycs can also consume endpoint data to
automacally detect and report on post-intrusion threats. The analycs engine can use
endpoint data to raise alerts for abnormal network behavior (for example port scan acvity).
• Cortex XDR agents—Protects your endpoints from known and unknown malware and
malicious behavior and techniques. Cortex XDR agents perform its own analysis locally on
the endpoint but also consumes WildFire threat intelligence. The Cortex XDR agent reports
all endpoint acvity to the Cortex Data Layer for analysis by Cortex XDR apps.
• External alert sources—To add addional context to your incidents, you can send Cortex
XDR alerts from external sources using the Cortex XDR API.
Cortex XDR Overview
Cortex XDR Concepts

• XDR
• Sensors
• Log Stching
• Causality Analysis Engine
• Causality Chain
• Causality Group Owner (CGO)
• Analycs Concepts
XDR
With Endpoint Detecon and Response (EDR), enterprises rely on endpoint data as a means
to trigger cybersecurity incidents. As cybercriminals and their taccs have become more
sophiscated, the me to idenfy and contain breaches has only increased. Extended Detecon
and Response (XDR) goes beyond the tradional EDR approach of using only endpoint data to
idenfy 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 aacks and
insider abuse and remediate compromised endpoints.
Sensors
Cortex XDR uses your exisng Palo Alto Networks products as sensors to collect logs and
telemetry data. The sensors that are available to you depend on your Cortex XDR license type.
With a Cortex XDR Pro per TB license, a sensor can be any of the following:
• Virtual (VM-Series) or physical firewalls—Idenfies known threats in your network and cloud
data center environments
• Prisma Access or GlobalProtect—Idenfies known threats in your mobile user and remote
network traffic
• External vendors—You can forward logs from supported vendors and addional vendors that
adhere to required formats.
With a Cortex XDR Pro per Endpoint license, a sensor can be any of the following:
• Cortex XDR agents—Idenfies threats on your Windows, Mac, Linux, and Android endpoints
and halts any malicious behavior or files
While more sensors increases the amount of data Cortex XDR can analyze, you only need to
deploy one type of sensor to begin detecng and stopping threats with Cortex XDR.
Log Stching
To provide a complete and comprehensive picture of the events and acvity surrounding an event,
Cortex XDR correlates together firewall network logs, endpoint raw data, and cloud data across
your detecon sensors. The act of correlang logs from different sources is referred to as log
Cortex XDR Overview
stching and helps you idenfy the source and desnaon of security processes and connecons
made over the network.
Log stching allows you to:
• Run invesgaon queries based on stched network and endpoint logs
• Create granular BIOC and Correlaon Rules over logs from Palo Alto Networks Next-
Generaon Firewalls and raw endpoint data
• Invesgate correlated network and endpoint events in the Network Causality View
Log stching streamlines detecon and reduces response me by eliminang the need for manual
analysis across different data sensors. Stching data across the firewalls and endpoints allows
you to obtain data form different sensors in a unified view, each sensor adding another layer
of visibility. For example, when a connecon is seen through the firewall and the endpoint, the
endpoint can provide informaon on the processes involved and on the chain of execuon while
the firewall can provide informaon on the amount of data transferred over the connecon and
the different app ids involved.
Causality Analysis Engine

The Causality Analysis Engine correlates acvity from all detecon sensors to establish causality
chains that idenfy the root cause of every alert. The Causality Analysis Engine also idenfies
a complete forensic meline of events that helps you to determine the scope and damage of
an aack, and provide immediate response. The Causality Analysis Engine determines the most
relevant arfacts in each alert and aggregates all alerts related to an event into an incident.
Causality Chain
When a malicious file, behavior, or technique is detected, Cortex XDR correlates available data
across your detecon sensors to display the sequence of acvity that led to the alert. This
sequence of events is called the causality chain. The causality chain is built from processes, events,
insights, and alerts associated with the acvity. During alert invesgaon you should review the
enre causality chain to fully understand why the alert occurred.
Causality Group Owner (CGO)

The Causality Group Owner (CGO) is the process in the causality chain that the Causality Analysis
Engine idenfied as being responsible for or causing the acvies that led to the alert.
Cortex XDR Overview
Cortex XDR Licenses

• Features by Cortex XDR License Type
• Cortex XDR Endpoint Agent License Allocaon
• Cortex XDR License Expiraon
• Cortex XDR License Monitoring
• Migrate Your Cortex XDR License
Features by Cortex XDR License Type

The following table describes the capabilies associated with each Cortex XDR license type. You
can use either Cortex XDR Prevent or a Cortex XDR Pro license. There are three types of Pro
licenses, Cortex XDR Pro per Endpoint, Cortex XDR Cloud per Host, and Cortex XDR Pro per
TB, that you can use independently or together for more complete coverage. If you do not know
which license type you have, see Cortex XDR License Monitoring.
The Cortex XDR Pro per TB license grants a monthly ingeson quota of 1 TB per month and no
more than 33GB per day. In addion, each license enables storing 1 TB of data for 30 days. For
more informaon, see Manage Your Log Storage within Cortex XDR.
Feature Cortex XDR Cortex XDR Pro Cortex XDR Cortex XDR Pro
Prevent per Endpoint Cloud per Host per TB
Log storage • Minimum • Minimum • Minimum of • Minimum

of 200 of 200 50 endpoints 5TB log
endpoints endpoints • 30 day log storage
• 30 day log • 30 day log retenon • 30 day log
retenon retenon retenon
Kubernetes Host — — —
Support
Cortex XDR Add-on Licenses

Add-on licenses are required on top of a Cortex XDR license
Cortex XDR Overview
Host Insights, — —
including:
Without the Without the
• Host add-on license, add-on license,
Inventory Host Insights is Host Insights is
available with available with
• Vulnerability
Cortex XDR Pro Cloud Host
Assessment
per Endpoint for Protecon for
• File Search a 1-month trial Cortex XDRfor
and Destroy period. a 1-month
trial period.
Forensics — —
Without the Without the
add-on license, add-on license,
Forensics is Forensics is
available with available with
Cortex XDR Pro Cloud Host
per Endpoint for Protecon for
a 1-month trial Cortex XDR
period. for a 1-month
trial period.
Compute Unit —
Without the Without the Without the
add-on license, add-on license, add-on license,
Compute unit Compute unit Compute unit
is available with is available with is available with
Cortex XDR Pro Cloud Host Cortex XDR
per Endpoint for Protecon for Pro per TBfor
a 1-month trial Cortex XDR for a 1-month trial
period. a 1-month trial period.
period.
Period Based —
Retenon (Hot
Storage)
Period Based —
Retenon (Cold
Storage)
GB Event — — —
Forwarding
Cortex XDR Overview
Endpoints Event — —
Forwarding
Endpoint Prevenon Features
Endpoint —
management
Device control —
Host firewall —
Disk encrypon —
Response Acons
Live Terminal —
Endpoint —
isolaon
External —
dynamic list
(EDL)
Script execuon — —
Remediaon — —
analysis
Incident Scoring —
Rules
Featured Alert —
Fields
Widget Library —
Assets
Asset —
Management
Palo Alto — — —
Networks IoT
Security
Cortex XDR Overview
Analysis
Analycs, —
including
Identy
Analycs
Alert and Log Collectors
Cortex XDR —
agent alerts
Prisma Cloud — — —
and Prisma
Cloud Compute
Palo Alto — — —
Networks IoT
Security
Third-Party — — —
Cloud Security
Data (AWS,
Azure, Google)
Enhanced data — —
collecon for
EDR and other
Pro features
Other alerts —
(from Palo Alto
(API)
Networks and
third-party
sources)
Other logs — — —
(from Palo Alto
Networks and
third-party
sources)
Integraons
Threat
intelligence
Cortex XDR Overview
(AutoFocus,
VirusTotal)
Outbound
integraon and
+ agent audit + agent audit
noficaon
logs logs
forwarding
(Slack, Syslog)
Broker VM
Agent Proxy
Syslog Collector — — —
Apache Kaa — — —
Collector
CSV Collector — — —
Database — — —
Collector
Files and Folders — — —

Collector
FTP Collector — — —
NetFlow — — —
Collector
Network —
Mapper
Pathfinder —
Windows Event — — —
Collector
MSSP
MSSP (requires
addional MSSP
license)
Managed — —
Threat Hunng
(requires an
Cortex XDR Overview
addional + a minimum of
Managed Threat 500 endpoints
Hunng License)
Cortex XDR Endpoint Agent License Allocaon

Cortex XDR regulates agent licenses according to the available license quota and revocaon
policy.
• Enforcement of Cortex XDR Pro Endpoint Licenses
• Enforcement of Cortex XDR Cloud per Host License
• License Revocaon
Enforcement of Cortex XDR Pro Endpoint Licenses

For the Cortex XDR Pro per Endpoint license, Cortex XDR limits the number of Pro agents and
associated Pro capabilies to the number of agents allocated by the license. Pro agent features
include:
• Enhanced Data Collecon on the endpoint
• Remediaon analysis
• Host Insights including Vulnerability Assessment, Host Inventory, and File Search and Destroy
You can further refine the endpoints on which you enable Pro features in your agent sengs
profiles.
Aer ulizing all available Pro licenses, Cortex XDR falls back to a Cortex XDR Prevent policy
that protects the endpoint but does not include Pro-specific capabilies. When you exceed the
permied number of Pro agents, Cortex XDR displays a noficaon in the noficaon area.
Cortex XDR permits a small grace over the permied number but begins enforcing the number
of agents aer 14 days. If addional Pro agents are required, increase your Cortex XDR Pro per
Endpoint license capacity.
To view the Pro license status for specific endpoints, see View Details About an Endpoint.
Enforcement of Cortex XDR Cloud per Host Licenses

For the Cortex XDR Cloud per Host license, Cortex XDR auto-idenfies if a host is running in a
public cloud and assigns the Cloud per Host license accordingly.
Endpoint License Revocaon

With Cortex XDR Prevent and Cortex XDR Pro per Endpoint licenses, Cortex XDR manages
licensing for all endpoints in your organizaon. Each me you install a new Cortex XDR agent on
an endpoint, the Cortex XDR agent registers with Cortex XDR to obtain a license. In the case of
non-persistent VDI, the Cortex XDR agent registers with Cortex XDR as soon as the user logs in
to the endpoint.
Cortex XDR issues licenses unl you exhaust the number of license seats available. Cortex XDR
also enforces a license cleanup policy to automacally return unused licenses to the pool of
Cortex XDR Overview
available licenses. The me at which a license returns to the license pool depends on the type of
endpoint:
Endpoint Type License Return Agent Removal from Agent Removal from
Cortex XDR console Cortex XDR Database
Standard and mobile Aer 30 days Aer 180 days Aer 180 days
devices
(Non-Persistent) Immediately aer log- Aer 6 hours Aer 7 days

VDI and Temporary off for VDI, otherwise
Session aer 90 minutes
Aer a license is revoked, if the agent connects to Cortex XDR, reconnecon will succeed as long
as the agent has not been deleted.
If a deleted agent tries to connect to Cortex XDR during the 180 days period, the agent can
resume connecon and maintain its agent ID. Aer the 180 days period, the agent ID is deleted
alongside all the associated data. In order to reconnect the agent, you must use Cytool to
reconnect it or reinstall it on the endpoint, and the agent will be assigned a new ID and a fresh
start.
It can take up to an hour for Cortex XDR to display revived endpoints.
Cortex XDR License Expiraon

Cortex XDR licenses are valid for the period of me associated with the license purchase. Aer
your Cortex XDR license expires, Cortex XDR allows access to your tenant for an addional grace
period of 48 hours. Aer the 48-hour grace period, Cortex XDR disables access to the Cortex
XDR app unl you renew the license.
For the first 30 days of your expired license, Cortex XDR connues to protect your endpoints and/
or network and retains data in the Cortex Data Layer according to your data retenon policy and
licensing. Aer 30 days, the tenant is decommissioned and agent prevenon capabilies cease.
Cortex XDR License Monitoring

From the Sengs > Cortex XDR License dialog, you can view the license types and add-ons
associated with your Cortex XDR instance.
The Cortex XDR License dialog is made of the following secons:

License and Endpoint Usage
• Hover over the informaon icon to view a list of all available licenses including the start and
expired dates.
Cortex XDR Overview
• For each license, Cortex XDR displays a le with the expiraon date of your license and
addional details specific to your license type:
• Cortex XDR Pro per Endpoint—Total number of installed agents in addion to the number
and percentage of agents with Pro features enabled.
• Cortex XDR Pro per TB—Amount of total storage included with your license.
• Cortex XDR Cloud per Host—Total number of hosts collecng cloud-based data.
• Combinaon of Cortex XDR Pro per Endpoint and Cortex XDR Pro per TB Cortex XDR Pro
per Endpoint—Total number of installed agents, while Cortex XDR Pro per TB displays how
many agents are enabled with endpoint data collecon, allowing them to collect and send
data to the server.
Addons
• Hover over the informaon icon to view a list of all available add-ons including the start and
expired dates.
• For each add-on associated to your Cortex XDR instance, Cortex XDR displays a le with
details specific to the add-on type.
For informaon on your data usage and storage license, select Sengs > Configuraons > Data
Management > Dataset Management. See Dataset Management.
To keep you informed of updates made to your license and avoid service disrupons, Cortex XDR
displays license noficaons when you log in. The noficaon idenfies any changes made to your
license and describes any required acons.
Cortex XDR also indicates when you have exceeded your Cortex XDR Pro per Endpoint license
capacity. To view the Pro license status for specific endpoints, see the View Details About an
Endpoint. For more informaon, see Enforcement of Cortex XDR Pro Endpoint Licenses.
Migrate Your Cortex XDR License

As part of the migraon of Cortex XDR 1.0 to Cortex XDR 2.0, a new Cortex XDR licensing
structure is in effect. The new licensing structure allows you to beer view and manage how your
network data and endpoints are best ulized across your organizaon.
Cortex XDR 1.0 license was based on the amount of terabyte (TB) used for either.
• 1TB = 200 Pro per Endpoints (with EDR Collecon)
Or
• 1TB = 1TB of network traffic analysis/third party data + 200 Prevent Endpoints (without EDR
collecon)
The Cortex XDR 2.0 license structure is based on three Licenses that you can purchase
individually or as a combinaon. The endpoint licenses provide the number of permied agents,
either Prevent or Pro. The TB license idenfies the amount of TB used for network traffic analysis
and collecng third-party data:
• Cortex XDR Prevent license—Number of Prevent Endpoints (without EDR collecon)
• Cortex XDR Pro per Endpoint license—Number of Pro Endpoints (with EDR collecon)
• Cortex XDR Pro per TB license—Amount of network data used for network traffic analysis and
third-party data.
Cortex XDR Overview
License Conversion Method and Example

Converng Cortex XDR 1.0 license to a Cortex XDR 2.0 license is calculated as follows:
License Type Calculaon
Endpoints • For each Cortex 1.0 license, 1 TB = 200 Pro per

Endpoints (with EDR collecon).
The number of endpoints is converted based on
the quota allocated in Hub > Cortex Data Lake >
Cortex XDR > Endpoint XDR Data, previously Traps >
Endpoint Data.
Network Data • For each Cortex XDR 1.0 license, 1 TB = 1 TB of

network data.
Since Cortex XDR 2.0 pro per TB license

no longer includes Prevent endpoints, the
license does not reflect them, however, you
can keep using them unl your renewal.
Aer migraon of Cortex XDR 2.0, when selecng Sengs > Cortex XDR License, the license
displays the converted amounts of network data or its equivalent number of endpoints allocated
to your license. The following table displays a conversion comparison between Cortex XDR 1.0
and 2.0 licenses.
License Version License Details
Cortex XDR 1.0 License • Cortex XDR 1.0 PAN-MGFR-XDR-1TB license - 100TB
• Hub > Cortex Data Lake > Traps > Endpoint Data -
10TB Endpoint Data.
Post Migraon Cortex XDR 2.0 • Up to 20,000 Pro per Endpoints

License
• Up to 100TB for network traffic analysis and third-
party data
Convert Your Cortex XDR License

When your Cortex XDR app is migrated to Cortex XDR 2.0, we recommend you convert
your Cortex XDR license to align with the new structure. To apply the new license structure,
determine how the amount of network data and number of endpoints are distributed across your
organizaon.
Aer you convert your legacy license to Cortex XDR 2.0 license structure, your new
network and endpoint allocaon are applied immediately. You can edit the allocaon at
any me, however, aer you convert to the new license structure you cannot revert to
your legacy license.
Cortex XDR Overview
STEP 1 | In Cortex XDR app, select Sengs > Cortex XDR License.
• (1) Network quota in TB and qualifying number of Pro per Endpoints

• (2,3) Number of agents installed and enabled to collect EDR data in your organizaon based
on the quota allocated in Hub > Cortex Data Lake > Cortex XDR > Endpoint XDR Data.
• (4) Current number of days Cortex XDR retains your data.
Cortex XDR Overview
STEP 2 | Convert your Cortex XDR 1.0 license to Cortex XDR 2.0 license.
1. Select Convert License.
2. Use the Network Allocaon slide bar to allocate your license between network and
endpoints (1 network TB = 200 endpoints).
If you allocate all of your license to network data then you disable endpoint
capabilies (and vice versa).
3. Apply your new license allocaons.
Cortex XDR Overview
STEP 3 | In your new Cortex XDR 2.0 license, review or Edit your license allocaon.
• Number of Cortex XDR agents
• Amount of network TB
• Number of installed endpoints and endpoints enabled with EDR Data collecon according
to the number of agents allocated to your license, rather than the Cortex Data Lake
distribuon.
• Number of days remaining for Cortex XDR to retain your data.
STEP 4 | Should you require addional TB or agent coverage, contact your Sales representave.
Cortex XDR Overview
Get Started with Cortex XDR Pro
> Setup Overview > Set up Endpoint Protecon
> Plan Your Cortex XDR Deployment > Configure Your Network Devices
> Deploy your Network Devices > Set up Network Analysis
> Acvate Cortex XDR > Configure Cortex XDR
> Manage User Roles > Set up Outbound Integraon
> Set Up Cloud Identy Engine > Use the Interface
> Manage Your Log Storage within
Cortex XDR
29
Setup Overview
Before you can use Cortex XDR for advanced detecon and response, you must acvate the
Cortex XDR app and set up related apps and services.
You must perform the setup acvies as shown in the following image. Some steps are required
only if you have the corresponding license type.
STEP 1 | Plan Your Cortex XDR Deployment.

As part of your planning, ensure that you or the person who is acvang Cortex apps has the
appropriate roles.
STEP 2 | (Cortex XDR Pro per TB license only) Deploy your Network Devices.
STEP 3 | (Oponal) Configure Cortex XDR to take firewall logs from an exisng Cortex Data Lake.
You can configure Cortex XDR to take logs from other Palo Alto Networks products already
logging to an exisng Cortex Data Lake. Otherwise, you will Acvate a new Data Lake as part
of the Cortex XDR tenant acvaon when seng up Cortex XDR in the Cortex Gateway.
STEP 4 | Set up Cortex XDR.

1. Acvate Cortex XDR.
2. Assign User Roles and Permissions.
3. Allocate Log Storage.
STEP 5 | (Oponal) Set Up Cloud Identy Engine (Formally Directory Sync Services (DSS))
1. Acvate and Set Up a Cloud Identy Engine Instance.
2. Add the Cloud Identy Engine Instance to Cortex XDR.
STEP 6 | (Cortex XDR Pro per Endpoint only) Set up Endpoint Protecon.
1. Plan your Cortex XDR agent deployment.
2. Create Cortex XDR agent installaon packages.
3. Define endpoint groups.
4. Deploy the Cortex XDR agent to your endpoints.
5. Configure your endpoint security policy.
STEP 7 | (Cortex XDR Pro per TB license only) Configure your Network Devices.
STEP 8 | (Cortex XDR Pro per TB license only) Set up Network Analysis.
1. Perform any remaining setup of your network sensors.
2. Configure the internal networks that you want Cortex XDR to monitor.
3. Verify that Cortex XDR is receiving alerts.
4. If you set up a Directory Sync Service instance, enable Cortex XDR to use it.
STEP 9 | Configure Cortex XDR.

1. (Oponal) Integrate addional threat intelligence.
2. Aer 24 hours, enable Cortex XDR Analycs Analysis.
1. Configure Network Coverage.
2. (Recommended) Acvate Pathfinder to interrogate endpoints that do not have the
Cortex XDR agent installed.
3. Define alert exclusions
4. Priorize incidents based on aributes by creang an incident starring policy.
5. Import or configure rules for known BIOC and IOCs, and create any applicable
Correlaon Rules.
6. (Oponal) Manage External Dynamic Lists- Requires a Cortex XDR Pro per TB license.
STEP 10 | (Oponal) Set up Outbound Integraon.

• Integrate with Slack.
• Integrate with a Syslog Server.
• Integrate with Cortex XSOAR.
STEP 11 | (Oponal) Set up Managed Security.
STEP 12 | Use the Cortex XDR Interface.
Plan Your Cortex XDR Deployment

Before you get started with Cortex XDR, plan your deployment.
Deployment Type Deployment Consideraons
New Cortex XDR tenants Determine the amount of log storage you need
for your Cortex XDR deployment. Talk to your
Partner or Sales Representave to determine
whether you must purchase addional storage
within the Cortex XDR tenant.
Determine the region in which you want to host
Cortex XDR and any associated services, such as
Directory Sync Service.
If you plan to stream data from a

Cortex Data Lake instance, it must be
in the same region as Cortex XDR.
• US—All Cortex XDR logs and data remain

within the US boundary.
• UK—All Cortex XDR logs and data remain
within the UK boundary.
• EU—All Cortex XDR logs and data remain
within the Europe boundary.
• SG—All Cortex XDR logs and data remain
within the Singapore boundary.
• JP—All Cortex XDR logs and data remain
within the Japan boundary.
• CA—All Cortex XDR logs and data remain
within the Canada boundary. However, if you
have a WildFire Canada cloud subscripon,
consider the following:
• You can not send file submissions for bare-
metal analysis.
• You will not be protected against macOS-
borne zero-day threats. However, you will
Deployment Type Deployment Consideraons

receive protecons against other macOS
malware in regular WildFire updates.
• You will not be able to see file submissions
in AutoFocus™.
• AU—All Cortex XDR logs and data remain
within the Australia boundary.
• IN—All Cortex XDR logs and data remain
within the India boundary. However, if you
have a WildFire India cloud subscripon,
consider the following:
• When the Cortex XDR agent idenfies
unknown files, Cortex XDR sends the
files to the WildFire Singapore Cloud for
analysis. Starng October 2021 Cortex
XDR will integrate with WildFire located in
India to allow you to keep all Cortex XDR
Agent WildFire traffic within the Indian
boundary.
Aer the migraon, WildFire India

portal will not display informaon
for past events that occurred
prior to the transion to the new
India cloud locaon, however,
you will sll have access to the
WildFire Singapore portal to
view the history. In addion,
all informaon regarding the
calculated verdicts, such as the
WildFire verdict and WildFire
report, will be available in the
Cortex XDR portal.
(Cortex XDR Pro per Endpoint license only)
Calculate the bandwidth required to support the
number of agents you plan to deploy. You need
1.2Mbps of bandwidth for every 1,000 agents.
The bandwidth requirement scales linearly so, for
example, to support 100,000 agents, you need to
allocate 120Mbps of bandwidth.
When you are ready to get started with a new
tenant, Acvate Cortex XDR.
Cortex XDR Public Key Download Cortex XDR Public Key
Deploy your Network Devices

With a Cortex XDRPro per TB license, if you use Palo Alto Networks firewalls as a traffic log
source, you must acvate your firewalls and Panorama and configure them for log forwarding to
Cortex Data Lake.
STEP 1 | Register and acvate your firewalls and Panorama.
STEP 2 | Upgrade firewalls and Panorama to the latest soware and content releases.
PAN-OS 8.0.6 is the minimum required soware release version for Palo Alto Networks
firewalls and Panorama. However, to enable Cortex XDR to leverage the Directory Sync Service
and Enhanced Applicaon Logs, upgrade firewalls and Panorama to PAN-OS 8.1.1 or later and
to the latest content release:
Get the latest applicaon and threat content updates.
Upgrade to PAN-OS 8.1.1.
STEP 3 | Ensure that firewalls have visibility into internal traffic and applicaons.
It’s important that at least one firewall sending logs to the Cortex Data Lake is processing or
has visibility into internal traffic and applicaons.
If you have deployed only internet gateway firewalls, one opon might be to configure a tap
interface to give a firewall visibility into data center traffic even though the firewall is not in the
traffic flow. Connect the tap mode interface to a data center switch SPAN or mirror port that
provides the firewall with the mirrored traffic, and make sure that the firewall is enabled to log
the traffic and send it to the Cortex Data Lake.
Because data center firewalls already have visibility into internal network traffic, you
don’t need to configure these firewalls in tap mode; however, contact Palo Alto Networks
Professional Services for best pracces to ensure that the Cortex Data Lake and Cortex XDR-
required configuraon updates do not affect data center firewall deployments.
Acvate Cortex XDR

To acvate and manage user permissions of your Cortex XDR tenants, Cortex XDR operates as a
standalone applicaon known as the Cortex Gateway.
The Cortex Gateway allows you to:
• Acvate new tenants.
• View and manage exisng tenants and tenants available for acvaon that are allocated to
your Customer Support Portal (CSP) account.
• View and manage granular role-based access control (RBAC) sengs.
The sizing calculator is managed on the hub.
Acvang a Cortex XDR tenant is a one-me task you’ll need to perform when you first start
using Cortex XDR. Aer you’ve acvated your Cortex XDR tenant—and completed all the
steps described in Setup Overview—you’ll only need to repeat the acvaon if you want to add
addional Cortex XDR tenants.
The following are prerequisites to acvate Cortex XDR:
• Locate the email that contains your acvaon informaon.
• Ensure you have CSP Super User role permissions to your exisng administrator accounts. This
role cannot be removed or changed through the Cortex Gateway.
To acvate your Cortex XDR tenant:
STEP 1 | Navigate to the acvaon link you received in email and sign in to begin acvaon in the
Cortex Gateway.
As a first user with CSP Super User permissions to access the Cortex Gateway, you are
automacally granted XDR Account Admin permissions to the Cortex Gateway. With
these permissions, you are able to acvate Cortex XDR tenants, create new roles, and
assign permissions to users allocated to your tenant.
The Cortex Gateway displays tenants Available for Acvaon and Available Tenants.
In the Available for Acvaon secon, you can view all the tenants allocated to your CSP
account that are ready for acvaon. You can review the tenant details, such as license type,
number of endpoints, and purchase date.
The Available Tenants secon lists tenants that have already been acvated. If you have more
than one CSP account, the tenants are displayed according the CSP account name.
STEP 2 | In the Available for Acvaon secon, locate the tenant you want to acvate according to
the serial number and Acvate to launch the Tenant Acvaon wizard.
STEP 3 | In Tenant Acvaon > Select Support Account, ensure the tenant you want to acvate is
allocated to the correct CSP account. You can expand Cortex XDR and Cortex Data Lake to
view the tenants and Cortex Data Lake instances associated within the CSP account.
If you manage mulple company CSP accounts, make sure you select the specific
account to which you want to allocate the Cortex XDR tenant before proceeding with
acvaon. Once acvated, the tenant will be associated with the account and cannot
be moved.
STEP 4 | In Tenant Acvaon > Define Tenant Sengs, define the following tenant details:
• Tenant Name—Give your Cortex XDR app instance an easily-recognizable name. Choose a
name that is 59 or fewer characters and is unique across your company account.
• Region—Select a region in which you want to set up your Cortex Data Lake instance. If
you selected an exisng Cortex Data Lake instance, this field automacally displays the
region in which your Cortex Data Lake instance is deployed and cannot be changed.
• Tenant Subdomain—Give your Cortex XDR instance an easy to recognize
name that is used to access the tenant directly using the full URL (https://
<subdomain>.xdr.<region>.paloaltonetworks.com).
Note this is a public FQDN, so be careful with sensive informaon such as the
company name.
• Cortex Data Lake—You can either Acvate new Data Lake or select the Cortex Data Lake
instance name you created that is already logging Palo Alto Networks products.
• Review and agree to the terms and condions of the Privacy policy, Term of Use, EULA.
STEP 5 | Acvate your tenant.

Acvaon can take up to an hour. Cortex XDR sends a noficaon to your email when the
tenant has completed the acvaon process.
STEP 6 | Select Back to main gateway and in the Available Tenant secon, search for your tenant
name. Hover over a tenant to display the Tenant Status and License Details. When the
tenant displays an Acve status, select the tenant name to confirm you can successfully
access the Cortex XDR management console.
You can change your tenant subdomain from oldName.xdr.us.paloaltonetworks.com to

newName.xdr.us.paloaltonetworks.com anyme you want, if you have Account Admin
or Instance Admin permissions. To change your tenant subdomain name, please open a
Palo Alto Networks support cket.
STEP 7 | Connue to assign user roles and permissions.
Manage User Roles

Role-based access control (RBAC) enables you to manage roles or specific permissions, and assign
access rights to administrave users in the following areas in Cortex XDR, where the role opons
to configure change slightly depending on where you access these RBAC sengs.
• Cortex Gateway—Select Tenant Navigator > Cortex Gateway > Permission Management
where you can define Permission Management for one or more tenants by selecng the
Permissions and Roles subcategories.
• Cortex XDR Access Management—Select Sengs > Configuraons > Access Management
where you can define Access Management for a specific tenant by selecng the Users, Roles,
and User Groups subcategories. In addion, you can also set manage user access permissions
for the various XQL datasets as part of managing roles.
You can manage roles for all Cortex XDR apps and services. By assigning roles, you enforce the
separaon of viewing access and iniang acons among funconal or regional areas of your
organizaon. Cortex XDR provides a number of predefined Palo Alto Networks roles to assign
access rights to Cortex XDR users. For more informaon, see Predefined User Roles for Cortex
XDR.
Permission Management
You can manage roles and permissions for a single tenant or a number of tenants at the same
me using the Cortex XDR Permission Management console, which is accessible via the Cortex
Gateway. The Permission Management console is used for first me acvaons. To create and
assign roles, you must first acvate your Cortex XDR tenant and be assigned a XDR Account Admin
role in the Cortex Gateway.
The Permission Management console is divided into two subcategories, Permissions and Roles,
which you can view on separate pages.
In the Permissions page, Cortex XDR lists all the users allocated to a specific Customer Support
Portal (CSP) account and tenant name. If a user is not listed, ensure that the user is added in
the Customer Support Portal. The Permissions table provides different fields of informaon as
detailed below. You can select whether to Show User Subset to display only the users who are not
designated as a Hidden user (default). For example, this is useful when you have users, who are
not related to Cortex XDR and will not be designated with a Cortex XDR role, such as CSP Super
Users, and you want to hide them from the list. You can also select whether to View By Users
(default) or Tenants.
Groups and Group Roles can only be configured in Cortex XDR in the Sengs >
Configuraons > Access Management > User Groups page. For more informaon, see
Manage User Groups.
• User Name—Displays the first and last name of the user and whether the user is a CSP Super
User and Account Admin. If the user is allocated to more than one tenant, expand the user name
to display the details for each tenant.
• Email—Email address of the user.
• Tenant—Name of the tenant the user has permission to access. Next to the user name, expand
( ) to view the tenant name.
• Direct XDR Role—Name of the role assigned to the user. Next to the user name, expand ( ) to
view the role assigned per tenant, if the user does not have any Cortex XDR access permission,
the field displays No-Role.
• Groups—Lists the groups that a user belongs to, where any group imported from Acve
Directory has the leers AD added beside the group name.
• Group Roles—Lists the different group roles based on the groups the user belongs to. When
you hover over the group role, the group associated with this role is displayed.
• Last Login Time—Last date and me the user accessed the tenant.
• Status—Displays whether the user is Acve or Inacve.
In the Roles page, Cortex XDR lists the Predefined User Roles for Cortex XDR and custom
defined roles. Use roles to assign specific view and acon access privileges to administrave user
accounts. The way you configure administrave access depends on the security requirements of
your organizaon. The built-in roles provide specific access rights that cannot be changed. The
roles you create provide more granular access control.
The Roles table provides the following fields of informaon.
• Role Name—Name of the role.
• Created By—Displays one of the following opons depending on whether the role is a custom
role created by a user or a predefined role.
• Palo Alto Networks—Predefined role granng user permissions in all tenants.
• <user email address> —Custom role created in the Cortex Gateway granng user
permission in all tenants.
• <user email address> —Custom role created in the Cortex XDR app granng user
permission that specific tenant alone.
• Tenant—Name of the tenant the role applies to according to where the role was created;
Cortex Gateway or Cortex XDR app.
• Descripon—Descripon of the role.
• Creaon Time—Date and me when the role was created. The field is available for only a
custom role.
• Modificaon Time—Date and me of when the role was last updated. The field is available for
only a custom role.
STEP 1 | Select Tenant Navigator > Cortex Gateway > Permission Management.
STEP 2 | Manage your Cortex XDR roles and permissions.

If you are managing more than one CSP account, select the account you want to display the
available roles. If you only manage one CSP account, Cortex XDR only displays the roles
available on your tenant.
In the Roles table, the following opons are available to help you manage roles.
• Create a custom role based on Cortex XDR Predefined roles.
1. Locate the predefined role that you want to base your custom role on, right-click and
select Save As New Role.
2. In the Create Role window, specify a Role Name and update the Descripon.
3. Update the Views and Acons permissions you want the role to include and Create the
role.
• Create and save new roles based on the granular permission.
1. Select New Role.
2. In the Create Role window, specify a Role Name and Descripon.
3. Select the Views and Acons permissions you want the role to include and Create the
role.
• Edit role permissions (only available for roles you create).
1. Locate the custom role you want to edit, right-click and select Edit Role.
2. In the Edit Role window, update the Views and Acons permissions you want the role to
include and Edit the role.
STEP 3 | Assign roles to a Cortex XDR user.

In the Permissions page, select the Account Name. The following opons are available to help
you manage permissions. You can assign roles to one or more users at a me.
• Assign permissions to a user that does not have a role.
1. Hover over the user name and select , located to the right of the row, to Add
Permissions.
2. In the Add Permissions window, select from the list of Available Tenants for which you
want to grant permissions.
3. Select a role from either the Default Roles or Custom Roles you want to assign the user
and Add the role to the user.
• Update permission for users with an exing role.
1. Hover over the user name and select , located to the right of the row, to Update
Permissions.
2. In the Update Permissions window, select a role from either the Default Roles or Custom
Roles you want to assign the user and Update the role.
• Deacvate a user.
Locate the user you want to deacvate, right-click, and select Deacvate User.
You cannot deacvate a user that has an Account Admin role.
• Designate a user as hidden.

Locate the user you want to hide, right-click, and select Hide User. When a user is
designated as hidden, the user will no longer be displayed in the Permissions table when the
table is configured to Show User Subset (default configuraon).
• Manage User Scope
Assign users to specific endpoint groups in your organizaon.
Access Management
The Access Management console is accessible by selecng Sengs > Configuraons > Access
Management. The console is divided into the following subcategories, which you can view on
separate pages.
• Users—Manage users allocated to a specific tenant.
• Roles—Manage roles for a specific tenant.
• User Groups—Manage your user groups for a specific tenant.
Manage Users
In the Users page, Cortex XDR lists all the users allocated to a specific Customer Support Portal
(CSP) account and tenant. If a user is not listed, ensure that the user is added in the Customer
Support Portal. The Users table provides different fields of informaon as detailed below. At the
top of the page, you can perform the following acons.
• Import Mulple User Roles as a CSV (Comma-separated values) file. This import can be used
to quickly add users who already belong to a CSP account and assign them preexisng roles
in Cortex XDR. You can use the Download example file to view the required format of the
CSV file to upload and replace the file contents with the data you want to upload, where the
following columns must be included.
• User email—The email address of the user belonging to a CSP account that you want to
import.
• Role Name—The name of the role that you want to assign to this user, where the role must
already be created in Cortex XDR.
• Is an account role (default=false)—A boolean value to define whether the user is designated
with an XDR Account Admin role in the Cortex Gateway. To define this in the CSV file, set
the value to TRUE; otherwise, the value is set to FALSE (default).
• Show User Subset to display only the users who are not designated as a Hidden user (default).
• Search for something in the search box.
The following is a descripon of the different columns in the Users table.
Certain fields are exposed and hidden by default. An asterisk (*) is beside every field that is
exposed by default.
• User Name*—Displays the first and last name of the user.

• Email*—Email address of the user.
• Direct XDR Role*—Name of the role assigned to the user. When the user does not have any
Cortex XDR access permission, the field displays No-Role.
• Groups*—Lists the groups that a user belongs to, where any group imported from Acve
Directory has the leers AD added beside the group name.
• Group Roles*—Lists the different group roles based on the groups the user belongs to. When
you hover over the group role, the group associated with this role is displayed.
• Endpoint Scope*—Displays the currently assigned Endpoint Scope for the user as either All
Endpoints or Specific Groups.
• Last Login Time*—Last date and me the user accessed the tenant.
• Status*—Displays whether the user is Acve or Inacve.
• First Name—Displays the first name of the user.
• Last Name—Displays the last name of the user.
You can also pivot (right-click) from rows and specific values in the table, where a number of
different opons are available to help you manage your Cortex XDR users from this page. You can
perform these acons on one or more users at a me.
STEP 1 | Select Sengs > Configuraons > Access Management > Users.
In the Users page, a number of different opons are available to help you manage users.
STEP 2 | Manage your Cortex XDR users.

The following opons are available to help you manage users, which you can perform on one
or more users at a me.
• Update user role for users with an exing role.
1. You can either hover over the user name and select the Update User Role icon ( ),
located to the right of the row, or right-click the user name and select Update User Role.
You can also select more than one user to set and manage a role for all these system
users belonging to the same group at once.
2. Select a Role from the list of default and custom roles that you want to assign the user.
For a user with an XDR Account Admin role, you can only degregate their role
using the Cortex Gateway.
3. Add a parcular user to a group by selecng the User Groups from the list.
4. Show Accumulated Permissions for the user(s) based on the Role and User Groups
assigned to the user(s). Role permissions are comprised of different Components
permissionsfor all roles and Dataset permissions are also included for custom roles. By
default All permissions are displayed, which lists the combined permissions of every
Role and User Group assigned to the user. You can also select the specific roles assigned
to the user, which enables you to compare available permissions based on the roles
selected. This can help you understand how the role permissions for a parcular user
are built. For example, if you need to isolate for a specific component, the permissions
provided by a parcular Role or User Group.
5. Update User to save your changes to the user role.
• Deacvate a user.
Locate the user you want to deacvate, right-click, and select Deacvate User.
You cannot deacvate a user that has an Account Admin role.
• Remove a role assigned to a user.

1. Locate the user you want to remove the role from, right-click, and select Remove Role.
2. Click Remove.
You cannot remove a user that has an Account Admin role.
• Designate a user as hidden.

Locate the user you want to hide, right-click, and select Hide User. When a user is
designated as hidden, the user will no longer be displayed in the Users table when the table
is configured to Show User Subset (default configuraon). This is useful, for example, when
you have users, who are not related to Cortex XDR and will not be designated with a Cortex
XDR role, such as CSP Super Users, and you want to hide them from the list.
• Copy text to clipboard to copy text from a specific row field in the row of a user.
• Copy enre row to copy the text from all the fields in a row of a user.
• Manage User Scope
Assign users to specific endpoint groups in your organizaon.
Manage Roles
You can manage roles for a specific tenant only using the Cortex XDR Access Management
console.In addion, you can also set manage user access permissions for the various XQL datasets
as part of managing roles.
In the Roles page, Cortex XDR lists the Predefined User Roles for Cortex XDR and custom
defined roles. Use roles to assign specific view and acon access privileges to administrave user
accounts. The way you configure administrave access depends on the security requirements of
your organizaon. The built-in roles provide specific access rights that cannot be changed. The
roles you create provide more granular access control.
The following is a descripon of the different columns in the Roles table.
• Role Name—Name of the role.
• Created By—Displays either the email address of the user who created a custom role or for
predefined roles one of the following opons are displayed.
• Palo Alto Networks—Predefined role granng user permissions in all tenants.
• <user email address> —Custom role created in the gateway granng user permission to
this tenant.
• <user email address> —Custom role created in the Cortex XDR app granng user
permission to this specific tenant.
• Descripon—Descripon of the role.
• Creaon Time—Date and me when the role was created. The field is available for only a
custom role.
• Update Date—Date and me of when the role was last updated. The field is available for only a
custom role.
• Custom—Displays a boolean value of either Yes or No to indicate whether the role is a custom
role.
When creang a New Role or eding an exisng role, you can manage roles for all Cortex XDR
apps and services in the Components tab of the Create Role window. Role permissions for the
various Cortex XDR components are listed according to the sidebar navigaon in Cortex XDR.
By assigning roles, you enforce the separaon of viewing access and iniang acons among
funconal or regional areas of your organizaon. In addion, Cortex XDR supports XQL dataset
permission enforcement as part of managing roles or specific permissions using role-based access
control (RBAC). The Datasets tab of the Create Role window is where you can enable or disable
the access permissions for the various datasets listed. The Datasets permissions control the
dataset access across the enre product components, as opposed to the Components RBAC
tab, which controls access to a specific component. When a dataset component is enabled for a
parcular role, the Alert and Incidents pages display all the alerts and incidents, where informaon
about the datasets is included. By default, the Enable dataset access management feature is
disabled, and users have access to all datasets. Once you enable this feature, you need to define
for each dataset type the access permissions you want to grant for the role.
STEP 1 | Select Sengs > Configuraons > Access Management > Roles.
STEP 2 | Manage your Cortex XDR roles.

Cortex XDR only displays the roles available on your tenant. To view the roles and permissions
for mulple tenants, see Permission Management.
In the Roles table, the following opons are available to help you manage roles.
• Create a custom role based on Cortex XDR Predefined roles.
1. Locate the predefined role that you want to base your custom role on, right-click, and
select Save As New Role.
2. Specify a Role Name and update the Descripon.
3. In the Components tab, where the components are listed according to the sidebar
navigaon in Cortex XDR, update the role permissions for each Cortex XDR component
to None, View, or View/Edit. Some components have an addional acons level to
define.
4. In the Datasets tab, the Enable dataset access management permissions feature is
disabled by default, and the user role has access to all datasets. By default, even if you
are basing your role on a preexisng role with access to datasets, access management
permissions are disabled unless you enable them. Once you enable this feature, you need
to define for each dataset type the access permissions you want to grant for the role in
any of the following ways, where the opons differ depending on the dataset type.
-Select Access All to enable this role to access all datasets that currently exist for this
dataset type.
-Select Future datasets to enable this role to access all datasets that will be created in
the future for this dataset type.
-Select access to choose the specific datasets that you want this role to be able to access
for this dataset type. By default, the specific datasets are displayed. If not, select the
expander icon (>) beside the dataset type to display the datasets that currently exist for
this dataset type.
To help you easily know whether the Enable dataset access management permissions
feature is enabled or disabled without having to open the tab, the tab either displays as
Datasets (Disabled) or Datasets (Enabled).
5. Create the role.
• Create and save new roles based on the granular permission.
1. Select New Role.
2. Specify a Role Name and Descripon.
3. In the Components tab, where the components are listed according to the sidebar
navigaon in Cortex XDR, update the role permissions for each Cortex XDR component
to None, View, or View/Edit. Some components have an addional acons level to

define.
4. In the Datasets tab, the Enable dataset access management permissions feature is
disabled by default, and the user role has access to all datasets. By default, even if you
are basing your role on a preexisng role with access to datasets, access management
permissions are disabled unless you enable them. Once you enable this feature, you need
to define for each dataset type the access permissions you want to grant for the role in
any of the following ways, where the opons differ depending on the dataset type.
-Select Access All to enable this role to access all datasets that currently exist for this
dataset type.
-Select Future datasets to enable this role to access all datasets that will be created in
the future for this dataset type.
-Select access to choose the specific datasets that you want this role to be able to access
for this dataset type. By default, the specific datasets are displayed. If not, select the
expander icon (>) beside the dataset type to display the datasets that currently exist for
this dataset type.
To help you easily know whether the Enable dataset access management permissions
feature is enabled or disabled without having to open the tab, the tab either displays as
Datasets (Disabled) or Datasets (Enabled).
5. Create the role.
• Edit role permissions (only available for roles created in the tenant).
1. Locate the custom role you want to edit, right-click, and select Edit Role.
2. In the Components tab of the Edit Role window, where the components are listed
according to the sidebar navigaon in Cortex XDR, update the role permissions for
each Cortex XDR component to None, View, or View/Edit. Some components have an
addional acons level to define.
3. In the Datasets tab, you can enable and disable dataset access permissions for the
various datasets listed as required.
4. Edit the role.
Manage User Groups

In the User Groups page, you can manage user groups for a specific tenant.
At the top of the page, you can perform the following acons.
• Import a single exisng group from Acve Directory that you want to manage in Cortex XDR.
This feature is only available if you enabled the Cloud Identy Engine in
Configuraons > Integraons > Cloud Identy Engine.
• Create a new user group for a number of different system users or groups.
The User Groups table provides the following fields of informaon.
• Group Name—Name of the user group.
• Descripon —Descripon of the user group.
• Role—Lists the group role associated with this user group. You can only have a single role
designated per group.
• Users—Lists all the users belonging to this user group.
• Nested Groups—Lists any nested groups associated with this user group.
• Insert Time—Date and me when the user group was added.
• Update Time—Date and me of when the user group was last updated.
• Source—Displays the source of the user group as either a user group imported from Acve
Directory or a Custom user group created in Cortex XDR.
You can also pivot (right-click) from rows and specific values in the table, where a number of
different opons are available to help you manage your Cortex XDR user groups from this page.
• Save an exisng group as a new group.
• Edit a group.
• Remove a group.
• Copy text to clipboard.
• Copy enre row.
STEP 1 | Select Sengs > Configuraons > Access Management > User Groups.
In the User Groups page, a number of different opons are available to help you manage user
groups.
STEP 2 | Manage your Cortex XDR user groups.

The following opons are available to help you manage user groups, which you can perform on
one or more user groups at a me.
• Import a single exisng group from Acve Directory that you want to manage in Cortex
XDR.
This feature is only available if you enabled the Cloud Identy Engine in
Configuraons > Integraons > Cloud Identy Engine.
1. Import AD Group.
2. Set the following parameters in the Import Group from Acve Directory window.
-Import AD Group—Specify the parcular Acve Directory group in the field and select
whether the AD group can be found in All, OUs, or Groups.
Only CSP users will be imported.
-Specify a Descripon.
-Role—Select a role that you want to designate for this user group, where only a single
role can be assigned to a group.
3. Import the user group.
• Create a new user group for a number of different system users or groups.
1. Select New Group.
2. Set the following parameters in the New Custom Group window.
-Specify the Name and Descripon for the user group.
-Role—Select a role that you want to designate for this user group, where only a single
role can be assigned to a group.
-Users—Select the user(s) that you want to belong to this user group, where you can also
use the search field to narrow down the list of users.
-Nested Groups—(oponal) Select the nested group(s) that you want associated with this
user group.
3. Create the user group.
• Save an exisng group as a new group.
1. Select the user group or right-click the user group, and select Save as New Group.
2. Set the following parameters in the New Custom Group window.
-Specify the Name and Descripon for the user group.
-Role—Leave the designated role or select a new role that you want to designate for this
user group.
-Users—Leave the current user(s) or select the user(s) that you want to belong to this
user group. You can also use the search field to narrow down the list of users.
-Nested Groups—Leave the current nested group(s), select the nested group(s) that you
want associated with this user group, or remove all nested groups if you don’t want any
defined.
3. Create the user group.
• Edit a user group.
1. Select the user group or right-click the user group, and select Edit Group.
2. Set the following parameters in the Edit Custom Group window.
-Update the Name and Descripon for the user group.
-Role—Leave the designated role or select a new role that you want to designate for this
user group.
-Users—Leave the current user(s) or select the user(s) that you want to belong to this
user group. You can also use the search field to narrow down the list of users.
-Nested Groups—Leave the current nested group(s), select the nested group(s) that you
want associated with this user group, or remove all nested groups if you don’t want any
defined.
3. Save your changes.
• Remove a user group.
1. To remove more than one user group, select the user groups, right-click, and select
Remove Groups.
To remove one user group, select the user group or right-click the user group, and select
Remove Group.
2. Click Delete in the window that is displayed.
• Copy text to clipboard to copy text from a specific row field in the row of a user group.
• Copy enre row to copy the text from all the fields in a row of a user group.
Predefined User Roles for Cortex XDR

Role-based access control (RBAC) enables you to use predefined Palo Alto Networks roles to
assign access rights to Cortex XDR users. You can manage roles for all Cortex XDR apps and
services in the Cortex Gateway and Cortex XDR management console. By assigning roles, you
enforce the separaon of access among funconal or regional areas of your organizaon.
Each role extends specific privileges to users. The way you configure administrave access
depends on the security requirements of your organizaon. Use roles to assign specific access
privileges to administrave user accounts. The Palo Alto Networks roles provide specific access
rights that cannot be changed, but can be saved as a new role and edited according to your needs.
You can manage role permissions in Cortex XDR, which are listed by the various components
according to the sidebar navigaon in Cortex XDR. Some components include addional acon
permissions, such as pivot (right-click) opons, which you can also assign access, but only when
you’ve given the user View/Edit permissions to the applicable component.
The following tables describe the various Cortex XDR components and addional acon
permissions according to the sidebar navigaon that are associated with the Palo Alto Networks
predefined roles.
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.
• XDR Account Admin

• Instance Administrator
• Deployment Admin
• Invesgator
• Invesgaon Admin
• Responder
• Privileged Invesgator
• Privileged Responder
• IT Admin
• Privileged IT Admin
• Privileged Security Admin
• Viewer
• Scoped Endpoint Admin
• Security Admin
XDR Account Admin

The Cortex XDR predefined user role called XDR Account Admin provides full access to the given
app(s), including all instances added to the app(s) in the future. App Administrator can assign roles
for apps instances, and it can also acvate app instances specific to the app.
Table 1: XDR Account Admin
Navigaon Components Permissions Addional

Headings Acon
Permissions
None View View/Edit Edit/None
DASHBOARDS Dashboards — — —
& REPORTS
Ingeson — — —
Monitoring
Reports — — —
INCIDENT
RESPONSE

Headings Acon
Permissions
>Incidents & Alerts & — — —

Alerts Incidents
>Invesgaon Query Center — — —
Personal — — —
Query
Library
Forensics — — —
Host Insights — — —
>Response Acon — —
Center
Isolate
Terminate
Process
Quaranne
EDL
File
Retrieval
File
Search
Destroy
Files
Allow
List/Block
List
Disable
Response
Acons

Headings Acon
Permissions
Remediaon
Delete
Quaranned
files
Agent Scripts — —
Library
Run Standard
Script
Run High-
Risk
Script
Script
Configuraons
Live Terminal — — —
DETECTIONS
& THREAT
INTEL
>Detecons Rules — —
Prevenon
Rules
Request
WildFire
Verdict
Change
Assets Network — — —
Configuraon
Compliance — — —
Asset — — —
Inventory

Headings Acon
Permissions
Endpoints
Endpoint — —
Administraons
Endpoint
Management
Retrieve
Endpoint
Data
Endpoint
Scan
Change
Managing
Server
Pause
Protecon
Endpoint — — —
Groups
Installaons
Prevenon
Policies
Global — — —
Excepons
extension
policies
Profiles
Host Firewall — — —

Headings Acon
Permissions
Device — —
Control
Rules
Excepons
Sengs
>General Auding — — —
Sengs
General — — —
Configuraon
Alert — — —
Noficaons
>Cortex XDR On-demand — — —

- Analycs Analycs
>Broker VMs Broker — —

Services
Pathfinder
Applet
Pathfinder — — —
Data
Collecon
>Data Log — — —
Collecon Collecons
External — — —
Alerts
Mapping
>Integraons Public API — — —
Threat — — —
Intelligence
EDL — — —
Configuraon
Instance Administrator
The Cortex XDR predefined user role called Instance Administrator provides full access to the app
instance for which this role is assigned.
The Instance Administrator can also make other users an Instance Administrator for the app
instance. If the app has predefined or custom roles, the Instance Administrator can assign those
roles to other users.
The Instance Administrator can only assign permissions to the other user from the Cortex
XDR Management Console.
Table 2: Instance Administrator

Headings Acon
Permissions
& REPORTS
Monitoring
Reports — — —
INCIDENT
RESPONSE

Alerts Incidents
Query
Library
Center
Isolate

Headings Acon
Permissions
Terminate
Process
Quaranne
EDL
File
Retrieval
File
Search
Destroy
Files
Allow
List/Block
List
Disable
Response
Acons
Remediaon
Delete
Quaranned
files
Library
Run Standard
Script
Run High-
Risk
Script

Headings Acon
Permissions
Script
Configuraons
DETECTIONS
& THREAT
INTEL
Prevenon
Rules
Request
WildFire
Verdict
Change
Configuraon
Asset — — —
Inventory
Endpoints
Endpoint — —
Administraons
Endpoint
Management
Retrieve
Endpoint
Data
Endpoint
Scan

Headings Acon
Permissions
Change
Managing
Server
Pause
Protecon
—
Groups
Installaons
Prevenon
Policies
Global — — —
Excepons
extension
policies
Profiles
Device — —
Control
Rules
Excepons
Sengs
Sengs
General — — —
Configuraon

Headings Acon
Permissions
Alert — — —
Noficaons


Services
Pathfinder
Applet
Data
Collecon
Alerts
Mapping
Threat — — —
Intelligence
EDL — — —
Configuraon
Deployment Admin
The Cortex XDR predefined user role called Deployment Admin is used to manage and control
endpoints and installaons, and configure broker VMs.
Table 3: Deployment Admin

Headings Acon
Permissions

Headings Acon
Permissions
& REPORTS
Monitoring
Reports — — —
INCIDENT
RESPONSE

Alerts Incidents
Query
Library
Center
Isolate
—
Terminate
Process
—
Quaranne
—
EDL
—
File Retrieval
—

Headings Acon
Permissions
File Search
—
Destroy Files
—
Allow List/
Block List
—
Disable
Response
Acons
—
Remediaon
—
Delete
Quaranned
files
—
Library
Run Standard
Script
—
Run High-
Risk Script
—
Script
Configuraons
—

Headings Acon
Permissions
DETECTIONS
& THREAT
INTEL
Prevenon
Rules
—
Request
WildFire
Verdict
Change
—
Configuraon
Asset — — —
Inventory
Endpoints
Endpoint — —
Administraons
Endpoint
Management
Retrieve
Endpoint
Data
—
Endpoint
Scan
—
Change
Managing
Server

Headings Acon
Permissions
Pause
Protecon
—
Groups
Installaons
Prevenon
Policies
Global — — —
Excepons
extension
policies
Profiles
Device — —
Control
Rules
—
Excepons
—
Sengs
Sengs
General — — —
Configuraon

Headings Acon
Permissions
Alert — — —
Noficaons


Services
Pathfinder
Applet
Data
Collecon
Alerts
Mapping
Threat — — —
Intelligence
EDL — — —
Configuraon
Invesgator
The Cortex XDR predefined user role called Invesgator is used to view and triage alerts and
incidents.
Table 4: Investigator

Headings Acon
Permissions

Headings Acon
Permissions
& REPORTS
Monitoring
Reports — — —
INCIDENT
RESPONSE

Alerts Incidents
Query
Library
Center
Isolate
—
Terminate
Process
—
Quaranne
—
EDL
—
File Retrieval
—

Headings Acon
Permissions
File Search
—
Destroy Files
—
Allow List/
Block List
—
Disable
Response
Acons
—
Remediaon
—
Delete
Quaranned
files
—
Library
Run Standard
Script
—
Run High-
Risk Script
—
Script
Configuraons
—

Headings Acon
Permissions
DETECTIONS
& THREAT
INTEL
Prevenon
Rules
—
Request
WildFire
Verdict
Change
—
Configuraon
Asset — — —
Inventory
Endpoints
Endpoint — —
Administraons
Endpoint
Management
—
Retrieve
Endpoint
Data
—
Endpoint
Scan
—

Headings Acon
Permissions
Change
Managing
Server
—
Pause
Protecon
—
Groups
Installaons
Prevenon
Policies
Global — — —
Excepons
extension
policies
Profiles
Device — —
Control
Rules
—
Excepons
—
Sengs

Headings Acon
Permissions
Sengs
General — — —
Configuraon
Alert — — —
Noficaons


Services
Pathfinder
Applet
—
Data
Collecon
Alerts
Mapping
Threat — — —
Intelligence
EDL — — —
Configuraon
Invesgaon Admin
The Cortex XDR predefined user role called Invesgaon Admin is used to view and triage alerts
and incidents, configure rules, view endpoint profiles and policies, and Analycs management
screens.
Table 5: Investigation Admin

Headings Acon
Permissions
& REPORTS
Monitoring
Reports — — —
INCIDENT
RESPONSE

Alerts Incidents
Query
Library
Center
Isolate
—
Terminate
Process
—
Quaranne
—
EDL

Headings Acon
Permissions
File Retrieval
—
File Search
—
Destroy Files
—
Allow List/
Block List
—
Disable
Response
Acons
—
Remediaon
—
Delete
Quaranned
files
—
Library
Run Standard
Script
—
Run High-
Risk Script
—
Script
Configuraons
—

Headings Acon
Permissions
DETECTIONS
& THREAT
INTEL
Prevenon
Rules
—
Request
WildFire
Verdict
Change
—
Configuraon
Asset — — —
Inventory
Endpoints
Endpoint — —
Administraons
Endpoint
Management
—
Retrieve
Endpoint
Data
—
Endpoint
Scan

Headings Acon
Permissions
—
Change
Managing
Server
—
Pause
Protecon
—
Groups
Installaons
Prevenon
Policies
Global — — —
Excepons
extension
policies
Profiles
Device — —
Control
Rules
Excepons
Sengs
Sengs

Headings Acon
Permissions
General — — —
Configuraon
Alert — — —
Noficaons


Services
Pathfinder
Applet
—
Data
Collecon
Alerts
Mapping
Threat — — —
Intelligence
EDL — — —
Configuraon
Responder
The Cortex XDR predefined user role called Responder is used to view and triage alerts, and
access all response capabilies excluding Live Terminal.
Table 6: Responder

Headings Acon
Permissions
& REPORTS
Monitoring
Reports — — —
INCIDENT
RESPONSE

Alerts Incidents
Query
Library
Center
Isolate
Terminate
Process
Quaranne
EDL
File Retrieval
—

Headings Acon
Permissions
File Search
—
Destroy Files
—
Allow
List/Block
List
Disable
Response
Acons
—
Remediaon
—
Delete
Quaranned
files
—
Library
Run Standard
Script
—
Run High-
Risk Script
—
Script
Configuraons
—

Headings Acon
Permissions
DETECTIONS
& THREAT
INTEL
Prevenon
Rules
—
Request
WildFire
Verdict
Change
Configuraon
Asset — — —
Inventory
Endpoints
Endpoint — —
Administraons
Endpoint
Management
—
Retrieve
Endpoint
Data
—
Endpoint
Scan
—

Headings Acon
Permissions
Change
Managing
Server
—
Pause
Protecon
—
Groups
Installaons
Prevenon
Policies
Global — — —
Excepons
extension
policies
Profiles
Device — —
Control
Rules
—
Excepons
—
Sengs

Headings Acon
Permissions
Sengs
General — — —
Configuraon
Alert — — —
Noficaons


Services
Pathfinder
Applet
—
Data
Collecon
Alerts
Mapping
Threat — — —
Intelligence
EDL — — —
Configuraon
Privileged Invesgator
The Cortex XDR predefined user role called Privileged Invesgator is used to view and triage
alerts, incidents and rules, and view endpoint profiles and policies, and Analycs management
screens.
Table 7: Privileged Investigator

Headings Acon
Permissions
& REPORTS
Monitoring
Reports — — —
INCIDENT
RESPONSE

Alerts Incidents
Query
Library
Center
Isolate
—
Terminate
Process
—
Quaranne
—
EDL

Headings Acon
Permissions
File Retrieval
—
File Search
—
Destroy Files
—
Allow List/
Block List
—
Disable
Response
Acons
—
Remediaon
—
Delete
Quaranned
files
—
Library
Run Standard
Script
—
Run High-
Risk Script
—
Script
Configuraons
—

Headings Acon
Permissions
DETECTIONS
& THREAT
INTEL
Prevenon
Rules
—
Request
WildFire
Verdict
Change
—
Configuraon
Asset — — —
Inventory
Endpoints
Endpoint — —
Administraons
Endpoint
Management
—
Retrieve
Endpoint
Data
—
Endpoint
Scan

Headings Acon
Permissions
—
Change
Managing
Server
—
Pause
Protecon
—
Groups
Installaons
Prevenon
Policies
Global — — —
Excepons
extension
policies
Profiles
Device — —
Control
Rules
—
Excepons
—
Sengs

Headings Acon
Permissions
Sengs
General — — —
Configuraon
Alert — — —
Noficaons


Services
Pathfinder
Applet
—
Data
Collecon
Alerts
Mapping
Threat — — —
Intelligence
EDL — — —
Configuraon
Privileged Responder
The Cortex XDR predefined user role called Privileged Responder is used to view and triage alerts
and incidents, access all response capabilies, and configure rules, policies, and profiles.
Table 8: Privileged Responder

Headings Acon
Permissions
& REPORTS
Monitoring
Reports — — —
INCIDENT
RESPONSE

Alerts Incidents
Query
Library
Center
Isolate
Terminate
Process
Quaranne
EDL
File
Retrieval

Headings Acon
Permissions
File
Search
Destroy
Files
Allow
List/Block
List
Disable
Response
Acons
—
Remediaon
Delete
Quaranned
files
—
Library
Run Standard
Script
Run High-
Risk
Script
Script
Configuraons
DETECTIONS
& THREAT
INTEL

Headings Acon
Permissions
Prevenon
Rules
—
Request
WildFire
Verdict
Change
Configuraon
Asset — — —
Inventory
Endpoints
Endpoint — —
Administraons
Endpoint
Management
—
Retrieve
Endpoint
Data
Endpoint
Scan
Change
Managing
Server
—
Pause
Protecon

Headings Acon
Permissions
—
Groups
Installaons
Prevenon
Policies
Global — — —
Excepons
extension
policies
Profiles
Device — —
Control
Rules
Excepons
Sengs
Sengs
General — — —
Configuraon
Alert — — —
Noficaons


Headings Acon
Permissions
>Broker VMs Broker — — —

Services
Pathfinder
Applet
—
Data
Collecon
Alerts
Mapping
Threat — — —
Intelligence
EDL — — —
Configuraon
IT Admin
The Cortex XDR predefined user role called IT Admin is used to manage and control endpoints
and installaons, configure broker VMs, view endpoint profiles and policies, and view alerts.
Table 9: IT Admin

Headings Acon
Permissions
& REPORTS
Monitoring

Headings Acon
Permissions
Reports — — —
INCIDENT
RESPONSE

Alerts Incidents
Query
Library
Center
Isolate
—
Terminate
Process
—
Quaranne
—
EDL
—
File Retrieval
—
File Search
—
Destroy Files

Headings Acon
Permissions
—
Allow List/
Block List
—
Disable
Response
Acons
—
Remediaon
—
Delete
Quaranned
files
—
Library
Run Standard
Script
—
Run High-
Risk Script
—
Script
Configuraons
—
DETECTIONS
& THREAT
INTEL

Headings Acon
Permissions
Prevenon
Rules
—
Request
WildFire
Verdict
Change
—
Configuraon
Asset — — —
Inventory
Endpoints
Endpoint — —
Administraons
Endpoint
Management
Retrieve
Endpoint
Data
Endpoint
Scan
—
Change
Managing
Server
—
Pause
Protecon
—

Headings Acon
Permissions
Groups
Installaons
Prevenon
Policies
Global — — —
Excepons
extension
policies
Profiles
Device — —
Control
Rules
—
Excepons
—
Sengs
Sengs
General — — —
Configuraon
Alert — — —
Noficaons


Headings Acon
Permissions

Services
Pathfinder
Applet
Data
Collecon
Alerts
Mapping
Threat — — —
Intelligence
EDL — — —
Configuraon
Privileged IT Admin
The Cortex XDR predefined user role called Privileged IT Admin is used to manage and control
endpoints and installaons, configure brokers, create profiles and policies, view alerts, and iniate
Live Terminal.
Table 10: Privileged IT Admin

Headings Acon
Permissions
& REPORTS
Monitoring

Headings Acon
Permissions
Reports — — —
INCIDENT
RESPONSE

Alerts Incidents
Query
Library
Center
Isolate
—
Terminate
Process
—
Quaranne
—
EDL
—
File
Retrieval
File
Search

Headings Acon
Permissions
Destroy
Files
Allow List/
Block List
—
Disable
Response
Acons
—
Remediaon
Delete
Quaranned
files
—
Library
Run Standard
Script
Run High-
Risk
Script
Script
Configuraons
DETECTIONS
& THREAT
INTEL
Prevenon
Rules

Headings Acon
Permissions
—
Request
WildFire
Verdict
Change
Configuraon
Asset — — —
Inventory
Endpoints
Endpoint — —
Administraons
Endpoint
Management
Retrieve
Endpoint
Data
Endpoint
Scan
—
Change
Managing
Server
Pause
Protecon
Groups
Installaons

Headings Acon
Permissions
Prevenon
Policies
Global — — —
Excepons
extension
policies
Profiles
Device — —
Control
Rules
Excepons
Sengs
Sengs
General — — —
Configuraon
Alert — — —
Noficaons


Services
Pathfinder
Applet

Headings Acon
Permissions
Data
Collecon
Alerts
Mapping
Threat — — —
Intelligence
EDL — — —
Configuraon
Privileged Security Admin

The Cortex XDR predefined user role called Privileged Security Admin is used to triage and
invesgate alerts and incident, respond, and edit profiles and policies.
Table 11: Privileged Security Admin

Headings Acon
Permissions
& REPORTS
Monitoring
Reports — — —
INCIDENT
RESPONSE

Alerts Incidents

Headings Acon
Permissions
Query
Library
Center
Isolate
Terminate
Process
Quaranne
EDL
File
Retrieval
File
Search
Destroy
Files
Allow
List/Block
List
Disable
Response
Acons
—
Remediaon

Headings Acon
Permissions
Delete
Quaranned
files
—
Library
Run Standard
Script
Run High-
Risk
Script
Script
Configuraons
DETECTIONS
& THREAT
INTEL
Prevenon
Rules
Request
WildFire
Verdict
Change
Configuraon
Asset — — —
Inventory

Headings Acon
Permissions
Endpoints
Endpoint — —
Administraons
Endpoint
Management
—
Retrieve
Endpoint
Data
Endpoint
Scan
Change
Managing
Server
—
Pause
Protecon
Groups
Installaons
Prevenon
Policies
Global — — —
Excepons
extension
policies
Profiles

Headings Acon
Permissions
Device — —
Control
Rules
Excepons
Sengs
Sengs
General — — —
Configuraon
Alert — — —
Noficaons


Services
Pathfinder
Applet
—
Data
Collecon
Alerts
Mapping

Headings Acon
Permissions
Threat — — —
Intelligence
EDL — — —
Configuraon
Viewer
The Cortex XDR predefined user role called Viewer is used to view the majority of the features of
the Cortex XDR app for this instance.
Table 12: Viewer

Headings Acon
Permissions
& REPORTS
Monitoring
Reports — — —
INCIDENT
RESPONSE

Alerts Incidents
Query
Library

Headings Acon
Permissions
Center
Isolate
—
Terminate
Process
—
Quaranne
—
EDL
—
File Retrieval
—
File Search
—
Destroy Files
—
Allow List/
Block List
—
Disable
Response
Acons
—
Remediaon
—
Delete
Quaranned
files

Headings Acon
Permissions
—
Library
Run Standard
Script
—
Run High-
Risk Script
—
Script
Configuraons
—
DETECTIONS
& THREAT
INTEL
Prevenon
Rules
—
Request
WildFire
Verdict
Change
—
Configuraon
Asset — — —
Inventory

Headings Acon
Permissions
Endpoints
Endpoint — —
Administraons
Endpoint
Management
—
Retrieve
Endpoint
Data
—
Endpoint
Scan
—
Change
Managing
Server
—
Pause
Protecon
—
Groups
Installaons
Prevenon
Policies
Global — — —
Excepons
extension
policies

Headings Acon
Permissions
Profiles
Device — —
Control
Rules
—
Excepons
—
Sengs
Sengs
General — — —
Configuraon
Alert — — —
Noficaons


Services
Pathfinder
Applet
—
Data
Collecon

Headings Acon
Permissions
Alerts
Mapping
Threat — — —
Intelligence
EDL — — —
Configuraon
Scoped Endpoint Admin

The Cortex XDR predefined user role called Scoped Endpoint Admin provides access only
to product areas that support endpoint scoped based access control (SBAC) - Endpoint
Administraon, Acon Center, Response, Dashboards, and Reports.
Table 13: Scoped Endpoint Admin

Headings Acon
Permissions
& REPORTS
Monitoring
Reports — — —
INCIDENT
RESPONSE

Alerts Incidents
Query
Library

Headings Acon
Permissions
Center
Isolate
Terminate
Process
Quaranne
EDL
—
File
Retrieval
File
Search
Destroy
Files
Allow List/
Block List
—
Disable
Response
Acons
Remediaon
—
Delete
Quaranned
files

Headings Acon
Permissions
—
Library
Run Standard
Script
Run High-
Risk
Script
Script
Configuraons
—
DETECTIONS
& THREAT
INTEL
Prevenon
Rules
—
Request
WildFire
Verdict
Change
—
Configuraon
Asset — — —
Inventory
Endpoints

Headings Acon
Permissions
Endpoint — —
Administraons
Endpoint
Management
Retrieve
Endpoint
Data
Endpoint
Scan
Change
Managing
Server
Pause
Protecon
—
Groups
Installaons
Prevenon
Policies
Global — — —
Excepons
extension
policies
Profiles

Headings Acon
Permissions
Device — —
Control
Rules
—
Excepons
—
Sengs
Sengs
General — — —
Configuraon
Alert — — —
Noficaons


Services
Pathfinder
Applet
—
Data
Collecon
Alerts
Mapping

Headings Acon
Permissions
Threat — — —
Intelligence
EDL — — —
Configuraon
Security Admin
The Cortex XDR predefined user role called Security Admin is used to triage and invesgate alerts
and incidents, respond (excluding Live Terminal), and edit profiles and policies.
Table 14: Security Admin

Headings Acon
Permissions
& REPORTS
Monitoring
Reports — — —
INCIDENT
RESPONSE

Alerts Incidents
Query
Library

Headings Acon
Permissions
Center
Isolate
Terminate
Process
Quaranne
EDL
File Retrieval
—
File Search
—
Destroy Files
—
Allow
List/Block
List
Disable
Response
Acons
—
Remediaon
—
Delete
Quaranned
files
—
Library

Headings Acon
Permissions
Run Standard
Script
—
Run High-
Risk Script
—
Script
Configuraons
—
DETECTIONS
& THREAT
INTEL
Prevenon
Rules
Request
WildFire
Verdict
Change
Configuraon
Asset — — —
Inventory
Endpoints
Endpoint — —
Administraons
Endpoint
Management

Headings Acon
Permissions
—
Retrieve
Endpoint
Data
Endpoint
Scan
Change
Managing
Server
—
Pause
Protecon
—
Groups
Installaons
Prevenon
Policies
Global — — —
Excepons
extension
policies
Profiles
Device — —
Control
Rules

Headings Acon
Permissions
—
Excepons
—
Sengs
Sengs
General — — —
Configuraon
Alert — — —
Noficaons


Services
Pathfinder
Applet
—
Data
Collecon
Alerts
Mapping
Threat — — —
Intelligence
EDL — — —
Configuraon
Manage User Scope

With Scope-Based Access Control (SBAC), Cortex XDR enables you to assign users to specific
endpoint groups in your organizaon. By default, all users have management access to all
endpoints in the tenant. However, aer you (as an administrator) assign a management scope
to a Cortex XDR user (non-administrator), the user is then be able to manage only the specific
endpoints that are predefined within that scope.
SBAC applies only to the following funconal areas in Cortex XDR.
• Endpoint Administraon table—View endpoints and take acons on endpoints.
• Policy Management—Create and edit Prevenon policies and profiles, Extension policies and
profiles, and global and device Excepons that are within the scope of the user.
• Acon Center—View and take acons only on endpoints that are within the scope of the user.
• Dashboards and Reports—Scoping takes place only on agent-related widgets.
Important: The rest of the funconal 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 funconal area. For
example, a scoped user with a permission to view incidents, can view all incidents in the
system without limitaon to a scope, however will not be able to create an alert or device
excepon.
Also note that the Agent Installaon widget is not available for scoped users.
To define the scope of a user.

STEP 1 | Select Sengs > Configuraons > Access Management > Users.
The currently assigned scope of each user is displayed on the Endpoint Scope column of the
Users table, which lists all registered users.
STEP 2 | Select and right-click the user or users to which you want to assign a scope, and then select
Assign Endpoint Scope.
The Assign Endpoint Scope dialog box appears.
STEP 3 | Under Endpoint Groups, select one of the following:

• Specific groups—Select the endpoint groups that you want to assign to the selected user
or users. This determines the scope of the user or users.
• All endpoints—Assign all endpoints to the selected user or users, without scoping.
STEP 4 | Apply.
The users to whom you have scoped parcular 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 organizaon, and the parcular purpose of each
organizaonal unit to which scoped users belong.
Scoped Endpoint Admin

Scoped Endpoint Admin is a predefined recommended role that you can assign to scoped users.
This predefined (by Palo Alto Networks) user role has recommended permissions to perform the
following acons in Cortex XDR.
• Views—View opons that are available for a Scoped User Admin:
• Endpoint Administraon > Endpoint Administraon
• Dashboards > Dashboard View
• Reports > Reports View
• Response > Acon Center
• Response > Scripts
• Acons—Acons that a Scoped User Admin can perform:
• Endpoint Administraon > File Retrieval
• Endpoint Administraon > Retrieve Endpoint Data
• Endpoint Administraon > Endpoint Scan
• Endpoint Administraon > Change Managing Server
• Endpoint Administraon > Agent Management Configuraons
• Dashboards > Dashboard Acon
• Response > Isolate
• Response > Live Terminal
• Response > File Search
• Response > Destroy Files
• Response > Terminate Process
• Response > Quaranne
• Response > Run Standard Script
• Response > Run High-Risk Script
• Response > Disable Response Acons
For more informaon about user roles, see Manage User Roles.
Set Up Cloud Identy Engine

Cloud Identy Engine is an oponal service that enables you to leverage Acve Directory
user, group, and computer informaon in Cortex XDR , and to provide context when you
invesgate alerts. You can use Acve Directory informaon in policy configuraon and endpoint
management.
When using the Cloud Identy Engine (previously called Directory Sync Service (DSS))with
a Cortex XDR Pro license, you can use XQL Search to query the data using the
pan_dss_raw dataset.
Aer you finish the setup, Cortex XDR automacally updates when the Cloud Identy Engine
updates.
To set up the Cloud Identy Engine:
STEP 1 | Navigate and log into the hub.
STEP 2 | Acvate and configure your Cloud Identy Engine instance as described in the Cloud Identy
Engine Geng Started guide.
Acvang a Cloud Identy Engine instance on your Cortex XDR account will allow you to pair
your Cortex XDR tenant with the Acve Directory informaon collected by the Cloud Identy
Engine instance. During the Acvaon step, make sure to take note of the instance name you
create.
STEP 3 | Aer you complete the Cloud Identy Engine Geng Started steps, navigate and log into
your Cortex XDR management console.
Wait about ten minutes aer you have acvated the instance before you do this.
1. In the Cortex XDR app, select Sengs > Configuraon > Integraons > Cloud Identy
Engine.
2. Add the Cloud Identy Engine instance you want to Cortex XDR to use.
3. In the Add Cloud Identy Engine dialog, select the App Instance Name you created in
the hub and Save.
Manage Your Log Storage within Cortex XDR

Cortex XDR Log Storage is managed in the Cortex XDR Data Layer. You receive log storage based
on the amount of storage associated with your Cortex XDR Licenses. Generally, this capacity
is determined by factors such as your daily ingeson needs and the number of users in your
deployment. All Cortex XDR licenses provide you with a default retenon period of 30 days for
your general data usage and your endpoint data usage. You can extend your license retenon
depending on your requirements for the following types of storage.
• Hot Storage—Fully searchable storage, for invesgaon and threat hunng.
• Cold Storage—Cheaper storage usually for long-term compliance needs with limited search
opons.
There are three types of Pro licenses.
Type of Pro License Retenon Details Storage Opons
Cortex XDR Pro per Endpoint Grants ingeson and 30 The following are the storage
(PAN-XDR-ADV-EP) days retenon. If you want opons available with this
to save more than 30 days license.
of endpoint data, you need
• Hot storage EP—Minimum
to obtain addional Cold
of 1 month storage.
or Hot Storage according
to your requirements for • Cold storage EP—
all of your endpoints. For Minimum of 6 months
example, if you obtain 20,000 storage.
endpoints for 30 days and
then require an addional 6
months retenon, you need
to purchase retenon for 6
months for 20,000 endpoints.
Cortex XDR Cloud per Host Grants ingeson and 30 The following are the storage
(PAN-XDR-ADV-EP-CLOUD) days retenon. If you want opons available with this
to save more than 30 days license.
of cloud data, you need to
• Hot storage EP—Minimum
obtain addional Cold or Hot
of 1 month storage.
Storage according to your
requirements for all of your • Cold storage EP—
hosts. Minimum of 6 months
storage.
Cortex XDR Pro per TB Where each license adheres For retenon, each license
(PAN-XDR-ADV-1TB) to the following guidelines. provides you with a default
retenon of 30 days. If
• Allows ingesng up to 1
you want to save more
TB per month and no more
than 30 days of Pro per TB
than 33GB per day.
data, you need to obtain
addional Cold or Hot
Type of Pro License Retenon Details Storage Opons

• Enables storing 1TB of Storage according to you
data for 30 days. requirements for all your data.
The following are the storage
The Cortex opons available with this
XDR Agent license.
and Cortex
• Hot storage GB—Minimum
XDR Stched
of 1 month storage.
data is not
counted • Cold storage GB—
against Minimum of 6 months
your daily storage.
ingeson
quota.
For more informaon on your storage license details, see Dataset Management.
To increase your capacity, contact your Palo Alto Network account representave.
To view your current Cortex XDR license.
From Cortex XDR, select Sengs > Cortex XDR License.
Data usage and storage license details are available in Dataset Management.
Set up Endpoint Protecon

The Cortex XDR agent monitors endpoint acvity and collects endpoint data that Cortex XDR
uses to raise alerts. Before you can begin collecng endpoint data, you must deploy the Cortex
XDR agent and configure endpoint policy.
To use endpoint management funcons in Cortex XDR you must be assigned an administrave
role in the hub.
STEP 1 | Verify the status of your Cortex XDR tenant.
1. From the hub, click the gear icon next to your name.
2. In the Cortex area, review the STATUS for the tenant you just acvated.
When Cortex XDR tenant is available, the status changes to the green check mark.
STEP 2 | Plan Your Cortex XDR Deployment.
STEP 3 | Enable Acces to Cortex XDR.
STEP 4 | (Oponal) Set up Broker VM communicaon.
STEP 5 | Install the Cortex XDR agent on your endpoints.

Install the agent soware directly on an endpoint or use a soware deployment tool of your
choice (such as JAMF or GPO) to distribute and install the soware on mulple endpoints.
1. Create an Agent Installaon Package.
2. Install the Cortex XDR agent.
For instrucons by operang system, see the Cortex XDR Agent Administrator’s Guide or
the Traps Agent Administrator’s Guide if you use an earlier version.
STEP 6 | Define Endpoint Groups to which you can apply endpoint security policy.
STEP 7 | Customize your Endpoint Security Profiles and assign them to your endpoints.
Cortex XDR provides out-of-the box exploit and malware protecon. However, at minimum,
you must enable Data Collecon in an Agent Sengs profile to leverage endpoint data in
Cortex XDR apps. Data collecon for Windows endpoints is available with Traps 6.0 and later
releases and on endpoints running Windows 7 SP1 and later releases. Data collecon on
macOS and Linux endpoints are available with Traps 6.1 and later releases.
STEP 8 | (Oponal) Configure Device Control profiles to restrict file execuon on USB-connected
devices.
STEP 9 | Verify that the Cortex XDR agent can connect to your Cortex XDR instance.
If successful, Cortex XDR displays a Connected status. In your Cortex XDR console, navigate to
Endpoints > All Endpoints to view the status of all your agents.
STEP 10 | Configure the internal networks that you want Cortex XDR to monitor.
1. From the Cortex XDR management console, navigate to Assets > Network Configuraon >
IP Address Ranges.
2. Define your IP Address Ranges.
This page provides a table of the IP address ranges Cortex XDR Analycs monitors, which is
pre-populated with the default IPv4 and IPv6 address spaces.
3. Define your Domain Names.
STEP 11 | If you have a Cortex XDR Pro per TB license, proceed to Set up Network Analysis. Otherwise
proceed to Configure XDR.
Plan Your Agent Deployment

You typically deploy Cortex XDR agent soware to endpoints across a network aer an inial
proof of concept (POC), which simulates your corporate producon environment. During the POC
or deployment stage, you analyze security events to determine which are triggered by malicious
acvity and which are due to legimate processes behaving in a risky or incorrect manner. You
also simulate the number and types of endpoints, the user profiles, and the types of applicaons
that run on the endpoints in your organizaon and, according to these factors, you define, test,
and adjust the security policy for your organizaon.
The goal of this mul-step process is to provide maximum protecon to the organizaon without
interfering with legimate workflows.
Aer the successful compleon of the inial POC, we recommend a mul-step implementaon in
the corporate producon environment for the following reasons:
• The POC doesn't always reflect all the variables that exist in your producon environment.
• There is a rare chance that the Cortex XDR agent will affect business applicaons, which can
reveal vulnerabilies in the soware as a prevented aack.
• During the POC, it is much easier to isolate issues that appear and provide a soluon before full
implementaon in a large environment where issues could affect a large number of users.
A mul-step deployment approach ensures a smooth implementaon and deployment of the
Cortex XDR soluon throughout your network. Use the following steps for beer support and
control over the added protecon.
Step Duraon Plan
0. Calculate the bandwidth as needed For every 100,000 agents, you will need
required to support the number to allocate 120Mbps of bandwidth. The
of agents you plan to deploy. bandwidth requirement scales linearly. For
example, to support 300,000 agents, plan
to allocate 360Mbps of bandwidth (three
mes the amount required for 100,000
agents).
1. Install Cortex XDR on 1 week Install the Cortex XDR agent on a small
endpoints. number of endpoints (3 to 10).
Step Duraon Plan

Test normal behavior of the Cortex
XDR agents (injecon and policy) and
confirm that there is no change in the user
experience.
2. Expand the Cortex XDR 2 weeks Gradually expand agent distribuon to

deployment. larger groups that have similar aributes
(hardware, soware, and users). At the
end of two weeks you can have Cortex
XDR deployed on up to 100 endpoints.
3. Complete the Cortex XDR 2 or more Broadly distribute the Cortex XDR agent
installaon. weeks throughout the organizaon unl all
endpoints are protected.
4. Define corporate policy and Up to 1 week Add protecon rules for third-party or in-
protected processes. house applicaons and then test them.
5. Refine corporate policy and Up to 1 week Deploy security policy rules to a small
protected processes. number of endpoints that use the
applicaons frequently. Fine tune the
policy as needed.
6. Finalize corporate policy and A few minutes Deploy protecon rules globally.
protected processes.
Enable Access to Cortex XDR

Aer you receive your account details, enable and verify access to Cortex XDR.
STEP 1 | (Oponal) If you are deploying the broker VM as a proxy between Cortex XDR and the
Cortex XDR agents, start by enabling the communicaon between them.
STEP 2 | In your firewall configuraon, enable access to Cortex XDR communicaon servers, storage
buckets, and resources.
For the complete list or resources, refer to Resources Required to Enable Access to Cortex.
With Palo Alto Networks firewalls, we recommend that you use the following App-IDs to allow
communicaon between Cortex XDR agents and the Cortex XDR management console when
you configure your security policy:
• cortex-xdr—Requires PAN-OS Applicaons and Threats content update version 8279 or
a later release.
• traps-management-service—Requires PAN-OS Applicaons and Threats content
update version 793 or a later release.
If you use App-ID in your security policy, you must also allow access for addional resources
that are not covered by the App-ID. If you do not use Palo Alto Networks firewalls with App-ID
you must allow access to the full list of resources.
STEP 3 | (Oponal for endpoints running the following or later releases: Cortex XDR 7.5.1 Hotfix 1
and later, Cortex XDR 7.4.3 Hotfix 1 and later, Cortex XDR 7.3.4 Hotfix 1 and later, Traps
6.1.8 Hotfix 1 and later, Traps 6.1.7 Hotfix 1 and later, and Traps 5.0.12 Hotfix 1 and later) To
establish secure communicaon (TLS) to Cortex XDR, the endpoints, and any other devices
that iniate a TLS connecon with Cortex, you must have the following cerficates installed
on the operang system.
Cerficate Fingerprint
GoDaddy Root Cerficate • SHA1 Fingerprint—47 BE AB C9 22 EA E8 0E 78

Authority - G2 (Godaddy) 78 34 62 A7 9F 45 C2 54 FD E6 8B
• SHA256 Fingerprint—45 14 0B 32 47 EB 9C C8
C5 B4 F0 D7 B5 30 91 F7 32 92 08 9E 6E
5A 63 E2 74 9D D3 AC A9 19 8E DA
GoDaddy Class 2 Root • SHA1 Fingerprint—27 96 BA E6 3F 18 01 E2 77

Cerficaon Authority Cerficate 26 1B A0 D7 77 70 02 8F 20 EE E4
• SHA256 Fingerprint—C3 84 6B F2 4B 9E 93 CA
64 27 4C 0E C6 7C 1E CC 5E 02 4F FC AC
D2 D7 40 19 35 0E 81 FE 54 6A E4
R1 GlobalSign Root Cerficate • SHA1 Fingerprint—b1 bc 96 8b d4 f4 9d 62 2a

(Google) a8 9a 81 f2 15 01 52 a4 1d 82 9c
• SHA256 Fingerprint—eb d4 10 40 e4 3e c7 c9
e3 81 d3 1e f2 a4 1a 48 b6 68 5c 96 e7
ce f3 c1 df 6c d4 33 1c 99
For the Cortex XDR agent 5.X release installed

on endpoints running a Windows version that
does not support SHA256 by default, you must
install KB2868626 to establish a connecon
between Cortex XDR and the agent. This
applies to Windows Server 2003 R2 (32-bit)
(SP2 & later), Windows Server 2003 (32-bit)
(SP2 & later), Windows XP (32-bit) (SP3 &
later), Windows Server 2008 (all edions; FIPS
Mode), and Windows Vista (SP1 & later; FIPS
Mode).
STEP 4 | (Windows only) Enable access for Windows CRL checks.

(Endpoints running the following or later releases: Traps 6.0.3, Traps 6.1.1, and Cortex XDR
7.0 and later) When the Cortex XDR agent examines portable executables (PEs) running on
the endpoint as part of the enforced Malware Security Profile, the agent performs a cerficate
revocaon (CRL) check. The CRL check ensures that the cerficate used to sign a given PE is
sll considered valid by its Cerficate Authority (CA), and has not been revoked. To validate the
cerficate, the Cortex XDR agent leverages Microso Windows APIs and triggers the operang
system to fetch the specific Cerficate Revocaon List (CRL) from the internet. To complete
the cerficate revocaon check, the endpoint needs HTTP access to a dynamic list of URLs,
based on the PEs that are executed or scanned on the endpoint.
1. If a system-wide proxy is defined for the endpoint (stacally or using a PAC file), Microso
Windows downloads the CRL lists through the proxy.
2. If a specific proxy is defined for the Cortex XDR agent, and the endpoint has no access to
the internet over HTTP, then Microso Windows will fail to download the CRL lists. As a
result, the cerficate revocaon check will fail and the cerficate will be considered valid by
the agent, while creang a latency in execung PEs. If the Cortex XDR agent is running in
an isolated environment that prohibits the successful compleon of cerficate revocaon
checks, the Palo Alto Networks Support team can provide a configuraon file that will
disable the revocaon checks and avoid unnecessary latency in the execuon me of PEs.
STEP 5 | (Supported on Cortex XDR agent 7.0 or a later for Windows endpoints and Cortex XDR
agent 7.3 or later for Mac and Linux endpoints) Enable peer-to-peer (P2) content updates.
By default, the Cortex XDR agent retrieves content updates from its peer Cortex XDR agents
on the same subnet. To enable P2P, you must enable UDP and TCP over port 33221. You can
change the port number or choose to download the content directly from the Cortex XDR
sever in the Agent sengs profile.
STEP 6 | Verify that you can access your Cortex XDR tenant.
Aer you download and install the Cortex XDR agent soware on your endpoints and
configure your endpoint security policy, verify that the Cortex XDR agents can check in with
Cortex XDR to receive the endpoint policy.
STEP 7 | If you use SSL decrypon and experience difficulty in connecng the Cortex XDR agent
to the server, we recommend that you add the FQDNs required for access to your SSL
Decrypon Exclusion list.
In PAN-OS 8.0 and later releases, you can configure the list in Device > Cerficate
Management > SSL Decrypon Exclusion.
Resources Required to Enable Access to Cortex XDR

To Enable Access to Cortex XDR 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 locaon in which IP addresses
are used. All customer data is stored in your deployment region, regardless of the IP
address registraon and restricts data transmission through any infrastructure to that
region. For consideraons, see Plan Your Cortex XDR Deployment.
Throughout this topic, <xdr-tenant> refers to the chosen subdomain of your Cortex
XDR tenant and <region> is the region in which your Cortex Data Lake is deployed (see
Plan Your Cortex XDR Deployment for supported regions).
Refer to the following tables for the FQDNs, IP addresses, ports, and App-ID coverage for your
deployment.
• See Required Resources by Region Table
• Required Resources for Federal (United States - Government)
For IP address ranges in GCP, refer to the following tables for IP address coverage for your
deployment:
• hps://www.gstac.com/ipranges/goog.json—Refer to this list to look up and allow access to
the IP address ranges subnets.
• hps://www.gstac.com/ipranges/cloud.json—Refer to this list to look up and allow access to
the IP address ranges associated with your region.
Table 15: Required Resources by Region
FQDN IP Addresses and Port App-ID Coverage
<xdr- IP address by region. cortex-xdr

tenant>.xdr.<region>.paloaltonetworks.com
• US—35.244.250.18
Used to connect to the Cortex • EU— 35.227.237.180
XDR management console.
• CA—34.120.31.199
• UK— 34.120.87.77
• JP—35.241.28.254
• SG— 34.117.211.129
• AU—34.120.229.65
• DE—34.98.68.183
• IN—35.186.207.80
Port—443
distributions.traps.paloaltonetworks.com
• IP address—35.223.6.69 traps-management-
• Port—443 service
Used for the first request in
registraon flow where the
agent passes the distribuon
id and obtains the ch-<xdr-
tenant>.traps.paloaltonetworks.com
of its tenant
wss:// IP address by region. cortex-xdr

lrc-<region>.paloaltonetworks.com
• US—35.190.88.43
Used in live terminal flow. • EU—35.244.251.25
• CA—35.203.99.74
• UK—35.242.159.176
• JP—34.84.201.32

• SG—34.87.61.186
• AU—35.244.66.177
• DE—34.107.61.141
• IN—35.200.146.253
Port—443
panw-xdr-installers-prod- • IP ranges in GCP cortex-xdr

us.storage.googleapis.com • Port—443
Used to download installers for
upgrade acons from the server.
This storage bucket is used for all
regions.
panw-xdr-payloads-prod- • IP ranges in GCP cortex-xdr

us.storage.googleapis.com • Port—443
Used to download the executable
for live terminal for Cortex XDR
agents earlier than version 7.1.0.
This storage bucket is used for all
regions.
global-content-profiles- • IP ranges in GCP cortex-xdr

policy.storage.googleapis.com
• Port—443
Used to download content
updates.
panw-xdr-evr- • IP ranges in GCP cortex-xdr

prod-<region>.storage.googleapis.com
• Port—443
Used to download extended
verdict request results in scanning.
dc-<xdr- IP address by region. traps-management-

tenant>.traps.paloaltonetworks.com service
• US—34.98.77.231
Used for EDR data upload. • EU—34.102.140.103
• CA—34.96.120.25
• UK—35.244.133.254
• JP—34.95.66.187
• SG—34.120.142.18
• AU—34.102.237.151
• DE—34.107.161.143

• IN—34.120.213.187
Port—443
ch-<xdr- IP address by region. traps-management-

• US—34.98.77.231
Used for all other requests • EU—34.102.140.103
between the agent and its tenant
server including heartbeat, • CA— 34.96.120.25
uploads, acon results, and scan • UK—35.244.133.254
reports.
• JP—34.95.66.187
• SG—34.120.142.18
• AU—34.102.237.151
• DE—34.107.161.143
• IN—34.120.213.188
Port—443
api-<xdr- IP address by region. —

• US—35.222.81.194
Used for API requests and • EU— 34.90.67.58
responses.
• CA—35.203.82.121
• UK— 34.89.56.78
• JP—34.84.125.129
• SG—34.87.83.144
• AU—35.189.18.208
• DE—34.107.57.23
• IN—35.200.158.164
Port—443
cc-<xdr- IP address by region. traps-management-

• US—35.224.140.142
Used for get-verdict requests. • EU—34.90.71.103
• CA—35.203.35.23
• UK—34.89.42.214
• JP—34.84.225.105
• SG—35.247.161.94
• AU—35.201.23.188
• DE—34.90.71.103

• IN—35.244.57.196
Port—443
Broker VM Resources
Required for deployments that use Broker VM features
br-<xdr- IP address by region. —

• US—104.155.131.72
• EU— 34.91.128.226
• CA— 34.95.8.232
• UK—35.197.219.110
• JP— 34.85.74.43
• SG—34.87.167.125
• AU—35.244.93.0
• DE—35.198.112.13
• IN—35.200.234.99
Port—443
• time.google.com UDP port—123 —

• pool.ntp.org
App Login and Authencaon
identy.paloaltonetworks.com • IP address— —
34.107.215.35
(SSO)
• Port—443
login.paloaltonetworks.com • IP address— —
34.107.190.184
(SSO)
• Port—443
In-App Help Center and Noficaons
data.pendo.io Port—443 —
pendo- Port—443 —
stac-5664029141630976.storage.googleapis.com
Email Noficaons
— IP address by region. —
• US— 67.231.148.124
• EU—67.231.156.123
To Collect 3rd Party Data from Customer's SaaS and Cloud resources
— IP address by region. cortex-xdr

• US
• 34.66.69.154
• 35.202.21.123
• AU
• 35.197.181.108
• 35.197.175.44
• CA
• 34.95.33.72
• 34.95.62.136
• SG
• 35.247.148.38
• 35.247.173.40
• JP
• 34.85.68.167
• 34.84.99.239
• IN
• 34.93.3.196
• 34.93.175.218
• DE
• 34.89.197.46
• 34.107.3.224
• UK
• 34.105.227.146
• 34.105.137.22

• EU
• 34.90.70.107
• 35.204.129.196
Log Forwarding to a Syslog Receiver
See Integrate a Syslog Receiver. — —
Table 16: Required Resources for Federal (United States - Government)
distributions-prod- • IP address— traps-management-

104.198.132.24
fed.traps.paloaltonetworks.com service
Used for the first request in • Port—443
ID and obtains the ch-<xdr-
of its tenant
wss://lrc- • IP address— cortex-xdr

fed.paloaltonetworks.com 35.188.188.91
Used in live terminal flow. • Port—443
panw-xdr- • IP ranges in GCP cortex-xdr

installers-prod- • Port—443
fr.storage.googleapis.com
Used to download installers for
upgrade acons from the server.
panw-xdr-payloads-prod- • IP ranges in GCP cortex-xdr

fr.storage.googleapis.com • Port—443
Used to download the
executable for live terminal for
Cortex XDR agents earlier than
version 7.1.0.
global-content- • IP ranges in GCP cortex-xdr

profiles-policy-prod- • Port—443
updates.
panw-xdr-evr-prod- • IP ranges in GCP cortex-xdr

fr.storage.googleapis.com • Port—443
Used to download extended
verdict request results in
scanning.
app- • IP address— —
104.155.148.118
proxy.federal.paloaltonetworks.com
• Port—443
dc-<xdr- • IP address— traps-management-

130.211.195.231
Used for EDR data upload. • Port—443
ch-<xdr- • IP address— traps-management-

130.211.195.231
Used for all other requests • Port—443
between the agent and
its tenant server including
heartbeat, uploads, acon
results, and scan reports.
api-<xdr- • IP address— —
130.211.195.231
tenant>.xdr.federal.paloaltonetworks.com
Used for API requests and • Port—443
responses.
cc-<xdr- • IP address—35.222.50.74 traps-management-

Used for get-verdict requests.
Broker VM Resources
Required for deployments that use Broker VM features
br-<xdr- • IP address—34.71.185.11 —
tenant>.xdr.federal.paloaltonetworks.com:443
• Port—443
distributions-prod- • IP address— traps-management-

104.198.132.24
fed.traps.paloaltonetworks.com service
• Port—443
• time.google.com UDP port—123 —

• pool.ntp.org
App Login and Authencaon
identy.paloaltonetworks.com • IP address— —
34.107.215.35
(SSO)
• Port—443
login.paloaltonetworks.com • IP address— —
34.107.190.184
(SSO)
• Port—443
In-App Help Center and Noficaons
data.pendo.io Port—443 —
pendo- Port—443 —
stac-5664029141630976.storage.googleapis.com
To Collect 3rd Party Data from Customer's SaaS and Cloud resources
— IP addresses cortex-xdr
• 34.68.217.16
• 34.69.175.202
See Integrate a Syslog Receiver.
Proxy Communicaon
You can configure communicaon through proxy servers between the Cortex XDR server and the
Cortex XDR agents running on Windows, Mac, and Linux endpoints. The Cortex XDR agent uses
the proxy sengs defined as part of the Internet & Network sengs or WPAD protocol on the
endpoint. You can also configure a list of proxy servers that your Cortex XDR agent will use to
communicate the with Cortex XDR server.
Cortex XDR supports the following types of proxy configuraons:
• System-wide proxy—Use system-wide proxy to send all communicaon on the endpoint
including to and from the Cortex XDR agent through a proxy server configured for the
endpoint. Cortex XDR supports proxy communicaon for proxy sengs defined explicitly on
the endpoint, as well as proxy sengs configured in a proxy auto-config (PAC) file.
• Applicaon-specific proxy—(Available with Traps agent 5.0.9, Traps agent 6.1.2, and Cortex
XDR agent 7.0 and later releases) Configure a Cortex XDR specific proxy that applies only to
the Cortex XDR agent and does not enforce proxy communicaons with other apps or services
on your endpoint. You can set up to five proxy servers either during the Cortex XDR agent
installaon process, or following agent installaon, directly from the Cortex XDR management
console.
If the endpoints in your environment are not connected directly to the internet, you can deploy
a Palo Alto Networks broker VM.
Applicaon-specific proxy configuraons take precedence over system-wide proxy configuraons.
The Cortex XDR agent retrieves the proxy list defined on the endpoint and tries to establish
communicaon with the Cortex XDR server first through app-specific proxies. Then, if
communicaon is unsuccessful, the agent tries to connect using the system-wide proxy, if defined.
If none are defined, the Cortex XDR agent aempts communicaon with the Cortex XDR server
directly. The Cortex XDR agent does not support proxy communicaon in environments where
proxy authencaon is required.
Configure Your Network Devices

With a Cortex XDR Pro per TB license, if you use Palo Alto Networks firewalls as a traffic log
source, you must configure your firewalls and Panorama log forwarding to Cortex Data Lake.
Ensure you have first deployed your network devices.
STEP 1 | Onboard Panorama-Managed Firewalls to Cortex Data Lake.
STEP 2 | Configure firewalls to forward Cortex XDR-required logs to Cortex Data Lake.
The Cortex Data Lake provides centralized, cloud-based log storage for firewalls, and Panorama
provides an interface you can use to view the stored logs. The rich log data that firewalls
forward to the Cortex Data Lake provides the Cortex XDR analycs engine the network
visibility it requires to perform data analycs.
To support Cortex XDR, firewalls must forward at least Traffic logs to the Cortex Data Lake.
The complete set of log types that a firewall should forward to the Cortex Data Lake are:
Traffic (required)
Threat (spyware, an-exploit, an-malware, dns security, etc)
URL Filtering
User-ID
HIP
Enhanced applicaon logs (PAN-OS 8.1.1 or later)
Enhanced applicaon logs are designed to increase visibility into network acvity for Palo Alto
Networks Cloud Services apps, and Cortex XDR requires these logs to support certain features.
Follow the complete workflow to configure Panorama-managed firewalls to forward logs to the
Cortex Data Lake.
Set up Network Analysis

With a Cortex XDR Pro per TB license you must set up your network sensors and define network
coverage for your internal networks.
STEP 1 | Set up your network sensors.
1. If you use unmanaged Palo Alto Networks firewalls, and did not configure log-forwarding
on your firewalls before acvang Cortex XDR, Start Sending Logs to Cortex Data Lake.
2. (Oponal) Set up External Data Ingeson.
If you have external (non-Palo Alto Networks) network sensors, you can set up a syslog
collector to receive alerts or logs from them. If you send external alerts, Cortex XDR
can include any them in relevant incidents for a more complete picture of the acvity
involved. If you send logs and alerts from external sources such as Check Point firewalls,
Cortex XDR can apply analycs analysis and raise analycs alerts on the external logs
and include the external alerts in incidents for addional context.
3. (Oponal) If you use a third-party authencaon service, you can Ingest Authencaon
Logs and Data into authencaon stories. Aer you set up log collecon, you can search
for authencaon data using the Query Builder.
4. (Oponal) If you want to use Pathfinder to examine unmanaged network hosts, servers,
and workstaons for malicious or risky soware, Acvate Pathfinder™.
STEP 2 | Configure the internal networks that you want Cortex XDR to monitor.
1. From the Cortex XDR management console, navigate to Assets > Network Configuraon.
2. Define your IP Address Ranges.
This page provides a table of the IP address ranges Cortex XDR Analycs monitors, which is
pre-populated with the default IPv4 and IPv6 address spaces.
3. Define your Domain Names.
STEP 3 | If you use GlobalProtect or Prisma Access, add the GlobalProtect VPN IP address pool for the
VPN traffic that you want to monitor.
1. To enable the Cortex XDR app to analyze your VPN traffic, add (+) a new segment and
specify the first and last IP address of your GlobalProtect VPN IP address pool.
2. Idenfy this network segment as Reserved for VPN. GlobalProtect dynamically assigns
IP addresses from the IP pool to the mobile endpoints that connect to your network. The
Cortex XDR analycs engine creates virtual enty profiles for network segments that are
reserved for VPN.
3. Save ( ) the network segment. If the Configuraon saved noficaon does not appear,
save again.
STEP 4 | If you selected a Cloud Identy Engine (Directory Sync instance) during the Cortex XDR
acvaon process, Set Up Cloud Identy Engine.
Configure Cortex XDR

Before you can begin using Cortex XDR, you must set up your alert sensors. The more sensors
that you integrate with Cortex XDR, the more context you have when a threat is detected.
You can also set up Cortex to raise Analycs alerts on network or endpoint data (or both)
depending or your Cortex XDR Pro licenses.
The following workflow highlights the tasks that you must perform (in order) to configure Cortex
XDR.
STEP 1 | Integrate External Threat Intelligence Services.
Integrang external threat intelligence services enables you to view feeds from sources such as
AutoFocus and VirusTotal in the context of your incident invesgaon.
STEP 2 | Aer you acvate Cortex XDR apps and services, wait 24 hours and then configure the
Cortex XDR analycs.
1. Specify the internal networks that you want Cortex XDR to monitor.
2. (Recommended) If you want to use Pathfinder to scan unmanaged endpoints, Acvate
Pathfinder.
3. Enable Cortex XDR - Analycs.
By default, Cortex XDR - Analycs is disabled. Acvang Cortex XDR - Analycs enables
the Cortex XDR analycs engine to analyze your endpoint data to develop a baseline and
raise Analycs and Analycs BIOC alerts when anomalies and malicious behaviors are
detected.
To create a baseline for enabling Analycs, Cortex XDR requires a minimum set of data;
EDR or Network logs from at least 30 endpoints over a minimum of 2 weeks or cloud
audit logs over a minimum of 5 days. Once this requirement is met, Cortex XDR allows to
enable analycs and begin triggering alerts within a few hours.
1. In Cortex XDR, select Sengs > Configuraons > Cortex XDR - Analycs.
The Enable opon will be grayed out if you do not have the required data set.
2. When available, Enable Cortex XDR - Analycs. The analycs engine will immediately
begin analyzing your Cortex data for anomalies.
Creang a baseline can take up to 3 hours.
4. Enable Identy Analycs.

By default, Identy Analycs is disabled. Acvang Identy Analycs enables the Cortex
XDR analycs engine to aggregate and display throughout your invesgaon user profile
informaon, acvity, and alerts associated with a user-based Analycs type alert and
Analycs BIOC rule.
To enable the Identy Analycs, you must first Acvate the Cortex XDR Analycs and
Set Up Cloud Identy Engine (Formally Directory Sync Services (DSS)).
Aer configuring your Cloud Identy Engine instance and Cortex XDR Analycs, Enable
Identy Analycs.
STEP 3 | Add an Alert Exclusion Policy.
STEP 4 | Manage Incident Starring.
STEP 5 | (Oponal) Palo Alto Networks also automacally delivers behavioral indicators of
compromise (BIOCs) rules defined by the Palo Alto Networks threat research team to all
Cortex XDR tenants, but you can also import any addional indicators as rules, as needed.
To alert on specific BIOCs, Create a BIOC Rule. To immediately alert on known malicious
indicators of compromise (IOCs)—such as known malicious IP addresses—Create an IOC Rule
or Create a Correlaon Rule.
Integrate External Threat Intelligence Services

To aid you with threat invesgaon, Cortex XDR displays the WildFire-issued verdict for each Key
Arfact in an incident. To provide addional verificaon sources, you can integrate an external
threat intelligence service with Cortex XDR. The threat intelligence services the app supports are:
• AutoFocus™—AutoFocus groups condions and indicators related to a threat with a tag. Tags
can be user-defined or come from threat-research team publicaons and are divided into
classes, such as exploit, malware family, and malicious behavior. When you add the service, the
relevant tags display in the incident details page under Key Arfacts. Without an AutoFocus
license key, you can sll pivot from Cortex XDR to the service to iniate a query for the
arfact. See the AutoFocus Administrator’s Guide for more informaon on AutoFocus tags.
• VirusTotal—VirusTotal provides aggregated results from over 70 anvirus scanners, domain
services included in the block list, and user contribuons. The VirusTotal score is represented as
a fracon, where, for example, a score of 34/52 means out of 52 queried services, 34 services
determined the arfact to be malicious. When you add the service, the relevant VirusTotal
score displays in the incident details page under Key Arfacts. Without a VirusTotal license key,
you can sll pivot from Cortex XDR to the service to iniate a query for the arfact.
• WildFire®—WildFire detects known and unknown threats, such as malware. The WildFire
verdict contains detailed insights into the behavior of idenfied threats. The WildFire verdict
displays next to relevant Key Arfacts in the incidents details page, the causality view, and
within the Live Terminal view of processes.
WildFire provides verdicts and analysis reports to Cortex XDR users without requiring a
license key. Using WildFire for next-generaon firewalls or other use-cases connues to
require an acve license.
Before you can view external threat intelligence in Cortex XDR incidents, you must obtain the
license key for the service and add it to the Cortex XDR Configuraon. Aer you integrate any
services, you will see the verdict or verdict score when you invesgate the incident..
To integrate an external threat intelligence service:
STEP 1 | Get your the API License Key for the service.
• Get your AutoFocus API key.
• Get your VirusTotal API key.
STEP 2 | Enter the license key in the Cortex XDR app.

Select Sengs > Configuraons > Integraons > Threat Intelligence and then enter the
license key.
STEP 3 | Test your license key.

Select Test. If there is an issue, an error message provides more details.
STEP 4 | Verify the service integraon in an incident.

Aer adding the license key, you should see the addional verdict informaon from the service
included in the Key Arfacts of an incident. You can right-click the service, such as VirusTotal
(VT) or AutoFocus (AF), to see the enre verdict. See Manage Incidents for more informaon
on where these services are used within the Cortex XDR app.
Set up Your Cortex Environment

To create a more personalized user experience, Cortex XDR enables you to define your Server and
Security Sengs.
From the Cortex XDR management console, navigate to Sengs > Configuraons > General >
Server Sengs to define the following:
• Keyboard Shortcuts
• User Timezone
• Timestamp Format
• Distribuon List Emails
• XQL Configuraon Sengs
• Define Incident Mean Time to Resolve (MTTR)
• Impersonaon Role
• Session Security Sessions
Define Keyboard Shortcuts

Select the keyboard shortcut for the Cortex XDR capabilies.
In the Keyboard Shortcuts secon, change the default sengs for:

• Arfact and Asset Views
• Quick Launcher
The shortcut value must be a keyboard leer, A through Z, and cannot be the same for both
shortcuts.
Select Timezone
Select your own specific mezone. Selecng a mezone affects the mestamps displayed in the
Cortex XDR management console, auding logs, and when exporng files.
In the Timezone secon, select the mezone in which you want to display your Cortex XDR
data.
Define Timestamp Format

Select your mestamp format. Selecng a mezone affects the mestamps displayed in the
Cortex XDR management console, auding logs, and when exporng files.
In the Timestamp Format secon, select the mestamp format in which you want to display
your Cortex XDR data.
The seng is configured per user and not per tenant.
Define Distribuon List Emails

Define a list of email addresses Cortex XDR can use as distribuon lists. The defined email
addresses are used to send product maintenance, updates, and new version noficaons. The
email addresses are in addion to e-mails registered with your CSP account.
In the Email Contacts secon, enter email addresses you want to include in a distribuon list.
Make sure to select aer each email address.
Define XQL Configuraon Sengs

The XQL Configuraon sengs control your XQL queries in the system. To make it easier for you
to configure Case Sensivity across Cortex XDR in one central area, you can configure whether
Case Sensivity (config case_sensive = true | false) is applied throughout the applicaon. This
seng overwrites any other default configuraon except for BIOCs, which will remain case
insensive no maer what this configuraon is set to.
In the XQL Configuraon secon, you can either leave the toggle set to Case Sensivity
(case_sensive) to ensure field values are evaluated as case sensive (config
case_sensitive = true) throughout the enre applicaon (default) or disable the toggle,
so that field values are evaluated as case insensive (config case_sensitive = false)
throughout the applicaon.
This seng overwrites any other default configuraon except for BIOCs, which will
remain case insensive no maer what this configuraon is set to.
Define Incident Mean Time to Resolve (MTTR)

Define the target incident MTTR you want applied according to the incident severity.
In the Define the Incident target MTTR per incident severity secon, enter within how many
days and hours you want incidents resolved according to the incident severity Crical, High,
Medium, and Low.
The defined MTTR is used to display the Resolved Incident MTTR dashboard widgets.
Define the Impersonaon Role

Define the type of role permissions granted to Palo Alto Networks Support team when opening
support ckets. By default, Palo Alto Networks Support is granted read-only access to your
tenant.
In the Impersonaon Sengs secon, define the level and duraon of the permissions.
• Select one of the following Role permissions:
• Read-Only—Default seng, grants read only access to your tenant.
• Support related acons—Grants permissions to tech support file collecon, dump file
collecon, invesgaon query, Correlaon Rule, BIOC and IOC rule eding, alert starring,
exclusion and excepon eding.
• Full role permissions—No limitaons are applied, grants full permissions to all acons and
content on your tenant.
• Set the Permission Reset Timeframe.
If you selected Support related acons or Full role permissions in the Role field, set a
specific meframe for how long these permissions are valid. Select either 7 Days, 30 Days,
or No me limitaon.
We recommend that Role permissions are granted only for a specific meframe, and full
administrave permissions is granted only when specifically requested by the support team.
Set up Session Security Sengs

The session security sengs include:
• Session Expiraon—Enables you to define the number of hours aer which the user login
session will expire. You can also define a one-week expiraon me for the Cortex XDR
dashboard.
• Allowed Sessions—Enables you to define approved domains and approved IP ranges through
which access to Cortex XDR should be allowed.
• User Expiraon—Enables you to deacvate an inacve user, and also set the user deacvaon
trigger period.
• Allowed Domains—Enables you to specify one or more domain names that can be used in your
distribuon lists.
From the Cortex XDR management console, select Sengs > Configuraons > Security
Sengs.
Under Session Expiraon, define the following:

1. User Login Expiraon—Select the amount of session hours aer which the user login
should expire.
2. Dashboard Expiraon—Select either 7 Days or As user login expiraon (1 hour) to define
the ming of the dashboard expiraon.
Under Allowed Sessions, define the following:

1. Approved Domains—Select Enabled or Disabled. If enabled, specify the domains from
which you want to allow user access to Cortex XDR. You can add or remove domains as
necessary.
2. Approved IP Ranges—Select Enabled or Disabled. If enabled, specify the IP ranges from
which you want to allow user access to Cortex XDR. You can add or remove IP CIDR
addresses as necessary.
Under User Expiraon, define if you want to Deacvate Inacve User. By default, user
expiraon is Disabled, when Enabled enter the number of days aer which inacve users
should be deacvated.
Under Allowed Domains, specify one or more domain names that users in your organizaon
can be used in your distribuon list. For example, when generang a report, ensure the reports
are not sent to email addresses outside your organizaon.
Save.
Set up Outbound Integraon

You can set up any of the following oponal outbound integraons:
• Integrate Slack for Outbound Noficaons
• Integrate a Syslog Receiver
• Integrate with Cortex XSOAR—Send alerts to Cortex XSOAR for automated and coordinated
threat response. From Cortex XSOAR, you define, adjust, and test playbooks that respond to
Cortex XDR alerts. You can also manage your incidents in Cortex XSOAR with any changes
automacally synced to Cortex XDR. For more informaon, see the in-app documentaon in
Cortex XSOAR.
• Integrate with external receivers such as ckeng systems—To manage incidents from the
applicaon of your choice, you can use the Cortex XDR API Reference to send alerts and
alert details to an external receiver. Aer you generate your API key and set up the API to
query Cortex XDR, external apps can receive incident updates, request addional data about
incidents, and make changes such as to set the status and change the severity, or assign an
owner. To get started, see the Cortex XDR API Reference.
Use the Interface

Cortex XDR provides an easy-to-use interface that you can access from the hub. By default,
Cortex XDR displays the Incident Management Dashboard when you log in. If desired, you can
change the default dashboard or Build a Custom Dashboard that displays when you log in.
Each SAML login session is valid for 8 hours.
Depending on your license and assigned role, you can explore the following areas in the app.
Interface Descripon
Dashboard & Reports From the Dashboard & Reports menu you can view
and manage your dashboards and reports from
the dashboard and incidents table, and view alert
exclusions.
• Dashboard—Provides dashboards that you can use
to view high-level stascs about your agents and
incidents.
• Reports—View all the reports that Cortex XDR
administrators have run.
• Customize—Create and manage new dashboard and
reports.
• Dashboards Manager—Add new dashboards with
customized widgets to surface the stascs that
maer to you most.
• Reports Templates—Build reports using pre-
defined templates, or customize a report. Reports
can generated on- demand scheduled.
• Widget Library—Search, view, edit, and create
widgets based on predefined widgets and user-
created custom widgets.
Incident Response From the Incident Response menu you can view,
manage, invesgate and take acon on all incidents.
• Incidents—Invesgate and manage your incidents.
• Invesgaon
• Query Builder—Build complex queries to
invesgate, idenfy connecons, and expose the
root cause of alerts from your data sources.
• Query Center—View and manage the results of
all simple and complex queries created from the
Query Builder.
• Scheduled Queries—View and manage all
scheduled and reoccurring queries created from
the Query Builder.
• Forensics—Streamline your incident response,
data collecon, threat hunng, and analyses of
you endpoint data to find the source and scope
of an aack.
• Host Inventory—
• Response
• Acon Center—Provides a central locaon
from which you can track the progress of all
invesgaon, response, and maintenance acons
performed on your endpoints.
• Live Terminal—Iniate a remote connecon to
an endpoint enabling you to remotely manage,
invesgate, and perform response acons on the
endpoint.
• EDL—Add malicious domains and IP addresses to
an external dynamic list enforceable on your Palo
Alto Networks firewall.
• Incident Configuraon—Create a starring
configuraon that automacally categorizes and
starts incidents when a related alert contains
specific aributes that you define as important.
Detecon From the Detecon menu, you can define specific rules
for which you want Cortex XDR to raise alerts.
• Detecon Rules
• IOC—Idenfy specific hashes, IP addresses,
domains, file names and paths that indicates a
threat.
• BIOC—Idenfy specific network, process, file, or
registry acvity that indicates a threat.
• Correlaons—Analyze correlaons of mul-
events from mulple sources.
• Excepons—Define excepon criteria for a IOC
or BIOC rule.
Assets From the Assets menu, you can define your network
parameters and view a list of all the assets in your
network.
• Network Configuraon—Define your internal IP
address ranges and domain names to idenfy and
track your network assets.
• Vulnerability Assessment—Idenfy and quanfy the
security vulnerabilies on an endpoint.
• User Scores—Invesgate user acvies and detect
compromised accounts and malicious devices using
the Cortex XDR calculated User Score.
• Asset Inventory—Provides a central locaon from
which you can view and invesgate informaon
relang to assets in your network.
• Cloud Inventory—Provides a unified, normalized
asset inventory for cloud assets in Google Cloud
Plaorm, Microso Azure, and Amazon Web
Services.
Endpoints From the Endpoints menu, you can manage your

registered endpoints and configure policy.
• All Endpoints—View and manage endpoints that
have registered with your Cortex XDR instance.
• Endpoint Groups—Create endpoint groups to which
you can perform acons and assign policy.
• Agent Installaons—Create packages of the Cortex
XDR agent soware for deployment to your
endpoints.
• Policy Management—Configure your endpoint
security profiles and assign them to your endpoints.
• Host Firewall—Control communicaons on your
endpoints by applying sets of rules that allow or
block internal and external traffic.
• Device Control Violaons—Monitor all instances
where end users aempted to connect restricted
USB-connected devices and Cortex XDR blocked
them on the endpoint.
• Disk Encrypon Visibility—View and manage
endpoints that were encrypted using BitLocker.
Managed Services The Managed Threat Hunng service augments your

security by providing 24/7, year-round monitoring by
Palo Alto Networks threat researchers and Unit 42
experts.
Quick Launcher Open an in-context shortcut that you can use to search
for informaon, perform common invesgaon tasks,
or iniate response acons from any place in the
Cortex XDR console.
Sengs From the Sengs menu, you can view informaon

about your Cortex XDR license, review logs of acons
iniated by Cortex XDR analysts, and configure
Cortex XDR sengs, integraons with other apps and
services, and access management.
Tenant Navigator View and switch to tenants to which you have access
to, divided per CSP account. You can also navigate
directly to the Cortex Gateway.
Noficaons View Cortex Cortex XDR noficaons.
User From the User, see who is logged into Cortex Cortex
XDR. Right click and select:
• About to view addional version and tenant ID
informaon.
• What’s New to view selected new features available
for your license type.
• Log Out to terminate connecon with your Cortex
XDR Management Console.
The following topics describe addional management acons you can perform on page results.
• Filter Page Results
• Save and Share Filters
• Show or Hide Results

• Manage Columns and Rows
Manage Tables
Most pages in Cortex XDR present data in table format and provide controls to help you manage
and filter the results. If addional views or acons are available for a specific value, you can pivot
(right-click) from the value in the table. For example, you can view the incident details, or pivot to
the Causality View for an alert or you can pivot to the results for a query.
On most pages, you can also refresh ( ) the content on the page.
To manage tables in the app:
• Filter Page Results
• Export Results to File
• Save and Share Filters
• Show or Hide Results
• Manage Columns and Rows
• Display Quick Acons
Filter Page Results

To reduce the number of results, you can filter by any heading and value. When you apply a
filter, Cortex XDR displays the filter criteria above the results table. You can also filter individual
columns for specific values using the icon to the right of the column heading.
Some fields also support addional operators such as =, !=, Contains, not Contains, *, !*.
There are three ways you can filter results:
• By column using the filter next to a field heading
• By building a filter query for one or more fields using the filter builder
• By pivong from the contents of a cell (show or hide rows containing)
Filters are persistent. When you navigate away from the page and return, any filter you added
remain acve.
To build a filter using one or more fields:
STEP 1 | From a Cortex XDR page, select filter ( ).
Cortex XDR adds the filter criteria above the top of the table.
STEP 2 | For each field you want to filter:

1. Select or search the field.
2. Select the operator by which to match the criteria.
In most cases this will be = to include results that match the value you specify, or != to
exclude results that match the value.
3. Enter a value to complete the filter criteria.
CMD fields have a 128 character limit. Shorten longer query strings to 127
characters and add an asterisk (*).
Alternavely, you can select Include empty values to create a filter that excludes or
includes results when the field has an empty values.
STEP 3 | To add addional filters, click +AND (within the filter brackets) to display results that must
match all specified criteria, or +OR to display results that match any of the criteria.
STEP 4 | Click out of the filter area into the results table to see the results.
STEP 5 | Next steps:

• If at any me you want to remove the filter, click the X next to it. To remove all filters, click
the trash icon.
• Save and Share Filters.
Export Results to File

If needed, you can export the page results for most pages in Cortex XDR to a tab separated values
(TSV) file.
STEP 1 | (Oponal) Filter Page Results to reduce the number of results for export.
STEP 2 | Select export to file ( ).

Cortex XDR exports any results matching your applied filters in TSV format. The TSV format
requires a tab separator, automac detecon does not work in case of mul-event exports.
Save and Share Filters

You can save and share filters across your organizaon.
Save a filter:
Saved filters are listed on the Filters tab for the table layout and filter manager menu.
1. Save ( ) the acve filter.
2. Enter a name to idenfy the filter.
You can create mulple filters with the same name. Saving a filter with an exisng name
will not override the exisng filter.
3. Choose whether to Share this filter or whether to keep it private for your own use only.
Share a filter:
You can share a filter across your organizaon.
1. Select the table layout and filter menu indicated by the three vercal dots, then select
Filters.
2. Select the filter to share and click the share icon.
3. If needed, you can later unshare ( ) or delete ( ) a filter.
Unsharing a filter will turn a public filter private. Deleng a shared filter will remove it for
all users.
Show or Hide Results

As an alternave to building a filter query from scratch or using the column filters, you can pivot
from rows and specific values to define the match criteria to fine tune the results in the table. You
can also pivot on empty values to show only results with empty values or only results that do not
have empty values in the column from which you pivot.
CMD fields are limited to 128 characters. If you pivot on a CMD field with a truncated
value, the app shows or hides all results that match the first 128 characters.
The show or hide acon is a temporary means of filtering the results: If you navigate away from
the page and later return, any results you previously hid will appear again.
This opon is available for fields which have a finite list of opons.
To hide or show only results that match a specific field value:
STEP 1 | Right-click the matching field value by which you want to hide or show.
STEP 2 | Select the desired acon:

• Hide rows with <field value>
• Show rows with <field value>
• Hide empty rows
• Show empty rows
Manage Columns and Rows

From Cortex XDR pages, you can manage how you want to view the results table and what
informaon you want Cortex XDR app to display.
• Adjust the row height and column width
• Add or Remove fields in the table
• Configure the order of the columns
Any adjustments you make to the columns or rows persist when you navigate away from and later
return to the page.
Adjust the row height and column width:

1. On the Cortex XDR page select the menu indicated by three vercal dots to the right of
the filter buon.
2. In View Configuraon, select the desired:
• Row height ranging from short to tall ( ).
• Column width ranging from narrow, fixed width, or scaled to the column heading ( ).
Add or remove fields in the table:

1. On an Cortex XDR page, select the menu indicated by three vercal dots to the right of
the filter buon.
2. Below the column manager, search for a column by name, or select the fields you want to
add or clear any fields you want to hide.
Cortex XDR adds or removes the fields to the table as you select or clear the fields.
3. If desired, drag and drop the fields to change the order in which they appear in the table.
Configure the order of the columns:

Define the order in which you want to display the field columns using the column index
number. The column index number is the relave column number displayed in the table.
1. On the Cortex XDR page, select the number ( ) assigned to field name you want to
change.
2. Enter the relave column number you want the field displayed in the table. The number
you enter should not be greater that the number of columns.
Field names that are locked ( ) cannot be moved.
Display Quick Acons

From the Cortex XDR tables, you can quickly iniate acons using icons available in the table
rows. Depending on the table, the icons provide a quick alternave to the corresponding right-
click pivot menus.
Navigate to a Cortex XDR table throughout the Cortex XDR app.
Hover over a table row to display the available acons.
Endpoint Security
Endpoint security features require a Cortex XDR Pro - Endpoint license.
> Endpoint Security Concepts

> Manage Cortex XDR Agents
> Define Endpoint Groups
> About Content Updates
> Endpoint Security Profiles
> Customizable Agent Sengs
> Apply Security Profiles to Endpoints
> Excepons Security Profiles
> Hardened Endpoint Security
155
Endpoint Security
Endpoint Security Concepts

• Cortex XDR versus Tradional Endpoint Protecon
• File Analysis and Protecon Flow
• Endpoint Protecon Capabilies
• Endpoint Protecon Modules
Cortex XDR versus Tradional Endpoint Protecon

Cyberaacks target endpoints to inflict damage, steal informaon, or achieve other goals that
involve taking control of computer systems that do not belong to the aackers. These adversaries
perpetrate cyberaacks either by causing a user to unintenonally run a malicious executable
file, known as malware, or by exploing a weakness in a legimate executable file to run malicious
code behind the scenes without the knowledge of the user.
One way to prevent these aacks is to idenfy executable files, dynamic-link libraries (DLLs),
and other pieces of code to determine if they are malicious and, if so, to prevent the execuon
of these components by first matching each potenally dangerous code module against a list of
specific, known threat signatures. The weakness of this method is that it is me-consuming for
signature-based anvirus (AV) soluons to idenfy newly created threats that are known only
to the aacker (also known as zero-day aacks or exploits) and add them to the lists of known
threats, which leaves endpoints vulnerable unl signatures are updated.
Cortex XDR takes a more efficient and effecve approach to prevenng aacks that eliminates
the need for tradional 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
aacks at their inial entry points—the point where legimate executable files are about to
unknowingly allow malicious access to the system.
Cortex XDR provides a mul-method protecon soluon with exploit protecon modules that
target soware vulnerabilies in processes that open non-executable files and malware protecon
modules that examine executable files, DLLs, and macros for malicious signatures and behavior.
Using this mul-method approach, the Cortex XDR soluon can prevent all types of aacks,
whether these are known or unknown threats.
Endpoint Security
Exploit Protecon Overview

An exploit is a sequence of commands that takes advantage of a bug or vulnerability in a soware
applicaon or process. Aackers use these exploits to access and use a system to their advantage.
To gain control of a system, the aacker must exploit a chain of vulnerabilies in the system.
Blocking any aempt to exploit a vulnerability in the chain will block the enre exploitaon
aempt.
To combat an aack in which an aacker takes advantage of a soware exploit or vulnerability,
Cortex XDR employs exploit protecon modules (EPMs). Each EPM targets a specific type of exploit
aack in the aack chain. Some capabilies that Cortex XDR EPMs provide are reconnaissance
prevenon, memory corrupon prevenon, code execuon prevenon, and kernel protecon.
Malware Protecon Overview

Malicious files, known as malware, are oen disguised as or embedded in non-malicious files.
These files can aempt to gain control, gather sensive informaon, or disrupt the normal
operaons of the system. Cortex XDR prevents malware by employing the Malware Prevenon
Engine. This approach combines several layers of protecon to prevent both known and unknown
malware that has not been seen before from causing harm to your endpoints. The migaon
techniques that the Malware Prevenon Engine employs vary by the endpoint type.
• Malware Protecon for Windows
Endpoint Security
• Malware Protecon for Mac

• Malware Protecon for Linux
• Malware Protecon for Android
Malware Protection for Windows
• WildFire integraon—Enables automac detecon of known malware and analysis of unknown
malware using WildFire threat intelligence.
• Local stac analysis—Enables Cortex XDR to use machine learning to analyze unknown files
and issue a verdict. Cortex XDR uses the verdict returned by the local analysis module unl it
receives a verdict from Cortex XDR.
• DLL file protecon—Enables Cortex XDR to block known and unknown DLLs on Windows
endpoints.
• Office file protecon—Enables Cortex XDRto block known and unknown macros when run
from Microso Office files on Windows endpoints.
• Behavioral threat protecon (Windows 7 SP1 and later versions)—Enables connuous
monitoring of endpoint acvity to idenfy and analyze chains of events—known as causality
chains. This enables Cortex XDR to detect malicious acvity that could otherwise appear
legimate if inspected as individual events. Behavioral threat protecon requires Traps agent
6.0 or a later release.
• Evaluaon of trusted signers—Permits unknown files that are signed by highly trusted signers
to run on the endpoint.
• Malware protecon modules—Targets behaviors—such as those associated with ransomware—
and enables you to block the creaon of child processes.
• Policy-based restricons—Enables you to block files from execung from within specific local
folders, network folders, or external media locaons.
• Periodic and automated scanning—Enables you to block dormant malware that has not yet
tried to execute on endpoints.
Malware Protection for Mac
malware using WildFire threat intelligence.
• Local stac analysis—Enables Cortex XDR to use machine learning to analyze unknown files
and issue a verdict. The Cortex XDR agent uses the verdict returned by the local analysis
module unl it receives the WildFire verdict from Cortex XDR.
• Behavioral threat protecon—Enables connuous monitoring of endpoint acvity to idenfy
and analyze chains of events—known as causality chains. This enables the Cortex XDR agent
to detect malicious acvity that could otherwise appear legimate if inspected as individual
events. Behavioral threat protecon requires Traps agent 6.1 or a later release.
• Mach-O file protecon—Enables you to block known malicious and unknown mach-o files on
Mac endpoints.
• DMG file protecon—Enables you to block known malicious and unknown DMG files on Mac
endpoints.
• Evaluaon of trusted signers—Permits unknown files that are signed by trusted signers to run
on the endpoint.
Endpoint Security
• Periodic and automated scanning—Enables you to block dormant malware that has not yet
tried to execute on endpoints. Scanning requires Cortex XDR agent 7.1 or a later release.
Malware Protection for Linux
malware using WildFire threat intelligence. WildFire integraon requires Traps agent 6.0 or a
later release.
• Local stac analysis—Enables the Cortex XDR agent to use machine learning to analyze
unknown files and issue a verdict. The Cortex XDR agent uses the verdict returned by the local
analysis module unl it receives the WildFire verdict from Cortex XDR. Local analysis requires
Traps agent 6.0 or a later release.
• Behavioral threat protecon—Enables connuous monitoring of endpoint acvity to idenfy
and analyze chains of events—known as causality chains. This enables Cortex XDR to detect
malicious acvity that could otherwise appear legimate if inspected as individual events.
Behavioral threat protecon requires Traps agent 6.1 or a later release.
• ELF file protecon—Enables you to block known malicious and unknown ELF files executed
on a host server or within a container on a Cortex XDR-protected endpoint. Cortex XDR
automacally suspends the file execuon unl a WildFire or local analysis verdict is obtained.
ELF file protecon requires Traps agent 6.0 or a later release.
• Malware protecon modules—Targets the execuon behavior of a file—such as those
associated with reverse shell protecon.
Malware Protection for Android
• WildFire integraon—Enables automac detecon of known malware and grayware, and
analysis of unknown APK files using WildFire threat intelligence.
• APK files examinaon—Analyze and prevent malicious APK files from running.
• Evaluaon of trusted signers—Permits unknown files that are signed by trusted signers to run
on the Android device.
File Analysis and Protecon Flow

The Cortex XDR agent ulizes advanced mul-method protecon and prevenon techniques to
protect your endpoints from both known and unknown malware and soware exploits.
Exploit Protecon for Protected Processes

In a typical aack scenario, an aacker aempts to gain control of a system by first corrupng or
bypassing memory allocaon or handlers. Using memory-corrupon techniques, such as buffer
overflows and heap corrupon, a hacker can trigger a bug in soware or exploit a vulnerability in
a process. The aacker must then manipulate a program to run code provided or specified by the
aacker while evading detecon. If the aacker gains access to the operang system, the aacker
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
aempts by employing roadblocks—or traps—at each stage of an exploitaon aempt.
Endpoint Security
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 soware.
This occurs at the earliest possible stage before any files belonging to the process are loaded
into memory. The Cortex XDR agent then acvates one or more protecon modules inside
the protected process. Each protecon module targets a specific exploitaon technique and is
designed to prevent aacks on program vulnerabilies based on memory corrupon or logic flaws.
In addion to automacally protecng processes from such aacks, the Cortex XDR agent reports
any security events to Cortex XDR and performs addional acons as defined in the endpoint
security policy. Common acons that the Cortex XDR agent performs include collecng forensic
data and nofying the user about the event.
The default endpoint security policy protects the most vulnerable and most commonly used
applicaons but you can also add other third-party and proprietary applicaons to the list of
protected processes.
Malware Protecon
The Cortex XDR agent provides malware protecon in a series of four evaluaon phases:
Phase 1: Evaluation of Child Process Protection Policy

When a user aempts to run an executable, the operang system aempts 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 protecon policy. If the parent process is a known targeted process
Endpoint Security
that aempts 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 Microso Word document (using the winword.exe process) and that 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: Evaluaon of the Restricon Policy.
Phase 2: Evaluation of the Restriction Policy
When a user or machine aempts to open an executable file, the Cortex XDR agent first evaluates
the child process protecon policy as described in Phase 1: Evaluaon of Child Process Protecon
Policy. The Cortex XDR agent next verifies that the executable file does not violate any restricon
rules. For example, you might have a restricon rule that blocks executable files launched from
network locaons. If a restricon rule applies to an executable file, the Cortex XDR agent blocks
the file from execung and reports the security event to Cortex XDR and, depending on the
configuraon of each restricon rule, the Cortex XDR agent can also nofy the user about the
prevenon event.
If no restricon rules apply to an executable file, the Cortex XDR] agent next moves to Phase 3:
Evaluaon of Hash Verdicts.
Phase 3: Hash Verdict Determination
The Cortex XDR agent calculates a unique hash using the SHA-256 algorithm for every file that
aempts to run on the endpoint. Depending on the features that you enable, the Cortex XDR
agent performs addional 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 determine a verdict for a file, the Cortex XDR agent evaluates the file in the following order:
1. Hash excepon—A hash excepon enables you to override the verdict for a specific file
without affecng the sengs in your Malware Security profile. The hash excepon 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 excepon for any of the following situaons:
• 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 aer 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.
Aer you configure a hash excepon, Cortex XDR distributes it at the next heartbeat
communicaon 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
excepon for the file. The hash excepon 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 excepon is not configured for the file, the Cortex XDR agent next evaluates the
verdict to determine the likelihood of malware. The Cortex XDRagent uses a mul-step
evaluaon process in the following order to determine the verdict: Highly trusted signers,
WildFire verdict, and then Local analysis.
Endpoint Security
2. Highly trusted signers (Windows and Mac)—The Cortex XDR agent disnguishes highly
trusted signers such as Microso 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 the allow list from Cortex XDR. When an unknown
file aempts to run, the Cortex XDR agent applies the following evaluaon criteria: Files
signed by highly trusted signers are permied 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, evaluaon of other known signers takes place if
WildFire evaluaon 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
the Cortex XDR and, depending on the configured behavior for malicious files, the Cortex XDR
agent then does one of the following:
• Blocks the malicious executable file
• Blocks and quarannes the malicious executable file
• Nofies the user about the file but sll allows the file to execute
• Logs the issue without nofying the user and allows the file to execute.
If the verdict is benign, the Cortex XDR agent moves on to the next stage of evaluaon (see
Phase 4: Evaluaon of Malware Protecon 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 aempts to run on a Windows
or Mac endpoint, the Cortex XDRagent 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 addional 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 stac
set of paern-matching rules that inspect mulple file features and aributes, and a stascal
model that was developed with machine learning on WildFire threat intelligence. The model
enables the Cortex XDR agent to examine hundreds of characteriscs 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 unl it receives an official WildFire
verdict or hash excepon.
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 sengs (not recommended), see Add a New Malware
Security Profile.
Phase 4: Evaluation of Malware Security Policy
If the prior evaluaon phases do not idenfy a file as malware, the Cortex XDR agent observes
the behavior of the file and applies addional malware protecon rules. If a file exhibits malicious
Endpoint Security
behavior, such as encrypon-based acvity common with ransomware, the Cortex XDRagent
blocks the file and reports the security event to the Cortex XDR.
If no malicious behavior is detected, the Cortex XDR agent permits the file (process) to connue
running but connues to monitor the behavior for the lifeme of the process.
Endpoint Protecon Capabilies

Each security profile provides a tailored list of protecon capabilies that you can configure
for the plaorm you select. The following table describes the protecon capabilies you can
customize in a security profile. The table also indicates which plaorms support the protecon
capability (a dash (—) indicates the capability is not supported).
Protecon Capability Windows Mac Linux Android
Exploit Security Profiles
Browser Exploits Protecon — —

Browsers can be subject to
exploitaon aempts from malicious
web pages and exploit kits that are
embedded in compromised websites.
By enabling this capability, the
Cortex XDR agent automacally
protects browsers from common
exploitaon aempts.
Logical Exploits Protecon — —

Aackers can use exisng
mechanisms in the operang system
—such as DLL-loading processes
or built in system processes—
to execute malicious code. By
enabling this capability, the Cortex
XDR agent automacally protects
endpoints from aacks that try to
leverage common operang system
mechanisms for malicious purposes.
Known Vulnerable Processes —

Protecon
Common applicaons in the
operang system, such as PDF
readers, Office applicaons, and
even processes that are a part of the
operang system itself can contain
bugs and vulnerabilies that an
aacker can exploit. By enabling
this capability, the Cortex XDR
Endpoint Security

agent protects these processes from
aacks which try to exploit known
process vulnerabilies.
Exploit Protecon for Addional —

Processes
To extend protecon to third-party
processes that are not protected by
the default policy from exploitaon
aempts, you can add addional
processes to this capability.
Operang System Exploit Protecon —

Aackers commonly leverage the
operang system itself to accomplish
a malicious acon. By enabling
this capability, the Cortex XDR
agent protects operang system
mechanisms such as privilege
escalaon and prevents them from
being used for malicious purposes.
Unpatched Vulnerabilies — — —
Protecon
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
Vulnerabilies Protecon capability
allows the Cortex XDR agent to
apply a workaround to protect
the endpoints from the known
vulnerability.
Malware Security Profiles
Behavioral Threat Protecon —

Prevents sophiscated aacks that
leverage built-in OS executables and
common administraon ulies by
connuously monitoring endpoint
Endpoint Security

acvity for malicious causality
chains.
Ransomware Protecon — — —
Targets encrypon based acvity
associated with ransomware to
analyze and halt ransomware before
any data loss occurs.
Prevent Malicious Child Process — — —

Execuon
Prevents script-based aacks used
to deliver malware by blocking
known targeted processes from
launching child processes commonly
used to bypass tradional security
approaches.
Portable Executables and DLLs — — —

Examinaon
Analyze and prevent malicious
executable and DLL files from
running.
ELF Files Examinaon — — —

Analyze and prevent malicious ELF
files from running.
Local File Threat Examinaon — — —

Analyze and quaranne malicious
PHP files arriving from the web
server.
Office Files Examinaon — — —

Analyze and prevent malicious
macros embedded in Microso
Office files from running.
Mach-O Files Examinaon — — —

Analyze and prevent malicious mach-
o files from running.
DMG Files Examinaon — — —
Endpoint Security

Analyze and prevent malicious DMG
APK Files Examinaon — — —

Analyze and prevent malicious APK
Reverse Shell Protecon — — —

Detect suspicious or abnormal
network acvity from shell processes
and terminate the malicious shell
process.
Network Packet Inspecon Engine — — —

Analyze network packet data to
detect malicious behavior.
Restricons Security Profiles
Execuon Paths — — —
Many aack scenarios are based on
wring malicious executable files to
certain folders such as the local temp
or download folder and then running
them. Use this capability to restrict
the locaons from which executable
files can run.
Network Locaons — — —
To prevent aack scenarios that
are based on wring malicious files
to remote folders, you can restrict
access to all network locaons
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 aached to the
endpoints in your network.
Endpoint Security
Opcal Drive — — —
To prevent malicious code from
gaining access to endpoints using
opcal disc drives (CD, DVD,
and Blu-ray), you can restrict the
executable files, that users can
launch from opcal disc drives
connected to the endpoints in your
network.
Endpoint Protecon Modules

Each security profile applies mulple security modules to protect your endpoints from a wide
range of aack techniques. While the sengs for each security module are not configurable, the
Cortex XDR agent acvates a specific protecon module depending on the type of aack, the
configuraon of your security policy, and the operang 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 aack based on
the technique. To help you understand the nature of the aack, the alert idenfies the protecon
module the Cortex XDR agent employed.
The following table lists the modules and the plaorms on which they are supported. A dash (—)
indicates that the module is not supported.
Module Windows Mac Linux Android
An-Ransomware — — —
Targets encrypon-
based acvity
associated with
ransomware and has
the ability to analyze
and halt ransomware
acvity before any data
loss occurs.
APC Protecon — — —
Prevents aacks
that change the
execuon order of a
process by redirecng
an asynchronous
procedure call (APC) to
Endpoint Security

point to the malicious
shellcode.
Behavioral Threat —
Prevents sophiscated
aacks that leverage
built-in OS executables
and common
administraon ulies
by connuously
monitoring endpoint
acvity for malicious
causality chains.
Brute Force Protecon — — —

Prevents aackers
from hijacking the
process control flow
by monitoring memory
layout enumeraon
aempts.
Child Process — — —
Protecon
Prevents script-based
aacks that are used
to deliver malware,
such as ransomware,
by blocking known
targeted processes
from launching child
processes that are
commonly used to
bypass tradional
security approaches.
CPL Protecon — — —
Protects against
vulnerabilies related
to the display roune
for Windows Control
Panel Library (CPL)
shortcut images,
which can be used as
Endpoint Security

a malware infecon
vector.
Data Execuon — — —
Prevenon (DEP)
Prevents areas of
memory defined to
contain only data from
running executable
code.
DLL Hijacking — — —
Prevents DLL-hijacking
aacks where the
aacker aempts to
load dynamic-link
libraries on Windows
operang systems from
unsecure locaons
to gain control of a
process.
DLL Security — — —
Prevents access to
crucial DLL metadata
from untrusted code
locaons.
Dylib Hijacking — — —
Prevents Dylib-
hijacking aacks where
the aacker aempts to
load dynamic libraries
on Mac operang
systems from unsecure
locaons to gain control
of a process.
Exploit Kit Fingerprint — — —

Protects against
the fingerprinng
technique used by
browser exploit kits to
idenfy informaon
—such as the OS or
Endpoint Security

applicaons which run
on an endpoint—that
aackers can leverage
when launching
an aack to evade
protecon capabilies.
Font Protecon — — —
Prevents improper font
handling, a common
target of exploits.
Gatekeeper — — —
Enhancement
Enhances the
macOS gatekeeper
funconality that
allows apps to run
based on their digital
signature. This module
provides an addional
layer of protecon by
extending gatekeeper
funconality to bundles
and child processes so
you can enforce the
signature level of your
choice.
Hash Excepon
Halts execuon of files
that an administrator
idenfied as malware
regardless of the
WildFire verdict.
Hot Patch Protecon — — —

Prevents the use of
system funcons
to bypass DEP and
address space layout
randomizaon (ASLR).
Java Deserializaon — — —
Endpoint Security

Blocks aempts to
execute malicious code
during the Java objects
deserializaon process
on Java-based servers.
JIT — —
Prevents an aacker
from bypassing the
operang system's
memory migaons
using just-in-me (JIT)
compilaon engines.
Kernel Integrity — — —
Monitor (KIM)
Prevents rootkit
and vulnerability
exploitaon on Linux
endpoints. On the
first detecon of
suspicious rootkit
behavior, the behavioral
threat protecon (BTP)
module generates
an XDR Agent alert.
Cortex XDRstches
logs about the process
that loaded the kernel
module with other logs
relang to the kernel
module to aid in alert
invesgaon. When
the Cortex XDR agent
detects subsequent
rootkit behavior, it
blocks the acvity.
Local Analysis —
Examines hundreds of
characteriscs of an
unknown executable
file, DLL, or macro to
determine if it is likely
to be malware. The
local analysis module
Endpoint Security

uses a stac set of
paern-matching
rules that inspect
mulple file features
and aributes, and
a stascal model
that was developed
using machine learning
on WildFire threat
intelligence.
Local Threat Evaluaon — — —

Engine (LTEE)
Protects against
malicious PHP files
arriving from the web
server.
Local Privilege —
Escalaon Protecon
Prevents aackers
from performing
malicious acvies
that require privileges
that are higher than
those assigned to the
aacked or malicious
process.
Network Packet — — —
Inspecon 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.
Null Dereference — — —
Endpoint Security

Prevents malicious
code from mapping
to address zero in
the memory space,
making null dereference
vulnerabilies
unexploitable.
Restricted Execuon - — — —
Local Path
Prevents unauthorized
execuon from a local
path.
Network Locaon
execuon from a
network path.
Removable Media
execuon from
removable media.
Reverse Shell — — —
Protecon
Blocks malicious
acvity where an
aacker redirects
standard input and
output streams to
network sockets.
ROP —
Protects against the
use of return-oriented
programming (ROP) by
protecng APIs used in
ROP chains.
SEH — — —
Prevents hijacking
of the structured
Endpoint Security

excepon handler
(SEH), a commonly
exploited control
structure that can
contain mulple SEH
blocks that form a
linked list chain, which
contains a sequence of
funcon records.
Shellcode Protecon — — —
Reserves and protects
certain areas of
memory commonly
used to house payloads
using heap spray
techniques.
ShellLink — — —
Prevents shell-link
logical vulnerabilies.
SO Hijacking — — —
Protecon
Prevents dynamic
loading of libraries from
unsecure locaons
to gain control of a
process.
SysExit — — —
Prevents using system
calls to bypass other
protecon capabilies.
UASLR — — —
Improves or altogether
implements ASLR
(address space layout
randomizaon) with
greater entropy,
robustness, and strict
enforcement.
Endpoint Security
Vulnerable Drivers — — —
Protecon
Detect aempts 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-
Detecon (Malware
and Grayware)
Idenfies a file that
was previously allowed
to run on an endpoint
that is now determined
to be malware. Post-
detecon events
provide noficaons for
each endpoint on which
the file executed.
Endpoint Security
Manage Cortex XDR Agents

• Create an Agent Installaon Package
• Set an Applicaon Proxy for Cortex XDR Agents
• Move Cortex XDR Agents Between Managing XDR Servers
• Upgrade Cortex XDR Agents
• Set a Cortex XDR Agent Crical Environment Version
• Delete Cortex XDR Agents
• Uninstall the Cortex XDR Agent
• Set an Alias for an Endpoint
• Manage Endpoint Tags
• Manage Agent Tokens
Create an Agent Installaon Package

To install the CortexXDR agent on the endpoint for the first me, you must first create an agent
installaon package. Aer you create and download an installaon package, you can then install it
directly on an endpoint or you can use a soware deployment tool of your choice to distribute the
soware to mulple endpoints.
To install the CortexXDR agent soware, you must use a valid installaon package that exists in
your Cortex XDR management console. If you delete an installaon package, new agents installed
from this package are not able to register to Cortex XDR, however exisng agents may re-register
using the Agent ID generated by the installaon package.
To create a new installaon package:
STEP 1 | From Cortex XDR, select Endpoints > Agent Installaons.
STEP 2 | Create a new installaon package.
STEP 3 | Enter a unique Name and an oponal Descripon to idenfy the installaon package.
The package Name must be no more than 100 characters and can contain leers, numbers,
hyphens, underscores, commas, and spaces.
STEP 4 | Select the Package Type.

• Standalone Installers—Use for fresh installaons and to Upgrade Cortex XDR 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.
• (Linux only) Kubernetes Installer—Use for fresh installaons and upgrades of CortexXDR
agents running on Kubernetes clusters.
Endpoint Security
STEP 5 | Specify the installaon package sengs.

• (Windows, macOS, and Linux) Select the Plaorm for which you want to create the
installaon package and the Agent Version for the package.
• (Kubernetes only) Configure the sengs for your YAML deployment. These sengs cannot
be changed aer you create the installaon package:
• Select the Agent Version for the package. Crical Environment versions are displayed
as CE versions. Enable Always deploy with latest agent version to ensure that each
new node will launch the latest CortexXDR agent release for which a YAML installaon
package was created. You must assign an Agent Sengs Profile where Agent Auto
Upgrade is enabled for this deployment method.
• Set the CortexXDR agent DaemonSet namespace. For simplified management, it is
recommended to use the default cortex-xdr namespace.
• For a more granular deployment, enter any labels or selectors in the Node Selector. The
CortexXDR agent will be deployed only on these nodes.
• Configure the CortexXDR agent to communicate through an intermediary such as a proxy
or the Palo Alto Networks Broker Service. To enable the agent to direct communicaon
to an intermediary, you use this installaon opon to assign the IP address and port
number you want the CortexXDR agent to use. You can also configure the proxy by
entering the FQDN and port number. When you enter the FQDN, you can use both
lowercase and uppercase leers. Avoid using special characters or spaces.Use commas to
separate mulple addresses.
The CortexXDR agent does not support proxy communicaon in environments

where proxy authencaon is required.
• You can configure the CortexXDR agent to Run on master node, or Run on all nodes.
STEP 6 | Create the installaon package.

Cortex XDR prepares your installaon package and makes it available on the Agent
Installaons page.
STEP 7 | Download your installaon package.

When the status of the package shows Completed, right-click the agent version, and click
Download.
• For Windows endpoints, select between the architecture type. You can download the
installer msi file only, or for CortexXDR agents 7.4 and later, a distribuon package that
includes both the installer msi file and the latest content zip. The distribuon package is
recommended to reduce the network load and me typically required for the inial roll-
out or major upgrades of the CortexXDR agent. To understand the benefits, workflow,
and requirements to support this type of deployment, refer to the Cortex XDR agent
administrator guide.
• For macOS endpoints, download the ZIP installaon folder and upload it to the endpoint.
To deploy the CortexXDR agent using JAMF, upload the ZIP folder to JAMF. Alternavely,
Endpoint Security
to install the agent manually on the endpoint, unzip the ZIP folder and double-click the pkg
file.
• For Linux endpoints, you can download .rpm or .deb installers (according to the endpoint
Linux distribuon), and deploy the installers on the endpoints using the Linux package
manager. Alternavely, you can download a Shell installer and deploy it manually on the
endpoint.
When you upgrade a CortexXDR agent version without package manager, Cortex
XDR will upgrade the installaon process to package manager by default, according
to the endpoint Linux distribuon.
• For Kubernetes clusters on Linux endpoints, download the YAML file. Palo Alto Networks
strongly recommends that you do not edit this file.
• For Android endpoints, Cortex XDR creates a tenant-specific download link which you
can distribute to Android endpoints. When a newer agent version is available, Cortex XDR
idenfies older package versions as [Outdated].
STEP 8 | Next steps:

As needed, you can return to the Agent Installaons page to manage your agent installaon
packages. To manage a specific package, right click the agent version, and select the desired
acon:
• Edit the package name or descripon.
• Delete the installaon package. Deleng an installaon package does not uninstall the
CortexXDR agent soware from any endpoints.
Since Cortex XDR relies on the installaon package ID to approve agent registraon
during install, it is not recommended to delete the installaon package of acve
endpoints. If you install the CortexXDR agent from a package aer you delete it,
Cortex XDR denies the registraon request leaving the agent in an unprotected
state. Hiding the installaon package will remove it from the default list of
available installaon packages, and can be useful to eliminate confusion within
the management console main view. These hidden installaon 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 installaon
package.
• Hide installaon packages. Using the Hide opon 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.
Set an Applicaon Proxy for Cortex XDR Agents

This capability is supported on endpoints with Traps agent 5.0.9 (Windows only) or Cortex
XDRagent 7.0 and later releases.
In environments where agents communicate with the Cortex XDR server through a wide-system
proxy, you can now set an applicaon-specific proxy for the Traps and Cortex XDR agent without
affecng the communicaon of other applicaons on the endpoint. You can set the proxy in one
Endpoint Security
of three ways: during the agent installaon or aer installaon using Cytool on the endpoint or
from All Endpoints in Cortex XDRas described in this topic. You can assign up to five different
proxy servers per agent. The proxy server the agent uses is selected randomly and with equal
probability. If the communicaon between the agent and the Cortex XDR server through the app-
specific proxies fails, the agent resumes communicaon through the system-wide proxy defined
on the endpoint. If that fails as well, the agent resumes communicaon with Cortex XDR directly.
STEP 1 | From Cortex XDR, select Endpoints > All Endpoints.
STEP 2 | If needed, filter the list of endpoints.
STEP 3 | Set an agent proxy.

1. Select the row of the endpoint for which you want to set a proxy.
2. Right-click the endpoint and select Endpoint Control > Set Agent Proxy.
3. You can assign up to five different proxies per agent. For each proxy, enter the IP address
and port number. For Cortex XDR agents 7.2.1 and later, you can also configure the
proxy by entering the FQDN and port number. When you enter the FQDN, you can
use either all lowercase leers or all uppercase leers. Avoid using special characters or
spaces.
For example:
my.network.name:808,YOUR.NETWORK.COM:888,10.196.20.244:8080.
4. Set when you’re done.
5. If necessary, you can later Disable Agent Proxy from the right-click menu.
When you disable the proxy configuraon, all proxies associated with that agent are
removed. The agent resumes communicaon with the Cortex XDR server through
the wide-system proxy if defined, otherwise if a wide-system is not defined the
agent resumes communicang directly with the Cortex XDR server. If neither a wide-
system proxy nor direct communicaon exist and you disable the proxy, the agent will
disconnect from Cortex XDR.
Move Cortex XDR Agents Between Managing XDR Servers

You can move exisng agents between Cortex XDR managing servers directly from the Cortex
XDR management console. This can be useful during POCs or to beer manage your agents
allocaon 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
previously stored for it on the original managing server. Aer the Cortex XDR registers with the
new server, it can no longer communicate with the previous one.
The following are prerequisites to enable you change the managing server of a Cortex XDR agent.
• Ensure that you are running a Cortex XDR agent 7.2 or later release.
• Ensure you have administrator privileges for Cortex XDR in the hub.
To register to another managing server, the Cortex XDR agent requires a distribuon ID of an
installaon package on the target server in order to idenfy itself as a valid Cortex XDR agent.
The agent must provide an ID of an installaon package that matches the same operang system
and 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 installaon
Endpoint Security
package created for a Cortex XDR Agent 5.0.0 for Windows. The operang system version can be
different.
Cortex XDR does not support moving agents between FedRamp and commercial tenants.
To change the managing server of a Cortex XDR Agent:

STEP 1 | Obtain an installaon package ID from the target managing server.
1. Log in to Cortex XDR on the target management server, then navigate to Endpoints >
Agent Installaons.
2. From the agent installaons table, locate a valid installaon package you can use to
register the agent. Alternavely, you can create a new installaon package if required.
3. Right-click the ID field and copy the value. Save this value, you will need it later for the
registraon process. If the ID column is not displayed in the table, add it.
STEP 2 | Locate the Cortex XDR agent you want to move.

Log in the current managing server of the Cortex XDR agent and navigate to Endpoints > All
Endpoints.
Endpoint Security
STEP 3 | Change the managing server.

1. Select one or more agents that you want to move to the target server.
2. Right click + Alt to open the opons menu in advanced mode, and select Endpoint
Control > Change managing server. This opon is available only for an administrator in
Cortex XDR and for Cortex XDR agent 7.2 and later releases.
3. Enter the ID number of the installaon package you obtained in Step 1. If you selected
agents running on different operang systems, for example Windows and Linux, you
must provide an ID for each operang system. When done, click Move.
STEP 4 | Track the acon.

When you track the acon in the Acon Center, the original managing server will keep
displaying In progress (Sent) status also aer the acon has ended successfully, since the agent
no longer reports to this managing server. The new managing server will add this as a new
agent registraon acon.
Upgrade Cortex XDR Agents

Aer you install the Cortex XDR agent and the agent registers with Cortex XDR, you can upgrade
the Cortex XDR agent soware using a method supported by the endpoint plaorm:
• 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.
Endpoint Security
• Windows, Mac, or Linux—Create new installaon packages and push the Cortex XDR agent
package to up to 5,000 endpoints from Cortex XDR.
• You cannot upgrade VDI endpoints or a Golden Image.

• Before upgrading a Cortex XDRagent 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, aer the upgrade the extensions
remain on the endpoint without any opon 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 administraon
guide for approving System Extensions, either manually or using an MDM profile.
Upgrades are supported using acons which you can iniate from the Acon Center or from All
Endpoints as described in this workflow.
STEP 1 | Create an Agent Installaon Package for each operang system version for which you want
to upgrade the Cortex XDR agent.
Note the installaon package names.
STEP 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.
STEP 3 | Select the endpoints you want to upgrade.

You can also select endpoints running different operang systems to upgrade the agents at the
same me.
STEP 4 | Right-click your selecon and select Endpoint Control > Upgrade Agent Version.
For each plaorm, select the name of the installaon package you want to push to the selected
endpoints.
Starng in the Cortex XDR agent 7.1 release, you can install the Cortex XDR agent on Linux
endpoints using package manager. When you upgrade an agent on a Linux endpoint that is not
using package manager, Cortex XDR upgrades the installaon process by default according to
the endpoint Linux distribuon. Alternavely, if you do not want to use the package manage,
clear the opon Upgrade to installaon by package manager.
The Cortex XDR agent keeps the name of the original installaon package aer every
upgrade.
STEP 5 | Upgrade.
Cortex XDR distributes the installaon package to the selected endpoints at the next heartbeat
communicaon with the agent. To monitor the status of the upgrades, go to Response > Acon
Center. From the Acon Center you can also view addional informaon about the upgrade
Endpoint Security
(right-click the acon and select Addional data) or cancel the upgrade (right-click the acon
and select Cancel Agent Upgrade).
• During the upgrade process, the endpoint operang system might request for a
reboot. However, you do not have to perform the reboot for the Cortex XDR agent
upgrade process to complete successfully.
• Aer you upgrade to a Cortex XDR agent 7.2 or a later release on an endpoint with
Cortex XDR Device Control rules, you need to reboot the endpoint for the rules to
take effect.
Set aCortex XDR Agent Crical Environment Version

Aer you install the Cortex XDR agent and the agent registers with Cortex XDR, you can set
endpoints to run with a Cortex XDR agent Crical Environment version.
Crical Environment Versions are designed for sensive and highly regulated environments
and do not contain all updates and content exisng in the standard version. Therefore, it is
recommended to restrict the use of these versions to the required minimum.
Seng an endpoint with a CE agent version requires you to define your Agent Configuraons
which then allows you to:
• Create a CE Agent Installaon Package
• Define the upgrade and auto-upgrade Agent Sengs Profile
To set a Cortex XDR agent CE version:
STEP 1 | Define your agent configuraon.
1. Navigate to Sengs > Configuraons > Agent Configuraons > Crical Environment
Versions.
2. Enable Crical Environment Versions to be Created and Installed in the Tenant.
STEP 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 Crical Environment agent.
Delete Cortex XDR Agents

If you have an endpoint that you no longer want to track through the Cortex XDR management
console, for example if the endpoint disconnected from the Cortex XDR management console, or
an endpoint where the Cortex XDR agent was uninstalled, you can delete the endpoint from the
management console views. Deleng an endpoint triggers the following lifespan flow:
• The endpoint status changes to Deleted, and the license returns immediately to the license
pool. Aer a retenon 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 Acon Center tables and in the
Causality View for the standard 90 days retenon period.
• Alerts that already include the endpoint data at the me of the alert creaon are not affected.
Endpoint Security
Addionally, Cortex XDR automacally deletes agents aer a long period of inacvity:
• Standard agents are deleted aer 180 days of inacvity.
• VDI and TS agents are deleted aer 6 hours of inacvity.
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.
STEP 2 | Right-click the endpoint you want to remove.

You can also select mulple endpoints if you want to perform a bulk delete.
STEP 3 | Select Endpoint Control > Delete Endpoint.
Uninstall the Cortex XDR Agent

If you want to uninstall the Cortex XDR agent from the endpoint, you can do so from the Cortex
XDR management console at any me. You can uninstall the Cortex XDR agent from an unlimited
number of endpoints in a single bulk acon. Uninstalling an endpoint triggers the following
lifespan flow:
• Once you uninstall the agent from the endpoint, the acon is immediate. All agent files and
protecons are removed from the endpoint, leaving the endpoint unprotected.
• The endpoint status changes to Uninstalled, and the license returns immediately to the
license pool. Aer a retenon 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 Acon Center tables and in the
Causality View for the standard 90 days retenon period.
• Alerts that already include the endpoint data at the me of the alert creaon are not affected.
Before upgrading a Cortex XDRagent 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, aer the upgrade the extensions remain on the endpoint
without any opon 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
administraon guide for approving System Extensions, either manually or using an MDM
profile.
The following workflow describes how to uninstall the Cortex XDR agent from one or more
Windows, Mac, or Linux endpoints. To uninstall the Cortex XDR app for Android, you must do so
from the Android endpoint.
Endpoint Security
STEP 1 | Log in to Cortex XDR.

Go to Incident Response > Response > Acon Center > + New Acon.
STEP 2 | Select Agent Uninstall.
STEP 3 | Click Next.
STEP 4 | 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 aribute or group name.
STEP 6 | Review the acon summary and click Done when finished.
STEP 7 | To track the status of the uninstallaon, return to the Acon Center.
Set an Alias for an Endpoint

To idenfy one or more endpoints by a name that is different from the endpoint hostname, you
can configure an alias. You can set an alias for a single endpoint or you can set an alias for mulple
endpoints in bulk. To quickly search for the endpoints during invesgaon and when you need to
take acon, you can use the either the endpoint hostname or the alias.
STEP 2 | Select one or more endpoints.
STEP 3 | Right-click anywhere in the endpoint rows.
STEP 4 | Select Endpoint Control > Change Endpoint Alias.
STEP 5 | Enter the alias name and Update.

If you later change your mind, you can Clear alias of all selected agents from the same menu.
STEP 6 | Use the Quick Launcher to search the endpoints by alias across the Cortex XDR management
console.
Manage Endpoint Tags

Endpoint tags enable mulple layers of segmentaon to your endpoints. An endpoint tag is a
dynamic enty that is created and assigned to one or more endpoints. The assigned endpoint tags
can then be used to create Endpoint Groups, Policies, and Acons.
To manage your endpoint tags:
The following uses Windows operang system installaon parameters and Cytool
argument examples.
Endpoint Security
STEP 1 | Create an endpoint tag.

As of Cortex XDR agent version 7.7.1 and up, you can create endpoint tags on either the:
• Cortex XDR management console (Server)
• Machine where the Cortex XDR agent (Agent) is installed by running a:
• Windows, Mac, Linux agent installaon parameter
• Cytool argument
• From the Cortex XDR agent:
1. Navigate to the Cytool folder locaon and open the CLI as an administrator.
2. Installer parameter - run msiexec /i ... ENDPOINT_TAGS="Name1, Name 2,
Name3".
Cytool argument - run cytool endpoint tags add “tag1
[,tag2, ...,tagN]”.
Tag names are case sensive and can contain spaces.
• 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 > Assign Endpoint
Tags.
3. Select Add tag... and choose one ore more tags from the list of exisng tags or begin to
type a new tag name to Create tag.
Tag names are case sensive and can contain spaces.
4. Save the tag names you selected.
STEP 2 | Remove an endpoint tag.

Depending on where you created your tag, Server or Agent, you can choose to edit or remove
the tags.
2. Cytool Argument - run cytool endpoint tags remove “tag1
[,tag2, ...,tagN]”.
2. Select one or more endpoints, right-click, and select Endpoint Control > Remove
Endpoint Tags.
3. Save the tag names you removed.
Endpoint Security
STEP 3 | Track your endpoint tags.

2. For Cytool, run cytool endpoint tags list.
All Server and Agent tags associated with the specific endpoint are displayed. Tags
created in the Cortex XDR agent are displayed with a shield icon.
2. Filter and search the Tags field for the endpoint tags you created and assigned.
Manage Agent Tokens

You can now run some of the agent funcons that require administrave passwords using a
unique token shared between Cortex XDR server and Cortex XDR agent.
There are two types of tokens that can be set.
• Rolling token—this token is automacally generated per endpoint every fourteen days by the
system and then sent to the relevant agent.
• Temporary token—this token enables you to set a temporary token which 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.
STEP 1 | View agent password.
You can view the password of the selected agent. Whether the password is from a rolling token
or temporary token is indicated in the dialog.
1. Select Endpoints > All Endpoints > Endpoint Control > View Token.
2. Click the copy buon to copy the password displayed and then click Ok.
You can now use the password to run funcons at the agent.
Endpoint Security
STEP 2 | Add 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.
1. Select Endpoints > All Endpoints > Endpoint Control > Set Temporary Token.
2. In the Token Expiraon field, add the number of days for which to generate a temporary
token for the agent and then click the Add Token Expiraon blue arrow.
3. Click the copy buon to copy the password displayed and then click Create to begin
generang the token.
4. Go to the Acon Center to view which agent received the temporary token.
STEP 3 | Retrieve token using 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 funcons with the updated token from the server. You can sll
retrieve the password to run funcons at the agent.
1. From the agent, run the cytool.exe to run the token query command. This command
displays the current token of the endpoint.
2. Copy the token from the command line interface of the agent.
3. In the server, at the top of the page, click the Retrieve Token buon.
4. In the Retrieve Token dialog, in the Hash field, paste the token that you copied from the
endpoint.
5. Click the copy buon to copy the password displayed and then click Ok.
Endpoint Security
Define Endpoint Groups

To easily apply policy rules and manage specific endpoints, you can define an endpoint group. If
you set up Cloud Identy Engine, you can also leverage your Acve Directory user, group, and
computer informaon in endpoint groups.
There are two methods you can use to define an endpoint group:
• Create a dynamic group by allowing Cortex XDR to populate your endpoint group dynamically
using endpoint characteriscs such as a endpoint tag, paral hostname or alias; full or paral
domain or workgroup name; IP address, range or subnet; installaon type (VDI, temporary
session, or standard endpoint); agent version; endpoint type (workstaon, server, mobile); or
operang system version.
• Create a stac group by selecng a list of specific endpoints.
Aer you define an endpoint group, you can then use it to target policy and acons to specific
recipients. The Endpoint Groups page displays all endpoint groups along with the number of
endpoints and policy rules linked to the endpoint group.
To define an endpoint stac or dynamic group:
STEP 1 | From Cortex XDR, select Endpoints > Endpoint Groups > +Add Group.
STEP 2 | Select either Create New to create an endpoint group from scratch or Upload From File,
using plain text files with new line separator, to populate a stac endpoint group from a file
containing IP addresses, hostnames, or aliases.
STEP 3 | Enter a Group Name and oponal Descripon to idenfy the endpoint group. The name you
assign to the group will be visible when you assign endpoint security profiles to endpoints.
STEP 4 | Determine the endpoint properes for creang an endpoint group:

• Dynamic—Use the filters to define the criteria you want to use to dynamically populate an
endpoint group. Dynamic groups support mulple criteria selecons 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.
Cortex XDR supports only IPv4 addresses.
• Stac—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 stac endpoint group from a file, the IP address, hostname, or alias of
the endpoint must match an exisng agent that has registered with Cortex XDR. You can
select up to 250 endpoints.
Disconnecng Cloud Identy Engine in your Cortex XDR deployment can affect
exisng endpoint groups and policy rules based on Acve Directory properes.
Endpoint Security
STEP 5 | Create the endpoint group.

Aer 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.
STEP 6 | Manage an endpoint group, as needed.

At any me, 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 acon:
• Edit—View the endpoints that match the group definion, and oponally refine the
membership criteria using filters.
• Delete the endpoint group.
• Save as new—Duplicate the endpoint group and save it as a new group.
• Export group—Export the list of endpoints that match the endpoint group criteria to a tab
separated values (TSV) file.
• View endpoints—Pivot from an endpoint group to a filtered list of endpoints on the
Endpoint Administraon page where you can quickly view and iniate acons on the
endpoints within the group.
Endpoint Security
About Content Updates

To increase security coverage and quickly resolve any issues in policy, Palo Alto Networks can
seamlessly deliver soware packages for Cortex XDR called content updates. Content updates can
contain changes or updates to any of the following:
Starng with the Cortex XDR 7.1 agent release, Cortex XDR delivers to the agent the
content update in parts and not as a single file, allowing the agent to retrieve only the
updates and addions it needs.
• Default security policy including exploit, malware, restricon, and agent sengs profiles
• Default compability rules per module
• Protected processes
• Local analysis logic
• Trusted signers
• Processes included in your block list by signers
• Behavioral threat protecon rules
• Ransomware module logic including Windows network folders suscepble to ransomware
aacks
• Event Log for Windows event logs and Linux system authencaon logs
• Python scripts provided by Palo Alto Networks
• Python modules supported in script execuon
• Maximum file size for hash calculaons in File search and destroy
• List of common file types included in File search and destroy
• Network Packet Inspecon Engine rules
When a new update is available, Cortex XDR nofies the Cortex XDR agent. The Cortex XDR
agent then randomly chooses a me within a six-hour window during which it will retrieve the
content update from Cortex XDR. By staggering the distribuon of content updates, Cortex XDR
reduces the bandwidth load and prevents bandwidth saturaon due to the high volume and size of
the content updates across many endpoints. You can view the distribuon of endpoints by content
update version from the Cortex XDR 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, starng 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
disnguish between major and minor releases, XXX is rounded up to the nearest ten for every
major release, and incremented by one for a minor release. For example, 180-<build_num> and
190-<build_num> are major releases, and 181-<build_num>, 182-<build_num>, and 191-
<build_num> are minor releases.
Endpoint Security
To adjust content update distribuon for your environment, you can configure the following
oponal sengs:
• Content management sengs as part of the Cortex XDR global agent configuraons.
• Content download source, as part of the Cortex XDR agent seng 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 in one of the following
methods:
• (Windows and Mac only) Perform manual check-in from the Cortex XDR agent console.
• Iniate a check-in using the Cytool checkin command.
Endpoint Security
Endpoint Security Profiles

Cortex XDR provides default security profiles that you can use out of the box to immediately
begin protecng your endpoints from threats.
While security rules enable you to block or allow files to run on your endpoints, security profiles
help you customize and reuse sengs 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 aached to the rule for further inspecon.
From Endpoints > Policy Management > Prevenon > Profiles, you can create the following
profiles. The Prevenon Profiles table lists all the profiles per operang system. Profiles associated
with one or more targets that are beyond your defined user scope are locked and cannot be
edited.
Profile Name Descripon
Exploit Profiles Exploit profiles block aempts to exploit

system flaws in browsers, and in the operang
system. For example, Exploit profiles help
protect against exploit kits, illegal code
execuon, and other aempts to exploit
process and system vulnerabilies. Exploit
profiles are supported for Windows, Mac, and
Linux plaorms.
Add a New Exploit Security Profile.
Malware Profiles Malware profiles protect against the execuon

of malware including trojans, viruses, worms,
and grayware. Malware profiles serve two
main purposes: to define how to treat
behavior common with malware, such as
ransomware or script-based aacks, and
to define how to treat known malware and
unknown files. Malware profiles are supported
for all plaorms.
Add a New Malware Security ProfileAdd a
New Malware Security Profile.
Restricons Profiles Restricons profiles limit where executables

can run on an endpoint. For example, you can
restrict files from running from specific local
folders or from removable media. Restricons
profiles are supported only for Windows
plaorms.
Add a New Restricons Security Profile.
Endpoint Security
Profile Name Descripon
Agent Sengs Profiles Agent Sengs profiles enable you to

customize sengs that apply to the Cortex
XDR agent (such as the disk space quota
for log retenon). For Mac and Windows
plaorms, you can also customize user
interface opons for the Cortex XDR console,
such as accessibility and noficaons.
Add a New Agent Sengs Profile.
Excepons Profiles Excepons Security Profiles override the

security policy to allow a process or file to run
on an endpoint, to disable a specific BTP rule,
to allow a known digital signer, and to import
excepons from the Cortex XDR support
team. Excepons profiles are supported for
Windows, Mac, and Linux plaorms.
Add a New Excepons Security Profile.
Aer you add the new security profile, you can Manage Endpoint Security Profiles.
Add a New Exploit Security Profile

Exploit security profiles allow you to configure the acon the Cortex XDR agent takes when
aempts to exploit soware vulnerabilies or flaws occur. To protect against specific exploit
techniques, you can customize exploit protecon capabilies in each Exploit security profile.
By default, the Cortex XDR agent will receive the default profile that contains a pre-defined
configuraon for each exploit capability supported by the plaorm. To fine-tune your Exploit
security policy, you can override the configuraon of each capability to block the exploit behavior,
allow the behavior but report it, or disable the module.
To define an Exploit security profile:
STEP 1 | Add a new profile.
1. From Cortex XDR, select Endpoints > Policy Management > Prevenon > Profiles > +
New Profile and select whether to Create New or Import from File a new profile.
New imported profiles are added and not replaced.
2. Select the plaorm to which the profile applies and Exploit as the profile type.
3. Click Next.
Endpoint Security
STEP 2 | Define the General Informaon.

1. Enter a unique Profile Name to idenfy the profile. The name can contain only leers,
numbers, or spaces, and must be no more than 30 characters. The name you choose will
be visible from the list of profiles when you configure a policy rule.
2. To provide addional context for the purpose or business reason that explains why you
are creang the profile, enter a profile Descripon. For example, you might include an
incident idenficaon number or a link to a help desk cket.
STEP 3 | Configure the acon to take when the Cortex XDR agent detects an aempt to exploit each
type of soware flaw.
For details on the different exploit protecon capabilies, see Endpoint Protecon Capabilies.
• Block—Block the exploit aack.
• Report—Allow the exploit acvity but report it to Cortex XDR.
• Disabled—Disable the module and do not analyze or report exploit aempts.
• Default—Use the default configuraon to determine the acon to take. Cortex XDR displays
the current default configuraon for each capability in parenthesis. For example, Default
(Block).
To view which processes are protected by each capability, see Processes Protected by Exploit
Security Policy .
For Known Vulnerable Process Protecon, enable to automacally protect endpoints from
aacks that try to leverage common operang system mechanisms for malicious purposes.
Select either to Block (default) or Report. When enabled, select whether to also enable the
Java Deserializaon Protecon. If enabled, the same acon mode defined for the Known
Vulnerable Process Protecon is inherited.
Aackers can use exisng mechanisms in the operang system to execute malicious code. By
enabling this capability, XDR agent Add the following secon in Windows Exploit ProfileKnown
Vulnerable Processes ProteconAcon Mode - Block (default) / Report / DisabledInhering
from acon mode - Java Deserializaon Protecon - Enabled / Disabled (default)When the
Acon mode of Known Vulnerable Processes Protecon is set to disabled the Jave protecon
becomes greyed out and is disabled as well regardless of its value.If enabled, the acon mode -
report or block is inherited from the main seng.
For Logical Exploits Protecon, you can also configure a block list for the DLL Hijacking
module. The block list enables you to block specific DLLs when run by a protected process.
The DLL folder or file must include the complete path. To complete the path, you can use
environment variables or the asterisk ( *) as a wildcard to match any string of characters (for
example, */windows32/).
For Exploit Protecon for Addional Processes, you also add one or more addional
processes.
In Exploit Security profiles, if you change the acon 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 Protecon, Java Deserializaon, ROP, and
SO Hijacking.
Endpoint Security
STEP 4 | (Windows only) Configure how to address unpatched known vulnerabilies in your network.
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 Vulnerabilies Protecon capability
allows the Cortex XDR agent to apply a workaround to protect the endpoints from the known
vulnerability. It takes the Cortex XDR agent up to 6 hours to enforce your configured policy on
the endpoints.
To address known vulnerabilies CVE-2021-24074, CVE-2021-24086, and CVE-2021-24094,
you can Modify IPv4 and IPv6 sengs as follows:
• Do not modify system sengs (default)—Do not modify the IPv4 and IPv6 sengs
currently set on the endpoint, whether the current values are your original values or values
that were modified as part of this workaround.
• Modify system sengs unl the endpoint is patched—If the endpoint is already patched,
this opon does not modify any system sengs. For unpatched endpoints, the Cortex
XDR agent runs the following commands to temporarily modify the IPv4 and IPv6 sengs
unl the endpoint is patched. Aer the endpoint is patched for CVE-2021-24074,
CVE-2021-24086, and CVE-2021-24094, all modified Windows system sengs as part
of this workaround are automacally reverted to their values before modificaon. Palo
Alto Networks strongly recommends that you review these commands before applying this
workaround in your network to ensure your crical business components are not affected
or harmed:
netsh int ipv6 set global reassemblylimit=0, this command disables IPv6
fragmentaon on the endpoint.
netsh int ipv4 set global sourceroutingbehavior=drop, this command
disables LSR / loose source roung for IPv4.
• Revert system sengs to your previous sengs—Revert all Windows system sengs
to their values before modificaon 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 7.1 or later and content 167-51646
or later. This workaround in not recommended for non-persistent, stateless, or linked-
clone environments. In some cases, enabling this workaround can affect the network
funconality on the endpoint.
STEP 5 | Save the changes to your profile.
STEP 6 | Apply Security Profiles to Endpoints.

You can do this in two ways: You can Create a new policy rule using this profile from the right-
click menu or you can launch the new policy wizard from Policy Rules.
Endpoint Security
Processes Protected by Exploit Security Policy

By default, your exploit security profile protects endpoints from aack techniques that target
specific processes. Each exploit protecon capability protects a different set of processes that Palo
Alto Networks researchers determine are suscepble to aack. The following tables display the
processes that are protected by each exploit protecon capability for each operang system.
Windows Processes Protected by Exploit Security Policy
Browser Exploits Protecon
• [updated version of Adobe • flashul_acvex.exe • opera.exe

Flash Player for Firefox • iexplore.exe • plugin-container.exe
installed on endpoint]
• microsoedge.exe • safari.exe
• browser_broker.exe
• microsoedgecp.exe • webkit2webprocess.exe
• chrome.exe
• opera_plugin_wrapper.exe
• firefox.exe
Logical Exploits Protecon
• cliconfg.exe • excel.exe • powerpnt.exe

• dism.exe • migwiz.exe • sysprep.exe
• dllhost.exe • mmc.exe • winword.exe
Known Vulnerable Processes Protecon
• 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 • microso.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 • qask.exe • wab.exe
Endpoint Security
Windows Processes Protected by Exploit Security Policy

• fltldr.exe • quickmeplayer.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
Operang System Exploit Protecon
• cmon.exe • runmebroker.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 Protecon
• 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 Protecon
• adobereader • firefox • pdf reader x

• app drive for google drive • firefox-bin • plugin-container
• app drop for dropbox • google chrome helper • quickme 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 • microso excel • textwrangler
• app for linkedin • microso outlook • vlc
• app for youtube • microso powerpoint • vmware fusion services
Endpoint Security
Mac Processes Protected by Exploit Security Policy

• com.apple.safariservices • microso remote desktop • vmware fusion
• com.apple.webkit.plugin • microso 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
• adobereader • document writer • photos

• airmail • itunes helper • photoshop
• app drive for google drive • itunes • quickbooks
• app drop for dropbox • jump desktop • quickme player
• app for dropbox • mail • signal
• app for facebook • mail+ for yahoo • slack
• app for google drive • messages • sonicwall mobile connect
• app for googledocs • microso excel • telegram
• app for instagram • microso outlook • textmate
• app for linkedin • microso powerpoint • textwrangler
• app for youtube • microso remote desktop • thunderbird
• bbedit • microso word • vlc
• c-lion • miniwriterfree • vmware fusion services
• cisco anyconnect secure • parallels client • vmware fusion
mobility client • pdf reader pro free • vpn shield
• com.apple.cloudphotosconfiguraon
• pdf reader x • winmail.dat file viewer
Linux Processes Protected by Exploit Security Policy
• anacron • mailman • rsyslogd

• apache2 • master • samba
• authproxy • mongod • saned
• bluetoothd • mysqld • sendmail
• charon • mysqld_safe • sendmail.sendmail
• chronyd • named • smartd
• couriertcpd • ndsd • smbd
• cron • nginx • snmpd
Endpoint Security
Linux Processes Protected by Exploit Security Policy

• crond • nmbd • squid
• cupsd • node • squid3
• cyrus_pop3d • nscd • starter
• danted • php • syslog-ng
• dhcpd • php5-fpm • nyproxy
• dovecot • pmmasterd • vspd
• exim • pop2d • wickedd-dhcp4
• pd • pop3d • wickedd-dhcp6
• hpd • postgres • winbindd
• ibserver • propd • xinetd
• identd • qmgr
• lighpd • rpcbind
• java • rsync
• kamailio
Add a New Malware Security Profile

Malware security profiles allow you to configure the acon Cortex XDR agents take when known
malware and unknown files try to run on Windows, Mac, Linux, and Android endpoints.
configuraon for each malware protecon capability supported by the plaorm. To fine-tune
your Malware security policy, you can override the configuraon of each capability to block the
malicious behavior or file, allow but report it, or disable the module. For each seng you override,
clear the opon to Use Default.
To configure a Malware security profile:
2. Select the plaorm to which the profile applies and Malware as the profile type.
STEP 2 | Idenfy the profile.

Endpoint Security
STEP 3 | Configure the Cortex XDR agent to examine executable files, macros, or DLL files on
Windows endpoints, Mach-O files or DMG files on Mac endpoints, ELF files on Linux
endpoints, or APK files on Android endpoints.
1. Configure the Acon Mode—the behavior of the Cortex XDR agent—when malware is
detected:
• Block—Block aempts to run malware.
• Report—Report but do not block malware that aempts to run.
• (Android only) Prompt—Enable the Cortex XDR agent to prompt the user when
malware is detected and allow the user to choose to allow malware, dismiss the
noficaon, or uninstall the app.
• Disabled—Disable the module and do not examine files for malware.
2. Configure addional acons to examine files for malware.
By default, Cortex XDR uses the sengs specified in the default malware security profile
and displays the default configuraon in parenthesis. When you select a seng other
than the default, you override the default configuraon for the profile.
• (Windows, Mac starng with Cortex XDR agent 7.4, Linux starng with Cortex XDR
agent 7.5) Quaranne Malicious Executables / Mach-O / ELF files—By default, the
Cortex XDR agent blocks malware from running but does not quaranne the file.
Enable this opon to quaranne files depending on the verdict issuer (local analysis,
WildFire, or both local analysis and WildFire).
The quaranne feature is not available for malware idenfied in network drives.
• Upload <file_type> files for cloud analysis—Enable the Cortex XDR agent to send
unknown files to Cortex XDR, and for Cortex XDR to send the files to WildFire for
analysis. With macro analysis, the Cortex XDR agent sends the Microso Office file
containing the macro. The file types that the Cortex XDR agent analyzes depend on
the plaorm type. WildFire accepts files up to 100MB in size.
• Treat Grayware as Malware—Treat all grayware with the same Acon Mode you
configure for malware. Otherwise, if this opon is disabled, grayware is considered
benign and is not blocked.
• Acon on Unknown to WildFire—Select the behavior of the Cortex XDR agent
when an unknown file tries to run on the endpoint (Allow, Run Local Analysis, or
Block). With local analysis, the Cortex XDRagent uses embedded machine learning to
determine the likelihood that an unknown file is malware and issues a local verdict for
the file. If you block unknown files but do not run local analysis, unknown files remain
blocked unl the Cortex XDR agent receives an official WildFire verdict.
• (Cortex XDR agent 7.5 and later for Windows only)Acon when WildFire verdict is
Benign with Low Confidence—Select the behavior of the Cortex XDR agent when a
file with Benign Low Confidence verdict from WildFire tries to run on the endpoint
(Allow, Run Local Analysis, or Block). With local analysis, the Cortex XDR agent
uses embedded machine learning to determine the likelihood that an unknown file
is malware and issues a local verdict for the file. If you block these files but do not
run local analysis, they remain blocked unl the Cortex XDR agent receives a high-
Endpoint Security
confidence WildFire verdict. To enable this capability, ensure that WildFire analysis
scoring is enabled in your Global Agent Sengs.
• For opmal user experience, Palo Alto Networks recommends you set the
acon mode to either Allow or Run Local Analysis.
• Acon on Benign LC verdict is supported from agent version 7.5 and
above. For agent version 7.4.X, acon on Benign LC verdict is the same as
the acon for files with Unknown verdict.
• (Windows only) Examine Office Files From Network Drives—Enable the Cortex XDR
agent to examine Microso Office files in network drives when they contain a macro
that aempts to run. If this opon is disabled, the Cortex XDR agent will not examine
macros in network drives.
(Windows only) As part of the an-malware security flow, the Cortex XDR
agent leverages the OS capability to idenfy revoked cerficates for executables
and DLL files that aempt to run on the endpoint by accessing the Windows
Cerficate Revocaon List (CRL). To allow the Cortex XDR agent access the CRL,
you must enable internet access over port 80 for Windows endpoints running
Traps 6.0.3 and later releases, Traps 6.1.1 and later releases, or Cortex XDR
7.0 and later releases. If the endpoint is not connected to the internet, or you
experience delays with executables and DLLs running on the endpoint, please
contact Palo Alto Networks Support.
3. (Oponal) Add files and folders to your allow list to exclude them from examinaon.
1. +Add a file or folder.
2. Enter the path and press Enter or click the check mark when done. You can also use
a wildcard to match files and folders containing a paral name. Use ? to match a
single character or * to match any string of characters. To match a folder, you must
terminate the path with * to match all files in the folder (for example, c:\temp\*).
3. Repeat to add addional files or folders.
4. Add signers to your allow list to exclude them from examinaon.
When a file that is signed by a signer you included in your allow list aempts to run,
1. +Add a trusted signer.
2. Enter the name of the trusted signer (Windows) or the SHA1 hash of the cerficate
that signs the file (Mac) and press Enter or click the check mark when done. You can
also use a wildcard to match a paral name for the signer. Use ? to match any single
character or * to match any string of characters.
3. Repeat to add addional folders.
Cortex XDR agent evaluates the signer name using the CN (Common Name)
value in the digital signature, while the Cortex XDR console can display in the
Alerts table both the O (Organizaon) value and the CN (Common Name).
Endpoint Security
STEP 4 | (Windows, Mac, and Linux only) Configure Behavioral Threat Protecon.
Behavioral threat protecon requires Traps agent 6.0 or a later release for Windows
endpoints, and Traps 6.1 or later versions for Mac and Linux endpoints.
With Behavioral threat protecon, the agent connuously monitors endpoint acvity to
idenfy and analyze chains of events—known as causality chains. This enables the agent to
detect malicious acvity in the chain that could otherwise appear legimate if inspected
individually. A causality chain can include any sequence of network, process, file, and registry
acvies on the endpoint. Behavioral threat protecon can also idenfy behavior related
to vulnerable drivers on Windows endpoints. For more informaon on data collecon for
Behavioral Threat Protecon, see Endpoint Data Collected by Cortex XDREndpoint Data
Collecon.
Palo Alto Networks researchers define the causality chains that are malicious and distribute
those chains as behavioral threat rules. When the Cortex XDRagent detects a match to a
behavioral threat protecon rule, the Cortex XDR agent carries out the configured acon
(default is Block). In addion, the Cortex XDR agent reports the behavior of the enre event
chain up to the process, known as the causality group owner (CGO), that the Cortex XDR agent
idenfied as triggering the event sequence.
To configure Behavioral Threat Protecon:
1. Define the Acon mode to take when the Cortex XDR agent detects malicious causality
chains:
• Block (default)—Block all processes and threads in the event chain up to the CGO.
• Report—Allow the acvity but report it to Cortex XDR.
• Disabled—Disable the module and do not analyze or report the acvity.
2. Define whether to quaranne the CGO when the Cortex XDR agent detects a malicious
event chain.
• Enabled—Quaranne the CGO if the file is not signed by a highly trusted signer.
When the CGO is signed by a highly trusted signer or powershell.exe, wscript.exe,
cscript.exe, mshta.exe, excel.exe, word.exe or powerpoint.exe, the Cortex XDR agent
Endpoint Security
parses the command-line arguments and instead quarannes any scripts or files called
by the CGO.
• Disabled (default)—Do not quaranne the CGO of an event chain nor any scripts or
files called by the CGO.
3. (Windows only, requires a Cortex XDR agent 7.2 or a later release) Define the Acon
Mode for Vulnerable Drivers Protecon.
Behavioral threat protecon rules can also detect aempts to load vulnerable drivers. As
with other rules, Palo Alto Networks threat researchers can deliver changes to vulnerable
driver rules with content updates.
• Block (default)—Block all aempts to run vulnerable drivers.
• Report—Allow vulnerable drivers to run but report the acvity.
4. (Oponal) Add files that you do not want the Cortex XDR agent to terminate when a
malicious causality chain is detected to your allow list. The allow list does not apply to
vulnerable drivers.
1. +Add a file path.
2. Enter the file path you want to exclude from evaluaon. Use ? to match a single
character or * to match any string of characters.
3. Click the checkmark to confirm the file path.
4. Repeat the process to add any addional file paths to your allow list.
STEP 5 | (Windows only) Respond to Malicious Causality Chains.

When the Cortex XDR agent idenfies a remote network connecon that aempts to perform
malicious acvity—such as encrypt endpoint files—the agent can automacally block the IP
address to close all exisng communicaon, and block new connecons 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 Acon Center, as well as
unblock them to re-enable communicaon as appropriate.
This module is supported with Cortex XDR agent 7.3.0 and later release.
1. Select the Acon Mode to take when the Cortex XDR agent detects remote malicious
causality chains:
• Enabled (default)—Terminate connecon and block IP address of the remote
connecon.
• Disabled—Do not block remote IP addresses.
2. To allow specific and known safe IP address or IP address ranges that you do not want
the Cortex XDR to block, add these IP addresses to your allow list.
+Add and then specify the IP address.
Endpoint Security
STEP 6 | (Windows only) Configure Ransomware Protecon.

1. Define the Acon mode to take when the Cortex XDR agent detects ransomware
acvity locally on the endpoint or in pre-defined network folders:
• Block (default)—Block the acvity.
2. Choose whether you want the Cortex XDR agent to Quaranne Malicious Process when
ransomware is detected.
The quaranne opon is only available if the Acon mode is Block.
3. Configure the ransomware module Protecon mode.
By default, the protecon mode is set to Normal where the decoy files on the endpoint
are present, but do not interfere with benign applicaons and end user acvity on the
endpoint. If you suspect your network has been infected with ransomware and need to
provide beer coverage, you can apply the Aggressive protecon mode. The aggressive
mode exposes more applicaons in your environment to the Cortex XDR agent decoy
files, while also increasing the likelihood that benign soware is exposed to decoy files,
raising false ransomware alerts, and impairing user experience.
STEP 7 | (Windows only) Configure the Cortex XDR agent to Prevent Malicious Child Process
Execuon.
1. Select the Acon Mode to take when the Cortex XDR agent detects malicious child
process execuon:
• Block—Block the acvity.
2. To allow specific processes to launch child processes for legimate purposes, add the
child process to your allow list with oponal execuon criteria.
+Add and then specify the allow list criteria including the Parent Process Name, Child
Process Name, and Command Line Params. Use ? to match a single character or * to
match any string of characters.
If you are adding child process evaluaon criteria based on a specific security
event, the event indicates both the source process and the command line
parameters in one line. Copy only the command line parameter for use in the
profile.
STEP 8 | (Windows and Mac only) Enable endpoint file scanning.

Periodic scanning enables you to scan endpoints on a reoccurring basis without waing for
malware to run on the endpoint. Periodic scanning is persistent, and if the scan is scheduled
to start while the endpoint is powered-off, then scan will be iniated when the endpoint
Endpoint Security
is powered-on again. The scheduling of future scans is not affected by this delay. To beer
understand how the agent scans the endpoint, refer to Scan an Endpoint for Malware.
When periodic scanning is enabled in your profile, the Cortex XDR agent iniates an
inial scan when it is first installed on the endpoint, regardless of the periodic scanning
scheduling me.
1. Configure the Acon Mode for the Cortex XDRagent to periodically scan the endpoint
for malware: Enabled to scan at the configured intervals, Disabled (default) if you don’t
want the Cortex XDR agent to scan the endpoint.
2. To configure the scan schedule, set the frequency (Run Weekly or Run Monthly) and day
and me at which the scan will run on the endpoint.
Just as with an on-demand scan, a scheduled scan will resume aer a reboot, process
interrupon, or operang system crash.
3. (Windows only) To include removable media drives in the scheduled scan, enable the
Cortex XDR agent to Scan Removable Media Drives.
4. Add folders you your allow list to exclude them from examinaon.
1. Add (+) a folder.
2. Enter the folder path. Use ? to match a single character or * to match any string of
characters in the folder path (for example, C:\*\temp).
3. Press Enter or click the check mark when done.
STEP 9 | (Windows Vista and later Windows releases) Enable Password The Protecon.
Select Enabled to enable the Cortex XDR agent to prevent aacks that use the Mimikatz
tool to extract passwords from memory. When set to Enabled, the Cortex XDR agent silently
prevents aempts to steal credenals (no noficaons are provided when these events occur).
The Cortex XDR agent enables this protecon module following the next endpoint reboot. If
you don’t want to enable the module, select Disabled.
This module is supported with Traps agent 5.0.4 and later release.
STEP 10 | (Windows only) Configure the Network Packet Inspecon Engine.

By analyzing the network packet data, the Cortex XDR agent can detect malicious behavior
already at the network level and provide protecon to the growing corporate network
boundaries. The engine leverages both Palo Alto Networks NGFW content rules, and new
Endpoint Security
Cortex XDR content rules created by the Research Team which are updated through the
security content.
1. Define the Acon mode to take when the Cortex XDR agent detects malicious behavior:
• Terminate Session (default)—Drop the malicious connecons. In case of an outgoing
connecon, also terminate all associated processes.
• Report—Allow the packets in your network but report it to Cortex XDR.
STEP 11 | (Linux only) Enable Local File Threat Examinaon.

The Local Threat-Evaluaon Engine (LTEE) enables the Cortex XDR agent to detect webshells
and oponally quaranne malicious PHP files on the endpoint.
1. Select the Acon Mode to take when the Cortex XDR agent detects the malicious
behavior.
• Enable—Enable the Cortex XDR agent to analyze the endpoint for PHP files arriving
from the web server and alert of any malicious PHP scripts.
• Disable—Disable the module and do not analyze or report the acvity.
2. Quaranne malicious files.
When Enabled, the Cortex XDR agents quaranne malicious PHP files on the endpoint.
The agent quarannes newly created PHP files only, and does not quaranne updated
files.
3. (Oponal) Add files and folders to your allow list to exclude them from examinaon.
1. +Add a file or folder.
* to match files and folders containing a paral name. To match a folder, you must
terminate the path with * to match all files in the folder (for example, /usr/bin/*).
3. Repeat to add addional files or folders.
Endpoint Security
STEP 12 | (Linux only) Configure Reverse Shell Protecon.

The Reverse Shell Protecon module enables the Cortex XDR agent to detect and oponally
block aempts to redirect standard input and output streams to network sockets.
1. Define the Acon Mode to take when the Cortex XDR agent detects the malicious
behavior.
• Block—Block the acvity.
2. (Oponal) Add processes to your allow list that must redirect streams to network
sockets.
1. +Add a connecon.
2. Enter the path of the process, and the local and remote IP address and ports.
Use a wildcard to match a paral path name. Use a * to match any string of characters
(for example, */bash). You can also use a * to match any IP address or any port.
3. Press Enter or click the check mark when done.

WildFire® Analysis Concepts

• File Forwarding
• File Type Analysis
• Verdicts
• Local Verdict Cache
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 aer the limit resets. WildFire also limits sample sizes to 100MB. For more
informaon, see the WildFire documentaon.
For samples that the Cortex XDR agent reports, the agent first checks its local cache of hashes to
determine if it has an exisng 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 idenfied as malware, it is blocked. If the sample remains
unknown aer comparing it against exisng WildFire signatures, Cortex XDR forwards the sample
for WildFire analysis.
Endpoint Security
File Type Analysis

The Cortex XDR agent analyzes files based on the type of file, regardless of the file’s extension.
For deep inspecon and analysis, you can also configure your Cortex XDR to forward samples to
WildFire. A sample can be:
• Any Portable Executable (PE) file including (but not limited to):
• Executable files
• Object code
• FON (Fonts)
• Microso Windows screensaver (.scr) files
• Microso Office files containing macros opened in Microso Word (winword.exe) and
Microso Excel (excel.exe):
• Microso Office 2003 to Office 2016—.doc and .xls
• Microso Office 2010 and later releases—.docm, .docx, .xlsm, and .xlsx
• Dynamic-link library file including (but not limited to):
• .dll files
• .ocx files
• Android applicaon package (APK) files
• Mach-o files
• DMG files
• Linux (ELF) files
For informaon on file-examinaon sengs, see Add a New Malware Security Profile.
Verdicts
WildFire delivers verdicts to idenfy samples it analyzes as safe, malicious, or unwanted (grayware
is considered obtrusive but not malicious):
• Unknown—Inial 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
idenfied as malware, WildFire generates and distributes a signature to prevent against 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).
When WildFire is not available or integraon is disabled, the Cortex XDR agent can also assign a
local verdict for the sample using addional methods of evaluaon: When the Cortex XDR agent
performs local analysis on a file, it uses paern-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:
Endpoint Security
• 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 aempt to
run on the endpoint inits 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 protecon
is enabled (see Add a New Agent Sengs Profile), the local cache is accessible only by the Cortex
XDR agent and cannot be changed.
Each me a file aempts 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 excepon. Hash excepons take precedence over any addional 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.
If Cortex XDR does not have a verdict for the file, it queries WildFire and oponally submits the
file for analysis. While the Cortex XDR agent aempts waits for an official WildFire verdict, it can
use File Analysis and Protecon Flow to evaluate the file. Aer Cortex XDRreceives the verdict it
responds to the Cortex XDR agent that requested the verdict.
For informaon on file-examinaon sengs, see Add a New Malware Security Profile.
Add a New Restricons Security Profile

Restricons security profiles limit the surface of an aack on a Windows endpoint by defining
where and how your users can run files.
configuraon for each restricons capability. To customize the configuraon for specific Cortex
XDRagents, configure a new Restricons security profile and assign it to one or more policy rules.
To define a Restricons security profile:
Endpoint Security

2. Select the plaorm to which the profile applies and Restricons as the profile type.
3. Click Next.
STEP 2 | Define the basic sengs.

STEP 3 | Configure each of the Restricons Endpoint Protecon Capabilies.

1. Configure the acon to take when a file aempts to run from a specified locaon.
• Block—Block the file execuon.
• Nofy—Allow the file to execute but nofy the user that the file is aempng to run
from a suspicious locaon. The Cortex XDR agent also reports the event to Cortex
XDR.
• Report—Allow the file to execute but report it to Cortex XDR.
• Disabled—Disable the module and do not analyze or report execuon aempts from
restricted locaons.
2. Add files to your allow list or block list, as needed.
The type of protecon capability determines whether the capability supports an allow
list, block list, or both. With an allow list, the acon mode you configure applies to all the
paths except for those that you specify. With a block list, the acon applies only to the
paths that you specify.
1. +Adda file or folder.
a wildcard to match a paral 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\*).

Endpoint Security
Manage Endpoint Security Profiles

Aer you customize your Endpoint Security Profiles, you can manage these profiles from the
Profiles page as needed.
View informaon about your security profiles.

The following table displays the fields that are available on the Profiles page in alphabecal
order. The table includes both default fields and addional fields that are available in the
column manager.
Field Descripon
Associated Targets The targets the profile applies to.
Created By Administrave user who created the security

profile.
Created Time Date and me at which the security profile was
created.
Descripon Oponal descripon entered by an administrator

to describe the security profile.
Modificaon Time Date and me at which the security profile was
modified.
Modified By Administrave user who modified the security

profile.
Name Name provided to idenfy the security profile.
Plaorm Plaorm type of the security profile.
Summary Summary of security profile configuraon.
Type Security profile type.
Usage Count Number of policy rules that use the profile.
Edit a security profile.

1. From Endpoints > Policy Management > Prevenon > Profiles, right-click the security
profile and select Edit.
2. Make your changes and then Save the security profile.
Endpoint Security
Export profile.
profile and select Export Profile.
2. Verify the profile you want to export.
Duplicate a security profile.

profile and select Save as New.
2. Make your changes and then Create the security profile.
3. Populate a new policy rule with a security profile.
View the security policy rules that use a security profile.

From Endpoints > Policy Management > Prevenon > Profiles, right-click the security profile
and select View policy Rules.
Cortex XDR displays the policy rules that use the profile.
Populate a new policy rule with a security profile.

profile and Create a new policy rule using this profile.
Cortex XDR automacally populates the Plaorm selecon based on your security
profile configuraon and assigns the security profile based on the security profile type.
2. Enter a descripve Policy Name and oponal descripon for the policy rule.
3. Assign any addional security profiles that you want to apply to your policy rule, and
select Next.
4. Select the target endpoints for the policy rule or use the filters to define criteria for the
policy rule to apply, and then select Next.
5. Review the policy rule summary, and if everything looks good, select Done.
Delete a security profile.

1. If necessary, delete or detach any policy rules that use the profile before aempng to
delete it.
2. From Endpoints > Policy Management > Prevenon > Profiles, idenfy the security
profile that you want to remove.
The Usage Count should have a 0 value.
3. Right-click the security profile and select Delete.
4. Confirm the deleon and you are done.
Endpoint Security
Customizable Agent Sengs

Each Agent Sengs Profile provides a tailored list of sengs that you can configure for the
plaorm that you select.
The following table describes these customizable sengs and indicates which plaorms support
the seng (a dash (—) indicates the seng is not supported).
In addion to the customizable Agent Sengs Profiles, you can also:
• Configure Global Agent Sengs that apply to all the endpoints in your network.
• Configure Hardened Endpoint Security protecons that leverage exisng mechanisms and
added capabilies to reduce the aack surface on your endpoints.
Seng Windows Mac Linux Android
Agent Profiles
Disk Space —
Customize the amount
of disk space the Cortex
XDR agent uses to store
logs and informaon
about events.
User Interface — —
Determine whether
and how end users can
access the Cortex XDR
console.
Traps Tampering — —
Protecon
Prevent users from
tampering with the
Cortex XDR agent
components by
restricng access.
Uninstall Password — —
Change the default
uninstall password to
prevent unauthorized
users from uninstalling
the Cortex XDR agent
soware.
Endpoint Security
Windows Security — — —
Center Configuraon
Configure your Windows
Security Center
preferences to allow
registraon with the
Microso Security
Center, to allow
registraon with
automated Windows
patch installaon, or to
disable registraon.
Change forensic data
collecon and upload
preferences.
XDR Pro Endpoints —

Enable the Cortex XDR
Pro agent capabilies,
including enhanced data
collecon, advanced
responses, and available
Pro add-ons.
Requires a Cortex XDR
Pro per Endpoint license.
Response Acons —
Manual response acons
that you can take on
the endpoint aer a
malicious file, process,
or behavior is detected.
For example, you can
terminate a malicious
process, isolate the
infected endpoint from
the network, quaranne
a malicious file, or
perform addional
acon as necessary to
remediate the endpoint.
Content Updates —
Endpoint Security

Configure how the
Cortex XDR agent
performs content
updates on the endpoint:
whether to download
the content directly from
Cortex XDR or from a
peer agent, whether to
perform immediate or
delayed updates, and
whether to perform
automac content
updates or connue
using the current content
version.
Agent Auto Upgrade —

Enable the agent to
perform automac
upgrades whenever a
new agent version is
released. You can choose
to upgrade only to minor
versions in the same line,
only to major versions, or
both.
Upload Using Cellular — — —

Data
Enable Android
endpoints to send
unknown APK files for
inspecon as soon as
a user connects to a
cellular network.
Global Agent Configuraons
Global Uninstall —
Password
Set the uninstall
password for all agents in
the system.
Content Bandwidth —
Management
Endpoint Security

Configure the total
bandwidth to allocate
for content update
distribuon within your
organizaon.
Agent Auto Upgrade —

Configure the Cortex
XDR agent auto upgrade
scheduler and number of
parallel upgrades.
Endpoint Data Collecon —

Configure the type of
informaon collected
by the Cortex XDR
Agent for Vulnerability
Assessment and Host
insights.
See Hardened Endpoint
Security for the list of
all operang systems
that support these
capabilies.
Advanced Analysis —
Enable Cortex XDR to
automacally upload
alert data for secondary
verdict verificaon and
security policy tuning.
Add a New Agent Sengs Profile

Agent Sengs Profiles enable you to customize Cortex XDR agent sengs for different plaorms
and groups of users.
Endpoint Security

2. Select the plaorm to which the profile applies and Agent Sengs as the profile type.
3. Click Next.

STEP 3 | (Windows, Mac, and Linux only) Configure the Disk Space to allot for Cortex XDR agent logs.
Specify a value in MB from 100 to 10,000 (default is 5,000).
STEP 4 | (Windows and Mac only) Configure User Interface opons for the Cortex XDR console.
By default, Cortex XDR uses the sengs specified in the default agent sengs profile and
displays the default configuraon in parenthesis. When you select a seng other than the
default, you override the default configuraon for the profile.
• Tray Icon—Choose whether you want the Cortex XDR agent icon to be Visible (default) or
Hidden in the noficaon area (system tray).
• XDR Agent Console Access—Enable this opon to allow access to the Cortex XDR console.
• XDR Agent User Noficaons—Enable this opon to operate display noficaons in the
noficaons area on the endpoint. When disabled, the Cortex XDR agent operates in silent
mode where the Cortex XDR agent does not display any noficaons in the noficaon
area. If you enable noficaons, you can use the default noficaon messages, or provide
custom text for each noficaon type. You can also customize a noficaon footer.
• Live Terminal User Noficaons—Choose whether to Nofy the end user and display a
pop-up on the endpoint when you iniate a Live Terminal session. For Cortex XDR agents
7.3 and later releases only, you can choose to Request end-user permission to start the
session. If the end user denies the request, you will not be able to iniate a Live Terminal
session on the endpoint.
• (Cortex XDR agent 7.3 and later releases only) Live Terminal Acve Session Indicaon—
Enable this opon to display a blinking light ( ) on the tray icon (or in the status bar for
Mac endpoints) for the duraon of the remote session to indicate to the end user that a live
terminal session is in progress.
STEP 5 | (Android only) Configure network usage preferences.

When the opon to Upload Using Cellular Data is enabled, the Cortex XDR agent uses cellular
data to send unknown apps to the Cortex XDR for inspecon. Standard data charges may
apply. When this opon is disabled, the Cortex XDR agent queues any unknown files and sends
Endpoint Security
them when the endpoint connects to a Wi-Fi network. If configured, the data usage seng on
the Android endpoint takes precedence over this configuraon.
STEP 6 | (Windows and Mac only) Configure Agent Security opons that prevent unauthorized access
or tampering with the Cortex XDR agent components.
Use the default agent sengs or customize them for the profile. To customize agent security
capabilies:
1. Enable XDR Agent Tampering Protecon.
2. (Windows only) By default, the Cortex XDR agent protects all agent components,
however you can configure protecon more granularly for Cortex XDR agent services,
processes, files, and registry values. With Traps 5.0.6 and later releases, when protecon
is enabled, access will be read-only. In earlier Traps releases, enabling protecon disables
all access to services, processes, files, and registry values.
STEP 7 | (Windows and Mac only) Set an Uninstall Password.

Define and confirm a password the user must enter to uninstall the Cortex XDR agent. The
uninstall password is encrypted using encrypon algorithm (PBKDF2) when transferred
between Cortex XDR and Cortex XDR agents. Addionally, the uninstall password is used to
protect tampering aempts when using Cytool commands.
The default uninstall password is Password1. A new password must sasfy the Password
Strength indicator requirements:
• Contain eight or more characters.
• Contain English leers, numbers, or any of the following symbols: !()-._`~@#"'.
STEP 8 | (Windows only) Configure Windows Security Center Integraon.

The Windows Security Center is a reporng tool that monitors the system health and security
state of Windows endpoints on Windows 7 and later releases:
• Enabled—The Cortex XDR agent registers with the Windows Security Center as an official
Anvirus (AV) soware product. As a result, Windows shuts down Microso Defender on
the endpoint automacally, except for endpoints that are running Windows Server versions.
To avoid performance issues, Palo Alto Networks recommends that you disable or remove
Endpoint Security
Windows Defender from endpoints that are running Windows Server versions and where
the Cortex XDR agent is installed.
• Enabled (No Patches)—For the Cortex XDR agent 5.0 release only, select this opon if you
want to register the agent to the Windows Security Center but prevent from Windows to
automacally install Meltdown/Spectra vulnerability patches on the endpoint.
• Disabled—The Cortex XDR agent does not register to the Windows Acon Center. As a
result, Windows Acon Center could indicate that Virus protecon is Off, depending on
other security products that are installed on the endpoint.
When you Enable the Cortex XDR agent to register to the Windows Security Center,
Windows shuts down Microso Defender on the endpoint automacally. If you
sll want to allow Microso Defender to run on the endpoint where Cortex XDR
is installed, you must Disable this opon. However, Palo Alto Networks does not
recommend running Windows Defender and the Cortex XDRagent on the same
endpoint since it might cause performance issues and incompability issues with
Global Protect and other applicaons.
STEP 9 | Configure Alerts Data collecon opons.

When the Cortex XDR agent alerts on process-related acvity on the endpoint, the Cortex
XDR agent collects the contents of memory and other data about the event in what is known
as a alert data dump file. You can customize the Alert Data Dump File Size—Small, Medium, or
Full (the largest and most complete set of informaon)—and whether to Automacally Upload
Alert Data Dump File to Cortex XDR. During event invesgaon, if automac uploading of the
alert data dump file was disabled, you can manually retrieve the data.
STEP 10 | (Requires a Cortex XDR Pro per Endpoint license) Enable and configure Cortex XDR Pro
Endpoint capabilies on the endpoint, including enhanced data collecon, advanced
responses, and available Pro add-ons.
1. Enable XDR Pro Endpoints Capabilies to configure which Pro capabilies to acvate on
the endpoint.
The Pro features are hidden unl you enable the capability. Enabling this capability
consumes a Cortex XDR Pro per Endpoint license.
2. (Supported on Cortex XDR agent 6.0 or a later for Windows endpoints and Cortex XDR
agent 6.1 or later for Mac and Linux endpoints) Enable Monitor and Collect Enhanced
Endpoint Data.
By default, the Cortex XDR agent collects informaon about events that occur on the
endpoint. If you enable Behavioral Threat Protecon in a Malware Security profile, the
Cortex XDR agent also collects informaon about all acve file, process, network, and
registry acvity on an endpoint (see Endpoint Data Collected by Cortex XDREndpoint
Data Collecon). When you enable the Cortex XDR agent to monitor and collect
enhanced endpoint data, you enable Cortex XDR to share the detailed endpoint
informaon with other Cortex apps. The informaon can help to provide the endpoint
context when a security event occurs so that you can gain insight on the overall event
scope during invesgaon. The event scope includes all acvies that took place during
Endpoint Security
an aack, the endpoints that were involved, and the damage caused. When disabled, the
Cortex XDR agent will not share endpoint acvity logs.
3. (Requires Host Insights add-on and Cortex XDR agent 7.1 or later releases) Enable Host
Insights Capabilies.
• Enable Endpoint Informaon Collecon to allow the Cortex XDR agent to collect
Host Inventory informaon such as users, groups, services, drivers, hardware, and
network shares, as well as informaon about applicaons installed on the endpoint,
including CVE and installed KBs for Vulnerability Assessment.
• (Supported on Cortex XDR agent 7.2 or a later for Windows endpoints and Cortex
XDR agent 7.3 or later for Mac endpoints) Enable File Search and Destroy Acon
Mode to allow the Cortex XDR agent to collect detailed informaon about files on the
endpoint to create a files inventory database. The agent locally monitors any acons
performed on these files and updates the local files database in real-me.
With this opon you can also choose the File Search and Destroy Monitored File
Types where Cortex XDR monitors all file types or only common file types. If you
choose Common file types, Cortex XDR monitors the following file types:
• Windows—bat, bmp, c, cab, cmd, cpp, csv, db, dbf, doc, docb,
docm, docx, dotm, dotx, dwg, dxf, exe, exif, gif, gz, jar,
java, jpeg, jpg, js, keynote, mdb, mdf, msi, myd, pages,
pdf, png, pot, potm, ppam, pps, ppsm, ppsx, ppt, pptm,
pptx, ps1, pub, py, rar, rtf, sdf, sldm, sldx, sql, sqlite,
sqlite3, svg, tar, txt, url, vb, vbe, vbs, vbscript, vsd,
vsdx, wsf, xla, xlb, xlm, xls, xlsm, xlsx, xlt, xltm, xltx,
xps, zip, and 7z.
• Mac—acm, apk, ax, bat, bin, bundle, csv, dll, dmg, doc,
docm, docx, dylib, efi, hta, jar, js, jse, jsf, lua, mpp,
mppx, mui, o, ocx, pdf, pkg, pl, plx, pps, ppsm, ppsx, ppt,
pptm, pptx, py, pyc, pyo, rb, rtf, scr, sh, vds, vsd, wsf,
xls, xlsm, xlsx, xsdx, and zip.
Addionally, you can exclude files that exist under a specific local path on the
endpoint from inclusion in the files database.
4. (Requires Forensics Add-on and Cortex XDR agent 7.4 or a later for Windows endpoints)
Enable Monitor and Collect Forensics Data allow the Cortex XDR agent to collect
detailed informaon about what happened on your endpoint to create a forensics
Endpoint Security
database. Define the following if to enable collecon and in what me intervals of the
following enty types:
• Process Execuon
• File Access
• Persistence
• Command History
• Network
• Remote Access
• Search Collecons
Data collected by the agent is displayed in the Forensic Data Analysis page.
5. (Supported on Cortex XDR agent 7.5 or a later for Windows endpoints and requires
to15) Enable Distributed Network Scan to allow the Cortex XDR agent to scan your
network using Ping to provide updated idenfiers of your unmanaged network assets,
such as IP addresses and OS plaorms. The result scans can be viewed in the Asset
Management table.
1. Enable the Acon Mode.
2. In Scan Mode, select Nmap or Ping.
3. Select is you want any Excluded IP Address Ranges. The IP address ranges are
populated from your Network Configuraons.
4. If you selected Nmap, enable or disable OS Fingerprinng.
STEP 11 | (Windows and Mac only) Response Acons.

If you need to isolate an endpoint but want to allow access for a specific applicaon , add the
process to the Network Isolaon Allow List. The following are consideraons to the allow list:
• When you add a specific applicaon to your allow list from network isolaon, the
Cortex XDR agent connues to block some internal system processes. This is because
some applicaons, for example ping.exe, can use other processes to facilitate network
communicaon. As a result, if the Cortex XDR agent connues to block an applicaon
you included in your allow list, you may need to perform addional network monitoring to
determine the process that facilitates the communicaon, and then add that process to the
allow list.
• (Windows) For VDI sessions, using the network isolaon response acon can disrupt
communicaon with the VDI host management system thereby halng access to the VDI
session. As a result, before using the response acon you must add the VDI processes and
corresponding IP addresses to your allow list.
1. +Add an entry to the allow list.
2. Specify the Process Path you want to allow and the IPv4 or IPv6 address of the endpoint.
Use the * wildcard on either side to match any process or IP address. For example, specify *
as the process path and an IP address to allow any process to run on the isolated endpoint
with that IP address. Conversely, specify * as the IP address and a specific process path to
allow the process to run on any isolated endpoint that receives this profile.
3. Click the check mark when finished.
Endpoint Security
agent 7.3 or later for Mac and Linux endpoints) Specify the Content Configuraon for your
Cortex XDR agents.
• Content Auto-update—By default, Cortex XDR agent always retrieves the most updated
content and deploys it on the endpoint so it is always protected with the latest security
measures. However, you can Disable the automac content download. Then, the agent
stops retrieving content updates from the Cortex XDR Server and keeps working with the
current content on the endpoint.
• If you disable content updates for a newly installed agent, the agent will retrieve
the content for the first me from Cortex XDR and then disable content updates
on the endpoint.
• When you add a Cortex XDR agent to an endpoints group with disabled content
auto-upgrades policy, then the policy is applied to the added agent as well.
• Content Rollout—The Cortex XDR agent can retrieve content updates Immediately as they
are available, or aer a pre-configured Delayed period. When you delay content updates,
the Cortex XDR agent will retrieve the content according to the configured delay. For
example, if you configure a delay period of two days, the agent will not use any content
released in the last 48 hours.
If you disable or delay automac-content updates provided by Palo Alto Networks, it

may affect the security level in your organizaon.
STEP 13 | Enable Agent Auto Upgrade for your Cortex XDR agents.
To ensure your endpoints are always up-to-date with the latest Cortex XDR agent release,
enable automac agent upgrades.
1. Select the Automac Upgrade Scope:
• Latest agent release
• Only maintenance release
• Only maintenance release in a specific version
• Upgrade to a specific version
2. Select the Upgrade Rollout:
• Immediate
• Delayed—Specify the Delay Period In Days using a numeric value. Oponal values are
7 through 45.
To control the agent auto upgrade scheduler and number of parallel upgrades in your
network, see Configure Global Agent Sengs.
Automac upgrades are not supported with non-persistent VDI and temporary
sessions.
3. (Oponal) For Crical Environment (CE) versions, make sure to select if you want to
upgrade your CE versions only within the CE lines. It can take up to 15 minutes for new
and updated auto-upgrade profile sengs to take effect on your endpoints.
Endpoint Security
agent 7.3 or later for Mac and Linux endpoints) Specify the Download Source for agent and
content updates.
To reduce your external network bandwidth loads during updates, you can choose the
Download Source(s) from which the Cortex XDR agent retrieves agent release upgrades and
content updates: from a peer agent in the local network, from the Palo Alto Networks Broker
VM, or directly from the Cortex XDR server. If all opons are selected in your profile, then the
aempted download order is first using P2P, then from Broker VM, and lastly from the Cortex
Server.
• (Requires Cortex XDR agents 7.4 and later for P2P agent upgrade) P2P—Cortex XDR
deploys serverless peer-to-peer P2P distribuon to Cortex XDR agents in your LAN
network by default. Within the six hour randomizaon window during which the Cortex
XDR agent aempts to retrieve the new version, it will broadcast its peer agents on the
same subnet twice: once within the first hour, and once again during the following five
hours. If the agent did not retrieve the files from other agents in both queries, it will proceed
to the next download source defined in your profile.
To enable P2P, you must enable UDP and TCP over the defined PORT in Download Source.
By default, Cortex XDR uses port 33221. You can configure another port number.
• (Requires Cortex XDR agents 7.4 and later releases and Broker VM 12.0 and later) Broker
VM—If you have a Palo Alto Networks Broker VM in your network, you can leverage the
Local Agent Sengs applet to cache release upgrades and content updates. When enabled
and configured, the Broker retrieves from Cortex XDR the latest installers and content
every 15 minutes and stores them for a 30-days retenon period since an agent last asked
for them. If the files were not available on the Broker VM at the me of the ask, the agent
proceeds to download the files directly from the Cortex XDR server.
If you enable the Broker download opon, proceed to select one or more available brokers
from the list. Cortex XDR enables you to select only brokers that are connected and for
which the caching is configured. When you select mulple brokers, the agent chooses
randomly which broker to use for each download request.
• Cortex Server—To ensure your agents remain protected, the Cortex Server download source
is always enabled to allow all Cortex XDR agents in your network to retrieve the content
directly from the Cortex XDR server on their following heartbeat.
Limitaons in the content download process:

• When you install the Cortex XDRagent, 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 sengs) to retrieve the
content for the first me. During this me, your endpoint is not protected.
• When you upgrade a Cortex XDR agent to a newer Cortex XDR agent version, if the
new agent cannot use the content version running on the endpoint, then the new
content update will start within one minute in P2P and within five minutes from
Cortex XDR.
Endpoint Security
STEP 15 | Enable Network Locaon Configuraon for your Cortex XDR agents.
(Requires Cortex XDR agents 7.1 and later releases) If you configure host firewall rules in your
network, you must enable Cortex XDR to determine the network locaon of your device, as
follows:
1. A domain controller (DC) connecvity test— When Enabled, the DC test checks whether
the device is connected to the internal network or not. If the device is connected to the
internal network, then it is in the organizaon. Otherwise, if the DC test failed or returned
an external domain, Cortex XDR proceeds to a DNS connecvity test.
2. A DNS test—In the DNS test, the Cortex XDR agent submits a DNS name that is known
only to the internal network. If the DNS returned the pre-configured internal IP, then the
device is within the organizaon. Otherwise, if the DNS IP cannot be resolved, then the
device is located elsewhere. Enter the IP Address and DNS Server Name for the test.
If the Cortex XDR agent detects a network change on the endpoint, the agent triggers the
device locaon test, and re-calculates the policy according to the new locaon.
STEP 16 | (Supported for Cortex XDR 7.7 or later for Linux only) Define the Agent Operaon Mode.
1. Select with which Mode you want the Cortex XDR to run the Linux endpoint. You can
select either Kernel (default) or User Space.
2. Enable whether you want to run User Space mode when Kernel mode is unavailable. By
default, the User Space fall-back is disabled.

Configure Global Agent Sengs

On top of customizable Agent Sengs Profiles for each Operang System and different endpoint
targets, you can set global Agent Configuraons that apply to all the endpoints in your network.
STEP 1 | From the Cortex XDR management console, select Sengs > Configuraons > General >
Agent Configuraons.
STEP 2 | Set global uninstall password.

The uninstall password is required to remove a Cortex XDR agent and to grant access to 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 exisng 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 seng a different password for those agents in the Agent Sengs
profile. The selected password must sasfy the requirements enforced by Password Strength
indicator.
Endpoint Security
STEP 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 consumpon by adjusng the bandwidth it is allocated. Based on the
number of agents you want to update with content and upgrade packages, acve 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 opmized performance and reduced
bandwidth consumpon, it is recommended that you install and update new agents with
Cortex XDR agents 7.3 and later that 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. When you enable
minor content version updates, the Cortex XDR agent receives minor content updates,
starng with the next content releases. To learn more about the minor content numbering
format, refer to the About Content Updates topic.
STEP 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 calculaon, Cortex XDR recommends the opmal value of Mbps based on the number
of acve agents in your network, and including overhead consideraons for large content
updates. Cortex XDR will verify that agents aempng to download the content update are
within the allocated bandwidth before beginning the distribuon. If the bandwidth has reached
its cap, the download will be refused and the agents will aempt again at a later me. Aer you
set the bandwidth, Save the configuraon.
STEP 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
automac upgrade process in your network. To beer control the rollout of a new Cortex
XDR agent release in your organizaon, during the first week only a single batch of agents
is upgraded. Aer that, auto-upgrades connue 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 me range. The minimum range is four hours.
Endpoint Security
STEP 6 | Configure automated Advanced Analysis of Cortex XDR Agent alerts raised by exploit
protecon modules.
Advanced Analysis is an addional verificaon method you can use to validate the verdict
issued by the Cortex XDR agent. In addion, Advanced Analysis also helps Palo Alto Networks
researchers tune exploit protecon modules for accuracy.
To iniate addional 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 automacally
retrieve the files.
Aer Cortex XDR receives the data, it automacally 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 Addional data view for the data retrieval acon on the Acon
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 automacally create and
distribute excepons based on the Advanced Analysis results.
1. Configure the desired opons:
• Enable Cortex XDR to automacally upload defined alert data files for advanced
analysis. Advanced Analysis increases the Cortex XDR exploit protecon module
accuracy
• Automacally apply Advanced Analysis excepons to your Global Excepons
list. This will apply all Advanced Analysis excepons suggested by Cortex XDR,
regardless of the alert data file source
2. Save the Advanced Analysis configuraon.
STEP 7 | Configure the Cortex XDR Agent license revocaon and deleon period.
This configuraon applies to standard endpoints only and does not impact the license status of
agents for VDIs or Temporary Sessions.
1. Configure the desired opons:
• Connecon Lost (Days)—Configure the number of days aer which the license should
be returned when an agent loses the connecon to Cortex XDR. Default is 30 days;
Range is 2 to 60 days.
• Agent Deleon (Days)—Configure the number of days aer 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 Connecon Lost
value.
2. Save the Agent Status configuraon.
STEP 8 | Enable WildFire analysis scoring for files with Benign verdicts.
The WildFire analysis score for files with 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 me of tesng gets a lower confidence Benign score. To
add an addional verificaon method to such files, enable this seng. Then, when Cortex XDR
receives a Benign Low Confidence verdict, the agent enforces the Malware Security profile
Endpoint Security
sengs 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
installaons, and exisng security policies. It could take up to a week to take effect on
exisng agents in your environment pending agent caching.
STEP 9 | Enable Informave BTP Alerts.

Behavioral threat protecon (BTP) alerts have been given unique and informave names and
descripons, to provide immediate clarity into the events without having to drill down into
each alert. Enable to display the informave BTP rule alert names and descripons. Aer you
update the sengs, new alerts will include the changes while already exisng alerts will remain
unaffected.
If you have any Cortex XDR filters, starring policies, exclusion policies, scoring rules,
log forwarding queries, or automaon rules configured for XSOAR/3rd party SIEM, we
advise you to update those to support the changes before acvang the feature. For
example, change the query to include the previous descripon that is sll available in
the new descripon, instead of searching for an exact match.
Endpoint Data Collected by Cortex XDREndpoint Data Collecon

When the Cortex XDR agent raises an alert on endpoint acvity, a minimum set of metadata
about the endpoint is sent to the server as described in Metadata Collected for Cortex XDR Agent
Alerts.
When you enable behavioral threat protecon or EDR data collecon in your endpoint security
policy, the Cortex XDR agent can also connuously monitor endpoint acvity for malicious event
chains idenfied by Palo Alto Networks. The endpoint data that the Cortex XDR agent collects
when you enable these capabilies varies by the plaorm type.
• EDR Data Collected for Windows Endpoints
• EDR Data Collected for Mac Endpoints
• EDR Data Collected for Linux Endpoints
Metadata Collected for Cortex XDR Agent Alerts

When the Cortex XDR agent raises an alert on endpoint acvity, the following metadata is sent to
the server:
Field Descripon
Absolute Timestamp Kernel system me
Relave Timestamp Upme since the computer booted
Thread ID ID of the originang thread
Process ID ID of the originang process
Endpoint Security
Field Descripon
Process Creaon Time Part of process unique ID per boot session (PID +
creaon me)
Sequence ID Unique integer per boot session
Primary User SID Unique idenfier of the user
Impersonang User SID Unique idenfier of the impersonang user, if applicable
EDR Data Collected for Windows Endpoints
Category Events Aributes
Executable metadata (Traps Process start • File size

6.1 and later)
• File access me
Files • Create • Full path of the modified

• Write file before and aer
modificaon
• Delete
• SHA256 and MD5 hash for
• Rename the file aer modificaon
• Move • SetInformaonFile for
• Modificaon (Traps 6.1 mestamps (Traps 6.1 and
and later) later)
• Symbolic links (Traps 6.1 • File set security (DACL)
and later) informaon (Traps 6.1 and
later)
• Resolve hostnames on local
network (Traps 6.1 and
later)
• Symbolic-link/hard-link
and reparse point creaon
(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)
Endpoint Security

• File size (Traps 6.1 and
later)
• File access me (Traps 6.1
and later)
Process • Create • Process ID (PID) of the

• Terminate parent process
• PID of the process
• Full path
• Command line arguments
• Integrity level to determine
if the process is running
with elevated privileges
• Hash (SHA256 and MD5)
• Signature or signing
cerficate details
Thread Injecon • Thread ID of the parent

thread
• Thread ID of the new or
terminang thread
• Process that iniated the
thread if from another
process
Network • Accept • Source IP address and port

• Connect • Desnaon IP address and
• Create port
• Listen • Failed connecon
• Close • Protocol (TCP/UDP)
• Bind • Resolve hostnames on local

network
Network Protocols • DNS request and UDP • Origin country

response • Remote IP address and port
• HTTP connect • Local IP address and port
• HTTP disconnect • Desnaon IP address and
• HTTP proxy parsing port if proxy connecon
• Network connecon ID
• IPv6 connecon status
(true/false)
Endpoint Security
Network Stascs • On-close stascs • Upload volume on TCP link

• Periodic stascs • Download volume on TCP
link
Traps sends stascs on
connecon close and
periodically while connecon
is open
Registry • Registry value: • Registry path of the

modified value or key
• Deleon
• Name of the modified value
• Set
or key
• Registry key:
• Data of the modified value
• Creaon
• Deleon
• Rename
• Addion
• Modificaon (set
informaon)
• Restore
• Save
Session • Log on • Interacve log-on to the

• Log off computer
• 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 User Detecon Detecon when a user is
later) present or idle per acve user
session on the computer.
Endpoint Security
Event Log See the Windows Event Logs table for the list of Windows
Event Logs that can be sent to the server.
In Traps 6.1.3 and later releases, Cortex XDR and Traps agents can send the following Windows
Event Logs to the server:
Table 17: Windows Event Logs
Path Provider Event IDs Descripon
Applicaon EMET
Applicaon Windows Error WER events for

Reporng applicaon crashes only
Applicaon Microso-Windows- 1511, 1518 User logging on with

User Profiles Service temporary profile (1511),
Cannot create profile
using temporary profile
(1518)
Applicaon Applicaon Error 1000 Applicaon crash/

hang events, similar to
WER/1001. These include
full path to faulng EXE/
Module
Applicaon Applicaon Hang 1002 Applicaon crash/

hang events, similar to
WER/1001. These include
full path to faulng EXE/
Module
Microso-Windows- 11, 70, 90 CAPI events Build Chain

CAPI2/Operaonal (11), Private Key accessed
(70), X509 object (90)
Microso-Windows- 3008 DNS Query Completed

DNS-Client/ (3008) without local
Operaonal machine na,e resoluon
events and without
enmpty name resoluon
events
Microso-Windows- 2004 Detect User-Mode drivers

DriverFrameworks- loaded - for potenal
BadUSB detecon
Endpoint Security

UserMode/
Operaonal
Microso-Windows- 4103, 4104, PowerShell execute block

PowerShell/ 4105, 4106 acvity (4103), Remote
Operaonal Command (4104), Start
Command (4105), Stop
Command (4106)
Microso-Windows- Microso-Windows- 106, 129, 141,

TaskScheduler/ TaskScheduler 142, 200, 201
Operaonal
Microso-Windows- 1024 Log aempted TS connect

TerminalServices- to remote server
RDPClient/
Operaonal
Microso-Windows- 1006, 1009 Modern Windows

Windows Defender/ Defender event provider
Operaonal Detecon events (1006
and 1009)
Microso-Windows- 1116, 1119 Modern Windows

Windows Defender/ Defender event provider
Operaonal Detecon events (1116
and 1119)
Microso-Windows- Microso-Windows- 2004, 2005, Windows Firewall With

Windows Firewall Windows Firewall 2006, 2009, Advanced Security Local
With Advanced With Advanced 2033 Modificaons (Levels 0, 2,
Security/Firewall Security 4)
Security 1102 Security Log cleared

events (1102)
Security 5142, 5144 Network Share create

(5142), Network Share
Delete (5144)
Security 4688 Process Create (4688)
Security Microso-Windows- Event log service events

Eventlog specific to Security
channel
Security 4880, 4881, CA Service Stopped

4896, 4898 (4880), CA Service Started
(4881), CA DB row(s)
Endpoint Security

deleted (4896), CA
Template loaded (4898)
Security 6272, 6280 RRAS events – only

generated on Microso
IAS server
Security Microso-Windows- 4624, 4625, Successful logon (4624),

Security-Auding 4634, 4647, Failed logon (4625),
4648, 4649, Logoff (4634), User
4672, 4768, iniated logoff (4647),
4769, 4770, Logon aempted, explicit
4771, 4776, credenals (4648), Replay
4778, 4800, aack (4649), Special
4801, 4802, privileges aempted
4803 login (4672), Kerberos
TGT request (4768),
Kerberos service cket
requested (4769),
Kerberos service cket
renewal (4770), Kerberos
pre-authencaon
failed (4771), Domain
controller validaon
aempt (4776), Session
was reconnected to a
Windows staon (4778),
Workstaon locked
(4800), Workstaon
unlocked (4801),
Screensaver was invoked
(4802), Screensaver was
dismissed (4803)
Security Microso-Windows- 4720, 4722, A user account was

Security-Auding 4723, 4724, created (4720), A user
4725, 4726, account was enabled
4727, 4728, (4722), An aempt
4729, 4731, was made to change
4732, 4733, an account's password
4735, 4737, (4723), An aempt was
4738, 4740, made to reset an account’s
4741, 4742, password (4724), A user
4743, 4754, account was disabled
4755, 4756, (4725), A user account
4757, 4764, was deleted (4726), Group
4765, 4766, creaons (4727, 4731,
4754), Group member
Endpoint Security

4767, 4780, addions (4728, 4732,
4799 4756), Group member
removals (4729, 4733,
4757), Group changes
(4735, 4737, 4755,
4764), A user account
was changed (4738), A
user account was locked
out (4740), A computer
account was created
(4741), A computer
account was changed
(4742), A computer
account was deleted
(4743), SID history (4765,
4766), A user account was
unlocked (4767), ACL set
on accounts (4780), Group
membership enumeraon
(4799)
Secuirty Microso-Windows- 4616, 4821, System me was

Security-Auding 4822, 4823, changed (4616), Kerberos
4824 service cket was
denied (4821), NTLM
authencaon failed
(4822, 4823), Kerberos
preuathencaon failed
(4824), User denied
access to Remote Desktop
(4825), Key file operaon
(5058), Key migraon
operaon (5059)
Security Microso-Windows- 4698, 4702, A scheduled task

Security-Auding 4886, 4887, was created (4698),
4899, 4900, A scheduled task
5140 was updated (4702),
Cerficate Services
received a cerficate
request (4886), Cerficate
Services approved a
cerficate request (4887),
A Cerficate Services
template was updated
(4899), Cerficate
Services template security
was updated (4900), A
Endpoint Security

network share object was
accessed (5140)
Security Microso-Windows- 4713 Kerberos policy was

Security-Auding changed
Security Microso-Windows- 4662 An operaon was

Security-Auding performed on an object
EDR Data Collected for Mac Endpoints
Files • Create • Full path of the modified

• Write file before and aer
modificaon
• Delete
• SHA256 and MD5 hash for
• Rename the file aer modificaon
• Move
• Open
Process • Start • Process ID (PID) of the

• Stop parent process
• PID of the process
• Full path
• Command line arguments
• Integrity level to determine
if the process is running
with elevated privileges
• Hash (SHA256 and MD5)
• Signature or signing
cerficate details
Network • Accept • Source IP address and port

• Connect Failure port
• Disconnect • Failed connecon
• Listen • Protocol (TCP/UDP)
• Stascs • Aggregated send/

receive stascs for the
connecon
Endpoint Security
Event Log • Authencaon • Provider Name

• Data fields
• Message
EDR Data Collected for Linux Endpoints
Files • Create • Full path of the file

• Open • Hash of the file
• Write
For specific files
• Delete only and only
if the file was
wrien.
• Copy • Full paths of both the

• Move (rename) original and the modified
files
• Change owner (chown) • Full path of the file

• Change mode (chmod) • Newly set owner/aributes
Network • Listen • Source IP address and port

• Accept for explicit binds

port
• Connect failure
• Failed TCP connecons
• Disconnect
• Protocol (TCP/UDP)
Process • Start • PID of the child process

• PID of the parent process
• Full image path of the
process
• Command line of the
process
• Hash of the image
(SHA256 & MD5)
• Stop • PID of the stopped process
Endpoint Security
Event Log • Authencaon • Provider Name

• Data fields
• Message
Endpoint Security
Apply Security Profiles to Endpoints

Cortex XDR provides out-of-the-box protecon for all registered endpoints with a default security
policy customized for each supported plaorm type. To tune your security policy, customize the
sengs in a security profile and aach the profile to a policy.
Each policy you create must apply to one or more endpoints or endpoint groups. The Prevenon
Policy Rules table lists all the policy rules per operang system. Rules associated with one or more
targets that are beyond your defined user scope are locked and cannot be edited.
STEP 1 | From Cortex XDR, create a policy rule.
Do either of the following:
• Select Endpoints > Policy Management > Prevenon > Policy Rules, and select + New
Policy or Import from File.
When imporng a policy, select whether to enable the associated policy targets.
Rules within the imported policy are managed as follows:
• New rules are added to top of the list.
• Default rules override the default rule in the target tenant.
• Rules without a defined target are disabled unl target is specified.
• Select Endpoints > Policy Management > Prevenon > Profiles, right-click the profile you
want to assign and Create a new policy rule using this profile.
STEP 2 | Define a Policy Name and oponal Descripon that describes the purpose or intent of the
policy.
STEP 3 | Select the Plaorm for which you want to create a new policy.
STEP 4 | Select the desired Exploit, Malware, Restricons, and Agent Sengs profiles you want to
apply in this policy.
If you do not specify a profile, the Cortex XDR agent uses the default profile.
STEP 6 | Use the filters to assign the policy to one or more endpoints or endpoint groups.
Cortex XDR automacally applies a filter of the plaorm you selected and, if exists, the Group
Name according to the groups within your defined user scope.
STEP 7 | Click Done.
STEP 8 | In the Policy Rules table, change the rule posion, if needed, to order the policy relave to
other policies.
The Cortex XDR agent evaluates policies from top to boom. When the Cortex XDR agent
finds the first match it applies that policy as the acve policy. To move the rule, select the
arrows and drag the policy to the desired locaon in the policy hierarchy.
Right-click to View Policy Details, Edit, Save as New, Disable, and Delete.
Endpoint Security
STEP 9 | Export policy.

Select one ore more policies, right-click and select Export Policies. You can choose to include
the associated Policy Targets, Global Excepons, and endpoint groups.
The exported file is encoded Base64 and cannot be edited.
Endpoint Security
Excepons Security Profiles

To allow full granularity, Cortex XDR enables you to create excepons from your baseline policy.
With these excepons you can remove specific folders or paths from exempon, or disable
specific security modules.
You can configure the following types of policy excepons:
Excepon Type Descripon
Process excepons Define an excepon for a specific process for

one or more security modules.
Support excepons Import an excepon from the Cortex XDR

Support team.
Behavioral Threat Protecon Rule Excepon An excepon disabling a specific BTP rule
across all processes.
Digital Signer Excepon (Windows only) An excepon adding a digital

signer to the list of allowed signers.
Java Deserializaon Excepon (Linux only) An excepon allowing specific

Java executable (jar, class).
Local File Threat Examinaon Excepon (Linux only) An excepon allowing specific
PHP files.
There are two types of excepons you can create:

• Policy excepons that apply to specific policies and endpoints (see Add a New Excepons
Security Profile)
• Global excepons that apply to all policies (see Add a Global Endpoint Policy Excepon)
Depending on your defined user scope, creang excepons may be disabled.
To help you manage and asses your BIOC/IOC rules, Cortex XDR automacally creates a System
Generated rule excepon if the same BIOC/IOC rule is detected by the same iniator hash within
a 3 day meframe on 100 different endpoints.
Each me a BIOC/IOC alert is detected, the 3 day meframe begins counng down. If aer 3 days
without an alert, the 3 day meframe is reset. For example:
Day Number BIOC/IOC Detecons Acon
Example A
1 98 Detecons No excepon created
Endpoint Security
Day Number BIOC/IOC Detecons Acon
2 1 Detecon No excepon created
4 1 Detecon System Generated excepon

created
Example B
1 98 Detecons No excepon created
2 1 Detecon No excepon created
6 99 Detecons No excepon created since

detecons were not within
the 3 day meframe
Add a New Excepons Security Profile

You can configure excepons that apply to specific groups of endpoints or you can Add a Global
Endpoint Policy Excepon. Use the following workflow to create an endpoint-specific excepon:
2. Select the plaorm to which the profile applies and Excepons as the profile type.
3. Click Next.

STEP 3 | Configure the excepons profile.

To configure a Process Excepon:
1. Select the operang system.
2. Enter the name of the process.
3. Select one or more Endpoint Protecon Modules that will allow this process to run. The
modules displayed on the list are the modules relevant to the operang system defined
Endpoint Security
for this profile. To apply the process excepon on all security modules, Select all. To
apply the process excepon on all exploit security modules, select Disable Injecon.
4. Click the adjacent arrow.
5. Aer you’ve added all processes, click Create.
You can return to the Process Excepon profile from the Endpoints Profile page at any
point and edit the sengs, for example if you want to add or remove more security
modules.
To configure a Support Excepon:
1. Import the json file you received from Palo Alto Networks support team by either
browsing for it in your files or by dragging and dropping the file on the page.
2. Click Create.
To configure module specific excepons relevant for the selected profile plaorm:
• Behavioral Threat Protecon Rule Excepon—When you view an alert for a Behavioral
Threat event which you want to allow in your network from now on, right-click the alert and
Create alert excepon. Review the alert data (Plaorm and Rule name) and select from the
following opons as needed.
- CGO hash—Causality Group Owner (CGO) hash value.
- CGO signer—CGO signer enty (for Windows and Mac only).
- CGO process path—Directory path of the CGO process.
- CGO command arguments—CGO command arguments. This opon 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. Aer selecng this opon, check the full path of each relevant command
argument within quote marks. You can edit the displayed paths if needed.
From Excepon Scope, select Profile and click Create.
• Digital Signer Excepon—When you view an alert for a Digital Signer Restricon which
you want to allow in your network from now on, right-click the alert and Create alert
excepon. Cortex XDR displays the alert data (Plaorm, Signer, and Generang Alert ID).
Select Excepon Scope: Profile and select the excepon profile name. Click Add.
• Java Deserializaon Excepon—When you idenfy a Suspicious Input Deserializaon
alert that you believe to be benign and want to suppress future alerts, right-click the
alert and Create alert excepon. Cortex XDR displays the alert data (Plaorm, Process,
Java executable, and Generang Alert ID). Select Excepon Scope: Profile and select the
excepon profile name. Click Add.
• Local File Threat Examinaon Excepon—When you view an alert for a PHP file which you
want to allow in your network from now on, right-click the alert and Create alert excepon.
Cortex XDR displays the alert data (Process, Path, and Hash). Select Excepon Scope:
Profile and select the excepon profile name. Click Add
• Gatekeeper Enhancement Excepon—When you view a Gatekeeper Enhancement security
alert for a bundle or specific source-child combinaon you want to allow in your network
from now on, right-click the alert and Create alert excepon. Cortex XDR displays the
alert data (Plaorm, Source Process, Target Process, and Alert ID). Select Excepon Scope:
Profile and select the excepon profile name. Click Add. This excepon allows Cortex
Endpoint Security
XDR to connue enforcing the Gatekeeper Enhancement protecon module on the source
process running other child processes.
At any point, you can click the Generang Alert ID to return to the original alert from which
the excepon was originated. You cannot edit module specific excepons.

If you want to remove an excepons profile from your network, go to the Profiles page, right-
click and select Delete
Add a Global Endpoint Policy Excepon

As an alternave to adding an endpoint-specific excepon in policy rules, you can define and
manage global excepons that apply across all of your endpoints. On the Global Excepon page,
you can manage all the global excepons in your organizaon for all plaorms. Profiles associated
edited.
Together with Excepons Security Profiles, global excepons constute the sum of all the
excepons allowed within your security policy rules.
• Add a Global Process Excepon
• Add a Global Support Excepon
• Add a Global Behavioral Threat Protecon (BTP) Rule Excepon
• Add A Global Local Analysis Rules Excepon
• Review Advanced Analysis Excepons
• Add a Global Digital Signer Excepon
• Add a Global Java Deserializaon Excepon
• Add a Global Local File Threat Examinaon Excepon
• Add a Global Gatekeeper Enhancement Excepon
• Import and Export Excepons
Add a Global Process Excepon

STEP 1 | Go to Endpoints > Policy Management > Policy Excepons.
STEP 2 | Select Process excepons.

1. Select the operang system.
2. Enter the name of the process.
3. Select one or more Endpoint Protecon Modules that will allow this process to run. The
modules displayed on the list are the modules relevant to the operang system defined
for this profile. To apply the process excepon on all security modules, Select all. To
Endpoint Security
apply the process excepon on all exploit security modules, select Disable Injecon.
Click the adjacent arrow to add the excepon.
STEP 3 | Aer you add all excepons, Save your changes.

The new process excepon is added to the Global Excepons in your network and will be
applied across all rules and policies. To edit the excepon, select it and click the edit icon. To
delete it, select it and click the delete icon.
Add a Global Support Excepon

STEP 1 | Go to Endpoints > Prevenon > Global Excepons.
STEP 2 | Select Support Excepons.

Import the json file you received from Palo Alto Networks support team by either browsing
for it in your files or by dragging and dropping the file on the page.
STEP 3 | Click Save.

The new support excepon is added to the Global Excepons in your network and will be
applied across all rules and policies.
Add a Global Behavioral Threat Protecon (BTP) Rule Excepon

When you view a Behavioral Threat alert in the Alerts table for which you want to allow across
your organizaon, you can create a global excepon for that rule.
STEP 1 | Right-click the BTP alert and select Create alert excepon.
STEP 2 | Review the alert data (plaorm and rule name) and then select from the following opons as
needed:
1. CGO hash—Causality Group Owner (CGO) hash value.
2. CGO signer—CGO signer enty (for Windows and Mac only).
3. CGO process path—Directory path of the CGO process.
4. CGO command arguments—CGO command arguments. This opon 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. Aer selecng this opon, check the full path of each relevant command
argument within quote marks. You can edit the displayed paths if needed.
5. From Excepon Scope, select Global.
STEP 3 | Click Create.

The relevant BTP excepon is added to the Global Excepons in your network and will be
applied across all rules and policies. At any point, you can click the Generang Alert ID to
Endpoint Security
return to the original alert from which the excepon was originated. To delete a specific global
excepon, select it and click X.
You cannot edit global excepons generated from a BTP security event.
Add A Global Local Analysis Rules Excepon

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 excepon to allow these rules across your organizaon.
STEP 1 | Right-click the alert and select Create alert excepon.
STEP 2 | Review the alert data (plaorm and rule name) and select Excepon Scope: Global.
STEP 3 | Click Add.

The relevant Local Analysis Rules excepon is added to the Global Excepons in your network
and will be applied across all rules and policies. The excepon 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 Generang Alert ID to return to the original alert from which the excepon was
originated. To delete a specific global excepon, select it and click X. You cannot edit global
excepons generated from a local analysis security event.
Review Advanced Analysis Excepons

With Advanced Analysis, Cortex XDR can provide a secondary validaon of Cortex XDR Agent
alerts raised by exploit protecon modules. To perform the addional analysis, Cortex XDR
analyzes alert data sent by the Cortex XDR agent. If Advanced Analysis indicates an alert is
actually benign, Cortex XDR can automacally create excepons and distribute the updated
security policy to your endpoints.
By enabling Cortex XDR to automacally create and distribute global excepons you can minimize
disrupon for users when they subsequently encounter the same benign acvity. To enable the
automac creaon of Advanced Analysis Excepons, configure the Advanced Analysis opons in
your Configure Global Agent Sengs.
For each excepon, Cortex XDR displays the affected plaorm, excepon name, and the relevant
alert ID for which Cortex XDR determined acvity was benign. To drill down into the alert details,
click the Generang Alert ID.
Add a Global Digital Signer Excepon

When you view in the Alerts table a Digital Signer Restricon alerts for a digital signer you trust
and want to allow from now on across your network, create a Global Excepon for that digital
signer directly from the alert.
Review the alert data (Plaorm, signer, and alert ID) and select Excepon Scope: Global.
STEP 2 | Click Add.

The relevant digital signer excepon is added to the Global Excepons in your network and will
be applied across all rules and policies. At any point, you can click the Generang Alert ID to
Endpoint Security
excepon, select it and click X. You cannot edit global excepons generated from a digital
signer restricon security event.
Add a Global Java Deserializaon Excepon

When you view in the Alerts table a Suspicious Input Desensizaon alert for a Java executable
you want to allow from now on across your network, create a global excepon for that executable
directly from the alert of the security event that prevented it.
Review the alert data (Plaorm, Process, Java executable, and alert ID) and select Excepon
Scope: Global.
STEP 2 | Click Add.

The relevant digital signer excepon is added to the Global Excepons in your network and will
be applied across all rules and policies. At any point, you can click the Generang Alert ID to
excepon, select it and click X. You cannot edit global excepons generated from a digital
signer restricon security event.
Add a Global Local File Threat Examinaon Excepon

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 excepon for that file directly from the alert of
the security event that prevented it.
Review the alert data (Process, Path, and Hash) and select Excepon Scope: Global.
STEP 2 | Click Add.

The relevant PHP file is added to the Global Excepons in your network and will be applied
across all rules and policies. At any point, you can click the Generang Alert ID to return to the
original alert from which the excepon was originated. To delete a specific global excepon,
select it and click X. You cannot edit global excepons generated from a local file threat
examinaon excepon restricon security event.
Add a Global Gatekeeper Enhancement Excepon

When you view a Gatekeeper Enhancement security alert in the Alerts table, you can create a
global excepon for this specific bundle or source-child combinaon only, while allowing Cortex
XDR to connue enforcing the Gatekeeper Enhancement protecon module on the source
process running other child processes.
Review the alert data (Plaorm, Source Process, Target Process, and Alert ID) and select
Excepon Scope: Global.
Endpoint Security
STEP 2 | Click Add.

The relevant source and target processes are added to the Global Excepons in your network
and will be applied across all rules and policies. At any point, you can click the Generang Alert
ID to return to the original alert from which the excepon was originated. To delete a specific
global excepon, select it and click X. You cannot edit global excepons generated from a
gatekeeper enhancement security event.
Import and Export Excepons

Select + Import/Export to Export your excepons list and/or Import from File.
The exported file is encoded Base64 and cannot be edited.
Endpoint Security
Hardened Endpoint Security

Cortex XDR enables you to extend the security on your endpoints beyond the Cortex XDR agent
built-in prevenon capabilies to provide an increased coverage of network security within your
organizaon. By leveraging exisng mechanisms and added capabilies, the Cortex XDR agent can
enforce addional protecons 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 capabilies.
• Device Control
• Host Firewall
• Host Firewall for Windows
• Host Firewall for macOS
• Disk Encrypon
• Host Inventory
• Vulnerability Assessment
The Extensions Profiles table lists the profiles details per operang system. Profiles associated
edited.
Field Descripon
Associated Targets The targets associated with the profile.
Created By Administrave user who created the profile.
Created Time Date and me at which the profile was created.
Descripon Oponal descripon entered by an administrator

to describe the profile.
Modificaon Time Date and me at which the profile was modified.
Modified By Administrave user who modified the profile.
Name Name provided to idenfy the security profile.
Plaorm Plaorm type of the profile.
Summary Summary of profile configuraon.
Type Profile type.
Usage Count Number of policy rules that use the profile.
Endpoint Security
To apply the profiles, from Endpoints > Policy Management > Extensions > Policy Rules, you can
view all the policy rules per operang 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 plaorms and minimal agent
version. A dash (—) indicates the seng is not supported.
Hardened endpoint security capabilies are not supported for Android endpoints.
Module Windows Mac Linux
Device Control X X —
Protects endpoints from Cortex XDR agent Cortex XDR agent
loading malicious files from 7.0 and later 7.2 and later
USB-connected removable
For VDI, Cortex
devices (CD-ROM, disk
XDR agent 7.3 and
drives, floppy disks and
later
Windows portable devices
drives).
Host Firewall X X —
Protects endpoints from Cortex XDR agent Cortex XDR agent
aacks originang in 7.1 and later 7.2 and later
network communicaons
to and from the endpoint.
Disk Encrypon X X —
Provides visibility into Cortex XDR agent Cortex XDR agent
endpoints that encrypt 7.1 and later 7.2 and later
their hard drives using
BitLocker or FileVault.
Host Inventory X X X
Provides full visibility Cortex XDR agent Cortex XDR agent Cortex XDR agent
into the business and IT 7.1 and later 7.1 and later 7.1 and later
operaonal data on all your
endpoints.
Vulnerability Assessment X — X
Idenfies and quanfies Cortex XDR agent Cortex XDRR agent
the security vulnerabilies 7.1 and later 7.1 and later
(CVEs) that exist for
applicaons installed on
you endpoints.
Endpoint Security
Device Control
By default, all external USB devices are allowed to connect to your Cortex XDR endpoints. To
protect endpoints from connecng USB-connected removable devices—such as disk drives, CD-
ROM drives, floppy disk drives, and other portable devices—that can contain malicious files,
Cortex XDR provides device control.
For example, with device control, you can:
• Block all supported USB-connected devices for an endpoint group.
• Block a USB device type but add to your allow list a specific vendor from that list that will be
accessible from the endpoint.
• Temporarily block only some USB device types on an endpoint.
Depending on your defined user scope permissions, creang device profiles, policies,
excepons, and violaons may be disabled.
The following are prerequisites to enforce device control policy rules on your endpoints:
Plaorm Requirements and Limitaons
Windows Cortex XDR agent 7.0 or a later release.

For VDI—
• Cortex XDR agent 7.3 or a later release.
• 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.
• For VMWare Horizon, you must disable Sharing > Allow access to
removable storage in your VMWare horizon client sengs.
Mac • Cortex XDR agent 7.2 or a later release.

• Device Control policy rules do not take effect on Android devices.
Linux Not supported.
If you are running Cortex XDR agents 7.3 or earlier releases, device control rules take
effect on your endpoint only aer the Cortex XDR agent deploys the policy. If you already
had a USB device connected to the endpoint, you have to disconnect it and connect it
again for the policy to take effect.
Endpoint Security
Device Control Profiles

To apply device control in your organizaon, define device control profiles that determine which
device types Cortex XDR blocks and which it permits. There are two types of profiles:
Profile Descripon
Configuraon Profile Allow or block these USB-connected device

type groups:
• Disk Drives
• CD-Rom Drives
• Floppy Disk Drives
• (Windows only) Windows Portable Devices
Cortex XDR relies on the device

class assigned by the operang
system.
Add a New Configuraon Profile.

The Cortex XDR agent relies on the device
class assigned by the operang system. For
Windows endpoints only, you can configure
addional device classes.
Add a Custom Device Class
Excepons 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 Excepons Profile.
Device Configuraon and Device Excepons profiles are set for each operang system separately.
Aer you configure a device control profile, Apply Device Control Profiles to Your Endpoints.
Add a New Configuraon Profile

STEP 1 | Log in to Cortex XDR .
Go to Endpoints > Policy management > Extension > Profiles and select + New Profile or
Import from File.
STEP 2 | Select Plaorm and click Device Configuraon > Next.
STEP 3 | Fill in the General Informaon.

Assign the profile Name and add an oponal Descripon. The profile Type and Plaorm are set
by Cortex XDR .
Endpoint Security
STEP 4 | Configure the Device Configuraon.

For each group of device types, select whether to Allow or Block them on the endpoints.
For Disk Drives only, you can also choose to allow to connect in Read-only mode. To use the
default opon defined by Palo Alto Networks, leave Use Default selected.
Currently, the default is set to Use Default (Allow) however Palo Alto Networks may
change the default definion at any me.
To view in XQL Search connect and disconnect events of USB devices that are reported
by the agent, the Device Configuraon 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 excepon in place. For more
informaon, see Ingest Connect and Disconnect Events of USB Devices.
STEP 5 | Save your profile.

When you’re done, Create your device profile definions.
If needed, you can edit, delete, or duplicate your profiles.
You cannot edit or delete the default profiles pre-defined in Cortex XDR .
STEP 6 | (Oponal) To define excepons to your Device Configuraon profile, Add a New Excepons
Profile.
STEP 7 | Apply Device Control Profiles to Your Endpoints.
Add a New Excepons Profile

Go to Endpoints > Policy management > Extension > Profiles and select + New Profile or
Import from File.
STEP 2 | Select Plaorm and click Device Excepons > Next
STEP 3 | Fill in the General Informaon.

Assign the profile Name and add an oponal Descripon. The profile Type and Plaorm are set
by the system.
Endpoint Security
STEP 4 | Configure Device Excepons.

You can add devices to your allow list according to different sets of idenfiers-vendor, product,
and serial numbers.
• (Disk Drives only) Permission—Select the permissions you want to grant: Read only or
Read/Write.
• Type—Select the Device Type you want to add to the allow list (Disk Drives, CD-Rom,
Portable, or Floppy Disk).
• Vendor—Select a specific vendor from the list or enter the vendor ID in hexadecimal code.
• (Oponal) Product—Select a specific product (filtered by the selected vendor) to add to your
allow list, or add your product ID in hexadecimal code.
• (Oponal) 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.

When you’re done, Create your device excepons profile.
If needed, you can later edit, delete, or duplicate your profiles.
You cannot edit or delete the predefined profiles in Cortex XDR .
STEP 6 | Apply Device Control Profiles to Your Endpoints.
Apply Device Control Profiles to Your Endpoints

Aer you define the required profiles for Device Configuraon and Excepons, you must
configure Device Control Policies and enforce them on your endpoints. Cortex XDR applies Device
Control policies on endpoints from top to boom, 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.
STEP 1 | Log in to Cortex XDR .
Go to Endpoints > Policy management > Extension > Policy Rules and select + New Policy or
Import from File.
When imporng a policy, select whether to enable the associated policy targets. Rules
within the imported policy are managed as follows:
Endpoint Security
STEP 2 | Configure sengs for the Device Control policy.

1. Assign a policy name and select the plaorm. You can add a descripon.
The plaorm will automacally be assigned to Windows.
2. Assign the Device Type profile you want to use in this rule.
3. Click Next.
4. Select the target endpoints on which to enforce the policy.
Use filters or manual endpoint selecon 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.
5. Click Done.
STEP 3 | Configure policy hierarchy.

Drag and drop the policies in the desired order of execuon. 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.
STEP 4 | Save the policy hierarchy.

Aer the policy is saved and applied to the agents, Cortex XDR enforces the device control
policies on your environment.
STEP 5 | (Oponal) Manage your policy rules.

In the Protecon Policy Rules table: you can view and edit the policy you created and the
policy hierarchy.
1. View your policy hierarchy.
2. Right-click to View Policy Details, Edit, Save as New, Disable, and Delete.
3. Select one ore more policies, right-click and select Export Policies. You can choose to
include the associated Policy Targets, Global Excepons, and endpoint groups.
STEP 6 | Monitor device control violaons.

Aer you apply Device Control rules in your environment, use the Endpoints > Device Control
Violaons page to monitor all instances where end users aempted to connect restricted
USB-connected devices and Cortex XDR blocked them on the endpoint. All violaon logs
are displayed on the page. You can sort the results, and use the filters menu to narrow down
Endpoint Security
the results. For each violaon event Cortex XDR logs the event details, the plaorm, and the
device details that are available.
If you see a violaon for which you’d like to define an excepon on the device that triggered it,
right-click the violaon and select one of the following opons:
• Add device to permanent excepons—To ensure this device is always allowed in your
network, select this opon to add the device to the Device Permanent Excepons list.
• Add device to temporary excepons—To allow this device only temporarily on the selected
endpoint or on all endpoints, select this opon and set the allowed me frame for the
device.
• Allow device to a profile excepon—Select this opon to allow the device within an exisng
Device Excepons profile.
STEP 7 | Tune your device control excepons.

To beer 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 excepons are configured per device and you must select the device category, vendor,
and type of permission that you want to allow on the endpoint. Oponally, to limit the
excepon to a specific device, you can also include the product and/or serial number.
Cortex XDR enables you to configure the following excepons:
Excepon Name Descripon
Permanent Excepons Permanent excepons approve the device in your

network across all Device Control policies and profiles.
You can create them directly from the violaon event
that blocked the device, or through the Permanent
Excepons list.
Permanent excepons apply across plaorms,

allowing the devices on all operang systems.
Create a Permanent Excepon.
Temporary Excepons Temporary excepons approve the device for a specific

me period up to 30 days. You create a temporary
excepon directly from the violaon event that blocked
the device.
Create a Temporary Excepon.
Profile Excepons Profile excepons approve the device in an exisng

excepons profile. You create a profile excepon directly
from the violaon event that blocked the device.
Endpoint Security
Excepon Name Descripon

Create a Profile Excepon.
1. Create a Permanent Excepon.

Permanent device control excepons are managed in the Permanent Excepon list and
are applied to all devices regardless of the endpoint plaorm.
• If you know in advance which device you’d like to allow throughout your network,
create a general excepon from the list:
1. Go to Endpoints > Policy Management > Extensions and select Device Permanent
Excepons on the le menu. The list of exisng Permanent Excepons is
displayed.
2. Select: Type, Permission, and Vendor.
3. (Oponal) Select a specific product and/or enter a specific serial number for the
device.
4. Click the adjacent arrow and Save. The excepon is added to the Permanent
Excepons list and will be applied in the next heartbeat.
• Otherwise, you can create a permanent excepon directly from the violaon event
that blocked the device in your network:
1. On the Device Control Violaons page, right-click the violaon event triggered by
the device you want to permanently allow.
2. Select Add device to permanent excepons. Review the excepon data and
change the defaults if necessary.
3. Click Save.
2. Create a Temporary Excepon.
1. On the Device Control Violaons page, right-click the violaon event triggered by the
device you want to temporarily allow.
2. Select Add device to temporary excepons. Review the excepon data and change
the defaults if necessary. For example, you can configure the excepon to this
endpoint only or to all endpoints in your network, or set which device idenfiers will
be included in the excepon.
3. Configure the excepon TIME FRAME by defining the number of days or number of
hours during which the excepon will be applied, up to 30 days.
4. Click Save. The excepon is added to the Device Temporary Excepons list and will be
applied in the next heartbeat.
3. Create an Excepon within a Profile.
1. On the Device Control Violaons page, right-click the violaon event triggered by the
device you want to add to a Device Excepons profile.
2. Select the PROFILE from the list.
3. Click Save. The excepon is added to the Excepons Profile and will be applied in the
next heartbeat.
Endpoint Security
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 idenfier used by Microso. Alternavely, if you configured a GUID value to a specific
USB connected device, you must use this value for the new device class. Aer you add a custom
device class, you can view it in Device Management and enforce any device control rules and
excepons on this device class.
To create a custom USB-connected device class:
STEP 1 | Go to Endpoints > Policy Management > Sengs > Device Management.
This is the list of all your custom USB-connected devices.
STEP 2 | Create the new device class.

Select +New Device. Set a Name for the new device class, supply a valid and unique GUID
Idenfier. For each GUID value you can define one class type only.
STEP 3 | Save.
The new device class is now available in Cortex XDR as all other device classes.
Add a Custom User Noficaon

(Requires a Cortex XDR agent 7.5 or a later release for Windows) You can personalize the Cortex
XDR noficaon pop-up on the endpoint when the user aempts to connect a USB device that is
either blocked on the endpoint or allowed in read-only mode. To edit the noficaons, refer to the
Agent Sengs Profile.
Ingest Connect and Disconnect Events of USB Devices
This feature requires a Cortex XDR Pro license.
The Cortex XDR Query Language (XQL) supports the ingeson 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 Configuraon 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 excepon in place. For more informaon, see
Add a New Configuraon 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 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.
Endpoint Security
• 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
Host Firewall
The Cortex XDR host firewall enables you to control communicaons 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. Addionally, you can configure
different sets of rules based on the current locaon of your endpoints - within or outside your
organizaon network. The Cortex XDR host firewall rules leverage the operang system firewall
APIs and enforce these rules on your endpoints, but not your Windows or Mac firewall sengs.
The following are prerequisites to apply Cortex XDR host firewall policy rules on your endpoints:
Windows • Cortex XDR agent 7.1 or a later release.

• Cortex XDR host firewall rules can apply to both incoming and
outgoing communicaon on the endpoint.
• It is recommended to disable the windows firewall on endpoints
running win 7 SP1 before applying the Cortex XDR host firewall
profile.
Mac • Cortex XDR agent 7.2 or a later release.

• Cortex XDR host firewall rules can apply only to incoming
communicaon on the endpoint.
• Aer 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 sengs with
the Cortex XDR host firewall:
• Automatically allow built-in software to
receive incoming connections.
• Automatically allow downloaded signed software
to receive incoming connections.
Endpoint Security
Linux Not supported.
To start using the Cortex XDR host firewall, refer to:

• Host Firewall for Windows
• Host Firewall for macOS
Host Firewall for Windows

Enforce the Cortex XDR host firewall policy in your organizaon to control communicaons on
your endpoints and gain visibility into your network connecons. 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 operang system firewall APIs and enforce these rules on your endpoints, but not
your operang system firewall sengs. Once you deploy the host firewall, use the Host Firewall
Events table to track the enforcement events in your organizaon.
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 rule(s) within rule groups—Create host firewall rules groups that you can reuse across
all host firewall profiles. Add rules to each group and priorize the rules from top to boom to
create an enforcement hierarchy.
• Configure a profile—Select one or more rules 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 organizaon’s internal network, and when it is outside.
Priorize the groups within the profile from top to boom to create an enforcement hierarchy.
• Configure a policy—Add your host firewall profile to a new or exisng policy that will be
enforced on selected target endpoints.
• Monitor and troubleshoot—View aggregated host firewall enforcement events, or all single
host firewall acvies the agent performed in your network. Cortex XDR Pro customers can
also query the host firewall events using the new host_firewall_events dataset in XQL
Search for data and network analysis.
Migration and Backwards Supportability
Host firewall is supported with Cortex XDR agents 7.1 or a later release. Starng with Cortex XDR
3.0 and Cortex XDR agent 7.5, new capabilies were added. Your exisng host firewall rules and
policies are migrated as follows:
• Any exisng host firewall profile in Cortex XDR 2.9 is converted into a single rules group in
Cortex XDR 3.0 and located on the Host Firewall Rules Groups page.
• If the exisng profile contains both internal and external rules, then two groups are created:
an external rules group and an internal rules group, and the rule name is added an internal/
external suffix respecvely. For example, internal rule-x is renamed as rule-x-internal
• Cortex XDR 3.0 host firewall includes new features which are supported only with Cortex XDR
agents 7.5 and later, such as mulple IP addresses, reporng mode, and more. For an older
agent release, exisng host firewall rules remain unaffected. However, if you create a rule from
Endpoint Security
Cortex XDR 3.0, or edit an already exisng rule that was created in an old Cortex XDR release
and add one of these unsupported parameters, the agent could display unexpected behavior
and the host firewall policy will be disabled on the endpoint.
As a result, all migrated rules are set not to report matching traffic by default and
enforcement events are not included in the Host Firewall Events table.
Set Up the Host Firewall
Set up your rule groups and host firewall profile.
Create a Rules Group
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 boom. Aer you create a rules group, you can
assign the group to a host firewall profile. When you edit, re-priorize, 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. Addionally, you can import exisng firewall rules into Cortex XDR , or export
them in JSON format.
STEP 1 | Create a group.
From Endpoints > Host Firewall > Host Firewall Rules Groups, click +New Group on the upper
bar.
STEP 2 | Fill-in general informaon.

Enter the rule name and oponal descripon. 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.
STEP 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, applicaons, services, and more.
Endpoint Security
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.
• 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.
1. Configure rule sengs.

A host firewall rule allows or blocks the communicaon to and/or from an endpoint.
Enter the rule Name, oponal Descripon, and select the Plaorms you want to
associate the rule with.
Fine tune the rule by applying the acon 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 addional 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 selecng 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.
• Direcon—Select the direcon of the communicaon this rule applies to: Inbound
communicaon to the endpoint, Outbound communicaon from the endpoint, or
Both.
• Acon—Select whether the rule acon is to Allow or Block the communicaon 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, mulple IP addresses separated by
a comma, range of IP addresses separated by a hyphen, or a combinaon of these
opons.
• Depending on the type of plaorm you selected, define the Applicaon, Service, and
Bundle IDs of the Windows Sengs and/or macOS Sengs—Configure the rule for
all applicaons/services or specific ones only by entering the full path and name. If
you use system variables in the path definion, you must re-enforce the policy on the
endpoint every me 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,
Endpoint Security
whether the rule is set to Allow or Block the traffic. When Disabled, the rule is applied
but enforcement events are not reported periodically.
2. Save rule.
Aer 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.
STEP 4 | Priorize rules.

The rules within the group are enforced by priority from top to boom. By default, every
new rule is added to the top of the already exisng 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 priorize all the rules.
STEP 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

Aer you create a group, you can perform addional acons. 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
exisng rules groups in your organizaon. The table lists high level informaon 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 sengs.
• 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.
Manage Rules
Aer you create a host firewall rule and assign it to a rules group, you can manage the rule
sengs 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 boom (and within each
Endpoint Security
group, the rules are also enforced from top to boom). You can also configure profiles based on
the device locaon within your internal network. When you edit, re-priorize, 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.
STEP 1 | Create a profile.
From Endpoints > Policy Management > Extensions and select + Add Profile or Import from
File.
STEP 2 | Select the plaorm and click Host Firewall > Next.
STEP 3 | Fill-in General Informaon.

Enter the profile name and oponal descripon.
STEP 4 | Configure Report Sengs.

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.
STEP 5 | Configure Internal and External Rule Groups.

To apply locaon based host firewall rules, you must first enable network locaon
configuraon in your Agent Sengs Profile. When enabled, Cortex XDR enforces the host
firewall rules based on the current locaon of the device within the internal organizaon
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 Locaon Based
opon, your policy will apply the internal set of rules only, and that will be applied to the
device regardless of its locaon.
Create a New Ruleor add a rules group to the Internal/External Groups:
1. Click +Add Group.
2. 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.
3. Review the rule group field details.
The groups are listed according to the order of enforcement from top to boom. To
change this order, click on the group priority number and drag the group to the desired
row.
Field Descripon
Applicable Rules Count Displays the number of rules in the specific

group that are associated with the plaorm
profile.
Created by Displays the email address of the user that

created the rule.
Endpoint Security
Field Descripon
Creaon Time Date and me of when the rule was created.
Descripon Descripon 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.
Modificaon Time Date and me of when the group was

modified.
4. (Oponal) 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 plaorm profile you are
creang.
5. Allow or Block the Default Acon for Inbound/Outbound Traffic in the profile if you
want to allow all network connecons that have not been matched to any other rule in
the profile.
STEP 6 | Save the profile.

When you are done, click Create. You can now configure a host firewall policy.
Manage Policy Rules

Aer you create the host firewall extensions profile, you can perform addional acons. The
changes take effect on the next heartbeat. From Endpoints > Policy Management > Extensions >
Policy Rules, right-click to:
• Edit— Change the profile sengs 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 sll available in Cortex XDR.
• Save As New—Duplicate the profile, edit, and save as new.
• Export Profile—Select one ore more policies, right-click and select Export Policies. You can
choose to include the associated Policy Targets, Global Excepons, and endpoint groups.
Create a Host Firewall Policy
Aer 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 exisng policy, or create a
new one.
Endpoint Security
STEP 1 | Create a policy.

From Endpoints > Policy Management > Extensions > Policy Rules, click +New Policy or
Import from File.
STEP 2 | Fill-in general informaon.

Enter the policy name, descripon, and plaorm. Click Next.
STEP 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.
STEP 4 | Select endpoints.

Select the target endpoints on which to enforce the policy. Use filters or manual endpoint
selecon to define the exact target endpoints of the policy. Click Done.

Drag and drop the policies in the desired order of execuon, from top to boom.
STEP 6 | Save the policy.

Aer 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 me
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 addional data such as the me of the first rule hit, the rule
acon, protocol, and more.
Collect Detailed Log Files
To gain deeper visibility into all the host firewall acvity that occurred on an endpoint, you
can retrieve a log file lisng all single acons 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-wrien and overriding older logs. When you upload the file, the logs are
Endpoint Security
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. Alternavely, you can perform this acon for mulple
endpoints from Endpoints Administraon.
Host Firewall for macOS

The Cortex XDR host firewall enables you to control communicaons 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 XDRhost firewall policy rules. Addionally, you can configure
different sets of rules based on the current locaon of your endpoints - within or outside your
organizaon network. The Cortex XDR host firewall rules leverage the operang system firewall
APIs and enforce these rules on your endpoints, but not your Windows or Mac firewall sengs.
In Cortex XDR 3.0, no change was made to the Host Firewall Configuraon or operaon
on macOS endpoints. All exisng policies configured in Cortex XDR 2.9 sll apply and will
connue 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 and prerequisites.
• Enable Network Locaon Configuraon
• Add a New Host Firewall Profile
• Apply Host Firewall Profiles to Your Endpoints
• Monitor the Host Firewall Acvity on your Endpoint
Enable Network Location Configuration
If you want to apply locaon based host firewall rules, you must first enable network locaon
configuraon in your Agent Sengs Profile. On every heartbeat, and if the Cortex XDR agent
detects a network change on the endpoint, the agent triggers the device locaon test and re-
calculates the policy according to the new locaon.
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 boom (and within each
group, the rules are also enforced from top to boom). You can also configure profiles based on
the device locaon within your internal network. When you edit, re-priorize, 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.
Go to Endpoints > Policy Management > Extensions Profiles > Profiles and select + New
Profile or Import from File. Select the Plaorm and click Host Firewall > Next
Endpoint Security
STEP 2 | Fill-in the General Informaon for the new profile.

Assign a Profile Name and oponal descripon to the profile.
STEP 3 | Define your Report Sengs.

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.
STEP 4 | Configure Internal and External Rule Groups.

To apply locaon based host firewall rules, you must first enable network locaon
configuraon in your Agent Sengs Profile. When enabled, Cortex XDR enforces the host
firewall rules based on the current locaon of the device within the internal organizaon
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 Locaon Based
opon, your policy will apply the internal set of rules only, and that will be applied to the
device regardless of its locaon.
Create a New Rule or add a rules group to the Internal/External Groups:
1. Click +Add Group.
2. 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.
3. Review the rule group field details.
The groups are listed according to the order of enforcement from top to boom. To
change this order, click on the group priority number and drag the group to the desired
row.
Field Descripon
Applicable Rules Count Displays the number of rules in the specific

group that are associated with the plaorm
profile.
Created by Displays the email address of the user that

created the rule.
Creaon Time Date and me of when the rule was created.
Descripon Descripon 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.
Endpoint Security
Field Descripon
Modified by Displays the email address of the last user that

made changes to the group.
Modificaon Time Date and me of when the group was

modified.
4. (Oponal) 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 plaorm profile you are
creang.
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.
5. Allow or Block the Default Acon for Inbound/Outbound Traffic in the profile if you
want to allow all network connecons that have not been matched to any other rule in
the profile.
STEP 5 | (Oponal) Manage Legacy Host Firewall Rules.

Manage Host Firewall Rules created on macOS 10 and Cortex XDR agent 7.5 and prior.
1. Enable Manage Host Firewall to allow Cortex XDR to manage the host firewall on your
Mac endpoints.
2. Configure the host firewall Internal and External sengs.
The host firewall sengs allow or block inbound communicaon on your Mac endpoints.
Enable or Disable the following acons:
• Stealth Mode—Hide your mac endpoint from all TCP and UDP networks by enabling
the Apple Stealth mode on your endpoint.
• Block All Incoming Connecons—Select where to block all incoming communicaons
on the endpoint or not.
• Applicaon Exclusions—Allow or block specific programs running on the endpoint
using a Bundle ID.
If the profile is locaon based, you can define both internal and external sengs.

When you’re done, Create your host firewall profile.
STEP 7 | Apply Host Firewall Profiles to Your Endpoints.
Apply Host Firewall Profiles to Your Endpoints

Aer you define the required host firewall profiles, configure the Protecon Policies and enforce
them on your endpoints. Cortex XDR applies Protecon policies on endpoints from top to boom,
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 communicaon to and form the endpoint is
applied.
Endpoint Security

Go to Endpoints > Policy Management > Extensions > Policy Rules, and select +New Policy or
Import from File.
STEP 2 | Configure sengs for the host firewall policy.

1. Assign policy name, oponal descripon, and operang system.
2. Assign the host firewall profile you want to use in this rule.
3. Click Next.
policy rules.
5. Click Done.
Alternavely, you can associate the host firewall profile to an exisng policy. Right-click the
policy and select Edit. Select the Host Firewall profile and click Next. If needed, you can edit
other sengs in the rule (such as target endpoints, descripon, etc.) When you’re done, click
Done

Drag and drop the policies in the desired order of execuon.

Aer the policy is saved and applied to the agents, Cortex XDR enforces the host firewall
Monitor the Host Firewall Activity on your Endpoint

To view only the communicaon events on the endpoint to which the Cortex XDR host firewall
rules were applied, you can run the Cytool firewall show command.
Addionally, to monitor the communicaon on your macOS endpoint, you can use the following
operang system ulies: From the endpoint System Preferences > Security and Privacy >
Firewall > Firewall opons, you can view the list of blocked and allowed applicaons in the
firewall. The Cortex XDR host firewall blocks only incoming communicaons on Mac endpoints,
sll allowing outbound communicaon iniated from the endpoint.
Disk Encrypon
Cortex XDR provides full visibility into encrypted Windows and Mac endpoints that were
encrypted using BitLocker and FileVault, respecvely. Addionally, you can apply Cortex XDR
Endpoint Security
Disk Encrypon rule on the endpoints by creang disk encrypon rules and policies that leverage
BitLocker and FileVault capabilies.
Before you start applying disk encrypon policy rules, ensure you meet the following
requirements and refer to these known limitaons:
Requirement / Limitaon Windows Mac
Endpoint Pre-requisites • The endpoint is running • The endpoint is running

a Microso Windows a macOS version that
version that supports supports FileVault.
BitLocker. • The endpoint is running a
• The endpoint is within Cortex XDR agent 7.2 or
the organizaon network later release.
domain.
• The endpoint is running a
Cortex XDR agent 7.1 or
later release
• To allow the agent to
encrypt the endpoint,
Trusted Plaorm Module
(TPM) must be supported
and enabled on the
endpoint.
• Acve Directory Domain
Services is required for
recovery key backup.
Disk Encrypon Scope You can enforce XDR disk • You can enforce XDR disk
encrypon policy rules only encrypon policy rules
on the Operang System only on the Operang
volume. System volume.
• The Cortex XDR Disk
Encrypon profile for
Mac can encrypt the
endpoint disk, however it
cannot decrypt it. Aer
you disable the Cortex
XDR policy rule on the
endpoint, you can decrypt
the endpoint manually.
Other Group Policy configuraon: • Provide a FileVaultMaster

cerficate / instuonal
• Make sure the GPO
recovery key (IRK) that is
configuraon applying
signed by a valid authority.
to the endpoint enables
Save BitLocker recovery • It can take the agent up
to 5 minutes to report
Endpoint Security
Requirement / Limitaon Windows Mac

informaon to AD DS for the disk encrypon status
operang system drives. to Cortex XDR if the
• Make sure your Cortex endpoint was encrypted
XDR disk encrypon policy through Cortex XDR, and
does not conflict with up to one hour if it was
the GPO configuraon to encrypted through another
Choose drive encrypon MDM.
method and cipher • In line with the operang
strength. system requirements, the
Cortex XDR encrypon
profile will take place on
the endpoint aer the
user logs off and back on,
and approves the prompt
to enable the endpoint
encrypon.
• Palo Alto Networks
recommends you do
not apply an encrypon
enforcement from another
MDM on the endpoint
together with the Cortex
XDR encrypon profile.
Follow this high-level workflow to deploy the Cortex XDR disk encrypon in your network:
• Monitor the Endpoint Encrypon Status in Cortex XDR
• Configure a Disk Encrypon Profile
• Apply Disk Encrypon Profile to Your Endpoints
Monitor the Endpoint Encrypon Status in Cortex XDR

You can monitor the Encrypon Status of an endpoint in the Endpoints > Disk Encrypon
Visibility table. For each endpoint, the table lists both system and custom drives that were
encrypted.
The following table describes both the default and addional oponal fields that you can view in
the Disk Encrypon Visibility table per endpoint. The fields are in alphabecal order.
Field Descripon
Encrypon Status The endpoint encrypon status can be:

• Applying Policy—Indicates that the Cortex
XDR disk encrypon policy is in the
process of being applied on the endpoint.
• Compliant—Indicates that the Cortex XDR
agent encrypon status on the endpoint
Endpoint Security
Field Descripon
is compliant with the Cortex XDR disk
encrypon policy.
• Not Compliant—Indicates that the Cortex
XDR agent encrypon status on the
endpoint is not compliant with the Cortex
XDR disk encrypon policy.
• Not Configured—Indicates that no disk
encrypon rules are configured on the
endpoint.
• Not Supported—Indicates that the
operang system running on the endpoint
is not supported by Cortex XDR.
• Unmanaged—Indicates that the endpoint
encrypon is not managed by Cortex XDR.
Endpoint ID Unique ID assigned by Cortex XDR that

idenfies the endpoint.
Endpoint Name Hostname of the endpoint.
Endpoint Status The status of the endpoint. For more details,

see View Details About an Endpoint.
IP Address Last known IPv4 or IPv6 address of the

endpoint.
Last Reported Date and me of the last change in the agent’s
status. For more details, see View Details
About an Endpoint.
MAC Address The MAC address of the endpoint.
Operang System The plaorm running on the endpoint.
OS Version Name of the operang 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 encrypon method.
You can also monitor the endpoint Encrypon Status in your Endpoint Administraon table. If the
Encrypon Status is missing from the table, add it.
Endpoint Security
Configure a Disk Encrypon Profile

Go to Endpoints > Policy Management > Extensions > Profiles and select + New Profile or
Import from File. Choose the Plaorm and select Disk Encrypon. Click Next.
STEP 2 | Fill-in the general informaon for the new profile.

Assign a name and an oponal descripon to the profile.
STEP 3 | Enable disk encrypon.

To enable the Cortex XDR agent to apply disk encrypon rules using the operang system disk
encrypon capabilies, Enable the Use disk encrypon opon.
STEP 4 | Configure Encrypon details.

• For Windows:
• Encrypt or decrypt the system drives.
• Encrypt the enre disk or only the used disk space.
• For Mac:
Inline with the operang system requirements, when the Cortex XDR agent aempts to
enforce an encrypon profile on an endpoint, the endpoint user is required to enter the
login password. Limit the number of login aempts to one or three. Otherwise, if you do not
force log in aempts, the user can connuously dismiss the operang system pop-up and
the Cortex XDR agent will never encrypt the endpoint.
STEP 5 | (Windows only) Specify the Encrypon methods per operang system.
For each operang system (Windows 7, Windows 8-10, Windows 10 (1511) and above), select
the encrypon method from the corresponding list.
You must select the same encrypon method configured by the Microso Windows
Group Policy in your organizaon for the target endpoints. Otherwise, if you select a
different encrypon method than the one already applied through the Windows Group
Policy, Cortex XDR will display errors.
STEP 6 | (Mac only) Upload the FileVaultMaster cerficate.

To enable the Cortex XDR agent encrypt your endpoint, or to help users who forgot their
password to decrypt the endpoint, you must upload to Cortex XDR the FileVaultMaster
cerficate / instuonal recovery key (IRK). You must ensure the key is signed by a valid
authority and upload a CER file only.

When you’re done, Create your disk encrypon profile.
STEP 8 | Apply Disk Encrypon Profile to Your Endpoints.
Endpoint Security
Apply Disk Encrypon Profile to Your Endpoints

Aer you define the required disk encrypon profiles, configure Protecon Policies and enforce
them on your endpoints. Cortex XDR applies Protecon policies on endpoints from top to boom,
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 communicaon to and form the endpoint is
applied.
Go to Endpoints > Policy Management > Extensions > Policy Rules, and select +New policy or
Import from File.
STEP 2 | Configure sengs for the disk encrypon policy.

1. Assign a policy name and oponal descripon.
The plaorm will automacally be assigned to Windows.
2. Assign the disk encrypon profile you want to use in this rule.
3. Click Next.
policy rules. If exists, the Group Name is filtered according to the groups within your
defined user scope.
5. Click Done.
Alternavely, you can associate the disk encrypon profile to an exisng policy. Right-click the
policy and select Edit. Select the Disk Encrypon profile and click Next. If needed, you can edit
other sengs in the rule (such as target endpoints, descripon, etc.) When you’re done, click
Done

Drag and drop the policies in the desired order of execuon.

Aer the policy is saved and applied to the agents, Cortex XDR enforces the disk encrypon
STEP 5 | Select one ore more policies, right-click and select Export Policies. You can choose to include
the associated Policy Targets, Global Excepons, and endpoint groups.
STEP 6 | Monitor the Endpoint Encrypon Status.
Endpoint Security
Host Inventory
With Host Inventory, you gain full visibility and inventory into the business and IT operaonal data
on all your endpoints. By reviewing inventory for all your hosts in a single place, you can quickly
idenfy IT and security issues that exist in your network, such as idenfying a suspicious service
or autorun that were 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. Alternavely, you can rescan the endpoint to retrieve the most
updated data. It can take Cortex XDR up to 6 hours to collect inial data from all endpoints in your
network.
The following are prerequisites to enable Host Inventory for your Cortex XDR instance:
Requirement Descripon
Licenses and Add-ons • Cortex XDR Pro per Endpoint license.

• Host Insights Add-on.
Supported Plaorms • Windows, Mac, and Linux starng with Cortex XDR agent 7.1
Setup and • Ensure Host Inventory Data Collecon is enabled for your Cortex
Permissions XDR agent.
The Cortex XDR Host inventory includes the following enes and informaon, according to the
operang system running on the endpoint:
Enty Windows Mac Linux
Accessibility — —
Applicaons
Autoruns
Daemons —
Disks
Drivers —
Extensions — —
Groups
Mounts —
Services — —
Endpoint Security
Enty Windows Mac Linux
Shares
System Informaon
Users
Users to Groups
For each enty, Cortex XDR lists all the details about the enty, 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:
Alternavely, to beer understand the overall presence of each enty on the total number of
endpoints, you can switch to aggregated view (click ) and group the data by the main enty.
You can also sort and filter according the number of affected endpoints. For example, in the
Services aggregated view, you can sort by the number of affected endpoints to idenfy the least
Endpoint Security
commonly deployed service in your network. To get a closer view on all endpoints, right-click and
select View affected endpoints:
View Host Inventory

To view the Host inventory, go to Incident Response > Invesgaon > Host Inventory. You can
export the tables and respecve asset views to a tab-separated values (TSV) file.
Data Descripon
Accessibility Details about installed applicaons that require and were allowed
special permissions to enable a camera, microphone, accessibility
features, full disk access, or screen captures.
Applicaons Details about all applicaons installed on your endpoints.

For each applicaon, Cortex XDR lists the exisng CVEs and the
vulnerability severity score that reflects the highest NIST vulnerability
score detected for the applicaon.
To further examine these vulnerabilies, see Applicaon Analysis.
Autoruns Details about executables that start automacally when the user logs in
or boots the endpoint.
Endpoint Security
Data Descripon
Cortex XDR displays informaon 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 configuraon,
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:
• Informaon about the daemon, such as the name, type, and path.
• Daemon state, indicang 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.
Drivers Details about all the drivers installed on an endpoint.

For each driver, Cortex XDR lists all the following details:
• Informaon about the driver, such as the driver name, type, and
path.
• Lisng details about the driver runme configuraon:
• The driver type
• Whether the driver is currently running, in which mode, and the
runme 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, indicang whether it is running, requires enabling, or
unloaded.
Groups Details about all user groups defined on an endpoint.

For each group, Cortex XDR lists idenfying 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.
Endpoint Security
Data Descripon
Services Details about all the services running on an endpoint.

For each service, Cortex XDR lists all the following details:
• Informaon about the service, such as the service name, type, and
path.
• Lisng details about the service runme configuraon and status:
• Whether the service is currently running and what is the runme
state
• Whether you can stop, pause, or delay the service start me
• Whether the service requires interacon 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.
• Idenfying details such as folder name, descripon, and path.
• Whether the folder is limited to a maximum number of shares, and
the maximum number of allowed shares.
System Informaon General system informaon about an endpoint.

For each endpoint, Cortex XDR lists all the following details:
• Informaon about the endpoint hardware, such as manufacturer,
model, physical memory, processors architecture, and CPU.
• The operang system name and release running on the endpoint.
Users List of users whose credenals are stored on the endpoint.

For each user, Cortex XDR lists all the following details:
• Idenfying details about the user, such as name and SID/UID.
• Details about the account, such as whether the account is acve and
the account type.
• Informaon about the password set for this user account, such as
whether it is required to login, has an expiraon date, or can be
changed.
Users to Groups A list mapping all the users, local and in your domain, to the exisng
user groups on an endpoint.
Endpoint Security
Data Descripon
• 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
credenals are stored on the Domain Controller server
and not on the endpoint), Cortex XDR will include this
user in the user-to-group mapping, but will not include it
in the users insights view.
Vulnerability Assessment
Cortex XDR vulnerability assessment enables you to idenfy and quanfy the security
vulnerabilies on an endpoint in Cortex XDR. Relying on the informaon from Cortex XDR, you
can easily migate and patch these vulnerabilies on all endpoints in your organizaon.
To provide you with a comprehensive understanding of the vulnerability severity, Cortex XDR
retrieves the latest data for each CVE from the NIST Naonal Vulnerability Database, including
CVE severity and metrics. You can use Cortex XDRto evaluate the extent and severity of each
CVE in your network, gain full visibility in to the risks to which each endpoint is exposed, and
assess the vulnerability status of an installed applicaon in your network.
You can access the Vulnerability Assessment panel from: Assets > Vulnerability Assessment.
Collecng the inial data from all endpoints in your network could take up to 6 hours. Aer that,
Cortex XDR iniates periodical recalculaons to rescan the endpoints and retrieve the updated
data. If at any point you want to force data recalculaon, click Recalculate.
The following are prerequisites for Cortex XDR to perform vulnerability assessment of your
endpoints:

Supported Plaorms • Windows—

• Cortex XDR lists only CVEs relang to the operang
system, and not CVEs relang to applicaons
provided by other vendors.
• Cortex XDRretrieves the latest data for each CVE
from the NIST Naonal Vulnerability Database as
Endpoint Security
well as from the Microso Security Response Center
(MSRC).
• 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
Microso no longer fixes CVEs.
• Linux—Cortex XDR agent 7.1 or a later release.
• Mac—For macOS versions prior to 10.5, Cortex
XDR collects only the applicaons list without CVE
calculaon. Newer macOS versions are currently not
supported.
Setup and Permissions • Ensure Host Inventory Data Collecon is enabled for
your Cortex XDR agent.
Limitaons Cortex XDR calculates CVEs for applicaons according to

the applicaon version, and not according to applicaon
build numbers.
CVE Analysis
To evaluate the extent and severity of each CVE across your endpoints, you can drill down in to
each CVE in Cortex XDR and view all the endpoints and applicaons in your environment that are
impacted by the CVE. Cortex XDR retrieves the latest informaon from the NIST public database.
From Add-ons > Host Insights > Vulnerability Assessment, select CVEs on the upper-right bar. For
each vulnerability, Cortex XDR displays the following default and oponal values:
Value Descripon
Affected endpoints The number of endpoints that are currently

affected by this CVE. For excluded CVEs, the
affected endpoints are N/A.
Applicaons The names of the applicaons 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.
Descripon The general NIST descripon of the CVE.
Endpoint Security
Value Descripon
Excluded Indicates whether this CVE is excluded from

all endpoint and applicaon views and filters,
and from all Host Insights widgets.
Plaorms The name and version of the operang system

affected by this CVE.
Severity The severity level (Crical, 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
descripon.
You can perform the following acons from Cortex XDR as you analyze the exisng vulnerabilies:
• View CVE details—Le-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 applicaons in your network that are impacted by a CVE—Right-click
the CVE and then select View applicaons.
• Exclude irrelevant CVEs from your endpoints and applicaons 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 invesgaon by Palo Alto Networks. The CVE is grayed out and labeled
Excluded and no longer appears on the Endpoints and Applicaons 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 me.
The CVE will be removed/reinstated to all views, filters, and widgets aer the next
vulnerabilies recalculaon.
Endpoint Analysis
To help you assess the vulnerability status of an endpoint, Cortex XDR provides a full list of
all installed applicaons and exisng CVEs per endpoint and also assigns each endpoint a
vulnerability severity score that reflects the highest NIST vulnerability score detected on the
endpoint. This informaon helps you to determine the best course of acon for remediang each
endpoint. From Add-ons > Host Insights > Vulnerability Assessment, select Endpoints on the
upper-right bar. For each endpoint, Cortex XDR displays the following default and oponal values:
Value Descripon
CVEs A list of all CVEs that exist on applicaons

that are installed on the endpoint.
Endpoint Security
Value Descripon

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 me of the last me the Cortex
XDR agent started the process of reporng its
applicaon inventory to Cortex XDR.
MAC address The MAC address associated with the

endpoint.
IP address The IP address associated with the endpoint.
Plaorm The name of the plaorm running on the

endpoint.

database.

descripon.
You can perform the following acons from Cortex XDR as you invesgate and remediate your
endpoints:
• View endpoint details—Le-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 applicaons installed on an endpoint—Right-click the endpoint and
then select View installed applicaons. This list includes the applicaon name, version, and
installaon path on the endpoint. If an installed applicaon has known vulnerabilies, 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 remediaon 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 Microso Windows
Endpoint Security
patches that were installed on the endpoint and a link to the Microso official Knowledge Base
(KB) support arcle.
• Retrieve an updated list of applicaons installed on an endpoint—Right-click the endpoint and
then select Rescan endpoint.
Applicaon Analysis
You can assess the vulnerability status of applicaons in your network using the Host inventory.
Cortex XDR compiles an applicaon inventory of all the applicaons installed in your network
by collecng from each Cortex XDR agent the list of installed applicaons. For each applicaon
on the list, you can see the exisng CVEs and the vulnerability severity score that reflects the
highest NIST vulnerability score detected for the applicaon. Any new applicaon installed on the
endpoint will appear in Cortex XDR with 24 hours. Alternavely, you can re-scan the endpoint to
retrieve the most updated list.
Starng with macOS 10.15, Mac built-in system applicaons are not reported by the
Cortex XDR agent and are not part of the Cortex XDR Applicaon Inventory.
From Add-ons > Host Insights > Host Inventory, select Applicaons.
• To view the details of all the endpoints in your network on which an applicaon is installed,
right-click the applicaon and select View endpoints.
• To view in-depth details about the applicaon, le-click the applicaon name.
Endpoint Security
Invesgaon and Response
> Cortex XDR Rules > Invesgate Files
> Search Queries > Forensic Data Analysis
> Invesgate Incidents > Response Acons
> Invesgate Arfacts and Assets > Playbooks
> Invesgate Alerts > Scripts
> Invesgate Endpoints
287
Cortex XDR Rules

When you idenfy a threat, you can define specific rules for which you want Cortex XDR to raise
alerts. You can define the following rules:
• Behavioral indicators of compromise (BIOCs)—Idenfying threats based on their behaviors
can be quite complex. As you idenfy specific acvies (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 - Analycs, Cortex XDR can also raise Analycs BIOCs (ABIOCs).
Whenever you create or enable a BIOC rule, the rule begins to monitor the stream of incoming
data for any new matches in real-me and analyzes the historical data collected in the Cortex
XDR tenant. BIOCs can also be used for prevenon in real-me at the Cortex XDR Agent level
using a Restricon Profile. See Working with BIOCs.
• Indicators of compromise (IOCs)—Known arfacts that are considered malicious or suspicious.
IOCs are stac and based on criteria, such as SHA256 hashes, IP addresses and domains, file
names, and paths. You create IOC rules based on informaon that you gather from various
threat-intelligence feeds or that you gather as a result of an invesgaon within Cortex XDR.
As soon as you create or enable an IOC rule, the rule begins to monitor the stream of incoming
data for any new matches in real-me and analyzes the historical data collected in the Cortex
XDR tenant. See Working with IOCs.
• Correlaons Rules—Help you analyze correlaons of mul-events from mulple sources by
using the Cortex XDR XQL-based engine for creang scheduled rules called Correlaons Rules.
When created, Correlaon Rules run based on a me interval, as these rules are configured
to run every X min/hours, and on data already in Cortex XDR. See Working with Correlaon
Rules.
Aer you create an indicator rule, you can Manage Exisng Indicators from Cortex XDR.
Working with BIOCs

Behavioral indicators of compromise (BIOCs) enable you to alert and respond to behaviors
—taccs, techniques, and procedures. Instead of hashes and other tradional indicators of
compromise, BIOC rules detect behavior such as is related to processes, registry, files, and
network acvity.
To enable you to take advantage of the latest threat research, Cortex XDR automacally receives
preconfigured rules from Palo Alto Networks. These global rules are delivered to all tenants with
content updates. In cases where you need to override a global BIOC rule, you can disable it or set
a rule excepon. You can also configure addional BIOC rules as you invesgate 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 app begins to monitor input feeds for matches.
Cortex XDR also analyzes historical data collected in the Cortex XDR tenant. Whenever there is a
match, or hit, on a BIOC rule, Cortex XDR logs a Cortex XDR Alert.
To further enhance the BIOC rule capabilies, you can also configure BIOC rules as custom
prevenon rules and incorporate them with your Restricons profiles. Cortex XDR can then raise
behavioral threat prevenon alerts based on your custom prevenon rules in addion to the BIOC
detecon alerts.
• BIOC Rule Details

• Create a BIOC Rule
• Manage Exisng Indicators
• Manage Global BIOC Rules
BIOC Rule Details

If you are assigned a role that enables Invesgaon > Rules privileges, you can view all user-
defined and preconfigured rules for behavioral indicators of compromise (BIOCs) from Detecon
& Threat Intel > Detecon Rules > BIOC.
If you have Cortex XDR - Analycs enabled, Cortex XDR also provides a separate page from
which you can view Analycs BIOCs (ABIOCs). To access this page, use the link next to the refresh
icon at the top of the page.
Each page displays fields that are relevant for the specific rule type. For more informaon, see:
• BIOC Rules Fields
• Analycs BIOC Fields
BIOC Rules Fields
By default, the BIOC Rules page displays all enabled rules. To search for a specific rule, use the
filters above the results table to narrow the results. From the BIOC Rules page, you can also
manage exisng rules using the right-click pivot menu.
The following table describes the fields that are available for each BIOC rule in alphabecal order.
Field Descripon
# OF HITS The number of hits (matches) on 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 mes Cortex XDR searched for the
first 10,000 matches in your Cortex XDR when
the BIOC rule was created or edited.
BEHAVIOR A schemac of the behavior of the rule.
Field Descripon
COMMENT Free-form comments specified when the BIOC

was created or modified.
EXCEPTIONS Excepons to the BIOC rule. When there's a

match on the excepon, the event will not trigger
an alert.
GLOBAL RULE ID Unique idenficaon number assigned to rules

created by Palo Alto Networks.
INSERTION DATE Date and me when the BIOC rule was created.
MITRE ATT&CK TACTIC Displays the type of MITRE ATT&CK tacc the
BIOC rule is aempng to trigger on.
MITRE ATT&CK TECHNIQUE Displays the type of MITRE ATT&CK technique

and sub-technique the BIOC rule is aempng to
trigger on.
MODIFICATION DATE Date and me 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 idenficaon number for the rule.
TYPE Type of BIOC rule:

• Collecon
• Credenal Access
• Dropper
• Evasion
• Execuon
• Evasive
• Exfiltraon
• File Privilege Manipulaon
• File Type Obfuscaon
• Infiltraon
• Lateral Movement
• Other
• Persistence
• Privilege Escalaon
Field Descripon
• 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 Rule status: Enabled or Disabled.
USED IN PROFILES Displays if the BIOC rule is associated with a

Restricon profile.
Analytics BIOC Fields

By default, the Analycs BIOC Rules page displays all enabled rules. To search for a specific rule,
use the filters above the results table to narrow the results. From the Analycs BIOC Rules page,
you can also disable and enable rules using the right-click pivot menu.
The following table describes the fields that are available for each Analycs BIOC rule in
alphabecal order.
Field Descripon
Acvaon Prerequisites Displays a descripon of the prerequisites Cortex

XDR requires in order to acvate the rule.
Descripon Descripon of the behavior that will raise the

alert.
# OF HITS The number of hits (matches) on this rule.
GLOBAL RULE ID Unique idenficaon number assigned to rules

created by Palo Alto Networks.
INSERTION DATE Date and me when the BIOC rule was created.
MITRE ATT&CK TACTIC Displays the type of MITRE ATT&CK tacc the
BIOC rule is aempng to trigger on.

and sub-technique the BIOC rule is aempng to
trigger on.
MODIFICATION DATE Date and me when the BIOC was last modified.
Field Descripon
NAME Unique name that describes the rule. New rules

are idenfied with a blue badge icon.
Rules associated with the Identy Analycs are
displayed with an Identy Analycs tag.
SEVERITY BIOC severity that was defined when the BIOC

rule was created. Severity levels can be Low,
Medium, High, Crical, and Mulple.
Mulple severity BIOC rules can raise alerts with
different severity levels. Hover over the flag to
see the severies defined for the rule.
STATUS Displays whether the rule is Enabled, Disabled,

or Pending Acvaon.
Rules that are Pending Acvaon are in the
process of collecng the data required to enable
the rule. Hover over the field to view how much
data within a certain period of me has already
been collected.
Create a BIOC Rule

Aer idenfying a threat and its characteriscs, you can configure rules for behavioral indicators
of compromise (BIOCs). Aer you create a BIOC rule, Cortex XDR searches for the first 10,000
matches in your Cortex XDR tenant and raise an alert if a match is detected. Going forward, the
app alerts when a new match is detected.
To ensure your BIOC rules raise alerts efficiently and do not overcrowd your Alerts table,
Cortex XDR automacally disables BIOC rules that reach 5000 or more hits over a 24
hour period.
• Create a Rule from Scratch

• Configure a Custom Prevenon Rule
• Import Rules
Create a Rule from Scratch
You can create a new BIOC rule in a similar way as you create a search with Query Builder or by
building the rule query with XQL Search. In both methods, you use Cortex XDR 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 addion, 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 TB license.

• Currently, you cannot create a BIOC rule on customized datasets and only the filter
stage, alter stage, and funcons without any aggregaons are supported for XQL
queries that define a BIOC.
• For BIOC rules, the field values in XQL are evaluated as case insensive (config
case_sensitive = false).
The following is an example of creang a BIOC rule in XQL.
dataset = xdr_data
| filter event_type = PROCESS and
event_sub_type = PROCESS_START and
action_process_image_name ~= ".*?\.(?:pdf|docx)\.exe"
The following describes the event_type values for which you can create a BIOC rule.
• FILE—Events relang to file create, write, read, and rename according to the file name and
path.
• INJECTION—Events related to process injecons.
• LOAD_IMAGE—Events relang to module IDs of processes.
• NETWORK—Events relang to incoming and outgoing network, filed IP addresses, port, host
name, and protocol.
• PROCESS—Events relang to execuon and injecon of a process name, hash, path, and CMD.
• REGISTRY—Events relang to registry write, rename and delete according to registry path.
• STORY—Events relang to a combinaon of firewall and endpoint logs over the network.
• EVENT_LOG—Events relang to Windows event logs and Linux system authencaon logs.
To create a BIOC rule:
STEP 1 | From Cortex XDR, select Detecon & Threat Intel > Detecon Rules > BIOC.
STEP 2 | Select + Add BIOC.
STEP 3 | Configure your BIOC criteria using one of the following methods.
• Build the rule query with XQL Search.
1. Click XQL Search.
2. The XQL query field is where you define the parameters of your query for the BIOC rule.
To help you create an effecve XQL query, the search field provides suggesons 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 addion, 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 funcons without any aggregaons are supported for XQL queries that define a
BIOC. For BIOC rules, the field values in XQL are evaluated as case insensive (config
case_sensitive = false). Aer configuring the XQL query for your BIOC rule and
the syntax is valid, a indicaon is displayed, and it is possible to add the

BIOC rule.
3. Click Test BIOC. Rules that you do not refine enough can create thousands of alerts. As
a result, it is highly recommended that you test the behavior of a new or edited BIOC
rule before you save it. For example, if a rule will return thousands of hits because you
negated a single parameter, it is a good idea to test the rule before you save it and make
it acve.
When you test the rule, Cortex XDR immediately searches for rule matches across all
your Cortex XDR tenant data. If there are surprises, now is the me to see them and
adjust the rule definion. The results are displayed in the Query Results tab underneath
the XQL query field.
For the purpose of showing you the expected behavior of the rule before you
save it, Cortex XDR tests the BIOC on historical logs. Aer 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. (Oponal) Use the Schema tab to view schema informaon for every field found in
the result set. This informaon includes the field name, data type, descripve 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 enty in a similar way that you create a search
with Query Builder.
1. Select a parcular enty icon. Define any relevant acvity or characteriscs for the
enty type. Create a new BIOC rule in the same way that you create a search with Query
Builder. You use XQL to define the rule. The XQL query must filter on an event_type in
order for it to be a valid BIOC rule.
2. Test your BIOC rule. Rules that you do not refine enough can create thousands of alerts.
As a result, it is highly recommended that you test the behavior of a new or edited BIOC
rule before you save it. For example, if a rule will return thousands of hits because you
negated a single parameter, it is a good idea to test the rule before you save it and make
it acve.
When you test the rule, Cortex XDR immediately searches for rule matches across all
your Cortex XDR tenant data. If there are surprises, now is the me to see them and
adjust the rule definion.
For the purpose of showing you the expected behavior of the rule before you
save it, Cortex XDR tests the BIOC on historical logs. Aer you save a BIOC rule,
it will operate on both historical logs (up to 10,000 hits) and new data received
from your log sensors.
3. Save your BIOC rule.
STEP 4 | Define the following parameters.

1. Name—Specify a descripve Name to idenfy the BIOC rule or leave the default name
that is automacally populated using the format XQL-BIOC-<rule number>.
2. Type—Select a rule TYPE which describes the acvity.
3. Severity—Specify the Severity you want to associate with an alert generated based on
this rule.
4. (Oponal) Select the MITRE Technique and MITRE Tacc you want to associate with the
alert. You can select up to 3 MITRE Techniques/Sub-Techniques and MITRE Taccs.
5. (Oponal) Select the +<number> more global excepons to view the EXCEPTIONS
associated with this BIOC rule.
6. (Oponal) Comment—Specify any addional comments, such as why you created the
BIOC.
7. Click OK.
Configure a Custom Prevention Rule

Custom prevenon rules are supported on Cortex XDR agent 7.2 and later versions and enable
you to configure and apply user-defined BIOC rules to Restricon profiles deployed on your
Windows, Mac, and Linux endpoints.
By using the BIOC rules, you can configure custom prevenon rules to terminate the causality
chain of a malicious process according to the Acon Mode defined in the associated Restricons
Security Profile and trigger Cortex XDR Agent behavioral prevenon type alerts in addion to the
BIOC rule detecon alerts.
For example, if you configure a custom prevenon rule for a BIOC Process event, apply it to
Restricons profile with an acon mode set to Block, the Cortex XDR agent:
• Blocks a process at the endpoint level according to the defined rule properes.
• Raises a behavioral prevenon alert you can monitor and invesgate in the Alerts table.
Before you configure a BIOC rule as a custom prevenon rule, create a Restricon Profile for each
type of operang system (OS) that you want to deploy your prevenon rules.
To configure a BIOC rule as a prevenon rule.
STEP 1 | In the BIOC Rule table, from the Source field, filter and locate a user-defined rule you want
to apply as a custom prevenon 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 event does not include the following field configuraons.
• All Events—Host Name
• File Event—Device Type, Device Serial Number
• Process Event—Device Type, Device Serial Number
• Registry Event—Country, Raw Packet
• BIOC rules with OS scope definions must align with the Restricons 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.
STEP 2 | Test your BIOC rule.

Rules that you do not refine enough can create thousands of alerts. As a result, it is highly
recommended that you test the behavior of a new or edited BIOC rule before you save it.
Cortex XDR automacally disables BIOC rules that reach 5000 or more hits over a 24 hour
period.
STEP 3 | Right-click and select Add to restricons profile.

If the rule is already referenced by one or more profiles, select See profiles to view the profile
names.
STEP 4 | In the Add to Restricons Profile pop-up:

• Ensure the rule you selected is compable with the type of endpoint operang system.
• Select the Restricon Profile name you want to apply the BIOC rule to for each of the
operang systems. BIOC event rules of type Event Log and Registry are only supported by
Windows OS.
You can only add to exisng profiles you created, Cortex XDR Default profiles will
not appear as an opon.
STEP 5 | Add the BIOC rule to the selected profiles.

The BIOC rule is now configured as a custom prevenon rule and applied to your Restricon
profiles. Aer the Restricon profile is pushed to your endpoints, the custom prevenon rule
can start triggering behavioral prevenon type alerts.
STEP 6 | Review and edit your custom prevenon rules.

1. Navigate to Endpoints > Policy Management > Profiles.
2. Locate the Restricons Profile to which you applied the BIOC rule. In the Summary field,
Custom Prevenon Rules appears as Enabled.
3. Right-click and select Edit.
4. In the Custom Prevenon Rules secon, you can review and modify the following:
• Acon Mode—Select to Enable or Disable the BIOC prevenon rules.
• Auto-disable—Select if to auto-disable a BIOC prevenon rule if it triggers aer a
defined number of mes during a defined duraon.
Auto-disable will turn off both the BIOC rule detecon and the BIOC
prevenon rule.
• Prevenon BIOC Rules table—Filter and maintain the BIOC rules applied to this
specific Restricon Profile. Right-click to Delete a rule or Go to BIOC Rules table.
5. Save your changes if necessary.
6. Invesgate the BIOC prevenon rules alerts.
• Select Incident Response > Incidents > Alerts Table.
• Filter the fields as follows:
• Alert Source: XDR Agent
• Acon: Prevention (<profile action mode>)
• Alert Name: Behavioral Threat
• In the Descripon field you can see the rule name that raised the prevenon alert.
Import Rules
You can use the import feature of Cortex XDR to import BIOCs from external feeds or that you
previously exported. The export/import capability is useful for rapid copying of BIOCs across
different Cortex XDR instances.
You can only import files that were exported from Cortex XDR. You can not edit an
exported file.
STEP 2 | Select Import Rules.
STEP 3 | Drag and drop the file on the import rules dialog or browse to a file.
STEP 4 | Click Import.

Cortex XDR loads any BIOC rules. This process may take a few minutes depending on the size
of the file.
STEP 5 | Refresh the BIOC Rules page to view matches (# of Hits) in your historical data.
STEP 6 | To invesgate any matches, view the Alerts page and filter the Alert Name by the name of
the BIOC rule.
Manage Global BIOC Rules

Cortex XDR checks for the latest update of global BIOC rules. If there are no new global BIOC
rules, the app displays a content status of Content up to date next to the BIOC rules table
heading. A dot to the le of the rule name indicates a global BIOC rule.
You can also view the oponal Source field to see which rules are pushed by Palo Alto Networks.
• Get the latest global BIOC rules.
• Copy a global BIOC rule.
• Add a Rule Excepon.
Get the latest global BIOC rules.

1. Navigate to Detecon & Threat Intel > Detecon Rules > BIOC.
2. To view the content details, hover over the status Content up to date, to show the global
rules version number and last check date.
The content status displays the date when the content was last updated, either
automacally or manually by an administrator.
3. If the status displays Could not check update, click the status to check for updates
manually.
The last updated date changes when the download is successful.
Copy a global BIOC rule.

You cannot directly modify a global rule, but you can copy global rules as a template to create
new rules.
1. Locate a Palo Alto Networks Source type rule, right-click and select Save as New.
2. Select OK to save the rule.
The rule appears in the BIOC Rules table as a user-defined Source type rule which you
can edit.
Add a Rule Excepon.

Although you cannot edit global rules, you can add excepons to the rule, if needed.
Working with IOCs

IOCs provide the ability to alert on known malicious objects on endpoints across the organizaon.
You can load IOC lists from various 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
• Desnaon IP address
• MD5 hash
• SHA256 hash
Aer you define or load IOCs, the app checks for matches in the endpoint data collected from
Cortex XDR agents. Checks are both retroacve and ongoing: The app looks for IOC matches in all
data collected in the past and connues to evaluate new any new data it receives in the future.
Alerts for IOCs are idenfied by a source type of IOC (see Alerts for more informaon).
• IOC Rule Details
• Create an IOC Rule
• Manage Exisng Indicators
IOC Rule Details

From the Rules > IOC page, you can view all indicators of compromise (IOCs) configured from or
uploaded to the Cortex XDR app. To filter the number of IOC rules you see, you can create filter
by one or more fields in the IOC rules table. From the IOC page, you can also manage or clone
exisng rules.
The following table describes the fields that are available for each IOC rule in alphabecal order.
Field Descripon
# OF HITS The number of hits (matches) on this indicator.
CLASS The IOC's class. For example, 'Malware'.
COMMENT Free-form comments specified when the IOC was

created or modified.
EXPIRATION DATE The date and me at which the IOC will be removed
automacally.
INDICATOR The indicator value itself. For example, if the

indicator type is a desnaon IP address, this could
be an IP address such as 1.1.1.1.
INSERTION DATE Date and me when the IOC was created.
MODIFICATION DATE Date and me when the IOC was last modified.
RELIABILITY Indicator's reliability level:

• A - Completely Reliable
• B - Usually Reliable
Field Descripon
• C - Fairly Reliable
• D - Not Usually Reliable
• E - Unreliable
REPUTATION Indicator's reputaon level. One of Unknown, Good,

Bad, or Suspicious.
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.
TYPE Type of indicator: Full path, File name, Host name,

Desnaon IP, MD5 hash.
VENDORS A list of threat intelligence vendors from which this

IOC was obtained.
Create an IOC Rule

There are two opons for creang new indicator of compromise (IOC) rules:
• Configure a single IOC.
• Upload a file, one IOC per line, that contains up to 20,000 IOCs. For example, you can upload
mulple file paths and MD5 hashes for an IOC rule. To help you format the upload file in the
syntax that Cortex XDR will accept, you can download the example file.
If you have a Cortex XDR Pro per Endpoint license, you can upload IOCs using REST APIs in
either CSV or JSON format.
To ensure your IOC rules raise alerts efficiently and do not overcrowd your Alerts table,
Cortex XDR automacally:
• Disables any IOC rules that reach 5000 or more hits over a 24 hour period.
• Creates a Rule Excepon based on the PROCESS SHA256 field for IOC rules that hit
more than 100 endpoints over a 72 hour period.
STEP 1 | From Cortex XDR, select Detedon & Threat Intel > Detecon Rules > IOC.
STEP 2 | Select + Add IOC.
STEP 3 | Configure the IOC criteria.

If aer invesgang a threat, you idenfy a malicious arfact, 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. Opons are Full Path, File Name, Domain, Desnaon IP, and
MD5 or SHA256 Hash.
3. Configure the SEVERITY you want to associate with an alert for the IOC.
4. (Oponal) Enter a comment that describes the IOC.
5. (Oponal) Configure the IOC's REPUTATION.
6. (Oponal) Configure the IOC's RELIABILITY.
7. (Oponal) Enter an EXPIRATION for the IOC. Opons are Default, Specific Expiraon
Date, No Expiraon.
8. Click Create.
If you want to match on mulple indicators, you can upload the criteria in a CSV file.
1. Select Upload File.
2. Drag and drop the CSV file containing the IOC criteria in the drop area of the Upload File
dialog or browse to the file.
Cortex XDR supports a file with mulple IOCs in a pre-configured format. For help
determining the format syntax, Cortex XDR provides an example text file that you can
download.
3. Configure the SEVERITY you want to associate with an alert for the IOCs.
4. Define the DATA FORMAT of the IOCs in the CSV file. Opons are Mixed, Full Path, File
Name, Domain, Desnaon IP, and MD5 or SHA256 Hash.
5. (Oponal) Configure the IOC's REPUTATION.
6. (Oponal) Configure the IOC's RELIABILITY.
7. (Oponal) Enter an EXPIRATION for the IOC. Opons are Default, Specific Expiraon
Date, No Expiraon.
8. Click Upload.
STEP 4 | (Oponal) Define any expiraon criteria for your IOC rules.
If desired, you can also configure addional expiraon criteria per IOC type to apply to all IOC
rules. In most cases, IOC types like Desnaon IP or Host Name are considered malicious only
for a short period of me since they are soon cleaned and then used by legimate services,
from which me they only cause false posives. For these types of IOCs, you can set a defined
expiraon period. The expiraon criteria you define for an IOC type will apply to all exisng
rules and addional rules that you create in the future. By default, Cortex XDR does not apply
an expiraon date set on IOCs.
1. Select Default Rule Expiraon.
2. Set the expiraon for any relevant IOC type. Opons are Never, 7 Days, 30 days, 90
days, or 180 days.
3. Click Save.
Working with Correlaon Rules

Correlaon Rules require a Cortex XDR Pro license. There may be future changes to the
Correlaon Rules offerings, which can impact your licensing agreements. You will receive
noficaon ahead of me before any changes are implemented.
Correlaon Rules help you analyze correlaons of mul-events from mulple sources by using the
Cortex XDR XQL-based engine for creang scheduled rules called Correlaon Rules. Alerts can
then be triggered based on these Correlaon Rules with a defined me frame and set schedule,
including every X minutes, once a day, once a week, or a custom me.
Once you have configured your Correlaon Rules, you can manage the Correlaon Rules in the
Correlaon Rules page, view and analyze the alerts generated from the Correlaon Rules in the
Alerts and Incidents pages. In addion, these Correlaon Rules are factored into the number of
incidents displayed on the Cortex XDR Dashboard.
• Correlaon Rule Details
• Create a Correlaon Rule
Correlaon Rule Details
Correlaon Rules require a Cortex XDR Pro license. There may be future changes to the
If you are assigned a role that enables Invesgaon > Rules privileges, you can view all user-
defined Correlaon Rules from Detecon & Threat Intel > Detecon Rules > Correlaons.
By default, the Correlaon 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 Correlaon Rules page, you can
also manage exisng rules using the right-click pivot menu.
In addion, the Correlaon Rules page helps you easily idenfy and resolve Correlaon Rules
errors. The number of errors are indicated at the top of the page in a red font using the format
<number> errors found. You can change the view to only display the Correlaon Rules with errors
by selecng Show Errors Only. The LAST EXECUTION column in the table indicates a Correlaon
Rule with an error by displaying the last execuon me in a red font and providing a descripon
of the Correlaon Rule Error when hovering over the field. The following error messages are
displayed in the applicable scenarios.
• Invalid query
• Query meout
• Dependency correlaon did not complete
• Unknown error
• Delayed rule—This rule is running past its scheduled me, which can cause delayed results.
• Dataset does not exist: <name of dataset>
Only 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.
A noficaon is also displayed in Cortex XDR to indicate these Correlaon Rules errors.
The following table describes the fields that are available for each Correlaon Rule in alphabecal
order.
exposed by default.
Field Descripon
# OF ALERTS* The number of alerts triggered for this rule.
ALERT CATEGORY* Type of alert as configured when creang the rule.

• Collecon
• Dropper
• Evasion
• Execuon
• Evasive
• Exfiltraon
• Infiltraon
• Persistence
• Reconnaissance
• Tampering
• Other
DATASET* The text displayed here depends on the resulng

acon configured for the Correlaon Rule when
the rule was created.
• alerts—When your resulng acon for the rule
was configured to Generate alert.
Field Descripon
• Dataset name—When your resulng acon for
the rule was configured to Save to dataset.
DESCRIPTION* The descripon for the Correlaon Rule that was

configured when the rule was created.
DRILL-DOWN QUERY Displays the Drill-Down Query that you

configured for addional informaon about the
alert for further invesgaon using XQL when you
created the rule. If you did not configure one, the
field is le empty.
Once configured any alert generated for
the Correlaon Rule has a right-click pivot
menu Open Drilldown Query opon,
an Open drilldown query link aer you
Invesgate Contribung Events, and a
quick acon 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 opon, link, or icon is
displayed.
The Drill-Down Query Time Frame can be
configured as either.
• Generated Alert—Uses the me frame of the
alert that is triggered, which is the first event
and last event mestamps for the alert (default
opon).
• XQL Search—Uses the me frame from when
the Correlaon Rule was run in XQL Search.
FAILURE REASON For a Correlaon Rule with an error, displays the

error message, which can be one of the following.
• Invalid query
• Query meout
• Dependency correlaon did not complete
• Unknown error
• Delayed rule—This rule is running past its
scheduled me, which can cause delayed
results.
Field Descripon
• Dataset does not exist: <name of dataset>
Only 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.
INSERTION DATE Date and me when the Correlaon Rule was
created.
LAST EXECUTION* Date and me when the Correlaon Rule was last
executed. Indicates a Correlaon Rule with an
error by displaying the last execuon me in a red
font and providing a descripon of the Correlaon
Rule Error when hovering over the field.
MITRE ATT&CK TACTIC* Displays the type of MITRE ATT&CK tacc the
Correlaon Rule is aempng to trigger on.
MITRE ATT&CK TECHNIQUE* Displays the type of MITRE ATT&CK technique

and sub-technique the Correlaon rule is
aempng to trigger on.
MODIFICATION DATE* Date and me when the Correlaon Rule was last
modified.
NAME* Unique name that describes the rule.
SCHEDULE* Displays the Time Schedule for the frequency

of running the XQL Search definion set for the
Correlaon Rule when the rule was created. The
opons displayed are one of the following.
• Every 10 Minutes
• Hourly
• Daily
• Displays the Time Schedule as Cron Expression
fields.
SEVERITY* Correlaon Rule severity that was defined when

the Correlaon Rule was created. Severity levels
Field Descripon
can be Informaonal, Low, Medium, High,
Crical, and Customized.
Whenever an alert is generated with a severity
type of Medium and above based on the
Correlaon Rule, a new incident is automacally
opened.
SOURCE* User who created this Correlaon Rule.
SUPPRESSION DURATION* The duraon me 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 oponal to configure.
SUPPRESSION STATUS* Displays the Suppression Status as either Enabled

or Disabled as configured when the rule was
created.
TIME FRAME* Displays the me 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
definion set for the Correlaon Rule is set to run
daily or using a cron expression. Otherwise, this
field is le empty.
XQL SEARCH Displays the XQL definion for the Correlaon

Rule that was configured in XQL Search when the
rule was created.
Create a Correlaon Rule
Correlaon Rules requires a Cortex XDR Pro license. There may be future changes to the
You can create a new Correlaon Rule from either the Correlaon Rules page or when building a
query in XQL Search.
When seng up Correlaon Rules, you have the following capabilies.

• Define when the Correlaon Rule runs.
• Define whether alerts generated by the Correlaon Rule are suppressed by a duraon me and
field.
• Set the resulng acon for the Correlaon Rule as either to generate an alert or save the data
to a dataset.
• When generang an alert, you can also define the alert sengs, which includes the Alerts
Field Mapping for incident enrichment, Alert Severity, MITRE Aack Taccs and Techniques,
and other alert sengs.
• When saving the data to a dataset, you can test and fine-tune new rules before iniang
alerts and applying correlaon of correlaon use-cases.
To create a Correlaon Rule in Cortex XDR .
STEP 1 | Open the New Correlaon Rule editor.
You can do this in two ways.
• From the Correlaon Rules page.
1. Select Detecon & Threat Intel > Detecon Rules > Correlaons.
2. Select +Add Correlaon.
• From XQL Search.
1. Select Incident Response > Invesgaon > Query Builder > XQL Search.
2. In the XQL query field, define the parameters for your Correlaon Rule.
3. Select Save as > Correlaon Rule.
The New Correlaon Rule editor is displayed where the XQL Search secon is populated
with the query you already set in the XQL query field.
STEP 2 | Configure the General sengs.

• Specify a descripve Name to idenfy the Correlaon Rule.
• (Oponal) Specify a Descripon for the Correlaon Rule.
STEP 3 | Use XQL to define the Correlaon Rule in XQL Search field.
Define the Correlaon Rule in the XQL Search field. Aer wring at least one line in XQL, you
can Open full query mode to display the query in XQL Search. You can Test the XQL definion
for the rule whenever you want.
When you open the New Correlaon Rule editor from XQL Search, this XQL Search
field is already populated with the XQL query that you defined.
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 exisng dataset.
When you finish wring the XQL for the Correlaon Rule definion, select Connue eding
rule to bring you back to the New Correlaon Rule editor, and the complete query you set is
added to the XQL Search field.
The XQL features for transaction, call, and wildcards in datasets (dataset in
(<dataset prefix>_*)) are not currently supported in Correlaon Rules. If you
add them to the XQL definion, you will not be able to Create or Save the Correlaon
Rule.
Using the current_me() funcon in your XQL query for a correlaon rule may yield
unexpected results when there are lags or during downme. This happens if the
correlaon rule doesn’t run exactly at the me of the data inside the meframe, 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.
STEP 4 | Configure the Timing sengs.

• Time Schedule—Select the Time Schedule for the frequency of running the XQL Search
definion set for the Correlaon 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.
• 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 parcular Timezone.
• Custom— Displays the Time Schedule as Cron Expression fields, where you can set the
cron expression in each me 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 parcular Timezone.
• Timezone—(Oponal) You can only set the Timezone when the Time Schedule is set to
Daily or Custom. Otherwise, the opon is disabled.
• Query me frame—Set the me 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.
By default, the query is to run once an hour (1 Hour/s).
STEP 5 | (Oponal) Configure Alert Suppression sengs.

Define whether the alerts generated by the Correlaon Rule are suppressed by a duraon me,
field, or both.
• Enable alert suppression—Select this checkbox to Enable alert suppression. By default, this
checkbox is clear and the alerts of the Correlaon Rule are configured to not be suppressed.
• Duraon me—Set the Duraon me 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 Duraon me can be
configured for a maximum of 1 day.
• Fields—(Oponal) 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 mulple fields from the list.
• Select Select all to configure all the fields for suppression. This means that all the fields
must match for the alerts to be suppressed. This opon will generate mulple alerts
during the suppression period.
• Search for a parcular field, which narrows the available opons as you begin typing.
• Do not set any Fields by leaving the field empty only 1 alert is generated during the
suppression period.
STEP 6 | Configure the resulng Acon for the Correlaon Rule.

1. You can select either of the following resulng acons to occur, where the configuraon
sengs change depending on your selecon.
• Generate alert—Generates a Correlaon type of alert according to the configured
sengs in the New Correlaon Rule editor (default). When this opon is selected a
number of new secons are opened to configure the alert.
• Save to dataset—Saves the data generated from the Correlaon Rule to a separate
Target Dataset. This opon is helpful when you are fine-tuning and tesng a rule
before promong the rule to producon. You can also save a rule to a dataset as a
building block for the next Correlaon Rule, which will be based on the results of the
first Correlaon 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 preexisng Target Dataset that was created for a different
Correlaon Rule. The list only displays the datasets configured when creang a
Correlaon Rule. Different Correlaon Rules can be saved to the same dataset and
Cortex XDR will expand the dataset schema as needed. The dataset you configure for
the Correlaon Rule contains the following addional fields.
• _rule_id
• _rule_name
• _insert_time
When you are finished configuring the Target Dataset, you can either Save for later the
Correlaon Rule or Create the Correlaon Rule.
2. Configure the Alert Sengs.
• 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 Correlaon
Rule as one of the following.
• Informaonal
• Low
• Medium
• High
• Crical
• User Defined—Select fields from inside the query.
Whenever the severity type is Medium or above for the alert generated, an
incident is automacally opened.
• Category—Select the type of alert that is generated, which can be any of the
following.
• Collecon
• Dropper
• Evasion
• Execuon
• Evasive
• Exfiltraon
• Infiltraon
• Persistence
• Reconnaissance
• Tampering
• Other
• User Defined—Select fields from inside the query.
• Alert Descripon—(Oponal) Specify a descripon 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 validaon 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 descripons.
• Drill-Down Query—(Oponal) You can configure a Drill-Down Query for addional
informaon about the alert for further invesgaon using XQL. This XQL query can
accept parameters from the alert output for the Correlaon Rule. Yet, keep in mind
that when you create the Correlaon Rule, Cortex XDRdoes 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 Descripon.
Once configured any alert generated for the Correlaon Rule has a right-click
pivot menu Open Drilldown Query opon, an Open drilldown query link aer you
Invesgate Contribung Events, and a quick acon 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
opon, link, or icon is displayed.
• Drill-Down Query Time Frame—Select the me frame used to run the Drill-Down
Query from one of the following opons, which provides more informave details
about the alert generated by the Correlaon Rule.
• Generated Alert—Uses the me frame of the alert that is triggered, which is the
first event and last event mestamps for the alert (default opon). If there is only
one event, the event mestamp is the me frame used for the query.
• XQL Search—Uses the me frame from when the Correlaon Rule was run in XQL
Search.
• MITRE ATT&CK—(Oponal) Select the MITRE Taccs and MITRE Techniques you
want to associate with the alert using the MITRE ATT&CK matrix.
1. You can access the matrix by selecng the MITRE ATT&CK bar or Open complete
MITRE matrix link underneath the bar on the right.
2. Select the MITRE Taccs 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 Taccs only, MITRE techniques and Sub-
Techniques only, or a combinaon of both.
3. Click Select and the matrix window closes and the MITRE ATT&CK secon in
the New Correlaon Rule editor lists the number of Taccs and Techniques
configured, which is also listed in the bar. For example, in the following image,
there are 3 Taccs and 4 Techniques configured. The three MITRE Taccs are
Resource Development with 2 Techniques configured, Credenal Access with 1
Technique configured, and Discovery with 1 Technique configured.
3. (Oponal) Configure the Alerts Fields Mappings.
You can map the alert fields, so that the mapped fields are displayed in the Alerts page
to provide important informaon in analyzing your alerts. In addion, mapping the fields
helps to improve incident grouping logic and enables Cortex XDR to list the arfacts
and assets based on the map fields in the incident. The opons available can change
depending on your Correlaon Rule definions in XQL Search. There are two ways to
map the alert fields.
• Use the Cortex XDR default incident enrichment—Select this opon if you want
Cortex XDR to automacally map the fields for you. This checkbox only displays when
your Correlaon Rule can be configured to use Cortex XDR incident enrichment and
then it is set as the default opon. We recommend using this opon whenever it is
available to you.
• Manually map the alert fields by selecng the fields that you want to map. When you
create the Correlaon 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.
STEP 7 | (Oponal) Save for later the Correlaon Rule.

Select Save for later > Create when you want to finish configuring your Correlaon Rule at
a different me, but do not want to lose your sengs. The Create buon is only enabled
when you have configured all the mandatory fields in the New Correlaon Rule editor. Once
configured, your Correlaon Rule is listed in the Correlaon Rules page, but is disabled. You
can edit or enable the rule at any me by right-clicking the rule and selecng Edit Rule or
Enable.
STEP 8 | Create the Correlaon Rule.

The rule is added to the table in the Correlaon Rules page as an acve rule and a noficaon
is displayed.
STEP 9 | Manage a Correlaon Rule, as needed.

At any me, you can return to the Correlaon Rules page to view and manage your Correlaon
Rules. To manage a Correlaon Rule, right-click the Correlaon Rule and select the desired
acon.
• Open in XQL—View the XQL results for the Correlaon Rule in XQL Search. You can Show
results in new tab or Show results in same tab.
• View related alerts—View the alerts generated by this Correlaon Rule in the Alerts page.
You can Show alerts in new tab or Show alerts in same tab.
• Execute Rule—Run the rule now without waing for the scheduled me.
• Disable the selected Correlaon Rule. This opon is only available on an acve rule.
• Enable the selected Correlaon Rule. This opon is only available on an inacve rule.
• Edit Rule—Edit the rule parameters configured in the Edit Correlaon Rule editor.
• Save as new—Duplicate the Correlaon Rule and save it as a new Correlaon Rule.
• Delete the Correlaon Rule.
• Show rows with ‘<field value>’ to filter the Correlaon Rules list to only display the
Correlaon Rules with a specific field value that you selected in the table. On certain fields
that are null, this opon does not display.
• Hide rows with ‘<Rule Descripon>’ to filter the Correlaon Rules list to hide the
Correlaon Rules with a specific field value that you selected in the table. On certain fields
that are null, this opon does not display.
• Copy enre row to copy the text from all the fields in a row of a Correlaon Rule.
Manage Exisng Indicators

Aer you create an indicator rule, you can take the following acons:
For Analycs BIOC rules, you can only disable and enable rules.
• View Alerts Triggered by a Rule

• Use a BIOC Rule as the Basis of a Query
• Edit a Rule
• Export a Rule (BIOC Only)

• Copy a BIOC Rule
• Disable or Remove a Rule
• Add a Rule Excepon
• Export a Rule Excepon
View Alerts Triggered by a Rule

As your IOC and BIOC rules trigger alerts, Cortex XDR displays the total # OF HITS for the rule in
the on the BIOC or IOC rules page. For rules with a high, medium, or low severity that have raised
one or more alerts, you can quickly pivot to a filtered view of those alerts raised by the indicator:
STEP 1 | From Cortex XDR, select Detecon & Threat Intel > Detecon Rules and the type of rule
(BIOC or IOC).
STEP 2 | Right-click anywhere in a rule, and then select View associated alerts.
Cortex XDR displays a filtered query of alerts associated with the Rule ID.
Use a BIOC Rule as the Basis of a Query

(BIOC or IOC).
STEP 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.
STEP 3 | If desired, add or change the query criteria.
STEP 4 | (Oponal) Test your query to see the sample results.
STEP 5 | If you are sasfied with query, Save the query.

For more informaon, see Manage Your Queries.
Edit a Rule
Aer you create a rule, it may be necessary to tweak or change the rule sengs. You can open the
rule configuraon from the Rules page or from the pivot menu of an alert triggered by the rule. To
edit the rule from the Rules page:
(BIOC or IOC).
STEP 2 | Locate the rule you want to edit.
STEP 3 | Right click anywhere in the rule and select Edit.
STEP 4 | Edit the rule sengs as needed, and then click OK.
If you make any changes, Test and then Save the rule.
Export a Rule (BIOC Only)

STEP 2 | Select the rules that you want to export.
STEP 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 exisng 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. See Manage Global BIOC
Rules.
STEP 1 | From Cortex XDR, select Detecon & Threat Intel > Detecon Rules and then BIOC.
STEP 2 | Locate the rule you want to copy.
STEP 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.
(BIOC or IOC).
STEP 2 | Locate the rule that you want to change.
STEP 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.
Add a Rule Excepon

If you want to create a rule to take acon on specific behaviors but also want to exclude one
or more indicators from the rule, you can create a rule excepon. 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 informaon about these
indicators, see Rules. For each excepon, you also specify the rule scope to which excepon
applies.
Cortex XDR only supports excepons with one aribute. See Add an Alert Exclusion
Policy to create advanced excepons based on your filtered criteria.
STEP 1 | From Cortex XDR, select Detecon & Threat Intel > Detecon Rules > Excepons.
STEP 2 | Select + New Excepon.
STEP 3 | Configure the indicators and condions for which you want to set the excepon.
STEP 4 | Choose the scope of the excepon, whether the excepon applies to IOCs, BIOCs, or both.
STEP 5 | Save the excepon.

By default, acvity matching the indicators does not trigger any rule. As an alternave, you
can select one or more rules. Aer you save the excepon, the Excepons count for the
rule increments. If you later edit the rule, you will also see the excepon defined in the rule
summary.
Export A Rule Excepon

You can choose to export a BIOC rule excepon.
STEP 1 | From Cortex XDR, select Detecon & Threat Intel > Detecon Rules > Excepons.
STEP 2 | In the Excepons table, locate the excepon rule you want to export. You can select mulple
rules.
STEP 3 | Right-click and select Export.

If one or more of the selected excepons are applied to a specific BIOC rule, select one of the
following opons:
• Export anyway
• Export only non-specific Excepons—Only export excepons applied on all BIOC rules.
• Export all Excepons as non-specific—Export and apply specific Excepons to BIOC rules.
Search Queries
• Cortex XDR Query Builder
• Query Center
• Scheduled Queries
• Quick Launcher
• Research a Known Threat
Cortex XDR Query Builder

The Query Builder is a powerful search tool at the heart of Cortex XDR that you can use to
invesgate any lead quickly, expose the root cause of an alert, perform damage assessment, and
hunt for threats from your data sources. With Query Builder, you can build complex queries for
enes and enty aributes so that you can surface and idenfy connecons between them. The
Query Builder searches the raw data and logs stored in Cortex XDR tenant and Cortex XDR for
the enes and aributes you specify and returns up to 10,000 results.
From the Query Builder, you can also use the XQL Search to create XQL queries to search for and
view raw data that is stored in Cortex XDR or imported from custom and third-party datasets.
The Query Builder provides queries for the following types of enes:
• Process—Search on process execuon and injecon by process name, hash, path, command-
line arguments, and more. See Create a Process Query.
• File—Search on file creaon and modificaon acvity by file name and path. See Create a File
Query.
• Network—Search network acvity by IP address, port, host name, protocol, and more. See
Create a Network Query.
• Registry—Search on registry creaon and modificaon acvity by key, key value, path, and
data. See Create a Registry Query.
• Event Log—Search Windows event logs and Linux system authencaon logs by username, log
event ID (Windows only), log level, and message. See Create an Event Log Query.
• Network Connecons—Search security event logs by firewall logs, endpoint raw data over your
network. See Create a Network Connecons Query.
• All Acons—Search across all network, registry, file, and process acvity by endpoint or
process. See Query Across All Enes.
The Query Builder also provides flexibility for both on-demand query generaon and scheduled
queries.
XQL Search
The XDR Query Language (XQL) enables you to query data ingested into Cortex XDR for rigorous
endpoint and network event analysis returning up to 1M results. XQL forms queries in stages.
Each stage performs a specific query operaon and is delimited by a pipe (|). Queries require a
dataset, or data source, to run against. Unless otherwise specified, the query will run against the
xdr_data dataset, which contains all log informaon that Cortex XDR collects. You can also
configure Cortex XDR to query addional datasets.
It is possible to create a dataset with uppercase characters in its name, but when creang a query,
the dataset name only uses lowercase characters.
To streamline your invesgaons, the XQL search provides the following aids to help you
construct and visualize your queries.
• XQL query—The XQL query field is where you define the parameters of your query. To help
you create an effecve XQL query, the search field provides suggesons and definions as you
type.
• Translate to XQL— Converts your exisng Splunk queries to the XQL syntax. When building
your XQL query and you move the toggle to Translate to XQL, 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 opon is disabled by default, so only the XQL query field is displayed.
• Query Results—Aer you create and run an XQL query, you can view, filter, and visualize your
Query Results.
• XQL Helper—Describes common stage commands and provides of 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 addion, a Personal Query Library for saving and managing your own queries that you can
also share with others, and queries shared with you.
• Schema—Contains schema informaon for every field found in the result set. This informaon
includes the field name, data type, descripve 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.
In the XQL, every user field included in the raw data, for network, authencaon, and login
events, has an equivalent normalized user field associated with it that displays the user
informaon 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.
For further help construcng queries, use the Cortex XDR XQL Language Reference.
Create an XQL Query
Use XQL Search to analyze raw log data stored in Cortex XDR. The following task demonstrates
how to create a query that uses the coalesce funcon to derive a single username by
examining mulple field names.
The XQL Language Reference provides more informaon about valid commands, such as the ones
used in this example, and general XQL syntax.
STEP 1 | From Cortex XDR, select Incident Response > Invesgaon > Query Builder > XQL Search.
STEP 2 | Determine the type of XQL query you are creang.

• To create an XQL query from scratch, use the default XQL query field to build your query.
• To create an XQL query based on a Splunk query, move the toggle to Translate to XQL,
where both a SPL query field and XQL query field are displayed. You can easily add a Splunk
query in the SPL query field, which is converted to XQL in the XQL query field aer you
click the arrow ( ). This opon is disabled by default, so only the XQL query field is
displayed. When building a Splunk query, skip to step #6. For more informaon on creang
Splunk queries, see Translate to XQL.
STEP 3 | (Oponal) 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. For more informaon, see how to manage datasets. See the XQL
Language Reference for a list of the datasets that are available to you, depending on your
configuraon.
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 exisng dataset.
You can specify a dataset using one of the following formats, which is based on the data
retenon offerings available in Cortex XDR.
• Hot Storage queries are performed on a dataset using the format dataset = <dataset
name>. This is the default opon.
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 invesgates data in both a cold_dataset and hot
dataset in the same query. In addion, since the hot storage dataset format is the
default opon and represents the fully searchable storage, for invesgaon and threat
hunng, this format is used throughout this guide. For more informaon on hot and
cold storage, see Dataset Management.
From the first leer that you type, the query field provides you with suggesons of commands
and their definions.
When you select a command, you will see available operators.
Aer selecng the operator, the query field presents available values.
STEP 4 | Hit the return key and enter a pipe (|) followed by the first stage of your query.
This stage uses the fields command to declare which fields are returned in the results. If you
use this stage, then following stages can only operate on the fields specified in it.
STEP 5 | Connue adding stages unl your query is complete.

This stage uses the funcon coalesce to return the first value that is not NULL out of the
given fields and the alter stage command to assign that value to the field username.
STEP 6 | Specify the me period against which you want to run your query.
The opons are last 24H (hours), last 7D (days), last 1M (month), or select a Custom me
period.
STEP 7 | Choose when to run the query.

Select the calendar icon to schedule a query to run on or before a specific date, Add as BIOC
to save the query as a BIOC rule (if compable), Run in background (that is, as resources are
available), or Run the query immediately.
Cold Storage queries (cold_dataset = <dataset name>) can only Run in

background as they take more resources to run.
STEP 8 | (Oponal) Aer your query is complete, you can save the query as one of the following rules.
• BIOC Rule—Save as > BIOC Rule. The XQL query must at a minimum filter on the
event_type field in order for it to be a valid BIOC rule that you can save. For more
informaon, see Working with BIOCs.
• Correlaon Rule—Save as > Correlaon Rule. For more informaon, see Working with
Correlaon Rules.
STEP 9 | Aer running your query, review the Query Results.

Alternate between the following display opons to invesgate your query results:
• Table ( )—Displays results in rows and columns according to the enty fields.
From the menu, you can change the table layout. You can also change the raw log format
(displayed in the _Raw_Log field) to one of the following log formats:
• RAW—Raw format of the enty in the database.
• JSON—Condensed JSON format with key value disncons. Null values are not
displayed.
• TREE—Dynamic view of the JSON hierarchy with the opon to collapse and expand the
different hierarchies.
• Graph ( )—Use the Chart Editor to visualize the query results.
• Advanced ( )—Displays results in a table format aggregang the enty fields into one
column. Similar to the table display, you can change the layout and 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.
You can also perform the following addional acons on the results displayed.
• Export to File ( )—Exports the results to a TSV (Tab-separated values) file.
• Refresh ( )—Refreshes the query results.
• Free text search ( )—Searches the query results for text that you specify in the free text
search. Click the Free text search icon to reveal the text Type your search here.
• Filter ( )—Enables you to filter a parcular field in the interface that is displayed to specify
your filter criteria.
We recommend for Integer, Boolean, and mestamp, such as _Time, fields that you
use the Filter as opposed to the Free text search to retrieve the most accurate query
results.
For Table and Advanced displays, Cortex XDR provides a Fields menu on the le side of the
query results that you use to filter the results. To quickly set a filter, Cortex XDR displays the
top 10 results from which you can choose to build your filter. From within the Fields menu,
click on any field (excluding JSON and array fields) to see a histogram of all the values found in
the result set for that field. This histogram includes a count of the total number of mes 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, and 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.
You can also manage your queries, which includes viewing query results, from the Query
Center.
STEP 10 | (Oponal) Save the query to your personal query library.
STEP 11 | (Oponal) Connue invesgaon in the Causality View or Timeline View.

Right-click the event and select the desired view. This opon is available for the following
types of events: process (except for those with an event sub type of terminaon), network, file,
registry, injecon, load image, system calls, event logs for Windows, and system authencaon
logs for Linux. For network stories, you can pivot to the Causality View only.
STEP 12 | (Oponal) Add a file path to your exing Malware Profile allowed list.
Right-click a <path> fields, for example, target_process_path, file_path, or os_parent_path, and
select Add <path type> to malware profile allow list.
STEP 13 | (Oponal) Visualize your query results.
Translate to XQL
To help you easily convert your exisng Splunk queries to the Cortex XDR Query Language
(XQL) syntax, Cortex XDR includes in XQL Search a new toggle called Translate to XQL. When
building your XQL query and this opon 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 opon is disabled by default, so only the XQL query field is displayed.
This feature is sll 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 translaons to XQL.
The following table details the supported funcons in Splunk that can be converted to XQL in
Cortex XDR with an example of a Splunk query and the resulng XQL query. In each of these
examples, the xdr_data dataset is used.
Splunk Funcon/Stage Splunk Query Example Resulng XQL Query Example
avg index=xdr_data dataset in

| stats (xdr_data)
avg(dst_association_strength)
| comp
avg(dst_association_strength)
bin index = xdr_data | dataset in

bin _time span=5m (xdr_data)| bin
_time span=5m
coalesce index= xdr_data dataset in

| eval (xdr_data)
product_or_vendor_not_null=coalesce(_product,
| alter
_vendor ) product_or_vendor_not_null
=

coalesce(_product,
_vendor)
count index=xdr_data dataset in

| stats (xdr_data)
count(_product) BY | comp
_time count(_product) by
_time
ctime index=xdr_data dataset in

| convert (xdr_data)
ctime(field) as | alter field =
field format_timestamp("%m/
%d/%Y %H:%M:%S",
to_timestamp(field))
earliest index = xdr_data dataset in

earliest=24d (xdr_data)
| filter _time >=
to_timestamp(add(to_epoch(curr
eval index=xdr_data | dataset in

eval field = "test" (xdr_data)
| alter field =
"test"
fillnull index=xdr_data | dataset in

fillnull value (xdr_data)
= "missing ipv6" | replacenull
agent_ip_addresses_v6 agent_ip_addresses_v6
= "missing ipv6"
floor index=xdr_data | dataset in

eval floor_test = (xdr_data)
floor(1.9) | alter floor_test =
floor(1.9)
inputlookup index=xdr_data dataset in

| inputlookup (xdr_data)
append=true | union
my_lookup.csv (dataset=my_lookup

| limit 1000000000)
iplocation index = xdr_data dataset in

| iplocation (xdr_data)
agent_ip_addresses | iploc
agent_ip_addresses
loc_continent
AS Continent,
loc_country AS
Country, loc_region
AS Region, loc_city
AS City, loc_latlon
AS lon
isnotnull index=xdr_data dataset in

| eval x = (xdr_data)\n
isnotnull(agent_hostname)
| alter x =
if(agent_hostname !
= null, true, false)
isnull index=xdr_data dataset in

| eval x = (xdr_data)\n
isnull(agent_hostname) | alter x =
if(agent_hostname =
null, true, false)
json_extract index= xdr_data dataset in

| eval (xdr_data)
London=json_extract(dfe_labels,"dfe_labels{0}")
| alter London
= dfe_labels ->
dfe_labels[0]{}
join join agent_hostname join type=left

[index = xdr_data] conflict_strategy=right
(dataset in
(xdr_data))
as inner
agent_hostname =
inner.agent_hostname
latest index = xdr_data dataset in

latest=-24d (xdr_data)

|filter _time <=
to_timestamp(add(to_epoch(date
len index = xdr_data | dataset in

where uri != null (xdr_data)
| eval length = | filter
len(agent_ip_address) agent_ip_addresses !
= null
| alter
agent_ip_address_length
=
len(agent_ip_addresses)
ltrim(<str>,<trim_chars>)index=xdr_data dataset in
| eval (xdr_data)
trimed_agent=ltrim("agent_hostname",
| alter
"agent_") trimed_agent =
ltrim("agent_hostname",
"agent_")
lower index = xdr_data dataset in

| eval field = (xdr_data) |
lower("TEST") alter field =
lowercase("TEST")
max index =xdr_data dataset in

| stats (xdr_data)
max(action_file_size) | comp
by _product max(action_file_size)
by _product
md5 index=xdr_data | dataset in

eval md5_test = (xdr_data)
md5("test") | alter md5_test =
md5("test")
median index = xdr_data dataset in

| stats (xdr_data)
median(actor_process_file_size)
| comp
by _time median(actor_process_file_size
by _time
min index =xdr_data dataset in

| stats (xdr_data)

min(action_file_size) | comp
by _product min(action_file_size)
by _product
mvcount index = xdr_data | dataset in

where http_data ! (xdr_data)
= null | eval | filter http_data !
http_data_array_length = null
= | alter
mvcount(http_data) http_data_array_length
=
array_length(http_data)
mvdedup index = dataset in

xdr_data | eval (xdr_data)
s=mvdedup(action_app_id_transitions)
| alter s =
arraydistinct(action_app_id_tr
mvexpand index = xdr_data | dataset in

mvexpand dfe_labels (xdr_data)
limit = 100 | arrayexpand
dfe_labels limit
100
mvfilter index = xdr_data dataset in

| eval x = (xdr_data)|
mvfilter(isnull(dfe_labels))
alter x =
arrayfilter(dfe_labels,
if("@element" =
null, true, false)
= true)
mvindex index=xdr_data dataset in

| eval field = (xdr_data)
mvindex(action_app_id_transitions,
| alter field =
0) arrayindex(action_app_id_trans
0)
mvjoin index=xdr_data dataset in

| eval (xdr_data)
n=mvjoin(action_app_id_transitions,
";")

| alter n =
arraystring(action_app_id_tran
";")
pow index=xdr_data | dataset in

eval pow_test = (xdr_data)
pow(2, 3) | alter pow_test =
pow(2, 3)
relative_time(X,Y) • index ="xdr_data" • dataset in

| where _time > (xdr_data)
relative_time(now(),"-7d@d")
| filter _time >
to_timestamp(add(to_epoch(da
• index ="xdr_data"
| where _time > • dataset in
relative_time(now(),"+7d@d")
(xdr_data)|
filter _time >
to_timestamp(add(to_epoch(da
replace index= xdr_data | dataset in

eval description = (xdr_data)
replace(agent_hostname,"\("."NEW")
| alter
description =
replace(agent_hostname,
concat("\(",
"NEW"))
rex index=xdr_data dataset in

action_local_ip! (xdr_data)
="0.0.0.0"| rex |filter
field=action_local_ip (action_local_ip !
"(?<src_ip>\d+\.\d = "0.0.0.0" AND
+\.\d+\.48)"| where action_local_ip !=
src_ip != ""| table null)
action_local_ip | alter src_ip =
src_ip arrayindex(regextract(action_l
"(\d+\.\d+\.\d+
\.48)"), 0)
| filter src_ip !=
""
| fields
action_local_ip,
src_ip
round index=xdr_data | dataset in

eval round_num = (xdr_data)
round(3.5)

| alter round_num =
round(3.5)
rtrim index=xdr_data dataset in

| eval (xdr_data)
trimed_hostname=rtrim("agent_hostname",
| alter
"hostname") trimed_hostname =
rtrim("agent_hostname",
"hostname")
search index = dataset in

xdr_data | eval (xdr_data)
ip="192.0.2.56" | alter ip =
| search "192.0.2.56"
ip="192.0.2.0/24" | filter
incidr(ip,"192.0.2.0/24")
= true
sha256 index = xdr_data | dataset in

eval sha256_test = (xdr_data)
sha256("test") | alter sha256_test
= sha256("test")
sort (ascending index = dataset in

order) xdr_data | sort (xdr_data)
action_file_size | sort asc
action_file_size |
limit 10000
sort (descending index = xdr_data dataset in

order) | sort - (xdr_data)
action_file_size | sort desc
action_file_size |
limit 10000
spath index = xdr_data dataset in

| spath (xdr_data)
output=myfield | alter myfield =
input=action_network_http
json_extract(action_network_ht
path=headers.User- Agent")
Agent
split index = xdr_data dataset in

| where mac ! (xdr_data)\n
= null | eval | filter mac != null
\n

split_mac_address = | alter
split(mac, ":") split_mac_address =
split(mac, ":")
stats index=xdr_data dataset in

| stats (xdr_data)
count(event_type) | comp
by _time count(event_type)
by _time
stats dc index = xdr_data | dataset in

stats dc(_product) (xdr_data)
BY _time | comp
count_distinct(_product)
by _time
strcat index=xdr_data | dataset in

strcat story_id "/" (xdr_data)
http_req_before_method | alter
comboIP comboIP=concat(if(story_id!
=null,story_id,""),"/",if(http_
=null,http_req_before_method,""
sum index=xdr_data dataset in

| where (xdr_data)
action_file_size ! | filter
= null | stats action_file_size !=
sum(action_file_size) null
by _time | comp
sum(action_file_size)
by _time
table index = xdr_data dataset in

| table _time, (xdr_data)
agent_hostname, | fields _time,
agent_ip_addresses, agent_hostname,
_product agent_ip_addresses,
_product
tonumber index=xdr_data | dataset in

eval tonumber_test (xdr_data)
= tonumber("90210")

| alter
tonumber_test =
to_number("90210")
upper index=xdr_data dataset in

| eval field = (xdr_data)
upper("test") | alter field =
uppercase("test")
var index=xdr_data dataset in

| stats var (xdr_data)
(event_type) by | comp
_time var(event_type) by
_time
To translate a Splunk query to the XQL syntax.

STEP 1 | Select Incident Response > Invesgaon > Query Builder > XQL Search.
STEP 2 | Toggle to Translate to XQL, where both a SPL query field and XQL query field are displayed.
STEP 3 | Add your Splunk query to the SPL query field.
STEP 4 | Click the arrow ( ).

The XQL query field displays the equivalent Splunk query using the XQL syntax.
You can then decide what to do with this query based on the instrucons explained in Create
an XQL Query.
Manage Your Personal Query Library

Cortex XDR provides as part of the Query Library a personal query library for saving and
managing your own queries. When creang a query in XQL Search or managing your queries from
the Query Center, you can save queries to your personal library. You can also decide whether the
query is shared with others (on the same tenant) in their Query Library or make it unshared and
only visible by you. In addion, you can 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 idenfy 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, descripon, creator, query text, and labels. In
addion, adding a label to your query enables you to search for these queries using these labels in
the Query Library.
To add a query to your personal query library.

STEP 1 | Save a query to your personal query library.
You can do this in two ways.
• From XQL Search
1. Select Incident Response > Invesgaon > Query Builder > XQL Search.
2. In the XQL query field, define the parameters of your query. For more informaon, see
Create an XQL Query.
3. Select Save as > Query to Library.
• From the Query Center
1. Select Incident Response > Invesgaon > 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.
STEP 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 Descripon—(Oponal) Specify a descripve name for your query.
• Labels—(Oponal) 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.

A noficaon appears confirming that the query was saved successfully to the library, and
closes on its own aer a few seconds.
Your 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.
STEP 4 | Other available opons.

As needed, you can return to your queries in the Query Library to manage your queries. Here
are the acons available to you.
• Edit the name, descripon, labels, and parameters of your query by selecng the query from
the Query Library, hovering over the line in the query editor that you want to edit, and
selecng 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, descripon,
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 enre list, Select all (default).
• Save as new—Duplicate the query and save it as a new query. This acon is available from
the query menu by selecng .
• 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 acon is only
available from the query menu by selecng 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 acon is only available from the query menu by
selecng when your query is shared with others. You can only Unshare a query that you
created. If another user created the query, this opon is disabled in the query menu.
• Delete the query. You can only delete queries that you created. If another user created the
query, this opon is disabled in the query menu when selecng .
Visualize Query Results

To help you beer understand your XQL query results and share your insights with others, Cortex
XDR enables you to generate visualizaons of your query data directly from the XQL Search page.
STEP 1 | In the Cortex XDR console, navigate to .
STEP 2 | Run an XQL query.

For example, enter dataset = xdr_data | fields action_total_upload, _time
| limit 10. The query returns the action_total_upload, a number field, and _time, a
string field, for up to 10 results.
STEP 3 | In the Query Results secon, to visualize the results either:

1. Navigate to Query Results > Chart Editor ( ) to manually build and view the graph
using the selected visualizaon parameters.
• Main
• Graph Type—Type of visualizaon; Area, Bubble, Column, Funnel, Gauge, Line,
Map, Pie, Scaer, Single Value, or Word Cloud.
• Subtype and Layout—Depending on the selected type of graph, choose from the
available display opons.
• 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 a field with a numeric value.
• Depending on the selected type of graph, customize the Color, Font, and Legend.
2. Enter the visualizaon parameters in the XQL query secon.
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 me that you run it. To
define the parameters, either:
• Manually enter the parameters, for example, view graph type = column
subtype = grouped header = “Test 1” xaxis = _time yaxis =
_product,action_total_upload.
• Select ADD TO QUERY to insert your chart preferences into the query itself.
STEP 4 | (Oponal) Create a custom widget.

To easily track your query results, you can create custom widgets based on the query results
in the Widget Library/ The custom widgets you create can be used in your custom dashboards
and reports.
Select Save to Widget Library to pivot to the Widget Library and generate a custom widget
based on the query results.
Create a File Query

From the Query Builder you can invesgate connecons between file acvity and endpoints. The
Query Builder searches your logs and endpoint data for the file acvity that you specify. To search
for files on endpoints instead of file-related acvity, use the XQL Search.
Some examples of file queries you can run include:
• Files modified on specific endpoints.
• Files related to process acvity that exist on specific endpoints.
To build a file query:
STEP 1 | From Cortex XDRXSIAM, select Incident Response > Invesgaon > Query Builder.
STEP 2 | Select FILE.
STEP 3 | Enter the search criteria for the file events query.
• File acvity—Select the type or types of file acvity you want to search: All, Create, Read,
Rename, Delete, or Write.
• File aributes—Define any addional process aributes for which you want to search.
Use a pipe (|) to separate mulple values (for example notepad.exe|chrome.exe). By
default, Cortex XDR will return the events that match the aribute you specify. To exclude
an aribute value, toggle the = opon to =!. Aributes 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.
• 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 addional excepon (match this value except), click the + to the right of the
value and specify the excepon value.
STEP 4 | (Oponal) Limit the scope to a specific acng process:
Select and specify one or more of the following aributes for the acng (parent)
process.
Use a pipe (|) to separate mulple 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 iniate 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—Enty that signed the cerficate 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 execuon chain that the Cortex
XDR agent idenfied as being responsible for iniang the process tree. The OS actor is
the parent process that creates an OS process on behalf of a different iniator. By default,
this opon is enabled to apply the same search criteria to iniang processes. To configure
different aributes for the parent or iniang process, clear this opon.
STEP 5 | (Oponal) Limit the scope to an endpoint or endpoint aributes:

Select and specify one or more of the following aributes:
• 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
STEP 6 | Specify the me period for which you want to search for events.
Opons are: Last 24H (hours), Last 7D (days), Last 1M (month), or select a Custom me period.

Select the calendar icon to schedule a query to run on or before a specific date, Run in
background to run the query as resources are available, or Run to run the query immediately
and view the results in the Query Center.
STEP 8 | When you are ready, View the Results of a Query.
Create a Process Query

From the Query Builder you can invesgate connecons between processes, child processes, and
endpoints.
For example, you can create a process query to search for processes executed on a specific
endpoint.
To build a process query:
STEP 1 | From Cortex XDR, select Incident Response > Invesgaon > Query Builder.
STEP 2 | Select PROCESS.
STEP 3 | Enter the search criteria for the process query.

• Process acon—Select the type of process acon you want to search: On process Execuon
or Injecon into another process.
• Process aributes—Define any addional process aributes for which you want to search.
Use a pipe (|) to separate mulple values. Use an asterisk (*) to match any string of
characters.
By default, Cortex XDR will return results that match the aribute you specify. To exclude
an aribute value, toggle the operator from = to !=. Aributes 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 iniate the process including any arguments, up to 128
characters.
• MD5—MD5 hash value of 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.
• 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.
process.
128 characters.

INSTALLATION TYPE.

Create a Network Query

From the Query Builder you can invesgate connecons between network acvity, acng
processes, and endpoints.
Some examples of network queries you can run include:
• Network connecons to or from a specific IP address and port number.
• Processes that created network connecons.
• Network connecons between specific endpoints.
To build a network query:
STEP 1 | From Cortex XDR, select INVESTIGATION > Query Builder.
STEP 2 | Select NETWORK.
STEP 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 aributes—Define any addional process aributes for which you want to search.
Use a pipe (|) to separate mulple values (for example 80|8080). By default, Cortex XDR
will return the events that match the aribute you specify. To exclude an aribute value,
toggle the = opon to =!. Opons are:
• REMOTE COUNTRY—Country from which the remote IP address originated.
• REMOTE IP—Remote IP address related to the communicaon.
• REMOTE PORT—Remote port used to make the connecon.
• LOCAL IP—Local IP address related to the communicaon. Matches can return addional
data if a machine has more than one NIC.
• LOCAL PORT—Local port used to make the connecon.
• PROTOCOL—Network transport protocol over which the traffic was sent.
process.
128 characters.

INSTALLATION TYPE.

Create an Image Load Query

From the Query Builder you can invesgate connecons between image load acvity, acng
processes, and endpoints.
Some examples of image load queries you can run include:
• Module load into process events by module path or hash.
To build an image load query:
STEP 2 | Select IMAGE LOAD.
STEP 3 | Enter the search criteria for the image load acvity query.
• Type of image acvity: All, Image Load, or Change Page Protecon.
• Idenfying informaon about the image module: Full Module Path, Module MD5, or
Module SHA256.
By default, Cortex XDR will return the acvity that matches all the criteria you specify. To
exclude a value, toggle the = opon to =!.
process.
128 characters.

INSTALLATION TYPE.

Create a Registry Query

From the Query Builder you can invesgate connecons between registry acvity, processes, and
endpoints.
Some examples of registry queries you can run include:
• Modified registry keys on specific endpoints.
• Registry keys related to process acvity that exist on specific endpoints.
To build a registry query:
STEP 2 | Select REGISTRY.
STEP 3 | Enter the search criteria for the registry events query.
• Registry acon—Select the type or types of registry acons you want to search: Key Create,
Key Delete, Key Rename, Value Set, or Value Delete.
• Registry aributes—Define any addional registry aributes for which you want to search.
By default, Cortex XDR will return the events that match the aribute you specify. To
exclude an aribute value, toggle the = opon to =!. Aributes are:
• KEY NAME—Registry key name.
• DATA—Registry key data value.
• REGISTRY FULL KEY—Full registry key path.
• KEY PREVIOUS NAME—Name of the registry key before modificaon.
• VALUE NAME—Registry value name.
process.
128 characters.

INSTALLATION TYPE.

Create an Event Log Query

From the Query Builder you can search Windows and Linux event log aributes and invesgate
event logs across endpoints with an Cortex XDR agent installed.
Some examples of event log queries you can run include:
• Crical level messages on specific endpoints.
• Message descripons with specific keywords on specific endpoints.
To build a file query:
STEP 2 | Select EVENT LOG.
STEP 3 | Enter the search criteria for your Windows or Linux event log query.
Define any event aributes for which you want to search. By default, Cortex XDR will return
the events that match the aribute you specify. To exclude an aribute value, toggle the =
opon to =!. Aributes 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 descripon of the event.
To specify an addional excepon (match this value except), click the + to the right of the value
and specify the excepon value.

INSTALLATION TYPE.


Create a Network Connecons Query

From the Query Builder you can invesgate network events stched across endpoints and the
Palo Alto Networks next-generaon firewalls logs.
Some examples of network queries you can run include:
• Source and desnaon of a process.
• Network connecons that included a specific App ID
• Processes that created network connecons.
• Network connecons between specific endpoints.
To build a network query:
STEP 2 | Select NETWORK CONNECTIONS.
STEP 3 | Enter the search criteria for the network events query.
• Network aributes—Define any addional process aributes for which you want to search.
Use a pipe (|) to separate mulple values (for example 80|8080). By default, Cortex XDR
will return the events that match the aribute you specify. To exclude an aribute value,
toggle the = opon to =!. Opons 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
STEP 4 | (Oponal) To limit the scope to a specific source, click the + to the right of the value and
specify the excepon value.
Specify one or more aributes for the source.
• HOST NAME—Name of the source.
• HOST IP—IP address of the source.
• HOST OS—Operang system of the source.
• PROCESS NAME—Name of the process.
• PROCESS PATH—Path to the process.
• CMD—Command-line used to iniate the process including any arguments, up to 128
characters.
• MD5—MD5 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.
• 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 execuon chain that app
idenfied as being responsible for iniang the process tree. Select this opon if you want
to apply the same search criteria to the causality actor. If you clear this opon, you can then
configure different aributes for the causality actor.
STEP 5 | (Oponal) Limit the scope to a desnaon.

Specify one or more of the following aributes:
• REMOTE IP—IP address of the desnaon.
• COUNTRY—Country of the desnaon.
• Desnaon TARGET HOST,NAME, PORT, HOST NAME, PROCESS USER NAME, HOST IP,
CMD, HOST OS, MD5, PROCESS PATH, USER ID, SHA256, SIGNATURE, or PID
Create an Authencaon Query

From the Query Builder you can invesgate authencaon acvity across all ingested
authencaon logs and data.
Some examples of authencaon queries you can run include:

• Authencaon logs by severity
• Authencaon logs by event message
• Authencaon logs for a specific source IP address
To build an authencaon query:
STEP 2 | Select AUTHENTICATION.
STEP 3 | Enter the search criteria for the authencaon query.

By default, Cortex XDR will return the acvity that matches all the criteria you specify. To
exclude a value, toggle the = opon to =!.

Query Across All Enes

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
authencaon logs for Linux.
Some examples of queries you can run across all enes include:
• All acvies on a host
• All acvies iniated by a process on a host.
To build a query:
STEP 2 | Select ALL ACTIONS.
process.
128 characters.

INSTALLATION TYPE.

Query Center
From the Query Center you can manage and view the results of all simple and complex queries
created from the Query Builder. The Query Center displays informaon about the query including
the query parameters and allows you to adjust and rerun queries as needed.
The following table describes the fields that are available for each query in alphabecal order.
Certain fields are exposed and hidden by default. An asterisks (*) is beside every field that
is exposed by default.
Field Descripon
BQL Displays whether the query was created by the

nave search.
Nave search has been deprecated, this field
allows you to view data for queries performed
prior.
COMPUTE UNIT USAGE Displays how many query units were used to
execute the API query and Cold Storage query.
CREATED BY * User who created or scheduled the query.
EXECUTION ID Unique idenfier of XQL queries in the tenant.

The idenfier id generated for queries executed
in the Cortex XDR app and XQL query API.
NUM OF RESULTS* Number of results returned by the query.
Field Descripon
PUBLIC API Displayed whether the source execung the

query was XQL query API.
QUERY DESCRIPTION* The query parameters used to run the query.
QUERY ID Unique idenfier of the query.
QUERY NAME* For saved queries, the Query Name idenfies

the query specified by the administrator. For
scheduled queries, the Query Name idenfies
the auto-generated name of the parent query.
Scheduled queries also display an icon to the
le of the name to indicate that the query is
reoccurring.
QUERY STATUS* Status of the query:

• Queued—The query is queued and will run
when there is an available slot.
• Running
• Failed
• Parally completed—The query was stopped
aer exceeding the maximum number of
permied results; 100,000 for queries
executed in Cortex XDR app and 1,000,000
for XQL Query API. To reduce the number
of results returned, you can adjust the query
sengs and rerun.
• Stopped—The query was stopped by an
administrator.
• Completed
• Deleted—The query was pruned.
RESULTS SAVED* Yes or No.
SIMULATED COMPUTE UNITS Displays how many query units were used to
execute the Hot Storage query.
TENANT List of tenants on which an XQL query were

executed.
TIMESTAMP* Date and me the query was created.
Field Descripon
XQL Displays whether the query was created by the

an XQL search.
Manage Your Queries

From the Query Center, you can view all manual and scheduled queries. The Query Center also
provides management funcons that allow you to modify, rerun, schedule, and remove queries.
You can also refresh the page to view updated status for queries, filter available queries based on
fields in the query table, and manage the fields presented in the Query Center.
• View the Results of a Query

• Rename a Query
• Modify a Query
• Add a Query to Your Personal Query Library
• Rerun or Schedule a Query to Run
• Manage Scheduled Queries
View the Results of a Query
Aer you run a query, you can view the events that match your search criteria. To view the results:
STEP 1 | Locate the query for which you want to view the results.
If necessary, use the to reduce the number of queries Cortex XDR displays.
STEP 2 | Right-click anywhere in the query row, select Show results, and choose whether to open the
query in the same tab or a new tab.
STEP 3 | (Oponal) If you want to refine your results, you can Modify a query from the query results.
STEP 4 | (Oponal) If desired, Export to file to export the results to a tab-separated values (TSV) file.
STEP 5 | (Oponal) Perform addional invesgaon on the alerts.

From the right-click pivot menu:
• Analyze the alert and open the Causality View.
• Invesgate in Timeline.
• View event log message to view the event details.
Modify a Query
Aer you run a query you might find you need to change your search parameters such as to
narrow the search results or correct a search parameter. There are two ways you can modify a
query: You can edit it in the Query Center, or you can edit it from the results page. Both methods
populate the criteria you specified in the original query in a new query which you can modify and
save.
Create a query based on an exisng query.

1. Select Invesgaon > Query Center.
2. Right click anywhere in the query and then select Save as a new query.
3. If desired, enter a descripve name to idenfy the query.
4. Then modify the search parameters as desired.
5. Choose when to run the query.
Select the calendar icon to schedule a query to run on or before a specific date, Run
in background to run the query as resources are available, or Run to run the query
immediately and view the results in the Query Center.
Modify an exisng query from the Query Center.

2. Right click anywhere in the query and then Edit a query.
3. Modify the search parameters as desired.
in background to run the query as resources are available, or Run to run the query
immediately and view the results in the Query Center.
Modify a query from the query results.

1. View the Results of a Query.
2. At the top of the query, click the pencil icon to the right of the query parameters.
Cortex XDR opens the query sengs page.
3. Modify the search parameters as desired.
in background to run the query and review the result at a later me, or Run to run the
query immediately and view the results in the Query Center.
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 will create a new query in the Query Center. When the
query completes, Cortex XDR displays a noficaon in the noficaon bar.
Rerun a query immediately.

2. Right click anywhere in the query and then select Rerun Query.
Cortex XDR iniates the query immediately.
Schedule a query to run:

1. Select INVESTIGATION > Query Center.
2. Right click anywhere in the query and then select Schedule.
3. Choose the desired schedule opon and the date and me the query should run:
• Run one me query on a specific date

• Run query by date and me—Schedule a reoccurring query at a frequency of your
choice.
4. Click OK to schedule the query.
Cortex XDR creates a new query and schedules it to run on or by the selected date and
me.
5. View the status of the scheduled query on the Scheduled Queries page.
At any me, you can view or make changes to the query on the Scheduled Queries page.
For example, you can edit the frequency, view when the query will next run, or disable
the query.
Rename a Query
If needed, you can rename a query at any me. If you later rerun the query, the new query will run
using the new name. You can also edit the name of a query when you Modify a Query.
STEP 1 | Select Invesgaon > Query Center.
STEP 2 | Right click anywhere in the query and then select Rename.
STEP 3 | Enter the new query name and click OK.
Quick Launcher
The Quick Launcher provides a quick, in-context shortcut that you can use to search for
informaon, perform common invesgaon tasks, or iniate response acons from any place in
the Cortex XDR app. The tasks that you can perform with the Quick Launcher include:
• Search for host, username, IP address, domain, filename, or filepath, mestamp to easily launch
the arfact 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 in the Asset Inventory table for a specific Asset Name or IP address. In addion, 2
acons are available when searching for Asset Inventory data.
• Change search to <host name of asset> to display addional acons related to that host.
This opon 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
• Iniate a malware scan on an endpoint
You can bring up the Quick Launcher either using the default keyboard shortcut— Ctrl-Shift
+X on Windows or CMD+Shift+X on macOS, by using the Quick Launcher icon located in the
top navigaon bar, or from the applicaon menus. To change the default keyboard shortcut, select
Sengs > Configuraons > General > Server Sengs > Keyboard Shortcuts. The shortcut value
must be a keyboard leer, A through Z, and cannot be the same as the Arfact and Asset Views
defined shortcut.
You can also prepopulate searches in Quick Launcher by selecng text in the app or selecng a
node in the Causality or Timeline Views.
By default, Cortex XDR opens the Quick Launcher in the center of the page. To change the default
posion, drag the Quick Launcher to another preferred locaon. The next me you open the
Quick Launcher, it opens in the previous locaon. To close the Quick Launcher, click Esc or click
out of the Quick Launcher dialog.
Scheduled Queries
From the Scheduled Queries page, you can easily view all scheduled and reoccurring queries
created from the Query Builder. The Scheduled Queries page displays informaon about the
query including the query parameters and allows you to adjust or modify the schedule as needed.
To edit a query schedule, right click the query and select the desired acon.
The following table describes the fields that are available for each query in alphabecal order.
Field Descripon
CREATED BY User who created or scheduled the query.
NEXT EXECUTION Next execuon me if the query is scheduled to run at

a specific frequency. If the query was only scheduled to
run at a specific me and date, this field will show None.
QUERY DESCRIPTION The query parameters used to run the query.
QUERY ID Unique idenfier of the query.
QUERY NAME For saved queries, the Query Name idenfies the query
specified by the administrator. For scheduled queries,
the Query Name idenfies the auto-generated name
of the parent query. Scheduled queries also display an
icon to the le of the name to indicate that the query is
reoccurring.
SCHEDULE TIME Frequency or me at which the query was scheduled to

run.
TIMESTAMP Date and me the query was created.
Manage Scheduled Queries

From the Scheduled Queries page, you can perform addional acons to manage your scheduled
and reoccurring queries.
• View Completed Queries

• Edit the Query Frequency
• Disable or Remove a Query
• Rename a Scheduled Query
View Completed Queries
To view completed queries:
STEP 1 | Select INVESTIGATION > Scheduled Queries.
STEP 2 | Locate the scheduled query for which you want to view previous execuons.
If necessary, use the Filter to reduce the number of queries Cortex XDR displays.
STEP 3 | Right-click anywhere in the query row, select Show executed queries, and choose whether to
open the query in the same tab or a new tab.
Cortex XDR filters the queries on the Query Center and displays the results in a new window.
Edit the Query Frequency

STEP 2 | Locate the scheduled query that you want to edit.

STEP 3 | Right click anywhere in the query row and then select Edit.
STEP 4 | Adjust the schedule sengs as needed, and then click OK.
Disable or Remove a Query

If you no longer need a query you can temporarily disable or permanently remove it.
STEP 2 | Locate the scheduled query that you want to change.

STEP 3 | Right click anywhere in the query row and then select Remove to permanently remove the
scheduled query, or Disable to temporarily stop the query from running at the scheduled
me. If you disable a query you can later return to the Scheduled Queries page and Enable it.
Rename a Scheduled Query

STEP 2 | Locate the scheduled query that you want to change.

STEP 3 | Right click anywhere in the query row and then select Rename.
STEP 4 | Edit the query name as desired, and then click OK.
Research a Known Threat

This topic describes what steps you can take to invesgate a lead. A lead can be:
• An alert from a non-Palo Alto Networks system with informaon relevant to endpoints or
firewalls.
• Informaon from online arcles or other external threat intelligence that provides well-defined
characteriscs about the threat.
• Users or hosts that have been reported as acng abnormally.
STEP 1 | Use the threat intelligence you have to build a query using Cortex XDR Query Builder.
For example, if external threat intelligence indicates a confirmed threat that involves specific
files or behaviors, search for those characteriscs.
STEP 2 | View the Results of a Queryand refine as needed to filter out noise.
See Modify a Query.
STEP 3 | Select an event of interest, and open the Causality View.

Review the chain of execuon and data, navigate through the processes on the tree, and
analyze the informaon.
STEP 4 | Open the Timeline View to view the sequence of events over me.
STEP 5 | Inspect the informaon again, and idenfy any characteriscs you can use to Create a BIOC
Rule or Create a Correlaon Rule.
If you can create a BIOC or Correlaon Rule, test and tune it as needed.
Invesgate Incidents
The Incidents page displays all incidents in the Cortex XDR management console to help you
priorize, track, triage, invesgate and take remedial acon.
To begin invesgang your incidents:
• Learn about Cortex XDR Incidents
• Set up External Integraons
• Manage your Incident Starring
• Create an Incident Scoring Rule
• Triage your Incidents
• Manage your Incidents
Incidents
An aack can affect several hosts or users and raises different alert types stemming from a single
event. All arfacts, assets, and alerts from a threat event are gathered into an Incident.
The logic behind which alert the Cortex XDR app assigns to an incident is based on a set of rules
which take into account different aributes. Examples of alert aributes include alert source, type,
and me period. The app extracts a set of arfacts related to the threat event, listed in each alert,
and compares it with the arfacts appearing in exisng alerts in the system. Alerts on the same
causality chain are grouped with the same incident if an open incident already exists. Otherwise,
the new incoming alert will create a new incident.
To keep incidents fresh and relevant, Cortex XDR provides thresholds aer which an incident
stops adding alerts:
• 30 days aer the incident was created
• 14 days since the last alert in the incident was detected (excludes backward scan alerts)
Aer the incident reaches either threshold, it stops accepng alerts and Cortex XDR groups
subsequent related alerts in a new incident. You can track the grouping threshold status in the
Alerts Grouping Status field in the Incidents table:
• Enabled—The incident is open to accepng new related alerts.
• Disabled—Grouping threshold is reached and the incident is closed to further alerts or if the
incident reached the 1,000 alert limit. To view the exact reason for a Disabled status, hover
over the status field.
You can select to view the Incidents page in a table format or split pane mode. Use to toggle
between the views. By default, Cortex XDR displays the split pane mode. Any changes you make
to the incident fields, such as descripon, resoluon status, filters, and sort selecons persist
when you toggle between the modes.
The split pane mode displays a side-by-side view of the your incidents list and the corresponding
incident details.
The table view displays only the incident fields in a table format. Right-click an incident to view
the incident details, and invesgate the related assets, arfacts, and alerts. For more informaon
see Invesgate Incidents.
the Incidents table and lists the fields in alphabecal order.
Incidents created prior to Cortex XDR version 2.9 are updated as follows:
• MITRE Aack Taccs, MITRE Aack Techniques, and Alert Categories fields will remain
empty.
• WildFire Hits field will begin with an empty value, however when a new alert is added
to the incident the filed is updated.
• Crical, High Severity, Medium Severity, Low Severity, Alert Grouping Status fields are
updated with the corresponding value.
• If an incident is merged or moved with other incidents, Cortex XDR will recalculate and
update the fields.
Field Descripon
Check box to select one or more incidents on

which to perform the following acons.
• Assign incidents to an analyst in bulk
• Change the status of mulple incidents
• Change the severity of mulple incidents
Alert Categories Type of alert categories triggered by the

incident alerts.
Alert Source Source of the alert, such as XDR Analycs

BIOC, XDR BIOC, and Correlaon.
Alerts Grouping Status Displays whether Alert Grouping is currently

enabled.
Alerts Breakdown The total number of alerts and number of alerts

by severity.
Assignee Email Email address associated with the assigned

incident owner.
Assigned To The user to which the incident is assigned. The

assignee tracks which analyst is responsible for
invesgang the threat. Incidents that have not
been assigned have a status of Unassigned.
Creaon Time Date and me when the incident was created.
Field Descripon
High Severity Alerts Number of high severity alerts that are part of
the incident.
Hosts Displays the host names affected by the

incident.
Incident Descripon The descripon is generated from the alert

name from the first alert added to the incident,
the host and user affected, or number of users
and hosts affected.
Incident ID A unique number to idenfy the incident.
Incident Name A user-defined incident name.
Incident Sources List of sources that raised high and medium

severity alerts in the incident.
Last Updated The last me a user took an acon or an alert

was added to the incident.
Low Severity Alerts Number of low severity alerts that are part of
the incident.
Medium Severity Number of medium severity alerts that are part

of the incident.
MITRE ATT&CK Tacc Displays the types of MITRE ATT&CK taccs

triggered by the alerts that are part of the
incident.
MITRE ATT&CK Technique Displays the type of MITRE ATT&CK technique

and sub-technique triggered by the alerts that
are part of the incident.
Resolve Comment The user-added comment when the user

changes the incident status to a Resolved status.
Resolved Timestamp Displays the date and me when the incident
was set with a resolved status.
Score Displays the score defined by the incident

scoring rule.
Severity The highest alert in the incident or the user-

defined severity.
Starred The incident includes alerts that match your

incident priorizaon policy. Incidents that have
Field Descripon
alert matches include a star by the incident
name in the Incident details view and a value of
Yes in this field.
Status Incidents have the status set to New when

they are generated. To begin invesgang an
incident, set the status to Under Invesgaon.
The Resolved status is subdivided into
resoluon reasons:
• Resolved - Threat Handled
• Resolved - Known Issue
• Resolved - Duplicate Incident
• Resolved - False Posive
• Resolved - Auto Resolve - Auto-resolved by
Cortex XDR when all of the alerts contained
in an incident have been excluded.
Total Alerts The total number of alerts in the incident.
Users Users affected by the alerts in the incident. If

more than one user is affected, click on + <n>
more to see the list of all users in the incident.
WildFire Hits Number of the Malware, Phishing, and

Greyware arfacts that are part of the incident.
External Integraons
To aid you with threat invesgaon, Cortex XDR displays the WildFire-issued verdict for each
Key Arfacn an incident. To provide addional verificaon sources, you can integrate external
threat intelligenceservice with Cortex XDR which can then be displayed for each Key Arfacn an
incident. Cortex XDR supports the following integraons.
Integraon Descripon
Threat Intelligence
WildFire® Cortex XDR automacally includes WildFire threat

intelligence in incident and alert invesgaon.
WildFire detects known and unknown threats, such
as malware. The WildFire verdict contains detailed
insights into the behavior of idenfied threats.
The WildFire verdict displays next to relevant Key
Arfacts in the incidents details page. See Review
WildFire® Analysis Details for more informaon.
AutoFocus™ AutoFocus groups condions and indicators related

to a threat with a tag. Tags can be user-defined or
come from threat-research team publicaons and
are divided into classes, such as exploit, malware
family, and malicious behavior. See the AutoFocus
Administrator’s Guide for more informaon on
AutoFocus tags.
To view AutoFocus tags in Cortex XDR incidents,
you must obtain the license key for the service and
add it to the Cortex XDR Configuraon. When you
add the service, the relevant tags display in the
incident details page under Key Arfacts.
VirusTotal VirusTotal provides aggregated results from over 70

anvirus scanners, domain services included in the
block list, and user contribuons. The VirusTotal
score is represented as a fracon, where, for
example, a score of 34/52 means out of 52 queried
services, 34 services determined the arfact 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
Configuraon. When you add the service, the
relevant VirusTotal (VT) score displays in the
incident details page under Key Arfacts.
Incident Management
Cortex XSOAR Cortex XSOAR enables automated and coordinated

threat response with the ability to adjust and test
response playbooks. When used with Cortex XDR,
you can manage incidents from the Cortex XSOAR
interface and leverage the Cortex XDR Causality
Analycs Engine and detecon capabilies.
Changes to one app are reflected in the other.
Third-party ckeng systems To manage incidents from the applicaon of your

choice, you can use the Cortex XDR API Reference
to send alerts and alert details to an external
receiver. Aer you generate your API key and set
up the API to query Cortex XDR, external apps
can receive incident updates, request addional
data about incidents, and make changes such as to
set the status and change the severity, or assign
an owner. To get started, see the Cortex XDR API
Reference.
Manage Incident Starring

To help you focus on the incidents that maer most, you can star an incident. Cortex XDR
a idenfies starred incidents with a purple star. You can star incidents in two ways: You can
manually star an incident aer reviewing it, or you can create an incident starring configuraon
that automacally categorizes and stars incidents when a related alert contains the specific
aributes that you decide are important.
Aer you define an incident starring configuraon, Cortex XDR a adds a star indicator to any
incidents that contain alerts that match the configuraon.
You can then sort or filter the Incidents table for incidents containing starred alerts and similarly
filter the Alerts table for starred alerts. In addion, you can also choose whether to display all
incidents or only starred incidents on the Incidents Dashboard.
Star a Specific Incident

To manually star an incident during or aer invesgaon:
STEP 1 | Select Incident Response > Incidents.
STEP 2 | From the Incident List, locate the incident you want to star.
STEP 3 | Select the star icon.
Create a Starring Configuraon

To proacvely star alerts and incidents containing alerts, create a starring configuraon.
STEP 1 | Select Incident Response > Incident Configuraon > Starred Alerts.
STEP 2 | + Add Starring Configuraon
STEP 3 | Enter a Configuraon Name to idenfy your starring configuraon.
STEP 4 | Enter a descripve Comment that idenfies the reason or purpose of the starring
configuraon.
STEP 5 | Use the alert filters to build the match criteria for the policy.
You can also right-click a specific value in the alert to add it as match criteria. The app refreshes
to show you which alerts in the incident would be included.
STEP 6 | Create the policy and confirm the acon.

If you later need to make changes, you can view, modify, or delete the exclusion policy from
the Invesgaon > Incident Management > Starred Alerts page.
Create an Incident Scoring Rule

Cortex XDR uses stching logic to gather and assign alerts to incidents based on a set of rules
which take into account different alert aributes, such SHA256 of files that are involved and IP
addresses. The incidents displayed in the Incidents Table can be priorized according to these alert
aributes.
To enable you to priorize incidents that are significant to the needs of your organizaon, the
Incident Scoring Rules opon allows you to set custom rules that highlight the incidents based on:
• A user-defined score
• Selected Cortex XDR alert aributes and assets
When an alert is triggered, Cortex XDR matches the alert with each of the custom incident rules
you created. If the alert matches one or more of the rules, the alert is given the score defined by
each rule. An incident rule can also contain a sub-rule that allows you to create a rule hierarchy.
Where a sub-rule exists, if the same alert matches one or more of the sub-rules, the alert is also
given the score defined by each sub-rule. By default, a score is applied only to the first alert that
matches the defined rule and sub-rule.
A sub-rule score is only applied to an alert if the top-level rule was a match.
Within each incident, Cortex XDR aggregates the alert scores and assigns the incident a total
score. The incident score is displayed in the Incidents Table as filterable field, Score, allowing you
to priorize the Incident Table according to the incident score. You can also view the score while
invesgang in the Incident View.
To create an incident scoring rule:
STEP 1 | In the Cortex XDR Management Console, navigate to Incident Response > Incident
Configuraon > Scoring Rules.
The Scoring Rules table displays the rules and, if applicable, the sub-rules currently in your
Cortex XDR tenant.
STEP 2 | Select Add Scoring Rule to define the rule criteria.
STEP 3 | In the Create New Scoring Rule dialog, define the following:
1. Rule Name—Enter a unique name for your rule.
2. Score—Set a numeric value that is applied to an alert matching the rule criteria.
3. Base Rule—Select whether to create a top-level rule, Root, or sub-rule, listed Rule Name
(ID:#). By default, rules are defined at root level.
4. Comment—Enter an oponal comment.
5. Mark whether to Apply score only to first alert of incident—By selecng this opon you
choose to apply the score only to the first alert that matches the defined rule. Subsequent
alerts of the same incident will not receive a score from this rule again. By default, a score is
applied only to the first alert that matches the defined rule and sub-rule.
6. Determine which alert aribute you want to use as the rule match criteria. Use the filter at
the top of the table to build your rule criteria.
STEP 4 | Review the rule criteria and Create the incident rule.
You are automacally redirected to the Scoring Rules table.
STEP 5 | In the Scoring Rules table, Save your scoring rule.
STEP 6 | (Oponal) Manage your exisng incident scoring rules.

In the Scoring Rules table view your exisng rules and sub-rules.
• Use the to rearrange a rule. Make sure to Save aer any changes you make.
• Right-click one rule or select more than one to:
• Edit rule—Edit the rule criteria for an exisng rule.
• Delete rule—Remove a rule and the sub-rules from your Cortex XDR tenant.
• Disable / Enable rule—Disables or enables rule. Disabled rules appear in the table but are
grayed out and you cannot perform any acons on them.
• Copy rule—Copy the rule criteria to a clipboard to create a sub-rule. Locate the rule you
want add a sub-rule, right-click and Paste “rule name”.
• Add sub-rule—Add a sub-rule to an exisng rule.
Make sure to Save your changes.
STEP 7 | (Oponal) Invesgate and manage incidents scoring rules from the Incident Table or View.
Triage Incidents
To help you triage and invesgate your incidents, Cortex XDR displays your incidents in a split-
pane view allowing you to easily invesgate the enre scope and cause of an event, view all
relevant assets, suspicious arfacts, and alerts within the incident details.
Navigate to Incident Response > Incidents. The Incident split-pane view is divided into two main
secons:
• Incident List
• Details Pane
The Details Pane supports Advanced View for incidents created aer Cortex XDR 3.0.
Incidents created before Cortex XDR 3.0, are displayed in a Legacy view. To enable
flexibility, you can select to display incidents created aer Cortex XDR 3.0 Cortex using
either the Legacy view or Advanced view.
The Incident List enables you to filter and sort according to the incident fields, such as status,
score, severity, and mestamp. Each incident displays a summary of the incident severity,
assignee, status, creaon me, descripon, and assets. From the Incident List you can also review
addional informaon.
The Details pane displays the informaon of the selected incident in the Incident List. The pane is
made up of the following tabs that allow you to further invesgate and manage each incident.
• Overview—Made up of an Incident Header lisng the incident details, the MITRE taccs
and techniques, summarized meline, and widgets to visualize the number of alerts, type of
sources, hosts, and users associated with the incident. Select the pin icon next to the tab name
to always display a specific tab first when you invesgate incidents.
• Key Assets & Arfacts—Displays the incident asset and arfact informaon of hosts, users, and
key arfacts associated with the incident.
• Alerts & Insights—Displays a table of the alerts and insights associated with the incident.
• Timeline—A chronological representaon of alerts and acons relang to the incident.
• Execuons—Displays the causality chains associated with the incident.
Manage Incidents
The Incident view allows you track incidents, invesgate incident details and take remedial acon.
Navigate to Incident Response > Incidents and locate the incident you want to invesgate.
To begin managing your incidents:
• Review Incident List Details
• Update Incident Details
• Invesgate Incident Overview
• Invesgate Incident Key Assets and Arfacts
• Invesgate Incident Alerts and Insights
• Invesgate Incident Timeline
• Invesgate Incident Execuons
Review Incident List Details

To provide an summary of each incident, Cortex XDR displays the following incident details for
each incident:
View the incident severity, score, and assignee. Select whether to you want to Star the incident.
View the status of the incident and when it was last updated.
Review the Cortex XDR incident ID and incident summary.
Invesgate the incident assets and alert sources:

• Review the host name associated with the incident. If there is more than one host, select
the [+x] to display the addional host names.
• Review the user name associated with the incident. If there is more than one user, select the
[+x] to display the addional user names.
• Hover over the alert source icons to display the alert source type. Select the alert source
icon to display the three most common alerts that were triggered and how many alerts of
each are associated with the incident.
Update Incident Details

The incident header allows you to quickly review and update your incident details.
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.
Add or edit the incident name.

Hover over Add incident name and select the pencil icon to add or edit the incident name.
Edit the incident descripon.

Hover over the incident descripon and select the pencil icon to edit the incident descripon.
Update the incident score.

Select the Incident Score to invesgate how the Rule based score was calculated.
In the Manage incident Score dialog, review the Rule ID, Rule Name, Descripon, Alert
IDs, and the Total Added Score associated with incident. The table displays all rules that
contributed to the incident total score, including rules that have been deleted. Deleted scores
appear with a N/A.
Override the Rule based score by selecng Set score manually and Apply the change.
Assign an incident.
Select the assignee (or Unassigned) and begin typing the assignee’s email address for
automated suggesons. Users must have logged in to the app to appear in the auto-generated
list.
Assign an incident status.

Select the incident Status to update the status to either New, Under Invesgaon, or Resolved
to indicate which incidents have been reviewed and to filter by status in the incidents table.
When seng an incident to Resolved, select the reason the resoluon was resolved, add a
oponal comment, and select if to Mark all alerts as resolved.
Merge incidents.
To merge incidents you think belong together, select the ellipsis icon, Merge Incidents and
enter the target incident ID you want to merge the incident with.
Incident scoring is managed as follows:
• Rule Based Score recalculates the incident score to include the merged incident scores.
• Manual Score allows to enter a score and override the rule-based score.
Incident assignees are managed as follows:
• If both incidents have been assigned—Merged incident takes the target incident assignee.
• If both incidents are unassigned—Merged incident remains unassigned.
• If the target incident is assigned and the source incident unassigned —Merged incident takes
the target assignee
• If the target incident is unassigned and the source incident is assigned—Merged incident
takes the exisng assignee
Create an exclusion.
Select the ellipsis icon, Create Exclusion and enter the Policy Name. Select the alerts to include
in the policy by filtering the Alert table and Create the exclusion.
Review Cortex XDR remediaon suggesons.

Select the ellipsis icon to open the Remediaon Suggesons dialog.
Review the incident assets.

Review the number of alerts, alert sources, hosts, users, and wildfire hits associated with the
incident. Select Hosts, Users, and Wildfire Hits to display the asset details.
Track and share your invesgaon progress.

Add notes or comments to track your invesgave steps and any remedial acons 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 descripon of the threat.
• Use the Incident Messenger ( ) to coordinate the invesgaon between analysts and track
the progress of the invesgaon. Select the comments to view or manage comments.
If needed, Search to find specific words or phrases in the Notepad and Messenger.
Invesgate Incident Overview

The incident Overview tab displays the MITRE taccs and techniques, summarized meline, and
interacve widgets that visualize the number of alerts, type of sources, hosts, and users associated
with the incident.
The Overview tab supports Advanced View for incidents created aer Cortex XDR 3.0.
Incidents created before Cortex XDR 3.0, are displayed in a Legacy view. To enable
flexibility, you can select to display incidents created aer Cortex XDR 3.0 Cortex using
either the Legacy view or Advanced view.
Review the incident MITRE taccs and techniques widget.

Cortex XDR displays the number of alerts associated with each tacc and technique. Select
the centered arrow at the boom of the widget to expand the widget and display the sub-
techniques. Hover over 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 tacc because of missing tags or in case an alert belongs
to several techniques.
Review the summarized meline.

The summarized Timeline displays the mestamp of following four type of acons that
occurred in the incident:
• When the incident was created.
• When the incident was assigned.
If the incident assignee was changed, the acon is marked in blue. Select the acon to
display the history.
• When the last alert was added to the incident.
• When the incident was resolved.
Invesgate informaon about the Alerts, Sources, and Assets associated with the incident.
• In the Alerts widget:
• Select See All to pivot to the Alerts & Insights table.
• Review the Total number of alerts and the colored line indicang the alert severity. Select
the severity tag to pivot to the Alerts & Insights table filtered according to the selected
severity.
• In the 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 Arfacts 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 informaon. Use
the available acons listed in the top right-hand corner to take remedial acons.
• Review Users that are marked as Featured.
• If available, review the User Score allocated to each user.
Invesgate Incident Key Assets and Arfacts

The Key Assets & Arfacts tab displays all the incident asset and arfact informaon of hosts,
users, and key arfacts associated with the incident.
Navigate to the Key Assets & Arfacts tab.
Invesgate arfacts.
In the Arfacts secon, search for and review the arfacts associated with the incident. Each
arfact displays, if available, the following arfact informaon and available acons according
to the type of arfact; File, IP Address, and Domain.
File Arfact
• File Details
• File name
• SHA256 value
• Number of alerts in the incident that include the file
• Signature status and signer
• WildFire Report. Select to view the Wildfire Analysis Report.
• AutoFocus (AF) tags. Select the tag to display the Source, Tag Class, and Descripon.
• VirusTotal (VT) Score. You can select the score to pivot to the VirusTotal report.
• Number of alerts in the incident that include the file according to severity
• Ellipses File Acons
• Open in Quick Launcher
• Go to VirusTotal
• Go to AutoFocus
• Search File on all Endpoints
• Open Hash View
• View Related Alerts
• Add to Block List
• Add to Allow List
IP Address Arfact
• IP Address Details
• IP Address value and name
• Number of alerts in the incident that include the IP address
• Whether the IP address in External or Internal.
• Whois informaon. Hover to display the Net Range, Registered Date, Registered name,
Organizaon, Updated Date details.
• Number of alerts in the incident that include the IP address according to severity
• Ellipsis IP Address Acons
• Open IP View

• Add to EDL
Domain Arfact
• Domain Details
• Domain name and IP Address
• Number of alerts that include the domain
• Number of alerts that include the domain according to severity
• Ellipsis Domain Acons
• Open IP View
• Add to EDL
Invesgate hosts.
In the Hosts secon, search for and review the hosts associated with the incident. Each host
displays, if available, the following host informaon and available acons:
• Host Details
• Icons represenng whether a Cortex XDR Agent is installed on the host and the
operang system plaorm. A green icon indicates the host is connected.
• Host Name
• IP address associated with the host.
• Number of alerts that include the host according to severity.
• Ellipsis Host Acons
You can choose to perform an acon on mulple hosts by marking the entries you want to
include or Select All.
• Security Operaons > Isolate Endpoint, Iniate Malware Scan, Retrieve Endpoint Files,
Iniate Live Terminal
• Open Asset View
To further invesgate the host:
Select the host name 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 informaon details. In addion, you can
perform the available acons listed in the top right-hand corner.
Invesgate users.
In the Users secon, search for and review the users associated with the incident. Each user
displays, if available, the following user informaon and available acons:
• User Details
• User Name
• Whether the user is Featured
• The User Score if available.
• Acve Directory and Organizaon Unit names. Hover to display the if the name is an
Acve Directory or OU.
• Workday icon. Hover to display the Workday informaon.
• Number of alerts that include the user according to severity.
• Ellipsis User Acons
• Open User View
Invesgate Incident Alerts and Insights

The Alerts & Insights tab displays a table of the alerts and insights associated with the incident.
Navigate to the Alerts & Insights tab.
Filter the Alerts and Insights tables as you would in the dedicated Cortex XDR pages.
Select an alert or insight to display the corresponding Details panel. The panel displays the
following alert details, if available.
• Alert
• Alert name, severity, alert source, and rule name
• General
• MITRE ATT&CK
• Host
• Rule
• Network Connecons
• Insight
• Insight name, type, source, and descripon
• General
• MITRE ATT&CK
• Host
• Rule
Use the available acons listed in the top right-hand corner to take remedial acons.
Invesgate Incident Timeline

The incident Timeline tab is a chronological representaon of alerts and acons relang to the
incident.
To begin invesgang:
Navigate to the Timeline tab and filter the acons according to following acon types:
• All acons
• Alerts
• Response Acons
• Incident Management Acons
• Automac Incident Updates
Invesgate meline entry.

Each meline entry is a representaon of a type of acon that was triggered in the alert. Alerts
that include the same arfacts are grouped into one meline entry and display the common
arfact in an interacve link. Depending on the type of acon, you can select the entry, host
names, and arfacts to further invesgate the acon:
• Locate the acon you want to invesgate:
• Response and Management Acons ( )—Add and view comments relang to this
acon.
• Alert and Automac Updates ( )—Display the Details panel. In the panel, navigate to
the Alerts tab to view the Alerts table filtered according to the Alert ID, the Key Assets
to view a list of Hosts and Users associated to the alert, and an opon to add Comments.
• Select the Host name to display, if available, the endpoint data.
• Select the Arfact to display the following type of informaon:
• Hash Arfact—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 Arfact—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 acon entries that involved more arfacts, expand Addional arfacts found to further
invesgate.
Invesgate Incident Execuons

The Execuons tab displays all the alert causality chains associated with the incident. The
causality chains are aggregated according to following type of groupings:
• Host Name
• Host with a Cortex XDR agent installed
• Host without a Cortex XDR agent installed
• Mulple Hosts
• Undetected Host
• User Name
• Username
• Mulple Users
• Undetected Users
• Cloud related alerts are displayed in the User Name grouping.

• Prisma Cloud Compute alerts are displayed in the Host Name grouping.
Navigate to the Execuons tab.
Invesgate the host causality chains.

In the Execuons secon, search for and review the hosts associated with the incident. Each
host displays, if available, the following host informaon and available acons:
• Execuon Details
• Icons represenng whether a Cortex XDR Agent is installed on the host and the
operang system plaorm. A green icon indicates the host is connected.
• Host Name
• IP address associated with the host.
• Alert Sources associated with this host.
• Number of alerts that include the host according to severity.
• Ellipsis Execuon Acons
Select the ellipsis to perform the following acon on the host:
• Security Operaons > Isolate Endpoint, Iniate Malware Scan, Retrieve Endpoint Files,
Iniate Live Terminal
• Open Asset View
Invesgate a causality chain.

The causality chains are listed according to the Causality Group Owner (CGO), expand the
CGO card you want to invesgate. Each CGO card displays the CGO name, the following CGO
event details, and the causality chain:
• CGO Name
• Alert Sources associated with the enre causality chain
• Execuon me of the causality chain
• Number of alerts that include the CGO according to severity.
Expand the causality chain to further invesgate and perform available Causality View acons.
Invesgate Arfacts and Assets

To streamline the invesgaon process and reduce the number of steps it takes to invesgate and
threat hunt arfacts and assets, Cortex XDR provides dedicated views of informaon relang to IP
address, Network Assets, and File and Process Hash.
Each of the views automacally aggregates and displays a summary of all the informaon Cortex
XDR and threat intelligence services have regarding a specific arfact and asset.
• IP Address View
• Asset View
• File and Process Hash View
• Invesgate a User
Invesgate an IP Address
The IP Address View provides a powerful way to invesgate and take acon on IP addresses by
reducing the number of steps it takes to collect, research, and threat hunt related incidents. Cortex
XDR automacally aggregates and displays a summary of all the informaon Cortex XDR and
threat intelligence services have regarding a specific IP address over a defined 24-hour or 7-day
me frame.
To help you determine whether an IP address is malicious, the IP Address View displays an
interacve visual representaon of the collected acvity for a specific IP address.
To invesgate an IP address:
STEP 1 | Open the IP View for an IP address.
You can access the view from an IP address in Cortex XDR console, where available, by
either right-click > Open IP View, selecng the IP address or using the default keyboard
shortcut Ctrl/CMD+Shift+E combinaon, or searching for a specific IP address in the Quick
Launcher.
To change the default keyboard shortcut, select Sengs > Configuraons > General > Server
Sengs > Keyboard Shortcuts. The shortcut value must be a keyboard leer, A through Z, and
cannot be the same as the Quick Launcher defined shortcut.
STEP 2 | Review the overview for the IP address.

The overview displays network operaons, incidents, acons, and threat intelligence
informaon relang to a specific IP address and provides a summary of the network operaons
and processes related to the IP address.
1. Review the auto generated summary of the number of network operaons and processes
related to the IP that occurred over the past 7 days.
2. Add an Alias or Comment to the IP address.
3. Review the locaon of the IP address. By default, Cortex XDR displays informaon on
whether the IP address is an internal or external IP address.
• External—Connecon Type: Incoming displaying IP address is located outside of your
organizaon. Displays the country flag if the locaon informaon is available.
• Internal—Connecon Type: Outgoing displaying IP address is from within your
organizaon. The XDR Agent icon is displayed if the corresponding endpoint
idenfied by the IP address has an agent is installed at that point in me.
4. Idenfy the IOC severity.
The color of the IP address value is color-coded to indicate the IOC severity.
• Low—Blue
• Medium—Yellow
• High—Red
• Crical—Red
5. Review any available threat intelligence for the IP address.
Depending on the threat intelligence sources that you integrate with Cortex XDR, you
can review any of the following threat intelligence.
• Virus Total score and report
Requires a license key. Select Sengs > Configuraons > Integraons >
Threat Intelligence.
• Whois idenficaon data for the specific IP address.
• IOC Rule, if applicable, including the IOC Severity, Number of hits, and Source.
• EDL IP address if the IP address was added to an EDL.
6. Review any related incidents:
Related Incidents lists the most recent incidents that contain the specific IP address
as part of the incident Key Arfacts according to the Last Updated mestamp. If the
IP address belongs to an endpoint with a Cortex XDR agent installed, the incidents are
displayed according to the host name rather than the IP address. To dive deeper into
specific incidents, select the Incident ID. To view all the related incidents, select View All.
Cortex XDR displays Recently Updated Incidents which filters incidents for those that
contain the IP address.
STEP 3 | Filter the IP address informaon you want to visualize.

Select from the following criteria to refine the scope of your IP address informaon you want
visualized. Each selecon aggregates the displayed data.
Filter Descripon
Type The type of informaon you want to display.

• Host Insights—Pivot to the Asset View of
the host associated with the IP address.
• Network Connecons—Display the IP
View of the network connecons made
with the IP address.
Primary The main set of values you want to

display. The values depend on the selected
Connecon Type.
• All Aggregaons—Summary of all the
related IP address data.
• Desnaon/Source Country
• Desnaon/Source Port
• Desnaon/Source IP
• Desnaon/Source Process
• App-ID
Secondary The set of values you want to apply as the

secondary set of aggregaons. Must differ
than your Primary selecon:
• Desnaon Country
• Desnaon/Source Port
• Desnaon/Source IP
• Desnaon/Source Process
• App-ID
Node Size The node size to display for the type of values.
• Number of Connecons
• Total Traffic
• Total Download
• Total Upload
Showing The number of the Primary and Secondary

aggregated connecons.
• Top 5
Filter Descripon
• Top 3
• Boom 5
• Boom 3
Connecon Type Type of connecon you want to display your

defined set of values.
• Incoming
• Outgoing
Timeframe Time period over which to display your

• 24 Hours
• 7 Days
Select to apply your selecons and update the informaon displayed in the visualizaon
pane. If necessary, Refresh to retrieve data.
STEP 4 | Review the selected data.

• Select each node to addional informaon.
• Select Recent Outgoing Connecons to view the most recent connecons made by this IP
address. Search all Outgoing Connecons to run a Network Connecons query on the all
the connecons made by this IP address.
STEP 5 | Aer reviewing the available informaon for the IP address, take acon if desired:
Depending on the current IOC and EDL status, select Acons to:
• Edit Rule
• Disable Rule
• Delete Rule
• Add to EDL
Invesgate an Asset
The Asset View provides a powerful way to invesgate assets by reducing the number of steps it
takes to collect and research hosts. Cortex XDR automacally aggregates informaon on hosts
and displays the host insights and a list of related incidents.
To invesgate an asset:
STEP 1 | Open the Asset View for an asset.

You can access the view from:
• A host with Cortex XDR agent installed in Cortex XDR console by right-click > Open Asset
View.
• The IP View of an internal IP address with a Cortex XDR Agent by selecng Host Insights
from the navigaon bar.
• The Quick Launcher, by searching for a specific Host Name.
STEP 2 | Review the Asset overview.

The overview displays the host name and any related incidents.
1. Review the Host name.
2. Add an Alias or Comment to the host name.
Related Incidents lists the most recent incidents that contain the host as part of the
incident Key Arfacts according to the Last Updated mestamp. If the host belongs to
an endpoint with a Cortex XDR agent installed, the incidents are displayed according to
the host name. To dive deeper into specific incidents, select the Incident ID. To view all
the related incidents, select View All.
STEP 3 | Filter the host informaon you want to display.

Select from the following criteria to refine the scope of the host informaon you want to
display. Each selecon aggregates the displayed data.
Filter Descripon
Type The type of informaon you want to display.

• Host Insights—A list of the host arfacts.
• Network Connecons—Pivot to the IP
view of the IP addresses associated with
the host.
Primary List of host arfacts you want to display.

• Users
• Groups
• Users to Groups
• Services
• Drivers
• Autorun
• System Informaon
• Shares
• Disks
Filter Descripon
Compare Compare host insights collected by Cortex

XDR over the last 30 days.
pane.
STEP 4 | Review the Host Inventory.

Select Run insights collecon to iniate a new collecon. The next me the Cortex XDR agent
connects, the insights are collected and displayed.
Invesgate a File and Process Hash

The file and process Hash View provides a powerful way to invesgate and take acon on SHA256
hash processes and files by reducing the number of steps it takes to collect, research, and threat
hunt related incidents. The Hash View automacally aggregates and displays a summary of all the
informaon Cortex XDR and threat intelligence services have regarding a specific SHA256 hash
over a defined 24 hour or 7 day me frame.
The Hash View allows you to drill down on each of the process execuons, file operaons,
incidents, acons, and threat intelligence reports relang to the hash.
To invesgate a file or process hash:
STEP 1 | Open the Hash View for a file or process hash.
You can access the view from every hash value in the Cortex XDR console by either right-
clicking Open Hash View, selecng the hash and using the keyboard shortcut Ctrl/CMD
+Shift+E combinaon, or searching for a specific hash in the Quick Launcher.
To change the default keyboard shortcut, navigate to Sengs > Configuraons > General >
Server Sengs > Keyboard Shortcuts. The shortcut value must be a keyboard leer, A through
Z, and cannot be the same as the Quick Launcher defined shortcut.
STEP 2 | Review the overview for the hash.

The overview displays host/user, incidents, acons, and threat intelligence informaon relang
to a specific hash and provides a summary of the files and processes related to the hash.
1. Review the auto generated summary of the number of network operaons and processes
related to the hash that occurred over the past 7 days.
2. Review the signature of the hash, if available.
3. Idenfy the WildFire verdict.
The color of the hash value is color-coded to indicate the WildFire report verdict:
• Blue—Benign
• Yellow—Grayware
• Red—Malware
• Light gray—Unknown verdict
• Dark gray—The verdict is inconclusive
4. Add an Alias or Comment to the hash value.
5. Review any available threat intelligence for the hash.
Depending on the threat intelligence sources that you integrate with Cortex XDR, you
can review any of the following threat intelligence.
• Virus Total score and report.
Requires a license key. Navigate to Sengs > Configuraons > Integraons

> Threat Intelligence.
• AutoFocus idenficaon data for the specific hash.
• IOC Rule, if applicable, including the IOC Severity, Number of hits, and Source
according to the color-coded values:
• Low—Blue
• Medium—Yellow
• High—Red
• Crical—Red
• WildFire analysis report.
6. Review if the hash has been added to:
• Allow List or Block List.
• Quaranned, select the number of endpoints to open the Quaranne Details view.
Related Incidents lists the most recent incidents that contain the specific hash as part of
the incident Key Arfacts according to the Last Updated mestamp. To dive deeper into
specific incidents, select the Incident ID. To view all the related incidents, select View All.
Cortex XDR displays Recently Updated Incidents which filters incidents for those that
contain the hash.
STEP 3 | Filter the hash informaon you want to visualize.

Select from the following criteria to refine the scope of your hash informaon you want
visualized. Each selecon aggregates the displayed data.
Filter Descripon
Event Type The main set of values you want to display.

The values depend on the selected type of
process or file.
• All Aggregaons—Summary of all the
related hash data.
• Process Execuons
• Process Injecons
• File Read
• File Write
• File Delete
• File Rename
• File Create
Primary The set of values you want to apply as the

primary set of aggregaons. Values depend on
the selected Event Type.
• Iniang Process
• Target Process / File
Secondary The set of values you want to apply as the

secondary set of aggregaons.
• Host
• User
Showing The number of the Primary and Secondary

aggregated values.
• Top 5
• Top 3
• Boom 5
• Boom 3
Timeframe Time period over which to display your

• 24 Hours
Filter Descripon
• 7 Days
pane. If necessary, Refresh to retrieve data.
STEP 4 | Review the selected data. For more informaon, select Recent Process Execuons to view
the most recent processes executed by the hash. Search all Process Execuons to run a
query on the hash.
STEP 5 | Aer reviewing the available informaon for the hash, take acon if desired:
• Select File Search to iniate a search for this hash across your network.
• Depending on the current hash status, select Acons to:
• Add the hash to a Allow List.
• Add the hash to a Block List.
• Create an IOC rule.
Invesgate a User
The User View provides a powerful way to invesgate user type assets by reducing the number of
steps it takes to collect and research a user. Cortex XDR, using Identy Analycs, automacally
aggregates informaon on a user and displays the user insights.
To invesgate the user:
STEP 1 | Open the User View.
You can access the view from:
• Users secon of the Incident View Key Assets & Arfacts tab
• User Scores Table
• Analycs Alert View User Node
• Top 5 Notable Users Widget
STEP 2 | Select to view the User details over either the Last 7 Days, Last 14 Days, or Last 30 Days.
STEP 3 | Invesgate the User overview.

• Details Header
Displays the following informaon aggregated by Cortex XDR from incidents, Workday, and
Acve Directory data:
• User Name—Represents the assigned user name.
• Department—Represents the user assigned department name.
• Phone Number—Represents the user assigned phone number.
• Locaon—Represents the user assigned locaon.
• Last Authencaon—Last date and me of an authencaon event associated with the
username.
• Last Login—Last date and me of a login event associated with the username.
• Workday Fields—If available, select All Info to display Workday user details.
• Current User Score—User Score currently assigned to the user. The score is updated
connuously as new alerts are associated with incidents.
• User Score Trend
Invesgate the User Score variaon over the selected meframe.
Select a score to display in the User Associated Incidents table the incidents that
contributed to the total user score on a specific day. In the table, you can view if the
following incident details:
• Starred—Whether the incident is starred, you can select to Star if you wish.
• Creaon Time—When the incident was created
• Descripon—Descripon of the incident
• Severity—Severity of the incident
• Points Added—Number of risk score the incident contributed to the user. The points are
calculated according to either Cortex XDR System Rules ( ) or Incident Scoring Rules
( ). Hover over a User defined score to display the Rule name that contributed to the
User Score.
Select an incident and pivot to the Incident View. Incidents that no longer exist or have
been merged are grayed out.
• User Associated Insights
Displays all the insights associated with the user filtered.
• Top 5 Hosts Logged Into
Top 5 hosts the user logged into.
• Top 5 Authencaon Target Hosts
Top 5 host names which the user requested access.
• Top 5 Authencaon Source Hosts
Top 5 host names where the user started authencaon.
• Recent Login
Displays the recent user login details.
• Recent Authencaons
Displays the recent user authencaon.
Invesgate Alerts
• Alerts
• Triage Alerts
• Manage Alerts
• Alert Exclusions
• Causality View
• Network Causality View
• Cloud Causality View
• Timeline View
• Analycs Alert View
Alerts
The Alerts page displays a table of all alerts in Cortex XDR.
The Alerts page consolidates non-informaonal alerts from your detecon sources to enable you
to efficiently and effecvely triage the events you see each day. By analyzing the alert, you can
beer understand the cause of what happened and the full story with context to validate whether
an alert requires addional acon. Cortex XDR supports saving 2M alerts per 4000 agents or 20
terabytes, half of the alerts are allocated for informaonal alerts, and half for severity alerts.
To view detailed informaon for an alert, you can also view details in the Causality Viewand
Timeline View. From these views you can also view related informaonal alerts that are not
presented on the Alerts page.
By default, the Alerts page displays the alerts that it received over the last seven days (to modify
the me period, use the page filters). Every 12 hours, Cortex XDR enforces a cleanup policy to
remove the oldest alerts that exceed the maximum alerts limit.
Cortex XDR processes and displays the name of users in the following standardized format, also
termed “normalized user”.
As a result, any alert triggered based on network, authencaon, or login events, displays the User
Name in the standardized format in the Alerts and Incidents pages. This impacts every alert for
Cortex XDR Analycs and Cortex XDR Analycs BIOC, including Correlaon, BIOC and IOC alerts
triggered on one of these event types.
The following table describes both the default fields and addional oponal fields that you can
add to the alerts table using the column manager and lists the fields in alphabecal order.
Field Descripon
Status Indicator Idenfies whether there is enough endpoint

( ) data to analyze an alert.
Field Descripon
Check box to select one or more alerts on which

to perform acons. Select mulple alerts to
assign all selected alerts to an analyst, or to
change the status or severity of all selected
alerts.
ACTION Acon taken by the alert sensor, either

Detected or Prevented with acon status
displayed in parenthesis. Opons are:
• Detected
• Detected (Allowed The Session)
• Detected (Download)
• Detected (Forward)
• Detected (Post Detected)
• Detected (Prompt Allow)
• Detected (Raised An Alert)
• Detected (Reported)
• Detected (Scanned)
• Detected (Sinkhole)
• Detected (Syncookie Sent)
• Detected (Wildfire Upload Failure)
• Detected (Wildfire Upload Success)
• Detected (Wildfire Upload Skip)
• Detected (XDR Managed Threat Hunng)
• Prevented (Block)
• Prevented (Blocked)
• Prevented (Block-Override)
• Prevented (Blocked The URL)
• Prevented (Blocked The IP)
• Prevented (Connue)
• Prevented (Denied The Session)
• Prevented (Dropped All Packets)
• Prevented (Dropped The Session)
• Prevented (Dropped The Session And Sent a
TCP Reset)
• Prevented (Dropped The Packet)
• Prevented (Override)
Field Descripon
• Prevented (Override-Lockout)
• Prevented (Post Detected)
• Prevented (Prompt Block)
• Prevented (Random-Drop)
• Prevented (Silently Dropped The Session
With An ICMP Unreachable Message To The
Host Or Applicaon)
• Prevented (Terminated The Session And
Sent a TCP Reset To Both Sides Of The
Connecon)
• Prevented (Terminated The Session And Sent
a TCP Reset To The Client)
• Prevented (Terminated The Session And Sent
a TCP Reset To The Server)
• N/A
AGENT OS SUB TYPE The operang system subtype of the agent from
which the alert was triggered.
ALERT ID A unique idenfier that Cortex XDR assigns to

each alert.
ALERT NAME Module that triggered the alert. If the alert was
generated by Cortex XDR, the Alert Name will
be the specific Cortex XDR rule that created the
alert (BIOC, IOC, or Correlaon Rule name). If
from an external system, it will carry the name
assigned to it by Cortex XDR. Alerts that match
an alert starring policy also display a purple star.
For alerts coming from firewalls, if

duplicate alerts with the same name
and host are raised within 24 hours,
they are aggregated and idenfied
by a +n tag.
Alerts that contain a Featured

Alert Field are displayed with
flag.
Alerts associated with the Identy Analycs are
displayed with an Identy Analycs tag.
Field Descripon
ALERT SOURCE Source of the alert: BIOC, Analycs BIOC,

Correlaon, IOC, XDR Agent, Firewall, or
Analycs.
APP-ID Related App-ID for an alert. App-ID is a traffic

classificaon system that determines what an
applicaon is irrespecve of port, protocol,
encrypon (SSH or SSL) or any other evasive
tacc used by the applicaon. When known,
you can also pivot to the Palo Alto Networks
Applipedia entry that describes the detected
applicaon.
APP CATEGORY APP-ID category name associated with a

firewall alert.
APP SUBCATEGORY APP-ID subcategory name associated with a

firewall alert.
APP TECHNOLOGY APP-ID technology name associated with a

firewall alert.
CATEGORY Alert category based on the alert source. An

example of an XDR Agent alert category is
Exploit Modules. An example of a BIOC alert
category is Evasion. If a URL filtering category is
known, this field also displays the name of the
URL filtering category.
CGO CMD Command-line arguments of the Causality

Group Owner.
CGO MD5 The MD5 value of the CGO that iniated the
alert.
CGO NAME The name of the process that started the

causality chain based on Cortex XDR causality
logic.
CGO SHA256 The SHA256 value of the CGO that iniated the
alert.
CGO SIGNATURE Signing status of the CGO:

• Unsigned
• Signed
• Invalid Signature
Field Descripon
• Unknown
CGO SIGNER The name of the soware publishing vendor

that signed the file in the causality chain that led
up to the alert.
Cortex XDR can display both the

O (Organizaon) value and the CN
(Common Name).
CLOUD IDENTITY TYPE Classificaon used to map identy type that

iniated an operaon which triggered an alert.
For example, Service, Application and
Temporary Credentials.
CLOUD IDENTITY SUB-TYPE A more specific classificaon of the identy

iniated operaon. For example, for Identy
Type: Temporary Credentials the sub type
could be Assumed Role.
CLOUD OPERATION TYPE Represents what has happened because of

the identy operaon. For example, Create,
Delete, and Modify.
CLOUD PROJECT Represents the cloud provider folders or

projects. For example, AWS Accounts and Azure
Subscripons.
CLOUD PROVIDER The name of the cloud provider where the alert
occurred:
• AWS
• GCP
• Azure
CLOUD REFERENCED RESOURCE Represents the resources that are referenced

in the alert log. In most cases, the referred
resource will be where the operaon was
iniated on.
CLOUD RESOURCE TYPE Classificaons 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.
Field Descripon
CLOUD RESOURCE SUB-TYPE A more specific classificaon used to map the

types of resources. For example, DISK,VPC,
Subnet are all mapped to Compute.
CONTAINS FEATURED HOST Displays whether the alert includes a host name
that has been flagged as a Featured Alert Field.
CONTAINS FEATURED USER Displays whether the alert includes a user name
that has been flagged as a Featured Alert Field.
CONATINS FEATURED IP ADDRESS Displays whether the alert includes an IP

address name that has been flagged as a
Featured Alert Field.
CID Unique idenfier of the causality instance

generated by Cortex XDR.
DESCRIPTION Text summary of the event including the alert

source, alert name, severity, and file path. For
alerts triggered by BIOC, IOC, and Correlaon
Rules, Cortex XDR displays detailed informaon
about the rule.
DESTINATION ZONE NAME The desnaon zone of the connecon for

firewall alerts.
DNS Query Name The domain name queried in the DNS request.
DOMAIN The domain on which an alert was triggered.
EMAIL RECIPIENT The email recipient value of a firewall alerts

triggered on a the content of a malicious email.
EMAIL SENDER The email sender value of a firewall alerts

EMAIL SUBJECT The email subject value of a firewall alerts

EVENT TYPE The type of event on which the alert was

triggered:
• File Event
• Injecon Event
• Load Image Event
• Network Event
Field Descripon
• Registry Event
EXCLUDED Whether the alert is excluded by an exclusion

configuraon.
EXTERNAL ID The alert ID as recorded in the detector from

which this alert was sent.
FILE PATH When the alert triggered on a file (the Event

Type is File) this is the path to the file on the
endpoint. If not, then N/A.
FILE MACRO SHA256 SHA256 hash value of an Microso Office file

macro
FILE MD5 MD5 hash value of the file.
FILE SHA256 SHA256 hash value of the file.
FW NAME Name of firewall on which a firewall alert was

raised.
FW RULE ID The firewall rule ID that triggered the firewall

alert.
FW RULE NAME The firewall rule name that matches the

network traffic that triggered the firewall alert.
FW SERIAL NUMBER The serial number of the firewall that raised the
firewall alert.
HOST The hostname of the endpoint or server on

which this alert triggered. The hostname is
generally available for XDR agent alerts or alerts
that are stched with EDR data. When the
hostname is unknown, this field is blank.
HOST FQDN The fully qualified domain name (FQDN) of the

Windows endpoint or server on which this alert
triggered.
HOST IP IP address of the endpoint or server on which

this alert triggered.
HOST MAC ADDRESS MAC address of the endpoint or server on

which this alert triggered.
HOST OS Operang system of the endpoint or server on

which this alert triggered.
Field Descripon
INCIDENT ID The ID of the any incident that includes the

alert.
INITIATED BY The name of the process that iniated an

acvity such as a network connecon or
registry change.
INITIATOR MD5 The MD5 value of the process which iniated

the alert.
INITIATOR SHA256 The SHA256 hash value of the iniator.
INITIATOR CMD Command-line used to iniate the process

including any arguments.
INITIATOR SIGNATURE Signing status of the process that iniated the

acvity:
• Unsigned
• Signed
• Unknown
INITIATOR PATH Path of the iniang process.
INITIATOR PID Process ID (PID) of the iniang process.
INITIATOR SIGNER Signer of the process that triggered the alert.

(Common Name).
INITIATOR TID Thread ID (TID) of the iniang process.
IS PHISHING Indicates whether a firewall alert is classified as

phishing.
LOCAL IP If the alert triggered on network acvity (the

Event Type is Network Connecon) this is the
IP address of the host that triggered the alert. If
not, then N/A.
LOCAL PORT If the alert triggered on network acvity (the

port on the endpoint that triggered the alert. If
not, then N/A.
Field Descripon
MAC ADDRESS The MAC address on which the alert was

triggered.
MISC Miscellaneous informaon about the alert.
MITRE ATT&CK TACTIC Displays the type of MITRE ATT&CK tacc on

which the alert was triggered.

and sub-technique on which the alert was
triggered.
MODULE For XDR Agent alerts, this field idenfies the

protecon 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 operang system that

created the alert.
OS PARENT CMD Command-line used to by the parent operang

system to iniate the process including any
arguments.
OS PARENT SIGNATURE Signing status of the operang system of the

acvity:
• Unsigned
• Signed
• Unknown
OS PARENT SIGNER Parent operang system signer.

(Common Name).
OS PARENT SH256 Parent operang system SHA256 hash value.
OS PARENT ID Parent operang system ID.
OS PARENT PID OS parent process ID.
OS PARENT TID OS parent thread ID.
Field Descripon
OS PARENT USER NAME Name of the user associated with the parent
operang system.
PROCESS EXECUTION SIGNATURE Signature status of the process that triggered

the alert:
• Unsigned
• Signed
• Unknown
PROCESS EXECUTION SIGNER Signer of the process that triggered the alert.

(Common Name).
REGISTRY DATA If the alert triggered on registry modificaons

(the Event Type is Registry) this is the registry
data that triggered the alert. If not, then N/A.
REGISTRY FULL KEY If the alert triggered on registry modificaons

(the Event Type is Registry) this is the full
registry key that triggered the alert. If not, then
N/A.
REMOTE HOST If the alert triggered on network acvity (the

the remote host name that triggered the alert. If
not, then N/A.
REMOTE IP The remote IP address of a network operaon

that triggered the alert.
REMOTE PORT The remote port of a network operaon that

triggered the alert.
RESOLUTION STATUS The status that was assigned to this alert when
it was triggered (or modified): New, Under
Invesgaon, Resolved. Right-click an alert to
Change Status.
Any update made to an alert impacts the
associated incident. An incident with all
its associated alerts marked as resolved is
automacally set to Auto-Resolved. Cortex XDR
connues to group Alerts to an Auto-Resolved
Incident for up to 6 hours. In the case where an
Field Descripon
alert is triggered during this duraon, Cortex
XDR will re-open the Incident.
RULE ID The ID that matches the rule that triggered the

alert.
SEVERITY The severity that was assigned to this

alert when it was triggered (or modified):
Informaonal, Low, Medium, High, Crical,
or Unknown. Right-click an alert to Change
Severity.
For BIOC, IOCs, and Correlaon Rules, you
define the severity when you create the rule.
Insights are low and informaonal severity
alerts that do not raise incidents, but provide
addional details when invesgang an event.
STARRED Whether the alert is starred by starring

configuraon.
SOURCE ZONE NAME The source zone name of the connecon for
firewall alerts.
TARGET FILE SHA256 The SHA256 hash vale of an external DLL file
that triggered the alert.
TARGET PROCESS CMD The command-line of the process whose

creaon triggered the alert.
TARGET PROCESS NAME The name of the process whose creaon

triggered the alert.
TARGET PROCESS SHA256 The SHA256 value of the process whose

creaon triggered the alert.
TIMESTAMP The date and me when the alert was triggered.
Right-click to Show rows 30 days prior or 30
days aer the selected mestamp field value.
URL The URL desnaon address of the domain

triggering the firewall alert.
USER NAME The name of the user that iniated the behavior
that triggered the alert. If the user is a domain
user account, this field also idenfies the
domain.
Field Descripon
Any alert triggered based on network,
authencaon, or login events, displays the
User Name in the follow standardized format in
the Alerts and Incidents pages.
XFF X-Forwarded-For value from the HTTP header

of the IP address connecng with a proxy.
From the Alerts page, you can also perform addional acons to manage alerts and pivot on
specific alerts for deeper understanding of the cause of the event.
• Manage Alerts
• Causality View
• Timeline View
• Analycs Alert View
Triage Alerts
When the Cortex XDR management console displays a new alert on the Alerts page, use the
following steps to invesgate and triage the alert:
STEP 1 | Review the data shown in the alert such as the command-line arguments (CMD), process info,
etc.
For more informaon about the alert fields, see Alerts.
STEP 2 | Analyze the chain of execuon in the Causality View.

When the app correlates an alert with addional endpoint data, the Alerts table displays a
green dot to the le 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.
STEP 3 | Review the Timeline View of review the sequence of events over me.
The meline is available for alerts that have been stched with endpoint data.
STEP 4 | If deemed malicious, consider responding by isolang the endpoint from the network.
STEP 5 | Remediate the endpoint and return the endpoint from isolaon.
STEP 6 | Inspect the informaon again to idenfy any behavioral details that you can use to Create a
BIOC Ruleand Create a Correlaon Rule.
If you can create a BIOC or Correlaon rule, test and tune the logic for the rule, and then save
it.
Manage Alerts
From the Incident Response > Incidents > Alerts Table, you can manage the alerts you see and the
informaon Cortex XDR displays about each alert.
The opons available can change depending on the Alert Source.
• Copy Alerts
• Analyze an Alert
• Pivot to Views
• Create Profile Excepons
• Add File Path to Malware Profile Allow List
• Create a Featured Alert Field
• View Generang BIOC or IOC Rule
• Retrieve Addional Alert Details
• Export Alert Details to a File
• Add an Alert Exclusion Policy
• Invesgate Contribung Events
• Open Drilldown Query
Copy Alerts
You can copy an alert into memory as follows:
• Copy the URL of the alert record
• Copy the value for an alert field
• Copy the enre row of alert record
With either opon, you can paste the contents of memory into an email to send. This is helpful if
you need to share or discuss a specific alert with someone. If you copy a field value, you can also
easily paste it into a search or begin a query.
Create a URL for an alert record:

1. From the Alerts page, right-click the alert you want to send.
2. Select Copy alert URL.
Cortex XDR saves the URL to memory.
3. Paste the URL into an email or use as needed to share the alert.
Copy a field value in an alert record:

1. From the Alerts page, right-click the field in the alert that you want to copy.
2. Select Copy text to clipboard.
Cortex XDR saves the field contents to memory.
3. Paste the value into an email or use as needed to share informaon from the alert.
Copy the enre row of alert record

1. From the Alerts page, right-click on one or more alerts you want to copy.
2. Select Copy enre row(s).
3. Paste the value into an email or use as needed to share informaon from the alert.
Analyze an Alert
To help you understand the full context of an alert, Cortex XDR provides a powerful analysis view
that empowers you to make a thorough analysis very quickly.
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 stched with endpoint data.
To view the analysis:
STEP 1 | From the Alerts page, locate the alert you want to analyze.
STEP 2 | Right-click anywhere in the alert, and select Invesgate Causality Chain.
STEP 3 | Choose whether to open the Causality View card for an alert in a new tab or the same tab.
You can also view the causality chain over me using the Timeline view.
STEP 4 | Review the chain of execuon and available data for the process and, if available, navigate
through the processes tree.
Pivot to Views
From any listed alert you can pivot to the following alert-related views:
• Open Asset View—Open the Asset View panel and view informaon related to the alert there.
• View full endpoint details—View the full details of the endpoint to which the alert relates.
• View related incident—View informaon about an incident related to the alert.
• View Observed Behaviors—View informaon about observed behaviors that are related to the
alert.
To pivot to any of these views:
STEP 1 | Right-click a listed alert.
STEP 2 | From the pop-up menu, select the view to which you want to pivot.
Create Profile Excepons

For XDR Agent alerts, you can create profile excepons for Window processes, BTP, and JAVA
deserializaon alerts directly from the Alerts table.
STEP 1 | Right-click an XDR Agent alert which has a category of Exploit and Create alert excepon.
STEP 2 | Select an Excepon Scope:

• Global—Apply the excepon across your organizaon.
• Profile—Apply the excepon to an exisng profile or click and enter a Profile Name to
create a new profile.
STEP 3 | Add the scope.
STEP 4 | (Oponal) View your profile excepons.

1. Navigate to Endpoints > Policy Management > Profiles.
2. In the Profiles table, locate the OS in which you created your global or profile excepon
and right-click to view or edit the excepon properes.
Add File Path to Malware Profile Allow List

Add a file path to an exisng Malware profile allow list directly from the Alerts table.
STEP 1 | In the Alerts table, select the Iniator Path, CGO path, and/or File Path field values you want
to add to your malware profile allow list.
STEP 2 | Right-click and select Add <path type> to malware profile allow list.
STEP 3 | In the Add <path type> to malware profile allow list dialog, select from your exisng Profiles
and Modules to which you want to add the file path to the allow list.
STEP 4 | (Oponal) View your Malware profile allow list.

1. Navigate to Endpoints > Policy Management > Prevenon > Profiles and locate the
malware profile you selected.
2. Right-click, select Edit Profile and locate in the Files / Folders in Allow List secon the
path file you added.
Create a Featured Alert Field

To beer highlight alerts that are significant to you, Cortex XDR enables you to label specific alert
aributes as Featured Alert Fields. Featured alert fields help you track in the Alerts Table alerts
that involve a specific host names, user names, and IP addresses.
STEP 1 | Navigate to Incident Response > Incident Configuraon > Featured Fields and select a type
of featured field:
• Hosts
• Users
• IP Addresses
• Acve Directory
STEP 2 | In the field type table, Add featured <field-type> to define a list of alert fields you want
flagged in the Alerts Table. You can either Create New featured alert field from scratch or
Upload from File.
• To create a new alert field:
1. Enter one or more field-type values of the and Add to the list.
2. (Oponal) Add a comment.
3. Add the featured alert field.
• To import fields:
1. Browse or Drag and Drop your CSV file of field values. Download example file to ensure
you using the correct format.
2. Import your file.
STEP 3 | (Oponal) Manage your featured alert field list.

• Locate the alert field you want to edit or delete.
• Right-click and Edit <field-type> to modify the field definion, or Delete Field Name to
remove the featured flag.
STEP 4 | Invesgate alerts that contain the featured alert fields.

• Navigate to the Alerts Table.
• In the Alerts table, sort according to the following fields:
• Contains Featured Host
• Contains Featured User
• Contains Featured IP Address
• In the Alert Name field, Cortex XDR displays alerts that contain a matching featured field
value with a flag.
Featured Acve Directory values are displayed in the User and Host fields
accordingly.
• (Oponal) Create an Incident Scoring Rule using the Alert table Contains Featured Field
Name fields to further highlight and priorize alerts containing the Host, User, and IP
address aributes.
View Generang BIOC or IOC Rule

Easily view the BIOC or IOC rules that generated alerts directly from the Alerts table.
STEP 1 | From the Alerts page, locate alerts with Alert Sources: XDR BIOC and XDR IOC.
STEP 2 | Right-click the row, and select Manage Alert > View generang 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.
STEP 3 | Review the rule, if necessary, right-click to perform available acons.
Retrieve Addional Alert Details

To easily access addional informaon relang to an alert:
STEP 1 | From the Alerts page, locate the alert for which you want to retrieve informaon.
STEP 2 | Right-click anywhere in the alert, and select one of the following opons:
• Retrieve alert data—Cortex XDR can provide addional analysis of the memory contents
when an exploit protecon module raises an XDR Alert. To perform the analysis you
must first retrieve alert data consisng of the memory contents at the me the alert was
raised. This can be done manually for a specific alert, or you can enable Cortex XDR to
automacally retrieve alert data for every relevant XDR Alert. Aer 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 Acon Center (pivot to view Addional data). When
analysis is complete, Cortex XDR 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 Cortex XDR agent send them to the Cortex XDR management console. If mulple files
are involved, Cortex XDR 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 addional
status informaon. When the files are successfully uploaded, you can download them from
the Acon 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.
STEP 3 | Navigate to Response > Acon Center to view retrieval status.
STEP 4 | Download the retrieved files locally.

In the Acon Center, wait for the data retrieval acon to complete successfully. Then, right-
click the acon row and select Addional 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 invesgate the alert,
ensure to provide the downloaded ZIP file.
Export Alert Details to a File

To archive, connue invesgaon offline, or parse alert details, you can export alerts to a tab-
STEP 1 | From the Alerts page, adjust the filters to idenfy the alerts you want to export.
STEP 2 | When you are sasfied 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.
Exclude Alert
To exclude an alert.
STEP 1 | From the Alerts page, locate the alert you want to exclude.
STEP 2 | Right-click the row, and select Manage Alert > Exclude Alert.
A noficaon displays indicang the exclusion is in progress.
Invesgate Contribung Events

When managing alerts generated by a Correlaon Rule, you can Invesgate Contribung Events,
which opens a window with all the events created for this alert. You can have up to 1000 events
per Correlaon Rule. In addion, if the alert generated for this Correlaon Rule includes a
Drilldown Query, you can select Open drilldown query, which opens a new browser in XQL
Search to run this query.
To invesgate contribung events.
STEP 1 | From the Alerts page, locate the alert you want to invesgate contribung events.
STEP 2 | Right-click the row, and select Manage Alert > Invesgate Contribung Events.
STEP 3 | (Oponal) Open drilldown query.

If the Correlaon Rule that generated this alert is configured with a Drilldown Query to provide
addional informaon about the alert for further invesgaon, you can open a new browser
in XQL Search to run the query. This XQL query can accept parameters from the alert output
for the Correlaon Rule. If the Correlaon Rule that generated this alert does not include a
Drilldown QUERY, no link is displayed.
The me frame used to run the Drilldown Query provides more informave details about the
alert generated by the Correlaon Rule. The alert me frame is the minimum and maximum
mestamps of the events for the alert. If there is only one event, the event mestamp is the
me frame used for the query.
1. Select the Open drilldown query link.
A new browser in XQL Search is opened where you can run the query and any other
operaons related to XQL Search.
2. Select Run.
Open Drilldown Query

When the Correlaon Rule that generated an alert is configured with a Drilldown Query to
provide addional informaon about the alert for further invesgaon, you can open a new
browser in XQL Search to run the query. This XQL query can accept parameters from the alert
output for the Correlaon Rule. If the Correlaon Rule that generated this alert does not include a
Drilldown Query, the opon is not available.
The me frame used to run the Drilldown Query provides more informave details about the alert
generated by the Correlaon Rule. The alert me frame is the minimum and maximum mestamps
of the events for the alert. If there is only one event, the event mestamp is the me frame used
for the query.
To open the Drilldown Query.
STEP 1 | From the Alerts page, locate the alert you want to open the Drilldown Query.
STEP 2 | Open Drilldown Query.

You can open the Drilldown Query in the following ways.
• Select the quick acon Open Drilldown Query icon ( ).
• Right-click the row, and select Manage Alert > Open Drilldown Query.
• Right-click the row, and select Manage Alert > Invesgate Contribung Events. For more
informaon, see Invesgate Contribung Events.
A new browser in XQL Search is opened where you can run the query and any other
operaons related to XQL Search.
STEP 3 | Select Run.
Alert Exclusions
The Incident Response > Incident Configuraon > Alerts Exclusions page displays all alert
exclusion policies in Cortex XDR.
An alert exclusion is a policy that contains a set of alert match criteria that you want to suppress
from Cortex XDR. You can Add an Alert Exclusion Policy from scratch or you can base the
exclusion off of alerts that you invesgate in an incident. Aer you create an exclusion policy,
Cortex XDR excludes and no longer saves any of the future alerts that match the criteria from
incidents and search query results. If you choose to apply the policy to historic results as well as
future alerts, the app idenfies the historic alerts as grayed out.
add to the alert exclusions table and lists the fields in alphabecal order.
Field Descripon
Check box to select one or more alert exclusions on which you want to
perform acons.
BACKWARD SCAN Exclusion policy status for historic data, either enabled if you want to
STATUS 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 idenfies the purpose or reason

for the exclusion policy.
DESCRIPTION Text summary of the policy that displays the match criteria.
MODIFICATION Date and me when the exclusion policy was created or modified.
DATE
NAME Descripve name provided to idenfy the exclusion policy.
POLICY ID Unique ID assigned to the exclusion policy.
STATUS Exclusion policy status, either enabled or disabled.
Field Descripon
USER User that last modified the exclusion policy.
USER EMAIL Email associated with the administrave user.
Add an Alert Exclusion Policy

Through the process of triaging alerts or resolving an incident, you may determine 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 policy.
Aer you create an exclusion policy, 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 policy
to historic results as well as future alerts, the app idenfies 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 noficaon to the incident
assignee (if set).
There are two ways to create an exclusion policy. You can define the exclusion criteria when you
invesgate an incident or you can create an alert exclusion from scratch.
• Build an Alert Exclusion Policy from Alerts in an Incident
• Build an Alert Exclusion Policy from Scratch
Build an Alert Exclusion Policy from Alerts in an Incident
If aer reviewing the incident details, if 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 Alert Exclusions from scratch.
STEP 1 | From the Incident view in Cortex XDR, select Acons > Create Exclusion.
STEP 2 | Enter a Policy Name to idenfy your alert exclusion.
STEP 3 | Enter a descripve Comment that idenfies the reason or purpose of the alert exclusion
policy.
STEP 4 | Use the alert filters to add any the 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 opon to Show only alerts in the named incident.
STEP 5 | Create the exclusion policy and confirm the acon.

If you later need to make changes, you can view, modify, or delete the exclusion policy from
the Incident Response > Incident Configuraon > Alert Exclusions page.
Build an Alert Exclusion Policy from Scratch

STEP 1 | Select Incident Response > Incident Configuraon > Alert Exclusions.
STEP 2 | Select + Add Exclusion.
STEP 3 | Enter a Policy Name to idenfy the exclusion policy.
STEP 4 | Enter any comments to explain the purpose or intent behind the policy.
STEP 5 | Define the exclusion criteria.

Use either the filters at the top to build your exclusion criteria. Or, to use exisng alert values
to populate your exclusion criteria, right click the value, and select Add rows with <value> to
policy.
As you define the criteria, the app filters the results to display matches.
STEP 6 | Review the results.

The alerts in the table will be excluded from appearing in the app aer the policy is created and
oponally, any exisng alert matches will be grayed out.
This acon is irreversible: All historic excluded alerts will remain excluded if you disable
or delete the policy.
STEP 7 | Create and then select Yes to confirm the alert excepon policy.
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 or sent to Cortex XDR from a supported alert source
such as the Cortex XDR agent) and includes the enre process execuon chain that led up to the
alert. On each node in the CI chain, Cortex XDR provides informaon to help you understand
what happened around the alert.
The Causality View comprises five secons:
Context
Summarizes informaon 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 acvity, this secon also displays the endpoint connecvity status and operang
system.
Causality Instance Chain

Includes the graphical representaon of the Causality Instance (CI) along with other informaon
and capabilies to enable you to conduct your analysis.
The Causality View presents a single CI chain. The CI chain is built from processes nodes, events,
and alerts. The chain presents the process execuon and might also include events that these
processes caused and alerts that were triggered on the events or processes. The Causality
Group Owner (CGO) is displayed on the le 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 enre CI to
fully understand why the alert occurred.
Causality data is displayed as follows:
• Visualizaon of the branch between the CGO and the actor process of the alert/event.
• Display up to nine addional process branches that reveal alerts related to the alert/event.
Branches containing alerts with the nearest mestamp to the original alert/event are displayed
first.
• Causality cards that contain more causality data display a Showing Paral Causality flag. You
can manually add addional child or parent processes branches by right-clicking on the process
nodes displayed in the graph.
The Causality View provides an interacve 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
selecng and dragging it. To return the chain to its original posion and size, click in the lower-
right of the CI graph.
The process node displays icons to indicate when an RPC protocol or code injecon event were
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 Informaon pop-up lisng useful informaon
about the process. If available, the pop-up includes the process Analycs Profiles.
• Path of the process.
• Command line of the process.
• SHA256 value of the process.
• Username of the user that iniated the process.
• Signature associated with the process, if available.
• WildFire verdict, if available.
• Running me of the process.
From any process node, you can also right-click to display addional acons that you can perform
during your invesgaon:
• Show parents and children—If the parent is not presented by default, you can display it. If the
process has children, Cortex XDR open 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 quaranne a process—If aer invesgang the
acvity in the CI chain, you want to take acon on the process, you can select the desired
acon to allow or block process across your organizaon.
In the causality view of a Detecon (Post Detected) type alert, you can also Terminate process
by hash.
• Depending on the type of node—file, process, or IP address—open the arfact view:
• Open Hash View to display detailed informaon about the files and processes relang to the
hash.
• Open IP View to display detailed informaon about the IP address.
• Iniate a remediaon analysis.
Enty Data
Provides addional informaon about the enty that you selected. The data varies by the type of
enty but typically idenfies informaon about the enty related to the cause of the alert and the
circumstances under which the alert occurred.
For example, device type, device informaon, remote IP address.
When you invesgate command-line arguments, click {***} to obfuscate or decode the base64-
encoded string.
For connued invesgaon, you can copy the enre enty data summary to the clipboard.
Response Acons
You can choose to isolate the host, on which the alert was triggered, from the network or iniate a
live terminal session to the host to connue invesgaon and remediaon.
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 informaonal.
To connue invesgaon, you can perform the following acons from the right-click pivot menu:
• View in XQL to populate the event in an XQL search query that you can further refine, if
needed.
• Add <path type> to malware profile allow list from the Process and File table <path> fields. For
example, target_process_path, src_process_path, file_path, or os_parent_path.
• For the behavioral threat protecon results, you can take acon on the iniator to add it to an
allow list or block list, terminate it, or quaranne it.
• Revise the event results to see possible related events near the me of an event using an
updated mestamp value to Show rows 30 days prior or 30 days aer.
To view stascs for files on VirusTotal, you can pivot from the Iniator MD5 or SHA256
value of the file on the Files tab.
Network Causality View

The Network Causality View provides a powerful way to analyze and respond to the stched
firewall and endpoint alerts. The scope of the Causality View is the Causality Instance (CI) to which
this alert pertains. The Causality View presents the network processes that triggered the alert,
generated by Cortex XDR, Palo Alto Networks next-generaon firewalls, and supported alert
source such as the Cortex XDR agent.
The network causality view includes the enre process execuon chain that led up to the alert.
On each node in the CI chain, Cortex XDR provides informaon to help you understand what
happened around the alert.
The CI chain visualizes the firewall logs, endpoint files, and network connecons that triggered
alerts connected to a security event.
The network causality view displays only the informaon it collects from the detectors. It is
possible that the CI may not show some of the firewall or agent processes.
The Network Causality View comprises five secons:
Secon Descripon
Context Summarizes informaon 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
acvity, this secon also displays the endpoint
connecvity status and operang system.
Host Isolaon You can choose to isolate the host, on which the
alert was triggered, from the network or iniate
a live terminal session to the host to connue
invesgaon and remediaon.
CI Chain Includes the graphical representaon of the

Causality Instance (CI) along with other informaon
and capabilies to enable you to conduct your
analysis.
The Causality View presents a CI chain for each of
the processes and the network connecon. The
CI chain is built from processes nodes, events, and
alerts. The chain presents the process execuon
and might also include events that these processes
caused and alerts that were triggered on the events
or processes. The Causality Group Owner (CGO)
is displayed on the le 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 enre CI to fully understand why the alert
occurred.
The Causality View provides an interacve
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 selecng and dragging it. To return
the chain to its original posion and size, click
in the lower-right of the CI graph.

From any process node, you can also right-click
to display addional acons that you can perform
during your invesgaon:
• Show parents and children—If the parent is
not presented by default, you can display it. If
the process has children, XDR app displays the
number of children beneath the process name
and allows you to display them for addional
informaon.
• Hide branch—Hide a branch from the Causality
View.
• Add to block list or allow list, terminate, or
quaranne a process—If aer invesgang the
acvity in the CI chain, you want to take acon
on the process, you can select the desired acon
on the process across your organizaon.
In the causality view of a Detecon (Post
Detected) type alert, you can also Terminate
process by hash.
When selecng the Network Appliance node in the
Network Causality View, the event mestamp is
now displayed in the Enty Data secon of the card.
The color of a process node also correlates to the
WildFire verdict.
• Blue—Benign.
• Yellow—Grayware.
• Red—Malware.
• Light gray—Unknown verdict.
• Dark gray—The verdict is inconclusive.
To view and download the WildFire
report, in the Enty Data secon, click
.
Enty Data Provides addional informaon about the enty

that you selected. The data varies by the type of
enty but typically idenfies informaon about
the enty related to the cause of the alert and the
Events Table Displays all related events for the process node
which matches the alert criteria that were not
triggered in the alert table but are informaonal.
You can also export the table results to a tab-
For the Behavioral Threat Protecon table, right-
click to add to allow list or block list, terminate, and
quaranne a process.
To view stascs for files on VirusTotal,

you can pivot from the Iniator MD5
or SHA256 value of the file on the Files
tab.
Cloud Causality View

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 identy and /or IP
address and the acons performed by the identy on the cloud resource. On each node in the CI
chain, Cortex XDR provides informaon to help you understand what happened around the event.
The Causality View comprises of the following secons:
Context
Summarizes informaon 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 representaon of the Causality Instance (CI) along with other informaon
and capabilies to enable you to conduct your analysis.
The Causality View presents a single event CI chain. The CI chain is built from Identy and
Resource nodes. The Identy 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 Identy
and Cloud Resource.
Causality data is displayed as follows:
The Causality View provides an interacve 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
selecng and dragging it. To return the chain to its original posion and size, click in the lower-
right of the CI graph.
Identy Node
Displays the name of the identy, generated alert informaon, and if available the associated IP
address.
To further invesgate the user:
1. Hover over a Identy node to display, if available, the identy Analycs Profiles.
2. Select the Identy node to display in the Enty Data secon addional informaon about the
Identy enty.
3. Select the Alert icon to display in the Enty Data secon addional informaon about the alert.
IP Address Node
Displays the IP address associated with the Identy.
Operaons
Lists the type of operaons performed by the identy on the cloud resources. Hover over the
operaon to display the original operaon name as provided by the Cloud Provider.
Cloud Resource Node
Displays the referenced resource on which the operaon was performed. Cortex XDR displays
informaon on the following resources:
• —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 invesgate the resource:
1. Hover over a Resource node to display, if available, the resource Analycs Profiles and
Resource Editors stascs.
2. Select the Resource node to display in the Enty Data secon addional informaon about the
Resource enty.
Enty Data
Provides addional informaon about the enty that you selected. The data varies by the type of
enty but typically idenfies informaon about the enty related to the cause of the alert and the
Events Table
Displays up to 100,000 related events and up to 1,000 related alerts.
To connue invesgaon, in the Alerts table, you can perform the following acons from the
right-click pivot menu:
• Invesgate Causality Chain of the associated alert.
• Open in XQL to populate the event in an XQL search query that you can further refine, if
needed.
• Manage Alert to perform available acons.
• Pivot to views to view related incident.
In the All Events table, Cortex XDR displays detailed informaon about each of the related events.
To simplify your invesgaon, Cortex XDR scans your Cortex XDR data aggregang the events
that have the same Identy 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 connue
invesgaon, right-click to View in XQL.
Timeline View
The Timeline provides a forensic meline of the sequence of events, alerts, and informaonal
BIOCs and Correlaon Rules involved in an aack. While the Causality View of an alert surfaces
related events and processes that Cortex XDR idenfies as important or interesng, the Timeline
displays all related events, alerts, and informaonal BIOCs and Correlaon Rules over me.
Cortex XDR presents the Timeline in four parts:
CGO (and process Cortex XDR displays the Causality Group Owner (CGO) and the
instances that are part of host on which the CGO ran in the top le of the meline. The
the CGO) CGO is the parent process in the execuon chain that Cortex XDR
idenfied as being responsible for iniang 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 invesgaon and displays the start and end me of the
CGO at either end of the mescale. You can move the slide bar
to the le or right to focus on any me-gap within the mescale.
You can also use the me filters above the table to focus on set
me periods.
Acvity Depending on the type of acvies involved in the CI chain of

events, the acvity secon can present any of the following three
lanes across the page:
• Alerts—The alert icon indicates when the alert occurred.
• BIOCs and Correlaon Rules—The category of the alert
is displayed on the le (for example: tampering or lateral
movement). Each BIOC event also indicates a color associated
with the alert severity. An informaonal severity can indicate
something interesng has happened but there weren’t
any triggered alerts. These events are likely benign but are
byproducts of the actual issue.
• Event informaon—The event types include process execuon,
outgoing or incoming connecons, failed connecons,
data upload, and data download. Process execuon and
connecons are indicated by a dot. One dot indicates one
connecon while many dots indicates mulple connecons.
Uploads and Downloads are indicated by a bar graph that
shows the size of the upload and download.
The lanes depict when acvity occurred and provide addional
stascs that can help you invesgate. For BIOC, Correlaon
Rules, and Alerts, the lanes also depict acvity nodes—highlighted
with their severity color: high (red), medium (yellow), low (blue), or
informaonal (gray)—and provide addional informaon about the
acvity when you hover over the node.
Related events, alerts, and Cortex XDR displays up to 100,000 alerts, BIOCs and Correlaon
informaonal BIOCs Rules (triggered and informaonal), and events. Click on a node in
the acvity area of the Timeline to filter the results you see here.
Similar to other pages in Cortex XDR, you can create filters to
search for specific events.
Analycs Alert View

The analycs alert view provides a detailed summary of the behavior that triggered an Analycs
or Analycs BIOC alert. This view also provides a visual depicon of the behavior and addional
informaon you can use to assess the alert. This includes the endpoint on which the acvity was
iniated, the user that performed the acon, the technique the analycs engine observed, and
acvity and interacons with other hosts inside or outside of your network.
When enabling the Identy Analycs, alerts associated with suspicious user acvity such as stolen
or misused credenals, lateral movement, credenal harvesng, or brute-force data are displayed
with a User node.
1. Context For Analycs alerts, the analycs view indicates the endpoint for
which the alert was raised.
For Analycs BIOC alerts, the Analycs view summarizes informaon
about the alert, including the source host name, IP address, the process
name on which the alert was raised, and the corresponding process ID.
2. Alert summary (Analycs alerts only) Describes the behavior that triggered the alert
and acvity impact.
3. Graphic summary Similar to the Causality View, the analycs view provides a graphic
representaon of the acvity that triggered the alert and an interacve
way to view the chain of behavior for an Analycs 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 selecng and
dragging it. To return the chain to its original posion and size, click
in the lower-right of the graph.

The acvity depicted in the graphic varies depending on the type of
alert:
• Analycs alerts—You can view a summary of the aggregated acvity
including the source host, the anomalous acvity, connecon count,
and the desnaon host. You can also select the host to view any
relevant profile informaon.
• Analycs BIOC alerts—You can view the specific event
behavior including the causality group owner that
iniated the acvity and related process nodes. To view
the summary of the specific event, you can select the
above the process node.

The following nodes display informaon unique to the Analycs Alert
View:
User node— Hover over to display the User Informaon and user
Analycs Profile data.
Mul-Event—Display in the Event Table all the event types associated

with the alert.
Right-click on the following nodes to view addional informaon:
• Device—Open in IP View
• Process—View Process Instances
• IP Address—Add to EDL
4. Alert descripon The alert descripon provides details and stascs related to the
acvity. Beneath the descripon, you can also view the alert name,
severity assigned to the alert, me of the acvity, alert tacc (category)
and type, and links to the MITRE summary of the aack tacc.
When selecng a User node, Identy User Details, such as Acve
Directory Group, Organizaonal Unit, and Role associated with the
user are displayed. If available, Login Details also appear.
5. Events table Displays events related to the alert.

User node—Displays the logins, hosts, alerts, and process execuons
associated with the user aggregated by the Identy Analycs 7
days prior to and aer the analycs alert mestamp. Right-click to
Invesgate Causality Chain and View in XQL the associated events.
Mul-Event—Displays the events associated with the alert according to
the type event type. Right-click to View in XQL and further Invesgate
with XQL the event details.
6. Response acons Acons you can take in response to an Analycs alert. These acons
can include isolang a host from the network, iniang 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.
Invesgate Endpoints
Endpoint invesgaon requires either a Cortex XDR Prevent or a Cortex XDR Pro per
Endpoint license.
• Acon Center
• View Details About an Endpoint
• Retrieve Files from an Endpoint
• Retrieve Support Logs from an Endpoint
• Scan an Endpoint for Malware
Acon Center
The Acon Center provides a central locaon from which you can track the progress of all
invesgaon, response, and maintenance acons performed on your Cortex XDR-protected
endpoints. The main All Acons tab of the Acon Center displays the most recent acons iniated
in your deployment. To narrow down the results, click Filter on the top right.
You can also jump to filtered Acon Center views for the following acons:
• Quaranne—View details about quaranned files on your endpoints. You can also switch to an
Aggregated by SHA256 view that collapses results per file and lists the affected endpoints in
the Scope field.
• Block List/Allow List—View files that are permied 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.
• Scripts Library—View Palo Alto Networks and administrator-uploaded scripts that you can run
on your endpoints.
• Isolaon—View the endpoints in your organizaon that have been isolated from the network.
For more informaon, refer to Isolate an Endpoint.
• External Dynamic List—View the list of IP addresses and domain names in your EDL. For more
informaon, refer to Manage External Dynamic Lists
• Endpoint Blocked IP Addresses—View remote IP addresses that the Cortex XDR agent
has automacally blocked from communicang with endpoints in your network. For more
informaon, refer to Add a New Malware Security Profile.
For acons that can take a while to complete, the Acon Center tracks the acon progress and
displays the acon status and current progress descripon for each stage. For example, aer
iniang an agent upgrade acon, Cortex XDR monitors all stages from the Pending request
unl the acon status is Completed. Throughout the acon lifeme, you can view the number of
endpoints on which the acon was successful and the number of endpoints on which the acon
failed. Aer a period of 90 days since the acon creaon, the acon is removed from Cortex XDR
and is no longer displayed in the Acon Center. You cannot delete acons manually from the
Acon Center.
The following table describes both the default and addional oponal fields that you can view
from the All Acons tab of the Acon Center and lists the fields in alphabecal order.
Field Descripon
Acon Type Type of acon iniated on the endpoint (for

example Agent Upgrade).
Created By The name of the user who iniated the acon.
Creaon Timestamp Date and me the acon was created.
Descripon Includes the acon scope of affected endpoints

and addional data relevant for each of the
specific acons, such as agent version, file path,
and file hash.
Expiraon Date Time the acon will expire. To set an expiraon

the acon must apply to one or more endpoints.
By default, Cortex XDR assigns a 7-day
expiraon limit to the following acons:
• Agent Uninstall
• Agent Upgrade
• Files Retrieval
• Isolate
• Cancel Endpoint Isolaon
Addional acons such as malware scans,
quaranne, and endpoint data retrieval are
assigned a 4-day expiraon limit.
Aer the expiraon limit, the status for any
remaining Pending acons on endpoints
change to Expired and these endpoints will
not perform the acon.
Status The status the acon is currently at:

• Pending—No endpoint has started to
perform the acon yet.
• In Progress—At least one endpoint has
started to perform the acon.
• Canceled—The acon was canceled before
any endpoint has started performing it.
Field Descripon
• Pending Abort—No endpoint has started to
perform the acon yet.
• Aborted—The acon was canceled for all
endpoints aer at least one endpoint has
started performing it.
• Expired—The acon expired before any
endpoint has started performing it.
• Completed with Paral Success—The
acon was completed on all endpoints.
However, some endpoints did not complete
it successfully. Depending on the acon type,
it may have failed, been canceled, expired, or
failed to retrieve all data.
• Completed Successfully—The acon was
completed successfully on all endpoints.
• Failed—The acon failed on all endpoints.
• Timeout—The acon med-out on all
endpoints.
Addional data—If addional details are available for an acon or for specific endpoints, you
can pivot (right-click) to the Addional data view. You can also export the addional data to a
TSV file. The page can include details in the following fields but varies depending on the type of
acon.
Endpoint Name Target host name of each endpoint for which an

acon was iniated.
IP Addresses IP address associated with the endpoint.
Status Status of the acon for the specific endpoint.
Acon Last Update Time at which the last status update occurred
for the acon.
Advanced Analysis For Retrieve alert data requests related to XDR

Alerts raised by exploit protecon modules,
Cortex XDR can analyze the memory state for
addional verdict verificaon. This field displays
the analysis progress and resulng verdict.
Acon Parameters Summary of the Acon including the alert name

and alert ID.
Addional Data | Malicious Files Addional data, if any is available, for the acon.
For malware scans, this field is tled Malicious
Field Descripon
Files and indicates the number of malicious files
idenfied during the scan.
Manage Endpoint Acons

There are two ways to iniate an endpoint acon: you can either Iniate an Endpoint Acon
from the Acon Center or iniate an acon when you View Details About an Endpoint. Then, to
monitor the progress and status of an endpoint acon, you can Monitor Endpoint Acons from
the Acon Center.
Initiate an Endpoint Action
You can create new administrave acons using the Acon Center wizard in three easy steps:
1. Select the acon type and configure its parameters.
2. Define the target agents for this acon.
3. Review and confirm the acon summary.
Go to Incident Response > Response > Acon Center > +New Acon.
STEP 2 | Select the acon you want to iniate and follow the required steps and parameters you need
to define for each acon.
Cortex XDR displays only the endpoints eligible for the acon you want to perform.
STEP 3 | Review the acon summary.

Cortex XDR will inform you if any of the agents in your acon scope will be skipped. Click
Done.
STEP 4 | Track your acon.

Track the new acon in the Acon Center. The acon status is updated according to the acon
progress, as listed in the table above.
Monitor Endpoint Actions

Go to Incident Response > Response > Acon Center.
STEP 2 | Select the relevant view.

Use the le-side menu on the Acon Center page to monitor the different acons according to
their type:
• All—Lists all the administrave acons that were created in your network, including me of
creaon, acon type and descripon, acon status, the name of the user who iniated the
acon, and the acon expiraon date, if it exists.
• Quaranne—Lists only acons iniated to quaranne files on endpoints, including the file
hash, file name, file path and scope of target agents included in this acon.
• Block List/Allow List—Lists only acons iniated to block or allow files, including file hash,
status and any exisng comments.
STEP 3 | Filter the results.

To further narrow the results, use the Filters menu on the top of the page.
STEP 4 | Take further acons.

Aer inspecng an acon log, you may want to take further acon. Right-click the acon and
select one of the following (where applicable):
• View addional data—Display more relevant details for the acon, such as file paths for
quaranned files or operang systems for agent upgrades.
For acons with Status, Failed or Completed with paral success, you can create an
upgrade acon to rerun the acon on endpoints that have not been completed successfully.
From the Acons table, select the failed/paral success endpoints, right-click and select
create upgrade acon. A new upgrade acon is added to the All Acons table for tracking.
• Cancel for Pending endpoints—Cancel the original acon for agents that are sll in Pending
status.
• Download output—Download a zip file with the files received from the endpoint for acons
such as file and data retrieval.
• Rerun—Launch the Create new acon wizard populated with the same details as the original
acon.
• Run on addional agents—Launch the acon wizard populated with the details as the
original acon except for the agents which you have to fill in.
• Restore—Restore quaranned files.
View Details About an Endpoint

The Endpoints > All Endpoints page provides a central locaon from which you can view and
manage the endpoints on which the Cortex XDR agent is installed. The right-click pivot menu that
is available for each endpoint displays the acons you can perform.
The following table describes the list of acons you can perform on your endpoints.
Field Acon
Endpoint Control • Open in interacve mode

• Perform Heartbeat
Field Acon
• Change Endpoint Alias
• Upgrade Agent Version
You cannot upgrade VDI endpoints.
• Retrieve Support File

• Set Endpoint Proxy
• Uninstall Agent
• Delete Endpoint
• Disable Capabilies (Live Terminal, Script Execuon, and File
Retrieval)
• Include / Exclude endpoints from auto upgrade
• Assign and Remove endpoint tags
Security Operaons • Retrieve Endpoint Files

• Iniate Malware Scan
• Abort Malware Scan
• Iniate Live Terminal
• Isolate Endpoint
•
Endpoint Data • View Incidents (in same tab or new tab)

• View Endpoint Policy
• View Acons
• View Endpoint Logs
the Endpoints table and lists. The table lists the fields in alphabecal order.
Field Descripon
Check box to select one or more endpoints on which to perform

acons.
Acve Directory Lists all Acve Directory Groups and Organizaonal Units to which the
user belongs.
Assigned Policy Policy assigned to the endpoint.
Auto Upgrade Status When Agent Auto Upgrades are enabled, indicates the acon status is
either:
Field Descripon
• In progress—Indicates that the Cortex XDR agent upgrade is in
progress on the endpoint.
• Up to date—Indicates that the current Cortex XDR agent version on
the endpoint is up to date.
• Failure—Indicates that the Cortex XDR agent upgrade failed aer
three retries.
• Not configured—Indicates that automac agent upgrades are not
configured for this endpoint.
• Pending—Indicates that the Cortex XDR agent version running
on the endpoint is not up to date, and the agent is waing for the
upgrade message from Cortex XDR.
• Not supported—Indicates this endpoint type does not support
automac agent upgrades. Relevant for VDI, TS, or Android
endpoints.
To include or exclude one or more endpoints from auto upgrade, right-
click and select Endpoint Control > <Exclude/Include> endpoints from
auto upgrade
Aer an endpoint is excluded, the Auto upgrade profile

configuraon will no longer be available.
If you exclude the endpoint from Auto Upgrade while the
Auto Upgrade Status is In progress status, the ongoing
upgrade will sll take place.
Cloud Info Displays IBM and Alibaba Cloud metadata reported by the endpoint.
Content Auto Update Indicates whether automac content updates are Enabled or Disabled
for the endpoint. See Agent Sengs profile.
Content Release Displays the me and date of when the current content version was
Timestamp released.
Content Rollout If you configured delayed content rollout, the number of days for delay
Delay (days) is displayed here. See Agent Sengs profile.
Content Status Displays the status of the content version on the relevant endpoint.
Cortex XDR aempts to contact an endpoint and check the content
version over a 7 day period. Aer this period Cortex XDR displays one
of the following statuses:
• Up to Date - The endpoint is running with the latest content version
• Waing for Update - Cortex XDR is in the process of updang the
new content version. Depending on your bandwidth and network
connecon, updang the content version may take me.
• Outdated - The endpoint is running on an outdated content version.
Field Descripon
• Offline - The endpoint is disconnected.
Content Status is calculated every 30 minutes, therefore,

there could be a delay of up to 30 minutes in displaying the
data.
Content Version Content update version used with the Cortex XDR agent.
Disabled Capabilies A list of the capabilies that were disabled on the endpoint. To disable
one or more capabilies, right-click the endpoint name and select
Endpoint Control > Disable Capabilies. Opons are:
• Live Terminal
• Script Execuon
• File Retrieval
You can disable these capabilies during the Cortex XDR agent
installaon on the endpoint or through Endpoint Administraon.
Disabling any of these acons is irreversible, so if you later want to
enable the acon on the endpoint, you must uninstall the Cortex XDR
agent and install a new package on the endpoint.
Domain Domain or workgroup to which the endpoint belongs, if applicable.
Only supported for Windows.
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 the endpoint
name, and select Change endpoint alias. The alias can contain any of
the following characters: a-Z, 0-9, !@#$%^&()-'{}~_.
Endpoint ID Unique ID assigned by Cortex XDR that idenfies the endpoint.
Endpoint Isolated Isolaon status, either:

• Isolated—The endpoint has been isolated from the network with
communicaon permied to only Cortex XDR and to any IP
addresses and processes included in the allow list.
• Not Isolated—Normal network communicaon is permied on the
endpoint.
• Pending Isolaon—The isolaon acon has reached the server and
is pending contact with the endpoint.
• Pending Isolaon Cancellaon—The cancel isolaon acon has
reached the server and is pending contact with the endpoint.
Field Descripon
Endpoint Name Hostname of the endpoint. If the agent enables Pro features, this field
also includes a PRO badge. For Anrdoid endpoints, the hostname
comprises the <firstname>—<lastname> of the registered user,
with a separang dash.
Endpoint Status Registraon status of the Cortex XDR agent on the endpoint:
• Connected—The Cortex XDR agent has checked in within 10
minutes for standard endpoints, and within 3 hours for mobile
endpoints.
• Connecon Lost—The Cortex XDR 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 Cortex XDR agent has checked in within the
defined inacvity 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 waing for user logon, aer which the Cortex XDR
agent consumes a license and starts enforcing protecon.
• Uninstalled—The Cortex XDR agent has been uninstalled from the
endpoint.
Endpoint Type Type of endpoint: Mobile, Server, or Workstaon.
Endpoint Version Versions of the Cortex XDR agent that runs on the endpoint.
First Seen Date and me the Cortex XDR 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 idenfier for the golden image.
Group Names Endpoint Groups to which the endpoint is a member, if applicable. See
Define Endpoint Groups.
Incompability Mode Cortex XDR agent incompability status, either:

• Agent Incompable—The Cortex XDR agent is incompable with
the environment and cannot recover.
• OS Incompable—The Cortex XDR agent is incompable with the
operang system.
When Cortex XDR agents are compable with the operang system
and environment, this field is blank.
Field Descripon
Isolaon Date Date and me of when the endpoint was Isolated. Displayed only for
endpoints in Isolated or Pending Isolaon Cancellaon status.
Install Date Date and me at which the agent was first installed on the endpoint.
Installaon Package Installaon package name used to install the Cortex XDR agent.
Installaon Type Type of installaon:

• Standard
• VDI
• Golden Image
• Temporary Session
IP Last known IPv4 or IPv6 address of the endpoint.
Is EDR Enabled Whether EDR data is enabled on the endpoint.
Last Content Update Displays the me and date when the agent last deployed a content
Time update.
Last Origin IP Represents the last IP address from which the Cortex XDR agent
connected.
Last Scan Date and me of the last malware scan on endpoint.
Last Seen Date and me 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 The IP address and port number of proxy that was last used for
communicaon between the agent and Cortex XDR.
Last Used Proxy Port Last proxy port used on endpoint.
Linux Operaon (Cortex XDR agent 7.7 and later for Linux) Displays the type of
Mode operaon mode your Linux endpoint is running by Cortex XDR agent.
The operaon modes available are; Kernel, User Space, or Kernel
Disabled.
MAC The endpoint MAC address that corresponds to the IP address.
Field Descripon
Network Locaon (Cortex XDR agent 7.1 and later for Windows and Cortex XDR agent
7.2 and later for macOS and Linux) Endpoint locaon is reported by
the Cortex XDR agent when you enable this capability in the Agent
Sengs profile:
• Internal
• External
• Not Supported—The Cortex XDR agent is running a prior agent
version that does not support network locaon reporng.
• Disabled—The Cortex XDR agent was unable to idenfy the
network locaon.
Operang System Name of operang system.
Operaonal Status Cortex XDR agent operaonal status:

• Protected—Indicates that the Cortex XDR agent is running as
configured and did not report any excepons to Cortex XDR.
• Parally protected—Indicates that the Cortex XDR agent reported
to Cortex XDR one or more excepons.
• Unprotected—Indicates the Cortex XDR agent was shut down.
OS Descripon Operang system version name.
OS Type Name of the operang system.
OS Version Operang system version number.
Plaorm Plaorm architecture.
Proxy IP address and port number of the configured proxy server.
Scan Status Malware scan status, either:

• None—No scan iniated
• Pending—Scan was iniated, waing for acon to reach endpoint.
• In Progress—Scan in process.
• Success—Scan completed.
• Pending Cancellaon—Scan was aborted, waing for acon to
reach endpoint.
• Canceled—Scan canceled.
• Error—Scan failed to run.
Tags Displays the tags associated with the endpoint.
Field Descripon
Tags created in the Cortex XDR agent are displayed with a shield icon.
Users User that was last logged into the endpoint. On Android endpoints,
the Cortex XDR app idenfies the user from the email prefix specified
during app acvaon.
Retrieve Files from an Endpoint

If during invesgaon you want to retrieve files from one or more endpoints, you can iniate a
files retrieval request from Cortex XDR.
For each files retrieval request, Cortex XDR supports up to:
• 20 files
• 500MB in total size
• 10 different endpoints
The request instructs the agent to locate the files on the endpoint and upload them to Cortex
XDR. The agent collects all requested files into one archive and includes a log in JSON format
containing addional status informaon. When the files are successfully uploaded, you can
download them from the Acon Center.
To retrieve files from one or more endpoints:
STEP 2 | Select Files Retrieval and click Next.
STEP 3 | Select the operang system and enter the paths for the files you want to retrieve, pressing
ADD aer each completed path.
You cannot define a path using environment variables on Mac and Linux endpoints.
STEP 5 | Select the target endpoints (up to 10) from which you want to retrieve files.
If needed, Filter the list of endpoints. For more informaon, refer to Filiter Page
Results.
To track the status of a files retrieval acon, return to the Acon Center. Cortex XDR retains
retrieved files for up to 30 days.
If at any me you need to cancel the acon, you can right-click it and select Cancel for pending
endpoint. You can cancel the retrieval acon only if the endpoint is sll in Pending status and
no files have been retrieved from it yet. The cancellaon does not affect endpoints that are
already in the process of retrieving files.
STEP 8 | To view addional data and download the retrieved files, right-click the acon and select
Addional data.
This view displays all endpoints from which files are being retrieved, including their IP Address,
Status, and Addional Data such as error messages of names of files that were not retrieved.
STEP 9 | When the acon status is Completed Successfully, you can right-click the acon and
download the retrieved files logs.
Cortex XDR retains retrieved files for up to 30 days.
Disable File Retrieval

If you want to prevent Cortex XDR from retrieving files from an endpoint running the Cortex XDR
agent, you can disable this capability during agent installaon or later on through Cortex XDR
Endpoint Administraon. Disabling script execuon is irreversible. If you later want to re-enable
this capability on the endpoint, you must re-install the Cortex XDR agent. See the Cortex XDR
agent administrator’s guide for more informaon.
Disabling File Retrieval does not take effect on file retrieval acons that are in progress.
Retrieve Support Logs from an Endpoint

When you need to invesgate or share addional forensic data, you can iniate a request to
retrieve all support logs and alert data dump files from an endpoint. Aer Cortex XDR receives the
logs, you can select to either download the log files or generate a secured link to access them on
the Cortex XDR server.
STEP 1 | Retrieve support files.
You can retrieve support files either from the All Endpoints table or Acon Center.
• All Endpoints
1. Navigate to Endpoints > All Endpoints.
2. Locate one or more endpoints, right-click and select Endpoint Control > Retrieve
Support File.
• Acon Center
1. Navigate to Incident Response > Response > Acon Center > + New Acon.
2. Select Retrieve Support File followed by Next.
3. Select the target endpoints (up to 10) from which you want to retrieve logs followed by
Next.
4. Review the acon summary and click Done when finished.
In the next heart beat, the agent will retrieve the request to package and send all logs to
Cortex XDR.
STEP 2 | Navigate back to the Acon Center, locate your Support File Retrieval acon type and wait
for the Status field to display Completed Successfully.
If at any me you need to cancel the acon, you can right-click it and select Cancel for pending
endpoint. You can cancel the retrieval acon only if the endpoint is sll in Pending status and
no files have been retrieved from it yet. The cancellaon does not affect endpoints that are
already in the process of retrieving files.
STEP 3 | When the status is Completed Successfully, right-click and select Addional data.
In the Acons table, you can see the endpoints from which support files were retrieved.
STEP 4 | Select an endpoint, right-click and select to either Download files or Generate support file
link.
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 iniate a new support file link.
Scan an Endpoint for Malware

In addion to blocking the execuon of malware, the Cortex XDR agent can scan your Windows
and Mac endpoints and aached removable drives for dormant malware that is not acvely
aempng to run. The Cortex XDR agent examines the files on the endpoint according to the
Malware security profile that is in effect on the endpoint (quaranne sengs, unknown file
upload, etc.) When a malicious file is detected during the scan, the Cortex XDR agent reports the
malware to Cortex XDR so you can manually take addional acon to remove the malware before
it is triggered and aempts to harm the endpoint.
You can scan the endpoint in the following ways:
• System scan—Iniate a full scan on demand from Endpoints Administraon for an endpoint. To
iniate a system scan, see Iniate a Full Scan from CortexIniate a Full Scan from Cortex.
.
• Periodic scan—Configure periodic full scans that run on the endpoint as part of the malware
security profile. To configure periodic scans, see Add a New Malware Security Profile.
• Custom scan—(Windows, requires a Cortex XDR agent 7.1 or later release) The end user can
iniate a scan on demand to examine a specific file or folder. For more informaon, see the
Cortex XDR agent administrator’s guide for Windows.
Iniate a Full Scan from Cortex

You can iniate full scans of one or more endpoints from either All Endpoints table or the Acon
Center. Aer iniang a scan, you can monitor the progress from Incident Response > Response
> Acon Center. From both locaons, you can also abort an in-progress scan. The me a scan
takes to complete depends on the number of endpoints, connecvity to those endpoints, and the
number of files for which Cortex XDR needs to obtain verdicts.
To iniate a scan from Cortex XDR:

Select Incident Response > Response > Acon Center > +New Acon.
STEP 2 | Select Malware Scan.
STEP 4 | Select the target endpoints (up to 100) on which you want to scan for malware.
Scanning is available on Windows and Mac endpoints only. Cortex XDR automacally filters
out any endpoints for which scanning is not supported. Scanning is also not available for
inacve endpoints.
If needed, Filter the list of endpoints by aribute or group name.
Cortex XDR iniates the acon at the next heart beat and sends the request to the agent to
iniate a malware scan.
STEP 7 | To track the status of a scan, return to the Acon Center.

When the status is Completed Successfully, you can view the scan results.
STEP 8 | View the scan results.

Aer a Cortex XDR agent completes a scan, it reports the results to Cortex XDR.
To view the scan results for a specific endpoint:
1. On Acon Center, when the scan status is complete, right-click the scan acon and
select Addional data.
Cortex XDR displays addional details about the endpoint.
2. 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.
Invesgate Files
• Manage File Execuon
• Manage Quaranned Files
• Review WildFire® Analysis Details
• Import File Hash Excepons
Manage File Execuon

You can manage file execuon on your endpoints by using file hashes that are included in your
allow and block lists. If you trust a certain file and know it to be benign, you can add the file hash
to the allow list and allow it to be executed on all your endpoints regardless of the WildFire®
or local analysis verdict. Similarly, if you want to always block a file from running on any of your
endpoints, you can add the associated hash to the block list.
Adding files to the block list or allow list takes precedence of any other policy rules that may have
otherwise been applied to these files. In the Acon Center in Cortex XDR, you can monitor block
list and allow list acons performed in your networks and add/remove file from these lists.
Supported file types are:
Operang System Supported File Types
Windows • PE, PE64

• doc, docx, xls, xlsx (only if they contain macro files)
Mac macho, DMG
Linux ELF

STEP 2 | Select either Add to Block List or Add to Allow List.
STEP 3 | Enter the SHA-256 hash of the file and click .

You can add up to 100 file hashes at once. You can add a comment that will be added to all the
hashes you added in this acon.
STEP 5 | Review the summary and click Done.

In the next heart beat, the agent will retrieve the updated lists from Cortex XDR.
STEP 6 | You are automacally redirected to the Block List or Allow List that corresponds to the
acon in the Acon Center.
STEP 7 | To manage the file hashes on the Block List or the Allow List, right-click the file and select
one of the following:
• Disable—The file hash remains on the list but will not be applied on your Cortex XDR
agents.
• Move to Block List or Move to Allow List—Removes this file hash from the current list and
adds it to the opposite one.
• Edit Incident ID—Select to either Link to exisng incident or Remove incident link.
• Edit Comment—Enter a comment.
• Delete—Delete the file hash from the list altogether, meaning this file hash will no longer be
applied to your endpoints.
• Open in VirusTotal—Directs you to the VirusTotal analysis of this hash.
• (Cortex XDR Pro License only) Open Hash View—Pivot the hash view of the hash.
• Open in Quick Launcher—Open the quick launcher search results for the hash.
Manage Quaranned Files

When the Cortex XDR agent detects malware on a Windows endpoint, you can take addional
precauons to quaranne the file. When the Cortex XDR agent quarannes malware, it moves the
file from the locaon on a local or removable drive to a local quaranne folder (%PROGRAMDATA
%\Cyvera\Quarantine) where it isolates the file. This prevents the file from aempng to run
again from the same path or causing any harm to your endpoints.
To evaluate whether an executable file is considered malicious, the Cortex XDR agent calculates a
verdict using informaon from the following sources in order of priority:
• Hash excepon policy
• WildFire threat intelligence
• Local analysis
Quaranning a file in Cortex XDR can be done in one of two ways:
• Enable the Cortex XDR agent to automacally quaranne malicious executables by configuring
quaranne sengs in the Malware security profile.
• Right-click a specific file from the causality card and select Quaranne.
STEP 1 | View the quaranned files in your network.
Navigate to Incident Response > Response > Acon Center > File Quaranne. Toggle between
DETAILED and AGGREGATED BY SHA256 views to display informaon on your quaranned
files.
STEP 2 | Review details about quaranned files.

In the Detailed view, filter and review the Endpoint Name, Domain, File Path, Quaranne
Source, and Quaranne Date of the all the quaranned files.
• Right-click one or more rows and select Restore all files by SHA256 to reinstate the
selected files.
This will restore all files with the same hash on all of your endpoints.
• In the Hash field, right-click to:

• Open in VirusTotal—Review the quaranned file inspecon results on VirusTotal. You will
be redirected in a new browser tab to the VirusTotal site and view all analysis details on
the selected quaranned file.
• Open Hash View—Drill down on each of the process execuons, file operaons,
• Open in Quick Launcher—Search for where the hash value appears in CortexXDR.
• Export to file a detailed list of the quaranned hashes in a TSV format.
In the Aggregated by SHA256 view, filter and review the Hash, File Name, File Path, and
Scope of all the quaranned files.
• Right-click a row and select Addional Data to open the Quaranne Details page detailing
the Endpoint Name, Domain, File Path, Quaranne Source, and Quaranne Date of a
specific file hash.
• Right-click and select Restore to reinstate one or more of the selected file hashes.
• Right-click and select Delete all files by SHA256 to permanently delete quaranned files on
the endpoint.
• In the Hash field, right-click to:
• Open in VirusTotal—Review the quaranned file inspecon results on VirusTotal. You will
be redirected in a new browser tab to the VirusTotal site and view all analysis details on
the selected quaranned file.
• Open Hash View—Drill down on each of the process execuons, file operaons,
• Open in Quick Launcher—Search for where the hash value appears in Cortex XDR.
Review WildFire® Analysis Details

For each file, Cortex XDR receives a file verdict and the WildFire Analysis Report. This report
contains the detailed sample informaon 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 the WildFire Analysis Details.

WildFire analysis details are available for files that receive a WildFire verdict. The Analysis
Reports secon includes the WildFire analysis for each tesng environment based on the
observed behavior for the file.
1. Open the WildFire report.
If you are analyzing an incident, right-click the incident and View Incident. From the Key
Arfacts involved in the incident, select the file for which you want to view the WildFire
report and open ( ). Alternavely, if you are analyzing an alert, right-click the alert and
Analyze. You can open ( ) the WildFire report of any file included in the alert Causality
Chain.
Cortex XDR displays the preview of WildFire reports that were generated within
the last couple of years only. To view a report that was generated more than two
years ago, you can Download the WildFire report.
2. Analyze the WildFire report.
On the le 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 stac analysis is performed on the file. Select the tesng environment on
the le, for example Windows 7 x64 SP1, to review the summary and addional details
for that tesng environment. To learn more about the behavior summary, see WildFire
Analysis Reports—Close Up.
3. (Oponal) 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 Palo Alto
Networks to request the verdict change.
1. Review the report informaon and verify the verdict that you are reporng.
2. Report ( ) the verdict to Palo Alto Networks.
3. Suggest a different Verdict for the hash.
4. Enter any details that may help us to beer understand why you disagree with the
verdict.
5. Enter an email address to receive an email noficaon aer Palo Alto Networks
completes the addional analysis.
6. Aer you enter all the details, click OK.
From this point on, the threat team will perform further analysis on the sample to
determine if it should be reclassified. If a malware sample is determined to be safe, the
signature for the file is disabled in an upcoming anvirus signature update or if a benign
file is determined to be malicious, a new signature is generated. Aer the invesgaon is
complete, you will receive an email describing the acon that was taken.
Import File Hash Excepons

The Acon Center page displays informaon on files quaranned and included in the allow list and
block list. To import hashes from the Endpoint Security Manager or from external feeds, you can
iniate an acon.
STEP 1 | From Cortex XDR, select Incident Response > Response > Acon Center > + New Acon
STEP 2 | Select Import Hash Excepons.
STEP 3 | Drag your Verdict_Override_Exports.csv file to the drop area.

If necessary, resolve any conflicts encountered during the upload and retry.
STEP 4 | Click Next twice.
STEP 5 | Review the acon summary, and click Done.

Cortex XDR imports and then distributes your hashes to the allow list and block list based on
the assigned verdict.
Forensic Data Analysis

The Cortex XDR Forensics end-to-end soluon streamlines your incident response, data
collecon, threat hunng, and analyses of your endpoint. By acvang the Forensics add-on,
Cortex XDR enables you to find the source and scope of an aack, and to determine what, if any,
data was accessed.
The following are prerequisites to acvate Forensics Data Analysis for your Cortex XDR instance:

• Forensics Add-on.
Supported Plaorms • Cortex XDR agent 7.4 or later for Windows

endpoints.
Setup and Permissions • Ensure Monitor and Collect Forensics Data is

enabled for your Cortex XDR agent.
The Cortex XDR Forensics page displays the following enes where you can perform a deep dive
into a single endpoint or search for arfacts across all your endpoints. For advanced detecve
work, you can use the XQL Search feature to query across all data, including endpoint, network,
cloud, and identy data, using the applicable dataset. Datasets and Presets contains a list of all
datasets included with the Forensics add-on.
Enty Descripon
Searches Displays details of forensic searches run by

users or as part of a Search Collecon.
Search Collecons Displays the collecons of forensic searches

saved under a collecon name.
Tagged Items Displays the list of forensic arfacts that were

tagged.
Tags offer you a way to label a parcular row
of data using a word or phrase that idenfies
its relevance to your invesgaon.
Host Timelines Displays a list of normalized, per-host

melines that include mulple forensic
arfacts in a single table.
Process Execuon Displays details of process execuons.
Process Execuon Arfacts Displays details of the following type of

process execuon arfacts:
• Amcache—A registry hive used by the
Applicaon Compability Infrastructure to
cache the details of executed or installed
programs.
• Applicaon Resource Usage —A table in
the System Resource Usage database that
stores stascs pertaining to resource
usage by running applicaons.
• Background Acvity Monitor—Per-user
registry keys created by Background
Acvity Monitor (BAM) service to store
the full paths of executable files and a
mestamp, indicang when they were last
executed.
• CidSizeMRU—A registry key containing a
list of recently launched applicaons.
• LastVisitedPidMRU—A registry key
containing a list of the applicaons
and folder paths associated with
recently opened files found in the user’s
OpenSavePidMRU key.
• Prefetch—A type of file created to opmize
applicaon startup in Windows. These files
contains a run count for each applicaon,
between one and eight mestamps of the
most recent execuons, and a record of all
of the files opened for a set duraon aer
the applicaon was started.
• Recentfilecache—A cache created by the
store the details of executed or installed
programs (Windows 7 only).
• Shimcache—A registry key used by the
cache details about local executables.
• UserAssist—A registry value that records
a count for each applicaon that a user
launches via the Windows UI.
• Windows Acvies—A database containing
user acvity for a parcular Microso
user account, potenally across mulple
devices. This is also called the Windows
Timeline.
File Access Displays details of file access arfacts.
File Access Arfacts Displays details of the following type of file

access arfacts:
• 7-Zip Folder History—A registry key
containing a list of archive files accessed
using 7-Zip.
• 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.
• Jumplist—A feature of the Windows Task
bar that provides shortcuts to users for
recently accessed files or applicaons.
• OpenSavePidiMRU—A registry key
containing a list of recently opened and
saved files for a user’s account.
• Recycle Bin—Folder used by Windows as
temporary storage for deleted files prior to
permanent deleon.
• ShellBags—Registry keys that record user
layout preferences for each folder with
which the user interacts.
• TypedPaths—A registry key containing a
list of paths that the user typed into the
Windows Explorer path bar.
• WinRARArcHistory—A registry key
containing a list of archive files accessed
using WinRAR.
• WordWheelQuery—Registry key containing
a list of terms that a user searched for in
Windows Explorer.
Persistence Displays details of the persistence arfacts.
Persistence Arfacts Displays details of the following type of

persistence arfacts:
• Drivers—Windows device drivers installed
on each endpoint.
• Registry—A collecon of registry keys that
can be used for malware persistence.
• Scheduled Tasks—Tasks used to execute
Windows programs or scripts at specified
intervals.
• Services—Windows applicaons that run
in the background and do not require user
interacon.
• Shim Databases—Databases used by the
apply shims to executables for backwards
compability. These databases can be used
to inject malicious code into legimate
processes and maintain persistence on an
endpoint.
• Startup Folder—Contents of the shortcut
.lnk files found in the StartUp folder for
both the system and users. The folders are
used to automacally launch applicaons
during system startup or user logon
processes.
• WMI—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.
Command History Displays details of the command history.
Command History Arfacts Displays details of the following type of

command history arfacts:
• PSReadline—A record of commands typed
into a PowerShell terminal by user. The
history file is only enabled by default,
starng with Powershell 5 on Windows 10
or newer.
Network Displays details of the network acvity.
Network Arfacts Displays details of the following type of

network arfacts:
• ARP Cache—A cache of Address Resoluon
Protocol (ARP) records for resolved MAC
and IP addresses.
• DNS Cache—A cache of Domain Name
System (DNS) records for resolved domains
and IP addresses.
• Hosts File—Full lisng of entries from the
etc/hosts file.
• Network Connecvity Usage—A table in
the System Resource Usage database that
stores stascs pertaining to network
connecons, containing the start me
and duraon of the connecons for each
network interface.
• Network Data Usage—A table in the
System Resource Usage database that
stores stascs pertaining to network data
usage for running applicaons. Includes
applicaon path, network interface, bytes
sent, and bytes received.
Remote Access Displays details of remote access soware.
Remote Access Arfacts Displays details of the following type of

remote access arfacts:
• LogMeIn—Records of acvity found in the
LogMeIn event logs.
• Team Viewer—Records of incoming
TeamViewer connecons found in the
Connecons_incoming.txt file.
• User Access Logging—A Windows Server
feature that records details about client
access to the server. Only found on
Windows Server 2012 and newer.
Triage Displays details of triage collecons.

Triage tables include:
• All—List of all files collected via Forensic
Triage and their current status.
• File—Full file lisngs for $MFT files
collected during Forensic Triage.
• Registry—Full registry lisngs for registry
hives collected during Forensic Triage.
• Event Logs—Full lisng of the events found
in the Windows event log (*.evtx) files.
• Browser History—Browser history from
Chrome, Edge, Firefox, and Internet
Explorer.
• Volale—Volale forensic arfacts
including: ARP Cache, DNS Cache,
Handles, Net Sessions, Port Lisng, and
Process Lisng.
• Configuraon—Custom Forensics Triage
configuraons created and saved for use in
online or offline triage collecons.
Forensics Add-on Opons

The Forensics page consolidates informaon collected by the Cortex XDR agent enabling you to
invesgate and take acon on your endpoints.
When adding Forensics, if you have Account Admin or Instance Admin permissions,
you can change your tenant subdomain from oldName.xdr.us.paloaltonetworks.com to
newName.xdr.us.paloaltonetworks.com. To change your tenant subdomain name, please open a
Palo Alto Networks support cket.
To review the following forensics data collected from your endpoints, in your Cortex XDR tenant,
navigate to Incident Response > Invesgaon > Forensics:
• Manage Forensics Searches
• Manage Tagged Items
• Manage Host Timelines
• Review Process Execuon
• Review File Access
• Review Persistence
• Review Command History
• Review Network
• Review Remote Access
• Review Triage
You can also use the Forensics add-on capabilies to iniate the following endpoint acons.
• Forensic File Search—Search for a file by path, size, or hash on your endpoint. Select to either
search ad-hoc or save the search to your search collecons.
• Registry Search—Search registry by paths. Select to either search ad-hoc or save the search to
your search collecons.
• Event Log Search—Search event logs by event IDs, channel, providers, and messages. Select to
either search ad-hoc or save the search to your search collecons.
Manage Forensics Searches

Invesgate details of forensic Searches run by users or as part of a Search Collecons. The table
displays the following fields.
Searches table display the following fields:
Field Descripon
Created Date and me of when the search was

created.
Created By User name of who created the search.
Hosts Searched Number of hosts searched.
Last Updated Date and me of the most recent search

result.
Name Name of the search.
Results Count Number of results found in the search.
Summary List of the search parameters.
Type Type of enty searched. For example, File,

Registry, Event Logs.
Search Collecons table displays the following fields:
Field Descripon
Created By User name of who created the search

collecon.
Descripon Descripon of the search collecon, if

available.
Last Updated Date and me of when the search collecon

was last modified. For example, searches were
added or removed.
Modified By User name of the who last modified the

search collecon.
Name Name of the search or Search Collecon.
Searches Number of searches in the search collecon.
The Search Collecons table includes the following collecons by default.

• Credenal Harvesng
• Persistence
• Suspicious Indicators
• Anvirus Events
• Powershell Events
• Network Events
• Sysmon Events
• Authencaon Events
STEP 1 | In the Search Collecons page, select Add Collecon to Create New Search Collecon.
1. Enter the Collecon Name and oponal Descripon.
2. In the Search table, select the searches you want to include in the search collecon.
Filter the table according to the table fields to narrow your rules.
3. Aer you have selected the rules you want to include in your collecon, Create Search
Collecon.
Review the search collecons you created.
STEP 2 | Right-click a search collecon to Edit, Delete, or Save as new.
Manage Tagged Items

The Tagged Items page allows you to view the list of forensic arfacts that were tagged. The tags
show details of the forensic data collected from the endpoints.
The Tagged Items table displays the following fields:
Field Descripon
Hostname Name of the host machine.
Timestamp Timestamp associated with the arfact.
Type Forensic arfact of which a tag was added.
Descripon Name of the mestamp field.
Tags There are three default tags to choose from.

• legimate
• malicious
• suspicious
You can also create your own tag.
User User account associated with the forensic

arfact.
Data Data summary for the tagged item.
Field Descripon
Mitre A&ck Tacc Displays the type of MITRE ATT&CK tacc of

the tagged item.
Mitre A&ck Technique Displays the type of MITRE ATT&CK

technique of the tagged item.
Notes Displays notes entered by the user.
STEP 1 | Edit a tag

You can edit a tag of an arfact in the Tagged Items table.
1. Locate the relevant item to update the tag.
2. Right-click and select Edit tags.
3. In Edit Tags, update the informaon as required and then click Save to update the
changes.
STEP 2 | Clear a tag

You can remove a tag from the arfact in the Tagged Items table.
1. Locate the relevant item to remove the tag.
2. Right-click and select Clear tags. The tag is removed from the arfact and the row is
removed from the Tagged Items table.
Manage Host Timelines

The Host Timelines page allows you to beer understand the order and ming of events that
occurred on your endpoints. The table contains a normalized meline of mulple forensic arfacts
from a given host enabling you to easily idenfy important acvity across mulple data types.
The Host Timelines table displays the following fields:
Field Descripon
Created By User name of who created the meline.
Endpoint ID Unique idenfied of the endpoint.
Hostname Name of the host.
ID Unique idenfier of the meline.
Ingested Date and me of when the meline ingeson

started.
Field Descripon
Method Whether the meline was generated

manually using the +Add Timelines feature or
automacally as the result of a triage acon.
Status Whether the meline is

In Progress or Completed collecng data from
the defined endpoints.
Triage Acon ID Unique idenfier for a Triage type seng.
STEP 1 | Create a Host Timeline.

You can create a host meline by either a Manual selecon of the endpoints or by ingesng
the endpoint Triage data.
• Manual
1. In the Host Timelines page, select Add Timelines to Create New Host Timelines.
2. Select the endpoints you want to include in your meline.
3. Aer you selected the endpoints you want included in the meline, Create Host
Timelines.
• Triage
1. Define the data you want collected from your endpoint by iniang a Forensics Triage
acon.
STEP 2 | Right-click a meline to view Addional data.

When selecng to view addional data, Cortex XDR displays detailed host related informaon
filtered according to the selected host name. To view more than one host at a me, select the
hosts, right-click and select View Host Timeline.
STEP 3 | Add a tag.

You can add a tag to a row of host meline.
1. Right-click a single or mulple rows, and select Addional Data > View in new tab or
Addional Data > View in same tab.
2. Right-click the filtered single or mulple rows, and select Add tags.
• If you select mulple rows, select the tag type or create your own and then click Save.
• If you select a single row, select the tag type or create your own, select the relevant
MITRE ATT&CK tacc or technique and enter notes if required.
3. Click Save.
STEP 4 | Edit a tag

You can edit a tag of a row of host meline.
1. Locate the relevant row to update the tag.
changes.

You can remove a tag from a row of host meline.
1. Locate the relevant row to remove the tag.
2. Right-click and select Clear tags. The tag is removed from the row.
Review Process Execuon

The Process Execuon table displays a normalized table containing an overview of all of the
different process execuon arfacts collected from the endpoints. Invesgate the following
detailed fields:
Field Descripon
Context Contextual detail relang to the executed

process such as files opened, command line
arguments, or process run count.
Descripon Descripon of the mestamp associated with

executable name.
Executable Name Name of the process executed.
Executable Path Path of the process executed.
Hostname Name of the host on which the process was

executed.
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 execuon.
Type Type of process arfact.
Field Descripon
User User name of who executed the process, if

available.
Verdict WildFire verdict for the following process

execuon arfacts.
• 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.
STEP 1 | Invesgate the process execuons.

Drill down to further invesgate the types of process arfacts Cortex XDR collected.
1. Navigate to Process Execuon Arfacts and select one the following tables to view
addional informaon:
• Amcache—A registry hive used by the Applicaon Compability Infrastructure to
cache the details of executed or installed programs.
• Applicaon Resource Usage —A table in the System Resource Usage database that
stores stascs pertaining to resource usage by running applicaons.
• Background Acvity Monitor—Per-user registry keys created by Background Acvity
Monitor (BAM) service to store the full paths of executable files and a mestamp,
indicang when they were last executed.
• CidSizeMRU—A registry key containing a list of recently launched applicaons.
• LastVisitedPidMRU—A registry key containing a list of the applicaons and folder
paths associated with recently opened files found in the user’s OpenSavePidMRU key.
• Prefetch—A type of file created to opmize applicaon startup in Windows. These
files contains a run count for each applicaon, between one and eight mestamps of
the most recent execuons, and a record of all of the files opened for a set duraon
aer the applicaon was started.
• Recentfilecache—A cache created by the Applicaon Compability Infrastructure to
store the details of executed or installed programs (Windows 7 only).
• Shimcache—A registry key used by the Applicaon Compability Infrastructure to
cache details about local executables.
• UserAssist—A registry value that records a count for each applicaon that a user
launches via the Windows UI.
• Windows Acvies—A database containing user acvity for a parcular Microso
user account, potenally across mulple devices. This is also called the Windows
Timeline.
STEP 2 | Add a tag.

You can add a tag to any of the rows in process execuon.
1. Right-click a single or mulple row, and select Add tags.
• If you select a single row, select the tag type or create your own, select any relevant
MITTRE ATT&CK taccs or techniques and enter notes if required.
2. Click Save.
STEP 3 | Edit a tag

You can edit a tag of any of the rows in process execuon.
changes.

You can remove a tag from any of the rows in process execuon.
Review File Access

The File Access table displays a normalized table containing an overview of all of the different file
access arfacts collected from the endpoints. Invesgate the following detailed fields:
Field Descripon

file or folder.
Field Descripon
Hostname Name of the host on which the file was

accessed.
Path Path of the accessed file or folder.
Timestamp Timestamp associated with the accessed file

or folder.
Type Type of file access arfact.
User User name of who accessed the file or folder,

if available.
STEP 1 | Invesgate the file access.

Drill down to further invesgate the types of file access arfacts Cortex XDR collected.
1. Navigate to File Access Arfacts and select one the following tables to view addional
informaon:
• 7-Zip Folder History—A registry key containing a list of archive files accessed using 7-
Zip.
• 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.
• Jumplist—A feature of the Windows Task bar that provides shortcuts to users for
recently accessed files or applicaons.
• OpenSavePidiMRU—A registry key containing a list of recently opened and saved files
for a user’s account.
• Recycle Bin—Folder used by Windows as temporary storage for deleted files prior to
permanent deleon.
• ShellBags—Registry keys that record user layout preferences for each folder with
which the user interacts.
• TypedPaths—A registry key containing a list of paths that the user typed into the
Windows Explorer path bar.
• WinRARArcHistory—A registry key containing a list of archive files accessed using
WinRAR.
• WordWheelQuery—Registry key containing a list of terms that a user searched for in
Windows Explorer.
STEP 2 | To triage an endpoint, locate the process execuon, right-click and select Triage endpoint.
STEP 3 | Add a tag.

You can add a tag to any of the rows in file access.
1. Right-click a single or mulple rows, and select Add tags.
• Right-click a single or mulple rows, and select Add tags.
2. Click Save.
STEP 4 | Edit a tag

You can edit a tag of any of the rows in file access.
changes.

You can remove a tag from any of the rows in file access.
Review Persistence
The Persistence table displays a normalized table containing an overview of all of the applicaon
persistence arfacts collected from the endpoints. Invesgate the following detailed fields:
You must have Host Insights add-on acvated in order to view the data.
Field Descripon
Command Command to be executed.

this row.
Endpoint ID Unique idenfied of the endpoint on which

the persistence mechanism resides.
File Path Path of the file associated with this

persistence mechanism.
File SHA256 SHA256 value of the file.
Hostname Name of the host on which the persistence

mechanism resides.
Field Descripon
Image Path Path of the image.
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

arfacts.
• 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.
STEP 1 | Invesgate persistence.

Drill down to further invesgate the types of persistence arfacts Cortex XDR collected.
1. Navigate to Persistence Arfacts and select one the following tables to view addional
informaon:
• Drivers—Windows device drivers installed on each endpoint.
• Registry—A collecon of registry keys that can be used for malware persistence.
• Scheduled Tasks—Scheduled tasks used to execute Windows programs or scripts at
specified intervals.
• Services—Windows applicaons that run in the background and do not require user
interacon.
• Shim Databases—Databases used by the Applicaon Compability Infrastructure
to apply shims to executables for backwards compability. These databases can be
used to inject malicious code into legimate processes and maintain persistence on an
endpoint.
• Startup Folder—Contents of the shortcut (.lnk) files found in the StartUp folder for
both the system and users. The folders are used to automacally launch applicaons
during system startup or user logon processes.
• WMI—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.
STEP 2 | Add a tag.

You can add a tag to any of the rows in persistence.
2. Click Save.
STEP 3 | Edit a tag

You can edit a tag of any of the rows in persistence arfacts.
changes.

You can remove a tag from any of the rows in persistence.
Review Command History

The Command History table displays an overview of the different types of command processes
that were executed on an endpoint. Invesgate the following detailed fields:
Field Descripon
Command Executed command.

this command history file.
Hostname Name of the host on which the command was

executed.
Line Line number where command was found in

history file.
Path Path of command history file.
Timestamp Timestamp associated with command history

file.
Type Type of command history arfact.
User User account associated with command

history file.
STEP 1 | Invesgate Command History.

Drill down to further invesgate the types of command history arfacts Cortex XDR collected.
1. Navigate to Command History Arfacts and select the following table to view addional
informaon:
• PSReadline—A record of commands typed into a PowerShell terminal by user. The
history file is only enabled by default, starng with Powershell 5 on Windows 10 or
newer.
STEP 2 | Add a tag.

You can add a tag to any of the rows in command history.
2. Click Save.
STEP 3 | Edit a tag

You can edit a tag of any of the rows in command history.
changes.

You can remove a tag from any of the rows in command history.
Review Network
The Network table displays an overview of the different types of network arfacts collected on
the endpoints. Invesgate the following detailed fields:
Field Descripon
Hostname Name of the host on which the network

acvity occurred.
Interface Type of network interface.
IP Address IP address associated with network acvity.
Resoluon Network data type associated with the IP

address.
Type Type of network arfact.
STEP 1 | Invesgate Network processes.

Drill down to further invesgate the types of network arfacts Cortex XDR collected.
1. Navigate to Network Arfacts and select one of the following table to view addional
informaon:
• ARP Cache—A cache of Address Resoluon Protocol (ARP) records for resolved MAC
and IP addresses.
• DNS Cache—A cache of Domain Name System (DNS) records for resolved domains
and IP addresses.
• Hosts File—Full lisng of entries from the etc/hosts file.
• Network Connecvity Usage—A table in the System Resource Usage database that
stores stascs pertaining to network connecons, containing the start me and
duraon of the connecons for each network interface.
• Network Data Usage—A table in the System Resource Usage database that stores
stascs pertaining to network data usage for running applicaons. Includes
applicaon path, network interface, bytes sent, and bytes received.
STEP 2 | Add a tag.
The following step is only relevant to.

• Network Data Usage
• Network Connecvity Usage
You can add a tag to the rows in network.

2. Click Save.
STEP 3 | Edit a tag

You can edit a tag of the rows in network.
changes.

You can remove a tag from the rows in network.
Review Remote Access

The Remote Access table displays a normalized table containing an overview of all of the remote
access arfacts collected from the endpoints. Invesgate the following detailed fields:
Field Descripon
Connecon ID Unique Idenfier associated with the

parcular remote access connecon found in
this row.
Connecon Type Type of remote access connecon.

this remote access connecon.
Duraon Duraon of remote access connecon.
Hostname Name of the host on which the remote access

occurred.
Message Descripon of acvity related to this remote

access collecon.
Source Host Originaon host of remote access connecon.
Timestamp Date and me of the remote access acvity.
Type Type of network arfact.
User User account associated with remote access

connecon.
STEP 1 | Invesgate remote access.

Drill down to further invesgate the types of remote access arfacts Cortex XDR collected.
1. Navigate to Remote Access Arfacts and select one of the following table to view
addional informaon:
• LogMeIn—Records of acvity found in the LogMeIn event logs.
• Team Viewer—Records of incoming TeamViewer connecons found in the
Connecons_incoming.txt file.
• User Access Logging—A Windows Server feature that records details about client
access to the server. Only found on Windows Server 2012 and newer.
STEP 2 | Add a tag.

You can add a tag to any of the rows in remote access.
2. Click Save.
STEP 3 | Edit a tag

You can edit a tag of any of the rows in remote access.
changes.

You can remove a tag from any of the rows in remote access.
Review Triage
The triage funconality in the Forensics add-on collects detailed system informaon, including a
full file lisng for all of the connected drives, full event logs, and registry hives, to provide you with
a complete, holisc picture of an endpoint.
The Triage table displays an overview of the different types of triage collecons that were
executed on an endpoint.
Drill down to further invesgate the following types of collecons:
• All—List of all files collected via Forensic Triage and their current status.
• File—Full file lisngs for $MFT files collected during Forensic Triage.
• Registry—Full registry lisngs for registry hives collected during Forensic Triage.
• Event Logs—Full lisng of the events found in the Windows event log (*.evtx) files.
• Browser History—Browser history from Chrome, Edge, Firefox, and Internet Explorer.
• Volale—Volale forensic arfacts including: ARP Cache, DNS Cache, Handles, Net Sessions,
Port Lisng, and Process Lisng.
• Configuraon—Custom Forensics Triage configuraons created and saved for use in online or
offline triage collecons.
STEP 1 | Add a tag.
The following step is only relevant to.

• File
• Registry
• Event Logs
• Browser History
You can add a tag to a row in the triage collecon.

1. Right-click a single or mulple rows, and select Addional Data > View in new tab or
Addional Data > View in same tab.
2. Right-click the filtered single or mulple rows, and select Add tags.
• If you select a single row, select the tag type or create your own, select the relevant
MITRE ATT&CK tacc or technique and enter notes if required.
3. Click Save.
STEP 2 | Edit a tag

You can edit a tag of a row in the triage collecon.
changes.

You can remove a tag from the row in the triage collecon
Response Acons
Aer or during the invesgaon of malicious acvity in your network, Cortex XDR offers various
response acons that enable you invesgate the endpoint and take immediate acon to remediate
it. For example, when you detect a compromised endpoint, you can isolate it from your network to
prevent it from communicang with any other internal or external device and thereby reducing an
aacker’s mobility on your network. The available response acons in Cortex XDR are:
• Iniate a Live Terminal Session
• Isolate an Endpoint
• Pause Endpoint Protecon
• Run Scripts on an Endpoint
• Remediate Changes from Malicious Acvity
• Search and Destroy Malicious Files
• Manage External Dynamic Lists
For response acons that rely on a Cortex XDR agent, the following table describes the supported
plaorms and minimal agent version. A dash (—) indicates the seng is not supported.
Iniate a Live Terminal X X X

Session
Cortex XDR agent Cortex XDR agent Cortex XDR agent
Iniates a remote 6.1 and later 7.0 and later 7.0 and later
connecon to an
endpoint allowing you
to invesgate and
respond to security
events on endpoints.
Using Live Terminal
you can navigate and
manage files in the file
system, manage acve
processes, and run the
operang system or
Python commands.
Isolate an Endpoint X X —
Halts all network access Cortex XDR agent Cortex XDR agent
on the endpoint except 6.0 and later 7.3 and later on
for traffic to Cortex macOS 10.15.4 and
XDR to prevent a later
compromised endpoint
from communicang

with any other internal
or external device.
Run Scripts on an X X X
Endpoint
Cortex XDR agent Cortex XDR agent Cortex XDR agent
Allows execung 7.1 and later 7.1 and later 7.1 and later
Python 3.7 scripts on
your endpoints directly
from Cortex XDR,
including pre-canned
scripts provided by
Cortex XDR or your
own Python scripts and
code snippets.
Remediate Changes X — —
from Malicious Acvity
Cortex XDR agent
Invesgates suspicious 7.2 and later
causality process chains
and incidents on your
endpoints, and displays
a list of suggested
acons to remediate
processes, files and
registry keys on your
endpoint that were
changed as a result of
malicious acvity.
Search and Destroy X X —

Malicious Files
Cortex XDR agent Cortex XDR agent
Searches for the 7.2 and later 7.3 and later on
presence of known and macOS 10.15.4 and
suspected malicious later
files on endpoints and
destroys the file from
endpoints where it
exists.
Response acons are not supported for Android endpoints.
Iniate a Live Terminal Session

To invesgate and respond to security events on endpoints, you can use the Live Terminal to
iniate a remote connecon to an endpoint. The Cortex XDR agent facilitates the connecon
using a remote procedure call. Live Terminal enables you to manage remote endpoints.
Invesgave and response acons that you can perform include the ability to navigate and
manage files in the file system, manage acve processes, and run the operang system or Python
commands.
Live Terminal is supported for endpoints that meet the following requirements:
Operang 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 acvity reported within the last 90 minutes (as
idenfied by the Last Seen me stamp in the endpoint details).
Mac • Cortex XDR agent 7.0 or a later release

• macOS 10.12 or a later release
Linux • Cortex XDR agent 7.0 or a later release

• Any Linux supported release
If the endpoint supports the necessary requirements, you can iniate a Live Terminal session from
the Endpoints page.
You can run PowerShell 5.0 or a later release on Live Terminal of Windows.
You can also iniate a Live Terminal as a response acon from a security event. If the endpoint is
inacve or does not meet the requirements, the opon is disabled.
Aer you terminate the Live Terminal session, you also have the opon to save a log of the
session acvity. All logged acons from the Live Terminal session are available for download as a
text file report when you close the live terminal session.
You can fine tune the Live Terminal session visibility on the endpoint by adjusng the User
Interface opons in your Agent Sengs Profile.
STEP 1 | Start the session.
From a security event or endpoint details, select Incident Response > Response > Live
Terminal. It can take the Cortex XDR agent a few minutes to facilitate the connecon.
STEP 2 | Use the Live Terminal to invesgate and take acon on the endpoint.
• Manage Processes
• Manage Files
• Run Operang System Commands
• Run Python Commands and Scripts
STEP 3 | When you are done, Disconnect the Live Terminal session.
You can oponally save a session report containing all acvity you performed during the
session.
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 the Live Terminal you can monitor processes running on the endpoint. The Task Manager
displays the task aributes, owner, and resources used. If you discover an anomalous process
while invesgang the cause of a security event, you can take immediate acon to terminate the
process or the whole process tree, and block processes from running.
STEP 1 | From the Live Terminal session, open the Task Manager to navigate the acve 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 malware, the row displays a red indicator and idenfies the file using a
malware aribute.
STEP 2 | To take acon on a process, right-click the process:

• Terminate process—Terminate the process or enre process tree.
• Suspend process—To stop an aack while invesgang the cause, you can suspend a
process or process tree without killing it enrely.
• Resume process—Resume a suspended process.
• Open in VirusTotal—VirusTotal aggregates known malware from anvirus products and
online scan engines. You can scan a file using the VirusTotal scan service to check for false
posives 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 invesgaon and
analysis. You can download files up to 200MB in size.
• Mark as Interesng—Add an Interesng tag to a process to easily locate the process in the
session report aer you end the session.
• Remove from Interesng—If no threats are found, you can remove the Interesng tag.
• Copy Value—Copy the cell value to your clipboard.
STEP 3 | Select Disconnect to end the Live Terminal session.

Choose whether to save the remote session report including files and tasks marked as
interesng. Administrator acons are not saved to the endpoint.
Manage Files
The File Explorer enables you to navigate the file system on the remote endpoint and take
remedial acon to:
• Create, manage (move or delete), and download files, folders, and drives, including connected
external drives and devices such as USB drives and CD-ROM.
Network drives are not supported.
• View file aributes, creaon and last modified dates, and the file owner.
• Invesgate files for malicious content.
To navigate and manage files on a remote endpoint:
STEP 1 | From the Live Terminal session, open the File Explorer to navigate the file system on the
endpoint.
STEP 2 | Navigate the file directory on the endpoint and manage files.
To locate a specific file, you can:
• Search for any filename rows on the screen from the search bar.
• Double click a folder to explore its contents.
STEP 3 | Perform basic management acons on a file.

• View file aributes
• Rename files and folders
• Export the table as a CSV file
• Move and delete files and folders
STEP 4 | Invesgate files for malware.

Right-click a file to take invesgave acon. You can take the following acons:
• Open in VirusTotal—VirusTotal aggregates known malware from anvirus products and
online scan engines. You can scan a file using the VirusTotal scan service to check for false
posives 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 invesgaon and
analysis. You can download files up to 200MB in size.
• Mark as Interesng—Add an Interesng tag to any file or directory to easily locate the file.
The files you tag are recorded in the session report to help you locate them aer you end
the session.
• Remove from Interesng—If no threats are found, you can remove the Interesng tag.
• Copy Value—Copies the cell value to your clipboard.
STEP 5 | Select Disconnect to end the live terminal session.

Choose whether to save the live terminal session report including files and tasks marked as
Run Operang System Commands

The Live Terminal provides a command-line interface from which you can run operang system
commands on a remote endpoint. Each command runs independently and is not persistent. To
chain mulple commands together so as to perform them in one acon, use && to join commands.
For example:
cd c:\windows\temp\ && <command1> && <command2>
On Windows endpoints, you cannot run GUI-based cmd commands like winver or
appwiz.cpl
STEP 1 | From the Live Terminal session, select Command Line.
STEP 2 | Run commands to manage the endpoint.

Examples include file management or launching batch files. You can enter or paste the
commands, or you can upload a script. Aer you are done, you can save the command session
output to a file.
Run Python Commands and Scripts

The Live Terminal provides a Python command line interface that you can use to run Python
commands and scripts.
The Python command interpreter uses Unix command syntax and supports Python 3 with
standard Python libraries. To issue Python commands or scripts on the endpoint, follow these
steps:
STEP 1 | From the Live Terminal session, select Python to start the python command interpreter on
the remote endpoint.
STEP 2 | Run Python commands or scripts as desired.

You can enter or paste the commands, or you can upload a script. Aer you are done, you can
save the command session output to a file.
Disable Live Terminal Sessions

If you want to prevent Cortex XDR from iniang Live Terminal remote sessions on an endpoint
running the Cortex XDR agent, you can disable this capability during agent installaon or later on
through Cortex XDR Endpoint Administraon. Disabling script execuon 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.
Isolate an Endpoint
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 communicang with other endpoints
thereby reducing an aacker’s mobility on your network. Aer the Cortex XDR agent receives
the instrucon to isolate the endpoint and carries out the acon, the Cortex XDR console shows
an Isolated check-in status. To ensure an endpoint remains in isolaon, agent upgrades are not
available for isolated endpoints.
Network isolaon is supported for endpoints that meet the following requirements:
Operang System Prerequisites
Windows • Cortex XDR agent 6.0 or a later release
Operang System Prerequisites

• (VDI) Network isolaon allow list in the Agent Sengs
Profile is configured to ensure VDI sessions remain
uniterrupted.
Mac • Cortex XDR agent 7.3 or a later release

• macOS 10.15.4 or a later release
• Cortex XDR Network extension is enabled on the endpoint.
Network isolaon on Mac endpoints does not terminate acve
connecons that were iniated before the Cortex XDR agent
was installed on the endpoint.
Linux • iptables and ip6tables

• Cortex XDR agent 7.7 or a later release
• Linux kernel with the following enabled:
• CONFIG_NETFILTER
• CONFIG_IP_NF_IPTABLES
• CONFIG_IP_NF_MATCH_OWNER
• Network isolaon allow list configured in the Agent Sengs
Profile
Network isolaon on Linux endpoints is based on the defined
IP addresses and ports.
STEP 1 | From Cortex XDR, iniate an acon to isolate an endpoint.

Go to Incident Response > Response > Acon Center > + New Acon and select Isolate.
You can also iniate the acon (for one or more endpoints) from the Isolaon page of the
Acon Center or from Endpoints > Endpoint Management > Endpoint Administraon.
STEP 2 | Select Isolate.
STEP 3 | Enter a Comment to provide addional background or other informaon that explains why
you isolated the endpoint.
Aer you isolate an endpoint, Cortex XDR will display the Isolaon Comment on the Acon
Center > Isolaon. If needed, you can edit the comment from the right-click pivot menu.
STEP 5 | Select the target endpoint that you want to isolate from your network.
If needed, Filter the list of endpoints. To learn how to use the Cortex XDR filters, refer
to Filter Page Results Filter Page Results.
In the next heart beat, the agent will receive the isolaon request from Cortex XDR.
STEP 8 | To track the status of an isolaon acon, select Incident Response > Response > Acon
Center > Currently Applied Acons > Endpoint Isolaon.
If aer iniang an isolaon acon, you want to cancel, right-click the acon and select
Cancel for pending endpoint. You can cancel the isolaon acon only if the endpoint is sll in
Pending status and has not been isolated yet.
STEP 9 | Aer you remediate the endpoint, cancel endpoint isolaon to resume normal
communicaon.
You can cancel isolaon from the Acons Center (Isolaon page) or from Endpoints > Endpoint
Management > Endpoint Administraon. From either place right-click the endpoint and select
Endpoint Control > Cancel Endpoint Isolaon.
Pause Endpoint Protecon

As of Cortex XDR agent 7.7 and above, you can pause the Cortex XDR agent protecon
capabilies on one or more endpoints while maintaining connecvity with the Cortex XDR
console. By only pausing the protecon and retaining connecvity, the Cortex XDR agent will run
with all the profiles disabled, but connue to send data and take acons from the server. Aer you
are ready, you can resume the endpoint protecon.
Pausing your endpoint protecon modules leaves your machines exposed to risks.
To pause one or more endpoint protecons:

STEP 1 | Navigate to Endpoints > All Endpoints.
STEP 2 | In the All Endpoints page, select the endpoints you want to pause protecon on, right-click
and select Endpoint Control > Pause Endpoint Protecon.
STEP 3 | Verify the endpoints, add an oponal comment that appears in the Management Audit log,
and Pause the protecon.
Endpoints that have been paused appear with a pause icon in the Endpoint Name field, and
depending on the acon progress, one of the following statuses in Manual Protecon Pause
field:
• Protecon Acve
• Pending Pause
• Protecon Paused
• Pending Acvaon
STEP 4 | When you are ready to resume protecon, select the endpoints, right-click and select
Endpoint Control > Resume Endpoint Protecon and Resume protecon on the listed
endpoints.
The All Endpoint table fields are updated accordingly.
STEP 5 | (Oponal) Track your pause and resume endpoint protecon acons.
Navigate to Incident Response > Response > Acon Center and locate Acon Type Pause
Endpoint Protecon or Resume Endpoint Protecon.
Remediate Changes from Malicious Acvity

When invesgang suspicious incidents and causality chains you oen need to restore and revert
changes made to your endpoints as result of a malicious acvity. To avoid manually searching
for the affected files and registry keys on your endpoints, you can request Cortex XDR for
remediaon suggesons.
Cortex XDR invesgates suspicious causality process chains and incidents on your endpoints
and displays a list of suggested acons to remediate processes, files and registry keys on your
endpoint.
To iniate remediaon suggesons, you must meet the following requirements:
• Cortex XDR Pro per Endpoint license
• An App Administrator, Privileged Responder, or Privileged Security Admin role permissions which
include the remediaon permissions
• EDR data collecon enabled
• Cortex XDR agent version 7.2 and above on Windows endpoints
STEP 1 | Iniate a remediaon analysis.
You can iniate a remediaon suggesons analysis from either of the following places:
• In the Incident View, navigate to Acons > Remediaon Suggesons.
Endpoints that are part of the incident view and do not meet the required criteria
are excluded from the remediaon analysis.
• In the Causality View, either:
• Right-click any process node involved in the causality chain and select Remediaon
Suggeson.
• Navigate to Acons > Remediaon Suggesons.
Analysis can take a few minutes. If desired, you can minimize the analysis pop-up while
navigang to other Cortex XDR pages.
STEP 2 | Review the remediaon suggeson summary and details.
Field Descripon
ORIGINAL EVENT DESCRIPTION Summary of the inial event that triggered the
malicious causality chain.
ORIGINAL EVENT TIMESTAMP Timestamp of the inial event that triggered the
malicious causality chain.
ENDPOINT NAME Hostname of the endpoint.
IP ADDRESS The IP address associated with the endpoint.
ENDPOINT STATUS Connecvity status of the endpoint. Can be either:

• Connected
• Disconnected
• Uninstalled
• Connecon lost
DOMAIN Domain or workgroup to which the endpoint belongs,

if applicable.
ENDPOINT ID Unique ID assigned by Cortex XDR that idenfies the

endpoint.
SUGGESTED REMEDIATION Acon suggested by the Cortex XDR remediaon

scan to apply to causality chain process:
Field Descripon
• Delete File
• Restore File
• Rename File
• Delete Registry Value
• Restore Registry Value
• Terminate Process—Available when selecng
Remediaon Suggesons for a node in the
Causality View.
• Terminate Causality—Terminate the enre causality
chain of processes that have been executed under
the process tree of the listed Causality Group
Owner (GCO) process name.
• Manual Remediaon—Requires you to take manual
acon to revert or restore.
SUGGESTED REMEDIATION Summary of the remediaon suggeson to apply to

DESCRIPTION the file or registry.
REMEDIATION STATUS Status of the applied remediaon:

• Pending
• In Progress
• Failed
• Completed Successfully
• Paral Success
REMEDIATION DATE Displays the mestamp of when all of the endpoint

arfacts were remediated. If missing a successful
remediaon, field will not display mestamp.
STEP 3 | Select one or more Original Event Descripons and right-click to Remediate.
STEP 4 | Track your remediaon process.

1. Navigate to Response > Acon Center > All Acons.
2. In the Acon Type field, locate your remediaon process.
3. Right-click Addional data to open the Detailed Results window.
Run Scripts on an Endpoint

For enhanced endpoint remediaon and endpoint management, you can run Python 3.7 scripts on
your endpoints directly from Cortex XDR. For commonly used acons, Cortex XDR provides pre-
canned scripts you can use out-of-the-box. You can also write and upload your own Python scripts
and code snippets into Cortex XDR for custom acons. Cortex XDR enables you to manage, run,
and track the script execuon on the endpoints, as well as store and display the execuon results
per endpoint.
The following are pre-requisites to execung scripts on your endpoints:
• Cortex XDR Pro Per Endpoint license
• Endpoints running the Cortex XDR agent 7.1 and later releases. Since the agent uses its built-
in capabilies and many available Python modules to execute the scripts, no addional 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 configuraon (required to upload a new script, run a snippet, and edit an exisng
script)
• Scripts (required to view the Scripts Library and the script execuon results)
Running snippets requires both Run High-risk scripts and Script configuraon
permissions. Addionally, all scripts are executed as System User on the endpoint.
Use the following work flow to start running scripts on your endpoints:
• Manage All Scripts in the Scripts Library
• Upload Your Scripts
• Run a Script on Your Endpoints
• Track Script Execuon and View Results
• Troubleshoot Script Execuon
• Disable Script Execuon
Manage All Scripts in the Scripts Library

All your scripts are available in the Acon Center > Scripts Library, including pre-canned scripts
provided by Palo Alto Networks and custom scripts that you uploaded. From the Scripts Library,
you can view the script code and meta data.
the Scripts Library per script. The fields are in alphabecal order.
Field Descripon
Compable OS The operang systems the script is compable

with.
Created By Name of the user who created the script. For

pre-canned scripts, the user name is Palo Alto
Networks.
Field Descripon
Descripon The script descripon is an oponal field that

can be filled-in when creang, uploading, or
eding a script.
Id Unique ID assigned by Cortex XDR that

idenfies the script.
Modificaon Date Last date and me in which the script or its
aributes were edited in Cortex XDR.
Name The script name is a mandatory filed that can be

filled-in when creang, uploading, or eding a
script.
Outcome • High-risk—Scripts that may potenally harm

the endpoint.
• Standard—Scripts that do not have a harmful
impact on the endpoint.
Script FileSHA256 The SHA256 of the code file.
From the Scripts Library, you can perform the following addional acons:
• Download script—To see exactly what the script does, right-click and Download the Python
code file locally.
• View / Download definions file—To view or download the script meta-data, right-click the
script and select the relevant opon.
• Run—To run the selected script, right-click and select Run. Cortex XDR redirects you to the
Acon Center with the details of this script already populang the new acon fields.
• Edit—To edit the script code or meta-data, right-click and Edit. This opon is not available for
pre-canned scripts provided by Palo Alto Networks.
By default, Palo Alto Networks provides you with a variety of pre-canned scripts that you can use
out-of-the-box. You can view the script, download the script code and meta-data, and duplicate
the script, however you cannot edit the code or definions of pre-canned scripts.
The following table lists the pre-canned scripts provided by Palo Alto Networks, in alphabecal
order. New pre-canned scripts are connuously uploaded into Cortex XDR though content
updates, and are labeled New for a period of three days.
Script name Descripon
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.
Script name Descripon
get_process_list List CPU and memory for all processes running

on the endpoint.
list_directories List all the directories under a specific path on

the endpoint, You can limit the number of levels
you want to list.
process_kill_cpu Set a minimum CPU value and kill all process on

the endpoint that are using higher CPU.
process_kill_mem Set a minimum RAM usage in bytes and kill all

process on the endpoint that are using higher
private memory.
process_kill_name Kill all processes by a given name.
*registry_delete Delete a Registry key or value on the endpoint.

(Windows)
*registry_get Retrieve a Registry value from the endpoint.

(Windows)
*registry_set Set a Registry value from the endpoint.

(Windows)
*Since all scripts are running under System context, you cannot perform any Registry
operaons on user-specific hives (HKEY_CURRENT_USER of a specific user).
Upload Your Scripts

You can write and upload addional scripts to the Scripts Library.
To upload a new script:
STEP 1 | From Acon Center > Scripts Library select +New Script.
Drag and drop your script file, or browse and select it. During the upload, Cortex XDR parses
your script to ensure you are using only Python modules supported by Cortex XDR. Click
Supported Modules if you want to view the supported modules list. If your script is using
unsupported Python modules, or if your script is not using proper indentaon, Cortex XDR will
require that you fix it. You can use the editor to update your script directly in Cortex XDR.
STEP 2 | Add meta-data to your script.

You can fill-in the fields manually, and also upload an exisng definions file in the supported
format to automacally fill-in some or all of the definion. To view the manifest format and
create your own, see Creang a Script Manifest.
• General—The general script definions include: name and descripon, risk categorizaon,
supported operang systems, and meout in seconds.
• Input—Set the starng execuon point of your script code. To execute the script line by
line, select Just run. Alternavely, to set a specific funcon in the code as the entry point,
select Run by entry point. Select the funcon from the list, and specify for each funcon
parameter its type.
• Output—If your script returns an output, Cortex XDR displays that informaon 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 automacally, select
Auto Detect.
• Diconary—If the script returns more than a single value, select Diconary from the
Output type list. By default, Cortex XDR displays in the script results table the diconary
value as is. To improve the script results table display and be able to filter according to
the returned value, you can assign a user friendly name and type to some or all of your
diconary keys, and Cortex XDR will use that in the results table instead.
To retrieve files from the endpoint, add to the diconary the files_to_get key to include
an array of paths from which files on the endpoint will be retrieved from the endpoint.
STEP 3 | When you are done, Create the new script.

The new script is uploaded to the Scripts Library.
Creating a Script Manifest

The script manifest file 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 validaon will fail and
you will be required to fix the file.
For the purpose of this example, we are showing each parameter in a new line. However,
when you create your file, you must remove any \n or \t characters.
This is an example of the manifest file structure and content:
{
"name":"script name",
"description":"script description",
"outcome":"High Risk|Standard",
"platform":"Windows,macOS,Linux",
"timeout":600,
"entry_point":"entry_point_name",
"entry_point_definition":{
"input_params":[
{"name":"registry_hkey","type":"string"},
{"name":"registry_key_path","type":"number"},
{"name":"registry_value","type":"number"}],
"output_params":{"type":"JSON","value":[
{"name":"output_auto_detect","friendly_name":"name1","type":"auto_detect"},
{"name":"output_boolean","friendly_name":"name2","type":"boolean"},
{"name":"output_number","friendly_name":"name3","type":"number},
{"name":"output_string","friendly_name":"name4","type":"string"},
{"name":"output_ip","friendly_name":"name5","type":"ip"}]
}
}
Always use lower case for variable names.
STEP 1 | Fill-in the script name and descripon.

You can use leers and digits. Avoid the use of special characters.
STEP 2 | Categorize the script.

If a script is potenally harmful, set it as High— Risk to limit the user roles that can run it.
Otherwise, set it as Standard.
STEP 3 | Assign the plaorm.

Enter the name of the operang system this script supports. The opons are Windows, macOS,
and Linux. If you need to define more than one, use a comma as a separator.
STEP 4 | Set the script meout.

Enter the number of seconds aer which Cortex XDR agent halts the script execuon on the
endpoint.
STEP 5 | Configure the script input and output.

To Run by entry point, you must specify the entry point name, and all input and output
definions.
The available parameter types are:
• auto_detect
• boolean
• number
• string
• ip
• number_list
• string_list
• ip_list
To set the script to Just run, leave both Entry_point and Entry_point_definitions
empty:
{
"name":"scrpit name",
"description":"script description",
"outcome":"High Risk|Standard",
"platform":"Windows,macOS,Linux",
"timeout":600,
"entry_point":"",
"entry_point_definition":{}
}
Run a Script on Your Endpoints

Follow this high-level workflow to run scripts on your endpoints that perform acons, or retrieve
files and data from the endpoint back to Cortex XDR.
STEP 1 | Iniate a new acon to run a script.
From Acon Center > +New Acon, select Run Script.
STEP 2 | Select an exisng script or add a code snippet.

1. To run an exisng script, start typing the script name or descripon in the search field,
or scroll down and select it from the list. Set the script meout in seconds and any other
script parameters, if they exist. Click Next
2. Alternavely, you can insert a Code Snippet. Unlike scripts, snippets are not saved in the
Cortex XDR Scripts Library and cannot receive input or output definions. Write you
snippet in the editor, fill-in the meout in seconds, and click Next
STEP 3 | Select the target endpoints.

Select the target endpoints on which to execute the script. When you’re done, click Next.
STEP 4 | Review the summary and run script.

Cortex XDR displays the summary of the script execuon acon. If all the details are correct,
Run the script and proceed to Track Script Execuon and View Results. Alternavely, to
track the script execuon progress on all endpoints and view the results in real-me, Run in
interacve mode.
Run Scripts in Interactive Mode

When you need to run several scripts on the same target scope of endpoints, or when you want
to view and inspect the results of those scripts immediately and interacvely, you can run your
scripts in Interacve Mode. You can also iniate interacve mode for an endpoint directly from
Endpoints Management. In this mode, Cortex XDR enables you to track the execuon progress
on all endpoints in real-me, run more scripts or code snippets as you go, and view the results of
these scripts all in one place.
In Interacve Mode, Cortex XDR displays general informaon that includes the scope of target
endpoints and a list of all the scripts that are being executed in this session. For each script on the
executed scripts list, you can view the following:
• The script name, date and me the script execuon acon was iniated, and a list of input
parameters.
• A progress bar that indicates in real-me the number of endpoints for which the script
execuon is In Progress, Failed, or Completed. When you hover over the progress bar, you
can drill-down for more informaon about the different sub-statuses included in each group.
Similarly, you can also view this informaon on the scripts list to the le in the form of a pie
chart that is dynamically updated per script as it is being executed.
Cortex XDR does not include disconnected endpoints in the visualizaon of the script
execuon progress bar or pie chart. If a disconnected endpoint later gets connected,
Cortex XDR will execute the script on that endpoint and the graphic indicators will
change accordingly to reflect the addional run and its status.
• Dynamic script results that are connuously updated throughout the script execuon progress.
Cortex XDR lists the results, and graphically aggregates results only if they have a small variety
of values. When both views are available, you can switch between them.
While in Interacve Mode, you can connuously execute more scripts and add code snippets that
will be immediately executed on the target endpoints scope. Cortex XDR logs all the scripts and
code snippets you execute in Interacve Mode, and you can later view them in the Acon Center.
To add another script, select the script from the Cortex XDR scripts library, or start typing a
Code Snippet. Set the script meout and input parameters as necessary, and Run when you
are done. The script is added to the executed scripts list and its runme data is immediately
displayed on screen.
Track Script Execuon and View Results

Aer you run a script, you see the script execuon acon in the Acon Center.
From the Acon Center, you can:
• Track Script Execuon Status

• Cancel or Abort Script Execuon
• View Script Execuon Results
• Open Script Interacve Mode
• Rerun a Script
Track Script Execution Status
All script execuon acons are logged in the Acon Center. The Status indicates the acon
progress, which includes the general acon status and the breakdown by endpoints included
in the acon. The following table lists the possible status of a script execuon acon for each
endpoint, in alphabecal order:
Status Descripon
Aborted The script execuon acon was aborted aer it

was already In Progress on the endpoint.
Canceled The script execuon acon was canceled from

Cortex XDR before the Cortex XDR agent pulled
the request from the server.
Completed Successfully The script was executed successfully on the

endpoint with no excepons.
Expired Script execuon acons expire aer four

days. Aer an acon expires, the status of any
remaining Pending acons on endpoints change
to Expired and these endpoints will not receive
the acon.
Failed A script can fail due to these reasons:

• The Cortex XDR agent failed to execute the
script.
• Excepons occurred during the script
execuon.
To understand why the script execuon failed,
see Troubleshoot Script Execuon.
In Progress The Cortex XDR agent pulled the script

execuon request.
Pending The Cortex XDR agent has not yet pulled the
script execuon request from the Cortex XDR
server.
Status Descripon
Pending Abort The Cortex XDR agent is in the process of

execung the script, and has not pulled the
abort request from the Cortex XDR server yet.
Timeout The script execuon reached its configured

me out and the Cortex XDR agent stopped the
execuon on the endpoint.
Cancel or Abort Script Execution

Depending on the current status of the script execuon acon on the target endpoints, you can
cancel or abort the acon for Pending and In Progress acons:
• When the script execuon acon is Pending, the Cortex XDR agent has not pulled the request
yet from Cortex XDR. When you cancel a pending acon, the Cortex XDR server pulls back the
pending request and updates the acon status as Canceled. To cancel the acon for all pending
endpoints, go to the Acon Center, right-click the acon and Cancel for pending endpoints.
Alternavely, to cancel a pending acon for specific endpoints only, go to Acon Center >
Addional data > Detailed Results, right-click the endpoint(s) and Cancel pending acon
• When the script execuon acon is In Progress, the Cortex XDR agent has begun running the
script on the endpoint. When you abort an in progress acon, the Cortex XDRR agent halts
the script execuon on the endpoint and updates the acon status as Aborted. To abort the
acon for all In Progress endpoints and cancel the acon for any Pending endpoints, go to the
Acon Center, right-click the acon and Abort and cancel execuon. Alternavely, to abort an
in progress acon for specific endpoints only, go to Acon Center > Addional data > Detailed
Results, right-click the endpoint(s) and Abort for endpoint in progress
View Script Execution Results
Cortex XDR logs all script execuon acons, including the script results and specific parameters
used in the run. To view the full details about the run, including returned values, right-click the
script and select Addional data.
The script results are divided into two secons. On the upper bar, Cortex XDR displays the script
meta-data that includes the script name and entry point, the script execuon acon status, the
parameter values used in this run and the target endpoints scope. You can also download the
exact code used in this run as a py file.
In the main view, Cortex XDR displays the script execuon results in two formats:
• Aggregated results—A visualizaon of the script results. Cortex XDR automacally 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 aggregaon. You can also
generate a PDF report of the aggregated results view.
• Main results view—A detailed table lisng all target endpoints and their details.
In addion the endpoint details (name, IP, domain, etc), the following table describes both
the default and addional oponal fields that you can view per endpoint. The fields are in
Field Descripon
*Returned values If your script returned values, the values are also
listed in the addional data table according to
your script output definions.
Execuon mestamp The date and me the Cortex XDR agent started
the script execuon on the endpoint. If the
execuon has not started yet, this field is empty.
Failed files The number of files the Cortex XDR agent failed
to retrieve from the endpoint.
Retenon date The date aer which the retrieved file will no
longer be available for download in Cortex XDR.
The value is 90 days from the execuon date.
Retrieved files The number of files the Cortex XDR successfully

retrieved from the endpoint.
Status See the list of statuses and their descripons in

Track Script Execuon Status.
Field Descripon
Standard output The returned stdout
For each endpoint, you can right-click and download the script stdout, download retrieved
files if there are any, and view returned excepons if there are any. You can also Export to file
to download the detailed results table in TSV format.
Open Script Interactive Mode
In Interacve Mode, Cortex XDR enables you to dynamically track the script execuon progress
on all target endpoints and view the results as they are being received in real-me. Addionally,
you can start execung more scripts on the same scope of target endpoints.
To iniate Interacve Mode for an already running script:
From the Acon Center, right-click the execuon acon of the relevant script and select Open
in interacve mode.
Rerun a Script
STEP 1 | From the Acon Center, right-click the script you want to rerun and select Rerun.
You are redirected to the final summary stage of the script execuon acon.
STEP 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 definions, navigate through the wizard
and make the necessary changes. Then, click Done. The script execuon acon is added to the
Acon Center
Troubleshoot Script Execuon

To understand why a script returned Failed execuon status, you can do the following:
1. Check script excepons—If the script generated excepons, you can view them to learn
why the script execuon failed. From the Acon Center, right click the Failed script and
select Addional data. In the Script Results table, right-click an endpoint for which the script
execuon failed and select View excepons. The Cortex XDR agent executes scripts on
Windows endpoints as a SYSTEM user, and on Mac and Linux endpoints as a root user. These
context differences could cause differences in behavior, for instance when using environment
variables.
2. Validate custom scripts—When a custom script you uploaded failed and the reason the script
failed is sll unclear from the excepons, or if the script did not generate any excepons, try
to idenfy whether it failed due to an error in Cortex XDR or due to an error in the script.
To idenfy the error source, execute the script without the Cortex XDR agent on the same
endpoint with regular Python 3.7 installaon. If the script execuon is unsuccessful, you should
fix your script. Otherwise, if the script was executed successfully with no errors, please contact
Palo Alto Networks support.
Disable Script Execuon

If you want prevent Cortex XDR from running scripts on a Cortex XDR agent, you can disable
this capability during agent installaon or later on through Cortex XDR Endpoint Administraon.
Disabling script execuon is irreversible. If you later want to re-enable this capability on the
endpoint, you must re-install the Cortex XDR agent. See the Cortex XDR Agent Administrator’s
Guide for more informaon.
Disabling Script Execuon does not take effect on scripts that are in progress.
Search and Destroy Malicious Files

To take immediate acon on known and suspected malicious files, you can search and destroy the
files from the Cortex XDR management console. Aer you idenfy the presence of a malicious
file, you can immediately destroy the file from any or all endpoints on which the file exists.
The Cortex XDR agent builds a local database on the endpoint with a list of all the files, including
their path, hash, and addional metadata. Depending on the number of files and disk size of each
endpoint, it can take a few days for Cortex XDR to complete the inial endpoint scan and to
populate the files database. You cannot search an endpoint unl the inial scan is complete and all
file hashes are calculated.
Aer the inial scan is complete and the Cortex XDRR agent retains a snapshot of the endpoint
files inventory, the agent maintains the files database by iniang periodic scans and closely
monitoring all acons performed on the files.
You can search for specific files according to the file hash, the file full path, or a paral path using
regex parameters from the Acon Center or the Query Builder. Aer you find the file, you can
quickly select it in the search results and destroy the file by hash or by path. You can also destroy a
file from the Acon Center, without performing a search, if you know the path or hash. When you
destroy a file by hash, all the file instances on the endpoint are removed.
You can validate a hash against VirusTotal and WildFire to provide addional context before
inializing the File Destroy acon.
The Cortex XDR agent does not include the following informaon in the local files
inventory.
• Informaon about files that existed on the endpoint and were deleted before the Cortex
XDR agent was installed.
• Informaon about files where the file size exceeds the maximum file size for hash
calculaons that is preconfigured in Cortex XDR.
• If the Agent Sengs Profile on the endpoint is configured to monitor common file
types only, then the local files inventory includes informaon 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:
Licenses and Add-ons • Provision an acve Cortex XDR Pro per

Endpoint license.
• Ensure the Host Insights Add-on is enabled on
your tenant.
Supported Plaorms • Windows—Cortex XDR agent 7.2 or a later

release. If you plan to enable Search and
Destroy on VDI sessions, you must perform
the inial scan on the Golden Image. For more
informaon, refer to Configure the Cortex
XDR Agent in a Non-Persistent VDI.
• Mac—Cortex XDR agent 7.3 or a later release
running on macOS 10.15.4 or a later release.
• Linux—Not supported.
Setup and Permissions • Ensure File Search and Destroy is enabled for
•
Search a File
You can search for files on the endpoint by file hash or file path. The search returns all instances of
this file on the endpoint. You can then immediately proceed to destroy all the file instances on the
endpoint, or upload the file to Cortex XDR for further invesgaon.
You can search for a file using the Query Builder or XQL Search or use the Acon Center wizard as
described in the following workflow.
STEP 1 | From the Acon Center select +New Acon > File Search.
STEP 2 | Configure the search method:

• To search by hash, enter the file SHA256 value. When you search by hash, you can also
search for deleted instances of this file on the endpoint.
• To search by path, enter the specific path for the file on the endpoint or specify the path
using wildcards. When you provide a paral path or paral file name using *, the search will
return all the results that match the paral expression. Note the following limitaons:
• 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.

Select the target endpoints on which you want to search for the file. Cortex XDR displays only
endpoints eligible for file search. When you’re done, click Next.
STEP 4 | Review the summary and iniate the search.

Cortex XDR displays the summary of the file search acon. If you need to change your sengs,
go Back. If all the details are correct, click Run. The File search acon is added to the Acon
Center.
STEP 5 | Review the search results.

In the Acon Center, you can monitor the acon progress in real-me and view the search
results for all target endpoints. For a detailed view of the results, right-click the acon and
select Addional data. Cortex XDR displays the search criteria, mestamp, and real-me status
of the acon 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 operang system) and details about the file instance
(such as full file name and path, hash values, and creaon and modificaon 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 operang
system), the search acon 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 me the
acon was updated).
If not all endpoints in the query scope are connected or the search has not completed, the
search acon remains in Pending status in the Acon Center.
STEP 6 | (Oponal) Destroy a file.

Aer you located the malicious file instances on all your endpoints, proceed to destroy all
the file instances on the endpoint. From the search results Addional data, right-click the file
to immediately Destroy by path, Destroy by hash, or Get file to upload it to Cortex XDR for
further examinaon.
Destroy a File
When you know a file is malicious, you can destroy all its instances on your endpoints directly
from Cortex XDR. You can destroy a file immediately from the File search acon result, or iniate
a new acon from the Acon 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, refer to Step 6 above.
• To destroy a file from the Acon Center wizard.
STEP 1 | From the Acon Center select +New Acon > Destroy File.
STEP 2 | To destroy by hash, provide the SHA25 of the file. To destroy by path, specify the exact file
path and file name. Click Next.

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.
STEP 4 | Review the summary and iniate the acon.

Cortex XDR displays the summary of the file destroy acon. If you need to change your
sengs, go Back. If all the details are correct, click Run. The File destroy acon is added to the
Acon Center.
Manage External Dynamic Lists

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 from the Cortex XDR
management console:
• IP Addresses EDL
• Domain Names EDL
To maintain an EDL in Cortex XDR, you must meet the following requirements:
• Cortex XDR Pro per TB or Cortex Pro per Endpoint license
• An App Administrator, Privileged Invesgator, or Privileged Security Admin role which include EDL
permissions
• Palo Alto Networks firewall running PAN-OS 9.0 or a later release
• Access to your Palo Alto Networks firewall configuraon
STEP 1 | Enable EDL.
1. Navigate to Sengs > Configuraons > Integraons > External Dynamic List
Integraons.
2. Enable External Dynamic List and enter the Username and Password that the Palo Alto
Networks firewall should use to access the Cortex XDR EDL.
STEP 2 | 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.
STEP 3 | Save the EDL configuraon.
STEP 4 | Enable the firewall to authencate the Cortex XDR EDL.

1. Download and save the following root cerficate: hps://certs.godaddy.com/repository/
gd-class2-root.crt.
2. On the firewall, select Device > Cerficate Management > Cerficates and Import the
cerficate. Make sure to give the device cerficate a descripve name, and select OK to
save the cerficate.
3. Select Device > Cerficate Management > Cerficate Profile and Add a new cerficate
profile.
4. Give the profile a descripve name and Add the cerficate to the profile.
5. Select OK to save the cerficate profile.
STEP 5 | Set the Cortex XDR EDL as the source for a firewall EDL.
For more detailed informaon 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.
1. On the firewall, select Objects > External Dynamic Lists and Add a new list.
2. Define the list Type as either IP List or Domain List.
3. Enter the IP Addresses Block List URL or the Domains Block List URL that you recorded
in the last step as the list Source.
4. Select the Cerficate Profile that you created in the last step.
5. Select Client Authencaon and enter the username and password that the firewall
must use to access the Cortex XDR EDL.
6. Use the Repeat field to define how frequently the firewall retrieves the latest list from
Cortex XDR.
7. Click OK to add the new EDL.
STEP 6 | 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.
1. Select Policies > Security and Add or edit a security policy rule.
2. In the Desnaon tab, select Desnaon Zone and select the external dynamic list as
the Desnaon Address.
3. Click OK to save the security policy rule and Commit your changes.
You do not need to perform addional commit or make any subsequent configuraon
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 Cortex XDR domain list as part of a URL Filtering profile
or as an object in a custom An-Spyware profile; when aached to a security
policy rule, a URL Filtering profile allows you to granularly control user access to
the domains on the list.
STEP 7 | 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 Acon Center or
throughout the Cortex XDRmanagement console.
Make sure EDL sizes don’t exceed your firewall model limit.
To add an IP address or Domain from the Acon Center, Iniate an Endpoint Acon to Add to
EDL. You can choose to enter the IP address or Domain you want to add Manually or choose
to Upload File.
During invesgaon, you can also Add to EDL from the Acons menu that is available from
invesgaon pages such as the Incidents View, Causality View, IP View, or Quick Launcher.
STEP 8 | At any me, you can view and make changes to the IP addresses and domain names lists.
1. Navigate to Incident Response > Response > Acon Center > Currently Applies Acons
> External Dynamic List.
2. Review your IP addresses and domain names lists.
3. If desired, select New Acon to add addional IP addresses and domain names.
4. 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.
Broker VM
> Broker VM Overview

> Set up the Broker VM
> Manage Your Broker VMs
> Broker VM Noficaons
497
Broker VM
Broker VM Overview
The Palo Alto Networks Broker is a secured virtual machine (VM), integrated with Cortex XDR,
that bridges your network and Cortex XDR. By seng up the broker, you establish a secure
connecon in which you can route your endpoints, and collect and forward logs and files for
analysis.
The Broker can be leveraged for running different services separately on the VM using the same
Palo Alto Networks authencaon. Once installed, the broker automacally receives updates and
enhancements from Cortex XDR, providing you with new capabilies without having to install a
new VM.
Broker VM
Per your Cortex XDR license, the following figure illustrates the different Broker VM features that
could be available on your organizaon side.
Broker VM
Broker VM
Set up Broker VM
The Palo Alto Networks Broker VM is a secured virtual machine (VM), integrated with Cortex
XDR, that bridges your network and the Cortex XDR app. By seng up the broker VM, you
establish a secure connecon 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 authencaon. Aer you complete the inial setup, the broker VM automacally
receives updates and enhancements from Cortex XDR, providing you with new capabilies
without having to install a new VM or manually update the exisng VM.
• Configure the Broker VM
• Acvate the Local Agent Sengs
• Acvate the Syslog Collector
• Acvate the Apache Kaa Collector
• Acvate the CSV Collector
• Acvate the Database Collector
• Acvate the Files and Folders Collector
• Acvate the FTP Collector
• Acvate the NetFlow Collector
• Acvate the Network Mapper
• Acvate Pathfinder
• Acvate the Windows Event Collector
Configure the Broker VM

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 acvate the available
applicaons. You can set up several broker VMs for the same tenant to support larger
environments. Ensure each environment matches the necessary requirements.
Before you set up the broker VM, verify you meet the following requirements:
Hardware: For standard installaon, use a minimum of a 4-core processor, 8GB RAM, and
512GB 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 512GB disk. Therefore, deploy the broker VM with
thin provisioning, meaning the hard disk can grow up to 512GB but will do so only if
needed.
Bandwidth is higher than 10mbit/s.
Broker VM
VM compable with:
Infrastructure Image Type Addional Requirements
Amazon Web Services (AWS) VMDK Create a Broker VM Amazon

Machine Image (AMI)
Google Cloud Plaorm VMDK Set up the Broker VM on

Google Cloud Plaorm (GCP)
Microso Azure VHD (Azure) Create a Broker VM Azure

Image
Microso Hyper-V 2012 VHD Hyper-V 2012 or later
Alibaba Cloud QCOW2 Create a Broker VM Image for

Alibaba Cloud
Nutanix Hypervisor QCOW2 Create a Broker VM Image for

a Nutanix Hypervisor
Nutanix AHV 2021
Ubuntu QCOW2 Create a Broker VM Image for

Ubuntu
Version 18.04
VMware ESXi OVA VMware ESXi 6.0 or later
Enable communicaon between the Broker Service, and other Palo Alto Networks services and
apps.
FQDN, Protocol, and Port Descripon
(Default) NTP server for clock synchronizaon between

the syslog collector and other apps and
• time.google.com
services. The broker VM provides default
• pool.ntp.org servers you can use, or you can define an
NTP server of your choice. If you remove
UDP port 123
the default servers, and do not specify a
replacement, the broker VM uses the me of
the host ESX.
br-<XDR Broker Service server depending on the region

of your deployment, such as us or eu.
HTTPS over TCP port 443
Broker VM
FQDN, Protocol, and Port Descripon
Informaon needed to communicate with

your Cortex XDR tenant. Used by tenants
deployed in all regions.
br-<xdr- Broker Service server for Federal (US

Government) deployment.
distributions-prod- Used by tenants with Federal (US

fed.traps.paloaltonetworks.com Government) deployment
Enable Access to Cortex XDR from the broker VM to allow communicaon between agents and
the Cortex XDR app.
If you use SSL decrypon in your firewalls, you need to add a trusted self-signed
cerficate authority on the broker VM to prevent any difficules with SSL decrypon.
If adding a CA cerficate to the broker is not possible, ensure that you’ve added the
Broker Service FQDNs to the SSL Decrypon Exclusion list on your firewalls.
Configure your broker VM as follows:
STEP 1 | In Cortex XDR, select Sengs > Configuraons > Data Broker > Broker VMs.
STEP 2 | Download and install the broker VM images for your corresponding infrastructure:
• Amazon Web Services (AWS)—Use the VMDK to Create a Broker VM Amazon Machine
Image (AMI).
• Google Cloud Plaorm—Use the VMDK image to Set up the Broker VM on Google Cloud
Plaorm (GCP).
• Microso Hyper-V 2012—Use the VHD image.
• Microso Azure—Use the VHD (Azure) image to Create a Broker VM Azure Image.
• Alibaba Cloud—Use the QCOW2 image to Create a Broker VM Image for Alibaba Cloud.
• Nutanix Hypervisor—Use the QCOW2 image to Create a Broker VM Image for a Nutanix
Hypervisor.
• Ubuntu—Use the QCOW2 image to Create a Broker VM Image for Ubuntu.
• VMware ESXi—Use the OVA image.
STEP 3 | Generate Token and copy to your clipboard.
The token is valid only for 24 hours. A new token is generated each me you select
Generate Token.
Broker VM
STEP 4 | Navigate to https://<broker_vm_ip_address>/.
When DHCP is not enabled in your network and you don’t have an IP address for
your broker VM, you need to configure the broker VM with a stac IP using the serial
console menu of the broker VM.
STEP 5 | Log in with the default password !nitialPassw0rd and then define your own unique
password.
The password must contain a minimum of eight characters, contain leers and
numbers, and at least one capital leer and one special character.
Broker VM
STEP 6 | Configure your broker VM sengs:

1. In the Network Interface secon, review the pre-configured Name, IP address, and MAC
Address, select the Address Allocaon: DHCP (default) or Stac, and select to either to
Disable or set as Admin the network address as the broker VM web interface.
• If you choose Stac, define the following and Save your configuraons:
• Stac IP address
• Netmask
• Default Gateway
• DNS Server
2. (Requires Broker VM 14.0.42 and later) (Oponal) 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:

• Formaed 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 will accept only
172.17.0.0/16.
3. (Oponal) Configure a Proxy Server address and other related details to route broker VM
communicaon.
• Select the proxy Type as HTTP, SOCKS4, or SOCKS5.
You can configure another broker VM as a Proxy Server for this broker
VM by selecng the HTTP type. When selecng HTTP to route broker VM
communicaon, you need to add the IP Address and Port number (set when
acvang the Agent Proxy) for the other broker VM registered in your tenant
that you want to designate as a proxy for this broker VM.
• Specify the proxy Address (IP or FQDN), Port, and an oponal User and Password.
Select the pencil icon to specify the password.
• Save your configuraons.
4. (Oponal) (Requires Broker VM 8.0 and later) Configure your NTP servers.
Specify the required server addresses using the FQDN or IP address of the server.
5. (Requires Broker VM 8.0 and later) (Oponal) In the SSH Access secon, Enable or
Disable SSH connecons to the broker VM. SSH access is authencated using a public
key, provided by the user. Using a public key grants remote access to colleagues and
Broker VM
Cortex XDR support who the private key. You must have Instance Administrator role
permissions to configure SSH access.
To enable connecon, generate an RSA Key Pair, enter the public key in the SSH Public
Key secon. Once one SSH public key is added, you can +Add Another. When you are
finished, Save your configuraon.
When using PuTTYgen to create your public and private key pairs, you need to copy
the public key generated in the Public key for pasng into OpenSSH authorized_keys
file box, and paste it in the broker VM SSH Public Key secon as explained above. This
public key is only available when the PuTTYgen console is open aer the public key is
generated. If you close the PuTTYgen console before pasng the public key, you will need
to generate a new public key.
6. (Requires Broker VM 10.1.9 and later) (Oponal) In the SSL Server Cerficate secon,
upload your signed server cerficate and key to establish a validated secure SSL
connecon between your endpoints and the broker VM. When you configure the server
cerficate and the key files in the Broker VM UI, Cortex XDR automacally updates them
in the tenant UI. Cortex XDR validates that the cerficate and key match, but does not
validate the Cerficate Authority (CA).
The Palo Alto Networks Broker supports only strong cipher SHA256-based
cerficates. MD5/SHA1-based cerficates are not supported.
7. In the Trusted CA Cerficate secon, upload your signed Cerficate Authority (CA)
cerficate or Cerficate Authority chain file in a PEM format. If you use SSL decrypon
in your firewalls, you need to add a trusted self-signed CA cerficate on the broker VM
to prevent any difficules with SSL decrypon. For example, when configuring Palo Alto
Networks NGFW to decrypt SSL using a self-signed cerficate, 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 cerficate to the broker is not possible, ensure that you’ve added
the Broker Service FQDNs to the SSL Decrypon Exclusion list on your firewalls.
See Enable Access to Cortex XDR.
8. (Requires Broker VM 8.0 and later) (Oponal) Collect and Generate New Logs. Your
Cortex XDR logs will download automacally aer approximately 30 seconds.
STEP 7 | Register and enter your unique Token, created in the Cortex XDR console.
Registraon of the Broker VM can take up to 30 seconds.
Aer a successful registraon, Cortex XDR displays a noficaon.

You are directed in Cortex XDR to Sengs > Configuraons > Data Broker > Broker VMs.
The Broker VMs page displays your broker VM details and allows you to edit the defined
configuraons.
Create a Broker VM Amazon Machine Image (AMI)

Aer you download your Cortex XDR Broker VMDK image, you can convert the image to Amazon
Web Services (AWS) AMI.
Broker VM
Be sure you set up an AWS VM Import role (vmimport) before you connue 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
informaon on seng up an AWS VM Import role and the permissions required, see Required
service role.
To convert the image.
Set up AWS CLI
(Oponal) If you haven’t done so already, set up your AWS CLI as follows:
STEP 1 | Install the AWS zip file by running the following command on your local machine:
curl "https://s3.amazonaws.com/aws-cli/awscli-bundle.zip" -o
"awscli-bundle.zip"unzip awscli-bundle.zipsudo /usr/local/bin/
python3.7 awscli-bundle/install -i /usr/local/aws -b /usr/local/
bin/aws
STEP 2 | Connect to your AWS account by running:
aws configure
Create an AMI Image
STEP 1 | Navigate and log in to your AWS account.
STEP 2 | In the AWS Console, navigate to Services > Storage > S3 > Buckets.
STEP 3 | In the S3 buckets page, + Create bucket to upload your broker image to.
STEP 4 | 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>
STEP 5 | Prepare a configuraon file on your hard drive.

For example:
[ { "Description":"<Broker VM Version>",
"Format":"vmdk", "UserBucket":{
"S3Bucket":"<your_bucket>", "S3Key":"<broker-vm-
version.vmdk>" } }]
Broker VM
STEP 6 | Create a AMI image from the VMDK file.

Run
aws ec2 import-image --description="<Broker VM Version>" --disk-

containers="file:///<file:///path/to/configuration.json>"
Creang 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", "..." } ]}
STEP 7 | (Oponal) Aer the AMI image has been created, you can define a new name for the image.
Navigate to Services > EC2 > IMAGES > AMIs and locate your AMI image using the task ID.
Select the pencil icon to enter a new name.
Launch an Instance
STEP 1 | Navigate to Services > EC2 > Instances.
STEP 2 | Search for your AMI image and Launch the file.
STEP 3 | In the Launch Instance Wizard define the instance according to your company requirements
and Launch.
STEP 4 | (Oponal) In the Instances page, locate your instance and use the pencil icon to rename the
instance Name.
Broker VM
STEP 5 | Define HTTPS and SSH access to your instance.

Right-click your instance and navigate to 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 troubleshoong. Make sure to allow these
connecon to the broker from secure networks only.
Assigning security groups can take up to 15 minutes.
STEP 6 | Verify the broker VM has started correctly.

Locate your instance, right-click and navigate to Instance Sengs > Get Instance Screenshot.
You are directed to your broker VM console lisng your broker details.
Create a Broker VM Azure Image

Aer you download your Cortex XDR Broker VHD (Azure) image, you need to upload it to Azure
as a storage blob.
To create the image:
STEP 1 | Decompress the downloaded VHD (Azure) image. Make sure you decompress the zipped
hard disk file on a server that has more then 512GB of free space.
Decompression can take up to a few hours.
Broker VM
STEP 2 | Create a new storage blob on your Azure account by uploading the VHD file. You can use to
upload either from Microso Windows or Ubuntu.
Uploading from Microso Windows.
1. Verify you have:
• Windows PowerShell version 5.1 or later.
• .NET Framework 4.7.2 or later.
2. Open PowerShell and execute Set-ExecutionPolicy unrestricted.
• [Net.ServicePointManager]::SecurityProtocol =
[Net.SecurityProtocolType]::Tls12
• Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201-
Force
3. Install azure cmdlets.
Install-Module -Name Az -AllowClobber
4. Connect to your Azure account.
Connect-AzAccount
5. Start the upload.
az storage blob upload -f <vhd to upload> -n <vhd name> -c
<container name> --account-name <account name>.
Upload can take up to a few hours.
Uploading from Ubuntu 18.04

1. Install Azure ul.
curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash
2. Connect to Azure.
az login
3. Start the upload.
az storage blob upload -f <vhd to upload> -n <vhd name> -c
<container name> --account-name <account name>
STEP 3 | In the Azure home page, navigate to Azure services > Disks and +Add a new disk.
Broker VM
STEP 4 | In the Create a managed disk > Basics page define the following informaon:
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. Addional field are displayed, define as follows:
• Source blob—Select Browse. You are directed to the Storage accounts page. From the
navigaon panel, select the bucket and then container to which you uploaded the Cortex
XDR VHD image.
In the Container page, Select your VHD image.
• OS type—Select Linux
• VM generaon—Select Gen 1
Review + create to check you sengs.
STEP 5 | Create your broker VM disk.

Aer deployment is complete Go to resource.
STEP 6 | In your created Disks page, Create VM.
STEP 7 | In the Create a virtual machine page, define the following:

Instance details
• (Oponal) Virtual machine name—Enter the same name as the disk name you defined.
• Size—Select the size according to your company guidelines.
Select Next to navigate to the Networking tab.
Network interface
• NIC network security group—Select Advanced.
• Configure network security group—Select HTTPS to be able to access the Broker VM Web
UI, and SSH to allow for remote access when troubleshoong. Make sure to allow these
connecon to the broker from secure networks only.
Review + create to check your sengs.
STEP 8 | Create your VM.

Aer deployment is complete Go to resource. You are directed to your VM page.
Creang the VM can take up to 15 minutes. The broker VM Web UI is not accessible
during this me.
Broker VM
Set up the Broker VM on Google Cloud Plaorm (GCP)

You can deploy the Broker VM on Google Cloud Plaorm. The Broker VM facilitates
communicaon with external services through the installaon and setup of applets such as the
syslog collector.
To set up the Broker VM on the Google Cloud Plaorm, you install the VMDK image provided in
Cortex XDR . To complete the set up, you must have G Cloud installed and have an authencated
user account.
STEP 1 | Download the Broker VM VMDK image from Cortex XDR (see Configure the Broker VM).
STEP 2 | 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.
STEP 3 | Open a command prompt and run the following.
gcloud config set project <project-name>
STEP 4 | Upload the VMDK image to the bucket, run the following.
gsutil cp </path/to/broker.vmdk> gs://<bucket-name>
Broker VM
STEP 5 | 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
image import to work, Cloud Build service account must have compute.admin and
iam.serviceAccountUser roles. When using the Google Cloud console to import
the image, you will be prompted to add these permissions automacally.
• gcloud CLI
Before imporng 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 informaon 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> --os=ubuntu-1804 --

source-file="gs://<image path>" --network=<network_name> --
subnet=<subnet_name> --zone=<region> --async
• Google Cloud Console

1. Navigate to Compute Engine > Images.
2. Create Image.
3. Complete the following fields.
• Specify a meaningful Name for this image, such as broker-9-0-32.
• Select Virtual disk (VMDK, VHD) as the Source.
• To select the Cloud Storage file, Browse and select the bucket and the VMDK image
you uploaded.
• Select Ubuntu 18.04 Bionic as the Operang system on virtual disk.
• Allow Compute Engine to Install guest packages.
• Create the image.
The image creaon process can take up to 20 minutes.
Broker VM
STEP 6 | When the Google Compute completes the image creaon, create a new instance.
1. From the Google Cloud Plaorm, select Compute Engine > VM instances.
2. Create instance.
3. In Boot disk opon, choose Custom images and select the image you created.
4. In the Firewall secon, Allow HTTPS traffic.
5. 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 mulple applets, use e2-standard-4.
Broker VM
STEP 7 | Connue the steps to Configure the Broker VM.
Create a Broker VM Image for Alibaba Cloud

Aer you download your Cortex XDR Broker 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 ulity file
provided by Alibaba Cloud to upload the image.
To create a Broker VM image for Alibaba Cloud:
STEP 1 | Download the ossutil ulity file provided by Alibaba Cloud.
The download is dependent on the operang system and infrastructure you are using.
• Alibaba Cloud supports using the following operang systems for the ulity file: Windows,
Linux, and macOS.
• Supported architectures: x86 (32-bit and 64-bit) and ARM (32-bit and 64-bit)
For more informaon on downloading the ulity, see the Alibaba Cloud documentaon.
Broker VM
STEP 2 | Upload the image file to Alibaba Cloud using the ulity file you downloaded.
The command is dependent on the operang system and architecture you are using. Below
are a few examples of the commands to use based on the different operang systems and
architectures, which you may need to modify based on your system requirements.
• Linux (using CLI)
• Format
./ossutil64 cp Downloads/<name of broker vm QCOW2 image> oss://

<directory name>/<file name for uploaded image>
• Example
./ossutil64 cp Downloads/QCOW2_broker-vm-14.0.1.qcow2 oss://

kvm-images-qcow2/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/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/XDR-broker-
vm-14.0.1.qcow2
For Linux and Windows uploads, you can use Alibaba Cloud’s graphical management
tool called ossbrowser.
STEP 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
Broker VM
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 aer this.
5. Select Hamburger menu > Elasc 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 combinaon of the internal link that you copied
for the Broker VM image and the <file name for 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 aer
the .com: /<file name for uploaded image>.
• Image Name—Specify a name for the image.
• Operang System/Plaorm—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 noficaon is displayed indicang 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.
Broker VM
STEP 4 | Create a new virtual machine (VM) in Alibaba Cloud.

1. Select Hamburger menu > Elasc Compute Service > Instances & Images > Instances.
2. Create Instance to open a wizard to define the VM machine.
3. Define the Basic Configuraons screen by seng these parameters.
• 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 sengs according to your system requirements.
• Selected Instance Type Quanty—Set these sengs according to your system
requirements.
• Image—Select Custom Image, and in the field select the image that you imported to
Alibaba Cloud.
• Storage—(Oponal) Set these sengs according to your system requirements.
• Snapshot—(Oponal) Set these sengs according to your system requirements.
4. Click Next.
5. Define the Networking screen by seng these parameters.
• Network Type—Select the applicable Network Type and update the field according to
your system configuraon.
• Public IP Address—(Oponal) Enable the instance to access the public network.
• Security Group—You must select a Security Group for seng 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.
• Elasc Network Interface—(Oponal) Add an ENI according to you system
requirements.
6. Click Next.
7. Define the System Configuraons screen by seng these parameters.
• Logon Credenals—Select Inherit Password From Image.
• Instance Name—You can either leave the default instance name or specify a new
name for the VM instance.
• Descripon—(Oponal) Specify a descripon for the VM instance.
• The rest of the fields are oponal to configure.
8. Click Next.
9. (Oponal) Define the Grouping screen according to your system requirements.
10. Click Next.
11. Review the Preview screen sengs, select ECS Terms of Service and Product Terms of
Service, and click Create Instance.
A dialog box is displayed indicang 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.
Broker VM
STEP 5 | Reboot the Broker VM before logging in for the first me.
Create a Broker VM Image for a Nutanix Hypervisor

Aer you download your Cortex XDR Broker VM QCOW2 image, you need to upload it to a
Nutanix hypervisor. The Nutanix AHV 2021 version is supported.
To create a Broker VM image for a Nutanix hypervisor:
STEP 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. Addional fields related to the
QCOW2 file are automacally displayed in the Add Image page, where the Name and
Type of file are automacally populated.
4. (Oponal) Define the rest of the fields displayed for the QCOW2 file.
5. Click Next.
6. Select the locaon by defining the Placement Method and Select Clusters sengs.
7. Click Save.
The image is now listed in the list of images.
Saving the image to Nutanix hypervisor can take me as it’s a large file.
Broker VM
STEP 2 | Create a new virtual machine (VM).

1. Select Hamburger menu > Compute & Storage > VMs, and click Create VM.
2. In the Create VM screen, set the following Configuraon fields.
• Name—Specify a name for the new VM.
• Descripon—(Oponal) Specify a descripon to idenfy the VM.
• Number of VMs—Select the number of VMs you want to create. The default is set to
1.
• VM Properes
• 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 alloed memory for the VM.
3. Click Next.
4. Set the Resources fields.
• Disks—Aach Disk and set the following field sengs.
• Type—Leave the default Disk type.
• Operaon—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—Aach to Subnet and set the following field sengs.
• Subnet—Select the subnet from the list.
• Network Connecon State—Leave the default Connected opon selected.
When you finish, click Save.
• Boot Configuraon—Leave the default Legacy BIOS Mode selected.
5. Click Next.
6. Set the Management fields, where you can leave the default sengs for the various
fields.
7. Click Next.
8. Click Create VM.
The VM is now listed in the list of VMs.
Creang the VM can take up to 15 minutes. The broker VM Web user interface is
not accessible during this me.
STEP 3 | Review the VM details for connecng to the VM.

Select Summary and you can use the IP Addresses and Host IP listed to connect to the VM.
Broker VM
Create a Broker VM Image for Ubuntu

Aer you download your Cortex XDR Broker VM QCOW2 image, you need to upload it to
Ubuntu. The Ubuntu version 18.04 is supported.
To create a Broker VM image for Ubuntu:
STEP 1 | Open your kernel-based Virtual Machine (KVM) on Ubuntu.
STEP 2 | Click the New VM icon ( ) to open the Create a new virtual machine wizard.
STEP 3 | In the Step 1 screen of the wizard, select Import exisng disk image, and click Forward.
STEP 4 | Define the Step 2 screen of the wizard.

• Provide the exisng 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 opon selected.
• Version—Leave the Generic opon selected.
STEP 5 | Click Forward.
STEP 6 | Define the Step 3 screen of the wizard.

• Memory (RAM)—Specify 4096 (4GB)
of memory.
• CPUs—Specify 2 CPUs.
STEP 7 | Click Forward.
STEP 8 | In the Step 4 screen of the wizard, set a Name for your new VM.
STEP 9 | Click Finish.

You new VM is now listed and available to use.
Acvate the Local Agent Sengs

The Local Agent Sengs 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 connecon to the internet, setup the Broker VM to act as a proxy that
routes all the traffic between the Cortex XDR management server and Cortex XDR agents via
a centralized and controlled access point. This enables your agents to receive security policy
updates, and send logs and files to Cortex XDR without a direct connecon. Addionally,
with the Broker VM endpoints agents are able to connect to the internet. The Broker VM
acts like a transparent proxy and doesn’t decrypt the secure connecon between the server
and the agent, and hides the agent’s original IP addresses. If your network topology includes
SSL decrypon in an upstream proxy/firewall, the Broker VM does not parcipate in the trust
relaonship as it is not iniang the connecon to the server to be fully transparent.
Broker VM
• Enable Broker caching—To reduce your external network bandwidth loads, you can cache
Cortex XDR agent installaons, 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 retenon period since an agent last asked for them.
If the files were not available on the Broker VM at the me 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.
The following are prerequisites and limitaons for the Local Agent Sengs applet.
General Each local seng on the broker VM can support up

to 10,000 agents.
Agent Proxy • Supported with Traps agent version 5.0.9 and

Traps agent version 6.1.2 and later releases.
Agent Installer and Content Caching • Supported with Cortex 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.
• Requires the Broker to have an FQDN record in
your local DNS server.
• Requires you upload a strong cipher SHA256-
based SSL cerficates when you setup the
Broker VM.
• Requires adding the Broker as a download
source in your Agent Sengs Profile.
Aer you configured and registered your Palo Alto Networks Broker VM, proceed to setup you
Local Agent Sengs applet.
STEP 1 | In Cortex XDR, go to Sengs > Configuraons > Data Broker > Broker VMs and locate your
broker VM.
Broker VM
STEP 2 | (Oponal) To setup the Agent Proxy:

1. Right-click the broker, select Broker Management > Configure.
Ensure your proxy server is configured. If not, proceed to add it as described in Configure
the Broker VM.
2. From Broker Management > Configure, right-click the broker again and select Local
Agent Sengs > Acvate.
3. In the Local Agent Sengs configuraon, enable Agent Proxy. You can also specify the
Agent Proxy Listening Interface.
When you install your Cortex XDR agents, you must configure the IP address of
the broker VM and a port number during the installaon. You can use the default
8888 port or set a custom port. You are not permied to configure port numbers
between 0-1024 and 63000-65000, or port numbers 4369, 5671, 5672, 5986,
6379, 8000, 9100, 15672, 25672. Addionally, you are not permied to reuse
port numbers you already assigned to the Syslog Collector applet.
STEP 3 | (Oponal) To setup up Agent Installer and Content Caching:

1. Ensure you uploaded your SHA256-based cerficates.
If not, upload them as described in Configure the Broker VM and Save.
2. Specify the Broker VM FQDN.
Right-click the broker, select Broker Management > Configure. Under Device Name,
enter your Broker VM FQDN. This FQDN record must be configured in your local DNS
server.
3. Acvate the Local Agent Sengs applet on the Broker.
From Broker Management > Configure, right-click the broker again, and select Local
Agent Sengs > Acvate
4. Acvate installer and content caching.
In the Local Agent Sengs configuraon, enable Agent Installer and Content Caching.
5. To enable agents to start using broker caching, you must add the Broker VM as a
download source in your Agent Sengs profile and select which brokers to use, as
described in Add a New Agent Sengs Profile. Then, ensure the profile is associated
with a policy for your target agents.
STEP 4 | Aer a successful acvaon, the Apps field displays Local Agent Sengs - Acve. Hover
over it to view the applet status and resource usage.
To help you easily troubleshoot connecvity issues for a Local Agent Sengs applet on the
Palo Alto Networks Broker VM, Cortex XDR displays a list of Denied URLs. These URLs are
displayed when you hover over the Local Agent Sengs applet to view the Connecvity
Status. As a result, in a situaon where the Local Agent Sengs applet is reported as acvated
with a failed connecon, you can easily determine the URLs that need to be allowed in your
network environment.
Broker VM
STEP 5 | Manage the local agent sengs. Aer the local agent sengs have been acvated, right-click
your broker VM.
• To change your sengs, click Local Agent Sengs > Configure.
• To disable the local agent sengs altogether, click Local Agent Sengs > Deacvate.
Acvate the Syslog Collector

Ingesng Logs and Data from external sources requires a Cortex XDR Pro per TB 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 ingeson rate of 90,000
logs per second (lps) with the recommended Broker VM setup.
To increase the log ingeson rate, you can add addional CPUs to the broker VM. The Syslog
Collector listens for logs on specific ports and from any or specific IP addresses.
STEP 1 | If you haven’t already done so, Configure the Broker VM.
STEP 2 | In Cortex XDR, navigate to Sengs > Configuraons > Data Broker > Broker VMs and
locate your broker VM.
STEP 3 | Right-click the broker VM and select Syslog Collector > Acvate.
STEP 4 | Configure your Syslog Collector:

Cortex XDR supports mulple sources over a single port on a single Syslog Collector. The
following opons are available.
• Edit the Oponal Sengs of the default PORT/PROTOCOL: 514/UDP. See Step 5.
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 Step 7.
• Add a new Syslog Collector data source. See Step 6.
Broker VM
STEP 5 | Edit the default 514/UDP Syslog Collector data source:

1. Right-click the 514/UDP PORT/PROTOCOL, and select Edit.
2. Configure these Oponal Sengs:
• 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 sengs. 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 sengs. If you did not specify a Vendor or Product in the Syslog
Collector sengs and the values are blank in the event log row, the values
for both fields are set to unknown.
• Vendor—Specify a parcular vendor for the Syslog format defined or leave the default
Auto-Detect seng.
• Product—Specify a parcular product for the Syslog format defined or leave the
default Auto-Detect seng.
• Source Network—Specify the IP address or Classless Inter-Domain Roung (CIDR). If
you leave this blank, Cortex XDR will allow receipt of logs from any source IP address
or CIDR that transmits over the specified protocol and port. When you specify
overlapping addresses in the Source Network field in mulple 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 maer.
In this example, the IP address 10.0.0.10 is only captured from the first row definion.
For more informaon on priorizing the order of the syslog formats, see Step #7.
Aer each configuraon, select to save the changes and then Done to update the
Syslog Collector with your sengs.
Broker VM
STEP 6 | Add a new Syslog Collector data source:

1. Select Add New.
2. Configure these mandatory General sengs:
• Protocol—Choose a protocol over which the Syslog will be sent: UDP, TCP, or Secure
TCP
• 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
• When configuring the Protocol as Secure TCP, these addional General Sengs are
available:
• Server Cerficate—Browse to your server cerficate to configure server
authencaon.
• Private Key—Browse to your private key for the server cerficate.
• Oponal CA Cerficate—(Oponal) Browse to your CA cerficate for mutual
authencaon.
• Minimal TLS Version—Select either 1.0 or 1.2 (default) as the minimum TLS version
allowed.
Cortex XDR will nofy you when your cerficates are about to expire.
3. Configure these Oponal Sengs:

• 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 parcular vendor for the Syslog format defined or leave the default
• Product—Enter a parcular product for the Syslog format defined or leave the default
• Source Network—Specify the IP address or Classless Inter-Domain Roung (CIDR). If
you leave this blank, Cortex XDR will allow receipt of logs from any source IP address
or CIDR that transmits over the specified protocol and port. When you specify
overlapping addresses in the Source Network field in mulple 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 maer.
In this example, the IP address 10.0.0.10 is only captured from the first row definion.
For more informaon on priorizing the order of the syslog formats, see Step #7.
Aer each configuraon, select to save the changes and then Done to update the
Syslog Collector with your sengs.
Broker VM
STEP 7 | Make addional changes to the Syslog Collector data sources configured.
• To remove a Syslog Collector data source, right-click the row aer the Port/Protocol entry,
and select Remove.
• To priorize the order of the Syslog formats listed for the protocols and ports configured,
drag and drop the rows to the order you require.
STEP 8 | Save the Syslog Collector sengs.

Aer a successful acvaon, the Apps field, for the broker VM which you configured the
Syslog Collector, displays Syslog Collector - Active, Connected.
STEP 9 | (Oponal) To view metrics about the Syslog Collector, hover over the Syslog Collector link in
the Apps field.
Cortex XDR displays the following informaon.
• Connecvity 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 connecvity issue.
• Resources—Displays the amount of CPU, Memory, and Disk space the applet is using.
STEP 10 | Manage the Syslog Collector.

Aer the Syslog Collector has been acvated, you can make addional changes to your
configuraon if needed. To modify a configuraon, right-click your broker VM and select:
• Syslog Collector > Configure to redefine the Syslog configuraons.
• Syslog Collector > Deacvate to disable the Syslog Collector.
Acvate the Apache Kaa Collector

Apache Kaa is an open-source distributed event streaming plaorm for high-performance data
pipelines, streaming analycs and data integraon. Apache Kaa records are organized into
Topics. The parons for each Topic are spread across the bootstrap servers in the Apache Kaa
cluster. The bootstrap servers are responsible for transferring data from Producers to Consumer
Groups, which enable the Apache Kaa server to save offsets of each paron in the Topic
consumed by each group.
The broker VM provides an Apache Kaa Collector applet that enables you to monitor and
collect events from Topics on self-managed on-prem Apache Kaa clusters directly to your log
repository for query and visualizaon purposes. The applet supports Apache Kaa setups with no
authencaon, with SSL authencaon, and SASL SSL authencaon.
Aer you acvate the Kaa Collector applet, you can collect events as datasets
(<Vendor>_<Product>_raw) by defining the following.
• Apache Kaa connecon details including the Bootstrap Server List and Authencaon
Method.
Broker VM
• Topics Collecon configuraon for the Apache Kaa topics that you want to collect.
Following are the prerequisites for seng up the Apache Kaa Collector applet.
• Apache Kaa version 2.5.1 and above.
• Apache Kaa cluster set up on premises, from which the data will be ingested.
• Privileges to manage Broker Service configuraon, for example Instance Administrator).
Complete the following tasks before you begin seng up the Kaa Collector applet.
• Create a user in the Apache Kaa cluster with the necessary permissions and the following
authencaon details.
• Broker Cerficate and Private Key for an SSL connecon.
• Username and Password for an SASL SSL connecon.
• Configure the Broker VM.
Acvate the Apache Kaa Collector.
STEP 1 | In Cortex XDR, select Sengs > Configuraons > Data Broker > Broker VMs and locate your
broker VM.
STEP 2 | Right-click the broker VM and select Kaa Collector > Acvate.
Broker VM
STEP 3 | Configure the Kaa Connecon.

1. Specify the Bootstrap Server List—The <hostname/ip>:<port> of the bootstrap server
(or servers). You can specify mulple servers, separated with a comma. For example,
hostname1:9092,1.1.1.1:9092.
2. Select one of the Authencaon Methods.
• No Authencaon—Default connecon method for a new Apache Kaa setup, which
doesn’t require authencaon. With a standard Kaa setup, any user or applicaon
can write messages to any topic, as well as read data from any topic.
• SSL Authencaon—Authencate your connecon to Apache Kaa using an SSL
cerficate. Use this authencaon method when the connecon to the Apache Kaa
server is a secure TCP, and upload the following.
• Broker Cerficate—Signed cerficate used for the applet to authencate to the
Apache Kaa server.
• Private Key—Private key for the applet used for decrypng the SSL messages
coming from the Apache Kaa server.
• (Oponal)CA Cerficate—CA cerficate that was used to sign the server and
private cerficates. This CA cerficate is also used to authencate the Apache
Kaa server identy.
• SASL SSL (SCRAM-SHA-256)—Authencate your connecon to the Apache Kaa
server with your Username, Password, and oponally your CA Cerficate.
3. Test Connecon to verify that you can connect to the Apache Kaa server. An error
message is displayed for each server connecon test that fails.
4. Configure the Topics Collecon parameters.
• Select the Topic Subscripon Method for subscribing to Apache Kaa topics. Use
List Topics to specify a list of topics. Use Regex Paern Matching to specify a regular
expression to search available topics.
• Specify Topic(s) from the Apache Kaa server. For the List Topics subscripon
method, use a comma separated list of topics to subscribe to. For the Regex Paern
Matching subscripon method, use a regular expression to match the Topic(s) to
subscribe to.
• (Oponal) Specify a Consumer Group, a unique string or label that idenfies the
consumer group this log source belongs to. Each record that is published to an Apache
Kaa topic is delivered to one consumer instance within each subscribing consumer
group. Apache Kaa uses these labels to load balance the records over all consumer
instances in a group. When specified, the Apache Kaa collector uses the given
consumer group. When not specified, Cortex XDR assigns the Apache Kaa applet
collector to a new automacally generated consumer group which is automacally
generated for this log source with the name PAN-<Broker VM device name>-<topic
name>.
• Select the Log Format from the list as either RAW (default), JSON, CEF, LEEF, CISCO,
or CORELIGHT. This seng 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
Broker VM
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.
• 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 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.
5. (Oponal)Add Topic to create another Topic Collecon. Each topic can be added for a
server only once.
6. (Oponal) Other available opons for Topic Collecon.
As needed, you can manage your Topic Collecon sengs. Here are the acons available
to you.
• Edit the Topics Collecon details.
• Disable/Enable a Topics Collecon by hovering over the top area of the Topics
Collecon secon, on the opposite side of the Topics Collecon name, and selecng
the applicable buon.
• Rename a Topics Collecon by hovering over the top area of the Topics Collecon
secon, on the opposite side of the Topics Collecon name, and selecng the pen
icon.
• Delete a Topics Collecon by hovering over the top area of the Topics Collecon
secon, on the opposite side of the Topics Collecon name, and selecng the delete
icon.
STEP 4 | (Oponal)Add Connecon to create another Apache Kaa Connecon for collecng data.
STEP 5 | (Oponal) Other available opons for Connecons.

As needed, you can return to your Apache Kaa Collector sengs to manage your
connecons. Here are the acons available to you.
• Edit the Connecon details.
• Rename a connecon by hovering over the default Collecon name, and selecng the edit
icon to edit the text.
• Delete a connecon by hovering over the top area of the connecon secon, on the
opposite side of the connecon name, and selecng the delete icon. You can only delete a
connecon when you have more than one connecon configured. Otherwise, this icon is
not displayed.
STEP 6 | Save to commit changes. Save is enabled only when all the mandatory fields are filled in.
STEP 7 | (Oponal) To view metrics about the Apache Kaa Collector, in the Broker VM screen, hover
over the Kaa Collector link 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.
Broker VM
STEP 8 | Manage the Kaa Collector.

Aer you acvate the Kaa Collector, you can make addional changes as needed. To modify
a configuraon, right-click your broker VM and select.
• Kaa Collector > Configure to redefine the Kaa Collector configuraons.
• Kaa Collector > Deacvate to disable the Kaa Collector.
You can also Ingest Apache Kaa Events as Datasets.
Acvate the CSV Collector

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 visualizaon purposes. Aer you acvate 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 seng the list of CSV files to monitor and upload to Cortex XDR
using a username and password.
Be sure you do the following tasks before you begin seng up the CSV Collector applet.
• Ensure that you share the applicable CSV files.
• Know the complete file path for the Windows directory.
Acvate the CSV Collector.
broker VM.
STEP 2 | Right-click the broker VM and select CSV Collector > Acvate.
Broker VM
STEP 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.
1. Mounted Folders
• FOLDER PATH—Specify the complete file path to the Windows directory containing
the shared CSV files using the format: //host/<folder_path>. For example, //
testenv1pc10/CSVFiles.
• USERNAME—Specify the username for accessing the Windows directory.
• PASSWORD—Specify the password for accessing the Windows directory.
Aer you configure the mounted folder details, Add ( ) details to the applet.
2. Monitored CSV Files
• FOLDER PATH+NAME—Select the monitored Windows directory and specify the name
of the CSV file. Use a wildcard file search using these characters in the name of the
directory, CSV file name, and Path Exclusion.
- ?—Matches a single char, such as 202?-report.csv.
- *—Matches either mulple 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 EXCLUSION—(Oponal) Specify the complete file path for any files from the
Windows directory that you do not want included. The same wildcard file search
characters are allowed in this field as explained above for the FOLDER PATH+NAME
field. For example, if you want to exclude any CSV file prefixed with 'exclude_' in
the directory and subdirectories of //host/<folder_path>, use the syntax //
host/<folder_path>/**/exclude_*.csv>.
• TAGS—(Oponal) To easily query the CSV data in the database, you can add a tag to the
collected CSV data. This tag is appended to the data using the format <data>_<tag>.
• TARGET DATASET—Either select the target dataset for the CSV data or create a new
dataset by specifying the name for the new dataset.
STEP 4 | Acvate the CSV Collector applet.

Aer a successful acvaon, the Apps field displays CSV Collector - Active.
The CSV Collector checks for new CSV files every 10 minutes.
Broker VM
STEP 5 | (Oponal) To view metrics about the CSV Collector, hover over the CSV Collector link in the
Apps field.
applet is using.
STEP 6 | Manage the CSV Collector.

Aer you acvate the CSV Collector, you can make addional changes as needed. To modify a
configuraon, right-click your broker VM and select:
• CSV Collector > Configure to redefine the CSV Collector configuraons.
• CSV Collector > Deacvate to disable the CSV Collector.
You can also Ingest CSV Files as Datasets.
Acvate the Database Collector

Ingesng logs and data from external sources requires a Cortex XDR Pro per TB license.
The broker VM provides a Database Collector applet that enables you to collect data from a client
relaonal database directly to your log repository for query and visualizaon purposes. Aer you
acvate 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 connecon details, where the connecon type can be MySQL, PostgreSQL, MSSQL,
and Oracle. Cortex XDR uses Open Database Connecvity (ODBC) to access the databases.
• Sengs related to the query details for collecng the data from the database to monitor and
upload to Cortex XDR.
Complete the following task before you begin seng up the FTP Collector applet.
Acvate the Database Collector.
broker VM.
STEP 2 | Right-click the broker VM and select Database Collector > Acvate.
Broker VM
STEP 3 | Configure your Database Connecon.

1. Configure the Database Connecon sengs.
• Connecon—Select the type of database connecon 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 Connecon Type for MySQL, PostegreSQL, and
MSSQL.
When configuring an Oracle connecon, this field is called Service Name, so you can
specify the name of the service.
• Enable SSL—Select whether to Enable SSL (default) to encrypt the data while in transit
between the database and the broker VM.
• Username—Specify the username to access the database.
• Password—Specify the password to access the database.
• Test Connecon—Select to validate the database connecon.
2. Configure the Database Query sengs.
• Rising Column—Specify a column for the Database Collector applet to keep track of
new rows from one input execuon to the next. This column must be included in the
query results.
• Retrieval Value—Specify a Retrieval Value for the Database Collector applet to
determine which rows are new from one input execuon to the next. The first me
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 me 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—(oponal) Specify the column name(s) to match against when mulple
records have the same value in the Rising Column. This column must be included in
the query results. This is a comma separated field that supports mulple values. In
addion, when specifying a Unique IDs, the query should use the greater than equal
to sign (>=) in relaon to the Retrieval Value. If the Unique IDs is le empty, the user
should use the greater than sign (>).
• Collect Every—Specify the execuon frequency of collecon by designang a number
and then selecng the unit as either Seconds, Minutes, Hours, or Days.
• Vendor and Product—Specify the Vendor and Product for the type of data being
collected. The vendor and product are used to define the name of your XQL dataset
• 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 queson mark (?) in the
query is a checkpoint placeholder for the Retrieval Value. Every me the input is run,
Broker VM
the Database Collector applet replaces the queson mark with the latest checkpoint
value (i.e. start value) for the Retrieval Value.
• Generate Preview—Select Generate Preview to display up to 10 rows from the SQL
Query and Preview the results. The Preview works based on the Database Collector
sengs, which means that if aer running the query no results are returned, then the
Preview returns no records.
• Add Query—(oponal) To define another Query for data collecon on the configured
database connecon, select Add Query. Another Query secon is displayed for you to
configure.
STEP 4 | (oponal) Add Connecon to define another database connecon to collect data from
another client relaonal database.
STEP 5 | (oponal) Other available opons.

As needed, you can return to your Database Collector sengs to manage your connecons.
Here are the acons available to you.
• Edit the connecon name by hovering over the default Collecon name, and selecng the
edit icon to edit the text.
• Edit the query name by hovering over the default Query name, and selecng the edit icon
to edit the text.
• Disable/Enable a query by hovering over the top area of the query secon, on the opposite
side of the query name, and selecng the applicable buon.
not displayed.
• Delete a query by hovering over the top area of the query secon, on the opposite side of
the query name, and selecng the delete icon. You can only delete a query when you have
more than one query configured. Otherwise, this icon is not displayed.
STEP 6 | Acvate the Database Collector applet.

Aer a successful acvaon, the Apps field displays Database Collector - Active.
STEP 7 | (Oponal) To view metrics about the Database Collector, hover over the Database Collector
link in the Apps field.
applet is using.
STEP 8 | Manage the Database Collector.

Aer you acvate the Database Collector, you can make addional changes as needed. To
modify a configuraon, right-click your broker VM and select.
• Database Collector > Configure to redefine the Database Collector configuraons.
• Database Collector > Deacvate to disable the Database Collector.
You can also Ingest Database Data as Datasets.
Broker VM
Acvate the Files and Folders Collector

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 visualizaon purposes. The Files and Folders collector applet
only starts to collect files that are more than 256 bytes. Aer you acvate the Files and Folders
Collector applet, you can collect files as datasets (<Vendor>_<Product>_raw) by defining the
following.
• Details of the folder path on the network share containing the files that you want to monitor
and upload to Cortex XDR.
• Sengs 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.
Complete the following task before you begin seng up the Files and Folders Collector applet.
• 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 collecon.
Acvate the Files and Folders Collector.
broker VM.
STEP 2 | Right-click the broker VM and select Files and Folder Collector > Acvate.
Broker VM
STEP 3 | Configure the Files and Folders Collector sengs.
The image above is displaying the File and Folder Sengs secon with the Batch Mode
selected to display all opons available. Yet, the Tail Mode is selected by default.
1. Configure the Shared Folder Connecon sengs.

• Folder Path—Specify the path to the files and folders that you want Cortex XDR to
monitor connuously 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 Connecon—Select to validate the connecon and permissions.
2. Configure the File and Folder Sengs.
• Mode—Select the mode to use for collecng logs, where the fields displayed change
depending on your selecon.
• Tail—Connuously monitors files for new data (default).
• Batch—Reads enre file and then renames/deletes uploaded files.
In Batch mode, the Files and Folders Collector supports collecng logs
from a network share for a maximum file size of 500 MB.
and then selecng the unit as either Minutes, Hours, or Days. This opon is only
displayed in Batch Mode.
• Aer Files Uploaded—Select what to do with the files aer they are uploaded to the
Cortex XDR server. You can either select Rename files with a suffix (default) and then
you must specify the Suffix or Delete files. When adding a suffix, the suffix is added at
Broker VM
the end of the original file name using the format <file name>.<suffix>, which
becomes the new name of the file. This opon is only displayed in Batch Mode.
• Include—Specify the files and folders that must match to be monitored by Cortex
XDR. Mulple values are allowed with commas separang the values.
Allowed wildcard:
• '?' matches a single alphabet character in a specific posion.
• '*' matches any character or set of characters, including no character.
Example: log*.json includes any JSON file starng with 'log'.
• Exclude—(oponal) Specify the files and folders that must match to not be monitored
by Cortex XDR. Mulple values are allowed with commas separang the values.
Allowed wildcard:
Example: *.backup excludes any file ending with '.backup'.
• Log Format—Select the Log Format from the list as either Raw (default), JSON, CSV,
TSV, PSV, CEF, LEEF, Corelight, or Cisco. This seng 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 nesng
and only supports single line JSON format, such that every new line means a
separate entry.
• # of Lines to Skip—(oponal) Specify the number of lines to skip at the beginning of
the file. This is set to 0 by default.
3. Configure Data Source Mapping sengs.
Vendor and Product—Specify the Vendor and Product for the type of data being
• The Vendor and Product defaults to Auto-Detect when the Log Format is set
to CEF or LEEF.
4. 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 sengs, which
means that if all the files that were configured to be monitored were already processed,
then the Preview returns no records.
STEP 4 | (oponal) Add Connecon to define another Files and Folders connecon for collecng logs
from files and folders in a shared resource.
Broker VM
STEP 5 | (oponal) Other available opons.

As needed, you can return to your Files and Folders Collector sengs to manage your
connecons. Here are the acons available to you.
• Disable/Enable a connecon by hovering over the top area of the connecon secon, on
the opposite side of the connecon name, and selecng the applicable buon.
not displayed.
STEP 6 | Acvate the Files and Folders Collector applet.

Aer a successful acvaon, the Apps field displays Files and Folders Collector -
Active.
STEP 7 | (Oponal) To view metrics about the Files and Folders, hover over the Files and Folders
Collector link in the Apps field.
applet is using.
STEP 8 | Manage the Files and Folders Collector.

Aer you acvate the Files and Folders Collector, you can make addional changes as needed.
To modify a configuraon, right-click your broker VM and select.
• Files and Folders Collector > Configure to redefine the Files and Folders Collector
configuraons.
• Files and Folders Collector > Deacvate to disable the Files and Folders Collector.
You can also Ingest Logs in a Network Share as Datasets.
Acvate the FTP Collector

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 visualizaon purposes. A maximum file size of 500 MB is supported. Aer you acvate
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) connecon details with the path to the folder containing the files
that you want to monitor and upload to Cortex XDR.
• Sengs 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
Broker VM
uploaded to Cortex XDR, you can define whether in the source directory the files are renamed
or deleted.
Complete the following tasks before you begin seng up the FTP Collector applet.
• 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 collecon.
• When seng up an FTPS Collector with a server using a Self-signed cerficate, you must
upload the cerficate first to the broker VM as a Trusted CA cerficate.
Acvate the FTP Collector.
broker VM.
STEP 2 | Right-click the broker VM and select FTP Collector > Acvate.
STEP 3 | Configure the FTP Connecon sengs.

1. Configure the FTP Connecon sengs.
• Type—Select the type of FTP connecon as FTP, SFTP, or FTPS.
• Host—Specify the hostname, IP address, or FQDN of the FTP server. When
configuring a FTPS Collector, you must specify the FQDN.
• Port—Specify the FTP port number.
• Username—Specify the username to login to the FTP server.
• Password—Specify the password to login to the FTP server.
• SSH Key-Based Authencaon—This checkbox is only displayed when seng a
SFTP Collector, which works with both Username and Password authencaon or
SSH Key-Based Authencaon. You can either leave this checkbox clear and set a
Username and Password (default) or select SSH Key-Based Authencaon to Browse
Broker VM
to a Private Key. When this connecon is established with a server using a Self-signed
cerficate, you must upload it first to the broker VM as a Trusted CA Cerficate.
When configuring an SFTP connecon, 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 geng 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 Connecon—Select to validate the FTP connecon.
2. Configure the FTP Sengs.
and then selecng the unit as either Minutes, Hours, or Days.
• Aer Files Uploaded—Select what to do with the files aer they are uploaded to the
Cortex XDR server. You can either select Rename files with a suffix (default) and then
you must specify the Suffix or Delete files. When adding a suffix, the suffix is added at
the end of the original file name using the format <file name>.<suffix>, which
becomes the new name of the file.
• Include—Specify the files and folders that must match to be monitored by Cortex
XDR. Mulple values are allowed with commas separang the values.
Allowed wildcard:
Example: log*.json includes any JSON file starng with 'log'.
• Exclude—(Oponal) Specify the files and folders that must match to not be monitored
by Cortex XDR. Mulple values are allowed with commas separang the values.
Allowed wildcard:
Example: *.backup excludes any file ending with '.backup'.
• Log Format—Select the Log Format from the list as either Raw (default), JSON, CSV,
TSV, PSV, CEF, LEEF, Corelight, or Cisco, which indicates to Cortex XDR how to parse
the data in the file. This seng defines the parser used to parse all the processed
files as defined in the Include and Exclude fields, regardless of the file names and
Broker VM
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 nesng
and only supports single line JSON format, such that every new line means a
separate entry.
• # of Lines to Skip—(Oponal) Specify the number of lines to skip at the beginning of
the file. This is set to 0 by default.
3. Configure the Data Source Mapping.
Vendor and Product—Specify the Vendor and Product for the type of data being
• The Vendor and Product defaults to Auto-Detect when the Log Format is set
to CEF or LEEF.
4. Generate Preview.
Select Generate Preview to display up to 10 rows from the first file and Preview the
results. The Preview works based on the FTP Collector sengs, which means that if all
the files that were configured to be monitored were already processed, then the Preview
returns no records.
STEP 4 | (Oponal) Add Connecon to define another FTP connecon for collecng logs from files
and folders via FTP, FTPS, or SFTP.
STEP 5 | (Oponal) Other available opons.

As needed, you can return to your FTP Collector sengs to manage your connecons. Here
are the acons available to you.
• Disable/Enable a connecon by hovering over the top area of the connecon secon, on
the opposite side of the connecon name, and selecng the applicable buon.
not displayed.
STEP 6 | Acvate the FTP Collector applet.

Aer a successful acvaon, the Apps field displays FTP Collector - Active.
STEP 7 | (Oponal) To view metrics about the FTP Collector, hover over the FTP Collector link in the
Apps field.
applet is using.
Broker VM
STEP 8 | Manage the FTP Collector.

Aer you acvate the FTP Collector, you can make addional changes as needed. To modify a
configuraon, right-click your broker VM and select.
• FTP Collector > Configure to redefine the FTP Collector configuraons.
• FTP Collector > Deacvate to disable the FTP Collector.
You can also Ingest FTP Files as Datasets.
Acvate the NetFlow Collector

Ingesng records from external sources requires a Cortex XDR Pro per TB 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 ingeson rate, you can add addional CPUs to the broker VM. The NetFlow
Collector listens for flow records on specific ports either from any, or from specific IP addresses.
Aer the NetFlow Collector is acvated, the NetFlow Exporter sends flow records to the NetFlow
Collector, which receives, stores, and pre-processes that data for later analysis.
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 mulple 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.
Complete the following task before seng up the NetFlow Collector applet.
Acvate the NetFlow Collector.
broker VM.
STEP 2 | Right-click the broker VM and select NetFlow Collector > Acvate.
STEP 3 | Click +Add New.
Broker VM
STEP 4 | Configure your NetFlow Collector.

1. Define General Sengs.
• UDP Port—Specify the number of the UDP port on which the NetFlow Collector
listens for flow records (default 2055).
This port number must match the UDP port number in the NetFlow exporter device.
The rules for each port are evaluated, line by line, on a first match basis. Cortex 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.
2. Define Custom Sengs.
• Source Network—Specify the IP address or a Classless Inter-Domain Roung (CIDR)
of the source network device that sends the flow records to Cortex 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
mulple rows in the Source Network field, such as 10.0.0.10 in the first row and
10.0.0.0/24 in the second row, the NetFlow Collector captures the IP address in the
first row.
• Vendor and Product—Specify a parcular vendor and product to be associated with
each dataset entry or leave the default IP Flow seng.
The Vendor and Product values 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 with the resulng dataset name ip_flow_ip_flow_raw.
Consider changing the default values in order to uniquely idenfy the source network
device.
Aer each configuraon, select to save your changes and then select Done to
update the NetFlow Collector with your sengs.
Broker VM
STEP 5 | (Oponal) Make addional changes to the NetFlow Collector data sources.
• You can make addional changes to the Port by right-clicking the applicable UDP port and
selecng the following.
• Edit—To change the UDP Port, Source Network, Vendor, or Product defined.
• Remove—To delete a Port.
• You can make addional changes to the Source Network by right-clicking on the Source
Network value.
The opons available change, according to the set Source Network value.
• Edit—To change the UDP Port, Source Network, Vendor, or Product defined.
• Remove—To delete a Port.
• Copy enre row—To copy the Source Network, Product, and Vendor informaon.
• Open IP View—To view network operaons and to view any open incidents on this IP
within a defined period. This opon is only available when the Source Network value is a
specific IP address or CIDR.
• Open in Quick Launcher—To search for informaon using the Quick Launcher shortcut.
This opon is only available when the Source Network value is a specific IP address or
CIDR.
• To priorize the order of the NetFlow formats listed for the configured data source, drag
and drop the rows to change their order.
STEP 6 | Acvate the NetFlow collector applet.

Aer successful acvaon, the Apps field from the Broker VM, in which you configured the
NetFlow Collector, displays NetFlow Collector - Active, Connected.
STEP 7 | (Oponal) To view NetFlow Collector metrics, hover over the NetFlow Collector link in the
Apps field.
Cortex XDR displays the following informaon:
• Logs Received and Logs Sent—Number of logs that the applet received and sent per
second over the last 24 hours. If there are more logs received than sent, this may indicate a
connecvity issue.
• Resources—Displays the amount of CPU, Memory, and Disk space the applet uses.
STEP 8 | Manage the NetFlow Collector.

Aer you acvate the NetFlow Collector, you can make addional changes. To modify a
configuraon, right-click your broker VM and select:
• NetFlow Collector > Configure to redefine the NetFlow Collector configuraons.
• NetFlow Collector > Deacvate to disable the NetFlow Collector.
You can also Ingest NetFlow Flow Records as Datasets.
Broker VM
Acvate the Network Mapper

Aer you have configured and registered your broker VM, you can choose to acvate the
Network Mapper applicaon.
The Network Mapper allows you to scan your network to detect and idenfy unmanaged hosts in
your environment according to defined IP address ranges. The Network Mapper configuraons are
used to locate unmanaged assets that appear in the Assets table.
Acvang the Network Mapper requires a Cortex XDR Pro per Endpoint or Cortex XDR
Pro per TB license.
STEP 1 | In Cortex XDR , select Sengs > Configuraons > Data Broker > Broker VMs and locate
your broker VM.
STEP 2 | Right-click and select Network Mapper > Acvate.
STEP 3 | In the Acvate Network Mapper window, define the following parameters:
• Scan Method—Select the either ICMP echo or TCP SYN scan method to idenfy your
network hosts. When selecng TCP SYN you can enter single ports and ranges together, for
example 80-83, 443.
• Scan Requests per Second—Define the maximum number of scan requests you want to
send on your network per second. By default, the number of scan requests are defined as
1000.
Each IP address range can receive mulple 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 me.
• Scanned Ranges—Select from the list of exing IP address ranges to scan. Make sure to
aer each selecon.
IP address ranges are displayed according to what you defined as your Network
Parameters.
STEP 4 | Acvate the applet.

Aer a successful acvaon, the Apps field displays Network Mapper- Active,
Connected.
Broker VM
STEP 5 | In the Apps field, select Network Mapper to view the following scan and applet metrics:
• Scan Details
• Connecvity 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 Duraon—Period of me in minutes and seconds the scan is running.
• Scan Progress—How much of the scan has been completed in percentage and IP address
rao.
• Detected Hosts—Number of hosts idenfied from within the IP address ranges.
• Scan Rate—Number of IP addresses scanned per second.
• Applet Metrics
STEP 6 | Manage the Network Mapper.

Aer the network mapper has been acvated, right-click you broker VM and select:
• Network Mapper > Configure to redefine the network mapper configuraons.
• Network Mapper > Scan Now to iniate a scan.
• Network Mapper > Deacvate to disable the network mapper.
Acvate Pathfinder™
Aer you have configured and registered your broker VM, acvate the Pathfinder applicaon.
To acvate Pathfinder, you must have a Cortex XDR Pro per Endpoint or Cortex XDR Pro
per TB license.
Pathfinder™ is a highly recommended, but oponal component integrated with the Broker VM
that deploys a non-persistent data collector on network hosts, servers, and workstaons that
are not managed by a Cortex XDR agent. The collector is automacally triggered by Analycs
type alerts with a severity of High and Medium as described in the Cortex XDR Analycs Alert
Reference, providing insights into assets that you would previously be unable to scan.
When an alert is triggered, the data collector is able to run for up to 2 weeks gathering EDR data
from unmanaged hosts. You can track and manage the collector directly from the Cortex XDR
console, and invesgate the EDR data by running a query from the Query Center.
Cortex XDR supports acvang Pathfinder on Windows operang systems with PowerShell
version 3 and above, excluding Vanilla Windows 7.
Acvate the Pathfinder app to deploy and query the data collector.
broker VM.
STEP 2 | Right-click and select Pathfinder > Acvate.
Broker VM
STEP 3 | In the Pathfinder Acvaon wizard, complete the following steps:

1. Define the Pathfinder Credenals used by the applet to access and deploy the data
collector. The Data Collector is deployed only within the ranges your defined IP address
ranges. You can either select to define the domain access credenals, or alternavely,
Broker VM
as of broker VM version 9.0 and later, you can define Pathfinder to access target hosts
using credenals stored in your CyberArk vault.
The Broker VM requires an SA account that has administrator privileges on all

Windows workstaons and servers in your environment. Due to this, Cortex XDR
recommends you limit the number of users granted access to the SA account as
it poses a credenal compromise security threat.
• Domain—Domain name of your network.

• Domain Suffixes—(Oponal) Domain suffixes required for DNS resolving within your
network. The domain suffixes list is read-only and populated by your defined Network
Configuraons.
• Authencaon Method—Select either Kerberos or NTLM.
When selecng Kerberos, the Broker has access to domain controllers over
port 88 and is able to acquire the authencaon cket. It is recommended to
use Kerberos for beer security.
• Define the access credenals using either Domain Credenals or your CyberArk AAM
parameters.
To define the access credenals, enter:
• User Name—User name used by Pathfinder to access your target host.
• Password—Password used by Pathfinder to access your target host.
Only encrypted credenals are stored on the broker VM.
To allow Pathfinder to use credenals stored in your CyberArk vault, enter the
following parameters. Make sure you are following the CyberArk guidelines.
• URL—Your CyberArk AAM URL address.
• Port—Your CyberArk AAM port number.
• App ID—The applicaon ID configured in your CyberArk AAM. The ID allows you
to access the path to where credenals are stored in the CyberArk vault.
• Query—Define the CyberArk AAM path to the credenals required by Pathfinder
to access the host. Make sure you are following the CyberArk formang
guidelines.
• Browse for your Client Cerficate, Client Key, and CA Cerficate you use to
idenfy. Cortex XDR will nofy you when your cerficates are about to expire.
Credenals are not stored on the broker VM, Pathfinder queries CyberArk
each me according to the defined parameters.
• Test the credenals and pathfinder permissions to ensure the broker VM can
successfully collect data from your defined hosts.
Tesng may take a few minutes to complete but ensures that pathfinder can
indeed deploy a data collector.
Broker VM
Select Next.
2. Define the data collector sengs.
• Select on which Targets to deploy the data collector. Target types are detected
according to your operang system.
• All—Deploy on all assets within your network.
• Servers—Deploy only on servers.
• Workstaons—Deploy only on workstaons.
• Define the Proxy Sengs.
By default the proxy sengs are disabled, data collected is sent directly to the cloud.
If you want to enable the proxy, select one of the following opons:
• Use Agent Proxy Sengs—Data collected will be routed using the sengs
provided in the Agent Proxy Applet. Agent proxy applet must be enabled for this
sengs to work.
• Use Custom Proxy—Define the IP address and port to route the data.
Select Next.
3. Select the IP Address Ranges to scan from the your defined Network Configuraons and
deploy the data collector. You can Add IP Address Ranges if you don’t see a range in the
populated list.
By default, every IP address range will use the Pathfinder credenals and sengs you
defined in the Credenals secon, and is labeled as an Applet Configuraon.
If you want configure other credenals for a specific range, use the right pane to override
the sengs. IP address ranges you edit are labeled as a Custom Configuraon. Make
sure to Test the credenals for this specific range.
The Pathfinder configuraon must contain at least one IP address range to run.
To avoid collision, IP address ranges can only be associated with one pathfinder
applet.
4. Acvate your Pathfinder.

Aer a successful acvaon, the Apps field displays the Pathfinder - Active,
Connected.
STEP 4 | In the Apps filed, select Pathfinder to view the following applet metrics:
• Handled Tasks—How many collectors are in progress, pending, or successfully running out
of the number of collectors that need to be setup.
• Failed Tasks—How many collectors have failed
Broker VM
STEP 5 | Manage the Pathfinder.

Right-click your broker VM and select:
• Pathfinder > Edit Configuraon to redefine your pathfinder configuraons.
• Pathfinder > Edit Credenals to redefine the user name and password.
You can select to edit credenals for mulple Pathfinder applets. However, only IP address
ranges that use the default defined credenals, labeled as Applet Configuraon, will adopt
your changes.
• Pathfinder > Deacvate to remove pathfinder.
STEP 6 | Track the Pathfinder Data Collector.

Aer the Pathfinder collector has been triggered, when an analycs type alert is triggered on
an unmanaged host, the data collector is deployed to unmanaged assets within the defined IP
address ranges and domain names.
The data collector is only deployed on unmanaged hosts, if you want to install the
Cortex XDR agent on an unmanaged host you must first remove the collector.
To track the data collector:

1. In Cortex XDR, select Sengs > Configuraons > Data Broker > Broker VMs >
Pathfinder Collecon Center.
The Pathfinder Collecon Center table displays the following fields about each of the
deployed collectors:
Field Descripon
Collector Install Time Timestamp of when the collector was installed

in the host.
Iniang Alert ID Displays the Alert ID of the analycs alert that

triggered the collector.
Iniang VM Name of the broker VM iniang the

collector.
Last Seen Timestamp of the last collector heartbeat.
Result Status of the collecon process. Can be:

• Collecon Completed
• Collecon Completed
Start Time Timestamp of when the collector was

triggered.
Status Status of the collector on the host. Can be:

• Pending
Broker VM
Field Descripon
• Running
• Completed
• Failed
• Removed
Target IP IP Address of the host scanned by the

collector.
2. Manage the collector.

• Set the number of collectors you want deployed. Set Collectors Number to limit the
number of collectors you want to deploy in your environment.
• Locate the collector, right-click and select:
• Remove Collector—Uninstall the collector from the host.
• View Iniang alert—Pivot to the Alerts Table filtered according to the iniang
alert.
• Retrieve Logs—Upload logs from the collector
• Download Logs—Download the collector logs to your local machine.
When you select and right-click the Target IP field, you can choose to view the IP
address in the IP View or Open in Quick Launcher.
STEP 7 | Query the collector data.

Data gathered by the data collector can be queried and invesgated from the Query Center. To
run a query on the EDR data from an unmanaged host:
1. Navigate to Invesgaon > Query Center.
2. Select the type of query you want to run and enter the search criteria.
When defining the Host aributes, for INSTALLATION TYPE make sure to select Data
Collector.
3. View your query results.
Acvate the Windows Event Collector

Aer you have configured and registered your broker VM, acvate your Windows Event Collector
applicaon.
The Windows Event Collector (WEC) runs on the broker VM collecng event logs from Windows
Servers, including Domain Controllers (DCs). The Windows Event Collector can be deployed in
mulple setups, and can be connected directly to mulple event generators (DCs or Windows
Servers) or routed using one or more Windows Event Collectors. Behind each Windows event
collector there may be mulple generang sources.
To enable the collecon 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 authencaon over TLS using server and client cerficates.
Broker VM
The WEF, a WinRM plugin, runs under the Network Service account. Therefore, you need to
provide the WEFs with the relevant cerficates and grant the account access permissions to the
private key used for client authencaon, for example, authencate with WEC.
You can also acvate the Windows Event Collector on Windows Core. For more
informaon, see Acvate the Windows Event Collector on Windows Core.
Ensure you meet the following prerequisites before acvang the collector.
• Cortex XDR Pro per TB license
• Broker VM version 8.0 and later
• You have knowledge of Windows Acve Directory and Domain Controllers.
• 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 informaon on
configuring the Broker VM FQDN, see Edit Your Broker VM Configuraon.
• Windows Server 2012 r2 or later.
STEP 1 | In Cortex XDR, select Sengs > Configuraons > Data Broker > Broker VM and locate your
broker VM.
STEP 2 | Right-click and select Windows Event Collector > Acvate.
STEP 3 | In the Windows Event Collecon Configuraon window, define the following.
Define the events collected by the applet. This lists event sources from which you want to
collect events.
• Source—Select from the pre-populated list with the most common event sources on
Windows Servers. The event source is the name of the soware that logs the events.
A source provider can only appear once in your list. When selecng event sources,
depending on the type event you want to forward, ensure the event source is enabled, for
Broker VM
example auding security events. If the source is not enabled, the source configuraon in
the given row will fail.
• Min. Event Level—Minimum severity level of events that are collected.
• Event IDs Group—Whether to Include, Exclude, or collect All event ID groups.
• Event IDs—(Oponal) Define specific event IDs or event ID ranges you want to collect.
Make sure to select aer each entry.
• Minimal TLS Version—Select either 1.0 or 1.2 (default) as the minimum TLS version allowed.
Ensure that you verify that all Windows event forwarders are supporng the minimal
defined TLS version.
For example, to forward all the Windows Event Collector events to the broker VM, define as
follows:
• Source—ForwardedEvents
• Min. Event Level—Verbose
• Event IDs Group—All
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 detecon funconality. Restore to Default to reinstate the Security event
collecon.
STEP 4 | Acvate your configuraons.

Aer a successful acvaon, the Apps field displays Windows Event Collector -
Active, Connected.
STEP 5 | In the Windows Event Forwarder Configuraon window, perform the following tasks.
1. (copy) the Subscripon Manage URL. This will be used when you configure the
subscripon manager in the GPO (Global Policy Object) on your domain controller.
2. Define Client Cerficate Export Password used to secure the downloaded WEF
cerficate used to establish the connecon between your DC/WEF and the WEC. You
will need this password when the cerficate is imported to the events forwarder.
3. Download the WEF cerficate in a PFX format to your local machine.
To view your Windows Event Forwarding configuraon details at any me, select your
Broker VM, right-click and navigate to Windows Event Collector > Configure Forwarder.
Cortex XDR monitors the cerficate and triggers a Cerficate Expiraon noficaon 30 days
prior to the expiraon date. The noficaon is sent daily specifying the number of days le on
the cerficate, or if the cerficate has already expired.
Broker VM
STEP 6 | Install your WEF Cerficate on the WEF to establish connecon.
You must install the WEF cerficate 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 Cerficate Import Wizard.
2. In the Cerficate Import Wizard:
1. Select Local Machine followed by Next.
2. Verify the File name field displays the PFX cerficate file you downloaded and select
Next.
3. In the Passwords field, specify the Client Cerficate Export Password you defined in
the Cortex XDR console followed by Next.
4. Select Automacally select the cerficate store based on the type of cerficate
followed by Next and Finish.
3. From a command prompt, run certlm.msc.
4. In the file explorer, navigate to Cerficates and verify the following for each of the
folders.
• In the Personal > Cerficates folder, ensure the cerficate
forwarder.wec.paloaltonetworks.com appears.
• In the Trusted Root Cerficaon Authories > Cerficates folder, ensure the CA
ca.wec.paloaltonetworks.com appears.
5. Navigate to Cerficates > Personal > Cerficates.
6. Right-click the cerficate and navigate to All tasks > Manage Private Keys.
7. In the Permissions window, select Add and in the Enter the object name secon, specify
NETWORK SERVICE followed by Check Names to verify the object name. The object
name is displayed with an underline when valid. and then OK.
Broker VM
8. Select OK, verify the Group or user names appear, and then Apply Permissions for privet
keys.
STEP 7 | Add the Network Service account to the domain controller Event Log Readers group.
the broker VM.
1. To enable events forwarders to forward events, the Network Service account must be
a member of the Acve Directory Event Log Readers group. In PowerShell, execute the
following command on the domain controller that is acng 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.
1. Run wevtutil gl security and take note of your channelAccess value.
For example:
`PS C:\Users\Administrator> wevtutil gl security

name: security
enabled: true
type: Admin
owningPublisher:
isolation: Custom
channelAccess: O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)
(A;;0x1;;;S-1-5-32-573)
logging:
logFileName: %SystemRoot%\System32\Winevt\Logs
\security.evtx
retention: false
autoBackup: false
maxSize: 134217728
publishing:
Broker VM
fileMax: 1
Take note of value: channelAccess: O:BAG:SYD:(A;;0xf0005;;;SY)

(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)
2. Run wevtutil sl security "/ca:<channelAccess
value>(A;;0x1;;;S-1-5-20)"
For example:
PS C:\Users\Administrator> wevtutil sl security

"/ca:O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)
(A;;0x1;;;S-1-5-32-573)(A;;0x1;;;S-1-5-20)"
Make sure you grant access on each of your domain controller hosts.
STEP 8 | 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: Windows Event
Forwarding followed by 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:

• Set the Windows Remote Management Service for automac startup.
• Select Computer Configuraon > Policies > Windows Sengs > Security Sengs
> System Services, and in the view panel locate and double-click Windows Remote
Management (WS-Management).
• Mark Define this policy seng and select Automac followed by Apply and OK.
• At a minimum for your WEC configuraon, you must enable logging of the same
events that you have configured to be collected in your WEC configuraon 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
authencaon events to be collected by your WEC using an authencaon protocol,
such as Kerberos, you should ensure all relevant audit events for authencaon are
Broker VM
configured on your domain controller. In addion, 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, parcularly for those that you
want Cortex XDR to apply grouping and analycs inspecon.
This step overrides any local policy sengs.
Here is an example of how to configure the WEC to collect authencaon events

using Kerberos as the authencaon protocol to enable the collecon of Broker VM
supported Kerberos events, Kerberos pre-authencaon, authencaon, request, and
renewal ckets.
> Advanced Audit Policy Configuraon > Audit Policies > Account Logon.
• In the view pain, right-click Audit Kerberos Authencaon Service and select
Properes. In the Audit Kerberos Authencaon Service window, mark Configure
Broker VM
the following audit events:, select to Success and Failure followed by Apply and
OK.
Repeat for Audit Kerberos Service Ticket Operaons.
6. Configure the subscripon manager.
Navigate to Computer Configuraon > Policies > Administrave Templates: Policy
definions > Windows Components > Event Forwarding, right-click Configure target
Subscripon Manager and select Edit.
In the Configure target Subscripon Manager window.

1. Mark Configure target Subscripon Manager as Enabled.
2. In the Opons secon, select Show and in the Show Contents window, paste the
Subscripon Manage URL you copied from the Cortex XDR console followed by OK.
3. Select Apply and OK to save your changes.
7. Add Network Service to Event Log Readers group.
Select Computer Configuraon > Preferences > Control Panel Sengs > Local Users
and Groups, right-click and select New > Local Group.
In the New Local Group Properes window.

• In the Group name field, select Event Log Readers (built-in).
• In the Members secon, select Add and enter in the Name filed Network Service
followed by OK.
Broker VM
You must type out the name, do not select the name from the browse buon.
• Select 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 Configuraon > Policies >
Windows Sengs > Security Sengs > Windows Firewall with Advanced Security >
Outbound Rules, right-click and select New Rule.
In the New Outbound Rule Wizard define the following Steps.
1. Rule Type—Select Port followed by Next.
2. Protocols and Ports— Select TCP and in the Specific Remote Ports field enter 5986
followed by Next.
3. Acon—Select Allow the connecon followed by Next.
4. Profile—Select Domain and disable Private and Public followed by Next.
5. Name—Specify Windows Event Forwarding.
6. Select Finish to save your configuraons.
STEP 9 | 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 exisng GPO....
2. In the Select GPO window, select Windows Event Forwarding followed by OK.
3. In an administrave PowerShell console, execute the following commands.
1. PS C:\Users\Administrator> gpupdate /force
Verify Computer Policy update has completed successfully. User

Policy update has completed successfully. confirmaon message
appears.
2. PS C:\Users\Administrator> Restart-Service WinRM
Broker VM
STEP 10 | Verify Windows Event Forwarding.

1. In an administrave PowerShell console, run the following command.
PS C:\Users\Administrator> Get-WinEvent Microsoft-windows-

WinRM/operational -MaxEvents 10
2. Look for WSMan operaon EventDelivery completed successfully confirmaon

messages. These indicate events forwarded successfully.
STEP 11 | (Oponal) Manage the Window Event Collector.

Aer the Windows Event Collector has been acvated in the Cortex XDR Management
Console, right-click your broker VM and select:
• Windows Event Collector > Configure Forwarder to define the event configuraon
informaon.
• Windows Event Collector > Deacvate to disable the Windows Event Collector.
• Windows Event Collector > Collecon Configuraon to view or edit exisng or add new
events to collect.
STEP 12 | (Oponal) In the Apps field, select Windows Event Collector to view the following applet
metrics.
Acvate the Windows Event Collector on Windows Core

Aer you have configured and registered your broker VM, you can acvate your Windows Event
Collector applicaon 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 Acvate the Windows Event Collector.
The Windows Event Collector (WEC) runs on the broker VM collecng event logs from Windows
Servers, including Domain Controllers (DCs). The Windows Event Collector can be deployed in
mulple setups, and can be connected directly to mulple event generators (DCs or Windows
Servers) or routed using one or more Windows Event Collectors. Behind each Windows event
collector there may be mulple generang sources.
To enable the collecon 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 authencaon over TLS using server and client cerficates.
The WEF, a WinRM plugin, runs under the Network Service account. Therefore, you need to
provide the WEFs with the relevant cerficates and grant the account access permissions to the
private key used for client authencaon, for example, authencate with WEC.
Ensure you meet the following prerequisites before acvang the collector.
• Cortex XDR Pro per TB license
Broker VM
• Broker VM version 8.0 and later

• You have knowledge of Windows Acve Directory and Domain Controllers.
• 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 informaon on
configuring the Broker VM FQDN, see Edit Your Broker VM Configuraon.
• Windows Server 2012 r2 or later.
STEP 1 | In Cortex XDR, select Sengs > Configuraons > Data Broker > Broker VM and locate your
broker VM.
STEP 2 | Right-click and select Windows Event Collector > Acvate.
STEP 3 | In the Windows Event Collecon Configuraon window, define the following.
Define the events collected by the applet. This lists event sources from which you want to
collect events.
• Source—Select from the pre-populated list with the most common event sources on
Windows Servers. The event source is the name of the soware that logs the events.
A source provider can only appear once in your list. When selecng event sources,
depending on the type event you want to forward, ensure the event source is enabled, for
example auding security events. If the source is not enabled, the source configuraon in
the given row will fail.
• Min. Event Level—Minimum severity level of events that are collected.
• Event IDs Group—Whether to Include, Exclude, or collect All event ID groups.
• Event IDs—(Oponal) Define specific event IDs or event ID ranges you want to collect.
Make sure to select aer each entry.
• Minimal TLS Version—Select either 1.0 or 1.2 (default) as the minimum TLS version allowed.
Ensure that you verify that all Windows event forwarders are supporng the minimal
defined TLS version.
For example, to forward all the Windows Event Collector events to the broker VM, define as
follows:
• Source—ForwardedEvents
• Min. Event Level—Verbose
• Event IDs Group—All
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 detecon funconality. Restore to Default to reinstate the Security event
collecon.
STEP 4 | Acvate your configuraons.

Aer a successful acvaon, the Apps field displays Windows Event Collector -
Active, Connected.
Broker VM
STEP 5 | In the Windows Event Forwarder Configuraon window, perform the following tasks.
1. (copy) the Subscripon Manage URL. This will be used when you Configure the
cerficate used to establish the connecon between your DC/WEF and the WEC. You
will need this password when the cerficate is imported to the events forwarder.
To view your Windows Event Forwarding configuraon details at any me, select your
Broker VM, right-click and navigate to Windows Event Collector > Configure Forwarder.
Cortex XDR monitors the cerficate and triggers a Cerficate Expiraon noficaon 30 days
prior to the expiraon date. The noficaon is sent daily specifying the number of days le on
the cerficate, or if the cerficate has already expired.
STEP 6 | Install your WEF Cerficate on the WEF to establish connecon.

1. Start PowerShell with elevated privileges.
1. Run PowerShell with the following command.
PowerShell
2. From inside a PowerShell command run the following command.
Start-Process -Verb RunAs PowerShell
2. Copy the PFX file that you downloaded to the local Core machine in one of the following
ways.
• If you're able to RDP to your server, open Notepad, and select File > Open to copy
and paste files from your local machine directly to the server. If you have any local
drives mapped through the RDP opons, the local drives are also displayed. We
recommend this method as it's the simplest.
• If you have enabled WinRM for remote PowerShell execuon, you can copy over
PowerShell using this command.
$session = New-PSSession –ComputerName <computer name>
Copy-Item –Path <path to PFX certificate file> –Destination

'<temporary file path>' –ToSession $session
For example.
$session = New-PSSession –ComputerName SERVER1
Copy-Item –Path C:\Downloads

\forwarder.wec.paloaltonetworks.com.pfx –Destination 'C:
Broker VM
\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 opon if you are an administrator and the firewall on your network isn't set to
block file sharing.
You can also launch PowerShell and run the following command to tell the remote
server to copy a file from your local computer using SMB.
Copy-Item –Path <path to PFX certificate file> –Destination

'\\<computer name>\c$\<path to PFX file>
For example.
Copy-Item –Path C:\Downloads

\forwarder.wec.paloaltonetworks.com.pfx
Broker VM
–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>'
For example.
certutil -f -importpfx '.

\forwarder.wec.paloaltonetworks.com.pfx'
You will need to enter the Client Cerficate 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 cerficates are in the correct locaons.

• Ensure the client cerficate appears in "My" (Personal) store by running the following
command.
certutil -store My
• Ensure the CA appears in Trusted Root Cerficaon Authories by running the

following command.
certutil -store root
5. Manage the private key of the forwarder.wec.paloaltonetworks.com.pfx

cerficate.
This entails applying permissions for the NETWORK SERVICE user.
1. Retrieve the Thumbprint of the forwarder.wec.paloaltonetworks.com.pfx
cerficate by running the following script.
$store = New-Object
System.Security.Cryptography.X509Certificates.X509Store("My","LocalMac
$store.Open("ReadWrite")
echo $store.Certificates
Aer the script runs, copy the relevant thumbprint.

2. Grant NT AUTHORITY\NETWORK SERVICE with read permissions by running the
following script with the $thumbprint set to the value you copied in the previous
step by replacing <Thumbprint retrieved value>.
$thumbprint = '<Thumbprint retrieved value>'

$account = 'NT AUTHORITY\NETWORK SERVICE'
#Open Certificate store and locate certificate based on
provided thumbprint
Broker VM
$store = New-Object
System.Security.Cryptography.X509Certificates.X509Store("My","LocalMac
$store.Open("ReadWrite")
$cert = $store.Certificates | where {$_.Thumbprint -eq
$thumbprint}
#Create new CSP object based on existing certificate

provider and key name
$csp = New-Object
System.Security.Cryptography.CspParameters($cert.PrivateKey.CspKeyCont
$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,"GenericRea
# Add access rule to CSP object
$csp.CryptoKeySecurity.AddAccessRule($access)
#Create new CryptoServiceProvider object which updates Key

with CSP information created/modified above
$rsa2 = New-Object
System.Security.Cryptography.RSACryptoServiceProvider($csp)
#Close certificate store

$store.Close()
echo $csp.CryptoKeySecurity
3. Aer the script runs, validate the permissions are now set correctly.
Broker VM
STEP 7 | Add the Network Service account to the domain controller Event Log Readers group.
the broker VM.
1. To enable events forwarders to forward events, the Network Service account must be
a member of the Acve Directory Event Log Readers group. In PowerShell, execute the
following command on the domain controller that is acng as the event forwarder:
PS C:\> net localgroup "Event Log Readers" "NT Authority

\Network Service" /add
Make sure you see the following message.
The command completed successfully.
2. Grant access to view the security event logs.

1. Run wevtutil gl security and take note of your channelAccess value.
For example:
`PS C:\Users\Administrator> wevtutil gl security

name: security
enabled: true
type: Admin
owningPublisher:
isolation: Custom
channelAccess: O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)
(A;;0x1;;;S-1-5-32-573)
logging:
logFileName: %SystemRoot%\System32\Winevt\Logs
\security.evtx
retention: false
autoBackup: false
maxSize: 134217728
publishing:
fileMax: 1
Take note of value: channelAccess: O:BAG:SYD:(A;;0xf0005;;;SY)

(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)
2. Run wevtutil sl security "/ca:<channelAccess
value>(A;;0x1;;;S-1-5-20)"
For example:
PS C:\Users\Administrator> wevtutil sl security

"/ca:O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)
(A;;0x1;;;S-1-5-32-573)(A;;0x1;;;S-1-5-20)"
Make sure you grant access on each of your domain controller hosts.
Broker VM
STEP 8 | 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 soluon. As
a result, follow this alternave 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 connecon between the servers with a simple
ping.
2. Run cmd as an administrator.
3. Run the following command.
gpmc.msc /gpcomputer: <computer name.Domain>
For example.
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: Windows Event
Forwarding followed by 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:

• Set the Windows Remote Management Service for automac startup.
> System Services, and in the view panel locate and double-click Windows Remote
Management (WS-Management).
• Mark Define this policy seng and select Automac followed by Apply and OK.
• At a minimum for your WEC configuraon, you must enable logging of the same
events that you have configured to be collected in your WEC configuraon 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
authencaon events to be collected by your WEC using an authencaon protocol,
Broker VM
such as Kerberos, you should ensure all relevant audit events for authencaon are
configured on your domain controller. In addion, 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, parcularly for those that you
want Cortex XDR to apply grouping and analycs inspecon.
This step overrides any local policy sengs.
Here is an example of how to configure the WEC to collect authencaon events

using Kerberos as the authencaon protocol to enable the collecon of Broker VM
supported Kerberos events, Kerberos pre-authencaon, authencaon, request, and
renewal ckets.
> Advanced Audit Policy Configuraon > Audit Policies > Account Logon.
• In the view pain, right-click Audit Kerberos Authencaon Service and select
Properes. In the Audit Kerberos Authencaon Service window, mark Configure
Broker VM
the following audit events:, select to Success and Failure followed by Apply and
OK.
Repeat for Audit Kerberos Service Ticket Operaons.
In the Configure target Subscripon Manager window.

2. In the Opons secon, select Show and in the Show Contents window, paste the
Subscripon Manager URL you copied from the Cortex XDR console followed by OK.
9. Add Network Service to Event Log Readers group.
Select Computer Configuraon > Preferences > Control Panel Sengs > Local Users
and Groups, right-click and select New > Local Group.
In the New Local Group Properes window.

• In the Group name field, select Event Log Readers (built-in).
• In the Members secon, select Add and enter in the Name filed Network Service
followed by OK.
Broker VM
You must type out the name, do not select the name from the browse buon.
• Select 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 Configuraon > Policies >
Windows Sengs > Security Sengs > Windows Firewall with Advanced Security >
Outbound Rules, right-click and select New Rule.
In the New Outbound Rule Wizard define the following Steps.
1. Rule Type—Select Port followed by Next.
2. Protocols and Ports— Select TCP and in the Specific Remote Ports field enter 5986
followed by Next.
3. Acon—Select Allow the connecon followed by Next.
4. Profile—Select Domain and disable Private and Public followed by Next.
5. Name—Specify Windows Event Forwarding.
6. Select Finish to save your configuraons.
STEP 9 | 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 exisng GPO....
2. In the Select GPO window, select Windows Event Forwarding followed by OK.
3. In an administrave PowerShell console, execute the following commands.
1. PS C:\Users\Administrator> gpupdate /force
Verify Computer Policy update has completed successfully. User

Policy update has completed successfully. confirmaon message
appears.
2. PS C:\Users\Administrator> Restart-Service WinRM
Broker VM
STEP 10 | Verify Windows Event Forwarding.

1. In an administrave PowerShell console, run the following command.
PS C:\Users\Administrator> Get-WinEvent Microsoft-windows-

WinRM/operational -MaxEvents 10
2. Look for WSMan operaon EventDelivery completed successfully confirmaon

messages. These indicate events forwarded successfully.
STEP 11 | (Oponal) Manage the Window Event Collector.

Aer the Windows Event Collector has been acvated in the Cortex XDR Management
Console, right-click your broker VM and select:
• Windows Event Collector > Configure Forwarder to define the event configuraon
informaon.
• Windows Event Collector > Deacvate to disable the Windows Event Collector.
• Windows Event Collector > Collecon Configuraon to view or edit exisng or add new
events to collect.
STEP 12 | (Oponal) In the Apps field, select Windows Event Collector to view the following applet
metrics.
Renew WEC Cerficates

Renewing your WEC cerficates in Cortex XDR includes renewing your Windows Event
Forwarding (WEF) client cerficate and your WEC server cerficate. You must install the WEF
cerficate 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.
Cortex XDR displays a noficaon for any tenant with an acve WEC applet containing a
Cerficate Authority (CA) cerficate that expires in less than 90 days. You will see these
noficaons in the following places unl the WEC cerficates are replaced.
Aer you receive a noficaon for renewing your WEC CA cerficate, we recommend
that you do not add any new WEF clients unl the WEC cerficaon renewal process is
complete. Events from these WEF clients that are added aerwards will not be collected
by the server unl the WEC cerficates are renewed.
• In the Broker VMs page, the health status of the Windows Event Collector applet is yellow.
When your mouse hovers over the health status, a warning message is displayed indicang that
Your Windows Event Collector server cerficate expires in X days.
• Unl you renew your broker VM WEC server cerficate, a warning message is displayed in the
Windows Event Forwarder Configuraons window.
Broker VM
• A new noficaon entled WEC Cerficate Authority Expiraon is displayed in the

noficaon area unl the cerficates are renewed.
In addion, Cortex XDR manages the renewal of your WEC cerficates by implemenng the
following me limits.
• The WEC CA cerficate is increased for an extended period of me for a maximum of 20 years.
• The broker VM applet includes an automac renewal mechanism for a WEC server cerficate,
which has a lifespan of 12 months.
• The WEC client cerficate aer the renewal is issued with a lifespan of 5 years.
To renew your WEC cerficates:
Broker VM
STEP 1 | Renew your WEF client cerficate in Cortex XDR.

1. In Cortex XDR, select Sengs > Configuraons > Data Broker > Broker VMs, and locate
your broker VM.
2. Right-click and select Windows Event Collector > Configure Forwarder.
3. In the Windows Event Forwarder Configuraon window:
1. (copy) the Subscripon Manage URL. This will be used when you configure the
cerficate used to establish the connecon between your DC/WEF and the WEC.
You will need this password when the cerficate is imported to the events forwarder.
4. Install your WEF Cerficate on the WEF to establish connecon.
You must install the WEF cerficate 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 Cerficate Import Wizard.
2. In the Cerficate Import Wizard:
1. Select Local Machine followed by Next.
2. Verify the File name field displays the PFX cerficate file you downloaded and
select Next.
3. In the Passwords field, enter the Client Cerficate Export Password you defined in
the Cortex XDR console followed by Next.
4. Select Automacally select the cerficate store based on the type of cerficate
followed by Next and Finish.
3. From a command prompt, run certlm.msc.
4. In the file explorer, navigate to Cerficates and verify the following for each of the
folders:
• In the Personal > Cerficates folder, ensure the cerficate
forwarder.wec.paloaltonetworks.com appears.
• In the Trusted Root Cerficaon Authories > Cerficates folder, ensure the CA
ca.wec.paloaltonetworks.com appears.
Broker VM
You can see more than one ca.wec.paloaltonetworks.com and

forwarder.wec.paloaltonetworks.com file from a previous
installaon in the directory, so select the file with the most extended
Expiraon Date. You can verify that you are using the correct cerficate:
• To verify the client cerficate in the Personal >
Cerficates folder is related to the CA, you can select your
forwarder.wec.paloaltonetworks.com file and from the
Cerficaon Path tab, double-click ca.wec.paloaltonetworks.com. In the
Details tab, Show: Properes only, and verify the Thumbprint matches
the ca.wec.paloaltonetworks.com file Thumbprint.
• For the Trusted Root Cerficate (i.e. CA cerficate), you can verify the
Thumbprint of your ca.wec.paloaltonetworks.com file matches
the Subscripon Manage URL by double-clicking the file and from the
Details tab verifying the Thumbprint.
5. Navigate to Cerficates > Personal > Cerficates.
6. Right-click the cerficate and navigate to All tasks > Manage Private Keys.
7. In the Permissions window, select Add and in the Enter the object name secon,
enter NETWORK SERVICE followed by Check Names to verify the object name. The
object name is displayed with an underline when valid. and then OK.
8. Select OK, verify the Group or user names appear, and then Apply Permissions for
privet keys.
Broker VM

In the Configure target Subscripon Manager window:

2. In the Opons secon, select Show, and in the Show Contents window, paste the
Subscripon Manage URL that you copied from the Cortex XDR console followed by
OK.
6. Complete the WEF Client cerficate renewal.
On every WEF DC, perform the following from a command prompt.
1. Run gpupdate /force to update the group policy.
2. Restart-Service WinRM to apply the configuraons.
STEP 2 | Renew your WEC server cerficate in Cortex XDR.
You should only perform this step under the following condions.
• You have completed the WEF cerficaon renewal process for ALL clients in your
environment. Otherwise, events from the WEFs that you did not install the new
client cerficate will not be collected by the WEC.
• You are approaching the WEC server CA cerficate expiraon date, which is 2 years
aer the Windows Event Collector applet acvaon, and receive a noficaon in
the Cortex XDR console.
1. In Cortex XDR, select Sengs > Configuraons > Data Broker > Broker VMs, and locate
your broker VM.
2. Right-click and select Windows Event Collector > Renew WEC Server Cerficate.
3. Click Renew.
Once Cortex XDR renews the WEC server cerficate, the status of the Windows Event
Collector on the Broker VMs machine is Acve, Connected indicang the applet is
running. In addion, the health status of the Windows Event Collector applet is now
Broker VM
green instead of yellow and the warning message that appeared when you hovered over
the health status no longer appears. Your WEC server cerficate is issued with a lifespan
of 12 months.
We also suggest that in XQL Search that you run the following query to verify that your
event logs are being captured.
dataset = 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 mestamp from aer 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 sll having a problem, contact
Technical Support.
Broker VM
Manage Your Broker VMs

Aer you configured the broker VMs, you can manage your broker VMs from the Cortex XDR
management console as follows.
• View Broker VM Details
• Edit Your Broker VM Configuraon
• Collect Broker VM Logs
• Reboot a Broker VM
• Shut Down a Broker VM
• Upgrade a Broker VM
• Open Remote Terminal
• Remove a Broker VM
View Broker VM Details

In Cortex XDR, select Sengs > Configuraons > Data Broker > Broker VMs to view detailed
informaon regarding your registered broker VMs.
The Broker VMs table enables you to monitor and mange your broker VM and applet connecvity
status, version management, device details, and usage metrics.
add to the alerts table using the column manager and lists the fields in alphabecal order.
Field Descripon
Status Indicator Idenfies 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 applicaons 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
Check box to select one or more broker devices

on which to perform acons.
Broker VM
Field Descripon
APPS List of acve or inacve applets and the

connecvity status for each.
CPU USAGE CPU usage of the broker device in percentage

synced every 5 minutes.
CONFIGURATION STATUS Broker VM configuraon status. Status is defined

by the following according to changes made to
any of the broker VM configuraons.
• up to date—Broker VM configuraon changes
made through the Cortex XDR console have
been applied.
in progress—Broker VM configuraon changes
made through the Cortex XDR console are
being applied.
submied—Broker VM configuraon changes
made through the Cortex XDR console have
reached the broker machine and awaing
implementaon.
failed—Broker VM configuraon changes made
through the Cortex XDR console have failed.
Need to open a Palo Alto Networks support
cket.
DEVICE ID Device ID allocated to the broker machine by

Cortex XDR aer registraon.
DEVICE NAME Same as the Device ID.

A
icon
nofies of an expired broker. To reconnect,
generate a new token and re-register your broker
as described in steps 1 through 7of Configure the
Broker VM. Once registered, all previous broker
configuraons are reinstated.
DISK USAGE Disk usage of the broker in poron of computer

storage that is currently in use.
Noficaon about low disk space appear in the
Noficaon Center.
EXTERNAL IP The IP interface the broker is using to

communicate with the server.
Broker VM
Field Descripon
For AWS and Azure cloud environments, the field
displays the Internal IP value.
INTERNAL IP All IP addresses of the different interfaces on the

device.
MEMORY USAGE Memory usage of the broker device in percentage

synced every 5 minutes.
STATUS Connecon status of the broker device. Status is

defined by either Connected or Disconnected.
Disconnected broker devices do not display
CPU Usage, Memory Usage, and Disk Usage
informaon.
Noficaons about the broker VM losing
connecvity to Cortex XDR appear in the
Noficaon Center.
UPGRADE TIME Timestamp of when the broker device was

upgraded.
VERSION Version number of the broker device. If the status

indicator is not green, then the broker is not
running the latest version.
Noficaons about the available new broker VM
version appear in the Noficaon Center.
Edit Your Broker VM Configuraon

Aer configuring and registering your broker VM, select Sengs > Configuraons > Data Broker
> Broker VMs to edit exisng configuraons and define addional sengs.
STEP 1 | In the Broker VMs table, locate your broker VM, right-click and select Broker Management >
Configure.
If the broker VM is disconnected, you can only View the configuraons.
STEP 2 | In the Broker VM Configuraons window, define the following sengs:

• Edit the exisng Network Interfaces, Proxy Server, NTP Server, and SSH Access
configuraons.
• (Requires Broker VM 8.0 and later) Device Name.
-Device Name—Change the name of your broker VM device name by selecng the pencil
icon. The new name will appear in the Broker VMs table.
-FQDN—Set your Broker VM FQDN as it will be defined in your Domain Name System
(DNS). This enables connecon between the WEF and WEC, acng as the subscripon
Broker VM
manager. The Broker VM FQDN sengs affect the WEC and Agent Installer and Content
Caching.
• (Requires Broker VM 8.0 and later) (Oponal) 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:

• Formaed 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 will accept only
172.17.0.0/16.
• Auto Upgrade
Enable or Disable automac upgrade of the broker VM. By default, auto upgrade is
enabled at Any me for all 7 days of the week, but you can also set the Days in Week and
Specific me for the automac 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 stascs in Prometheus
metrics format, allowing you to tap in and export data by navigang to http://
<broker_vm_address>:9100/metrics/. By default, monitoring your broker VM is
disabled.
• (Oponal) SSH Access
• (For 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 decrypon in your
firewalls, you need to add a trusted self-signed CA cerficate on the broker VM to
prevent any difficules with SSL decrypon. For example, when configuring Palo Alto
Networks NGFW to decrypt SSL using a self-signed cerficate, 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.
• (Requires 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
Broker VM
overwring 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.
• (Requires Broker VM 10.1.9 and later) (Oponal) In the SSL Server Cerficate secon,
upload your signed server cerficate and key to establish a validated secure SSL connecon
between your endpoints and the broker VM. When you configure the server cerficate and
the key files in the tenant UI, Cortex XDR automacally updates them in the Broker VM UI,
even when the Broker VM UI is disabled.
Cortex XDR validates that the cerficate and key match, but does not validate the
Cerficate Authority (CA).
STEP 3 | Save your changes.
Collect Broker VM Logs

Cortex XDR enables you to collect your broker VM logs directly from the Cortex XDR
management console.
You can collect logs by either regenerang the most up-to-date logs and downloading them
once they are ready, or downloading the current logs from the last creaon date reflected in the
TIMESTAMP.
STEP 1 | In Cortex XDR, select Sengs > Configuraons > Data Broker > Broker VMs to view the
Broker VMs table.
STEP 2 | Locate your broker VM, right-click and select one of these opons depending on the type of
logs you want to download.
• Broker Management > Generate New Logs— Regenerates the most up-to-date logs and
downloads them once they are ready.
• Broker Management > Download Logs (<TIMESTAMP>)—Downloads the logs from the last
creaon date reflected in the <TIMESTAMP> displayed. This opon is only displayed when
you’ve downloaded your logs previously using Generate New Logs.
Logs are generated automacally, but can take up to a few minutes depending on the size of
the logs.
Reboot a Broker VM
Cortex XDR enables you to reboot your broker VM directly from the Cortex XDR management
console.
STEP 1 | In Cortex XDR , select Sengs > Configuraons > Data Broker > Broker VMs > Broker VMs
table.
STEP 2 | Locate your broker VM, right-click and select Broker Management > Reboot VM.
Broker VM
Shut Down a Broker VM

Cortex XDR enables you to gracefully shutdown the broker VM directly from the Cortex XDR
Broker VMs table.
STEP 1 | Select Sengs > Configuraons > Data Broker > Broker VMs.
STEP 2 | Locate your broker VM in the Broker VMs table, right-click, and select Broker Management >
Shutdown VM.
Upgrade a Broker VM
You can upgrade any broker VM directly from the Cortex XDR management console.
STEP 1 | In Cortex XDR, select Sengs > Configuraons > Data Broker > Broker VMs table.
STEP 2 | Locate your broker VM, right-click and select Broker Management > Upgrade Broker
version.
Upgrading your broker VM takes approximately 5 minutes.
Open a Remote Terminal

Cortex XDR enables you to remotely connect to a broker VM directly from the Cortex XDR
console.
STEP 1 | In Cortex XDR, select Sengs > Configuraons > Data Broker > Broker VMs table.
Broker VM
STEP 2 | Locate the broker VM you want to connect to, right-click and select Open Remote Terminal.
Cortex XDR opens a CLI window where you can perform the following commands:
• Logs
Broker VM logs located are located in /data/logs/ folder and contain the applet
name in file name. For example, folder /data/logs/[applet name], containing
container_ctrl_[applet name].log
• Ubuntu Commands
Cortex XDR Broker VM supports all Ubuntu commands. For example, telnet 10.0.0.10
80 or ifconfig -a.
• Sudo Commands
Broker VM supports the command listed in the following table. All the commands are
located in the /home/admin/sbin folder.
Cortex XDR requires you use the following values when running commands:
Applet Names
• CSV Collector—file_collector
• Database Collector—db_collector
• Files and Folders Collector—log_collector
• FTP Collector— ftp_collector
• Kaa Collector—kafka_collector
• Local Agent Sengs—tms_proxy
• NetFlow Collector—netflow_collector
• Network Mapper—network_mapper
• Pathfinder—odysseus
• Syslog Collector—anubis
• Windows Event Collector—wec
Services
• Upgrade—zenith_upgrade
• Frontend service—webui
• Sync with Cortex 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 alphabecal order.
Broker VM
Command Descripon 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 sudo ./applets_status

more applets. wec
applets_stop Stop one or more applets. sudo ./applets_stop

wec
hostnamectl Check and update the sudo ./hostnamectl

machine hostname on a Linux set-hostname
operang system. <new_host_name>
Restart machine aer running
command.
kill Linux kill command. sudo ./kill [some

pid]
restart_routes Invoke a restart of the sudo ./restart_routes

roung service aer updang
your stac network route You can either
configuraon file, /etc/ restart_routes
network/routes. or reboot the
broker VM
The /etc/network/
machine for
routes configuraon file
the changes
is a standard Ubuntu routes in the /etc/
configuraon file and can be
network/
edited directly. The admin
routes file to
user that you logged in with,
take affect.
when using the remote
terminal or via SSH, has read/
write permissions to this file.
route Modify your IP address sudo ./route

roung.
services_restart Restarts one or more sudo ./

services. OS services are not services_restart
supported. cloud_sync
services_start Start one or more services sudo ./services_start

cloud_sync
Broker VM
Command Descripon Example
services_status Check the status of one or sudo ./

more services. services_status
cloud_sync
services_stop Stop one or more services. sudo ./

services_restart
cloud_sync
set_ui_password.sh Change the password of the sudo ./

Broker VM Web UI. set_ui_password.sh
Run the command, enter the
new password followed by
Ctrl+D.
squid_tail Display the Proxy applet sudo ./squid_tail

Squid log file in real-me.
tcpdump Linux capture network traffic sudo ./tcpdump -

command. i eth0 -w /tmp/
packets.pcap
You must use -w flag in order
to print output to file.
Remove a Broker VM
Cortex XDR allows you to remove a broker VM directly from the Cortex XDR management
console.
STEP 1 | In Cortex XDR, select Sengs > Configuraons > Data Broker > Broker VMs.
STEP 2 | Locate your broker VM, right-click and select Broker Management > Remove Broker.
Broker VM
Broker VM Noficaons
To help you monitor your broker VM version and connecvity effecvely, Cortex XDR sends
noficaons to your Cortex XDR console Noficaon Center.
Cortex XDR sends the following noficaons:
• New Broker VM Version—Nofies when a new broker VM version has been released.
• If the broker VM Auto Upgrade is disabled, the noficaon includes a link to the latest
release informaon. It is recommend you upgrade to the latest version.
• If the broker VM Auto Upgrade is enabled, 12 hours aer the release you are nofied of the
latest upgrade, or your are nofied that the upgrade failed. In such a case, open a Palo Alto
Networks Support Ticket.
• Broker VM Connecvity—Nofies when the broker VM has lost connecvity to Cortex XDR.
• Broker VM Disk Usage—Nofies when the broker VM is ulizing over 90% of the allocated disk
space.
Broker VM
Cortex XDR Collectors
Cortex XDR provides a XDR Collectors configuraon that is dedicated for on-premise
data collecon on Windows and Linux machines. The collector includes a dedicated
installer, a collector upgrade configuraon, content updates, and policy management.
> Collector Machine Requirements and Supported Operang Systems

> Resources Required to Enable Access to Cortex XDR Collectors
> Configure the Cortex XDR Collector Upgrade Scheduler
> Manage XDR Collectors
> Define Collector Machine Groups
> About XDR Collector Content Updates
> Add a XDR Collector Profile
> Apply Profiles to Collecon Machine Policies
> XDR Collector Datasets
589
Collector Machine Requirements and Supported

Operang Systems
You can configure Cortex XDR Collectors that are dedicated for on-premise data collecon on
Windows and Linux machines. The following hardware and soware specificaons are required
for the collector machines.
Machine Operang System Requirement Specificaons
Linux Processor 2.3 GHz dual-core
RAM 4GB; 8GB recommended
Hard disk space 10GB
Architecture x86 64-bit
Kernel version 2.6.32
Supported operang system • Red Hat Enterprise Linux 6

versions
• Red Hat Enterprise Linux 7
• Red Hat Enterprise Linux 8
• SUSE Linux Enterprise
Server 12
Server 15 SP0
Server 15 SP1
Server 15 SP2
• Ubuntu Server 12
Soware packages • Verify you have standard

Unix programs installed.
• ca-cerficates
• openssl 1.0.0 or a later
release

• Distribuons with SELinux
in enforcing or permissive
mode:
• Red Hat Enterprise
Linux 6, CentOS 6,
and Oracle Linux 6—
policycoreuls-python
• Red Hat Enterprise
Linux 7, CentOS 7,
and Oracle Linux 7—
policycoreuls-python
and selinux-policy-devel
• SUSE—policycoreuls-
python and selinux-
policy-devel
• Debian and Ubuntu
—policycoreuls and
selinux-policy-dev
• CentOS 6.10—Enable the
dynamic CA instead of the
legacy CA:
1. Enable the dynamic CA
configuraon: update-
ca-trust force-
enable
2. Import the
cerficates: cp XDR-
certificate.crt /
etc/pki/ca-trust/
source/anchors/.
3. Rebuild the cerficate
database: update-ca-
trust extract
Networking • Allow communicaon from

the Cortex XDR Collector
TCP port to the server (the
default is port 443).
Windows Processor • Intel Penum 4 or later

with SSE2 instrucon set
support

• AMD Opteron/Athlon
64 or later with SSE2
instrucon set support
• Dual core processor
(minimum)
RAM 2GB minimum
Hard disk space 200MB minimum; 20GB

recommended
Supported operang system Windows 7 and later

versions
Networking • Allow communicaon from

the Cortex XDR Collector
TCP port to the server (the
default is port 443).
Applicaons and ulies • Windows Accessories

(Notepad) to view logs
Resources Required to Enable Access to Cortex XDR

Collectors
To enable access to Cortex 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 locaon in which IP addresses
are used. All customer data is stored in your deployment region, regardless of the IP
address registraon and restricts data transmission through any infrastructure to that
region. For consideraons, see Plan Your Cortex XDR Deployment.
Throughout this topic, <xdr-tenant> refers to the chosen subdomain of your Cortex
XDR tenant and <region> is the region in which your Cortex Data Lake is deployed. For
supported regions, see Plan Your Cortex XDR Deployment.
Refer to the following tables for the FQDNs, IP addresses, ports, and App-ID coverage for your
deployment.
• Required Resources by Region
• Required Resources for Federal (United States - Government)
For IP address ranges in GCP, refer to the following tables for IP address coverage for your
deployment.
• hps://www.gstac.com/ipranges/goog.json—Refer to this list to look up and allow access to
the IP address ranges subnets.
• hps://www.gstac.com/ipranges/cloud.json—Refer to this list to look up and allow access to
the IP address ranges associated with your region.
Table 18: Required Resources by Region
<xdr- IP address by region: cortex-xdr

• US—35.244.250.18
Used to connect to the Cortex • EU— 35.227.237.180
XDR management console.
• CA—34.120.31.199
• UK— 34.120.87.77
• JP—35.241.28.254
• SG— 34.117.211.129
• AU—34.120.229.65
• DE—34.98.68.183

• IN—35.186.207.80
Port—443
Used for the first request in
id and obtains the ch-<xdr-
of its tenant

installers-prod- • Port—443
us.storage.googleapis.com
Used to download installers
for upgrade acons from the
server.
This storage bucket is used for
all regions.

profiles- • Port—443
policy.storage.googleapis.com
updates.
ch-<xdr- IP address by region: traps-management-

• US—34.98.77.231
Used for all other requests • EU—34.102.140.103
between the agent and
its tenant server including • CA— 34.96.120.25
heartbeat, uploads, acon • UK—35.244.133.254
results, and scan reports.
• JP—34.95.66.187
• SG—34.120.142.18
• AU—34.102.237.151
• DE—34.107.161.143
• IN—34.120.213.188
Port—443
api-<xdr- IP address by region: —

• US—35.222.81.194
• EU— 34.90.67.58

Used for API requests and • CA—35.203.82.121
responses. • UK— 34.89.56.78
• JP—34.84.125.129
• SG—34.87.83.144
• AU—35.189.18.208
• DE—34.107.57.23
• IN—35.200.158.164
Port—443
See Integrate a Syslog

Receiver.
Table 19: Required Resources for Federal (United States - Government)
FQDN IP Addresses and Port App-ID Coverage Required for Cortex

XDR Collectors
distributions- • IP address— traps-

prod- 104.198.132.24 management-
fed.traps.paloaltonetworks.com
Used for the
first request
in registraon
flow where the
agent passes
the distribuon
ID and obtains
the ch-<xdr-
of its tenant

installers- • Port—443
prod-
Used to download
installers for upgrade
acons from the
server.

profiles-
FQDN IP Addresses and Port App-ID Coverage Required for Cortex

XDR Collectors
policy-prod- • Port—443
Used to download
content updates.
ch-<xdr- • IP address— traps-

130.211.195.231
tenant>.traps.paloaltonetworks.com management-
Used for all other
requests between the
agent and its tenant
server including
heartbeat, uploads,
acon results, and
scan reports.
api-<xdr- • IP address— —
130.211.195.231
Used for API requests • Port—443
and responses.
See Integrate a Syslog

Receiver.
Configure the Cortex XDR Collector Upgrade Scheduler

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 configuraon at any me of day.
To define the XDR Collector upgrade scheduler and number of parallel upgrades.
STEP 1 | In Cortex XDR, select Sengs > Configuraons > XDR Collectors > Configuraons.
STEP 2 | Set the XDR Collectors Configuraons sengs.

• 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 me (default) or at a Specific
me. When seng a specific me, you can set the From and To mes.
Manage XDR Collectors

Managing Cortex XDR Collectors includes the following tasks from the Sengs > Configuraons
> XDR Collectors > Administraon page.
• Create a XDR Collector Installaon Package
• Install the XDR Collector Installaon Package for Windows
• Install the XDR Collector Installaon Package for Linux
• XDR Collectors Installaon Resource for Windows and Linux
• Set an Applicaon Proxy for XDR Collectors
• Upgrade XDR Collectors
• Uninstall the XDR Collector
• Set an Alias for a Collector Machine
Create a XDR Collector Installaon Package

To install a Cortex XDR Collector for the first me, you must first create a XDR Collector
installaon package. Aer you create and download an installaon package, you can then install
it directly on the collector machine or you can use a soware deployment tool of your choice to
distribute the soware to mulple collector machines.
To install the Cortex XDR Collector soware, you must use a valid installaon package that exists
in your Cortex XDR Collectors console. If you delete an installaon package, any XDR Collectors
installed from this package are not able to register to Cortex XDR.
To move exisng 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 installaon package.
To create a new installaon package.

STEP 1 | In Cortex XDR, select Sengs ( ) > Configuraons > XDR Collectors > Installers.
STEP 2 | Create a new installaon package.
STEP 3 | Enter a unique Name and an oponal Descripon to idenfy the installaon package.
The package Name must be no more than 100 characters and can contain leers, numbers,
hyphens, underscores, commas, and spaces.
STEP 4 | Select the Plaorm for which you want to create the installaon package as either Windows
or Linux.
STEP 5 | Select the Version.
STEP 6 | Create the installaon package.

Cortex XDR prepares your installaon package and makes it available in the XDR Collectors
Installaons page.
STEP 7 | Download your installaon package.

When the status of the package shows Completed, right-click the Collector Version row, and
click Download.
• For a Windows installaon, select between the architecture type for the msi file to
download. You can Download 64 bit installer or Download 32 bit installer.
• For a Linux installaon, you can Download Linux RPM installer or Download Linux DEB
installer (according to your Linux collector machine distribuon), and deploy the installers
on the on-premise collector machines using the Linux package manager. Alternavely, you
can Download Linux SH installer and deploy it manually on the Linux collector machine.
Once the applicable installaon package is downloaded, you can install the package.
• Install the XDR Collector Installaon Package for Windows.
• Install the XDR Collector Installaon Package for Linux.

As needed, you can return to the XDR Collectors Installaons page to manage your XDR
Collectors installaon packages. To manage a specific package, right click the Collector Version,
and select the desired acon:
• Edit the package name or descripon.
• Delete the installaon package. Deleng an installaon package does not uninstall the
Cortex XDR Collector soware from any on-premise collector machines.
Since Cortex XDR relies on the installaon package ID to approve XDR Collector
registraon during install, it is not recommended to delete the installaon package
for any acve on-premise collector machines. Hiding the installaon package will
remove it from the default list of available installaon packages, and can be useful
to eliminate confusion in the XDR Collectors console main view. These hidden
installaon 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 installaon
package.
• Hide installaon packages. Using the Hide opon 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.
Install the XDR Collector Installaon Package for Windows

A standard Cortex XDR Collector installaon for windows is intended for standard physical
collector machines or persistent virtual collector machines. You can perform the Windows
installaon for the XDR Collectors using the MSI or Msiexec.
Install the XDR Collector on Windows Using the MSI

Use the following workflow to install the XDR Collector using the MSI file.
Before compleng this task, ensure that you create and download a Cortex XDR Collector
installaon package in Cortex XDR.
To install a XDR Collector installaon package on Windows using the MSI.
When the package is executed using the MSI, an installaon log is generated in %TEMP%
\MSI<Random characters>.log by default.
STEP 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.
STEP 3 | Select I accept the terms in the License Agreement and click Next.
STEP 4 | Install the XDR Collector.

The installer displays a User Account Control dialog.
STEP 5 | Click Yes.
STEP 6 | Aer you complete the installaon, verify the Cortex XDR Collector can establish a
connecon.
If the Cortex XDR Collector does not connect to Cortex XDR, verify your Internet
connecon on the collector machine. If the XDR Collector sll does not connect, verify
the installaon package has not been removed from the Cortex XDR management
console.
Install the XDR Collector on Windows Using Msiexec

Msiexec provides full control over the installaon process and allows you to install, modify, and
perform operaons on a Windows Installer from the command line interface (CLI). You can also
use Msiexec to log any issues encountered during installaon.
You can also use Msiexec in conjuncon with a System Center Configuraon Manager (SCCM),
Alris, Group Policy Object (GPO), or other MSI deployment soware to install the Cortex XDR
Collector on mulple collector machines for the first me.
When you install the Cortex XDR Collector with Msiexec, you must install the Cortex XDR
Collector per-machine and not per-user.
Although Msiexec supports addional opons, the Cortex XDR Collectors installers support only
the opons listed here. For example, with Msiexec, the opon to install the soware in a non-
standard directory is not supported—you must use the default path.
The following parameters apply to the inial installaon of the XDR Collector on the collector
machine.
• /i <installer path>\<installer file name>.msi DATA_PATH=<Path for
persistence, content, Filebeat application data, and transaction
data> PROXY_LIST=<Proxy address or name list> /quiet /l*v
<installation log path>—Install a package quietly, changes data path, adds proxies,
and creates an installaon 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.
• 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 and Filebeat logs.
• DATA_PATH—The path for persistence, content, Filebeat applicaon data, and transacon data.
• PROVISIONING_SERVER—Provisioning server address.
• DISTRIBUTION_ID
• ELB_ADDRESS—Load balancer for fresh XDR Collector installaon.
installaon package in Cortex XDR.
To install Cortex XDR Collectors using Msiexec:
STEP 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.
STEP 2 | Run the msiexec command followed by one or more supported opons and properes.
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
Install the XDR Collector Installaon Package for Linux

You can install the Cortex XDR Collector using three available packages for a Linux installaon—
Linux RPM, Linux DEB, and Linux SH. You can install the Cortex XDR Collector package on any
Linux server, including a physical or virtual machine, and as temporary sessions.
You can install Cortex 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 installaon.
installaon package.
To install the Cortex XDR Collectors installaon package for Linux.
STEP 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
STEP 2 | Install the Cortex XDR Collectors soware.

You can install the Cortex XDR Collectors on the collector machine manually using the shell
installer or using the Linux package manager for .rpm and .deb installers.
To deploy using package manager:
1. Depending on your Linux distribuon, install the Cortex XDR Collectors using one of the
following commands:
Distribuon Install Command
RHEL, CentOS, or Oracle • yum install ./filename.rpm

• rpm -i ./filename.rpm
Ubuntu or Debian • apt-get install ./filename.deb

• dpkg -i ./filename.deb
SUSE • zypper install ./filename.rpm

• rpm -i ./filename.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 execuon of the script using the chmod +x filename command.
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.
Addional opons are available to help you customize your installaon if needed. The
following table describes common opons 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 installaon.
Opon Descripon
--proxy-list Proxy Communicaon

”<proxyserver>:<port>”
Configure the Cortex XDR Collector to
communicate through an intermediary such as
a proxy.
To enable the XDR Collector to direct
communicaon to an intermediary, you use
this installaon opon to assign the IP address
and port number you want the Cortex 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 leers. Avoid using
special characters or spaces.
Use commas to separate mulple addresses.
For example:
--proxy-list "My.Network.Name:80
8, 10.196.20.244:8080"
Aer the inial installaon, you can change

the proxy sengs from using the configuraon
XML.
The Cortex XDR Collector does

not support proxy communicaon
in environments where proxy
authencaon is required.
--data-path <directory path> Directory Path

The path for persistence, content, Filebeat
applicaon data, and transacon data.
Opon Descripon
--data–path=/tmp/xdrLog
If the Cortex XDR Collector does not connect to Cortex XDR, verify your Internet
connecon on the collector machine. If the XDR Collector sll does not connect,
verify the installaon package has not been removed from the Cortex XDR
management console.
XDR Collectors Installaon Resource for Windows and Linux

The following table provides valuable informaon about the XDR Collectors installaon for
Windows and Linux.
Installaon Default Path Descripon Related Files/Services

Component
Installaon folder • Windows— The default • Windows

installaon path for
%PROGRAMFILES • Service
the XDR Collector.
%\Palo Alto name—XDR
Contains all Program
Networks\XDR Collector
Core files and
Collector executables. • Process name
• Linux— —xdrcollectorsvc.exe
/opt/ • Linux
paloaltonetworks/ • Service name
xdr-collector —xcd
• Process
name—xdr-
collector.service
Logs • Windows— Contains the For both Windows

XDR Collector and Linux:
%PROGRAMDATA
applicaon Log as
%\XDR • scouter.log
well as the Filebeat
Collector applicaon log. • filebeat
\logs Indicates informaon,
• Linux— warnings, and errors
related to the XDR
/opt/
Collector applicaon.
paloaltonetworks/
xdr-
collector/
logs
Installaon Default Path Descripon Related Files/Services

Component
Configuraon • Windows— Contains the For both Windows

configuraon file of and Linux, the
%PROGRAMFILES
the XDR Collector for file name is
%\Palo Alto
both Windows and XDR_Collector.xml.
Networks\XDR Linux.
Collector
\config
• Linux—
/opt/
paloaltonetworks/
xdr-
collector/
config
Persistence • Windows— Contains the For both Windows

Operang System and Linux, the
%PROGRAMDATA
persistence file for file name is
%\XDR
the XDR Collector, .scouter.json.
Collector which issued as part
\OSPersistence of the registraon
• Linux— process.
/etc/panw/
OSPersistence/
Set an Applicaon Proxy for XDR Collectors

In environments where Cortex XDR Collectors communicate with the Cortex XDR server through
a wide-system proxy, you can set an applicaon-specific proxy for the Cortex XDR Collector
without affecng the communicaon of other applicaons on the collector machine. You can
set the proxy aer installaon from the XDR Collectors Administraon 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 communicaon
between the XDR Collector and the Cortex XDR sever through the app-specific proxies fails, the
XDR Collector resumes communicaon through the system-wide proxy defined on the collector
machine. If that fails as well, the XDR Collector resumes communicaon with Cortex XDR directly.
STEP 1 | In Cortex XDR, select Sengs > Configuraons > XDR Collectors > Administraon.
STEP 2 | If needed, filter the list of on-premise collector machines.
STEP 3 | Set an agent proxy.

1. Select the row of the on-premise collector machine that you want to set a proxy.
2. Right-click the collector machine and select Set Collector proxy.
3. You can assign up to ten different proxies per XDR Collector. For each proxy, specify the
IP address and port number. Aer each Proxy Address and Port added, select to add
the values to a list underneath these fields.
4. Set when you’re done.
5. If necessary, you can later Disable Collector Proxy from the right-click menu.
When you disable the proxy configuraon, all proxies associated with that XDR Collector
are removed. The XDR Collector resumes communicaon with the Cortex XDR sever
through the wide-system proxy if defined, otherwise if a wide-system is not defined the
XDR Collector resumes communicang directly with the Cortex XDR server. If neither a
wide-system proxy nor direct communicaon exist and you disable the proxy, the XDR
Collector disconnects from Cortex XDR.
Upgrade XDR Collectors

Aer you install the Cortex XDR Collector and the XDR Collector registers with Cortex XDR,
you can upgrade the Cortex XDR Collector soware for on-premise Windows or Linux collector
machine. You need to create a new installaon packages and push the Cortex XDR Collector
package to up to 500 collector machines from Cortex XDR.
Upgrades are supported using acons which you can iniate from the Incident Response >
Response > Acon Center or Sengs > XDR Collectors > Administraon page as described in
this workflow.
STEP 1 | Create a XDR Collector Installaon PackageCreate an XDR Collector Installaon Package for
each operang system version that you want to upgrade the Cortex XDR Collector.
Note the installaon package names.
STEP 2 | Select Sengs > XDR Collectors > Administraon.

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.
STEP 3 | Select the collector machines you want to upgrade.

You can also select collector machines running different operang systems to upgrade the XDR
Collectors at the same me.
STEP 4 | Right-click your selecon and select Upgrade Collector version.

For each plaorm, select the name of the installaon package you want to push to the selected
on-premise collector machines.
The Cortex XDR Collector keeps the name of the original installaon package aer
every upgrade.
STEP 5 | Upgrade.
Cortex XDR distributes the installaon package to the selected collector machine at the next
heartbeat communicaon with the XDR Collector. To monitor the status of the upgrades, go to
Response > Acon Center. From the Acon Center you can also view addional informaon
about the upgrade (right-click the acon and select Addional data) or cancel the upgrade
(right-click the acon and select Cancel Collector Upgrade).
Uninstall the XDR Collector

If you want to uninstall the Cortex XDR Collector from the on-premise collector machine, you
can do so from the Cortex XDR Collectors console at any me. You can uninstall the Cortex XDR
Collector from an unlimited number of collector machines in a single bulk acon. 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 communicaon
with the XDR Collector. All XDR Collector files are removed from the collector machine.
• The collector machine status changes to Uninstalled. Aer a retenon period of 7 days,
the XDR Collector is deleted from the database and is displayed in Cortex XDR as Collector
Machine Name - N/A (Uninstalled).
• Data associated with the deleted on-premise collector machine is displayed in the Acon
Center tables for the standard 90 days retenon period.
The following workflow describes how to uninstall the Cortex XDR Collector from one or more
Windows or Linux on-premise collector machines.
STEP 1 | Select Sengs > Configuraons > XDR Collectors > Administraon.
STEP 2 | Select the collector machines you want to uninstall.

You can also select collector machines running different operang systems to uninstall the XDR
Collectors at the same me.
STEP 3 | Right-click your selecon and select Uninstall Collector.
STEP 4 | To proceed, select I agree to confirm that you understand this acon uninstalls the XDR
Collector on all selected collector machines.
STEP 5 | Click OK.

To monitor the status of the uninstall process, go to Response > Acon Center.
Set an Alias for a Collector Machine

To idenfy 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 mulple collector machines in bulk. To quickly search for the collector machines
during invesgaon and when you need to take acon, you can use the either the collector
machine hostname or the alias.
STEP 1 | Select Sengs > Configuraons > XDR Collectors > Administraon.
STEP 2 | Select one or more collector machines.
STEP 3 | Right-click anywhere in the collector machine rows, and select Change Collector Alias.
STEP 4 | Specify the alias name and Update.
STEP 5 | Use the Quick Launcher to search the collector machines by alias across the Cortex XDR
Collectors console.
Define Collector Machine Groups

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 Acve Directory user,
group, and computer informaon 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 characteriscs, such as a paral hostname or alias; full or
paral domain name; IP address, range or subnet; XDR Collector version; or operang system
version.
• Create a stac group by selecng a list of specific collector machines.
Aer you define a collector machine group, you can then use it to target policy and acons 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 stac or dynamic group.
STEP 1 | In Cortex XDR, select Sengs > Configuraons > XDR Collectors > Groups.
STEP 2 | Select +Add Group to create a new collector machine group.
STEP 3 | Specify a Group Name and oponal Descripon to idenfy the collector machine group. The
name you assign to the group will be visible when you assign endpoint security profiles to
endpoints.
STEP 4 | Determine the collector machine properes for creang 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 mulple criteria selecons 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.
Cortex XDR Collectors supports only IPv4 addresses.
• Stac—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 stac collector machine group from a file, the IP address, hostname, or
alias of the collector machine must match an exisng Cortex XDR that has registered with
Cortex XDR.
Disconnecng Directory Sync in your Cortex XDR deployment can affect exisng
collector machine groups and policy rules based on Acve Directory properes.
STEP 5 | Create the collector machine group.

Aer 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.
STEP 6 | Manage a collector machine group, as needed.

At any me, 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
acon.
• Edit—View the collector machines that match the group definion, and oponally 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 Administraon page where you can quickly view and iniate acons 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 enre 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.
About XDR Collector Content Updates

To quickly resolve any issues in policy, Palo Alto Networks can seamlessly deliver soware
packages for Cortex XDR called content updates. Content updates for XDR Collectors contain
changes or updates to the Elascsearch* Filebeat infrastructure.
When a new update is available, Cortex XDR nofies the Cortex XDR Collectors. The Cortex XDR
Collectors then randomly choose a me within a six-hour window during which it will retrieve the
content update from Cortex XDR.
Elascsearch is a trademark of Elascsearch B.V., registered in the U.S. and in other countries.
Add a XDR Collector Profile

Ingesng logs and data requires a Cortex XDR Pro per TB license.
You can add a Cortex XDR Collector profile, which defines the data that is collected from the
collector machine for either a Windows or Linux plaorm. Data collecon from a collector
machine is configured using Elascsearch* Filebeat in the Elascsearch Filebeat default
configuraon file called filebeat.yml, which is included as part of the XDR Collector Profile
configuraon. Cortex XDR supports using Filebeat version 7.17.1 with the different operang
systems listed in the Elascsearch Support Matrix that conform to the collector machine operang
systems supported by Cortex XDR. Cortex XDR supports the various input types and modules
available in Elascsearch Filebeat. For more informaon on the input types supported, see
Configure Filebeat Inputs in Elascsearch. For more informaon on the modules supported, see
Configure Filebeat Modules in Elascsearch.
The XDR Collector profile is also where you can configure whether to implement an automac
upgrade for the Cortex XDR Collector release. Once you have added an XDR Collector profile, you
need to associate the profile to a parcular policy for a collector machine.
For more informaon on Elascsearch Filebeat, see the Elascsearch Filebeat Overview
Documentaon.
STEP 1 | In Cortex XDR, select Sengs > Configuraons > XDR Collectors > Profiles.
STEP 2 | Select the plaorm for the collector machine that you want to create a profile for.
• For Windows—Select +New Profile > Windows Profile.
• For Linux—Select +New Profile > Linux Profile.
The configuraon sengs are the same for both Windows and Linux.
STEP 3 | Configure the General Informaon parameters.

• Profile Name—Specify a unique Profile Name to idenfy the profile. The name can contain
only leers, numbers, or spaces, and must be no more than 30 characters. The name you
choose will be visible from the list of profiles when you configure a policy.
• Add descripon here—(Oponal) To provide addional context for the purpose or business
reason that explains why you are creang the profile, specify a profile descripon.
STEP 4 | Configure the Collector Upgrade parameters.

You can configure an automac upgrade for the Cortex XDR Collector release. By default, this
is disabled and the Use Default (Disabled) is selected. To implement an automac upgrade,
follow these steps.
1. Clear the Use Default (Disabled) checkbox.
2. For the Collector Auto-Upgrade field, select Enabled.
When configuring this field, the following addional fields are displayed for defining the
scope of the automac upgrade.
3. You can configure the scope of the automac upgrade to whenever a new XDR Collector
release is available including maintenance releases and new features.
• To ensure the latest XDR Collector release is used, leave the Use Default (Latest
collector release) checkbox selected.
• To configure only a parcular scope, perform the following steps.
1. Clear the Use Default (Latest collector release) checkbox.
2. For the Auto Upgrade Scope, select one of the following opons.
-Latest collector release—Configures the scope of the automac upgrade to
whenever a new XDR Collector release is available including maintenance releases
and new features.
-Only maintenance release—Configures the scope of the automac upgrade to
whenever a new XDR Collector maintenance release is available.
Only maintenance releases in a specific version—Configures the scope of the
automac upgrade to whenever a new XDR Collector maintenance release is
available for a specific version. When this opon is selected, you can select the
specific Release Version.
STEP 5 | Configure the Filebeat configuraon file.

In the Filebeat configuraon file editor, you can define the data collecon for your
Elascsearch Filebeat configuraon file called filebeat.yml. Cortex XDR supports the
various input types and modules available in Elascsearch Filebeat. For more informaon on
the input types supported, see Configure Filebeat Inputs in Elascsearch. For more informaon
on the modules supported, see Configure Filebeat Modules in Elascsearch.
In addion, you can download two example filebeat.yml configuraon files from the user
interface, which provide an example of configuring data collecon using an input or module. To
download the examples, select Download Filebeat Module Configuraons File Example and
Download Filebeat Input Configuraons File Example.
Cortex XDR also supports all secons in the filebeat.yml configuraon file, such as
support for Filebeat fields and tags. As a result, this enables you to use the add_fields
processor to idenfy the product/vendor for the data collected by the XDR Collectors so the
collected events go through the ingeson flow (Parsing Rules). To idenfy the product/vendor
ensure that you use the default fields aribute, as opposed to the target aribute, as shown
in the following example.
processors:
- add_fields:
fields:
vendor: <Vendor>
product: <Product>
• Cortex XDR collects all logs in either a JSON or text format that are uncompressed.
Compressed files, such as in a gzip format, are unsupported.
• Cortex XDR supports logs in single line format or mulline format. For more
informaon on handling messages that span mulple lines of text in Elascsearch
Filebeat, see Manage Mulline Messages.
For more informaon on how to configure the Filebeat configuraon file to collect
Windows DHCP logs, see Ingest Windows DHCP Logs with an XDR Collectors
Profile.
STEP 6 | Create your new profile, which is listed under the applicable plaorm in the XDR Collectors
Profiles page.
STEP 7 | Apply Profiles to Collecon Machine Policies.

You can do this in two ways. You can Create a new policy rule using this profile from the right-
click menu or you can launch the new policy wizard from XDR Collectors > Policies > XDR
Collectors Policies page.

As needed, you can return to the XDR Collectors Profiles page to manage your XDR Collectors
profiles. To manage a specific profile, right click anywhere in the XDR Collector profile row, and
select the desired acon:
• Edit the XDR Collector profile sengs.
• Save As New—Enables you to copy the exisng profile with its current sengs, make any
modificaons, and save it as a new profile by adding a unique name.
• Delete the XDR Collector profile.
• View Collector Policies—Opens a new tab with the XDR Collectors Policies page displayed,
so you can easily see the current policies that are associated to your XDR Collector profiles.
• Copy text to clipboard to copy the text from a specific field in the row of a XDR Collector
profile.
• Copy enre row to copy the text from the enre row of a XDR Collector profile.
Ingest Logs from Windows DHCP using Elascsearch Filebeat

You can configure Cortex XDR to receive Windows DHCP logs using Elascsearch Filebeat with
the following data collectors.
• XDR Collectors (recommended)

• Windows DHCP
Ingest Windows DHCP Logs with an XDR Collectors Profile
When defining data collecon in a XDR Collector profile using the Elascsearch Filebeat
configuraon file editor, you can configure whether the data collected undergoes follow-up
processing in the backend within the filebeat.yml file for Windows DHCP data. You can
enrich network logs with Windows DHCP data when defining data collecon in a XDR Collector
profile. 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 XQL dataset
(microsoft_dhcp_raw).
While this enrichment is also available when configuring a Windows DHCP Collector for a cloud
data collecon integraon, we recommend configuring Cortex XDR to receive Windows DHCP
logs with an XDR Collectors profile as it’s the ideal setup configuraon.
Configure Cortex XDR to receive logs from Windows DHCP via Elascsearch Filebeat with an
XDR Collectors profile.
STEP 1 | Add a XDR Collector Profile.
Follow all the steps explained in this secon, where you only need to ensure that you configure
the Filebeat configuraon file as explained in the following step.
STEP 2 | Configure the Filebeat configuraon file to collect Windows DHCP data.
enrich network logs with Windows DHCP data when defining data collecon by seng the
following secon and tags in the filebeat.yml file.
To avoid formang issues in your filebeat.yml, we recommend that if you copy

and paste the code syntax provided below into your file that you validate the YML
format to ensure the syntax is valid.
# ================================= 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_tags:
tags: [windows_dhcp]
target: "xdr_log_type"
Ingest Windows DHCP Logs with the Windows DHCP Collector
To receive Windows DHCP logs, you must configure data collecon from Windows DHCP via
Elascsearch Filebeat. This is configured by seng up a Windows DHCP Collector in Cortex XDR
and installing and configuring an Elascsearch* Filebeat agent on your Windows DHCP Server.
Cortex XDR supports using Filebeat up to version 8.0.1 with the Windows DHCP Collector.
Certain sengs in the Elascsearch Filebeat default configuraon file called filebeat.yml
must be populated with values provided when you configure the Collecon Integraons sengs
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. Aer you
set up collecon integraon, Cortex XDR begins receiving new logs and data from the source.
For more informaon on configuring the filebeat.yml file, see the Elasc Filebeat
Documentaon.
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 secons - Event ID Meaning and
the events list.
As soon as Cortex XDR begins receiving logs, the app automacally 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 XQL dataset.
Configure Cortex XDR to receive logs from Windows DHCP via Elascsearch Filebeat with the
Windows DHCP collector.
STEP 1 | Configure the Windows DHCP Collector in Cortex XDR.

1. Select Sengs ( ) > Configuraons > Data Collecon > Collecon Integraons.
2. In the Windows DHCP Collector configuraon, click Add Instance to begin a new
configuraon.
3. (Oponal) 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.
4. Specify a descripve Name for your log collecon configuraon.
5. 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 Elascsearch Output secon 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.
6. Select Done to close the window.

7. In the Integraons 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 Elascsearch Output secon in the filebeat.yml file as explained
in Step #2.
STEP 2 | Configure an Elascsearch Filebeat agent on your Windows DHCP Server.

1. Navigate to the Elascsearch Filebeat installaon directory, and open the
filebeat.yml file to configure data collecon with Cortex XDR. We recommend that
you use the download example file provided by Cortex XDR.
2. Update the following secons and tags in the filebeat.yml file. The example code
below details the specific secons to make these changes in the file.
To avoid formang issues in your filebeat.yml, we recommend that you do

not copy and paste the code syntax provided below into your file, and use the
download example file to make your customizaons.
• Filebeat inputs—Define the paths to crawl and fetch. The code below provides an
example of how to configure the Filebeat inputs secon 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
• Elascsearch 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
Elascsearch Output secon in the filebeat.yml file and indicates which sengs
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 secon in the filebeat.yml file and indicates
which sengs need to be obtained from Cortex XDR.
The tokenizer definion is dependent on the Windows server version that

you are using as the log format differs.
-For plaorms earlier than Windows Server 2008, use "%{id},%{date},
%{time},%{description},%{ipAddress},%{hostName},
%{macAddress}"
-For Windows Server 2008 and 2008 R2, use "%{id},%{date},
%{macAddress},%{userName},%{transactionID},
%{qResult},%{probationTime},%{correlationID}"
For Windows Server 2012 and above, use "%{id},%{date},
%{qResult},%{probationTime},%{correlationID},
%{dhcid},%{vendorClassHex},%{vendorClassASCII},
%{userClassHex},%{userClassASCII},
# ================================= Processors
=================================
processors:
- dissect:
tokenizer: "%{id},%{date},%{time},%{description},
%{ipAddress},%{hostName},%{macAddress},%{userName},
%{transactionID},%{qResult},%{probationTime},
%{correlationID},%{dhcid},%{vendorClassHex},
- drop_fields:
fields: ["message"]
- add_locale: ~
- rename:
fields:
- add_cloud_metadata: ~
- add_docker_metadata: ~
- add_kubernetes_metadata: ~
STEP 3 | Verify the status of the integraon.

Return to the Integraons page and view the stascs for the log collecon configuraon.
STEP 4 | Aer Cortex XDR begins receiving logs from Windows DHCP via Elascsearch Filebeat, you
can use the XQL Search to search for logs in the new dataset (microsoft_dhcp_raw).
Apply Profiles to Collecon Machine Policies

Once a Cortex XDR Collector profile is configured, you must aach the profile to a policy. Each
policy that you create must apply to one or more collector machines or collector machine groups.
STEP 1 | In Cortex XDR, create a policy.
Do either of the following:
• Select Sengs > Configuraons > XDR Collectors > Policies > +New Policy to create a
policy from scratch in the XDR Collectors Policies page.
• Select Sengs > Configuraons > XDR Collectors > Profiles, right-click the profile you
want to assign and Create a new policy rule using this profile in the XDR Collectors Profiles
page.
STEP 2 | Set the General sengs for the policy.

• Policy Name—Specify a unique name for the policy.
• Descripon—(Oponal) Specify a descripon that describes the purpose or intent of the
policy.
• Plaorm—Select the Plaorm as either Windows or Linux that you want to create the new
policy.
• Collector Profile—Select the applicable Collector Profile from the list available for the
Plaorm designated that you want to apply to the policy. If you do not specify a profile, the
Cortex XDR Collector uses the Default profile.
STEP 4 | Set the Target sengs in the XDR Collectors Endpoints screen.
Use the filters to assign the policy to one or more collector machines (endpoints) or collector
machine (endpoint) groups.
Cortex XDR automacally applies a filter for the plaorm you selected. To change the plaorm,
go Back to the general policy sengs.
STEP 6 | Review the Summary for the new policy.

If everything looks fine, click Done. Otherwise, click Back to make your changes.
STEP 7 | In the XDR Collectors Policies table, change the policy posion, if needed, to order the policy
relave to other policies.
The Cortex XDR Collector evaluates policies from top to boom. When the Cortex XDR
Collector finds the first match it applies that policy as the acve policy. To move the policy
order, select the arrows and drag the policy to the desired locaon in the policy hierarchy.

As needed, you can return to the XDR Collectors Policies page to manage your XDR Collectors
policies. To manage a specific policy, right click anywhere in the XDR Collector policy row, and
select the desired acon:
• Disable the XDR Collector policy.
• Delete the XDR Collector policy.
• View Policy Details—Opens a new window with the details of the current profile configured
for this policy, so you can easily see the Collector Upgrade and Filebeat configuraon file
details for the profile associated to this policy.
• Save As New—Enables you to copy the exisng policy with its current sengs, make any
modificaons, and save it as a new policy by adding a unique name.
• Edit the XDR Collector policy sengs.
• Copy text to clipboard to copy the text from a specific field in the row of a XDR Collector
policy.
• Copy enre row to copy the text from the enre row of a XDR Collector policy.
XDR Collector Datasets

Aer Cortex XDR begins receiving data from your XDR Collectors configuraon that are
dedicated for on-premise data collecon on Windows and Linux machines. The app automacally
creates an XQL dataset using the module or input specified during the Filebeat setup. The dataset
name follows 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.
Aer Cortex XDR creates the dataset, you can search for your XDR Collector data using XQL
Search.
External Data Ingeson
> External Data Ingeson Vendor Support
> Visibility of Logs and Alerts from External Sources in Cortex XDR
> Ingest Network Connecon Logs
> Ingest Authencaon Logs and Data
> Ingest Operaon and System Logs from Cloud Providers
> Ingest Cloud Assets
> Addional Log Ingeson Methods for Cortex XDR
> Ingest External Alerts
625
External Data Ingeson Vendor Support

To provide you with a more complete and detailed picture of the acvity involved in an incident,
you can ingest data from a variety of external, third-party sources in Cortex XDR.
Log/Data Type Vendor Support
Network Connecons • Amazon S3 (flow logs)

• Azure Event Hub
• Azure Network Watcher (flow logs)
• Check Point FW1/VPN1
• Cisco ASA
• Corelight Zeek
• Fornet Forgate
• Google Cloud Plaorm (flow logs)
• Okta
• Windows DHCP using Elascsearch
Filebeat
• Zscaler Cloud Firewall
Authencaon Services/Audit Logs • Amazon S3 (audit logs)

• Azure Event Hub (audit logs)
• Google Cloud Plaorm (audit logs)
• Google Workspace
• Microso Office 365
• Okta
• PingFederate
• PingOne for Enterprise
Operaon and System Loggers • Amazon S3 (generic logs)

• AWS CloudTrail and Amazon CloudWatch
(generic logs)
• Azure Event Hub
• Google Kubernetes Engine
• Google Cloud Plaorm
• Okta
Log/Data Type Vendor Support

• Prisma Cloud (alerts)
• Prisma Cloud Compute (alerts)
Endpoint Logs • Acvate the Windows Event Collector
Cloud Assets • AWS

• Google Cloud Plaorm
• Microso Azure
Custom External Sources • Any vendor sending CEF or LEEF formaed

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 Kaa
• BeyondTrust Privilege Management Cloud
• ElascSearch Filebeat
• Forcepoint DLP
• PAN IoT Security
• Proofpoint Targeted Aack Protecon
• ServiceNow CMDB
• Workday
• Any vendor sending alerts
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 stching with other logs such as to create network or authencaon 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 Analycs alerts
For more informaon, see Visibility of Logs and Alerts from External Sources in Cortex XDR.
To ingest data, you must set up the Syslog Collector applet on a Broker VM within your network.
Visibility of Logs and Alerts from External Sources in

Cortex XDR
Where you can view informaon ingested from external sources depends on the data source. The
following table describes the visibility of each vendor and device type. A indicates support
where a dash (—) indicates the feature is not supported.
Vendor and Raw Data Normalized Log Cortex XDR Alert Vendor Alert
Device Type Visibility Visibility Visibility Visibility
Network
Amazon S3 (flow —
logs)
Raw data is Opon to ingest Cortex XDR can
searchable in network flow raise Cortex
XQL Search. logs as Cortex XDR alerts
XDR network (Analycs,
connecon IOC, BIOC, and
stories that are Correlaon
searchable in the Rules) when
Query Builder relevant from
and in XQL logs.
Search.
Analycs
Alerts
are
only
raised
on
normalized
logs.
Azure Event Hub — —

(flow logs)
Raw data is Cortex XDR can
searchable in raise Cortex
XQL Search. XDR alerts
(Correlaon
Rules, IOC, and
BIOC) when
relevant from
flow logs.
Azure Network —
Watcher (flow
logs) Opon to ingest Cortex XDR can
network flow raise Cortex
Raw data is logs as Cortex XDR alerts
searchable in XDR network (Analycs,
XQL Search. connecon IOC, BIOC, and
and in XQL flow logs.
Search.
Analycs
Alerts
are
only
raised
on
normalized
logs.
Check Point
FW1/VPN1
Raw data is Network Cortex XDR can Alerts from
searchable in stories that raise Cortex Check Point
XQL Search. include Check XDR alerts firewalls
Point network (Analycs, are raised
Logs connecon logs IOC, BIOC, and throughout
with are searchable Correlaon Cortex XDR
sessionid in the Query Rules) when when relevant.
= Builder and in relevant from
0 XQL Search. logs.
are
dropped. Logs
with
sessionid
=
0
are
dropped.
Corelight Zeek —
Raw data is Network stories Cortex XDR can

searchable in that include raise Cortex
XQL Search. Corelight XDR alerts
Zeek network (Analycs,
connecon logs IOC, BIOC, and
are searchable Correlaon
in the Query Rules) when
Builder and in relevant from
XQL Search. logs.
Cisco ASA —

XQL Search. Cisco network XDR alerts
connecon logs (Analycs,
are searchable IOC, BIOC, and
in the Query Correlaon
Builder and in Rules) when
XQL Search. relevant from
logs.
Fornet
Forgate
Raw data is Network stories Cortex XDR can Alerts from
searchable in that include raise Cortex Fornet firewalls
XQL Search. Fornet network XDR alerts are raised
connecon logs (Analycs, throughout
are searchable IOC, BIOC, and Cortex XDR
in the Query Correlaon when relevant.
Builder and in Rules) when
logs.
Google Cloud —
Plaorm (flow
logs) Raw data is Opon to ingest Cortex XDR can
searchable in network flow raise Cortex
XQL Search. logs as Cortex XDR alerts
XDR network (Analycs,
connecon IOC, BIOC, and
and in XQL logs.
Search.
Analycs
Alerts
are
only
raised
on
normalized
logs.
Okta — Cortex XDR can —

raise Cortex
Raw data is XDR alerts
searchable in (IOC, BIOC,
XQL Search. and Correlaon
Rules only) when
relevant from
logs.
IOCs
and
BIOCs
are
only
raised
for
these
event
types:
sso
and
session_start.
Windows DHCP — —
via Elascsearch
Filebeat Raw data is Cortex XDR
searchable in uses Windows
XQL Search. DHCP logs to
enrich your
network logs
with hostnames
and MAC
addresses that
are searchable in
XQL Search.
Zscaler Cloud —
Firewall
XQL Search. Zscaler Cloud XDR alerts
Firewall network (Analycs,
connecon and IOC, BIOC, and
firewall logs Correlaon
are searchable Rules) when
in the Query
Builder and in relevant from
XQL Search. logs.
Analycs,
IOCs
and
BIOCs
are
only
raised
on
the
Firewall
data.
Authencaon Services/Audit Logs
Amazon S3 —
(audit logs)
Logs and stories Opon to stch Cortex XDR can
are searchable in audit logs with raise Cortex
XQL Search authencaon XDR alerts
stories that are (IOC, BIOC,
searchable in the and Correlaon
Query Builder Rules only) when
and XQL Search. relevant from
logs.
Azure Event Hub —

(audit logs)
Logs and stories Opon to stch Cortex XDR can
are searchable in audit logs with raise Cortex
stories that are (IOC, BIOC,
Query Builder Rules only) when
logs.
Google Cloud —
Plaorm (audit
logs) Raw data is Opon to stch Cortex XDR can
searchable in audit logs with raise Cortex
XQL Search. authencaon XDR alerts
stories that are (Analycs,
searchable in the IOC, BIOC, and
Correlaon
Query Builder Rules) when
logs.
Google — —
Workspace
Raw data is For all logs,
searchable in Cortex XDR can
XQL Search. raise Cortex
XDR alerts
(Correlaon
Rules only) when
relevant from
logs.
Microso Office —
365
Logs and stories Azure AD For Azure AD
(Azure AD authencaon authencaon
authencaon logs and audit logs
and audit normalized into only, Cortex
logs only) are authencaon XDR can raise
searchable in stories. Azure Cortex XDR
XQL Search AD audit logs alerts (Analycs,
normalized to IOC, BIOC, and
cloud audit logs Correlaon
stories. Both are Rules only)
searchable in the when relevant
Query Builder. from logs. For
all other logs,
Cortex XDR can
raise Cortex
XDR alerts
(Correlaon
Rules only) when
relevant from
logs.
Okta —
Logs and stories Logs Cortex XDR can

are searchable in stched with raise Cortex
stories are (IOC, BIOC,
Query Builder. Rules only) when
relevant from
logs.
IOCs
and
BIOCs
are
only
raised
for
these
event
types:
sso
and
session_start.
PingFederate —

relevant from
logs.
PingOne for —
Enterprise
relevant from
logs.
Operaon and System Logs from Cloud Providers
Amazon S3 — —
(generic logs)
(Correlaon
Rules only) when
relevant from
logs.
AWS CloudTrail — —
and Amazon
CloudWatch Raw data is Cortex XDR can
(generic logs) searchable in raise Cortex
(Correlaon
Rules only) when
relevant from
logs.
Azure Event Hub — —

(Correlaon
Rules only) when
relevant from
logs.
Google Cloud — —
Plaorm
(Correlaon
Rules only) when
relevant from
logs.
Google — —
Kubernetes
Engine Raw data is Cortex XDR can
(Correlaon
Rules only) when
relevant from
logs.
Okta — Cortex XDR can —

raise Cortex
Rules only) when
relevant from
logs.
Prisma Cloud
(alerts)
Raw data is Prisma Cloud Cortex XDR can Alerts from
searchable in alerts are raise Cortex Prisma Cloud
XQL Search. stched with XDR alerts are raised
Cloud Provider (Correlaon throughout
logs when Rules only) when Cortex XDR
relevant. relevant from when relevant.
logs.
Prisma Cloud —
Compute (alerts)
Raw data is Cortex XDR can Alerts from
searchable in raise Cortex Prisma Cloud
XQL Search. XDR alerts Compute
(Correlaon are raised
Rules only) when throughout
relevant from Cortex XDR
logs. when relevant.
Endpoint Logs
Windows Event —
Collector
Windows event Windows event Cortex XDR can
logs are available logs are stched raise Cortex
with agent EDR with agent EDR XDR alerts
data and are data and are (IOC, BIOC,
searchable in searchable in the and Correlaon
XQL Search. Query Builder. Rules only) when
relevant from
logs.
Cloud Assets
AWS — N/A N/A N/A
Google Cloud — N/A N/A N/A

Plaorm
Microso Azure — N/A N/A N/A
Custom External Sources
Any Vendor —
Sending CEF or To enable Cortex
LEEF formaed Raw data is Cortex XDR can
XDR to display
Syslog searchable in raise Cortex
alerts from other
vendors, you
(IOC, BIOC,
must map your
and Correlaon
alert fields to
Rules only) when
the Cortex XDR
relevant from
field format (see
logs.
Ingest External
Alerts).
Any vendor — —
CSV files on a
shared Windows Raw data is Cortex XDR can
directory searchable in raise Cortex
(Correlaon
Rules only) when
relevant from
logs.
Any vendor — —
logs stored in a
database Raw data is Cortex XDR can
(Correlaon
Rules only) when
relevant from
logs.
Any vendor logs — —

stored in files on
a network share Raw data is Cortex XDR can
(Correlaon
Rules only) when
relevant from
logs.
Any vendor logs — —

from a third
party source Cortex XDR can
raise Cortex
XDR alerts
over FTP, FTPS, Raw data is (Correlaon
or SFTP searchable in Rules only) when
logs.
Any vendor —
sending NetFlow
flow records Raw data is NetFlow events Cortex XDR can
searchable in are stched raise Cortex
XQL Search. with the Agent’s XDR alerts
EDR data and (IOC, BIOC,
other Network and Correlaon
products to Rules only) when
a Session relevant from
Story, and are logs.
searchable in the
Query Builder
and in XQL.
Any vendor —
sending logs To enable Cortex
over HTTP Raw data is Cortex XDR can
XDR to display
alerts from other
vendors, you
(Correlaon
must map your
Rules only) when
alert fields to
relevant from
the Cortex XDR
logs.
field format (see
Ingest External
Alerts).
Apache Kaa — Cortex XDR can —

raise Cortex
Rules only) when
relevant from
logs.
BeyondTrust — —
Privilege
Management Raw data is Cortex XDR can
Cloud searchable in raise Cortex
(Correlaon
Rules only) when
relevant from
logs.
Elascsearch — —
Filebeat
(Correlaon
Rules only) when
relevant from
logs.
Forcepoint DLP — —

(Correlaon
Rules only) when
relevant from
logs.
PAN IoT Security Cortex XDR —

uses PAN
Raw data is IOT Security Cortex XDR can
searchable in informaon raise Cortex
XQL Search. to improve XDR alerts
analycs (Analycs,
detecon IOC, BIOC, and
and assets Correlaon
management Rules) when
informaon. relevant from
logs.
Analycs
Alerts
are
only
raised
on
normalized
logs.
Proofpoint — —
Targeted Aack
Protecon
(Correlaon
Rules only) when
relevant from
logs.
ServiceNow — —
CMDB
(Correlaon
Rules only) when
relevant from
logs.
Workday — —

(Correlaon
Rules only) when
relevant from
logs.
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).
When ingesng data from an external source, Cortex XDR creates a dataset that you can query
using XQL. Datasets created in this way use the following naming convenon.
<vendor_name>_<product_name>_raw
For example: cisco_asa_raw

The datatypes used for the fields in an imported dataset are automacally 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.
Ingest Network Connecon Logs

• Ingest Network Flow Logs from Amazon S3
• Ingest Logs from Check Point Firewalls
• Ingest Logs from Cisco ASA Firewalls
• Ingest Logs from Corelight Zeek
• Ingest Logs from Fornet Forgate Firewalls
• Ingest Logs and Data from a GCP Pub/Sub
• Ingest Logs from Microso Azure Event Hub
• Ingest Network Flow Logs from Microso Azure Network Watcher
• Ingest Logs and Data from Okta
• Ingest Logs from Windows DHCP using Elascsearch Filebeat
• Ingest Logs from Zscaler Cloud Firewall
Ingest Network Flow Logs from Amazon S3

You can forward network flow logs for the relave service to Cortex XDR from Amazon Simple
Storage Service (Amazon S3).
To receive network flow logs from Amazon S3, you must first configure data collecon from
Amazon S3. You can then configure the Collecon Integraons sengs in Cortex XDR for Amazon
S3. Aer you set up collecon integraon, Cortex XDR begins receiving new logs and data from
the source.
You can either configure Amazon S3 with SQS noficaon manually on your own or use the AWS
CloudFormaon Script that we have created for you to make the process easier. The instrucons
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 Collecon from Amazon S3 Manually.
For more informaon on configuring data collecon from Amazon S3, see the Amazon S3
Documentaon.
As soon as Cortex XDR begins receiving logs, the app automacally creates an Amazon S3 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. You can also configure Cortex XDR to ingest
network flow logs as XDR network connecon 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 (Analycs, Correlaon Rules, IOC, and BIOC only) when relevant from
Amazon S3 logs. Analycs alerts are only raised on normalized logs.
Be sure you do the following tasks before you begin configuring data collecon from Amazon S3
using the AWS CloudFormaon Script.
• Ensure that you have the proper permissions to run AWS CloudFormaon 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 to perform API
operaons. You have the following opons:
• 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 opon as explained in configure the Amazon S3 collecon in Cortex XDR by
selecng 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 informaon, see Creang a role
to delegate permissions to an AWS service. This is the Assumed Role opon as described in
the configure the Amazon S3 collecon in Cortex XDR. For more informaon on creang an
assumed role for Cortex XDR, see Create an Assumed Role for Cortex XDR.
Configure Cortex XDR to receive network flow logs from Amazon S3 using the CloudFormaon
Script.
STEP 1 | Download the CloudFormaon Script in Cortex XDR.
2. In the Amazon S3 configuraon, click Add Instance link to begin a new configuraon.
3. To provide access to Cortex XDR to your logs and to perform API operaons using a
designated AWS IAM user, leave the Access Key opon selected. Otherwise, select
Assumed Role, and ensure that you Create an Assumed Role for Cortex XDR before
connuing with these instrucons.
4. For the Log Type, select Flow Logs to configure your log collecon to receive network
flow logs from Amazon S3, and the following text is displayed under the field Download
CloudFormaon Script. See instrucons here.
5. Click the Download CloudFormaon Script. link to download the script to your
computer.
STEP 2 | Create a new Stack in the CloudFormaon Console with the script you downloaded from
Cortex XDR.
For more informaon on creang a Stack, see Creang a stack on the AWS CloudFormaon
console.
1. Log in to the CloudFormaon Console.

2. From the CloudFormaon > Stacks page, ensure that you have selected the correct
region for your configuraon.
3. Select Create Slack > With new resources (standard).
4. Specify the template that you want AWS CloudFormaon 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 sengs in the Specify template page.
• Prerequisite - Prepare template > Prepare template—Select Template is ready.
• Specify Template
• Template source—Select Upload a template file.
• Upload a template file—Choose file, and select the cortex-xdr-create-s3-
with-sqs-flow-logs.json file that you downloaded from Cortex XDR.
5. Click Next.
6. In the Specify stack details page, configure the following stack details.
• Stack name—Specify a descripve name for your stack.
• Parameters > Cortex XDR Flow Logs Integraon
• 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.
7. Click Next.
8. In the Configure stack opons page, there is nothing to configure, so click Next.
9. In the Review page, look over the stack configuraons sengs that you have configured
and if they are correct, click Create stack. If you need to make a change, click Edit beside
the parcular 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 informaon in the stack for other steps
detailed below.
For the Amazon S3 bucket created using CloudFormaon, it is the customer’s

responsibility to define a retenon policy by creang a Lifecycle rule in the
Management tab. We recommend seng the retenon policy to at least 7 days
to ensure that the data is retrieved under all circumstances.
STEP 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 informaon, 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 Acons > Create flow log.
3. Configure the following Flow log sengs:

• Name - oponal—(Oponal) Specify a descripve name for your VPC flow log.
• Filter—Select All types of traffic to capture.
• Maximum aggregaon interval—If you ancipate a heavy flow of traffic, select 1 minute.
Otherwise, leave the default seng as 10 minutes.
• Desnaon—Select Send to an Amazon S3 bucket as the desnaon 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 secon, select the bucket that you created for collecng the Amazon S3 flow
logs when you created your stack, click Copy ARN, and paste the ARN in this field.
• Log record format—Specify the fields to include in the flow log record, where we
recommend leaving the default AWS default format selected.
4. Click Create flow log.
Once the flow log is created, a message indicang that the flow log was successfully created
is displayed at the top of the Your VPCs page.
In addion, if you open your Amazon S3 bucket configuraons, by selecng the bucket from
the Amazon S3 console, the Objects tab contains a folder called AWSLogs/ to collect the
flow logs.
STEP 4 | Configure access keys for the AWS IAM user that Cortex XDR uses for API operaons.
• It is the responsibility of the customer’s organizaon to ensure that the user

who performs this task of creang 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 navigaon pane, select Access management >
Users.
2. Select the User name of the AWS IAM user.
3. Select the Security credenals tab, and scroll down to the Access keys secon, 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 seng 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 informaon, see Managing access keys for IAM users.
STEP 5 | When you create an Assumed Role for Cortex XDR, ensure that you edit the policy that
defines the permissions for the Cortex XDR 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.
STEP 6 | Configure the Amazon S3 collecon in Cortex XDR.

2. In the Amazon S3 configuraon, click Add Instance to begin a new configuraon.
3. 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 le open aer creang the stack, open the Outputs tab, and copy the
Value of the QueueURL and paste it in this field.
• Name—Specify a descripve name for your log collecon configuraon.
• When seng 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
• When seng 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 Flow Logs to configure your log collecon to receive network flow
logs from Amazon S3. When configuring network flow log collecon, the following
addional field is displayed for the Configuraon.
You can Normalize and enrich flow logs by selecng the checkbox. If selected, Cortex
XDR ingests the network flow logs as XDR network connecon stories, which you
can query using XQL Search from the xdr_dataset dataset using the preset called
network_story.
4. Click Test to validate access, and then click Enable.
Once events start to come in, a green check mark appears underneath the Amazon S3
configuraon with the number of logs received.
Create an 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 operaons, 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
informaon, see Creang a role to delegate permissions to an AWS service.
When seng up any type of Amazon S3 Collector in Cortex XDR, these instrucon explain seng
up an Assumed Role.
STEP 1 | Log in to the AWS Management Console to create a role for Cortex XDR.
Refer to the AWS instrucons for guidance.
1. Create the role in the same region as your AWS account, and use the following values
and opons when creang the role.
• Type of Trusted > Another AWS Account, and specify the Account ID as
006742885340.
• Select Opons 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 oponal 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.
2. Click Next and add the AWS Managed Policy for Security Audit.
Then, add a role name and create the role. In this workflow, later, you will create the
granular policies and edit the role to aach the addional policies.
STEP 2 | Create the policy that defines the permissions for the Cortex XDR role.
1. Select IAM on the AWS Management Console.
2. In the navigaon pane on the le, select Access Management > Policies > Create Policy.
3. Select the JSON tab.
Copy the following JSON policy and paste it within 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>"
}
]
}
4. Review and create the policy.
STEP 3 | Edit the role you created in Step 1 and aach the policy to the role.
STEP 4 | Copy the Role ARN.
STEP 5 | Connue 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 Audit Logs from AWS Cloud Trail.
• Ingest Generic Logs from Amazon S3.
Configure Data Collecon from Amazon S3 Manually
There are various reasons why you may need to configure data collecon from Amazon S3
manually, as opposed to using the CloudFormaon Script provided in Cortex XDR. For example,
if your organizaon does not use CloudFormaon scripts, you will need to follow the instrucons
below, which explain at a high-level how to perform these steps manually with a link to the
relevant topic in the Amazon S3 documentaon with the detailed steps to follow.
For example queries, refer to the in-app XQL Library. You can also configure Cortex XDR to ingest
network flow logs as XDR network connecon 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 (Correlaons, IOC, and BIOC only) when relevant from Amazon S3 logs.
Be sure you do the following tasks before you begin configuring data collecon 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 configuraon, 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).
• Create a dedicated Amazon S3 bucket for collecng network flow logs with the default
sengs. For more informaon, see Creang a bucket using the Amazon S3 Console.
It is the customer’s responsibility to define a retenon policy for your Amazon S3

bucket by creang a Lifecycle rule in the Management tab. We recommend seng
the retenon 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.
operaons. You have the following opons.
Configure Cortex XDR to receive network flow logs from Amazon S3 manually.
STEP 1 | Log in to the AWS Management Console.
STEP 2 | From the menu bar, ensure that you have selected the correct region for your configuraon.
STEP 3 | Configure your Amazon Virtual Private Cloud (VPC) with flow logs. For more informaon, 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).
STEP 4 | Configure an Amazon Simple Queue Service (SQS). For more informaon, see Configuring
Amazon SQS queues (console).
Ensure that you create your Amazon S3 bucket and Amazon SQS queue in the same
region.
STEP 5 | Configure an event noficaon to your Amazon SQS whenever a file is wrien to your
Amazon S3 bucket. For more informaon, see Amazon S3 Event Noficaons.
STEP 6 | Configure access keys for the AWS IAM user that Cortex XDR uses for API operaons. For
more informaon, see Managing access keys for IAM users.

STEP 7 | Update the Access Policy of your SQS queue and grant the required permissions menoned
above to the relevant IAM user. For more informaon, see Granng permissions to publish
event noficaon messages to a desnaon.
Skip this step if you are using an Assumed Role for Cortex XDR.

• To provide access to Cortex XDR to your logs and perform API operaons using a
connuing with these instrucons. In addion, when you create an Assumed Role
for Cortex XDR, ensure that you edit the policy that defines the permissions for the
Cortex XDR 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 informaon on how to
retrieve your Amazon SQS ARN, see the Specify SQS queue field when you Configure
an event noficaon to your Amazon SQS whenever a file is wrien to your Amazon
S3 bucket.
• AWS Client ID—Specify the Access key ID, which you received when you created
• AWS Client Secret—Specify the Secret access key you received when you created
• 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 collecon to receive network flow
logs from Amazon S3. When configuring network flow log collecon, the following
You can Normalize and enrich flow logs by selecng the checkbox. When selected,
Cortex XDR ingests the network flow logs as XDR network connecon stories, which
you can query using XQL Search from the xdr_dataset dataset using the preset
called network_story.
Ingest Logs from Check Point Firewalls

If you use Check Point FW1/VPN1 firewalls, you can sll take advantage of Cortex XDR
invesgaon and detecon capabilies 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 conjuncon with Palo Alto Networks firewall logs and addional data
sources.
Cortex XDR can stch data from Check Point firewalls with other logs to make up network stories
searchable in the Query Builder and in XQL queries. Cortex XDR can also return raw data from
Check Point firewalls in XQL queries.
Logs with sessionid = 0 are dropped.
Desnaon Port data is available only in the raw logs.
In terms of alerts, Cortex XDR can both surface nave Check Point firewall alerts and raise its
own alerts on network acvity. Alerts are displayed throughout Cortex XDR alert, incident, and
invesgaon 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 stching network connecon logs
with other logs to form network stories. Cortex XDR can also analyze your logs to raise Analycs
alerts and can apply IOC, BIOC, and Correlaon Rule matching. You can also use queries to search
your network connecon logs.
STEP 1 | Ensure that your Check Point firewalls meet the following requirements.
Check Point soware version—R77.30, R80.10, R80.20, R80.30, or R80.40
STEP 2 | Increase log storage for Check Point firewall logs.

As an esmate for inial sizing, note that the average Check Point log size is roughly 700 bytes.
For proper sizing calculaons, test the log sizes and log rates produced by your Check Point
firewalls. For more informaon, see Manage Your Log Storage within Cortex XDR.
STEP 3 | Acvate the Syslog Collector.
STEP 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 informaon on seng up Log Exporter, see the Check Point
documentaon.
Ingest Logs from Cisco ASA Firewalls

If you use Cisco ASA firewalls, you can sll take advantage of Cortex XDR invesgaon and
detecon capabilies 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 Cisco ASA
firewall logs as the sole data source, but can also use Cisco ASA firewall logs in conjuncon with
Palo Alto Networks firewall logs. For addional endpoint context, you can also use Cortex XDR to
collect and alert on endpoint data.
act as a Syslog Collector. You then configure forwarding on your log devices to send logs to the
Syslog Collector in a CEF format.
STEP 1 | Verify that your Cisco ASA firewall meets the following requirements.
• Syslog in Cisco-ASA format
• Must include mestamps
• Only supports messages: 302013, 302014, 302015, 302016
STEP 3 | Increase log storage for Cisco ASA firewall logs.

As an esmate for inial sizing, note that the average Cisco ASA log size is roughly 180 bytes.
For proper sizing calculaons, test the log sizes and log rates produced by your Cisco ASA
firewalls. For more informaon, see Manage Your Log Storage within Cortex XDR.
STEP 4 | Configure the Cisco ASA firewall or the log device forwarding logs from it to log 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 Cisco ASA firewall logs. For more informaon on seng up Log Forwarding on
Cisco ASA firewalls, see the Cisco ASA Series documentaon.
Ingest Logs from Corelight Zeek

If you use Corelight Zeek sensors for network monitoring, you can sll take advantage of Cortex
XDR invesgaon and detecon capabilies by forwarding your network connecon 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
conjuncon with Palo Alto Networks or third-party firewall logs. For addional endpoint context,
you can also use Cortex XDR to collect and alert on endpoint data.
alerts and can apply IOC BIOC, and Correlaon Rule matching. You can also use queries to search
act as a Syslog Collector. You then configure forwarding on your Corelight Zeek sensors (using the
default Syslog export opon of RFC5424 over TCP) to send logs to the Syslog Collector.
During acvaon, 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.
STEP 2 | Forward logs to the Syslog Collector.

Cortex XDR can receive logs from Corelight Zeek sensors that use the Syslog export opon of
RFC5424 over TCP.
1. In the syslog configuraon 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 acvaon of the Syslog Collector,
default Syslog format (RFC5424), and any log exclusions or filters.
2. Save your syslog configuraon to apply the configuraon to your Corelight Zeek Sensors.
For full setup instrucons, see the Corelight Zeek documentaon.
Ingest Logs from Fornet Forgate Firewalls

If you use Fornet Forgate firewalls, you can sll take advantage of Cortex XDR invesgaon
and detecon capabilies 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 Fornet
Forgate firewall logs as the sole data source, but can also use Fornet Forgate firewall logs in
conjuncon with Palo Alto Networks firewall logs. For addional endpoint context, you can also
use Cortex XDR to collect and alert on endpoint data.
act as a syslog collector. You then configure forwarding on your log devices to send logs to the
syslog collector in a CEF format.
STEP 1 | Verify that your Fornet Forgate firewalls meet the following requirements.
• Must use ForOS 6.2.1 or a later release
• mestamp must be in nanoseconds
STEP 3 | Increase log storage for Fornet Forgate firewall logs.

As an esmate for inial sizing, note that the average Fornet Forgate log size is roughly
1,070 bytes. For proper sizing calculaons, test the log sizes and log rates produced by your
Fornet Forgate firewalls. For more informaon, see Manage Your Log Storage within Cortex
XDR.
STEP 4 | Configure the log device that receives Fornet Forgate 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 Fornet Forgate firewall logs. For more informaon on seng up Log Forwarding on
Fornet Forgate firewalls, see the Fornet ForOS documentaon.
Ingest Logs and Data from a GCP Pub/Sub

If you use the Pub/Sub messaging service from Global Cloud Plaorm (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 addional informaon and context to your invesgaons using the GCP XQL
dataset (google_cloud_logging_raw). For example queries, refer to the in-app XQL Library.
You can configure a Google Cloud Plaorm collector to receive generic, flow, or audit 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 GCP audit logs, which you can query with XQL
Search using the cloud_audit_logs dataset. In addion, you can configure Cortex XDR to
ingest network flow logs as XDR network connecon 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 (Analycs, IOC, BIOC, and Correlaon Rule only) when relevant from
GCP logs. Analycs alerts are only raised on normalized logs.
When collecng flow logs, we recommend that you include GKE annotaons in your logs,
which enable you to view the names of the containers that communicated with each
other. GKE annotaons are only included in logs if appended manually using the custom
metadata configuraon in GCP. For more informaon, see VPC Flow Logs Overview. In
addion, to customize metadata fields, you must use the gcloud command-line interface or
the API. For more informaon, 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 sengs using either the GCP web interface or a GCP cloud shell
terminal. Aer you set up your service account in GCP, you configure the Data Collecon sengs
in Cortex XDR. The setup process requires the subscripon name and authencaon key from
your GCP instance.
Aer you set up log collecon, Cortex XDR immediately begins receiving new logs and data from
GCP.
• Set up Log Forwarding Using the GCP Web Interface.
• Set up Log Forwarding Using the GCP Cloud Shell Terminal.
Set up Log Forwarding Using the GCP Web Interface

STEP 1 | Log in to your GCP account.
STEP 2 | Set up log forwarding from GCP to Cortex XDR.

1. Select Logging > Logs Router.
2. Select Create Sink > Cloud Pub/Sub topic, and then click Next.
3. To filter only specific types of data, select the filter or desired resource.
4. In the Edit Sink configuraon, define a descripve Sink Name.
5. Select Sink Desnaon > Create new Cloud Pub/Sub topic.
6. Enter a descripve Name that idenfies the sink purpose for Cortex XDR, and then
Create.
7. Create Sink and then Close when finished.
STEP 3 | Create a subscripon for your Pub/Sub topic.

1. Select the hamburger menu in G Cloud and then select Pub/Sub > Topics.
2. Select the name of the topic you created in the previous steps. Use the filters if
necessary.
3. Create Subscripon > Create subscripon.
4. Enter a unique Subscripon ID.
5. Choose Pull as the Delivery Type.
6. Create the subscripon.
Aer the subscripon is set up, G Cloud displays stascs and sengs for the service.
7. In the subscripon details, idenfy and note your Subscripon Name.
Oponally, use the copy buon to copy the name to the clipboard. You will need the
name when you configure Collecon in Cortex XDR.
STEP 4 | Create a service account and authencaon key.

You will use the key to enable Cortex XDR to authencate with the subscripon service.
1. Select the hamburger menu and then select IAM & Admin > Service Accounts.
2. Create Service Account.
3. Enter a Service account name and then Create.
4. Select a role for the account: Pub/Sub > Pub/Sub Subscriber.
5. Click Connue > Done.
6. Locate the service account by name, using the filters to refine the results, if needed.
7. Click the Acons menu idenfied by the three dots in the row for the service account
and then Create Key.
8. Select JSON as the key type, and then Create.
Aer you create the service account key, G Cloud automacally downloads it.
STEP 5 | In Cortex XDR, set up Data Collecon.

2. In the Google Cloud Plaorm configuraon, click Add Instance.
3. Specify the Subscripon Name that you previously noted or copied.
4. Browse to the JSON file containing your authencaon key for the service account.
5. Select the Log Type as one of the following, where your selecon changes the opons
displayed.
• Flow Or Audit Logs—When selecng this log type, you can decide whether to
normalize and enrich the flow and audit logs.
• (Oponal) You can Normalize and enrich flow and audit logs by selecng
the checkbox. If selected, Cortex XDR ingests the network flow logs as XDR
network connecon stories, which you can query using XQL Search from the
xdr_dataset dataset with the preset called network_story. In addion, you
can configure Cortex XDR to normalize GCP audit logs, which you can query with
XQL Search using the cloud_audit_logs dataset.
• Generic—When selecng this log type, you can configure the following sengs.
• Log Format—Select the log format type as Raw, JSON, CEF, LEEF, Cisco, or
Corelight.
-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
even if you specified a value in the Vendor and Product fields in the GCP
data collector sengs. 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 sengs. If you did not specify a Vendor or Product in the
GCP data collector sengs, 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 Cisco, the following fields are automacally set and not
configurable.
-Vendor—Cisco
-Product—ASA
For a Log Format set to Corelight, the following fields are automacally set and not
configurable.
-Vendor—Corelight
-Product—Zeek
For a Log Format set to Raw or JSON, the following fields are automacally set and
are configurable.
-Vendor—Google
-Product—Cloud Logging
Cortex XDR supports logs in single line format or mulline format. For a JSON
format, mulline logs are collected automacally when the Log Format is
configured as JSON. When configuring a Raw format, you must also define the
Mulline Parsing Regex as explained below.
• Vendor—(Oponal) Specify a parcular vendor name for the GCP generic data
collecon, which is used in the GCP XQL dataset <Vendor>_<Product>_raw
that Cortex XDR creates as soon as it begins receiving logs.
• Product—(Oponal) Specify a parcular product name for the GCP
generic data collecon, which is used in the GCP XQL dataset name
<Vendor>_<Product>_raw that Cortex XDR creates as soon as it begins
receiving logs.
• Mulline Parsing Regex—(Oponal) This opon is only displayed when the Log
Format is set to Raw, where you can set the regular expression that idenfies
when the mulline event starts in logs with mullines. It is assumed that when a
new event begins, the previous one has ended.
6. Test the provided sengs and, if successful, proceed to Enable log collecon.
STEP 6 | Aer Cortex XDR begins receiving informaon 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

STEP 1 | Launch the GCP cloud shell terminal or use your preferred shell with gcloud installed.
STEP 2 | Define your project ID.
gcloud config set project <PROJECT_ID>
STEP 3 | Create a Pub/Sub topic.
gcloud pubsub topics create <TOPIC_NAME>
STEP 4 | Create a subscripon for this topic.
gcloud pubsub subscriptions create <SUBSCRIPTION_NAME> --

topic=<TOPIC_NAME>
Note the subscripon name you define in this step as you will need it to set up log ingeson
from Cortex XDR.
STEP 5 | Create a logging sink.

During the logging sink creaon, you can also define addional log filters to exclude specific
logs. To filter logs, supply the oponal 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 sengs:
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
STEP 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
STEP 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>"
STEP 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
STEP 9 | Create a JSON key for the service account.

You will need the JSON file to enable Cortex XDR to authencate with the GCP service.
Specify the file desnaon and filename using a .json extension.
gcloud iam service-accounts keys create <OUTPUT_FILE> --iam-

account <SERVICE_ACCOUNT>@<PROJECT_ID>.iam.gserviceaccount.com

displayed.
Corelight.
set to CEF or LEEF.
configurable.
-Vendor—Cisco
-Product—ASA
configurable.
-Vendor—Corelight
-Product—Zeek
are configurable.
-Vendor—Google
receiving logs.
Ingest Logs from Microso Azure Event Hub

Ingesng Logs from Azure Event Hub requires a Cortex XDR Pro per TB license.
To receive logs from Azure Event Hub, you must configure the Collecon Integraons sengs
in Cortex XDR based on your Microso Azure Event Hub configuraon. Aer you set up data
collecon, 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 iniate XQL Search queries. For example queries, refer to the in-app XQL Library.
You can also configure Cortex XDR to normalize Azure Event Hub audit logs with other Cortex
XDR authencaon stories across all cloud providers using the same format, which you can query
with XQL Search using the cloud_audit_logs or xdr_data datasets. 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 (IOC, BIOC, and Correlaon Rule only) when relevant from Azure Event Hub
logs.
Cortex XDR can also ingest Azure sign-in logs when you configure an Azure Event Hub data
collector to collect audit logs. This is also dependent on seng the applicable Diagnosc sengs
in Azure Acve Directory with the selected sign-in log categories. These logs are added in Cortex
XDR to the MSFT_Azure_raw dataset. In addion, Cortex XDR can normalize and enrich these
authencaon logs. Cortex XDR can normalize these Acve Directory sign-in logs with other
Cortex XDR authencaon stories across all cloud providers using the same format. You can query
these logs in XQL Search using the cloud_audit_logs and xdr_data datasets.
Be sure you do the following tasks before you begin configuring data collecon from Azure Event
Hub.
• Create an Azure Event Hub. For more informaon, see Quickstart: Create an event hub using
Azure portal.
• Ensure the format for the logs you want collected from the Azure Event Hub is either JSON or
raw.
Configure the Azure Event Hub collecon in Cortex XDR.
STEP 1 | In the Microso Azure Console, open the Event Hubs page, and select the Azure Event Hub
that you created for collecon in Cortex XDR.
STEP 2 | Record the following parameters from your configured event hub, which you will need when
configuring data collecon in Cortex XDR.
• Your event hub’s consumer group.
1. Select Enes > Event Hubs, and select your event hub.
2. Select Enes > 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 collecon configuraon.
• Your event hub’s connecon string for the designated policy.
1. Select Sengs > Shared access policies.
2. In the Shared access policies table, select the applicable policy.
3. Copy the Connecon string-primary key.
• Storage account for the connecon string.
1. Open the Storage accounts page, and select the storage account that contains the
connecon string for the event hub you have configured for data collecon by Cortex
XDR.
2. Select Security + networking > Access keys, and click Show keys.
3. Copy the applicable Connecon string.
STEP 3 | (Oponal) Configure your Microso Azure Event Hub to collect Azure sign-in logs.
1. In the Microso Azure Console, search for Azure Acve Directory, and select Services >
Azure Acve Directory.
2. Select Monitoring > Diagnosc sengs, and +Add diagnosc seng.
3. Set the following parameters.
• Diagnosc seng name—Specify a name for your Diagnosc seng.

• Logs Categories—Select from the list of applicable sign-in Logs Categories, the ones
that you want to configure your designated resource to collect. You can select any of
the following categories to configure sign-in logs collecon.
• SignInLogs
• NonInteracveUserSignInLogs
• ServicePrincipalSignInLogs
• ManagedIdentySignInLogs
• ADFSSignInLogs
• Desnaon details—Select Stream to event hub, where addional parameters are
displayed that you need configure. Ensure that you set the following parameters using
the same sengs for the Azure Event Hub that you created for collecon in XDR.
• Subscripon—Select the applicable Subscripon for the Azure Event Hub.
• Event hub namespace—Select the applicable Subscripon for the Azure Event
Hub.
• (Oponal) 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.
4. Save your sengs.
STEP 4 | Configure the Azure Event Hub collecon in Cortex XDR.

2. In the Azure Event Hub configuraon, click Add Instance to begin a new configuraon.
3. Set these parameters.
• Event Hub Connecon String—Specify your event hub’s connecon string for the
designated policy.
• Storage Account Connecon String—Specify your event hub’s storage account for the
connecon string.
• 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, and Corelight.
When you Normalize and enrich audit logs, the log format is automacally
configured. As a result, this opon is removed and no longer available to
configure.
-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 Azure Event
Hub data collector sengs. 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 sengs. If you did not specify a Vendor or Product
in the Azure Event Hub data collector sengs, and the values are blank in the
event log row, the values for both fields are set to unknown.
configurable.
-Vendor—Cisco
-Product—ASA
configurable.
-Vendor—Corelight
-Product—Zeek
are configurable.
-Vendor—Ms
-Product—Azure
• Vendor and Product—Specify the Vendor and Product for the type of logs you are
ingesng.
The Vendor and Product are used to define the name of your XQL dataset
(<vendor>_<product>_raw). The Vendor and Product values vary depending on
the Log Format selected. To uniquely idenfy 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 automacally configured. Therefore, these fields are removed as available
opons.
• Normalize and enrich audit logs—(Oponal) You can Normalize and enrich audit logs
by selecng the checkbox. If selected, Cortex XDR normalizes and enriches Azure
Event Hub audit logs, including any Azure sign-in logs configured for collecon, with
other Cortex XDR authencaon stories across all cloud providers using the same
format, which you can query with XQL Search using the cloud_audit_logs and
xdr_data datasets.
Once events start to come in, a green check mark appears underneath the Azure Event
Hub configuraon with the amount of data received.
Ingest Network Flow Logs from Microso Azure Network Watcher

To receive network security group (NSG) flow logs from Azure Network Watcher, you must
configure data collecon from Microso Azure Network Watcher using an Azure Funcon
provided by Cortex XDR. This Azure Funcon requires a token that is generated when you
configure your Azure Network Watcher Collector in the Collecon Integraon sengs in Cortex
XDR. Aer you set up data collecon, Cortex XDR begins receiving new logs and data from the
source.
You can also configure Cortex XDR to ingest network flow logs as XDR network connecon
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 (Analycs, Correlaon Rule,
IOC and BIOC only) when relevant from Azure Network Watcher flow logs. Analycs alerts are
only raised on normalized logs.
Be sure you do the following tasks before you begin configuring data collecon from Azure
Network Watcher.
• Ensure that your NSG flow logs in Azure Network Watcher, conform to the requirements
as outlined in the Microso documentaon. For more informaon, see Introducon to flow
logging for network security groups.
• Enable NSG flow logs in the Microso Azure Portal.
Configure the Azure Network Watcher collecon in Cortex XDR.
STEP 1 | Configure the Azure Network Watcher collecon in Cortex XDR.

2. In the Azure Network Watcher configuraon, click Add Instance to begin a new
configuraon.
• Normalize and enrich flow logs—(Oponal) You can Normalize and enrich flow logs
by selecng the checkbox. If selected, Cortex XDR ingests network flow logs as
Cortex XDR network connecon stories, which you can query with XQL Search using
the xdr_dataset dataset with the preset called network_story.
image below.
provide this key when you configure the Azure Funcon and set the XDR Token value. If
you forget to record the key and close the window, you will need to generate a new key
and repeat this process. When you are finished, click Done to close the window.
5. In the Integraons page for the Azure Network Watch Collector that you created, select
Copy api url and record it somewhere safe. you will need to provide this URL when you
configure the Azure Funcon and set the XDR Host value.
STEP 2 | Configure the Azure Funcon provided by Cortex XDR.

1. Open the Azure Funcon provided by Cortex XDR.
2. Click Deploy to Azure.
3. Set these parameters, where some fields are mandatory to set and others are already
populated for you.
• Subscripon—Specify the Azure subscripon that you want to use for the App
Configuraon. If your account has only one subscripon, it is automacally selected.
• Resource group—Specify or create a resource group for your App Configuraon store
resource.
• Region—Specify the Azure region that you want to use.
• App Name—Specify the name of the funcon app. In the Azure Portal, this will be the
name that appears in the list of resources.
• App Service Plan—Select the applicable service plan. If you select Service Plan
(default), an App Service plan is created and you are billed accordingly. If you select
Consumpon, you are billed based on the Consumpon Plan.
• App Service Plan Tier—When seng a Service Plan, you must select the applicable
App Service Plan Tier from the list of opons (Free (default), Shared, Basic, Standard,
Premium, and PremiumV2). Otherwise, leave the default opon configured.
• App Service Plan Name—When seng a Service Plan, you must set the App Service
Plan Name, which must match the Service Plan Tier.
• App Service Plan Capacity—When seng a Service Plan, specify how many instances
do you want to set for the upper limit or leave the default as 2. For example, when
configuring an Standard Tier Service Plan, S2, set a value from 1 to 10.
• Github Repo URL—Specify the URL of the repo that contains the funcon
app source. Leave the default as hps://github.com/PaloAltoNetworks/
AzureNetworkWatcherNSGFlowLogsConnector.git or specify your fork's address

here.
• Github Repo Branch—Specify the name of the branch containing the code you want
to deploy. Leave the default as master or specify the applicable branch.
• Nsg Source Data Connecon—Specify your storage account connecon string for
your Azure Network Watcher.
1. From the Microso Azure Console, open the Storage accounts page, and select
the storage account that contains the connecon string for the Azure Network
Watcher you have configured for data collecon by Cortex XDR.
3. Copy the applicable Connecon string and paste it in the Nsg Source Data
Connecon field.
• Output Binding—Select where you want to send you logs to either xdr (default) or
eventhub.
• XDR Host—Specify the API URL that you recorded when you configured the Azure
Network Watcher collecon in Cortex XDR.
• XDR Token—Specify the token you received when
4. Click Review + Create to confirm your sengs for the Azure Funcon.
5. Click Create. It can take a few minutes for the deployment to complete.
Once events start to come in, a green check mark appears underneath the Azure Network
Watcher configuraon that you created in Cortex XDR with the amount of data received.
Ingest Logs and Data from Okta

Ingesng external logs and data requires a Cortex XDR Pro per TB license.
To receive logs and data from Okta, you must configure the Collecon Integraons sengs in
Cortex XDR. Aer you set up data collecon, Cortex XDR immediately begins receiving new logs
and data from the source. The informaon from Okta is then searchable in XQL Search using the
okta_sso_raw dataset.
You can collect all types of events from Okta. When seng up the Okta data collector in Cortex
XDR, a field called Okta Filter is available to configure collecon for events of your choosing. All
events are collected by default unless you define an Okta API Filter expression for collecng the
data, such as filter=eventType eq “user.session.start”.\n. For Okta informaon
to be weaved into authencaon stories, “user.authentication.sso” events must be
collected.
STEP 1 | Idenfy the domain name of your Okta service.

From the Dashboard of your Okta console, note your Org URL.
For more informaon, see the Okta Documentaon.
STEP 2 | Obtain your authencaon token in Okta.

1. Select API > Tokens.
2. Create Token and record the token value.
This is your only opportunity to record the value.
STEP 3 | Select Sengs ( ) > Configuraons > Data Collecon > Collecon Integraons.
STEP 4 | Integrate the Okta authencaon service with Cortex XDR.

1. Specify the OKTA DOMAIN (Org URL) that you idenfied on your Okta console.
2. Specify the TOKEN used to authencate with Okta.
3. Specify the Okta Filter to configure collecon for events of your choosing. All events
are collected by default unless you define an Okta API Filter expression for collecng
the data, such as filter=eventType eq “user.session.start”.\n. For Okta
informaon to be weaved into authencaon stories, “user.authentication.sso”
events must be collected.
4. Test the connecon sengs.
5. If successful, Enable Okta log collecon.
Once events start to come in, a green check mark appears underneath the Okta
configuraon with the amount of data received.
STEP 5 | Aer Cortex XDR begins receiving informaon from the service, you can Create an XQL
Query to search for specific data. When including authencaon events, you can also Create
an Authencaon Query to search for specific authencaon data.
Ingest Logs from Windows DHCP using Elascsearch Filebeat

You can configure Cortex XDR to receive Windows DHCP logs using Elascsearch Filebeat with
the following data collectors.
• XDR Collectors (recommended)
• Windows DHCP
Ingest Windows DHCP Logs with an XDR Collectors Profile
enrich network logs with Windows DHCP data when defining data collecon in a XDR Collector
profile. 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 XQL dataset
(microsoft_dhcp_raw).
While this enrichment is also available when configuring a Windows DHCP Collector for a cloud
data collecon integraon, we recommend configuring Cortex XDR to receive Windows DHCP
logs with an XDR Collectors profile as it’s the ideal setup configuraon.
Configure Cortex XDR to receive logs from Windows DHCP via Elascsearch Filebeat with an
XDR Collectors profile.
STEP 1 | Add a XDR Collector Profile.
Follow all the steps explained in this secon, where you only need to ensure that you configure
the Filebeat configuraon file as explained in the following step.
STEP 2 | Configure the Filebeat configuraon file to collect Windows DHCP data.
enrich network logs with Windows DHCP data when defining data collecon by seng the
following secon and tags in the filebeat.yml file.
To avoid formang issues in your filebeat.yml, we recommend that if you copy

and paste the code syntax provided below into your file that you validate the YML
format to ensure the syntax is valid.
# ================================= Processors
=================================
processors:
- dissect:
tokenizer:
"%{id},%{date},%{time},%{description},%{ipAddress},%{hostName},
%{macAddress},%{userName},%{transactionID},%{qResult},
%{probationTime},%{correlationID},%{dhcid},%{vendorClassHex},
- drop_fields:
fields: ["message"]
- add_locale: ~
- rename:
fields:
- add_tags:
tags: [windows_dhcp]
target: "xdr_log_type"
Ingest Windows DHCP Logs with the Windows DHCP Collector
To receive Windows DHCP logs, you must configure data collecon from Windows DHCP via
Elascsearch Filebeat. This is configured by seng up a Windows DHCP Collector in Cortex XDR
and installing and configuring an Elascsearch* Filebeat agent on your Windows DHCP Server.
Cortex XDR supports using Filebeat up to version 8.0.1 with the Windows DHCP Collector.
Certain sengs in the Elascsearch Filebeat default configuraon file called filebeat.yml
must be populated with values provided when you configure the Collecon Integraons sengs
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. Aer you
set up collecon integraon, Cortex XDR begins receiving new logs and data from the source.
For more informaon on configuring the filebeat.yml file, see the Elasc Filebeat
Documentaon.
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 secons - Event ID Meaning and
the events list.
As soon as Cortex XDR begins receiving logs, the app automacally 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 XQL dataset.
Configure Cortex XDR to receive logs from Windows DHCP via Elascsearch Filebeat with the
Windows DHCP collector.
STEP 1 | Configure the Windows DHCP Collector in Cortex XDR.

2. In the Windows DHCP Collector configuraon, click Add Instance to begin a new
configuraon.
3. (Oponal) 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.
image below.
provide this key when you set the api_key value in the Elascsearch Output secon 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.

7. In the Integraons 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 Elascsearch Output secon in the filebeat.yml file as explained
in Step #2.
STEP 2 | Configure an Elascsearch Filebeat agent on your Windows DHCP Server.

1. Navigate to the Elascsearch Filebeat installaon directory, and open the
filebeat.yml file to configure data collecon with Cortex XDR. We recommend that
you use the download example file provided by Cortex XDR.
2. Update the following secons and tags in the filebeat.yml file. The example code
below details the specific secons to make these changes in the file.
To avoid formang issues in your filebeat.yml, we recommend that you do

not copy and paste the code syntax provided below into your file, and use the
download example file to make your customizaons.
• Filebeat inputs—Define the paths to crawl and fetch. The code below provides an
example of how to configure the Filebeat inputs secon 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
• Elascsearch 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
Elascsearch Output secon in the filebeat.yml file and indicates which sengs
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 secon in the filebeat.yml file and indicates
which sengs need to be obtained from Cortex XDR.
The tokenizer definion is dependent on the Windows server version that

you are using as the log format differs.
-For plaorms earlier than Windows Server 2008, use "%{id},%{date},
%{macAddress}"
-For Windows Server 2008 and 2008 R2, use "%{id},%{date},
%{qResult},%{probationTime},%{correlationID}"
For Windows Server 2012 and above, use "%{id},%{date},
%{qResult},%{probationTime},%{correlationID},
%{dhcid},%{vendorClassHex},%{vendorClassASCII},
%{userClassHex},%{userClassASCII},
# ================================= Processors
=================================
processors:
- dissect:
tokenizer: "%{id},%{date},%{time},%{description},
%{ipAddress},%{hostName},%{macAddress},%{userName},
%{transactionID},%{qResult},%{probationTime},
%{correlationID},%{dhcid},%{vendorClassHex},
- drop_fields:
fields: ["message"]
- add_locale: ~
- rename:
fields:
- add_cloud_metadata: ~
- add_docker_metadata: ~
- add_kubernetes_metadata: ~

STEP 4 | Aer Cortex XDR begins receiving logs from Windows DHCP via Elascsearch Filebeat, you
can use the XQL Search to search for logs in the new dataset (microsoft_dhcp_raw).
Ingest Logs from Zscaler Cloud Firewall

If you use Zscaler Cloud Firewall 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 detecon and invesgaon capabilies. Cortex XDR can use the firewall and network
logs from Zscaler Cloud Firewall as the sole data source, and can also use these firewall and
network logs from Zscaler Cloud Firewall in conjuncon with Palo Alto Networks firewall and
network logs. For addional 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 performs these acons.
• Begins stching network connecon and firewall logs with other logs to form network stories.
Cortex XDR can also analyze your logs to raise Analycs alerts and can apply IOC, BIOC, and
Correlaon Rule matching. You can also use queries to search your network connecon logs.
• Creates a Zscaler XQL dataset (<Vendor>_<Product>_raw) based on the <Vendor> and
<Product> fields defined on the Zscaler Cloud Firewall syslog configuraon. This enables you
to search the logs using XQL Search.
syslog collector. To provide seamless log ingeson, Cortex XDR automacally maps the fields in
your traffic logs to the Cortex XDR log format.
To ingest logs from Zscaler Cloud Firewall:
STEP 2 | Increase log storage for Zscaler Cloud Firewall logs. For more informaon, see Manage Your
Log Storage within Cortex XDR.
STEP 3 | Configure NSS log forwarding in Zscaler Cloud Firewall to the Syslog Collector.
1. In the Zscaler Cloud Firewall applicaon, go to Administraon > Nanolog Streaming
Service.
2. In the NSS Feeds tab, Add NSS Feed.
3. In the Add NSS Feed screen, configure the fields for the Cortex XDR Syslog Collector.
The following image displays the fields required to add an NSS feed.
For more informaon on configuring the other configuraons on the screen, see
the Zscaler Cloud Firewall documentaon for Adding NSS Feeds for Firewall
Logs.
• SIEM TCP Port—Specify the port that you set when acvang the Syslog Collector in
Cortex XDR. See Step 1.
• SIEM IP Address—Specify the IP that you set when acvang the Syslog Collector in
Cortex XDR. See Step 1.
• Feed Escape Character—Specify the feed escape character as =.

• Feed Output Type—Select Custom.
• Feed Output Format—Specify the output format using the following:
%s{mon} %02d{dd} %02d{hh}:%02d{mm}:%02d{ss} zscaler-

nss-fw 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 cs5=%s{threatcat}
cs5Label=threatcat cs6=%s{threatname} cs6label=threatname
cn1=%d{durationms} cn1Label=durationms cn2=%d{numsessions}
cn2Label=numsessions cs5Label=ipCat cs5=%s{ipcat}
destCountry=%s{destcountry} avgduration=%d{avgduration}
4. Click Save.
5. Click Save and acvate the change according to the Zscaler Cloud Firewall
documentaon.
Ingest Authencaon Logs and Data

Ingesng Authencaon Logs and Data requires a Cortex XDR Pro per TB license.
When you ingest authencaon logs and data from an external source, Cortex XDR can weave
that informaon into authencaon stories. An authencaon story unites logs and data
regardless of the informaon source (for example, from an on-premise KDC or from a cloud-based
authencaon service) into a uniform schema. To search authencaon stories, you can use the
Query Builder or XQL Search.
Cortex XDR can ingest authencaon logs and data from the following authencaon services.
• AWS CloudTrail
• Microso Azure Event Hub
• GCP Pub/Sub
• Google Workspace
• Microso Office 365
• Okta
• PingFederate
• PingOne
Ingest Audit Logs from AWS Cloud Trail

You can forward audit logs for the relave 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 collecon from Amazon S3. You can then configure the Collecon
Integraons sengs in Cortex XDR for Amazon S3. Aer you set up collecon integraon, Cortex
XDR begins receiving new logs and data from the source.
For more informaon on configuring data collecon from Amazon S3 using AWS
CloudTrail, see the AWS CloudTrail Documentaon.
For example queries, refer to the in-app XQL Library. You can also configure Cortex XDR to stch
Amazon S3 audit logs with other Cortex XDR authencaon 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 (IOC, BIOC, and Correlaon Rule only) when
relevant from Amazon S3 logs.
Be sure you do the following tasks before you begin configuring data collecon 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).
operaons. You have the following opons.
Configure Cortex XDR to receive audit logs from Amazon S3 via AWS Cloudtrail.
STEP 3 | Configure an AWS CloudTrail trail with audit logs.
For more informaon on creang 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).
1. Open the CloudTrail Console, and click Create trail.

2. Configure the following sengs for your CloudTrail trail, where the default sengs
should be configured unless otherwise indicated.
• Trail name—Specify a descripve name for your CloudT rail trail.
• Storage locaon—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 exisng S3 bucket and Browse to the S3 bucket you already created. If you select
an exisng Amazon S3 bucket, the bucket policy must grant CloudTrail permission to
write to it. For informaon about manually eding the bucket policy, see Amazon S3
Bucket Policy for CloudTrail.
It is the customer’s responsibility to define a retenon policy for your

Amazon S3 bucket by creang a Lifecycle rule in the Management tab. We
recommend seng the retenon 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 Exisng key, and select the AWS KMS alias. The KMS
key and S3 bucket must be in the same region.
• SNS noficaon delivery—(Oponal) If you want to be nofied whenever CloudTrail
publishes a new log to your Amazon S3 bucket, click Enabled. Amazon Simple
Noficaon Service (Amazon SNS) manages these noficaons, which are sent for
every log file delivery to your S3 bucket, as opposed to every event. When you enable
this opon, you can either Create a new SNS topic by selecng New and the SNS
topic is displayed in the field, or use an Exisng topic and select the SNS topic. For
more informaon, see Configure SNS Noficaons for CloudTrail.
The CloudWatch Logs - oponal sengs are not supported and should be le
disabled.
3. Click Next, and configure the following Choose log events sengs.
• 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 operaons performed on or within a resource, or Insights events
to idenfy unusual acvity, errors, or user behavior in your account. Based on your
selecon, addional fields are displayed on the screen to configure under secon
headings with the same name as the event type.
• Management events secon—Configure the following sengs.
-API acvity—For Management events, select the API acvies you want to log. By
default, the Read and Write acvies are logged.
-Exclude AWS KMS events—(Oponal) 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 secon—(Oponal) This secon is displayed when you configure the
Event type to include Data events, which relate to resource operaons performed on
or within a resource, such as reading and wring to a S3 bucket. For more informaon
on configuring these oponal sengs in AWS CloudTrail, see Creang a trail.
• Insights events secon—(Oponal) This secon is displayed when you configure the
Event type to include Insight events, which relate to unusual acvies, errors, or
user behavior on your account. For more informaon on configuring these oponal
sengs in AWS CloudTrail, see Creang a trail.
4. Click Next.
5. In the Review and create page, look over the trail configuraons sengs that you have
configured and if they are correct, click Create trail. If you need to make a change, click
Edit beside the parcular 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 informaon, see Creang a
trail.
STEP 4 | Configure an Amazon Simple Queue Service (SQS).
region.
1. In the Amazon SQS Console, click Create Queue.

2. Configure the following sengs, where the default sengs should be configured unless
otherwise indicated.
• Type—Select Standard queue (default).
• Name—Specify a descripve name for your SQS queue.
• Configuraon secon—Leave the default sengs 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 noficaon
messages to your SQS queue. Use this sample code as a guide for defining the
“Statement” with the following definions:
-“Resource”—Leave the automacally 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 secon, select the bucket that you created for collecng the
Amazon S3 flow logs, click Copy ARN, and paste the ARN in the field.
For more informaon on granng permissions to publish messages to an SQS

queue, see Granng permissions to publish event noficaon messages to
a desnaon.
{
"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-leer queue secon—We recommend that you configure a queue for sending
undeliverable messages by selecng Enabled, and then in the Choose queue field
selecng 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 informaon, see Amazon SQS
dead-leer queues.
3. Click Create queue.
Once the SQS is created, a message indicang that the queue was successfully
configured is displayed at the top of the page.
Amazon S3 bucket.
1. Open the Amazon S3 Console and in the Properes tab of your Amazon S3 bucket, scroll
down to the Event noficaons secon, and click Create event noficaon.
2. Configure the following sengs.
• Event name—Specify a descripve name for your event noficaon containing up to
255 characters.
• Prefix—Do not set a prefix as the Amazon S3 bucket is meant to be a dedicated
bucket for collecng audit logs.
• Event types—Select All object create events for the type of event noficaons that
you want to receive.
• Desnaon—Select SQS queue to send noficaons 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 selecng the Amazon SQS that you created. In the Details secon, under ARN,
click the copy icon ( )), and paste the ARN in the field.
3. Click Save changes.

Once the event noficaon is created, a message indicang that the event noficaon
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.
STEP 6 | Configure access keys for the AWS IAM user that Cortex XDR uses for API operaons.

Users.
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 seng 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.
STEP 7 | Update the Access policy of your Amazon SQS queue.
Skip this step if you are using an Assumed Role for Cortex XDR .
1. In the Amazon SQS Console, select the SQS queue that you created in Configure an
Amazon Simple Queue Service (SQS).
2. Select the Access policy tab, and Edit the Access policy code in the editor
window to enable the IAM user to perform operaons 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 definions.
• “aws:SourceArn”—Specify the ARN of the AWS IAM user. You can retrieve the
User ARN from the Security credenals tab, which you accessed when configuring
access keys for the AWS API user.
• “Resource”—Leave the automacally generated ARN for the SQS queue that is
name”.

a desnaon.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
},
"Condition": {
"ArnLike": {
}
}
},
{
"Sid": "__receiver_statement",
"Effect": "Allow",
"Principal": {
"AWS": "[Add the ARN for the AWS IAM user]"
},
"Action": [
"SQS:ChangeMessageVisibility",
"SQS:DeleteMessage",
"SQS:ReceiveMessage"
],

the SQS queue defined by AWS]"
}
]
}
STEP 8 | Configure the Amazon S3 collecon in Cortex XDR .

for Cortex XDR, ensure that youedit the policy that defines the permissions for the
retrieve your Amazon SQS ARN, see Specify SQS queue.
• 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
XDR in AWS.
XDR in AWS.
• Log Type—Select Audit Logs to configure your log collecon to receive audit logs from
Amazon S3 via AWS CloudTrail. When configuring audit log collecon, the following
You can Normalize and enrich audit logs by selecng the checkbox. If selected, Cortex
XDR stches Amazon S3 audit logs with other Cortex XDR authencaon stories
across all cloud providers using the same format, which you can query with XQL
Search using the cloud_audit_logs dataset.

logs.
Hub.
Azure portal.
raw.
XDR.

• SignInLogs
• ADFSSignInLogs
Hub.
Hub.

designated policy.
connecon string.
configure.
to CEF or LEEF.
configurable.
-Vendor—Cisco
-Product—ASA
configurable.
-Vendor—Corelight
-Product—Zeek
are configurable.
-Vendor—Ms
-Product—Azure
ingesng.
opons.
xdr_data datasets.

format.
your GCP instance.
GCP.


Create.

necessary.


displayed.
Corelight.
set to CEF or LEEF.
configurable.
-Vendor—Cisco
-Product—ASA
configurable.
-Vendor—Corelight
-Product—Zeek
are configurable.
-Vendor—Google
receiving logs.


topic=<TOPIC_NAME>
from Cortex XDR.



pubsub.publisher






displayed.
Corelight.
set to CEF or LEEF.
configurable.
-Vendor—Cisco
-Product—ASA
configurable.
-Vendor—Corelight
-Product—Zeek
are configurable.
-Vendor—Google
receiving logs.
Ingest Logs and Data from Google Workspace

Ingesng logs from Google Workspace requires a Cortex XDR Pro per TB 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.
• Google Chrome
• Admin Console
• Google Chat
• Enterprise Groups
• Login
• Rules
• Google drive
• Token
• User Accounts
• SAML
• 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).
• Aachment details, when Get Aachment Info is selected, includes file name, size, and hash
calculaon.
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
• Admin Reports API (part of Admin SDK API)
• Emails require implemenng the Gmail API.
To receive logs from Google Workspace for any of the data types except emails, you must first
enable the Google Workspace Admin SDK API with a user with access to the Admin SDK Reports
API. For emails, you must set up a compliance email account as explained in the prerequisite
step below and then enable the Google Workspace Gmail API. Once implemented, you can then
configure the Collecon Integraons sengs in Cortex XDR. Aer you set up data collecon,
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 collecng, which you can use to iniate XQL Search queries. For example
queries, refer to the in-app XQL Library. For all logs, Cortex XDR can raise Cortex XDR alerts for
Correlaon Rules only, when relevant from Google Workspace logs.
The following table lists the different datasets, vendors, and products automacally configured for
the different types of data you can collect using the Google Workspace data collector.
Data Type Dataset Vendor Product
Google Chrome Google

google_workspace_chrome_raw Workspace Chrome
Admin Console Google

google_workspace_admin_console_raw Workspace Admin
Console
Google Chat Google

google_workspace_chat_raw Workspace Chat
Enterprise Groups Google Workspace

google_workspace_enterprise_groups_raw
Enterprise Groups
Login Google
google_workspace_login_raw Workspace Login
Rules Google
google_workspace_rules_raw Workspace Rules
Google drive Google

google_workspace_drive_raw Workspace Drive
Token Google
google_workspace_token_raw Workspace Token
User Accounts Google

google_workspace_user_accounts_raw Workspace User
Accounts
SAML Google
google_workspace_saml_raw Workspace SAML
Emails google_gmail_raw Google Gmail
Be sure you do the following tasks before you begin configuring data collecon from Google
Workspace using the instrucons detailed below.
• When configuring data collecon for all data types except emails, complete the following API
setup steps in the Reports API Prerequisites to set up the Google Workspace Admin SDK
environment.
1. Set up the basics
2. Set up a Google API Console project without acvang the Reports API service as this will
be explained in greater detail in the task below.
• Before you can collect Google emails, you need to set up the following.
1. A compliance email account.
2. In every user’s email account that you want to monitor, you need to ensure that the user
creates a rule to filter their emails to the compliance email account. When creang this rule,
ensure that every user sets the following in their filter rule.
• To—Specify the user’s email address, such as myemail@gmail.com, whose emails will
be monitored and forwarded to the compliance email account.
• Select Forward it to:, and then select the email address for the compliance email account,
where the emails will be forwarded.
This rule ensures to forward every message sent to the user’s account to a defined compliance
mailbox. Aer the Google Workspace data collector ingests the emails, they are deleted from
the compliance mailbox to prevent email from building up over me (nothing touches the actual
users’ mailboxes).
• Spam emails from the compliance email account, and from all other monitored email
accounts, are not collected.
• Any dra emails wrien in the compliance email account are collected by the
Google Workspace data collector, and are then deleted even if the email was never
sent.
STEP 1 | Complete the applicable prerequisite steps for the types of data you want to collect from
Google Workspace.
STEP 3 | Perform Google Workspace Domain-Wide Delegaon of Authority when collecng any type
of data from Google Workspace except Google Emails.
When collecng any type of data from Google Workspace except emails, you need to set
up Google Workspace enterprise applicaons to access users’ data without any manual
authorizaon. This is performed by following these steps.
For more informaon on the enre process, see Perform Google Workspace Domain-
Wide Delegaon of Authority.
1. Enable the Admin SDK API to create a service account and set credenals for this service
account.
As you complete this step, you need to gather informaon related to your service
account, including the Client ID, Private key file, and Email address, which you will need
to use later on in this task.
1. Select the Hamburger menu > APIs & Services > Library.
2. Search for the Admin SDK API, and select the API from the results list.
3. Enable the Admin SDK API.
4. Select APIs & Services > Credenals.
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 automacally used to populate the
following field as the service account ID, where the name is changed to lowercase
leers 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.
• (Oponal) Specify a service account descripon.
7. CREATE AND CONTINUE.
8. (Oponal) 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 locaon 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.
2. Delegate domain-wide authority to your service account with the Admin Reports API
scopes.
1. Open the Google Admin Console.
2. Select Security > Access and data control > API controls.
3. Scroll down to the Domain wide delegaon secon, and select MANAGE DOMAIN
WIDE DELEGATION.
4. Click Add new.
5. Set the following sengs 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 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 informaon on the Admin Reports API scopes, see OAuth 2.0
Scopes for Google APIs.
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 for all of the users of your domain.
STEP 4 | Enable the Gmail API to collect Google emails.

When you are configuring the Google Workspace data collector to collect Google emails, the
instrucon differ depending on whether you are configuring the collecon along with other
types of data with the Admin SDK API already set up or you are configuring the collecon to
only include emails using only the Gmail API. The steps below explain both scenarios.
1. Select the Hamburger menu > APIs & Services > Library.
2. Search for the Gmail API, and select the API from the results list.
3. Enable the Gmail API.
4. Select APIs & Services > Credenals.
The instrucons for seng up credenals differ depending on whether you are seng
up the Gmail API together with the Admin SDK API as you are collecng other data
types, or you are configuring collecon for emails only with the Gmail API.
• When you’ve already set up the Admin SDK API, verify that the same Service Account
that you configured for the Admin SDK API is listed, and connue on to the next step.
• When you’re only collecng 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 automacally used to populate the
following field as the service account ID, where the name is changed to lowercase
leers 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.
-(Oponal) Specify a service account descripon.
3. CREATE AND CONTINUE.
4. (Oponal) 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 locaon 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.
5. 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 delegaon secon, 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
gmail.addons.current.message.action
gmail.addons.current.message.metadata
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 informaon on the Gmail API scopes, see OAuth 2.0 Scopes for
Google APIs.
The instrucons differ depending on whether you are seng up the Gmail API
together with the Admin SDK API as you are collecng other data types, or you are
configuring collecon for emails only with the Gmail API.
• When you’ve already set up the Admin SDK API, Edit the same Service Account
that you configured for the Admin SDK API, and add the Gmail API scopes listed
above.
• When you’re only collecng Google emails without the Admin SDK API, click Add
New, and set the following sengs 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 connue 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.
STEP 5 | Prepare your service account to impersonate a user with access to the Admin SDK Reports
API when collecng 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 collecng 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.
1. In the Google Admin Console, select Directory > Users.
2. 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.
3. Record the email of this user as you will need it in Cortex XDR.
STEP 6 | In Cortex XDR, select Sengs ( ) > Configuraons > Data Collecon > Google Workspace.
STEP 7 | In the Google Workspace configuraon, click Add Instance to begin a new configuraon.
STEP 8 | Integrate the applicable Google Workspace service with Cortex XDR.
1. Specify a descripve Name for your log collecon integraon.
2. Browse to the JSON file containing your service account key Credenals for the Google
Workspace Admin SDK API that you enabled. If you’re only collecng Google emails,
ensure that you Browse to the JSON file containing your service account key Credenals
for the Gmail API that you enabled.
3. 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
acvity reports.
• Admin Console—Account informaon about different types of administrator acvity
events included in the Admin console applicaon's acvity reports.
• Google Chat—Chat acvity events included in the Chat acvity reports.
• Enterprise Groups —Enterprise group acvity events included in the Enterprise
Groups acvity reports.
• Login—Account informaon about different types of login acvity events included in
the Login applicaon's acvity reports.
• Rules—Rules acvity events included in the Rules acvity report.
• Google drive—Google Drive acvity events included in the Google Drive applicaon's
acvity reports.
• Token—Token acvity events included in the Token applicaon's acvity reports.
• User Accounts—Account informaon about different types of User Accounts acvity
events included in the User Accounts applicaon's acvity reports.
• SAML—SAML acvity events included in the SAML acvity report.
• Emails—Collects email data (not emails reports). All message details except email
headers and email content (payload.body, payload.parts, and snippet).
For more informaon about the events collected from the various Google
Reports, see Google Workspace Reports API Documentaon.
For all opons selected, except Emails, you must specify the Reports Admin 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 selecng Emails, configure the following.
• Audit Email Account—Specify the email address for the compliance mailbox that you
set up.
• Get Aachment Info from the ingested email, which includes file name, size, and hash
calculaon.
To test the connecon, you must select one or more log types. Cortex XDR then tests
the connecon sengs for the selected log types.
5. If successful, Enable Google Workspace log collecon.
Ingest Logs from Microso Office 365

• Ingesng logs from Microso Office 365 requires a Cortex XDR Pro per TB license.
• Ingesng Azure AD authencaon and audit events from Microso Graph API requires
a Microso Azure Premium 1 or Premium 2 license.
Cortex XDR can ingest the following logs and data from Microso Office 365 Management
Acvity API and Microso Graph API using the Office 365 data collector.
• Microso Office 365 audit events from Management Acvity API, which provides informaon
about various user, administrator, system, and policy acons and events from Office 365, Azure
AD and MDO acvity logs.
• Microso Office 365 emails via Microso’s Graph API, which requires a compliance mailbox to
ingest email.
• All message details except the body, bodyPreview, and subject.
• Aachment details including file name, file type, file hash, size, and id.
Prerequisite Step—Before you can collect Microso Office 365 emails, you need to setup a
compliance email account, and then configure an Email Flow Rule. This rule ensures to Blind
carbon copy (Bcc) every message sent to, from, and within the organizaon to a defined
compliance mailbox. Aer the Office 365 data collector ingests the emails, they are deleted
from the compliance mailbox to prevent email from building up over me (nothing touches the
actual users’ mailboxes).
• The Bcc field always returns an empty value from Microso’s Graph API.
• Junk emails from the compliance email account are collected. All other junk emails
from the other monitored email accounts are not collected.
• Any dra emails wrien in the compliance email account are collected by the Office
365 data collector, and are then deleted even if the email was never sent.
• Azure AD authencaon and audit events from Microso Graph API.
To address Azure reporng latency, there is a 10-minute latency period for Cortex
XDR to receive Azure AD logs.
• Office 365 Alerts from Microso Graph Security API
• Alerts from the following providers are available via the Microso Graph Security API
—Microso Defender for Cloud, Azure Acve Directory Identy Protecon, Microso
Defender for Cloud Apps, Microso Defender for Endpoint, Microso Defender for Identy,
Microso 365, Azure Informaon Protecon, and Azure Sennel.
For more informaon, see the Office 365 Management Acvity API schema.
To receive logs from Microso Office 365, you must first configure the Collecon Integraons
sengs in Cortex XDR. Aer you set up data collecon, 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 collecng, which you can use to iniate XQL Search queries. For
example queries, refer to the in-app XQL Library. When relevant, Cortex XDR normalizes Azure
AD authencaon logs into authencaon stories, and Azure AD audit logs are normalized to
cloud audit logs stories. For Azure AD authencaon and audit logs only, Cortex XDR can also
raise Cortex XDR alerts (Analycs, IOC, BIOC, and Correlaon Rules only) when relevant from
Azure AD logs. For all other logs, Cortex XDR can raise Cortex XDR alerts for Correlaon Rules
only, when relevant from Office 365 logs.
The following table lists the different datasets, vendors, and product automacally configured for
the different types of data you can collect using the Office 365 data collector.
Data Type Dataset Vendor Product
Microso Office 365

audit events from
Management Acvity
API
-Azure AD Acvity msft_o365_azure_ad_raw

msft O365 Azure AD
Logs
-Exchange Online msft_o365_exchange_online_raw

msft O365 Exchange
Online
-Sharepoint Online msft_o365_sharepoint_online_raw

msft O365 Sharepoint
Online
-DLP msft_o365_dlp_raw msft O365 DLP
-General msft_o365_general_raw
msft O365 General
Microso Office 365 msft_o365_emails_raw

msft o365_emails
emails via Microso’s
Graph API
Azure AD msft_azure_ad_raw msft Azure AD

authencaon events
from Microso Graph
API
Azure AD audit msft_azure_ad_audit_raw

msft Azure AD Audit
events from
Microso Graph API
Alerts from Microso msft_graph_security_alerts_raw

msft Security Alerts
Graph Security API
STEP 1 | From the Microso Azure 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 Permissions
Microso Office 365 audit events from

Management Acvity API
-Azure AD Acvity Logs ActivityFeed.Read
-Exchange Online ActivityFeed.Read
-Sharepoint Online ActivityFeed.Read
-DLP ActivityFeed.ReadDlp
-General ActivityFeed.Read
Microso Office 365 emails via Microso’s Mail.ReadWrite

Graph API
Azure AD authencaon and audit events • AuditLog.Read.All

from Microso Graph API
• Directory.Read.All
Alerts from Microso Graph Security API • SecurityAlert.Read.All

• SecurityEvents.Read.All
For more informaon on Microso Azure, see the following instrucons in the Microso
documentaon portal.
• Register an app.
• Add API permissions with type Applicaon.
• Create an applicaon secret.
STEP 2 | Select Sengs ( ) > Configuraons > Data Collecon > Office 365.
STEP 3 | In the Office 365 configuraon, click Add Instance to begin a new configuraon.
STEP 4 | Integrate the applicable Microso Azure service with Cortex XDR.
1. Specify the Tenant Domain of your Microso Azure AD tenant.
2. Obtain the Applicaon Client ID and Secret for your Azure AD service from the
Microso Azure Console and specify the values in Cortex XDR.
These values enable Cortex XDR to authencate with your Azure AD service.
3. Select the types of logs that you want to receive from Office 365.
The following opons are available.
Opons Data Source Descripon of Events
Azure AD Authencaon Microso Graph API Azure AD Sign-in logs.

Logs
Azure AD Audit Logs Microso Graph API Azure AD Audit logs

includes different
categories, such as
User Management,
Group Management and
Applicaon Management.
Azure AD Acvity Logs Office 365 Management Includes subset of Azure

Acvity API AD audit events and Azure
AD authencaon events.
Use this
opon when
you don’t
want to grant
permissions
for Azure AD
Authencaon
and Azure
AD Audit.
Exchange Online Office 365 Management Includes audit logs on

Acvity API Azure Exchange mailboxes
and Exchange admin
acvies on the Office
365 Exchange.
Sharepoint Online Office 365 Management Includes audit events on

Acvity API Sharepoint and OneDrive
acvies.
DLP Office 365 Management Includes Microso 365

Acvity API DLP events for Exchange,
Sharepoint, and OneDrive.
Opons Data Source Descripon of Events
General Office 365 Management Includes audit logs for

Acvity API various Microso 365
applicaons, such as
Power BI and Microso
Forms.
Alerts from Microso Microso Graph Security Includes an aggregaon

Graph Security API API of Microso 365 security
products/services alerts.
Emails—To collect Microso Graph API Includes the raw email

Microso Office 365 events from Office 365.
emails with a compliance
mailbox to ingest email,
configure the following.
• Audit Email Account—
Specify the email
address for the
compliance mailbox.
• Get Aachment Info
from the ingested
email.

To test the connecon, you must select one or more log types. Cortex XDR then tests
the connecon sengs for the selected log types.
5. If successful, Enable Office 365 log collecon.

collected.



Ingest Authencaon Logs from PingFederate

Ingesng Authencaon Logs requires a Cortex XDR Pro per TB license.
To receive authencaon 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.
Aer you set up log collecon, Cortex XDR immediately begins receiving new authencaon logs
from the source. Cortex XDR creates a dataset named ping_identity_pingfederate_raw.
Logs from PingFederate are searchable in XQL queries using the dataset and surfaced, when
relevant, in authencaon stories.
STEP 2 | Set up PingFederate to write logs in CEF.

To set up integraon, you must have an account for the PingFederate management dashboard
and access to create a subscripon 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.
STEP 3 | To search for specific authencaon logs or data, you can Create an Authencaon Query or
use the XQL Search.
Ingest Authencaon Logs and Data from PingOne

Ingesng Authencaon Logs and Data requires a Cortex XDR Pro per TB license.
To receive authencaon logs and data from PingOne for Enterprise, you must first set up a
Poll subscripon in PingOne and then configure the Collecon Integraons sengs in Cortex
XDR. Aer you set up collecon integraon, Cortex XDR immediately begins receiving new
authencaon logs and data from the source. These logs and data are then searchable in Cortex
XDR.
STEP 1 | Set up PingOne for Enterprise to send logs and data.

To set up integraon, you must have an account for the PingOne management dashboard and
access to create a subscripon for SSO logs.
From the PingOne Dashboard:
1. Set up a Poll subscripon.
1. Select Reporng > Subscripons > Add Subscripon.
2. Enter a NAME for the subscripon.
3. Select Poll as the subscripon type.
4. Leave the remaining defaults and select Done.
2. Idenfy your account ID and subscripon ID.
1. Select the subscripon you just set up and note the part of the poll URL between /
reports/ and /poll-subscripons. 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-subscripons/ and /events. This is
your subscripon ID.
In the example above, the subscripon ID is ***-0912348765-4567-98012***.
STEP 3 | Connect Cortex XDR to your PingOne for Enterprise authencaon service.
1. Enter your PingOne ACCOUNT ID.
2. Enter your PingOne SUBSCRIPTION ID.
3. Enter your PingOne USER NAME.
4. Enter your PingOne PASSWORD.
6. If successful, Enable PingOne authencaon log collecon.
Aer configuraon is complete, Cortex XDR begins receiving informaon from the
authencaon service. From the Integraons page, you can view the log collecon summary.
STEP 4 | To search for specific authencaon logs or data, you can Create an Authencaon Query or
Create an XQL Query.
Ingest Operaon and System Logs from Cloud Providers

• Ingest Alerts from Prisma Cloud
• Ingest Alerts from Prisma Cloud Compute
• Ingest Generic Logs from Amazon S3
• Ingest Generic Logs from AWS CloudTrail and Amazon CloudWatch
• Ingest Logs from Google Kubernetes Engine
• Ingest Logs and Data from a GCP Pub/Sub
• Ingest Logs from Microso Azure Event Hub
• Ingest Logs and Data from Okta
Ingest Alerts from Prisma Cloud

Ingesng alerts from Prisma Cloud requires a Cortex XDR Pro per TB license.
To receive alerts from Prisma Cloud, first configure the Collecon Integraons sengs in Cortex
XDR. Aer you set up collecon integraon, 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 XQL dataset (prisma_cloud_raw),
which you can use to iniate XQL Search queries and create Correlaon 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 informaon on the cloud collectors, see External Data Ingeson
Vendor Support. The Prisma Cloud alerts are stched 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
secon of the Prisma Cloud Administrator’s Guide
• Copy or download the Access Key ID and Secret Key as you will need them when configuring
the Prisma Cloud Collector in Cortex XDR.
Configure Cortex Cortex XDR to receive alerts from Prisma Cloud.
STEP 2 | In the Prisma Cloud Collector configuraon, click Add Instance to begin a new configuraon.
STEP 3 | Set the following parameters.

• Specify a Name to idenfy the connecon.
• 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.
STEP 4 | Click Test to validate the connecon, and then click Enable.
In Cortex Cortex XDR, once alerts start to come in, a green check mark appears underneath
the Prisma Cloud Collector configuraon with the amount of data received.
STEP 5 | (Oponal) Manage your Prisma Cloud Collector.

Aer you enable the Prisma Cloud Collector, you can make addional changes, as needed.
To modify a configuraon, select any of the following opons.
• Edit the Prisma Cloud Collector sengs.
• Disable the Prisma Cloud Collector.
• Delete the Prisma Cloud Collector.
STEP 6 | Aer Cortex 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
Cortex XDR Alerts table. In the Cortex Cortex XDR Alerts table, the Prisma Cloud alerts are
listed as Prisma Cloud in the ALERT SOURCE column.
Ingest Alerts from Prisma Cloud Compute

Ingesng alerts from Prisma Cloud Compute requires a Cortex XDR Pro per TB license.
To receive alerts from Prisma Cloud Compute, first configure the Collecon Integraons sengs
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. Aer 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 XQL dataset
(prisma_cloud_compute_raw), which you can use to iniate XQL Search queries and to create
Correlaon Rules. The in-app XQL Library contain sample search queries.
Configure Cortex XDR to receive alerts from Prisma Cloud Compute.
STEP 1 | Select Sengs ( ) > Configuraons > Data Collecon > Collecon Integraons
STEP 2 | In the Prisma Cloud Compute Collector configuraon, click Add Instance to begin a new
alerts integraon.
STEP 3 | Specify the Name for the Prisma Cloud Compute Collector displayed in Cortex XDR.
STEP 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 integraon. 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.
STEP 5 | Copy api url.

In the Collecon Integraons 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 configuraon in Prisma Cloud Compute.
The URL format for the tenant is https://api-<tenant

name>.xdr.us.paloaltonetworks.com/logs/v1/prisma.
STEP 6 | Create a webhook as explained in the Webhook Alerts secon of the Prisma Cloud
Administrator’s Guide (Compute).
1. Use the Webhook opon to configure the webhook.
2. In Incoming Webhook URL, paste the API URL that you copied and recorded from Copy
api url..
3. In Credenal Opons, select Basic Authencaon, and use the Username and Password
that you saved when you generated the token in Cortex XDR.
4. Select Container Runme.
5. Click Save.
In Cortex XDR, once alerts start to come in, a green check mark appears underneath the
Prisma Cloud Compute Collector configuraon with the amount of data received.
STEP 7 | (Oponal) Manage your Prisma Cloud Compute Collector.

Aer you enable the Prisma Cloud Compute Collector, you can make addional changes, as
needed.
• Edit the Prisma Cloud Compute Collector sengs.
• Disable the Prisma Cloud Compute Collector.
• Delete the Prisma Cloud Compute Collector.
STEP 8 | Aer 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 Cortex XDR 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.
Ingest Generic Logs from Amazon S3

You can forward generic logs for the relave service to Cortex XDR from Amazon S3.
To receive generic data from Amazon Simple Storage Service (Amazon S3), you must first configure
data collecon from Amazon S3. You can then configure the Collecon Integraons sengs in
Cortex XDR for Amazon S3. Aer you set up collecon integraon, Cortex XDR begins receiving
new logs and data from the source.
For more informaon on configuring data collecon from Amazon S3, see the Amazon S3
Documentaon.
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 (Correlaon Rules only) when relevant from Amazon S3 logs.
You need to set up an Amazon S3 data collector to receive generic logs when collecng
logs from BeyondTrust Privilege Management Cloud. For more informaon, see Ingest
Logs from BeyondTrust Privilege Management Cloud.
Be sure you do the following tasks before you begin configuring data collecon from Amazon S3.
• Create a dedicated Amazon S3 bucket, which collects the generic logs that you want captured.
For more informaon, see Creang a bucket using the Amazon S3 Console.
It is the customer’s responsibility to define a retenon policy for your Amazon S3

bucket by creang a Lifecycle rule in the Management tab. We recommend seng
the retenon 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 mul-line format is not supported.
• The log format must be compressed as gzip or uncompressed.
• For best performance, we recommend liming 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).
operaons. You have the following opons:
Configure Cortex XDR to receive generic logs from Amazon S3.
STEP 3 | Configure an Amazon Simple Queue Service (SQS).
region.
1. In the Amazon SQS Console, click Create Queue.

2. Configure the following sengs, where the default sengs should be configured unless
otherwise indicated.
• Type—Select Standard queue (default).
• Name—Specify a descripve name for your SQS queue.
• Configuraon secon—Leave the default sengs 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 noficaon
messages to your SQS queue. Use this sample code as a guide for defining the
“Statement” with the following definions.
-“Resource”—Leave the automacally generated ARN for the SQS queue that is
name”.
You can retrieve your bucket’s ARN by opening the Amazon S3 Console in a browser
window. In the Buckets secon, select the bucket that you created for collecng the
Amazon S3 flow logs, click Copy ARN, and paste the ARN in the field.

a desnaon.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
},
"Condition": {
"ArnLike": {
}
}
}
]
}
• Dead-leer queue secon—We recommend that you configure a queue for sending
undeliverable messages by selecng Enabled, and then in the Choose queue field
selecng 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 informaon, see Amazon SQS
dead-leer queues.
3. Click Create queue.
Once the SQS is created, a message indicang that the queue was successfully
configured is displayed at the top of the page.
Amazon S3 bucket.
1. Open the Amazon S3 Console and in the Properes tab of your Amazon S3 bucket, scroll
down to the Event noficaons secon, and click Create event noficaon.
2. Configure the following sengs:
• Event name—Specify a descripve name for your event noficaon containing up to
255 characters.
• Prefix—Do not set a prefix as the Amazon S3 bucket is meant to be a dedicated
bucket for collecng only network flow logs.
• Event types—Select All object create events for the type of event noficaons that
you want to receive.
• Desnaon—Select SQS queue to send noficaons 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 selecng the Amazon SQS that you created. In the Details secon, under ARN,
click the copy icon ( )), and paste the ARN in the field.
3. Click Save changes.

Once the event noficaon is created, a message indicang that the event noficaon
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.
STEP 5 | Configure access keys for the AWS IAM user.

Users.
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 seng 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.
STEP 6 | Update the Access policy of your Amazon SQS queue.
Skip this step if you are using an Assumed Role for Cortex XDR.
1. In the Amazon SQS Console, select the SQS queue that you created in Configure an
Amazon Simple Queue Service (SQS).
2. Select the Access policy tab, and Edit the Access policy code in the editor
window to enable the IAM user to perform operaons 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 definions.
• “aws:SourceArn”—Specify the ARN of the AWS IAM user. You can retrieve the
User ARN from the Security credenals tab, which you accessed when configuring
access keys for the AWS API user.
• “Resource”—Leave the automacally generated ARN for the SQS queue that is
name”.

a desnaon.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
},
"Condition": {
"ArnLike": {
}
}
},
{
"Sid": "__receiver_statement",
"Effect": "Allow",
"Principal": {
"AWS": "[Add the ARN for the AWS IAM user]"
},
"Action": [
"SQS:ChangeMessageVisibility",
"SQS:DeleteMessage",
"SQS:ReceiveMessage"
],

the SQS queue defined by AWS]"
}
]
}

for Cortex XDR, ensure that you edit the policy that defines the permissions for the
retrieve your Amazon SQS ARN, see Specify SQS queue.
• AWS Client ID—Specify the Access key ID, which you received when you
• AWS Client Secret—Specify the Secret access key you received when you
XDR in AWS.
XDR in AWS.
• Log Type—Select Generic to configure your log collecon to receive generic logs
from Amazon S3, which can include different types of data, such as file and metadata.
When selecng this opon, the following addional fields are displayed.
• Log Format—Select the log format type as Raw, JSON, CEF, LEEF, Cisco, Corelight,
or Beyondtrust Cloud ECS.
set to CEF or LEEF.
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 sengs. 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 sengs. If you did
not specify a Vendor or Product in the Amazon S3 data collector sengs,
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
automacally set and not configurable.
-Vendor—Beyondtrust
-Product—Privilege Management
-Compression—Uncompressed
For more informaon, see Ingest Logs from BeyondTrust Privilege Management
Cloud.
configurable.
-Vendor—Cisco
-Product—ASA
configurable.
-Vendor—Corelight
-Product—Zeek
are configurable.
-Vendor—AMAZON
-Product—AWS
• Vendor—(Oponal) Specify a parcular vendor name for the Amazon
S3 generic data collecon, which is used in the Amazon S3 XQL dataset
receiving logs.
• Product—(Oponal) Specify a parcular product name for the Amazon S3
generic data collecon, which is used in the Amazon S3 XQL dataset name
receiving logs.
• Compression—Select whether the logs are compressed into a gzip file or are
uncompressed.
Ingest Generic Logs from AWS CloudTrail and Amazon

CloudWatch
You can forward generic logs for the relave service to Cortex XDR from AWS CloudTrail or
Amazon CloudWatch.
You can ingest generic logs of the raw data from Amazon Kinesis Firehose. To enable log
forwarding, you set up Amazon Kinesis Firehose and then add that to your AWS CloudTrail
or Amazon CloudWatch configuraon. Aer you complete the set up process, logs from the
respecve service are then searchable in Cortex XDR to provide addional informaon and
context to your invesgaons.
To set up AWS integraon, you require certain permissions in AWS. You need a role that enables
access to configuring Amazon Kinesis Firehose.
STEP 1 | Set up the AWS integraon in Cortex XDR.
2. In the AWS configuraon, click Add Instance to begin a new configuraon.
4. Specify the Vendor and Product for the type of logs you are ingesng.
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 resulng dataset name as
amazon_aws_raw. To uniquely idenfy the log source, consider changing the values.
5. Choose the format of the data input source (CloudTrail or CloudWatch) that you will
export to Cortex XDR, either JSON or Text.
6. Save & Generate Token.
provide this key when you set up output sengs 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.
STEP 2 | Create a Kinesis Data Firehose delivery stream to your chosen desnaon.
1. Log in to the AWS Management Console, and open the Kinesis console.
2. Select Data Firehose > Create delivery stream.
3. Define the name and source for your stream.

• Delivery stream name—Enter a descripve name for your stream configuraon.
• Source—Select Direct PUT or other sources.
• Server-side encrypon for source records in the delivery stream—Ensure this opon
is disabled.
Click Next to proceed to the process record configuraon.
4. Define the process records.
• Transform source records with AWS Lambda—Set the Data Transformaon as
Disabled.
• Convert record format—Set Record format conversion as Disabled.
Click Next to proceed to the desnaon configuraon.
5. Choose a desnaon for the logs.
Choose HTTP Endpoint as the desnaon and configure the HTTP endpoint
configuraon sengs:
• HTTP endpoint name—Specify the name you used to idenfy your AWS log collecon
configuraon in Cortex XDR.
• HTTP endpoint URL—Copy the API URL associated with your log collecon from the
Cortex XDR management console (Sengs ( ) > Configuraons > Data Collecon
> Custom Collectors > Copy API URL. 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 configuraon of
your Cortex XDR log collecon sengs.
• Content encoding—Select GZIP. Disabling content encoding may result in high egress
costs.
• Retry duraon—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 integraon.
Click Next to proceed to the sengs configuraon.
6. Configure addional sengs.
• HTTP endpoint buffer condions—Set the Buffer size as 1 MiB and the Buffer interval
as 60 seconds.
• S3 buffer condions—Use the default sengs for Buffer size as 5 MiB and Buffer
interval as 300 seconds unless you have alternave sizing preferences.
• S3 compression and encrypon—Choose your desired compression and encrypon
sengs.
• Error logging—Select Enabled.
• Permissions—Create or update IAM role opon.
Select Next.
7. Review your configuraon and Create delivery stream.
When your delivery stream is ready, the status changes from Creang to Acve.
STEP 3 | To begin forwarding logs, add the Kinesis Firehose instance to your AWS CloudTrail or
Amazon CloudWatch configuraon.
To do this, add a subscripon filter for Amazon Kinesis Firehose.

STEP 5 | Aer Cortex XDR begins receiving logs from your Amazon services, you can use the XQL
Search to search for logs in the new dataset.

format.
your GCP instance.
GCP.


Create.

necessary.


displayed.
Corelight.
set to CEF or LEEF.
configurable.
-Vendor—Cisco
-Product—ASA
configurable.
-Vendor—Corelight
-Product—Zeek
are configurable.
-Vendor—Google
receiving logs.


topic=<TOPIC_NAME>
from Cortex XDR.



pubsub.publisher






displayed.
Corelight.
set to CEF or LEEF.
configurable.
-Vendor—Cisco
-Product—ASA
configurable.
-Vendor—Corelight
-Product—Zeek
are configurable.
-Vendor—Google
receiving logs.
Ingest Logs from Google Kubernetes Engine

Instead of forwarding Google Kubernetes Engine (GKE) logs directly to Google StackDrive, Cortex
XDR can ingest container logs from GKE using Elascsearch* Filebeat. To receive logs, you must
install Filebeat on your containers and enable Data Collecon sengs for Filebeat.
Aer Cortex XDR begins receiving logs, the app automacally creates an XQL dataset using the
vendor and product name that you specify during Filebeat setup. It is recommended to specify
a descripve 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.
Aer Cortex XDR creates the dataset, you can search your GKE logs using XQL Search.
STEP 1 | Install Filebeat on your containers.
For more informaon, see hps://www.elasc.co/guide/en/beats/filebeat/current/running-on-
kubernetes.html.
STEP 2 | Ingest Logs from Elascsearch Filebeat.

Record your token key and API URL for the Filebeat Collector instance as you will need these
later in this workflow.
STEP 3 | Deploy a Filebeat as a DaemonSet on Kubernetes.

This ensures there is a running instance of Filebeat on each node of the cluster.
1. Download the manifest file to a locaon where you can edit it.
curl -L -O https://raw.githubusercontent.com/elastic/
beats/7.10/deploy/kubernetes/filebeat-kubernetes.yaml
2. Open the YAML file in your preferred text editor.

3. Remove the cloud.id and cloud.auth lines.
4. For the output.elasticsearch configuraon, 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.
5. In the DaemonSet configuraon, locate the env configuraon and replace

ELASTIC_CLOUD_AUTH, ELASTIC_CLOUD_ID, ELASTICSEARCH_USERNAME,
ELASTICSEARCH_PASSWORD, ELASTICSEARCH_HOST, ELASTICSEARCH_PORT and
their relave 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 (Sengs ( ) > Configuraons > Data
Collecon > 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
configuraon of your Filebeat Collector instance.
Aer you configure these sengs your configuraon should look like the following
image.
STEP 4 | If you use RedHat OpenShi, you must also specify addional sengs.
See hps://www.elasc.co/guide/en/beats/filebeat/7.10/running-on-kubernetes.html.
STEP 5 | Deploy Filebeat on your Kubernetes.
kubectl create -f filebeat-kubernetes.yaml
This will deploy Filebeat in the kube-system namespace. If you want to deploy the Filebeat
configuraon in other namespaces, change the namespace values in the YAML file (in any
YAML inside this file) and add -n <your_namespace>.
Aer you deploy your configuraon, the Filebeat DameonSet will run throughout your
containers to forward logs to Cortex XDR. You can review the configuraon from the
Kubernetes Engine console: Workloads > Filebeat > YAML.
Cortex XDR supports logs in single line format or mulline format. For more
informaon on handling messages that span mulple lines of text in Elascsearch
Filebeat, see Manage Mulline Messages.
STEP 6 | Aer Cortex XDR begins receiving logs from GKE, you can use the XQL Search to search for
logs in the new dataset.

logs.
Hub.
Azure portal.
raw.
XDR.

• SignInLogs
• ADFSSignInLogs
Hub.
Hub.

designated policy.
connecon string.
configure.
to CEF or LEEF.
configurable.
-Vendor—Cisco
-Product—ASA
configurable.
-Vendor—Corelight
-Product—Zeek
are configurable.
-Vendor—Ms
-Product—Azure
ingesng.
opons.
xdr_data datasets.

collected.



Ingest Cloud Assets

• Ingest Cloud Assets from AWS
• Ingest Cloud Assets from Google Cloud Plaorm
• Ingest Cloud Assets from Microso Azure
Ingest Cloud Assets from AWS

Ingesng Cloud Assets from AWS requires a Cortex XDR Pro per TB 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 invesgaon.
To receive cloud assets from AWS, you must configure the Collecon Integraons sengs in
Cortex XDR using the Cloud Inventory data collector to configure the AWS wizard. The AWS
wizard includes instrucons to be completed both in AWS and the AWS wizard screens. Aer you
set up data collecon, 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 collecon in Cortex XDR.
STEP 1 | Open the AWS wizard in Cortex XDR.
2. In the Cloud Inventory configuraon, click Add Instance to begin a new configuraon.
3. Click AWS.
STEP 2 | Define the Account Details screen of the wizard.

Seng the connecon parameters on the right-side of the screen are dependent on certain
configuraons in AWS as explained below.
1. Select the Organizaon Level as either Account (default), Organizaon, or Organizaon
Unit. The Organizaon Level that you select changes the instrucons and fields
displayed on the screen.
2. Sign in to your AWS master account.
3. Create a stack called XDRCloudApp using the preset Cortex XDR template in AWS.
The following details are automacally filled in for you in the AWS CloudFormaon 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
authencate 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 relaonship in the role's trust policy.
To create the stack, accept the IAM acknowledgment for resource creaon by selecng
the I acknowledge that AWS CloudFormaon might create IAM resources with custom
names checkbox, and click Create Stack.
4. 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.
5. Select the Outputs tab and copy the Value of the Role ARN.
6. 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 Organizaon Level that you selected.
• Account—Paste the value in the Account Role ARN field.
• Organizaon—Paste the value in the Master Role ARN field.
• Organizaon Unit—Paste the value in the Master Role ARN field.

7. Set the Root ID in Cortex XDR.
This step is only relevant if you’ve configured the Organizaon Level as

Organizaon in the Account Details screen in Cortex XDR. Otherwise, you can
skip this step if the Organizaon Level is set to Account or Organizaon Unit.
1. On the main menu of the AWS Console, select <your username> > My Organizaon.
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.
8. Set the Organizaon Unit ID in Cortex XDR.

Organizaon Unit in the Account Details screen in Cortex XDR. Otherwise, you
can skip this step if the Organizaon Level is set to Account or Organizaon.
1. On the main menu of the AWS Console, select <your username> > My Organizaon.
2. Select the Organizaon Unit with an icon-ou ( ) beside it in the organizaonal

structure that you want to configure.
3. Copy the ID and paste it in the Organizaon Unit ID field in the Account Details
screen in Cortex XDR.
9. Define the following remaining connecon parameters in the Account Details screen in
Cortex XDR.
• Account Role External ID / Master External ID—The name of this field is dependent
on the Organizaon Level configured. This field is automacally populated with a
value. You can either leave this value or replace it with another value.
• Cortex XDR Collecon Name—Specify a name for your Cortex XDR collecon that is
displayed underneath the Cloud Inventory configuraon for this AWS collecon.
10. Click Next.
STEP 3 | Define the Configure Member Accounts screen of the wizard.
This wizard screen is only displayed if you’ve configured the Organizaon Level as
Organizaon or Organizaon Unit in the Account Details screen in Cortex XDR.
Otherwise, you can skip this step when the Organizaon Level is set to Account.
Configuring member accounts is dependent on creang a stack set and configuring stack
instances in AWS, which can be performed using either the Amazon Command Line Interface
(CLI) or Cloud Formaon template via the AWS Console. Both of these methods are explained
in the instrucons below.
• Define the account credenals using Amazon CLI.
1. Select the Amazon CLI tab, which is displayed by default.
2. Open the Amazon CLI.
For more informaon on how to set up the AWS CLI tool, see the AWS
Command Line Interface Documentaon.
3. Run the following command to create a stack set, which you can copy from the Configure
Member Accounts screen by selecng 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 selecng the copy icon ( ),
and paste in the Amazon CLI. For the --deployment-targets parameter, specify
the organizaon root ID to deploy to all accounts in your organizaon, or specify
Organizaon Unit IDs to deploy to all accounts in these Organizaon Units. In this
parameter, you will need to replace <Org_OU_ID1>, <Org_OU_ID2>, and <Region>
according to your AWS sengs.
aws cloudformation create-stack-instances --stack-

set-name StackSetCortexXdr01 --deployment-targets
OrganizationalUnitIds='["<Org_OU_ID1>", "<Org_OU_ID2>"]' --
regions '["<Region>"]'
In this example, the Organizaon 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 > CloudFormaon > StackSets,
and you can see the StackSet is now listed in the table.
• Define the account credenals using AWS CloudFormaon.
1. Select the Cloud Formaon tab.
2. Download the CloudFormaon template. The name of the file downloaded is called
cortex-xdr-aws-master-ro-1.0.0.template.
3. Sign in to your AWS Master Account using the AWS console, select Services >
CloudFormaon > StackSets, and click Create StackSet.
4. Define the following sengs.

-Select Template is ready.
-Select Upload a template file, Choose file, and select the CloudFormaon template that
you downloaded.
5. Click Next.

-StackSet name—Specify a name for the StackSet.
-ExternalID—The ExternalID value specified here must be copied from the one
populated in the External ID field on the right-side of the Configure Member Accounts
7. Click Next.
8. Select Service-managed permissions, and click Next.

Deployment targets
-Select Deploy to the organizaon.
-Select Enabled for Automac deployments.
-Select Delete stacks for Account removal behavior.
Specify regions
-Select a region.
Deployment opons
-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 creaon by
selecng the I acknowledge that AWS CloudFormaon 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.
STEP 4 | Review the Summary screen of the wizard.

If something needs to be corrected, you can go Back to correct it.

Once cloud assets from AWS start to come in, a green check mark appears underneath the
Cloud Inventory configuraon with the Last collecon me displayed. It can take a few
minutes for the Last Collecon me to display as the processing completes.
Whenever the Cloud Inventory data collector integraons are modified by using the
Edit, Disable, or Delete opons, it can take up to 10 minutes for these changes to be
reflected in Cortex XDR.
STEP 6 | Aer 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 informaon, see Cloud Inventory Assets.
Ingest Cloud Assets from Google Cloud Plaorm

Ingesng Cloud Assets from Google Cloud Plaorm requires a Cortex XDR Pro per TB
license.
Cortex XDR provides a unified, normalized asset inventory for cloud assets in Google Cloud
Plaorm (GCP). This capability provides deeper visibility to all the assets and superior context for
incident invesgaon.
To receive cloud assets from GCP, you must configure the Collecon Integraons sengs in
Cortex XDR using the Cloud Inventory data collector to configure the GCP wizard. The GCP
wizard includes instrucons to be completed both in GCP and the GCP wizard screens. Aer you
set up data collecon, Cortex XDR begins receiving new data from the source.
To configure the GCP cloud assets collecon in Cortex XDR.
STEP 1 | Open the GCP wizard in Cortex XDR.
3. Click Google Cloud Plaorm.
STEP 2 | Define the Configure Account screen of the wizard.

configuraons in GCP as explained below.
1. Select the Organizaon Level as either Project (default), Folder, or Organizaon. The
Organizaon Level that you select changes the instrucons.
2. Register your applicaon for Cloud Asset API in Google Cloud Plaorm, Select a project
where your applicaon will be registered, and click Connue.
The Cloud Asset API is enabled.
3. Click Connue to open the GCP Cloud Console.

4. On the main menu, select the project menu.
5. In the window that opens, perform the following.
1. From the Select from menu, select the organizaon that you want.
2. The next steps to perform in Google Cloud Plaorm are dependent on the
Organizaon Level you selected in Cortex XDR - Project, Folder, or Organizaon.
• Project or Folder Organizaon 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
Organizaon 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.
• Organizaon is the Organizaon Level—Select the ellipsis icon ( ) > Sengs. In
the Sengs page, copy the Organizaon ID for the applicable organizaon that
you want to configure and paste it in the Organizaon Id field in the Configure
Account screen in Cortex XDR.
6. Select the Hamburger menu > Storage > Cloud Storage > Browser.
7. You can either use an exisng 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
8. Define the following remaining connecon 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 Collecon Name—Specify a name for your Cortex XDR collecon that is
displayed underneath the Cloud Inventory configuraon for this GCP collecon.
9. Click Next.

1. Download the Terraform script. The name of the file downloaded is dependent on the
Organizaon 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
• Organizaon—cortex-xdr-gcp-organization-ro.tf
2. Login to the Google Cloud Shell.
3. Click Connue to open the Cloud Shell Editor.
4. Select File > Open, and Open the Terraform script that you downloaded from Cortex
XDR.
5. 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. teraform init—Inializes the Terraform script. You need to wait unl the
inializaon is complete before running the next command as indicated in the image
below.
2. terraform apply—When running this command you will be asked to enter the
following values.
• 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 applicaon. Ensure that you use a
permanent project.
• var.project_id—Specify the Project ID, Folder ID, or Organizaon ID that you
configured in the Configure Account screen of the wizard from GCP.
Aer specifying all the values, you need to Authorize gcloud to use your
credenals to make this GCP API call in the Authorize Cloud Shell dialog box that
is displayed.
Before the acon completes, you need to confirm whether you want to perform
these acons, and aer the process finishes running an Apply complete indicaon
is displayed.
You can view the output JSON file called cortex-service-account-<GCP

host project ID>.json by running the ls command.
6. 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 aer running the Terraform script, and click Download.
7. 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.
8. Click Next.
STEP 4 | (Oponal) Define the Change Asset Logs screen of the wizard.
You can skip this step if you’ve already configured a Google Cloud Plaorm data
collector with a Pub/Sub asset feed collecon.
1. In the GCP Console, search for Topics, and select the Topics link.
2. CREATE TOPIC.
3. Specify a Topic ID, and CREATE TOPIC.
A Topic name is automacally populated underneath the Topic ID field.
The new topic is listed in the table in the Topics page.

4. 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 selecng the copy
icon ( ), and paste in the gcloud CLI tool.
For more informaon 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.
• <FEED_ID>—Replace this placeholder text with a unique asset feed idenfier of your
choosing.
• --project—This parameter is automacally populated from the Project ID field in
the Configure Account screen wizard in Cortex XDR.
• <Topic name>—Replace this placeholder text with the name of the topic you
created in the Topic details page in the GCP console.
5. In the GCP Console, search for Subscripon, and select the Subscripons link.
6. CREATE SUBSCRIPTION for the topic you created.

• Subscripon ID—Specify a unique idenfier for the subscripon.
• Select a Cloud Pub/Sub topic—Select the topic you created.
• Delivery type—Select Pull.
8. Click CREATE.
The new subscripon is listed in the table in the Subscripons page.
9. Select the subscripon that you created for your topic and add PERMISSIONS for the
subscriber in the Subscripon details page.
10. 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 as you created in the
JSON file.
• Select a role—Select Pub/Sub Subscriber.
11. Copy the Subscripon name and paste it in the Subscripon Name field on the right-side
of the Change Asset Logs screen in Cortex XDR, and click Next.
The Subscripon Name is the name of the new Google Cloud Plaorm data
collector that is configured with a Pub/Sub asset feed collecon in Cortex XDR
under Sengs ( ) > Configuraons > Data Collecon > Collecon Integraons
> Google Cloud Plaorm.


Once cloud assets from GCP start to come in, a green check mark appears underneath the
Cloud Inventory configuraon with the Last collecon me displayed. It can take a few
In addion, if you created a Pub/Sub asset feed colleconcreated a Pub/Sub asset feed
collecon, a green check mark appears underneath the Google Cloud Plaorm configuraon
with the amount of data received.
STEP 7 | Aer Cortex XDR begins receiving GCP cloud assets, you can view the data in Assets >
Ingest Cloud Assets from Microso Azure

Ingesng Cloud Assets from Microso Azure requires a Cortex XDR Pro per TB license.
Cortex XDR provides a unified, normalized asset inventory for cloud assets in Microso Azure.
This capability provides deeper visibility to all the assets and superior context for incident
invesgaon.
To receive cloud assets from Microso Azure, you must configure the Collecon Integraons
sengs in Cortex XDR using the Cloud Inventory data collector to configure the Microso Azure
wizard. The Microso Azure wizard includes instrucons to be completed both in Microso Azure
and the Microso Azure wizard screens. Aer you set up data collecon, Cortex XDR begins
receiving new data from the source.
To configure the Microso Azure cloud assets collecon in Cortex XDR.
STEP 1 | Open the Microso Azure wizard in Cortex XDR.
3. Click Azure.
STEP 2 | Define the Configure Account screen of the wizard.

configuraons in Microso Azure as explained below.
1. Select the Organizaon Level as either Subscripon (default), Tenant, or Management
Group. The Organizaon Level that you select changes the instrucons and fields
displayed on the screen.
2. Login to your Microso Azure Portal.
3. Search for Subscripons, select Subscripons, copy the applicable Subscripon ID in
Azure, and paste it in the Subscripon ID field in the Configure Account screen wizard in
Cortex XDR.

Subscripon in the Configure Account screen in Cortex XDR. Otherwise, you can
skip this step if the Organizaon Level is set to Tenant or Management Group.
4. 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.

Management Group in the Configure Account screen in Cortex XDR. Otherwise,
you can skip this step if the Organizaon Level is set to Subscripon or Tenant.
5. Search for Tenant properes, select Tenant properes, copy the Tenant ID in Azure, and
paste it in the Tenant ID field in the Configure Account screen wizard in Cortex XDR.
6. Specify a Cortex XDR Collecon Name to be displayed underneath the Cloud Inventory
configuraon for this Azure collecon.
7. Click Next.

1. Download the Terraform script. The name of the file downloaded is dependent on the
Organizaon Level that you configured in the Configure Account screen of the wizard.
• Subscripon—cortex-xdr-azure-subscription-ro.tf
• Management Group—cortex-xdr-azure-group-ro.tf
• Tenant—cortex-xdr-azure-org-ro.tf
2. Login to the Azure Cloud Shell portal., and select Bash.
3. Click the upload/download icon ( ) to Upload the Terraform script to Cloud Shell,
browse to the file, and click Open.
A noficaon with the Upload desnaon is displayed on the boom-right corner of the
screen.
4. 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. teraform init—Inializes the Terraform script. You need to wait unl the
inializaon is complete before running the next command as indicated in the image
below.
2. terraform apply—When running this command you will be asked to enter the
following values, which are dependent on the Organizaon Level that you configured.
• var.subscription_id—Specify the Subscripon ID that you configured in the
Configure Account screen of the wizard from Microso Azure. This value only
needs to be specified if the Subscripon ID is set to Subscripon.
• var.management.group_id—Specify the Management Group ID that you
configured in the Configure Account screen of the wizard from Microso
Azure. This value only needs to be specified if the Management 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 Microso Azure.
Before the acon completes, you need to confirm whether you want to perform these
acons, and aer the process finishes running an Apply complete indicaon is displayed.
5. Copy the client_id value displayed in the Cloud Shell window and paste it in the
Applicaon Client ID field in the Account Details screen in Cortex XDR.
6. 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.
7. Download the JSON file from Cloud Shell using the upload/download icon ( ), so you
have output field values for future reference.
8. Click Next.


Once cloud assets from Azure start to come in, a green check mark appears underneath
the Cloud Inventory configuraon with the Last collecon me displayed. It can take a few
STEP 6 | Aer Cortex XDR begins receiving Azure cloud assets, you can view the data in Assets >
Addional Log Ingeson Methods for Cortex XDR

In addion to nave log ingeson support, Cortex XDR also supports the following custom log
ingeson methods.
• Ingest Logs from a Syslog Receiver
• Ingest CSV Files as Datasets
• Ingest Apache Kaa Events as Datasets
• Ingest Database Data as Datasets
• Ingest Logs in a Network Share as Datasets
• Ingest FTP Files as Datasets
• Ingest NetFlow Flow Records as Datasets
• Set up an HTTP Log Collector to Receive Logs
• Ingest Logs from BeyondTrust Privilege Management Cloud
• Ingest Logs from Elascsearch Filebeat
• Ingest Logs from Forcepoint DLP
• Ingest Alerts and Assets from PAN IoT Security
• Ingest Logs from Proofpoint Targeted Aack Protecon
• Ingest Data from ServiceNow CMDB
• Ingest Report Data from Workday
Ingest Logs from a Syslog Receiver

Cortex XDR can receive Syslog from a variety of supported vendors (see External Data Ingeson
Vendor Support). In addion, Cortex XDR can receive Syslog from addional vendors that use CEF,
LEEF, CISCO, CORELIGHT, or RAW formaed over Syslog (TLS not supported).
Aer Cortex XDR begins receiving logs from the third-party source, Cortex XDR automacally
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 Correlaon Rules.
To receive Syslog from an external source:
STEP 1 | Set up your Syslog receiver to forward logs.
STEP 2 | Acvate the Syslog Collector applet on a Broker VM within your network.
STEP 3 | Use the XQL Search to search your logs.
Ingest Apache Kaa Events as Datasets

Cortex XDR can receive events from Apache Kaa clusters directly to your log repository for
query and visualizaon purposes. Aer you acvate the Apache Kaa collector applet on a broker
VM in your network, which includes defining the connecon details and sengs related to the list
of subscribed topics to monitor and upload to Cortex XDR, you can collect events as datasets.
Aer Cortex XDR begins receiving topic events from the Apache Kaa clusters, Cortex XDR
automacally parses the events and creates a dataset with the specific name you set as the target
dataset when you configured the Apache Kaa Collector, and adds the data in these files to the
dataset. You can then use XQL Search queries to view events and create new Correlaon Rules.
Configure Cortex XDR to receive events as datasets from topics in Apache Kaa clusters.
STEP 1 | Acvate the Apache Kaa Collector applet on a broker VM within your network.
STEP 2 | Use the XQL Search to query and review logs.
Ingest CSV Files as Datasets

Cortex XDR can receive CSV log files from a shared Windows directory directly to your log
repository for query and visualizaon purposes. Aer you acvate the CSV Collector applet on
a broker VM in your network, which includes defining the list of folders mounted to the broker
VM and seng 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 leers (a-z, A-Z) or numbers (0-9) and must start with a
leer. Spaces are converted to underscores (_).
• Date values can be in either of the following formats:
• YYYY-MM-DD (oponally including HH:MM:SS)
• Unix Epoch me. For example, 1614858795.
Aer Cortex XDR begins receiving logs from the shared Windows directory, Cortex XDR
automacally 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 configuraon 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 Correlaon Rules.
Configure Cortex XDR to receive CSV files as datasets from a shared Windows directory.
STEP 1 | Ensure that you share the applicable CSV files in your Windows directory.
STEP 2 | Acvate the CSV Collector applet on a broker VM within your network.
STEP 3 | Use the XQL Search to locate and review logs.
Ingest Database Data as Datasets

Cortex XDR can receive data from a client relaonal database directly to your log repository for
query and visualizaon purposes. Aer you acvate the Database Collector applet on a broker
VM in your network, which includes defining the database connecon details and sengs related
to the query details for collecng the data from the database to monitor and upload to Cortex
XDR, you can collect data as datasets.
Aer Cortex XDR begins receiving data from a client relaonal database, Cortex XDR
automacally 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 connecon according to the execuon
frequency of collecon that you configured and appends the data to the dataset. You can then use
XQL Search queries to view data and create new Correlaon Rules.
Configure Cortex XDR to receive data as datasets data from a client relaonal database.
STEP 1 | Acvate the Database Collector applet on a broker VM within your network.
Ingest Logs in a Network Share as Datasets

Cortex XDR can receive logs from files and folders in a network share directly to your log
repository for query and visualizaon purposes. Aer you acvate the Files and Folders Collector
applet on a broker VM in your network, which includes defining the connecon details and
sengs related to the list of files to monitor and upload to Cortex XDR, you can collect files as
datasets.
Aer Cortex XDR begins receiving logs from files and folders in a network share, Cortex
XDR automacally parses the logs and creates a dataset with the specific name you set as
the target dataset when you configured the Files and Folders Collector using the format
<Vendor>_<Product>_raw. The Files and Folders Collector reads and processes the configured
files one by one, as well as any new files added to the configured files and folders, in the network
share according to the execuon frequency of collecon 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
Correlaon 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.
STEP 1 | Acvate the Files and Folders Collector applet on a broker VM within your network.
Ingest FTP Files as Datasets

Cortex XDR can receive logs from files and folders via FTP, FTPS, or SFTP directly to your log
repository for query and visualizaon purposes. Aer you acvate the FTP Collector applet on a
broker VM in your network, which includes defining the connecon details and sengs related to
the list of files to monitor and upload to Cortex XDR, you can collect files as datasets.
Aer Cortex XDR begins receiving logs from files and folders via FTP, FTPS, or SFTP, Cortex XDR
automacally 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 execuon
frequency of collecon 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 Correlaon Rules.
Configure Cortex XDR to receive logs as datasets from files and folders via FTP, FTPS, or SFTP.
STEP 1 | Acvate the FTP Collector applet on a broker VM within your network.
Ingest NetFlow Flow Records as Datasets

Cortex XDR can receive NetFlow flow records and IPFIX from a UDP port directly to your log
repository for query and visualizaon purposes. Aer you acvate the NetFlow Collector applet
on a broker VM in your network, which includes configuring your NetFlow Collector sengs, you
can ingest NetFlow flow records and IPFIX as datasets.
The ingested NetFlow flow record format must include, at the very least:
• Source and Desnaon IP addresses
• TCP/UDP source and desnaon port numbers
Aer Cortex XDR begins receiving flow records from the UDP port, Cortex XDR automacally
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 Correlaon Rules.
Configure Cortex XDR to receive NetFlow flow records as datasets from the routers and switches
that support NetFlow.
STEP 1 | Set up your NetFlow exporter to forward flow records to the IP address of the broker that
runs the NetFlow collector applet.
STEP 2 | Acvate the NetFlow Collector applet on a broker VM within your network.
STEP 3 | Use the XQL Search to query your flow records, using your designated dataset.
Set up an HTTP Log Collector to Receive Logs

In addion to logs from supported vendors, you can set up a custom HTTP log collector to receive
logs in Raw, JSON, CEF, or LEEF format.
Aer Cortex XDR begins receiving logs from the third-party source, Cortex XDR automacally
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 Correlaon rules.
To set up an HTTP log collector to receive logs from an external source.
STEP 1 | Create an HTTP Log collector in Cortex XDR.
1. Select Sengs ( ) > Configuraons > Custom Collecons.
2. In the HTTP configuraon, click Add Instance.
3. Specify a descripve Name for your HTTP log collecon configuraon.
4. Select the data object Compression, either gzip or uncompressed.
5. Select the Log Format as Raw, JSON, CEF, or LEEF.
Cortex XDR supports logs in single line format or mulline format. For a JSON format,
mulline logs are collected automacally when the Log Format is configured as JSON.
When configuring a Raw format, you must also define the Mulline Parsing Regex as
explained below.
-The Vendor and Product defaults to Auto-Detect when the Log Format is set to
CEF or LEEF.
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 sengs.
Yet, when the values are blank in the event log row, Cortex XDR uses the Vendor
and Product that you specified in the HTTP collector sengs. If you did not
specify a Vendor or Product in the HTTP collector sengs, and the values are
blank in the event log row, the values for both fields are set to unknown.
(<vendor>_<product>_raw). If you do not define a vendor or product, Cortex XDR
examines the log header to idenfy 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.
7. (Oponal) Specify the Mulline Parsing Regex for logs with mullines.
This opon is only displayed when the Log Format is set to Raw, so you can set the
regular expression that idenfies when the mulline event starts in logs with mullines. It
is assumed that when a new event begins, the previous one has ended.
provide this key when you configure your HTTP POST request. 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.
STEP 2 | Send data to your Cortex XDR HTTP log collector.

1. Send an HTTP POST request to the URL for your HTTP Log Collector.
For a sample curl or python request, click View Example.
2. Substute the values specific to your configuraon.
• 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.
• api_key—API key you previously recorded for your HTTP log collector.
• 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.
• 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 10Mib
records although 1 Mib is recommended. In the case of a curl command, the records
are contained in the -d ‘<records>’ parameter.
STEP 3 | Monitor your HTTP Log Collecon integraon.

You can return to the Sengs ( ) > Configuraons > Custom Collectors page to monitor the
status of your HTTP Log Collecon configuraon. For each instance, Cortex XDR displays the
number of logs received in the last hour, day, and week. You can also use the Data Ingeson
Dashboard to view general stascs about your data ingeson configuraons.
STEP 4 | Aer Cortex XDR begins receiving logs, use the XQL Search to search your logs.
Ingest Logs from BeyondTrust Privilege Management Cloud

If you use BeyondTrust Privilege Management Cloud, you can take advantage of Cortex XDR
invesgaon and detecon capabilies by forwarding your logs to Cortex XDR. This enables
Cortex XDR to help you expand visibility into computer, acvity, and authorizaon requests in the
organizaon, correlate and detect access violaons, 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 Correlaon Rules.
To integrate your logs, you first need to configure SIEM sengs and an AWS S3 Bucket according
to the specific requirements provided by BeyondTrust. You can then configure data collecon
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 collecon verify that you are using BeyondTrust Privilege
Management Cloud version 21.6.339 or later.
Configure BeyondTrust Privilege Management Cloud collecon in Cortex XDR.
STEP 1 | Configure SIEM sengs and an AWS S3 Bucket according to the requirements provided in
the BeyondTrust documentaon.
Ensure that when you add the AWS S3 bucket in the PMC and set the SIEM sengs, you
select ECS - Elasc Common Schema as the SIEM Format.
STEP 2 | Configure BeyondTrust logs collecon with Cortex XDR using an Amazon S3 data collector
for generic data.
Ensure your Amazon S3 data collector is configured with the following sengs.
• Log Type—Select Generic to configure your log collecon 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
automacally set and not configurable.
• Vendor—Beyondtrust
• Product—Privilege Management
• Compression—Uncompressed
STEP 3 | Aer 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 seng
up your Amazon S3 data collector.
Ingest Logs from Elascsearch Filebeat

If you want to ingest logs about file acvity on your endpoints and servers and do not use the
Cortex XDR agent, you can install Elascsearch* Filebeat as a system logger and then forward
those logs to Cortex XDR. To facilitate log ingeson, Cortex XDR supports the same protocols
that Filebeat and Elascsearch use to communicate. Cortex XDR supports using Filebeat up to
version 8.0.1 with the Filebeat data collector. Cortex XDR also supports logs in single line format
or mulline format. For more informaon on handling messages that span mulple lines of text in
Elascsearch Filebeat, see Manage Mulline Messages.
Cortex XDR supports all secons in the filebeat.yml configuraon file, such as support for
Filebeat fields and tags. As a result, this enables you to use the add_fields processor to idenfy the
product/vendor for the data collected by Filebeat so the collected events go through the ingeson
flow (Parsing Rules). To idenfy the product/vendor ensure that you use the default fields
aribute, as opposed to the target aribute, as shown in the following example.
processors:
- add_fields:
fields:
vendor: <Vendor>
product: <Product>
To provide addional context during invesgaons, Cortex XDR automacally creates a new
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 collecon sengs for Filebeat in Cortex XDR and output sengs in
your Filebeat installaons. As soon as Cortex XDR begins receiving logs, the data is visible in XQL
Search queries.
1. Select Sengs ( ) > Configuraons > Data Collecon > Custom Collectors.
2. In the Filebeat configuraon, click Add Instance.
3. Specify a descripve Name for your Filebeat log collecon configuraon.
(<vendor>_<product>_raw). If you do not define a vendor or product, Cortex XDR
examines the log header to idenfy 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.
provide this key when you set up output sengs 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.
STEP 2 | Set up Filebeat to forward logs.

Aer installing the Filebeat agent, configure an Elascsearch output:
1. Under the output.elascsearch secon, configure the following enes:
• hosts—Copy the API URL from your Filebeat configuraon 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 Collecon
in Cortex XDR.
• proxy_url—(Oponal) <server_ip>:<port_number>. You can specify your
own <server_ip> or use the broker VM to proxy Filebeat communicaon using the
format <broker_VM_ip>:<port_number>. When using the broker VM, ensure
that you acvate the Local Agent Sengs applet with the Agent Proxy enabled.
2. Save the changes to your output file.
Aer Cortex XDR begins receiving logs from Filebeat, they will be available in XQL Search
queries.
STEP 3 | (Oponal) Monitor your Filebeat integraon.

You can return to the Sengs ( ) > Configuraons > Data Collecon > Custom Collectors
page to monitor the status of your Filebeat configuraon. For each instance, Cortex XDR
displays the number of logs received in the last hour, day, and week. You can also use the Data
Ingeson Dashboard to view general stascs about your data ingeson configuraons.
STEP 4 | (Oponal) Set up alert noficaons to monitor the following events.

• A Filebeat agent status changes to disconnected.
• A Filebeat module has stopped sending logs.
Ingest Logs from Forcepoint DLP

If you use Forcepoint DLP to prevent data loss over endpoint channels, you can take advantage
of Cortex XDR invesgaon and detecon capabilies by forwarding your logs to Cortex XDR.
This enables Cortex XDR to help you expand visibility into data violaon by users and hosts in
the organizaon, 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 Correlaon Rules.
Syslog Collector in a CEF or LEEF format.
Configure Forcepoint DLP collecon in Cortex XDR.
STEP 1 | Verify that your Forcepoint DLP meet the following requirements.
• Must use version 8.8.0.347 or a later release.
• On premise installaon only.
STEP 2 | Acvate the Syslog Collector applet on a Broker VM in your network.

Ensure the Broker VM is configured with the following sengs.
• Format—Select either a CEF or LEF Syslog format.
• Vendor—Specify the Vendor as forcepoint.
• Product—Specify the Product as dlp_endpoint.
STEP 3 | Increase log storage for Forcepoint DLP logs.

As an esmate for inial sizing, note the average Forcepoint DLP log size. For proper sizing
calculaons, test the log sizes and log rates produced by your Forcepoint DLP. For more
informaon, see Manage Your Log Storage within Cortex XDR.
STEP 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 informaon, see the Forcepoint DLP documentaon.
STEP 5 | Aer Cortex XDR begins receiving data from Forcepoint DLP, you can use XQL Search to
search your logs using the forcepoint_dlp_endpoint dataset.
Ingest Alerts and Assets from PAN IoT Security

Ingesng alerts and assets from PAN IoT Security requires a Cortex XDR Pro per TB license.
The Palo Alto Networks IoT Security soluon discovers unmanaged devices, detects behavioral
anomalies, recommends policy based on risk, and automates enforcement without the need for
addional sensors or infrastructure. The Cortex XDR - PAN IoT Security integraon enables you to
ingest alerts and device informaon from your PAN IoT Security instance.
To receive data, configure the Collecon Integraons sengs in Cortex XDR for the PAN IoT
Security data collector in Sengs > Configuraons > Data Collecon > Collecon Integraons.
As soon as data collecon begins, Cortex XDR displays the PAN IoT Security alerts in the Cortex
XDR Alerts table and groups them into Incidents. The PAN IoT Security alerts are updated every
15 minutes. PAN IoT security alerts which were resolved before the integraon aren’t added to the
Cortex XDR table. Cortex XDR adds device acvies detected by PAN IoT Security into the Cortex
XDR Assets table. Device acvies are updated every five minutes.
Cortex XDR automacally creates a new dataset for device acvies
(panw_iot_security_devices_raw) and a new dataset for alerts
(panw_iot_security_alerts_raw), which you can use to iniate XQL Search queries and
create Correlaon Rules.
Before you configure the PAN IoT Security Collector, generate an access key and a key ID for the
integraon.
1. Log in to the PAN IoT Security portal and click your user name.
2. Select Preferences.
3. In the User Role & Access secon, Create an API Access Key.
4. Download and save the access key and key ID in a secure locaon.
For more informaon about the PAN IoT Secuity API, see Get Started with the IoT Security API.
Configure the PAN IoT Security alerts and assets collecon in Cortex XDR.
STEP 2 | In the PAN IoT Security Collector configuraon, click Add Instance to begin a new
configuraon.
STEP 3 | Specify the following parameters.

• Customer ID—Tenant domain part of the FQDN used for your PAN IoT Security account.
For example, in yourcorp.iot.paloaltonetworks.com, the customer ID is
yourcorp. The customer ID is unique and can’t be edited.
• Access Key and Key ID previously generated for the integraon.
• Integraon Scope—Select at least one of the two values, Alerts and Devices depending on
which informaon you want to ingest.
STEP 4 | Click Test to validate access, and then click Enable.

When events start to come in, a green check mark appears underneath the PAN IoT Security
Collector configuraon with the data and me that the data was last synced.
STEP 5 | (Oponal) Manage your PAN IOT Security Collector.

Aer you enable the PAN IOT Security Collector, you can make addional changes as needed.
• Edit the PAN IOT Security Collector sengs.
• Disable the PAN IOT Security Collector.
• Delete the PAN IOT Security Collector.
STEP 6 | Aer Cortex XDR begins receiving data from PAN IOT Security, you can use the XQL Search
to search for logs in the new datasets, panw_iot_security_devices_raw for device
acvies, and panw_iot_security_alerts_raw for alerts.
Ingest Logs from Proofpoint Targeted Aack Protecon

Ingesng Logs from Proofpoint Targeted Aack Protecon requires a Cortex XDR Pro per
TB license.
To receive logs from Proofpoint Targeted Aack Protecon (TAP), you must first configure TAP
service credenals in the TAP dashboard, and then the Collecon Integraons sengs in Cortex
XDR based on your Proofpoint TAP configuraon. Aer you set up data collecon, 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 iniate XQL Search queries. For example queries, refer to the in-app XQL
Library.
Configure the Proofpoint TAP collecon in Cortex XDR.
STEP 1 | Generate TAP Service Credenals in Proofpoint TAP.
TAP service credenals can be generated in the TAP Dashboard, where you will receive a
Proofpoint Service Principal for authencaon and Proofpoint API Secret for authencaon.
Record these credenals as you will need to provide them when configuring the Proofpoint
Targeted Aack Protecon data collector in Cortex XDR. For more informaon on generang
TAP service credenals, see Generate TAP Service Credenals.
STEP 2 | Configure the Proofpoint TAP collecon in Cortex XDR.

2. In the Proofpoint Targeted Aack Protecon configuraon, click Add Instance to begin a
new configuraon.
• Proofpoint Endpoint—All Proofpoint endpoints are available on the tap-api-
v2.proofpoint.com host. You can leave the default configuraon or specify
another host.
• Service Principal—Specify the Proofpoint Service Principal for authencaon. TAP
service credenals can be generated in the TAP Dashboard as explained in Generate
TAP Service Credenals in Proofpoint TAP.
• API Secret—Specify the Proofpoint API Secret for authencaon. TAP service
credenals can be generated in TAP Dashboard as explained in Generate TAP Service
Credenals in Proofpoint TAP.
Once events start to come in, a green check mark appears underneath the Proofpoint
Targeted Aack Protecon configuraon with the amount of data received.
STEP 3 | (Oponal) Manage your Proofpoint Targeted Aack Protecon data collector.
Aer you enable the Proofpoint Targeted Aack Protecon data collector, you can make
addional changes as needed.
You can perform any of the following.
• Edit the Proofpoint Targeted Aack Protecon data collector sengs.
• Disable the Proofpoint Targeted Aack Protecon data collector.
• Delete the Proofpoint Targeted Aack Protecon data collector.
Ingest Data from ServiceNow CMDB

To receive data from the ServiceNow CMDB database, you must first configure data collecon
from ServiceNow CMDB. ServiceNow CMDB is a logical representaons of assets, services, and
the relaonships between them that comprise the infrastructure of an organizaon. It is built
as a series of connected tables that contain all the assets and business services controlled by a
company and its configuraons. You can configure the Collecon Integraon sengs in Cortex
XDR for the ServiceNow CMDB database, which includes selecng 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 automacally 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 Correlaon Rules.
You can only configure a single ServiceNow CMDB Collector, which is automacally configured
every 6 hours to reload the data from the configured tables and replace the exisng data. You can
always use the Sync Now opon to reload the data and replace the exisng 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 credenals, who is designated to access the
tables from ServiceNow CMDB for data collecon in Cortex XDR. Record the credenals 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.
STEP 2 | In the ServiceNow CMDB Collector configuraon, click Add Instance to begin a new
configuraon.
STEP 3 | Set the following parameters.

• Domain—Specify your ServiceNow CMDB domain URL.
• User Name—Specify the username for your ServiceNow CMDB user that you designated to
use in Cortex XDR.
• Password—Specify the password for your ServiceNow CMDB user that you designated to
use in Cortex XDR.
• Tables—You can do any of the following acons 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. Aer each table selecon, select to add the table to the tables already
listed below for data collecon.
• Specify any custom tables that you want to configure for data collecon.
• From the default list of tables already configured, you can delete any of them by hovering
over the table and selecng the X icon.
STEP 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 configuraon with the data and me that the data was last synced.
STEP 5 | (Oponal) Manage your ServiceNow CMDB Collector.

Aer you enable the ServiceNow CMDB Collector, you can make addional changes as
needed. To modify a configuraon, select any of the following opons.
• Edit the ServiceNow CMDB Collector sengs.
• 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
automacally every 6 hours, but you can always get the latest data as needed.
STEP 6 | Aer 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.
Ingest Report Data from Workday

To receive Workday report data, you must first configure data collecon from Workday using a
Workday custom report to ingest the appropriate data. This is configured by seng up a Workday
Collector in Cortex XDR and configuring report data collecon via this Workday custom report
that you set up.
As soon as Cortex XDR begins receiving data, the app automacally creates a Workday XQL
dataset (workday_workday_raw). You can then use XQL Search queries to view the data and
create new Correlaon Rules. In addion, 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 Identy
Analycs 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 automacally configured to run the
report every 6 hours. You can always use the Sync Now opon to run the report whenever you
want.
Complete the following tasks before you begin configuring Cortex XDR to receive report data
from Workday.
1. Create an Integraon System User that is designated to access the custom report from
Workday for data collecon in Cortex XDR.
2. Create an Integraon System Security Group for the Integraon System User created in Step 1
for accessing the report. When seng this group ensure to define the following.
• Type of Tenanted Security Group—Select either Integraon System Security Group
(Constrained) or Integraon System Security Group (Unconstrained) depending on how
your data is configured. For more informaon, see the Workday documentaon.
• Integraon System User—Select the user that you defined in step 1 for accessing the
custom report.
3. Create the Workday credenals for the Integraon System User created in Step 1 so that
the username and password can be used to access the report in Cortex XDR. Record these
credenals as you will need them when configuring the Workday Collector in Cortex XDR.
For more informaon on compleng any of these prerequisite steps, see the Workday
documentaon.
Configure Cortex XDR to receive report data from Workday.
STEP 1 | Configure a Workday custom report to use for data collecon.

1. Login to the Workday Resource Center.
2. In search field, specify Create Custom Report to open the wizard.
3. Configure the following Create Custom Report sengs.
• Report Name—Specify the name of the report.

• Report Details secon.
• Report Type—Select Advanced. When you select this opon, 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 secon.
• Opmized for Performance—Select whether the data should be opmized for
performance. The way this checkbox is configured determines the Data Source
opons available to choose from.
• Date Source—Select the applicable data source containing the data that is used to
configure data collecon from Workday to Cortex XDR.
4. Click OK, and configure the following Addional Info sengs.
The Addional 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 selecng the applicable Field that you want to map to the
Cortex XDR field name required for data collecon in the Column Heading Override
XML Alias column.
• (Oponal) You can map any addional 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 selecng 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
selecng the applicable Field that contains the data represenng 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.
Cortex XDR uses a structured schema when integrang Workday data. To get
the best Analycs 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
5. (Oponal) Filter out any employees that you do not want included in the Filter tab.
6. Share access to the report with the designated Integraon System User that you created
by seng the following sengs in the Share tab.
• Report Definion Sharing Opons—Select Share with specific authorized groups and
users.
• Authorized Users—Select the designated Integraon System User that you created for
accessing the custom report.
7. Ensure that the following Web Services Opons sengs in the Advanced tab are
configured.
Here is an example of the configured sengs, where the Web Service API Version and
Namespace are automacally populated and dependent on your report.
8. (Oponal) Test the report to ensure all the fields are populated.
9. Get the URL for the report.
1. In the related acons menu, select Acons > Web Service > View URLs.
2. Click OK.
3. Scroll down to the JSON secon.
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 credenals to open
the report.
5. Copy the URL for the report and record them somewhere as this URL needs to be
provided when seng up the Workday Collector in Cortex XDR.
10. Complete the report by clicking Done.
STEP 2 | Configure the Workday collecon in Cortex XDR.

2. In the Workday Collector configuraon, click Add Instance to begin a new configuraon.
• 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 Integraon System User that
you created for accessing the custom report in Workday.
• Password—Specify the password for the designated Integraon System User that you
created for accessing the custom report in Workday.
A noficaon appears confirming that the Workday Collector was saved successfully,
and closes on its own aer a few seconds.
Once report data starts to come in, a green check mark appears underneath the
Workday Collector configuraon with the data and me that the data was last synced.
STEP 3 | (Oponal) Manage your Workday Collector.

Aer you enable the Workday Collector, you can make addional changes as needed. To
modify a configuraon, select any of the following opons.
• Edit the Workday Collector sengs.
• Disable the Workday Collector.
• Delete the Workday Collector.
• Sync Now to run the report to get the latest report data. The report is run automacally
every 6 hours, but you can always get the latest data as needed.
STEP 4 | Aer 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).
Ingest External Alerts

For a more complete and detailed picture of the acvity involved in an incident, Cortex XDR can
ingest alerts from any external source. Cortex XDR stches 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 arfacts 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, CORELIGHT, or RAW format) to the syslog collector. You can
also ingest alerts from external sources using the Cortex XDR API.
Aer Cortex XDR begins receiving external alerts, you must map the following required fields to
the Cortex XDR format.
• TIMESTAMP
• SEVERITY
• ALERT NAME
In addion, these oponal fields are available, if you want to map them to the Cortex XDR format.
• 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 XDR API, addional mapping is not required.
Storage of external alerts is determined by your Cortex XDR tenant retenon policy. For more
informaon, see Dataset Management.
To ingest external alerts.
STEP 1 | Send alerts from an external source to Cortex XDR.

There are two ways to send alerts:
• Cortex XDR 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 addional mapping step in Cortex XDR.
• Acvate Syslog collector—Acvate the syslog collector and then configure the alert source
to forward alerts to the syslog collector. Then configure an alert mapping rule as follows.
STEP 2 | In Cortex XDR, select Sengs ( ) > Configuraons > External Alerts Mapping.
STEP 3 | Right-click the Vendor Product for your alerts and select Filter and Map.
STEP 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 creaon. 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
creaon.
STEP 5 | Click Next to begin a new mapping rule.

On the le, configure the following.
1. Rule Informaon-Define the NAME and oponal DESCRIPTION to idenfy your
mapping rule.
2. Alerts Field-Map each required and any oponal 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 severies fields to the Cortex XDR risks of Crical, 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, say you need to map the port but your source field
contains both IP address and port (192.168.1.200:8080). To extract everything aer
the :, use the following regex:
^[^:]*_
For addional context when you are invesgang an incident, you can also map
addional oponal fields to fields in your alert source.
STEP 6 | Submit your alert filter and mapping rule when finished.
Data Management
> Dataset Management
> Create Parsing Rules
> Manage Event Forwarding
> Manage Compute Units Usage
811
Data Management
Dataset Management
This feature requires a Cortex XDR Pro license.
The Dataset Management page enables you to manage your datasets and understand your overall
data storage, period based retenon. The top part of the screen details your Storage License
Details as you receive log storage based on the amount of storage associated with your Cortex
XDR Licenses. All Cortex XDR licenses provide you with a default retenon of 30 days. You can
extend your license retenon depending on your requirements for the following types of storage.
• Hot Storage—Fully searchable storage, for invesgaon and threat hunng.
• Cold Storage—Cheaper storage usually for long-term compliance needs with limited search
opons.
The boom half of the screen lists your Datasets in a table format.
Once Cortex XDR starts to enforce retenon, you will not have access to data that exceeds
your retenon period. You will receive an email and in app noficaon before any changes
are implemented.
For each dataset listed in the table, the following informaon is available.
exposed by default.
Field Descripon
*DATASET NAME Name of the dataset, where only English

alphabecal characters (a-z, A-Z) are
supported. Numbers (0-9) and underscores
(_) are supported, but not as the first
character of the name.
*TYPE The type of dataset based on the method

used to upload the data.
• Correlaon—A dataset containing data
saved from a Correlaon Rule.
• Lookup—Two possible scenarios.
• Uploaded through the user interface.
• If saved by a query using the target
command, the Type can be either User
or Lookup. See the entry for target in
the XQL Language Reference for details.
• Raw—Every dataset where PANW data
is ingested out-of-the-box or third-party
Data Management
Field Descripon
data is ingested via 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. See the entry for target
in the XQL Language Reference for details.
*LOG UPDATE TYPE The event logs are updated either

connuously (Logs) or the current state is
updated periodically (State) as detailed in the
LAST UPDATED column.
*LAST UPDATED The last me the data in the dataset logs were
updated, when the LOG UPDATE TYPE is set
to State.
*TOTAL DAYS STORED The actual number of days that the data is
stored in the Cortex XDR tenant, which is
comprised of the HOT RANGE + the COLD
RANGE.
*HOT RANGE Details the exact period of the Hot Storage

from the start date to end date.
*COLD RANGE Details the exact period of the Cold Storage

from the start date to end date.
*TOTAL SIZE STORED The 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 the xdr_data dataset, where the first
30 days of storage are included with your
license, the first 30 days are not included in
the TOTAL SIZE STORED number.
*AVERAGE DAILY SIZE The average daily amount stored in the Cortex
XDR tenant. This number is dependent on the
events stored in the Hot Storage.
*TOTAL EVENTS The number of total events/logs that are

stored in the Cortex XDR tenant. This number
Data Management
Field Descripon
is dependent on the events stored in the Hot
Storage.
*AVERAGE EVENT SIZE The average size of a single event in the

dataset (TOTAL SIZE STORED divided by the
TOTAL EVENTS). This number is dependent
on the events stored in the Hot Storage.
DEFAULT QUERY TARGET Details whether the dataset is configured

to use as your default query target in XQL
Search, so when you write your queries you
do not 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 seng mulple
default datasets, your query does not need
to menon any of the dataset names, and
Cortex XDR queries the default datasets using
a join.
The datasets endpoints and host_inventory include dataset permission

enforcements in the Cortex XDR Query Language (XQL), Query Center, and XQL Widgets.
To view or access any of these datasets, you need role-based access control (RBAC)
permissions to the Endpoint Administraon and Host Inventory views. For more
informaon on RBAC, see Manage User Roles. Managed Security Services Providers
(MSSP) administraon permissions are not enforced on child tenants, but only on the
MSSP tenant.
Manage Datasets
This feature requires a Cortex XDR Pro per TB license.
Cortex XDR runs every XQL query against a dataset. A dataset is a collecon of column:value sets.
You can upload datasets as a CSV, TSV, or JSON file that contains the data you are interested in
querying. 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 as default opon.
To query other datasets, you have two opons: you can either set the dataset as default, which
enables you to query the datasets without specifying them in the query, or you can name a
specific dataset at the beginning of your query with the dataset stage command. You can add to
your list of available datasets by uploading a CSV, TSV, or JSON file to Cortex XDR.
You cannot upload a file that contains a byte array (that is, binary data).
Data Management
Cortex XDR Query Language (XQL) supports using different languages for dataset and field names.
In addion, when seng up your XQL query, it is important to keep in mind the following.
• The dataset formats supported are dependent on the data retenon 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 opon.
dataset = xdr_data
• Cold Storage queries are performed using the format cold_dataset = <dataset
name>.
cold_dataset = xdr_data
• The refresh mes for datasets. All Cortex XDR system datasets, which are created out-of-the-
box, are connuously ingested in near real-me as the data comes in, except for the following
excepons.
• 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 collecon in the Agent Sengs 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.
Manage datasets from Cortex XDR > Sengs > Configuraons > Data Management > Dataset
Management. In the Dataset Management page you can import, view, and interact with your
available datasets.
Data Management
Import a dataset.
1. Select + Lookup.
2. Browse to your CSV, TSV, or JSON file, or drag and drop it into the dialog window.You
can only upload a TSV file that contains a .tsv file extension.
When uploading a CSV, TSV, or JSON file, ensure that the file meets the
following requirements.
• Field names are supported using different languages, numbers (0-9), or
underscores (_). If you use any other characters, Cortex XDR automacally
converts them to underscores (_).
• Dataset names are supported using different languages. Numbers (0-9) and
underscores (_) are supported, but not as the first character of the name.
You can create dataset names using uppercase characters, but in queries
dataset names are always treated as if they are lowercase.
• Must start with a leer or underscore. Cannot use prefixes TABLE, FILE, or
_PARTITION.
• Cannot exceed 128 characters.
• No duplicate names, white spaces, or carriage returns.
3. (Oponal) Rename the file, where only English alphabecal characters are supported.
4. Add the file as a lookup.
5. Aer receiving a noficaon reporng that the upload succeeded, Refresh ( ) to view it
in your list of datasets.
If the file has the same name as an exisng dataset, Cortex XDR will append an
underscore and a number to the name to make it unique.
Save query results as a dataset.

You can use the target stage command to save query results as a dataset. For details about
this command, see the XQL Language Reference.
Query against a dataset by selecng it with the dataset command when you create an XQL
query.
Right-click a dataset to view the schema of the dataset, set it as default, delete it, copy it,
and show or hide datasets. In addion, for a dataset with a TYPE set to Lookup, you can also
download the JSON file.
• View Schema to view the schema informaon for every field found in the dataset result
set in the Schema tab of XQL Search. Each system field in the schema is wrien with an
underscore (_) before the name of the field in the FIELD NAME column in the table.
• Set as default to query the dataset without having to specify it in your queries in XQL
Search as dataset = <name of dataset>. Once configured, the DEFAULT QUERY
TARGET column entry for this dataset is set to Yes. By default, this opon 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
Data Management
XDR collects. Once you Set as default another dataset, you can always remove it by right-
clicking the dataset, and selecng Remove from defaults. When seng mulple default
datasets, your query does not need to menon any of the dataset names, and Cortex XDR
queries the default datasets using a join.
• Delete to remove the dataset from Cortex XDR.
• Download the JSON file for a dataset with a Type set to Lookup. This opon 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.
• Copy text to clipboard to copy the name of the dataset to your clipboard.
• Copy enre row to copy each cell in a row, separated by tabs, to your clipboard.
• Show rows with ‘<dataset_name>’ to create a filter that displays all datasets with the same
name.
• Hide rows with ‘<dataset_name>’ to create a filter that hides all datasets with the same
name.
Filter your available datasets to specify the ones you want to see.
1. Select Filter.
An interface for your filter criteria appears.
2. Select a field, an operator, and a value to match.
3. Select + AND or + OR to add addional filter expressions.
4. Save ( ) your filter to reuse it later.
Aer saving, select the three-dot menu ( ) to view your filter.
Customize the table.

Select the three-dot menu ( ) and Layout to change the width of rows and columns. You can
also select which columns to display. You can always Restore default layout to go back to
displaying the default column layout.
Data Management
Create Parsing Rules

Parsing Rules requires a Cortex XDR Pro per TB license, where only a user with Cortex XDR
Account Administrator and Instance Administrator permissions can access this screen.
Cortex XDR includes an editor for creang 3rd party Parsing Rules, which enables you to:
• Remove unused data that is not required for analycs, hunng, or regulaon.
• Reduce your data storage costs.
• Pre-process all incoming data for complex rule performance.
• Add tags to the ingested data as part of the ingeson flow.
• Easily idenfy and resolve Parsing Rules errors with error reporng.
• Test your Parsing Rules on actual logs and validate their outputs before implementaon.
Parsing Rules contain the following built-in characteriscs.
• Parsing Rules are bound to a specific vendor and product.
• Parsing Rules take raw log input, perform an arbitrary number of transions and modificaons
to the data using 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. This means, 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 ingeson, all fields are retained even fields with a null value. You can also use the Cortex
XDR XQL query language to query parsing rules for null values.
Cortex XDR provides a number of default Parsing Rules that you can easily override as required
using the Cortex XDR Query Language and addional custom syntax that is specific to creang
Parsing Rules. Before you create your own Parsing Rules and override the defaults, we recommend
that you review the following.
• Parsing Rules Editor Views
• Parsing Rules File Structure and Syntax
• Error Reporng in Parsing Rules
• Parsing Rules Raw Dataset
To create Parsing Rules:
STEP 1 | In Cortex XDR, select Sengs > Configuraons > Data Management > Parsing Rules.
Data Management
STEP 2 | Select the Parsing Rules editor view for wring your Parsing Rules.
You can select one of the following views.
• User Defined Rules—Leave the default view open and write your Parsing Rules directly in
the editor.
• 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.
For more informaon, see Parsing Rules Editor Views.
STEP 3 | Write your Parsing Rules using XQL syntax and the syntax specific for Parsing Rules. For
more informaon, see Parsing Rules File Structure and Syntax.
STEP 4 | (Oponal) 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.
1. Select the Simulate view.

2. For the User defined rules that you want to test, select the logs from the XQL Samples
listed that you want used to simulate the rule. For each Vendor and Product, up to 5
different samples are available to choose from.
3. 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.
4. Review the results in the Logs output table to determine if your User defined rules is fine
or needs further changes.
The Logs output table displays the following columns per dataset at the boom of the
window.
• Dataset—Displays the applicable dataset name and a line number associated to this
dataset in the User defined rules secon.
• 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 secon 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.
5. (Oponal) Modify your User defined rules and repeat steps #2-4 unl you are sasfied
with the results.
STEP 5 | (Oponal) Override the default Parsing Rules raw dataset.
Data Management
STEP 6 | Save your changes.

Your PARSING RULES are saved successfully.
Parsing Rules Editor Views

Parsing Rules requires a Cortex XDR Pro per TB license, where only Cortex XDR Account
Administrator and Instance Administrator have access to this screen.
The Parsing Rules editor contains the following views.
When there are any Parsing Rules errors to report, the Parsing Rules editor displays these
errors at the boom of the editor in a secon called List of Errors. Otherwise, this secon
is not displayed. For more informaon, see Error Reporng in Parsing Rules.
• User Defined Rules (default)—Displays an editor for wring your own custom parsing rules that
override the default rules and a List of Errors secon to help you troubleshoot any 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 secon 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 in one screen. In addion, the List of Errors secon 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 creang Parsing Rules. The editor includes the
following secons.
• User defined rules—A list of the current User defined rules on the le side of the window.
• XQL Samples—A table of the exisng XQL raw data samples on the right side of the
window, which contain sample logs lisng 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 boom of
the window.
-Dataset—Displays the applicable dataset name and a line number associated to this dataset
in the User defined rules secon.
-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 aer simulang 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
rules secon 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.
Data Management
Parsing Rules File Structure and Syntax

Parsing Rules requires a Cortex XDR Pro per TB license and Cortex XDR Account
Administrator and Instance Administrator permissions.
File Structure
The Parsing Rules file consists of mulple secons of these three types, which also represent the
custom syntax specific to Parsing Rules.
• INGEST—This secon is used to define the resulng dataset.
• COLLECT—(Oponal) This secon defines a rule that enables data reducon and data
manipulaon at the broker VM to help avoid sending unnecessary data to the Cortex XDR
server and reduce traffic, storage, and compung costs. In addion, the COLLECT secon is
used to manipulate, alter, and enrich the data before it’s passed to the Cortex XDR server.
While this rule is oponal to configure, once added this rule runs before the INGEST secon.
• CONST—(Oponal) This secon is used to define strings and numbers that can be re-used
mulple mes within XQL statements in other INGEST secons by using $constName.
• RULE—(Oponal) Rules are part of the XQL syntax, which are tagged with a name, and can be
reused in the code in the INGEST secons by using [rule:ruleName].
The order of the secons is unimportant. The data of each secon type gets grouped together
during the parsing stage. Before any acon 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 modificaons. This
subset of XQL is called XQL for Parsing (XQLp).
For more informaon on the XQL syntax, see Cortex XDR XQL Language Reference.
The COLLECT, CONST, INGEST, and RULE syntax is derived from XQL, but with the following
modificaons for XQLp.
• A statement never starts with dataset or preset selecon. 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 permied: alter, fields, filter, and join. In addion, a new
call stage is supported, which is used to invoke another rule.
• The join stage is only supported in CONST, INGEST, and RULE secons and is
unsupported in a COLLECT secon.
• No output stages are supported.
• A Rule object can only contain a single statement.
Data Management
• A join inner query is restricted to using a lookup as a data source and 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 condion can only take a sequence list, such as device_name in (“device1”,
“device2”, “device3”) and not another XQL or XQLp inner queries.
C-Type code comments 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 (;).
INGEST
An INGEST secon is used to define the resulng dataset. The COLLECT, CONST, and RULE
secons are only add-ons, used to help organize the INGEST secons, and are oponal to
configure. Yet, a Parsing Rules file that contains no INGEST secons, generates no Parsing Rules.
Therefore, the INGEST secon is mandatory to configure.
INGEST syntax is derived from XQL with a few modificaons as explained in the Parsing Rules
syntax. In addion, INGEST secons contain the following syntax add-ons.
• INGEST secons can have more than one XQLp statement, separated by a semicolon (;). Each
statement creates a different Parsing Rule.
• The XQL arrayfilter, arraycreate, arraymerge, and object_create funcons and iploc stage
command are also supported in the INGEST secon.
• Another new stage is available called drop.
• drop takes a condion similar to the XQL filter stage (same syntax), but drops every
log entry that passes that condion. One can think of it as a negave 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 secons take parameters, and not names as RULE secons use, where some are
mandatory and others oponal.
[ingest:vendor=<vendor>, product=<product>, dataset=<dataset>,

no_hit=<keep\drop>, ingestnull=<true\false>]
filter raw_log not contains "alert";
The parameter descripons are explained in the following table.
Data Management
Parameter Descripon
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 aer applying any of the
specified Parsing Rules (mandatory).
no_hit No-match strategy to use for the enre

specified group of rules (oponal). 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

(oponal). By default this is set to true, so
you only need to set this parameter when you
want to overwrite the default definion.
Each statement represents a different Parsing Rule in the same group as depicted in the following
example.
[CONST]
DEVICE_NAME = "ngfw";
[rule:use_two_rules]
filter severity = "medium" | call basic_rule | call
use_xql_and_another_rule;
[rule:basic_rule]
fields log_type, severity | filter log_type="eal" and severity="HIGH"
and type="something";
[rule:use_xql_and_another_rule]call multiline_statement | filter
severity = "medium";
[rule:multiline_statement]
alter url = json_extract(_raw_log, "$.url")
| join type = inner conflict_strategy = both (dataset=my_lookup) as
inn url=inn.url
Data Management
|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")
inn url=inn.url
| filter severity = "medium"
| filter severity = "medium"
inn severity=inn.severity
| fields severity, log_type
| drop device_name = $DEVICE_NAME
A few more points to keep in mind when wring INGEST secons.

• INGEST parameter names are not case sensive. Therefore, vendor=PANW and vendor=panw
are the same.
• Since secon order is unimportant, you do not have to declare a RULE or a CONST before using
it in an INGEST secon.
• You can have mulple INGEST secons with the same vendor, product, dataset and
no_hit values. Yet, this can lead to unexpected results. Consider the following example:
[ingest:vendor=panw, product=ngfw, dataset=panw_ngfw_ds,

no_hit=keep]
[ingest:vendor=panw, product=ngfw, dataset=panw_ngfw_ds,
no_hit=keep]
Data Management
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 secon 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
secon.
• 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 evaluang at 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 secons. For more informaon, see
Parsing Rules Raw Dataset.
• Cortex XDR supports configuring case sensivity in Parsing Rules only within the INGEST
secon using the following configuraon stage:
config case_sensitive = true | false
• You can add a single tagor list of tags to the ingested data as part of the ingeson flow that you
can easily query in XQL Search. You can add tags as part of the INGEST secon or using both
the INGEST and RULE secons. The following are examples of each.
• INGEST secon.
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 secons.

[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]
Data Management
tag add "test";

target_dataset="malware_test", no_hit= drop , ingestnull =
true ]
[RULE:new_tag_rule]
tag add "test1", "test2", "test3";
COLLECT
A COLLECT secon defines a rule that enables data reducon and data manipulaon at the broker
VM to help avoid sending unnecessary data to the Cortex XDR server and reduce traffic, storage,
and compung costs. In addion, the COLLECT secon is used to manipulate, alter, and enrich
the data before it’s passed to the Cortex XDR server. While this rule is oponal to configure, once
added this rule runs before the INGEST secon.
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 XQL with a few modificaons as explained in the Parsing Rules
syntax. In addion, 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 reducon and manipulaon at the broker VM for a different
vendor and product.
• While the XQL stages alter and fields are permied in COLLECT rules for various vendors and
products, you should avoid using them for supported vendors that can be used for Analycs as
these stages can disrupt the operaon of the Analycs Engine. For a list of these vendors, see
the Visibility of Logs and Alerts from External Sources in Cortex XDR table specifically those
vendors with Normalized Log Visibility.
Data Management
• Another new stage is available called drop.

• drop takes a condion similar to the XQL filter stage (same syntax), but drops every
log entry that passes that condion. One can think of it as a negave 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 secons take parameters, where some are mandatory and others oponal.
[COLLECT:vendor=<vendor>, product=<product>, target_brokers =

(bvm1, bvm2, bvm3), no_hit = <keep\drop>];
The parameter descripons are explained in the following table.
Parameter Descripon
vendor The vendor that the specified COLLECT rule

for data reducon and data manipulaon at
the broker VM applies to (mandatory).
product The product that the specified COLLECT rule

for data reducon and data manipulaon at
the broker VM applies to (mandatory).
target_brokers Specifies the list of brokers to run the

COLLECT rule for data reducon and data
manipulaon 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 enre

specified group of COLLECT rules (oponal).
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.
Data Management
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 secon.
[COLLECT:vendor="Apache", product="ApacheServer", target_brokers =

(bvm1, bvm2, bvm3), no_hit = drop]
alter source_log = json_extract_scalar(_raw_log, "$.source")
| filter source_log = "WebApp-Logs"
| fields source_log, _raw_log;
[INGEST:vendor="Apache", product="ApacheServer", target_dataset =
"dvwa_application_log"]
alter log_timestamp = json_extract_scalar(_raw_log, "$.timestamp")
| alter log_msg = json_extract_scalar(_raw_log, "$.msg")
| alter log_remote_ip = json_extract_scalar(_raw_log, "$.Remote_IP")
| alter scanned_ip = json_extract_scalar(_raw_log, "$.Scanned_IP")
| fields
log_msg ,log_remote_ip ,log_timestamp ,source_log ,scanned_ip ,
_raw_log;
A few more points to keep in mind when wring COLLECT rules.

• There are no COLLECT rules by default, so all collected events are forwarded by the broker VM
to the Cortex XDR server.
• When COLLECT rules are defined, the designated broker VMs check every collected event
versus each rule. When there is a match for a given product or vendor, the broker VM checks if
it meets the filter criteria.
• If it meets the criteria, the event is passed to the Cortex 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 sll goes
through other rules on this broker.
-If no_hit=keep, the event is passed to the Cortex XDR server, and goes through other
rules on this broker.
• 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.
CONST
A CONST secon is used to define strings and numbers that can be re-used mulple mes
within XQL statements in other INGEST secons by using $constName. This can be helpful to
avoid wring the same value in mulple secons, similar to constants in modern programming
languages.
For example:
[CONST]
DEFAULT_DEVICE_NAME = "firewall3060"; // string
FILE_REGEX = "c:\\users\\[a-zA-Z0-9.]*"; // complex string
my_num = 3; /* int */
An example of using a CONST inside XQL statements in other INGEST secons using
$constName:
Data Management
The dollar sign ($) must be adjacent to the [CONST] name, without any whitespace in
between.
...
| filter device_name = $DEFAULT_DEVICE_NAME
| alter new_field = JSON_EXTRACT(field, $FILE_REGEX)
| filter age < $MAX_TIMEOUT
| join type=$DEFAULT_JOIN_TYPE conflict_strategy=
$DEFAULT_JOIN_CONFLICT_STRATEGY (dataset=my_lookup) as inn
url=inn.url
...
NOTICE: Only quoted or integer terminal values are considered valid for CONST secons. For
example, these will not compile:
[CONST]
WORD_CONST = abcde; //invalid
func_val = regex_extract(_raw_log, "regex"); // not possible
RECURSIVE_CONST = $WORD_CONST; // not terminal - not
possible
CONST secons 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 wring CONST secons.

• CONST names are not case sensive. They can be wrien 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 secon, and across all secons of the file. You cannot
have the same CONST name defined again in the same secon, or in any other CONST secons
in the file.
• Since secon order is unimportant, you do not have to declare a CONST before using it. You can
have the CONST secon wrien below other secons that use those CONST secons.
• A CONST is an add-on to the Parsing Rule syntax and is oponal to configure.
• CONST syntax is derived from XQL, but a few modificaons as explained in the Parsing Rules
syntax.
RULE
Rules are very similar to funcons in modern programming languages. They are essenally pieces
of XQL code, tagged with a name - alias, for easier code re-use and avoiding code duplicaons. A
RULE is an add-on to the Parsing Rule syntax and is oponal to configure.
RULE syntax is derived from XQL with a few modificaons as explained in the Parsing Rules
syntax.
Data Management
For more informaon on the XQL syntax, see Cortex XDR XQL Language Reference.
A few more points to keep in mind when wring RULE secons.

• Rules are defined by [rule:ruleName] as depicted in the following example.
[rule:filter_alerts]
• Rules are invoked by using a call keyword as depicted in the following example.
[rule:filter_alerts]
[rule:use_another_rule]
filter severity="LOW" | call filter_alerts | fields - raw_log;
This is equivalent to wring.
[rule:use_another_rule]
filter severity="LOW" | filter raw_log not contains "alert" |
fields - raw_log;
• Rule names are not case sensive. They can be wrien 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 enre file. This means you cannot have the same rule
name defined more than once in the same file.
• Since secon order is unimportant, you do not have to declare a rule before using it. You can
have the rule definion secon wrien below other secons that uses this rule.
• You can add a single tagor list of tags to the ingested data as part of the ingeson flow that you
can easily query in XQL Search. You can add tags using both the INGEST and RULE secons.
For example,

target_dataset="malware_test", no_hit= drop , ingestnull = true ]
[RULE:new_tag_rule]
tag add "test";

target_dataset="malware_test", no_hit= drop , ingestnull = true ]
[RULE:new_tag_rule]
Data Management
tag add "test1", "test2", "test3";
You can also add tags using only the INGEST secon. For more informaon, see
INGEST.
Error Reporng in Parsing Rules

Parsing Rules requires a Cortex XDR Pro per TB license.
To help you easily idenfy and resolve Parsing Rules errors, Cortex XDR includes error reporng in
Parsing Rules for these scenarios.
• Unable to compile a rule for different reasons including invalid funcon parameters, such as
invalid regex.
• Unable to apply a rule to the data.
• Mismatch between expected data type, such as CEF, LEEF, or JSON with the actual data, such
as TEXT or CSV.
All errors are saved to a dataset called parsing_rules_errors, where the dataset type is
system_audit. The following table describes the fields that are available when running a query
in XQL Search for this dataset in alphabecal order.
• Some errors can only be found aer the applicable logs are collected in Cortex XDR.
• New errors generate a noficaon called Parsing Rules Error, which you can view when
selecng the Noficaon center.
Field Descripon
CREATED_AT Displays a mestamp for when the rule, which

generated the error, was created.
END_LINE Displays the last line of the parcular parsing

error that you’re looking at.
ERROR_CATEGORY Displays the category of the error.
ERROR_MESSAGE Displays the error message.
_ID Displays the Rule ID that triggered this error.
INGEST_NULL Displays a boolean value of either TRUE or

FALSE to indicate whether null value fields are
configured to be ingested or not. By default,
null fields are ingested.
NO_HIT Displays the no-match strategy configured to

use for the rule group that the rule triggering
Data Management
Field Descripon
this error belongs to. Possible values are the
following.
• drop— In a scenario where none of the
rules in the group generates output for a
given log record, that record is discarded.
• keep—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.
_PRODUCT Displays the defined PRODUCT configured

for the rule that triggered this error.
START_LINE Displays the firs line of the parcular parsing

error that you’re looking at.
TARGET_DATASET Displays the Target dataset configured for the

rue that triggered this error.
_TIME Displays the mestamp when the error was

generated.
_VENDOR Displays the defined VENDOR configured for

the rule that triggered this error.
XQL_TEXT Displays the complete query for running the

rule in XQL Search that generated this error.
The Parsing Rules editor includes a separate secon called List of Errors at the boom page with
the following capabilies.
The List of Errors secon is only displayed when there are any errors to list.
• Lists the details of the last 20 errors from the total number of errors found.
Cortex XDR only updates this list with new errors when the list is closed.
• Selecng a parcular error highlights the relevant lines in the User Defined or Default
Rules views and displays these lines on the screen, so you can easily review the error and
troubleshoot the problem.
• Link to Open All in XQL Search to view addional informaon about these errors in XQL
Search from the last 24 hours. The enre list of errors in the parsing_rules_errors
Data Management
dataset are displayed, so you can easily troubleshoot. You can edit the query opened in XQL
Search to search for a designated me of your choosing, for example, if you want to view the
results for the last week as opposed to 24 hours.
• When you Save changes in the Parsing Rules editor, all of the errors listed are removed from
the page.
Parsing Rules Raw Dataset

Parsing Rules requires a Cortex XDR Pro per TB license.
Each vendor and product has its own raw dataset that uses the format
<vendor>_<product>_raw. For example, for Palo Alto Networks Next-Generaon 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 creang an INGEST secon referring to that dataset.
For example, the following syntax overrides the panw_ngfw_raw automac Parsing Rule.
[ingest:vendor=panw, product=ngfw, dataset=panw_ngfw_raw]

filter ... | alter ...;
Data Management
Manage Event Forwarding

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 locaon by exporng your logs to a bucket
from where you can download them for two weeks.
The Event Forwarding page enables you to acvate your Event Forwarding licenses and retrieve
the path and credenals of your external storage desnaon. This page is available when you
purchase the Event Forwarding add-on license.
Start forwarding event logs.
STEP 1 | Under Sengs > Configuraons > Data Management > Event Forwarding, acvate the
licenses in the Acvaon secon.
• Enable GB Event Forwarding to export parsed logs for XDR pro TB to an external SIEM
for storage. This enables you to keep data in your own storage in addion 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
configuraon opons.
• 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 configuraon opons. See the
breakdown of the Exported Event Types for the endpoints.
STEP 2 | Save your selecon.
STEP 3 | To retrieve the data, access GCP Cloud Storage through the Service Account.
The Desnaon secon displays the details of the Google Cloud Plaorm (GCP) bucket where
your data is stored for 14 days. The data is compressed and saved as a line-delimited JSON
gzip file.
1. Copy the path displayed.
2. Generate and download the Service Account JSON WEB TOKEN, which contains the
access key. The token provides access to all your data stored in this bucket on the service
account, and must be saved in a safe place.
If you need to regenerate your access token, Replace and download a new access token.
This acon invalidates your previous token.
3. Using the path and the access key, retrieve your files manually or using an API.
• Copying files and objects from GCP
• Authencang as a service account
Endpoints Event Forwarding - Exported Event Types

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 Management
data without filtering or configuraon opons. 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 acon_socket_type is_boot_replay
acon_remote_ip acon_proxy
acon_remote_port acon_network_app_ids
acon_local_ip acon_network_rule_ids
acon_local_port acon_network_dpi_fields
acon_network_connecon_id acon_network_is_loopback
acon_network_is_server acon_upload
acon_network_creaon_me acon_download
acon_total_upload acon_network_stats_seq
acon_total_download acon_network_is_ipv6
acon_network_protocol
acon_network_stats_is_last
Process uuid / _id acon_process_causality_id
acon_process_os_pid acon_process_is_causality_root
acon_process_instance_id acon_process_is_replay
acon_process_image_md5 acon_process_yara_file_scan_result
acon_process_image_sha256 acon_process_wf_verdict
acon_process_image_path acon_process_stac_analysis_score
acon_process_image_name execuon_actor_causality_id
acon_process_image_extensionacon_process_ns_pid
acon_process_image_command_line
acon_process_container_id
acon_process_signature_product
acon_process_is_container_root
acon_process_signature_vendoracon_process_image_command_line_indice
Data Management
acon_process_signature_is_embedded
acon_process_is_special
acon_process_signature_status acon_process_ns_user_sid
acon_process_integrity_level acon_process_ns_user_real_sid
acon_process_username acon_process_file_size
acon_process_user_sid acon_process_file_create_me
acon_process_in_txn acon_process_file_mod_me
acon_process_pe_load_info acon_process_remote_session_ip
acon_process_peb acon_process_file_info
acon_process_peb32 acon_process_device_info
acon_process_last_writer_actorexecuon_actor_instance_id
acon_process_token acon_process_user_real_sid
acon_process_privileges acon_process_requested_parent_pid
acon_process_fds acon_process_requested_parent_iid
acon_process_scheduled_task_name
acon_process_terminaon_date
acon_process_instance_execuon_me
acon_process_terminaon_code
File acon_file_path acon_file_wf_verdict
acon_file_name acon_file_yara_file_scan_result
acon_file_previous_file_path acon_file_dir_query
acon_file_previous_file_name acon_file_previous_device_info
acon_file_md5 acon_file_device_info
acon_file_sha256 acon_file_reparse_path
acon_file_size acon_file_reparse_count
acon_file_aributes acon_file_dirty_reason
Data Management
acon_file_create_me acon_file_remote_ip
acon_file_mod_me acon_file_remote_port
acon_file_access_me acon_file_remote_file_ip
acon_file_type acon_file_remote_file_host
acon_file_operaon_flags acon_file_sec_desc
acon_file_mode acon_file_previous_file_extension
acon_file_owner acon_file_extension
acon_file_owner_name acon_file_archive_list
acon_file_group acon_file_contents
acon_file_group_name
acon_file_device_type
acon_file_signature_product
acon_file_signature_vendor
acon_file_signature_is_embedded
acon_file_signature_status
acon_file_pe_info
acon_file_prev_type
acon_file_last_writer_actor
acon_file_is_anonymous
Registry acon_registry_value_type
acon_registry_key_name
acon_registry_data
acon_registry_value_name
acon_registry_old_key_name
acon_registry_file_path
Data Management
acon_registry_return_val
Injecon acon_remote_process_thread_idacon_remote_process_causality_id
acon_remote_process_os_pid acon_remote_process_is_causality_root
acon_remote_process_instance_id
acon_remote_process_is_replay
acon_remote_process_image_md5
acon_remote_process_image_extension
acon_remote_process_image_sha256
acon_remote_process_image_command_lin
acon_remote_process_image_path
acon_remote_process_is_special
acon_remote_process_image_name
acon_remote_process_file_size
acon_remote_process_image_command_line
acon_remote_process_file_create_me
acon_remote_process_signature_product
acon_remote_process_file_mod_me
acon_remote_process_signature_vendor
acon_remote_process_file_info
acon_remote_process_signature_is_embedded
acon_remote_process_signature_status
acon_remote_process_thread_start_address
acon_remote_process_integrity_level
acon_remote_process_username
acon_remote_process_user_sid
address_mapping
Load Image acon_module_path acon_module_is_replay
acon_module_md5 acon_module_yara_file_scan_result
acon_module_sha256 acon_module_file_size
acon_module_base_address acon_module_file_create_me
acon_module_image_size acon_module_file_mod_me
acon_module_signature_productacon_module_file_access_me
acon_module_signature_vendoracon_module_device_info
Data Management
acon_module_signature_is_embedded
acon_module_wf_verdict
acon_module_signature_status
acon_module_file_info
acon_module_last_writer_actor
acon_module_other_load_locaon
acon_module_page_protecon
acon_module_system_properes
acon_module_code_integrity
acon_module_boot_code_integrity
User Status Change acon_user_status
acon_username
acon_user_status_sid
acon_user_session_id
acon_user_is_local_session
Host Status Change acon_boot_me
acon_powered_off
Agent Status Change acon_boot_instance_cleanup_required
agent_status_component
Host Metadata Discovery/ host_metadata_interface_map

Change
host_metadata_hostname
host_metadata_domain
Common fields for all event Included field Excluded field

types
Agent agent_content_version agent_install_type
Data Management

types
agent_hostname event_utc_diff_minutes
agent_interface_map manifest_file_version
agent_os_sub_type source_message_id
agent_os_type zip_id
agent_version agent_request_me
agent_id server_request_me
agent_ip_addresses agent_id_hash
agent_ip_addresses_v6 agent_id_hash_bre
backtrace_idenes
_product
_vendor
actor_fields
agent_is_vdi
Common event_version event_is_impersonated
event_type event_is_replay
event_sub_type event_impersonaon_status
event_id event_is_simulated
event_mestamp event_user_presence
event_rpc_interface_uuid agent_host_boot_me
event_rpc_func_opnum agent_session_start_me
event_validity_enum
event_invalidity_field
event_rpc_inteface_version_major
event_rpc_inteface_version_minor
Data Management

types
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_lineactor_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_sha256actor_remote_host
os_actor_process_signature_status
actor_remote_pipe_name
os_actor_process_logon_id actor_remote_port
os_actor_process_os_pid actor_rpc_interface_version_major
os_actor_remote_ip actor_rpc_interface_version_minor
os_actor_process_instance_id actor_rpc_protocol
os_actor_thread_thread_id actor_type
actor_rpc_func_opnum
actor_rpc_interface_uuid
actor_process_device_info
actor_process_execuon_me
actor_process_file_create_me
actor_process_file_mod_me
Data Management

types
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_effecve_username
actor_effecve_user_sid
Data Management
Manage Compute Units Usage

Cortex XDR uses compute units (CU) for these types of XQL Queries.
• API Queries—When running XQL queries on your data sources using APIs, each XQL query API
consumes compute units based on the meframe, complexity, and the number of API response
results.
• Cold Storage Queries—Cold Storage is a data retenon offering for cheaper storage usually
for long-term compliance needs with limited search opons. You can perform queries on
Cold Storage data using the dataset format cold_dataset = <dataset name>, which
consumes compute units according to the following calculaons.
• 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.
Cortex XDR provides a free daily quota of compute units allocated according to your license size.
Queries called without enough quota will fail. To expand your invesgaon capabilies, you can
purchase addional compute units by enabling the Compute Unit add-on.
The Compute Unit add-on provides an addional 1 compute unit per day, in addion to your free
daily quota. For example, if you have allocated 5 free daily compute units, with the add-on you will
have a total of 6 daily compute units. The compute units are refreshed every 24 hours according
to UTC me. You can purchase a minimum of 50 compute units.
To gage how many compute units you require, Cortex XDR provides a 30-day free trial period
with a total of three mes your allocated compute units to run XQL API and Cold Storage queries.
You can then track the cost of each XQL API query and Cold Storage query responses and the
Compute Units Usage page. In addion, Cortex XDR sends a noficaon when the Compute Units
add-on has reached your daily threshold.
To enable the add-on, selectSengs ( ) > Configuraons > Cortex XDR License > Addons le,
and select the Compute Unit le and Enable.
To manage your compute units usage for your XQL API and Cold Storage queries.
STEP 1 | Select Sengs ( ) > Configuraons > Data Management > Compute Unite Usage.
STEP 2 | In the Daily Usage in Compute Units secon, 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 addional amount you have purchased. Time frame is calculated according to UTC
me.
For Managed Security tenants, the values calculated are the total daily usage of parent and
child tenants.
STEP 3 | In the Compute Units over last 30 Days secon, to track your quota usage over the past 30
days. The red line represents your daily license quota. For Managed Security tenants, make
Data Management
sure you select from the MSSP Tenant Selecon drop-down menu, the tenant for which you
want to display the informaon. To invesgate further.
• Hover over each bar to view the total number of query units used on each day for both
API Usage and Cold Storage Usage.
• Select a bar to display in the XQL Queries Using API table the list of XQL API and Cold
Storage queries executed on the selected day.
STEP 4 | In the Compute Units Usage table, invesgate all the XQL API and Cold Storage queries that
were executed on your tenant. For Managed Security tenants, make sure you select from
the MSSP Tenant Selecon drop-down menu, the tenant for which you want to display the
informaon. You can filter and sort according to the following fields.
• ID—Unique idenfier represenng the executed XQL API query.
• Timestamp—Date and me of when the XQL API was executed.
• Type—Indicates the type of query performed either an API Query or Cold Storage Query.
• PAPI Key ID—API Key ID used to execute the XQL API.
• XQL Query—The XQL query called using an API or Cold Storage search.
• Compute Unit Usage—Displays how many query units were used to execute the API query
and Cold Storage query.
• Tenant—Appears only in a Managed Security tenant. Displays which tenant executed an API
query or Cold Storage query.
STEP 5 | Invesgate 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 XQL Search page where you can view the query results.
Analycs
> Analycs Concepts
845
Analycs
Analycs Concepts
Safeguarding a network requires a defense-in-depth strategy which ulizes current and patched
soware and hardware. Most strategies designed to keep unwanted users out of a network stop
intrusion aempts at the network perimeter, defending only against known threats. For example,
systems scanning for malicious soware rely on previously idenfied MD5 signature databases.
However, aackers constantly modify virus signatures to circumvent virus scanners.
Your network defense-in-depth strategy must include soware and processes designed to detect
and respond to an intruder who penetrates your systems. The Cortex XDR app efficiently and
automacally idenfies abnormal acvity on your network, while providing you with the exact
informaon you need to rapidly evaluate, isolate and remove potenal threats from your network.
• Analycs Engine
• Analycs Sensors
• Coverage of MITRE Aack Taccs
• Analycs Detecon Time Intervals
• Analycs Alerts and Analycs BIOCs
• Identy Analycs
Analycs Engine
The Cortex XDR app uses its Analycs Engine to examine logs and data retrieved from your
sensors on the Cortex XDR tenants to build an acvity baseline, and recognize abnormal acvity
when it occurs. The Analycs Engine accesses your logs as they are streamed to the Cortex XDR
tenant, including any Firewall data that was forwarded by the Cortex Data Lake, and analyzes
the data as soon as it arrives. Cortex XDR raises an Analycs alert when the Analycs Engine
determines an anomaly.
The Analycs Engine examines traffic and data from a variety of sources such as network acvity
from firewall logs, VPN logs (from Prisma Access from the Panorama plugin), endpoint acvity
data (on Windows endpoints), Acve Directory or a combinaon of these sources, to idenfy the
endpoints and users on your network. Aer idenfying the endpoints and the users, the Analycs
Engine collects relevant details about each asset based on the informaon it obtains from the logs
to create profiles. The Analycs Engine can detect threats from only network data or only endpoint
data, but for more context when invesgang an alert, using a combinaon of data sources is
recommended.
The Analycs Engine creates and maintains the profiles to view the acvity 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 stascal analysis of an enty or an enty relaon that compares
acvies from mulple enes in a peer group. For example, a domain can have a cross-
organizaon popularity profile or per peer group popularity profile.
• Temporal Profiles—A stascal analysis of an enty or an enty relaon that compares the
same enty to itself over me. For example, a host can have a Profile depending on the number
of ports it accessed in the past.
Analycs
• Enty classificaon—A model detecng the role of an enty. For example, users can be
classified as service accounts, and hosts as domain controllers.
Analycs Sensors
To detect anomalous behavior, Cortex XDR can analyze logs and data from a variety of sensors.
Sensor Descripon
Palo Alto Networks sensors
Firewall traffic logs Palo Alto Networks Firewalls perform tradional

and next-generaon firewall acvies. The
Cortex XDR Analycs 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 Analycs alerts with external
dynamic lists.
Enhanced applicaon logs (EAL) To provide greater coverage and accuracy, you
can enable enhanced applicaon logging on
your Palo Alto Networks firewalls. EAL are
collected by the firewall to increase visibility into
network acvity for Palo Alto Networks apps and
services, like Cortex XDR . Only firewalls sending
logs to Cortex Data Lake can generate enhanced
applicaon logs.
Examples of the types of data that enhanced
applicaon logs gather include records of DNS
queries, the HTTP header User Agent field that
specifies the web browser or tool used to access
a URL, and informaon about DHCP automac
IP address assignment. With DHCP informaon,
for example, Cortex XDR can alert on unusual
acvity based on hostname instead of IP address.
This enables the security analyst using Cortex
XDR to meaningfully assess whether the user’s
acvity is within the scope of his or her role, and
if not, to more quickly take acon to stop the
acvity.
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 also analyze VPN
traffic to detect anomalous behavior on mobile
endpoints.
Analycs
Sensor Descripon
Firewall URL logs (part of firewall threat Palo Alto Networks firewalls can log Threat
logs) log entries when traffic matches one of the
Security Profiles aached to a security rule on
the firewall. Cortex XDR can analyze entries for
Threat logs relang to URLs and raise alerts that
indicate malicious behavior such as command
and control and exfiltraon.
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 soware
exploits. The Analycs Engine can also analyze
the EDR data collected by the Cortex XDR agent
to raise alerts. To collect EDR data, you must
install Cortex XDR agent 6.0 or a later release
on your Windows endpoints (Windows 7 SP1 or
later).
The Cortex XDR Analycs Engine can analyze
acvity and traffic based solely on endpoint
acvity data sent from Cortex XDR agents. For
increased coverage and greater insight during
invesgaons, use a combinaon of Cortex XDR
agent data and firewalls to supply acvity 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 of Pathfinder to monitor endpoints.
Pathfinder scans unmanaged hosts, servers,
and workstaons for malicious acvity. The
Analycs Engine can also analyze the Pathfinder
data collector in combinaon with other data
sources to increase coverage of your network
and endpoints, and to provide more context
when invesgang alerts.
Directory Sync logs If you use the Cloud Identy Engine to provide
Cortex XDR with Acve Directory data, the
Analycs Engine can also raise alerts on your
Acve Directory logs.
External sensors
Third-party firewall logs If you use non-Palo Alto Networks firewalls—

Check Point, Fornet, Cisco ASA—or in addion
to or instead of Palo Alto Networks firewalls,
you can set up a syslog collector to facilitate
log and alert ingeson. By sending your firewall
Analycs
Sensor Descripon
logs to Cortex XDR , you can increase detecon
coverage and take advantage of Cortex XDR
analysis capabilies. When Cortex XDR analyzes
your firewall logs and detects anomalous
behavior, it raises an alert.
Third-party authencaon service logs If you use an authencaon service—Microso

Azure AD, Okta, or PingOne—you can set up log
collecon to ingest authencaon logs and data
into authencaon stories.
Windows Event Collector logs The Windows Event Collector (WEC) runs on the
broker VM collecng event logs from Domain
Controllers (DCs). The Analycs Engine can
analyze these event logs to raise alerts such as
for credenal access and defense evasion.
Coverage of MITRE Aack Taccs

Network aacks follow predictable paerns. If you interfere with any poron of this paern, the
aack is neutralized.
The Analycs Engine can alert on any of the following aack taccs as defined by the MITRE
ATT&CK™ knowledge base of taccs.
Tacc Descripon
Execuon Aer aackers gain a foothold in your

network, they can use various techniques to
execute malicious code on a local or remote
endpoint.
TheCortex XDR app detects malware
and grayware on your network using a
combinaon of network acvity, Pathfinder
data collector of your unmanaged endpoints,
Analycs
endpoint data from your Cortex XDR agents,
and evaluaon of suspicious files using the
WildFire® cloud service.
Persistence To carry out a malicious acon, an aacker

can try techniques that maintain access in
a network or on an endpoint. An aacker
can iniate configuraon 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 aacker to
regain access on the endpoint.
Discovery Aer an aacker has access to a part of your

network, they use discovery techniques to
explore and idenfy subnets, servers and
services that are hosted on those endpoints.
The idea is to idenfy vulnerabilies within
your network.
The app detects aacks that use this
tacc by looking for symptoms in your
internal network traffic such as changes in
connecvity paerns, including increased
rates of connecons, failed connecons, and
port scans.
Lateral Movement To expand the footprint inside your network,

and aacker uses lateral movement
techniques to obtain credenals to gain
addional access to more data in the network.
The Analycs Engine detects aacks during
this phase by examining administrave
operaons (such as SSH, RDP, and HTTP),
file share access, and user credenal usage
that is beyond the norm for your network.
Some of the symptoms the app looks for are
increased administrave acvity, SMB usage,
and remote code execuon.
Command and Control The command and control tacc allows an

aacker to remotely issue commands to an
endpoint and receive informaon from it.
The Analycs Engine idenfies intruders
using this tacc by looking for anomalies in
outbound connecons, DNS lookups, and
endpoint processes with bound ports. The
app is looking for unexplained changes in the
Analycs
periodicity of connecons and failed DNS
lookups, changes in random DNS lookups, and
other symptoms that suggest an aacker has
gained inial control of a system.
Exfiltraon Exfiltraon taccs are techniques to receive

data from a network, such as valuable
enterprise data. The app seeks to idenfy it
by examining outbound connecons with a
focus on the volume of data being transferred.
Increases in this volume are an important
symptom of data exfiltraon.
Analycs Detecon Time Intervals

The Cortex XDR Analycs Engine retrieves logs from Cortex XDR tenant to create a baseline so
that it can raise alerts when abnormal acvity occurs. This analysis is highly sophiscated and
performed on more than a thousand dimensions of data. Internally, the Cortex XDR app organizes
its analycs acvity into algorithms called detectors. Each detector is responsible for raising an
alert when worrisome behavior is detected.
To raise alerts, each detector compares the recent past behavior to the expected baseline by
examining the data found in your logs. A certain amount of log file me is required to establish a
baseline and then a certain amount of recent log file me is required to idenfy what is currently
happening in your environment.
There are several meaningful me intervals for Cortex XDR Analycs detectors:
Time Interval Descripon
Acvaon Period The shortest amount of log file me before

the app can raise an alert. This is typically the
me from when a detector first starts running
and when you see an alert but, in some cases,
detectors pause aer an upgrade as they
enter a new acvaon period.
Most but not all detectors start running aer
the acvaon period ends. The acvaon
period provides the detector enough data to
establish a baseline, which in turn helps to
avoid false posives.
The acvaon period is also referred to as the
profiling or waing period and, informally, it is
also referred to as soak me.
Analycs
Time Interval Descripon
Test Period The amount of logging me that a detector

uses to determine if unusual acvity is
occurring on your network. The detector
compares test period data to the baseline
created during the training period, and
uses that comparison to idenfy abnormal
behavior.
Training Period The amount of logging me that the detector

requires to establish a baseline, and to idenfy
the behavioral limits beyond which an alert
is raised. Because your network is not stac
in terms of its topology or usage, detectors
are constantly updang the baselines that
they require for their analycs. For this update
process, the training period is how far back in
me 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 acvity 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
stascal analysis of malicious
acvity recorded worldwide. The
engineers rounely perform this
stascal analysis and update the
predetermined limits as needed
with each release of Cortex XDR.
Deduplicaon Period The amount of me in which addional

alerts for the same acvity or behavior are
suppressed beforeCortex XDR raises another
Analycs alert.
These me periods are different for every Cortex XDR Analycs detector. The actual amount of
logging data (measured in me) required to raise any given Cortex XDR Analycs alert is idenfied
in the Cortex XDR Analycs Alert Reference.
Analycs
Analycs Alerts and Analycs BIOCs

The Cortex XDR analycs engine raises an alert when it detects suspicious acvity, composed up
of mulple events, that deviates from the behavior baseline it establishes over me. To ensure
the analycs detectors raise alerts efficiently and do not overcrowd your Alerts table, Cortex XDR
automacally disables alerts from detectors that reach 5000 or more hits over a 24 hour period.
In addion to standard Analycs alerts, there is another category of alerts for Analycs behavioral
indicators of compromise (BIOC)s. In contrast to standard Analycs alerts, Analycs BIOCs (ABIOCs)
—indicate a single event of suspicious behavior with an idenfied chain of causality. To idenfy the
context and chain of causality, ABIOCs leverage user, endpoint, and network profiles. The profile
is generated by the Analycs Engine and can be based on a simple stascal profile or a more
complex machine-learning profile. Cortex XDR tailors each ABIOC to your specific environment
aer analyzing your logs and data sources and connually tunes and delivers new ABIOCs with
content updates.
Identy Analycs
Cortex XDR enables you invesgate suspicious user acvity informaon using Identy Analycs.
When enabled, Identy Analycs aggregates and displays user profile informaon, acvity, and
alerts associated with a user-based Analycs type alert and Analycs BIOC rule.
To easily track the alerts and Analycs BIOC rules, Cortex XDR displays an Identy Analycs
tag in the Alerts table > Alert Name field and Analycs BIOC Rules table > Name field. In the
Analycs Alert View, when selecng the User node,Cortex XDR details the acve directory group,
organizaonal unit, role, logins, hosts, alerts, and process execuons associated with the user.
To enable the Identy Analycs, you must first:
• Set Up Cloud Identy Engine (Formally Directory Sync Services (DSS))
• Acvate Cortex XDR Analycs
Aer configuring your Cloud Identy Engine instance and Cortex XDR Analycs, select Sengs
( ) > Configuraons > Cortex XDR - Analycs and in the Featured in Analycs secon, Enable
Identy Analycs.
Analycs
Asset Management
> Network Configuraon
> Vulnerability Assessment
> Manage User Scores
> Asset Inventory
> Cloud Inventory Assets
855
Asset Management
Network Configuraon
Network asset visibility is a crucial invesgave tool in discovering rogue devices in your network
and prevenng malicious acvity. Understanding how many managed and unmanaged assets are
part of your network provides you with vital informaon to beer assess your security exposure
and track network communicaon.
Cortex XDR Network Configuraon provides an accurate representaon of your network assets
by collecng 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
In addion to the network resources, Cortex XDR allows you to configure in your Windows Agent
Profile a Cortex XDR agent scan of your endpoints using Ping that provides updated idenfiers of
your network assets, such as IP addresses and OS plaorms. The scan is automacally distributed
by Cortex XDR to all the agents configured in the profile and cannot be iniated by request.
With the data aggregated by Cortex XDR Network Configuraon you can locate and manage your
assets more effecvely and reduce the amount of research required to.
• Disnguish between assets managed and unmanaged by a Cortex XDR Agent.
• Idenfy assets that are part of your internal network.
• Track network data communicaons from within and outside your network.
Configure Your Network Parameters

To track and idenfy assets in your network, you need to define your internal IP address ranges
and domain names to enable Cortex XDR to analyze, locate, and display assets.
Define IP Address Ranges

STEP 1 | In Cortex XDR, select Assets > Network Configuraon > IP Address Ranges.
Asset Management
STEP 2 | Define an IP Address Range.

By default, Cortex XDR creates Private Network ranges that specify reserved industry
approved ranges. Private Network ranges are marked with a icon and can only have the
name edited.
To Add New Range select either:
• Create New
• In the Create IP Address Rage pop-up, enter the IP address Name and IP Address Range
or CIDR values.
You can add a range which is fully contained in an exisng range, however you
cannot add a new range which parally intersect with another range.
The range names you define will appear when invesgang the network related events
within the Cortex XDR console.
• Save your definions.
• Upload from File
• In the Upload IP Address Ranges pop-up, drag and drop or search for a CSV file lisng
the IP address ranges. Download example file to view the correct format.
• Add your list of IP address ranges.
STEP 3 | Review your IP address ranges.

Aer you named and defined your IP address ranges, review the following informaon:
The IP Address Ranges table displays the following fields:
• Range Name—Name of the IP address range you define.
• First IP Address—First IP address value of the defined range.
• Last IP Address—Last IP address value of the defined range.
• Acve Assets—Number of assets located within the defined range that are have reported
Cortex XDR Agent logs or appeared in your Network Firewall Logs.
• Acve Manged Assets—Number of assets located within the defined range that are
reported Cortex XDR Agent logs.
• Modified By—User name of user who last changed the range.
• Modificaon Time—Timestamp of when this range was last changed.
STEP 4 | Manage your IP address ranges.

In the IP Address Ranges table, locate your range and select:
• Edit range—Edit the IP address configuraons. Changes made will effect the Broker VM
Network Mapper.
• Delete range—Delete the IP address range.
Define Domain Names

STEP 1 | In Cortex XDR, select Assets > Network Configuraon > Internal Domain Suffixes.
Asset Management
STEP 2 | In the Internal Domain Suffixes secon, +Add the domain suffix you want to include as part
of your internal network. For example, acme.com.
STEP 3 | Select to add to the Domains List.
Asset Management
Vulnerability Assessment
Cortex XDR vulnerability assessment enables you to idenfy and quanfy the security
vulnerabilies on an endpoint in Cortex XDR. Relying on the informaon from Cortex XDR, you
can easily migate and patch these vulnerabilies on all endpoints in your organizaon.
To provide you with a comprehensive understanding of the vulnerability severity, Cortex XDR
retrieves the latest data for each CVE from the NIST Naonal Vulnerability Database, including
CVE severity and metrics. You can use Cortex XDRto evaluate the extent and severity of each
CVE in your network, gain full visibility in to the risks to which each endpoint is exposed, and
assess the vulnerability status of an installed applicaon in your network.
You can access the Vulnerability Assessment panel from: Assets > Vulnerability Assessment.
Collecng the inial data from all endpoints in your network could take up to 6 hours. Aer that,
Cortex XDR iniates periodical recalculaons to rescan the endpoints and retrieve the updated
data. If at any point you want to force data recalculaon, click Recalculate.
The following are prerequisites for Cortex XDR to perform vulnerability assessment of your
endpoints:

Supported Plaorms • Windows—

• Cortex XDR lists only CVEs relang to the operang
system, and not CVEs relang to applicaons
provided by other vendors.
• Cortex XDRretrieves the latest data for each CVE
from the NIST Naonal Vulnerability Database as
well as from the Microso Security Response Center
(MSRC).
• 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
Microso no longer fixes CVEs.
• Linux—Cortex XDR agent 7.1 or a later release.
• Mac—For macOS versions prior to 10.5, Cortex
XDR collects only the applicaons list without CVE
calculaon. Newer macOS versions are currently not
supported.
Asset Management
Setup and Permissions • Ensure Host Inventory Data Collecon is enabled for
Limitaons Cortex XDR calculates CVEs for applicaons according to

the applicaon version, and not according to applicaon
build numbers.
CVE Analysis
To evaluate the extent and severity of each CVE across your endpoints, you can drill down in to
each CVE in Cortex XDR and view all the endpoints and applicaons in your environment that are
impacted by the CVE. Cortex XDR retrieves the latest informaon from the NIST public database.
From Add-ons > Host Insights > Vulnerability Assessment, select CVEs on the upper-right bar. For
each vulnerability, Cortex XDR displays the following default and oponal values:
Value Descripon
Affected endpoints The number of endpoints that are currently

affected by this CVE. For excluded CVEs, the
affected endpoints are N/A.
Applicaons The names of the applicaons 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.
Descripon The general NIST descripon of the CVE.
Excluded Indicates whether this CVE is excluded from

all endpoint and applicaon views and filters,
and from all Host Insights widgets.
Plaorms The name and version of the operang system

affected by this CVE.

database.

Asset Management
Value Descripon
descripon.
You can perform the following acons from Cortex XDR as you analyze the exisng vulnerabilies:
• View CVE details—Le-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 applicaons in your network that are impacted by a CVE—Right-click
the CVE and then select View applicaons.
• Exclude irrelevant CVEs from your endpoints and applicaons 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 invesgaon by Palo Alto Networks. The CVE is grayed out and labeled
Excluded and no longer appears on the Endpoints and Applicaons 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 me.
The CVE will be removed/reinstated to all views, filters, and widgets aer the next
vulnerabilies recalculaon.
Endpoint Analysis
To help you assess the vulnerability status of an endpoint, Cortex XDR provides a full list of
all installed applicaons and exisng CVEs per endpoint and also assigns each endpoint a
vulnerability severity score that reflects the highest NIST vulnerability score detected on the
endpoint. This informaon helps you to determine the best course of acon for remediang each
endpoint. From Add-ons > Host Insights > Vulnerability Assessment, select Endpoints on the
upper-right bar. For each endpoint, Cortex XDR displays the following default and oponal values:
Value Descripon
CVEs A list of all CVEs that exist on applicaons

that are installed on 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.
Asset Management
Value Descripon
Last Reported Timestamp The date and me of the last me the Cortex
XDR agent started the process of reporng its
applicaon inventory to Cortex XDR.
MAC address The MAC address associated with the

endpoint.
IP address The IP address associated with the endpoint.
Plaorm The name of the plaorm running on the

endpoint.

database.

descripon.
You can perform the following acons from Cortex XDR as you invesgate and remediate your
endpoints:
• View endpoint details—Le-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 applicaons installed on an endpoint—Right-click the endpoint and
then select View installed applicaons. This list includes the applicaon name, version, and
installaon path on the endpoint. If an installed applicaon has known vulnerabilies, 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 remediaon 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 Microso Windows
patches that were installed on the endpoint and a link to the Microso official Knowledge Base
(KB) support arcle.
• Retrieve an updated list of applicaons installed on an endpoint—Right-click the endpoint and
then select Rescan endpoint.
Applicaon Analysis
You can assess the vulnerability status of applicaons in your network using the Host inventory.
Cortex XDR compiles an applicaon inventory of all the applicaons installed in your network
by collecng from each Cortex XDR agent the list of installed applicaons. For each applicaon
on the list, you can see the exisng CVEs and the vulnerability severity score that reflects the
highest NIST vulnerability score detected for the applicaon. Any new applicaon installed on the
Asset Management
endpoint will appear in Cortex XDR with 24 hours. Alternavely, you can re-scan the endpoint to
retrieve the most updated list.
Starng with macOS 10.15, Mac built-in system applicaons are not reported by the
Cortex XDR agent and are not part of the Cortex XDR Applicaon Inventory.
From Add-ons > Host Insights > Host Inventory, select Applicaons.
• To view the details of all the endpoints in your network on which an applicaon is installed,
right-click the applicaon and select View endpoints.
• To view in-depth details about the applicaon, le-click the applicaon name.
Asset Management
Manage User Scores

The User Scores page provides a central locaon from which you can view and invesgate
informaon relang to the user scores in your network.
Using Identy Analycs, Cortex XDR is able to aggregate from Workday and Acve Directory a
list of all the user assets located within your network according to their associated incidents. To
help invesgate user acvies and detect compromised accounts and malicious acvies, Cortex
XDR calculates a User Score that allows you to easily idenfy the most high-risk users in your
organizaon.
The User Score is the higher score of the following two components:
• Incident Scoring Rules—Alerts within an incident matching your scoring rules criteria are each
given a score. The alert with the highest score from the incident is assigned as the User Score.
• System Rules—Alerts within an incident matching Cortex XDR generated scoring rules are each
given a score. Cortex XDR sums all the alerts for each incident up to a total of 100. The highest
score is assigned as the User Score.
As new alerts are associated with incidents, the User Score assigned is recalculated.
Navigate to the User Scores table to view the latest score, and the User View to track the
User Score trend.
To invesgate your users, Cortex XDR displays the following informaon.

STEP 1 | Select User Scores.
Asset Management
STEP 2 | Filter and review your assets.

The following table describes the fields in the table.
Field Descripon
SCORE Represents the Cortex XDR high-risk user

score. The score is updated connuously as
new alerts are associated with incidents.
USER NAME Name of the user as provided by Cortex XDR.
FULL NAME Name of user as provided by Workday or

Acve Directory.
DEPARTMENT Department of user as provided by Workday

or Acve Directory.
PHONE NUMBER Phone number of user as provided by

Workday or Acve Directory.
EMAIL Email of user as provided by Workday or

Acve Directory.
LOCATION Locaon of user as provided by Workday or

Acve Directory.
LAST LOGIN Last date and me the user accessed Cortex
XDR.
STEP 3 | Invesgate further by locang the user you want to invesgate, right-click and Open User
View.
Some User Associated Insights may not appear as part of the User Associated
Incidents due to the insight generaon mechanism. For example, when an insight
related to one of the assets in an incident is generated a few days aer the associated
incident, the insight may not be associated with the incident.
Asset Management
Asset Inventory
Cortex XDR provides a central locaon from which you can view and invesgate informaon
relang to assets in your network. Using your defined internal network configuraons, 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.
• When any row in the table is selected, a side panel on the right with greater details is displayed,
where you can view addional data divided by secons. The secon 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 respecve asset views to a tab-separated values (TSV) file.
You can toggle between the following views on the page.
• Legacy View—Displays a list of all the assets located within your network according to their IP
address. The task below provides more informaon on invesgang your asset inventory using
the Legacy View.
The Legacy View will be deprecated in the upcoming Cortex XDR release.
• 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 capabilies 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 addional data divided by secons. The secon heading
names and data displayed change depending on the source of the assets.
To easily invesgate your asset inventory using the Legacy View.
STEP 1 | Select Assets > Asset Inventory.
STEP 2 | In the Page layout noficaon, toggle to the Legacy view.
Asset Management
STEP 3 | 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 oponal fields in the table, and the network
prerequisites required by Cortex XDR to retrieve the data.
Field Descripon Prerequisites
AGENT ID ID of the agent installed on

the asset. Cortex XDR only
displays agents that send EDR
data captured in the firewall
logs.
AGENT INSTALLED Whether or not the asset has

an agent installed.
AGENT VERSION Version 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.
FIRST TIME SEEN Timestamp of when the IP

address was first seen in the
logs.
HOST NAME Host name of the asset, if The asset requires at least
available. 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
IP ADDRESS IP address related to the last

asset associated with it.
Asset Management
LAST TIME SEEN Timestamp of when the IP

address was last seen in the
logs.
MAC ADDRESS Mac address of the asset. The asset requires at least
agent
collector
• For Mac endpoints, a
Global Protect client 9.1 or
a later release, configured
to send HIP Match logs
to Cortex XDR
MAC ADDRESS VENDOR Vendor name of the Mac The asset requires at least
address of the asset. one of the following:
agent
collector
• For Mac endpoints, a
Global Protect client 9.1 or
a later release, configured
to send HIP Match logs
to Cortex XDR
PLATFORM Plaorm running on the asset. The asset requires at least

agent
collector
• A Global Protect client
9.1 or a later release,
configured to send HIP
Match logs
Asset Management
RANGE NAMES Name of the IP address range

allocated to the IP address.
You can export your filtered results to a TSV file.
STEP 4 | Invesgate an asset.

Locate an IP address, right-click and select to:
• Open asset view—Pivot to the Asset View to view insights collected from an endpoint with
an agent installed.
Open IP View—Pivot to the IP Address View to view details of the associated IP address
from an endpoint without an agent installed.
The default filter in the table shows only non-agent assets.
• View agent details—Pivot to the Endpoints table filtered according to the agent ID. Choose
whether to open the view in a new tab or the same tab. This opon is available only for
assets with a Cortex XDR agent installed.
• Open in Quick Launcher—Open the Quick Launcher search results for the IP address.
• Remove Collector—Remove the Pathfinder Data Collector. Only available if a collector is
status is In Process.
All Assets
Ingesng and Viewing Cloud Compute Instances for Cloud Inventory Assets requires a
Cortex XDR Pro per TB license.
The All Assets page enable you to view all your assets from various assets 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 Automacally available Any license
Cloud Compute Instance Requires configuring either Cortex XDR Pro TB license
a Cloud Inventory data
collector or Cortex Agents
that are installed on the
Cloud Compute Instances.
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
Asset Management
tables and respecve asset views to a tab-separated values (TSV) file. From the All Assets page,
you can also manage the assets 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 enre list of assets.
When any row in the table is selected, a side panel on the right with greater details is displayed,
The following table describes the fields that are available when viewing All Assets in alphabecal
order.
exposed by default.
Field Descripon
CLOUD PROVIDER* The cloud provider used to collect these cloud

assets as either GCP, AWS, or Azure.
This field only displays with a

Cortex XDR Pro TB license.
CLOUD ID* Displays the Resource ID as provided from the

cloud provider.

FIRST OBSERVED* When the asset was first observed via any of
the sources.
HAS XDR AGENT* Boolean value indicang 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.
Asset Management
Field Descripon
NAME* Displays the name that describes the asset as

provided by the source, if provided.
OPERATING SYSTEM* The operang system reported by the source

for this asset.
REGION* Displays the region as provided by the Cloud

provider.

SOURCES* An array column that displays all the sources

that provided observaons for this asset.
TYPE* Type of asset, which can be defined as one of

the following.
The opons available are

dependent on your Cortex XDR
license.
• Cloud Compute Instance

• On-Prem
• Unassociated Responsive IPs
This field is unique to the All Assets table.
XDR AGENT ID If there is an endpoint installed on this asset,

this is the endpoint ID.
Specific Assets
Ingesng and Viewing Cloud Compute Instances for Cloud Inventory Assets requires a
Cortex XDR Pro per TB license.
The Specific Assets pages enable you to view specific assets from a designated assets category.
Each specific table contains the common columns that are listed in the All Assets table and some
addional specific columns that are relevant for the type of asset.
To view the Specific Assets pages, select Assets > Asset Inventory > Specific Assets, and select a
specific asset category.
By default, the Specific Assets pages displays the assets according to the name of the asset. To
search for specific assets, use the filters above the results table to narrow the results. You can
export the tables and respecve asset views to a tab-separated values (TSV) file. From the Specific
Assets page, you can also manage the assets output using the right-click pivot menu.
Asset Management
The table below describes the following for the different Specific Assets pages.
The Specific Assets listed are dependent on your Cortex XDR license. For more
informaon, see All Assets.
• Specific Assets—The name of the specific asset page.

• Descripon—A brief descripon of the assets included in the specific asset page.
• Unique Fields—The unique fields that are only available when viewing this specific asset page,
and are displayed in addion to the common fields listed for All Assets page. These fields are
exposed by default.
Specific Assets Descripon Unique Fields
Cloud Compute Instance Include assets that are No specific unique fields
managed by Cortex Agents, displayed in addion to the
where the agent reported common fields.
that the assets are in a cloud
environment. In addion, the
assets can be Cloud Compute
Instances that were reported
by a Cloud integraon
(i.e. Cloud Inventory data
collector) with or without a
Cortex agent.
Cortex XDR aempts to
associate the data received
from the Cortex agent and
the data received from the
Cloud Integraon and e
them together into a single
asset.
On-Prem Includes devices that have The following aributes are

a Cortex Agent and also relevant for IoT devices and
devices that were idenfied indicate the category and
by various sources yet were subcategory to which an IoT
not associated with a Cortex device belongs. For example,
Agent, such as IoT devices. the category may idenfy
network behaviors common
Does not include devices that
to all security cameras.
are in the cloud.
Respecvely, the model
idenfies the model of the IoT
device.
• DEVICE MODEL
Asset Management
Specific Assets Descripon Unique Fields

• DEVICE CATEGORY
• DEVICE SUBCATEGORY
Asset Management
Cloud Inventory Assets

Ingesng and Viewing Cloud Inventory Assets requires a Cortex XDR Pro per TB license.
Cortex XDR provides a unified, normalized asset inventory for cloud assets in Google Cloud
Plaorm, Microso Azure, and Amazon Web Services. This capability provides deeper visibility
to all the assets and superior context for incident invesgaon. 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 All
Cloud Assets and Specific Cloud Assets pages display the data in a table format.
The following are some of the main features available to you on these pages.
• When any row in the table is selected, a side panel on the right with greater details is displayed,
where you can view addional data divided by secons. The following are some descripons of
the main secons.
• Internet Exposure—When there are any open external ports, these ports and their
corresponding details are displayed, so you can quickly idenfy 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 idenes of the latest 5 editors lisng the percentage of eding
acons for a single identy. A link is provided to open a predefined query in XQL Search on
the cloud_audit_log dataset to view the edit operaons by the identy selected for this
asset in the last 7 days.
• Asset Metadata—Details the asset metadata collected for the parcular row selected in the
table.
For more informaon on these secons in the side panel, see Manage Your Cloud Inventory
Assets.
All Cloud Assets

The All Cloud Assets page enable you to view all your cloud assets from the various cloud assets
categories that you configured for collecon from Google Cloud Plaorm, Microso 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 me
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 respecve asset views to a tab-separated values
Asset Management
(TSV) file. From the All Cloud Assets page, you can also manage the assets output using the right-
click pivot menu. For more informaon, see Manage Your Cloud Inventory Assets.
The All Cloud Assets table is comprised of a number of common fields that are available when
viewing any of the Specific Cloud Assets pages. The TYPE and SUBTYPE fields are only available
in the All Cloud Assets table as these fields determine the Specific Cloud Assets categories, and
can be used to filters the different types of assets from the enre list of assets.
where you can view addional data divided by secons, such as Asset Metadata and Asset
Editors. The Asset Editors secon also provides a link to open a predefined query in XQL Search
on the cloud_audit_log dataset to view the edit operaons by the identy selected for this
The following table describes the fields that are available when viewing All Cloud Assets in
exposed by default.
Field Descripon
AVAILABILITY ZONE* Displays the AVAILABILITY ZONE according

to the cloud provider.
CLOUD TAGS* Displays any cloud tags or labels configured

according to the cloud provider.
CREATION TIME* Displays the me that the cloud asset was
1
created. This informaon is not always
available.
EXTERNAL IPS* Displays list of external public IPs.
GEO REGION* Displays the normalized value indicang the

geographic region, such as North America or
Middle East.
HEIRARCHY* 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 informaon, see the
PROJECT descripon.
INTEGRATION KEY Internal Cortex XDR idenficaon of the

integraon collecon.
Asset Management
Field Descripon
INTERNAL IPS* Displays list of internal private IPs.
INTERNET EXPOSURE (PORTS)* Displays a list of ports, where the details

regarding these ports are available to view in
the side panel.
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
• Microso Azure—Subscripon
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 descripon.
PROVIDER* The cloud provider used to collect these cloud

assets as either GCP, AWS, or Azure.
RAW ASSET Internal Cortex XDR debug informaon that

displays the raw data used to parse the data.
REGION* Displays the region as provided by the Cloud

provider.
RESOURCE GROUP Displays the RESOURCE GROUP when using

a Azure PROVIDER.
RESOURCE ID Displays the RESOURCE ID as provided from

the cloud provider.
SECONDARY ASSET ID Displays a SECONDARY ASSET ID provided

by the cloud provider that is used in Cortex
XDR to idenfy the asset if a NAME is not
provided.
Asset Management
Field Descripon
SUBTYPE* 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 Funcon
• Storage
• Other
This field is unique to the All Cloud Assets
table.
UPDATE TIME* Displays the me that the cloud asset was
updated. This informaon is not always
available.
1
Due to a known AWS synchronizaon issue, where the creaon me displayed in the AWS
Console does not match the actual me 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 me.
Specific Cloud Assets

Ingesng and Viewing Cloud Inventory Assets requires a XDR Pro per TB license.
The Specific Cloud Assets pages enable you to view specific cloud assets from a designated
cloud assets category from all the assets you configured to collect from Google Cloud Plaorm,
Microso Azure, and Amazon Web Services using the Cloud Inventory data collector. These asset
Asset Management
cloud categories are based on a combinaon of asset types and subtypes. Each specific table
contains the common columns that are listed in the All Cloud Assets table and some addional
specific columns that are relevant for this type of cloud asset.
To view the Specific Cloud Assets pages, select Assets > Cloud Inventory > Specific Cloud Assets,
and select a specific cloud asset category.
By default, the Specific Cloud Assets pages displays the cloud assets according to the most recent
me 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 respecve asset views to a tab-separated
values (TSV) file. From the Specific Cloud Assets page, you can also manage the assets output
using the right-click pivot menu. For more informaon, see Manage Your Cloud Inventory Assets.
where you can view addional data divided by secons, such as Asset Metadata and Asset
Editors. The Asset Editors secon also provides a link to open a predefined query in XQL Search
on the cloud_audit_log dataset to view the edit operaons by the identy selected for this
The image below is an example of a Specific Cloud Assets page for Compute Instances.
The table below describes for the different Specific Cloud Assets pages the following.
• Specific Cloud Assets—The name of the specific cloud asset page.
• Asset Type—The asset type that is automacally associated to this specific cloud asset page.
• Asset Subtype—The asset subtype that is automacally associated to 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 addion to the common fields listed for 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 me 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
Asset Management

whether the disk is
encrypted.
Storage Buckets Storage Bucket • BUCKET

ACCESS—Displays
the bucket access
opons as one of
the following.
• Public
• Private
• Fine Grained
• Unknown
• BUCKET
LOCATION—
Displays the
bucket locaon as
either Regional or
Mul Regional.
Virtual Private Compute VPC DEFAULT VPC—

Clouds (VPCs) Displays a boolean
value as either Yes
or No to indicate
whether this asset is
the default VPC.
Subnets Compute Subnet No specific unique

fields displayed
in addion to the
common fields.
Security Groups (FW Compute Security Group No specific unique

Rules) fields displayed
in addion to the
common fields.
Images Compute Image No specific unique

fields displayed
in addion to the
common fields.
Network Interfaces Compute Network Interfaces No specific unique

fields displayed
in addion to the
common fields.
Asset Management
Cloud Funcons Cloud Funcon Cloud Funcon No specific unique

fields displayed
in addion to the
common fields.
Manage Your Cloud Inventory Assets

The All Cloud Assets and Specific Cloud Assets pages provide a central locaon from which
you can view and invesgate informaon relang to inventory assets in the cloud. These cloud
inventory assets are collected from Google Cloud Plaorm, Microso Azure, and Amazon Web
Services depending on your defined cloud configuraons, and are received by Cortex XDR using
the Cloud Inventory data collector. These pages are designed in a similar format so you can
navigate to the page, view the data, and perform the same tasks to easily invesgate your assets.
To manage your cloud inventory assets.
STEP 1 | Select Assets > Cloud Inventory.
STEP 2 | View all All Cloud Assets by remaining on the page, or select a Specific Cloud Assets page
from the list available on the le panel.
By default, the pages displays all cloud assets according to the most recent me that the data
was updated.
STEP 3 | (Oponal) Filter and review your assets.

You can use the filter icon ( ) at the top of the page to build a filter from scratch or filter
the individual columns to view the informaon you are looking for. To create a persistent filter,
save ( ) it
STEP 4 | (Oponal) Export your filtered results to a tab-separated values (TSV) file using the Export to
file icon ( ) on the top of page.
STEP 5 | (Oponal) Invesgate any asset further by selecng the applicable row in the table to reveal
a side panel.
The side panel enables you to view addional data divided by secons, such as Asset
Metadata and Asset Editors. The Asset Editors secon also provides a link ( ) to open in a
Asset Management
new tab a predefined query in XQL Search on the cloud_audit_log dataset to view the edit
operaons by the identy selected for this asset in the last 7 days.
The following table describes the common side panel components that are displayed for all
asset types and subtypes, and the specific side panel components based on the specific cloud
assets type selected.
Side Panel Component Descripon Example Image
Common Side Panel Components
Header The header row displays the

following informaon 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.
• Addional specific
informaon per asset type,
which is only displayed
only if a value is available.
• The cloud PROVIDER.
Asset Management
Asset Metadata This secon includes the

following fields, which are
displayed if the informaon 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 Locaon—Displays
the normalized value
indicang the geographic
region, such as North
America or 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
• Microso Azure—
Subscripon
• Hierarchy—Displays the
hierarchy of the associated
PROJECT in the cloud
provider separated by a
Asset Management

forward slash (/) similar to
a file path.
The Project
is called
something
else in
each cloud
provider.
For more
informaon,
see the
PROJECT
descripon.
• Public IPs—Displays list of
external public IPs.
• Private IPs—Displays 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.
Asset Editors A bar chart of the idenes

of the Asset Editors is
displayed. Up to 5 editors are
displayed in a horizontal bar
chart lisng the percentage
of eding acons for a single
identy. The chart data does
not include any acons where
the identy 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
secon provides a link
( )
to open in a new tab
a predefined query
Asset Management

in XQL Search on the
cloud_audit_log dataset
to view the edit operaons by
the identy selected for this
A noficaon about the
data is also provided using
the format *Data since
<mestamp>.
Internet Exposure When there are any open

external ports, the open
ports and their corresponding
details are displayed.
• Title—The tle format is
<IP>:<port>. When you
hover your mouse over
the tle, you expose the
Show banner info icon,
which opens a Banner
window with the raw
JSON text obtained from
Cortex 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 mestamp
for when the open
external port was noced.
Specific Side Panel Components
Asset Management
VM Instance The TYPE of asset is set to

Compute and the SUBTYPE
is set to VM Instance. The
header includes the following
addional fields.
• Machine type—Displays
the type of machine.
• Last started—Displays
the last me the machine
started.
The following data is
displayed in the panel.
• Disks—A list of disks,
where each disk has the
following properes.
• 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
informaon, 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 network
interface.
• IP—The IP address of
the network interface.
• When you hover over
the network interface
name, you expose
different icons with
Asset Management

different acons that
you can perform to
open different side
panel components.
-View associated VPC—
Drills down to the VPC
side panel component if
the ID exists.
-View network
interface details—
Drills down to the
corresponding Network
Interface row if the ID
exists.
-View associated
subnet—Drills down to
the Subnet side panel
component if the ID
exists.
Disk Displays the following

informaon 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

• 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 acons
are available only if this
Asset Management

informaon is provided from
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

• Subnet as the specific
cloud assets type.
• CIDRs—A list of CIDRs.
Cloud Funcon Displays the following

• Cloud Funcons as the
• Runme—Displays the
runme system, such as
python3.9.
• Memory Size—The amount
of memory in MB.
• Descripon—A descripon
of the cloud funcon.
Storage Bucket Displays the following

• Storage Bucket as the
• Locaon Type—Displays
the bucket locaon as
either Regional or Mul
Regional
Asset Management

• Access Type—Displays the
bucket access opons as
one of the following.
• Public
• Private
• Fine Grained
• Unknown
Security Group Displays the following

• Security Group (FW Rule)
as the specific cloud assets
type.
• Group Name and
Descripon for the
Security Group, if
available. In AWS, there is
a name and descripon for
the enre group, while in
GCP per rule.
A Security Group is a list
of rules. A separate Rules
secon is displayed in the
side panel that lists the
following for each rule.
• Name—Name of the rule.
• Descripon—The
descripon 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
acons are dependent on
Asset Management

the available data, and are
exposed when you hover over
the INFO heading under the
NETWORK INTERFACES
secon.
• View associated VPC—
Drills down to the VPC
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
the ID exists.
STEP 6 | (Oponal) Manage cloud inventory assets, as needed.

At any me, 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 acon. Some acons are dependent on the type of cloud asset selected
and the parcular cell you are performing the acon 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 enre 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 invesgate and take acon
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 informaon, perform
Asset Management
common invesgave tasks, or iniate response acons related to a specific IP address or

CIDR.
• Show rows 30 days prior to ‘<mestamp field>’—For all mestamp fields in the assets
tables, you can filter the column list to only display the rows 30 days earlier than the
selected mestamp field.
• Show rows 30 days aer to ‘<mestamp field>’—For all mestamp fields in the assets
tables, you can filter the column list to only display the rows 30 days aer the selected
mestamp field.
Monitoring
> Cortex XDR Dashboard
> Monitor Cortex XDRXSIAM Incidents
> Monitor Cortex XDR Gateway Management Acvity
> Monitor Administrave Acvity
> Monitor Agent Acvity
> Monitor Agent Operaonal Status
891
Monitoring
Cortex XDR Dashboard

The Dashboard screen is the first page you see in the Cortex XDR app when you log in.
The dashboard comprises Dashboard Widgets (2) that summarize informaon about your endpoint
in graphical or tabular format. You can customize Cortex XDR to display Predefined Dashboards
or create your own custom dashboard using the dashboard builder. You can toggle between your
available dashboards using the dashboard menu (1).
In addion, the dashboard provides a color theme toggle (3) that enables you to switch the
interface colors between light and dark.
Dashboard Widgets
Cortex XDR provides the following list of widgets to help you create dashboards and reports
displaying summarized informaon about your endpoints.
Monitoring
Cortex XDR sorts widgets in the Cortex XDR app according to the following categories:
• Agent Management Widgets
• Asset Widgets
• Cloud Widgets
• Custom Widget
• Host Insights
• Incident Management Widgets
• Invesgaon Widgets
• System Monitoring
• User Defined Widgets
• XQL Search
Agent Management Widgets
Widget Name Descripon
Agent Content Version Breakdown Displays the total number of registered Cortex
XDR agents and the distribuon of agents by
content update version.
Agent Status Breakdown Displays the total number of Cortex XDR by

the agent status.
Agent Version Breakdown Displays the total number of registered Cortex

agent version.
Number of Installed Agents Displays a meline of the number of agents

installed on endpoints over the last 24 hours,
7 days, or 30 days.
Operang System Type Distribuon Displays the total number of registered

agents and their distribuon according to the
operang system.
Asset Widgets
Managed Assets vs Unmanaged Assets Displays a detailed breakdown of your acve

managed and unmanaged assets.
Monitoring
Agent Status Breakdown Displays the total number of Cortex XDR by

the agent status.
Agent Version Breakdown Displays the total number of registered Cortex

agent version.
Number of Installed Agents Displays a meline of the number of agents

installed on endpoints over the last 24 hours,
7 days, or 30 Days.
Operang System Type Distribuon Displays the total number of registered

agents and their distribuon according to the
operang system.
Top 5 Notable Users Displays the top 5 users with the highest User
Score. Select a user to pivot to the User View.
Cloud Widgets
Accounts by Cloud Provider Displays the number of accounts held in each

cloud provider. Refreshes every two hours.
Assets by Cloud Provider Displays the number of assets stored in each

cloud provider. Refreshes every two hours.
Assets by Geo Region Displays a breakdown of assets in each

geographic region. Refreshes every two hours.
Assets by Region Displays a breakdown of assets in each region.

Refreshes every two hours.
Assets by Responsive Port Number Displays the number of exposed cloud assets
by port number. Refreshes every two hours.
Assets by Sub-Type Displays a breakdown of cloud assets by sub-

type. Refreshes every two hours.
Assets by Type Displays a breakdown of cloud assets by type.

Refreshes every two hours.
Compute Instances Over Time Displays the number of mes a virtual

machine instance is used over me.
Monitoring

Select the me scope in the upper right to
view the number of Compute Instances over
the last 24 hours, 7 days, or 30 days.
Responsive Assets Over Time Displays the number of exposed cloud assets
over me.
view the number of exposed cloud assets over
the last 24 hours, 7 days, or 30 days.
Custom Widget
Custom Widget Displays visualizaon (such as chart, graph, or

addional visualizaon types) for the results
of an XQL Search.
See the XQL Language Reference for detailed
informaon about creang an XQL Search
query.
Host Insights
(Requires a Cortex XDR Host Insights Add-on)
CVEs By Severity Provides a summary of the total number of

exisng CVEs in your network according to
crical, high, medium, and low severity.
Click a severity to open a filtered view of the
CVEs.
Top CVEs By Affected Endpoints Displays the top Crical, High, and Medium
severity CVEs currently exisng in your
network according to the total number of
endpoints affected by each CVE.
Click a CVE to open a filtered view of all
affected endpoints.
Top Vulnerable Applicaons Displays the most vulnerable applicaons

with the highest number of Crical, High,
Monitoring

and Medium severity CVEs. Cortex XDR
calculates the vulnerabilies for different
applicaon versions running on different
operang systems.
Click an applicaon to open a filtered view of
all exisng CVEs for the selected applicaon.
Top Vulnerable Endpoints Displays the most vulnerable endpoints with

the highest number of crical, high, and
medium CVEs.
Click a host to open a filtered view of all
exisng CVEs for the selected host.
Vulnerabilies On All Endpoints Over Time Displays CVEs over me across your network.
view the number of CVEs over the last 24
hours, 7 days, or 30 Days.
Hover over the graph to view the number of
exisng CVEs on a specific day.
Incident Management Widgets
Incidents By Assignee Displays the top 10 users that are assigned

the highest number of incidents over the
last 30 days. For each assignee, the widget
displays the distribuon of Aged and Total
Open incidents. Aged incidents are older than
one week which have remained unresolved.
Select an assignee to open the incidents table
filtered to display incidents that are assigned
to the selected assignee.
Incidents By MITRE ATT&CK Display a breakdown of the number of

incidents involved with each MITRE ATT&CK
tacc and technique over the last 30 days,
7 days, 24 hours, or custom me range
according to the incidents creaon me.
Select a tacc or technique to pivot to the
Incidents Table filtered according to the
tacc/technique and creaon me.
Monitoring
Incidents By Status Provides a summary of the total current

number of open incidents according to status.
Click a status to open a filtered view of the
incidents.
Incidents Status Board Displays the last 30 days, 7 days, or 24 hours

of the following informaon according to the
incidents creaon me:
• Total number of open incidents, how many
are unassigned, and how many are overdue
according to the incident severity.
• Breakdown of open incidents according to
the status New and Under Invesgaon.
• Breakdown of resolved incidents according
to resolved reason.
For further invesgaon, select each of the
available breakdowns to pivot to the Incident
table sorted according to the incident creaon
me and selected breakdown.
Incidents Over Time Displays the following informaon over the

past 14 days:
• Number of new incidents created per day.
• Number of resolved incidents per day.
For further invesgaon, select each of the
bars to pivot to the Incident table sorted
according to the creaon date within the
selected 24 hours.
My Incidents Displays all acve incidents assigned to

the logged-in user, sorted according to the
creaon date. You can sort the list by age,
severity or score.
My Incidents Over Time Displays the daily number of new and

resolved incidents assigned to the logged-in
user for the past 14 days.
My Open Incidents by Severity Displays a breakdown of open incidents

assigned to the logged-in user, grouped by
severity, over the last 30 days. Click a severity
level to open a list of incidents filtered by that
severity level.
Monitoring
My MTTR Displays the Mean Time to Resolve (MTTR)

incidents assigned to the logged-in user,
compared to the defined Target MTTR.
Available date filters are 24 hours, 7 days, and
30 days.
Newest Incidents Displays the following details for the 5 most

recent incidents:
• Starred
• Severity
• ID
• Score
• Descripon
• Creaon me
Overdue Incidents of top 5 Assignees Displays the last 30 days, 7 days, or 24 hours
of the following informaon according to the
incidents creaon me:
• Top 5 assignees, by assignee name, with
the highest number of overdue incidents.
For further invesgaon, select a user to pivot
to the Incident table filtered according to the
incident creaon me and assignee.
Resolved Incidents by Assignee Displays a breakdown of the top five users

with the most resolved incidents assigned to
them according to the incident creaon me.
For further invesgaon, select an assignee to
pivot to the Incidents table filtered according
to the assignee and the resolved incident
resoluon me.
Resolved Incidents MTTR Displays either the last 30 days, 7 days,

or 24 hours of the following informaon
according to incident creaon me and
resolved statuses:
• Total Mean Time to Resolve (MTTR)
of all incidents, according to severity,
created during the selected meframe and
the average me it took to resolve the
incidents compared to the defined Target
MTTR.
Monitoring

For further invesgaon, select a severity
bar to pivot to the Incident table filtered
according to the incident creaon me and
severity.
Invesgaon Widgets
Data Usage Breakdown Displays a meline of the consumpon of

Cortex XDR data in TB. Hover over the graph
to see the amount at a specific me.
Detecon By Acons Displays the top five acons performed on

alerts or incidents. In the upper right corner:
• Toggle between alerts and incidents
• Select to view the number of alert/
incidents per acon over the last 24 hours,
7 days, or 30 Days
Detecons By Category Displays the top five categories of alerts or

incidents. In the upper right corner:
incidents per category over the last 24
hours, 7 days, or 30 Days
Detecon By Source Displays the top five sources of alerts or

incidents. In the upper right corner:
incidents per source over the last 24 hours,
7 days, or 30 Days
Open Incidents by Severity Displays the total open incidents over the last
30 days according to severity.
Select a severity to open a filtered view of
incidents by the selected severity.
Monitoring
Response Acon Breakdown Displays the top response acons taken in the
Acon Center over the last 24 hours, 7 days,
or 30 Days.
Top Hosts Displays the top ten hosts with the highest
number of incidents in order of severity over
the last 30 days. Incidents are color-coded:
red for high severity and yellow for medium
severity.
Click a host to open a filtered view of all open
incidents for the selected host.
Top Incidents Displays the top ten current incidents with the
highest number of alerts according to severity
over the last 30 days. Alerts are color-coded;
red for high and yellow for medium.
Click a severity to open a filtered view of all
open alerts for the selected incident.
Total Incidents Displays a meline of incidents including the

number of aged versus open incidents. Aged
incidents are older than one week which have
remained unresolved.
view the number of open incidents over the
last 24 hours, 7 days, or 30 days.
Hover over the graph to view the number of
open incidents on a specific day.
System Monitoring
Ingeson Rate Displays the rate at which Cortex XDR

consumes data ingested from a specific
vendor or product over the past 24 hours,
7 days, or 30 days. All ingeson rates are
measured by bytes per second.
Daily Consumpon A breakdown comparing the product/vendor

consumpon versus your allowed daily limit
over the past 24 hours, displayed in UTC.
Monitoring

The Daily limit is calculated according to your
Cortex XDR license type: Amount of TB / 30
days
If the ingeson rate has exceeded

your daily limit, Cortex XDR
will issue a noficaon through
the Noficaon Center and
email. Aer 3 connuous days
of exceeding the ingeson rate,
Cortex XDR will stop ingesng
data that exceeds the daily limit.
Detailed Ingeson Breakdown of ingeson data per vendor or

product over the past 30 days.
Filter the following informaon for each
source:
• Product/Vendor—Name of the selected
product or vendor.
• First Seen—Timestamp of when product/
vendor were first ingested.
• Last Seen—Timestamp of when product/
vendor were last ingested.
• Last Day Ingested—Amount of data
ingested over the past 30 days.
• Current Day Ingested—Amount of data
ingested over the past 24 hours.
User Defined Widgets
Free Text Displays a text box allowing to insert free text.
Header Displays a tle containing the free text. For

example, name and descripon of a report or
dashboard, customer name, tenant ID, or date.
Monitoring
XQL Search
XQL Query Displays visualizaon (such as chart, graph, or

addional visualizaon types) for the results
of an XQL Search query over the past 24
hours, 7 days, or 30 days. By default, the
query runs every 24 hours . Update Now to
rerun the query immediately.
See the XQL Language Reference for detailed
informaon about creang an XQL Search
query.
Manage Your Widget Library

The widget library displays predefined widgets and user-created custom widgets. From the widget
library, you can:
• Create and edit custom widgets based on XQL Search queries.
• Search for custom and predefined widgets.
• Edit exisng custom widgets.
Monitoring
STEP 1 | In Cortex XDR, navigate to Dashboards & Reports > Customize > Widget Library.
• Create and edit custom widgets based on XQL Search queries.
1. In the widget menu, Create custom XQL widget.
2. Enter a widget Name and oponal Descripon.
3. Create an XQL query. Select XQL Helper to view XQL search and schema examples.
4. Generate the XQL query to display the search results.
XQL queries generated from the widget library do not appear in the Query
Center. The results are used only for creang the custom widget.
5. In the Widget secon, define how you want to visualize the results.
6. Aer you are happy with the query parameters and visualizaon definions, Save
widget.
The custom widget appears in the list of exisng widgets.
• Search for custom and predefined widgets.
1. Search for a widget or Show widgets according to the type of category.
2. Select a widget type to display the widget graph type and parameters. By default, Cortex
XDR displays the widget with Mock Data. Toggle to display your current Real Data.
• Edit exisng custom widgets.
1. Locate a custom widget.
2. Select Update widget ( ) to edit the widget or Delete widget from library.
Eding an exisng widget affects all dashboards that include the widget and
future generated reports.
STEP 2 | (Oponal) Include the widgets listed in the widget library in your custom dashboards and
reports.
Predefined Dashboards
Cortex XDR comes with predefined dashboards that display widgets tailored to the dashboard
type. You can select any of the predefined dashboards directly from the dashboard menu in
Dashboards & Reports > Customize > Dashboards Manager. You can also select and rename a
predefined dashboard in the Dashboard Builder available by clicking + New Dashboard. The types
of dashboards that are available to you depend on your license type but can include:
• Agent Management Dashboard
• Cloud Inventory Dashboard
• Data Ingeson Dashboard
• Incident Management Dashboard
• My Dashboard
• Security Admin Dashboard
• Security Manager Dashboard
Monitoring
Agent Management Dashboard

The Agent Management Dashboard displays at-a-glance informaon about the endpoints and
agents in your deployment.
Support for the Agent Management Dashboard requires either a Cortex XDR Prevent or
Cortex XDR Pro per Endpoint license.
The dashboard is comprised of the following Dashboard Widgets:

• Agent Status Breakdown
• Agent Content Version Breakdown (Top 5)
• Agent Version Breakdown (Top 5)
• Operang Type Distribuon
• Top Hosts (Top 10 | Last 30 days)
Cloud Inventory Dashboard

The Cloud Inventory Dashboard displays an overview of all your assets on the cloud.
The Cloud Inventory Dashboard requires a Cortex XDR Pro per TB license.
Monitoring

• Accounts by Cloud Provider
• Compute Instances Over Time
• Assets by Cloud Provider
• Assets by Type
• Assets by Sub-Type
• Assets by Geo Region
• Assets by Region
• Assets by Responsive Port Number
• Responsive Assets Over Time
Data Ingeson Dashboard

The Data Ingeson dashboard displays an overview and detailed informaon regarding the type
and amount of data ingested by Cortex XDR filtered by different resoluons. For example, Syslog
Collector, Check Point logs, and authencaon logs.
Monitoring

• Daily Consumpon—Stacked graphs measuring your daily data consumpon, according to
either Vendors (default) or Products, versus your daily consumpon limit. Each bar indicates
a 24 hour range over the past 14 days. Cortex XDR measures and enforces the 24 hour rage
according to UTC, but the graph displays the 24 hour rage according to the selected tenant
mezone.
• Ingeson Rate—Displays your data ingeson rate, measured in Traffic/ Sec, over the past 24
hours, 7 days, or 30 days filtered according to the type of Vendors (default), Products, or All
Sources.
• Detailed Ingeson—Table lisng for the different Products (default) or Vendors, the LAST
SEEN date and me, LAST DAY INGESTED for the amount of data ingested over the last 24
hour range, and the CURRENT DAY INGESTED for the current amount ingested in the past 24
hours. Detailed ingeson for the current 24 hours is updated in 5 minute intervals.
The LAST DAY INGESTED and CURRENT DAY INGESTED columns always display 0
for any ingeson result less than 1.
Incident Management Dashboard

The Incidents Management Dashboard provides a graphical summary of incidents in your
environment, with incidents priorized and listed by severity, assignee, incident age, and affected
hosts.
Monitoring

• Incidents by Assignee (Top 10 | Last 30 days)
• Open Incidents
• Open Incidents By Severity (Last 30 days)
• Top Hosts (Top 10 | Last 30 days)
• Top Incidents (Top 10)
To filter a widget to display only incidents that match incident starring policies, select the star in
the right corner. A purple star indicates that the widget is displaying only starred incidents. The
starring filter is persistent and will connue to show the filtered results unl you clear the star.
My Dashboard
My Dashboard provides an overview of the incidents and MTTR for the logged-in user.
Monitoring
The dashboard is comprised of the following Dashboard Widgets.

• My Incidents
• My MTTR by Severity vs Target
• My Open Incidents By Severity
• My Incidents Over Time
Security Admin Dashboard

The Security Admin Dashboard displays an overview and detailed informaon regarding the
incidents across your organizaon and the status of resolved and overdue incidents.

• Incident Status Board—Displays a breakdown of the incidents over the last 30 days, 7 days, or
24 hours.
• Resolved Incident MTTR—Displays the overall MTTR of all incidents created by severity and
the average me it took to resolve the incidents compared to the defined Target MTTR over
the last 30 days, 7 days, or 24 hours.
• Overdue Incidents of Top 5 Assignees—Displays the top 5 assignees by assignee name with the
highest number of overdue incidents over the last 30 days, 7 days, or 24 hours according to the
incidents creaon me.
• Incidents Over Time—Displays the number of new incidents and resolved incidents over 14
days.
• Newest Incidents— Display incidents details of the 5 most recent incidents.
Monitoring
Security Manager Dashboard

The Security Manager Dashboard widgets display general informaon about Cortex XDR incidents
and agents.
The Security Manager Dashboard requires either a Cortex XDR Prevent or Cortex XDR Pro
per Endpoint license.
The dashboard is comprised of the following Dashboard Widgets.

• Agent Status Breakdown
• Agent Version Breakdown (Top 5)
• Incidents by Assignee (Top 10 | Last 30 days)
• Open Incidents By Severity (Last 30 days)
• Top Incidents (Top 10)
• Total Incidents
Build a Custom Dashboard

To create purposeful dashboards, you must consider the informaon that you and other analysts
find important to your day to day operaons. This consideraon guides you in building a custom
dashboard. When you create a dashboard, you can select widgets from the widget library and
choose their placement on the dashboard.
STEP 1 | Select Dashboards & Reports > Customize > Dashboards Manager > + New Dashboard.
STEP 2 | In the Dashboard Builder, enter a unique Dashboard Name and an oponal Descripon of
the dashboard.
Monitoring
STEP 3 | Choose the Dashboard Type.

You can use an exisng dashboard as a template, or you can build a new dashboard from
scratch.
STEP 5 | Customize your dashboard.

1. 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, you can use the toggle above
the dashboard to use Real Data.
2. Drag and drop widgets from the widget library to their desired posion.
3. For agent-related widgets, apply an endpoint scope, if desired.
Applying an endpoint scope restricts the results to only the endpoints that belong to the
group. To apply the scope, select the menu on the top right corner of the widget and
then select Groups. Search for and select one or more endpoint groups for which you
want to set the widget scope.
4. For incident-related widgets, select the star to display only incidents that match an
incident starring configuraon on your dashboard, if desired. A purple star indicates that
the widget is displaying only starred incidents (see Manage Incident Starring).
5. Repeat the process to connue adding addional widgets to the dashboard. If necessary,
you can also remove unwanted widgets from the dashboard. To remove a widget, select
the menu in the top right corner, and Remove widget.
STEP 6 | When you have finished customizing your dashboard, click Next.
STEP 7 | To set the custom dashboard as your default dashboard when you log in to Cortex XDR,
Define as default dashboard.
STEP 8 | To keep this dashboard visible only for you, select Private.
Otherwise, the dashboard is public and visible to all Cortex XDR app users with the appropriate
roles to manage dashboards.
STEP 9 | Generate your dashboard.
Manage Dashboards
In the Cortex XDR console, navigate to Dashboards & Reports > Customize > Dashboards
Manager to view all custom and default dashboards. From the Dashboards Manager, you can also
delete, edit, duplicate, disable, and perform addional management acons on your dashboards.
To manage an exisng dashboard, right click the dashboard and select the desired acon.
• Delete - Permanently delete a dashboard.
• Edit - Edit an exisng dashboard. You cannot edit the default dashboards provided by Palo Alto
Networks, but you can save it as a new dashboard.
• Save as new - Duplicate an exisng template.
• Disable - Temporarily disable a dashboard. If the dashboard is public, this dashboard is also
removed for all users.
Monitoring
• Set as default - Make the dashboard the default dashboard that displays when you (and other
users, if the dashboard is public) log in to Cortex XDR.
• Save as report template - Save a report as a template.
Run or Schedule Reports

There are two ways to create a report template:
• Run a Report Based on a Dashboard
• Create a Report from Scratch
Run a Report Based on a Dashboard

You can generate a report based on an exisng dashboard.
STEP 1 | Select Dashboards & Reports > Customize > Dashboards Manager.
STEP 2 | Right-click the dashboard from which you want to generate a report, and select Save as
report template.
STEP 3 | Enter a unique Report Name and an oponal Descripon of the report, then Save the
template.
STEP 4 | Select Reporng > Report Templates.
STEP 5 | Run the report.

You can either Generate Report to run the report on-demand, or you can Edit the report
template to define a schedule.
STEP 6 | Aer your report completes, you can download it from the Reporng > Reports page.
Create a Report from Scratch

You can create a new report, using an exisng or new template.
STEP 1 | Select Dashboards & Reports > Customize > Dashboards Manager > + New Template.
STEP 2 | Enter a unique Report Name and an oponal Descripon of the report.
STEP 3 | Select the Data Timeframe for your report.

You can choose Last 24H (day), Last 7D (week), Last 1M (month), or you can choose a custom
meframe.
Custom meframe is limited to one month.
STEP 4 | Choose the Report Type.

You can use an exisng template, or you can build a new report from scratch.
Monitoring
STEP 6 | Customize your report.

To get a feel for how the data will look, Cortex XDR provides mock data. To see how the report
would look with real data in your environment, you can use the toggle above the report to use
Real Data. Select Preview A4 to view how the report is displayed in an A4 format.
Drag and drop widgets from the widget library to their desired posion.
If necessary, remove unwanted widgets from the template. To remove a widget, select the
menu in the top right corner, and select Remove widget.
For incident-related widgets, you can also select the star to include only incidents that match
an incident starring configuraon in your report. A purple star indicates that the widget is
displaying only starred incidents.
STEP 7 | When you have finished customizing your report template, click Next.
STEP 8 | If you are ready to run the report, select Generate now.
STEP 9 | To run the report on a regular Schedule, you can specify the me and frequency that Cortex
XDR will run the report.
STEP 10 | (Oponal) Enter an Email Distribuon list or Slack workspace to send a PDF version of your
report.
Select Add password used to access report sent by email and Slack to set a password
encrypon.
Password encrypon is only available for PDF format.
STEP 11 | (Oponal) Aach CSV file of your XQL query widget to a report.
From the drop-down menu, search and select one or more of your custom widgets to aach
to the report. The XQL query widget is aached to the report as a CSV file along with the
customized PDF. Depending on how you selected to send the report, the CSV file is aached
as follows:
• Email—Sent as separate aachments for each widget. The total size of the aachment in the
email cannot exceed 20MB.
• Slack—Sent within a ZIP file that includes the PDF file.
STEP 12 | Save Template.
STEP 13 | Aer your report completes, you can download it from the Reporng > Reports page.
In the Name field, reports with mulple files, PDF and CSV files, are marked with a icon,
while reports with a single PDF are marked with a icon.
Monitoring
Monitor Cortex XDRXSIAM Incidents

The Incidents page displays all incidents in the Cortex XDR management console to help you
priorize, track, triage, invesgate and take remedial acon.
See Invesgate Incidents for more informaon.
Monitoring
Monitor Cortex Gateway Management Acvity

The Cortex Gateway allows you to manage the user roles and permissions across your Cortex XDR
CSP accounts. To track your permission management acvity, in the Cortex Gateway, navigate to
<User Name> and select Management Auding.
You must have Account Admin role permissions to access the Management Auding page.
The Management Audit Logs fields describe the following informaon:
Field Descripon
Descripon Log message describing the acon taken and on

which tenant. To filter according to a tenant, use the
contains operator.
Email Email of the user who performed the acon.
Result The result of the acon: Success, Fail, or N/A
Severity Severity associated with the log:

• Critical
• High
• Medium
• Low
• Informational
Subtype Addional classificaon of permissions log.
Timestamp Date and me when the acon occurred displayed in

UTC.
Type Type of acon, Permissions or Roles.
For Cortex XDR 3.0, only Permissions

type acons are displayed.
User Name Name of the user who performed the acon.
Monitoring
Monitor Administrave Acvity

From Sengs > Management Auding, you can track the status of all administrave and
invesgave acons. XDR stores audit logs for 365 days (instead of 180 days, which was the
retenon period in the past). Use the page filters to narrow the results or Manage Columns and
Rows to add or remove fields as needed.
To ensure you and your colleagues stay informed about administrave acvity, you can Configure
Noficaon Forwarding to forward your Management Audit log to an email distribuon list, Syslog
server, or Slack channel.
The following table describes the default and oponal addional fields that you can view in
Field Descripon
Email Email address of the administrave user
Descripon Descripve summary of the administrave acon.

Hover over this field to view more detailed
informaon in a popup toolp. 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 acon
Result Result of the administrave acon: Success, Paral,

or Fail.
Subtype Sub category of acon
Timestamp Time and date of the acon
Type Type of acvity logged, one of the following:

• Agent Configuraon—Configuraon of a parcular
Cortex XDR agent on a parcular endpoint.
• Agent Installaon—Installaon of the Cortex XDR
agent on a parcular endpoint.
• Alert Exclusions—Suppression of parcular alerts
from Cortex XDR.
• Alert Noficaons—Modificaon of the format or
ming of alerts.
• Alert Rules—Modificaon of alert rules.
• API Key—Modificaon of the Cortex XDR API key.
Monitoring
Field Descripon
• Authencaon—User sessions started, along with
the user name that started the session.
• Broker API—Operaon related to the Broker
applicaon programming interface (API).
• Broker VM—Operaon related to the Broker
virtual machine (VM).
• Dashboards—Use of parcular dashboards.
• Device Control Permanent Excepons—
Modificaon of permanent device control
excepons.
• Device Control Profile—Modificaon of a device
control profile.
• Device Control Temporary Excepons—
Modificaon of temporary device control
excepons.
• Disk Encrypon Profile—Modificaon of a disk
encrypon profile.
• Endpoint Administraon—Management of
endpoints.
• Endpoint Groups—Management of endpoint
groups.
• Extensions Policy—Modificaon of extension
policy sengs, including host firewall and disk
encrypon.
• Extensions Profiles—Modificaon of extension
profile sengs.
• Global Excepons—Management of global
excepons.
• Host Firewall Profile—Modificaon of a host
firewall profile.
• Host Insights— Iniaon of Host Insights data
collecon scan (Host Inventory and Vulnerability
Assessment).
• Incident Management—Acons taken on incidents
and on the assets, alerts, and arfacts in incidents.
• Ingest Data—Import of data for immediate use or
storage in a database.
• Integraons—Integraon operaons, such as
integrang Slack for outbound noficaons.
• Licensing—Any licensing-related operaon.
Monitoring
Field Descripon
• Live Terminal—Remote terminal sessions created
and acons taken in the file manager or task
manager, a complete history of commands issued,
their success, and the response.
• Managed Threat Hunng—Acvity relang to
managed threat hunng.
• MSSP—Management of security services
providers.
• Policy & Profiles—Acvity related to managing
policies and profiles.
• Prevenon Policy Rules—Modificaon of
prevenon policy rules.
• Protecon Policy—Modificaon of the protecon
policy.
• Protecon Profile—Modificaon of the protecon
profile.
• Public API—Authencaon acvity using an
associated Cortex XDR API key.
• Query Center—Operaons in the Query Center.
• Remediaon—Remediaon operaons.
• Reporng—Any reporng acvity.
• Response—Remedial acons taken. For example:
Isolate a host, undo host isolaon, add a file hash
signature to block list, or undo the addion to the
block list.
• Rules—Modificaon to rules.
• Rules Excepons—Creaon, eding, or deleon
under Rules excepons.
• SaaS Collecon—Any collected SaaS data.
• Script Execuon—Any script execuon.
• Starred Incidents—Modificaon of starred
incidents.
• Vulnerability Assessment—Any vulnerability
assessment acvity.
User Name The user who performed the acon.
Monitoring
Monitor Agent Acvity

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
reports the logs back to Cortex XDR hourly. Cortex XDR stores the logs for 365 days. To view the
Cortex XDR agent logs, select Sengs > Agent Auding.
To ensure you and your colleagues stay informed about agent acvity, you can Configure
Noficaon Forwarding to forward your Agent Audit log to an email distribuon 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 oponal fields that you can view in the Cortex XDR Agents Audit Table:
Field Descripon
Category The Cortex XDR agent logs these endpoint events using one of the
following categories:
• Audit—Successful changes to the agent indicang correct
behavior.
• Monitoring—Unsuccessful changes to the agent that may require
administrator intervenon.
• Status—Indicaon of the agent status.
Descripon Log message that describes the acon.
Domain Domain to which the endpoint belongs.
Endpoint ID Unique ID assigned by the Cortex XDR agent.
Endpoint Name Endpoint hostname.
Received Time Date and me when the acon was received by the agent and
reported back to Cortex XDR.
Result The result of the acon ( Success, Fail, or N/A)
Severity Severity associated with the log:

• Critical
• High
• Medium
• Low
Monitoring
Field Descripon
• Informational
Type and Sub-Type Addional classificaon of agent log (Type and Sub-Type:
• 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
• 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 prevenon data is being
deleted from the endpoint)
• Minimal content
Monitoring
Field Descripon
• Action:
• Endpoint Token
• Scan
• File retrieval
• Terminate process
• Isolate
• Cancel isolation
• Payload execution
• Quarantine
• Restore
• Block IP address
• Unblock IP address
• Tagging
Timestamp Date and me when the acon occurred.
XDR Agent Version Version of the Cortex XDR agent running on the endpoint.
Monitoring
Monitor Agent Operaonal Status

From the Cortex XDR management console, you have full visibility into the Cortex XDR
agent operaonal status on the endpoint, which indicates whether the agent is providing
protecon according to its predefined security policies and profiles. By observing the operaonal
status on the endpoint, you can idenfy when the agent may suffer from a technical issue or
misconfiguraon that interferes with the agent’s protecon capabilies or interacon with Cortex
XDR and other applicaons. The Cortex XDR agent reports the operaonal status as follows:
• Protected—Indicates that the Cortex XDR agent is running as configured and did not report any
excepons to Cortex XDR.
• Parally protected—Indicates that the Cortex XDR agent reported one or more excepons to
Cortex XDR.
• Unprotected—(Linux only) Indicates the Cortex XDR agent is not enforcing protecon on the
endpoint.
You can monitor the agent Operaonal Status in Endpoints > All Endpoints. If the Operaonal
Status field is missing, add it.
The operaonal status that the agent reports varies according to the excepons reported by the
Cortex XDR agent.
Status Descripon
Protected (Windows, Mac, and Linux) Indicates all protecon

modules are running as configured on the endpoint.
Parally protected Windows

• XDR data collecon is not running, or not set
• Behavioral threat protecon is not running
• Malware protecon is not running
• Exploit protecon is not running
Mac
• Operang system adapve mode*
• XDR Data Collecon is not running, or not set
Linux
• Kernel module not loaded**
• Kernel module compable but not loaded**
• Kernel version not compable**
• XDR Data Collecon is not running, or not set
Monitoring
Status Descripon
• An-malware flow is asynchronous
Unprotected Windows, Mac, and Linux:

• Behavioral threat protecon and Malware
protecon are not running
• Exploit protecon and malware protecon are not
running
• The content is unavailable.
Status can have the following implicaons on the endpoint:

• *(Status)—The exploit protecon module is not running.
• **(Status)—
• XDR data collecon is not running
• An-malware flow is asynchronous
• Local privilege escalaon protecon is asynchronous
Log Forwarding
To help you stay informed and updated, you can easily forward Cortex® XDR™ alerts
and reports to an external syslog receiver, a Slack channel, or to email accounts.
> Log Forwarding Data Types

> Integrate Slack for Outbound Noficaons
> Integrate a Syslog Receiver
> Configure Noficaon Forwarding
> Cortex XDR Log Noficaon Formats
923
Log Forwarding
Log Forwarding Data Types

To ensure you and your colleagues are informed and updated about events in your Cortex®
deployment, you can Configure Noficaon Forwarding to Email, Slack, or a syslog receiver. The
following table displays the data types supported by each noficaon receiver.
Data Type Email Slack Syslog Cortex XSOAR
Alerts
Agent Audit Log — —

Cortex XDR
Prevent or Cortex
XDR Pro per
Endpoint
Management Audit — —
Log
Reports — —
Log Forwarding
Integrate Slack for Outbound Noficaons

Integrate the Cortex® XDR™ app with your Slack workspace to beer manage and highlight your
Cortex XDR alerts and reports. By creang a Cortex XDR Slack channel, you ensure that defined
Cortex XDR alerts are exposed on laptop and mobile devices using the Slack interface. Unlike
email noficaons, Slack channels are dedicated to spaces that you can use to contact specific
members regarding your Cortex XDR alerts.
To configure a Slack noficaon, you must first install and configure the Cortex XDR app on Slack.
STEP 1 | From Cortex XDR, select Sengs > Configuraons > Integraons > External Applicaons.
STEP 2 | Select the provided link to install Cortex XDR on your Slack workspace.
You are directed to the Slack browser to install the Cortex XDR app. You can only use
this link to install Cortex XDR on Slack. Aempng to install from Slack marketplace
will redirect you to Cortex XDR documentaon.
STEP 3 | Click Submit.

Upon successful installaon, Cortex XDR displays the workspace to which you connected.
STEP 4 | Configure Noficaon Forwarding

Aer you integrate with your Slack workspace, you can configure your forwarding sengs.
Log Forwarding
Integrate a Syslog Receiver

To send Cortex XDR noficaons to your Syslog server, you need to define the sengs for the
Syslog receiver from which you want to send noficaons.
STEP 1 | Before you define the Syslog sengs, enable access to the following Cortex XDR IP
addresses for your deployment region in your firewall configuraons:
Region Log Forwarding IP Addresses
United States - Americas (US) • 35.232.87.9

• 35.224.66.220
Germany - Europe (EU) • 35.234.95.96

• 35.246.192.146
Netherlands - Europe (EU) • 34.90.202.186

• 34.90.105.250
Canada (CA) • 35.203.54.204

• 35.203.52.255
United Kingdom (UK) • 34.105.227.105

• 34.105.149.197
Singapore (SG) • 35.240.192.37

• 34.87.125.227
Japan (JP) • 34.84.88.183

• 35.243.76.189
Australia (AU) • 35.189.38.167

• 34.87.219.39
United States - Government • 104.198.222.185

• 35.239.59.210
India (IN) • 34.93.247.41

• 34.93.183.131
STEP 2 | Select Sengs > Configuraons > Integraons > External Applicaons.
STEP 3 | In Syslog Servers, add a + New Server.
Log Forwarding
STEP 4 | Define the Syslog server parameters:

• Name—Unique name for the server profile.
• Desnaon—IP address or fully qualified domain name (FQDN) of the Syslog server.
• Port—The port number on which to send Syslog messages.
• Facility—Choose one of the Syslog standard values. The value maps to how your Syslog
server uses the facility field to manage messages. For details on the facility field, see RFC
5424.
• Protocol—Select a method of communicaon with the Syslog server:
• TCP—No validaon is made on the connecon with the Syslog server. However, if an
error occurred with the domain used to make the connecon, the Test connecon will
fail.
• UDP—Cortex XDR runs a validaon to ensure connecon was made with the syslog
server.
• TCP + SSL—Cortex XDR validates the syslog server cerficate and uses the cerficate
signature and public key to encrypt the data sent over the connecon.
• Cerficate—The communicaon between Cortex XDR and the Syslog desnaon can use
TLS. In this case, upon connecon, Cortex XDR validates that the Syslog receiver has a
cerficate signed by either a trusted root CA or a self-signed cerficate. Cortex XDR validates
that the Syslog receiver has a cerficate signed by either a trusted root CA or a self signed
cerficate. You may need to merge the Root and Intermediate cerficate if you receive a
cerficate error when using a public cerficate.
Up to TLS 1.2 is supported.
If your Syslog receiver uses a self signed CA, Browse and upload your self-signed Syslog
receiver CA.
Make sure the self-signed CA includes your public key.
If you only use a trusted root CA leave the Cerficate field empty.
• Ignore Cerficate Error—Cortex XDR does not recommend, but you can choose to select
this opon to ignore cerficate errors if they occur. This will forward alerts and logs even if
the cerficate contains errors.
STEP 5 | Test the parameters to ensure a valid connecon and Create when ready.
You can define up to five Syslog servers. Upon success, the table displays the Syslog servers
and their status.
Log Forwarding
STEP 6 | (Oponal) Manage your Syslog server connecon.

In the Syslog Servers table
• Locate your Syslog server and right-click to Send text message to test the connecon.
Cortex XDR sends a message to the defined Syslog server which you can check to see if the
test message indeed arrived.
• Locate the Status field.
The Status field displays a Valid or Invalid TCP connecon. Cortex XDR tests connecon
with the Syslog server every 10min. If no connecon is found aer 1 hour, Cortex XDR send
a noce to the noficaon center.
If you find the Syslog data limited, Cortex XDR recommended to run the Get Alerts
API for complete alert data.
STEP 7 | Configure Noficaon Forwarding.

Aer you integrate with your Syslog receiver, you can configure your forwarding sengs.
Log Forwarding
Configure Noficaon Forwarding

With Cortex® XDR™ you can choose to receive noficaons to keep up with the alerts and
events that maer to your teams. To forward noficaons, you create a forwarding configuraon
that specifies the log type you want to forward. You can also add filters to your configuraon to
send noficaons that match specific criteria.
Cortex XDR applies the filter only to future alerts and events.
Use this workflow to configure noficaons for alerts, agent audit logs, and management audit
logs. To receive noficaons about reports, see Create a Report from Scratch.
STEP 1 | Select Sengs > Configuraons > General > Noficaons.
STEP 2 | + Add Forwarding Configuraon.
STEP 3 | Define the configuraon Name and Descripon.
STEP 4 | Select the Log Type you want to forward, one of the following:
• Alerts—Send noficaons for specific alert types (for example, XDR Agent or BIOC).
• Agent Audit Logs—Send noficaons for audit logs reported by your Cortex XDR agents.
• Management Audit Logs—Send noficaons for audit logs about events related to your
Cortex XDR management console.
STEP 5 | In the Configuraon Scope, Filter the type of informaon you want included in a noficaon.
For example, set a filter Severity = Medium, Alert Source = XDR Agent. Cortex
XDR sends the alerts or events matching this filter as a noficaon.
STEP 6 | (Oponal) Define your Email Configuraon.

1. In Email Distribuon, add the email addresses to which you want to send email
noficaons.
2. Define the Email Grouping Time Frame, in minutes, to specify how oen Cortex XDR
sends noficaons. Every 30 alerts or 30 events aggregated within this me frame are
sent together in one noficaon, sorted according to the severity. To send a noficaon
when one alert or event is generated, set the me frame to 0.
3. Choose whether you want Cortex XDR to provide an auto-generated subject.
4. If you previously used the Log Forwarding app and want to connue forwarding logs
in the same format, you can Use Legacy Log Format. See Cortex XDRXSIAM Log
Noficaon Formats.
Log Forwarding
STEP 7 | Configure addional forwarding opons.

Depending on the noficaon integraons supported by the Log Type, configure the desired
Slack channel or Syslog receiver noficaon sengs.
Before you can select a Slack channel or Syslog receiver you must Integrate Slack for
Outbound Noficaons and Integrate a Syslog Receiver.
1. 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. Aer
integrang your Slack account with your Cortex XDR tenant, Cortex XDR displays a list
of specific Slack channels associated with the integrated Slack workspace.
2. Select a Syslog receiver.
Cortex XDR displays the list of receivers integrated with your Cortex XDR tenant.
STEP 8 | Select Done to create the forwarding configuraon.
STEP 9 | (Oponal) To later modify a saved forwarding configuraon, right-click the configuraon, and
Edit, Disable, or Delete it.
Log Forwarding
Cortex XDRXSIAM Log Noficaon Formats

When Cortex XDR alerts and audit logs are forwarded to an external data source, noficaons are
sent in the following formats. If you prefer Cortex XDR to forward logs in legacy format, you can
choose the legacy opon in your log forwarding configuraon.
• Management Audit Log Messages
• Alert Noficaon Format
• Agent Audit Log Noficaon Format
• Management Audit Log Noficaon Format
• Legacy—Cortex XDR Log Format for IOC and BIOC Alerts
• Cortex XDR Analycs Log Formats
• Legacy—Cortex XDR (formerly Traps) Log Formats
Management Audit Log Messages

The following table displays the Cortex XDR management audit log messages by log type.
Message Details
Type-Acon Center
Action # {action_id} completed • Sub Type—Acon Completed

successfully. {action-- • Status—Success
_description}.
• Severity—Low
Action # {action_id} completed • Sub Type—Acon Completed

with {partial success}. {action-- • Status—Failed
_description}.
• Severity—Low
Action # {action_id} {failed / • Sub Type—Acon Completed

timeout / expired.} {action-- • Status—Failed
_description}.
• Severity—Low
Action # completed successfully. • Sub Type—Acon Completed

Action description: Set Endpoint • Status—Success
token with (x) days
• Severity—Low
Type—Agent Configuraon
Agent global uninstall password • Sub Type—Global uninstall password

updated • Status—Success
Log Forwarding
Message Details
• Severity—Informaonal
Agent auto upgrade configuration • Sub Type—Agent auto upgrade

Agent content bandwidth • Sub Type—Content bandwidth

management{bandwidth_allocation} management
• Status—Success
Agent advanced analysis • Sub Type—Advanced Analysis

configuration updated • Status—Success
Type—Agent Installaon
Distribution creation timeout for • Sub Type—Create

distribution id {distribution_id} • Status—Fail
packages generation - WLM task
timed-out • Severity—Informaonal
Deleted installation package • Sub Type—Delete

\'{distribution.dist_name}\ • Status—Success
Edited installation package • Sub Type—Edit

\'{current_distribution.dist_name}\ • Status—Success
Failed to create {general_desc} • Sub Type—Create

• Status—Fail
Created {general_desc} • Sub Type—Create

Type—Alert Exclusions
Log Forwarding
Message Details
Auto-resolved {cases_info} • Sub Type—Auto-Resolve Incidents

incidents because all of the • Status—Success
alerts they contain are excluded
Reopened incident ID {cases_info} • Sub Type—Unresolve Auto-Resolved

due to manual user action Incidents
Failed to Add exclusion policy • Sub Type—Add exclusion policy fail

{name} • Status—Fail
Add exclusion policy #{res} • Sub Type—Add exclusion policy

Failed to Edit exclusion policy • Sub Type—Edit exclusion policy fail

{edit_id} • Status—Fail
Edit exclusion policy #{edit_id} • Sub Type—Edit exclusion policy

Failed to delete exclusion policy • Sub Type—Delete exclusion policy fail

• Status—Fail
Delete exclusion policy {','.join(map(str, • Sub Type—Delete exclusion policy

whitelist_ids))}
Type—Alert Noficaons
Notification ID {rule_id} Created • Sub Type—New Configuraon

Notification ID {rule_id} Edited • Sub Type—Edit Configuraon
Log Forwarding
Message Details
Notification ID {rule_id} Enabled • Sub Type—Enable Configuraon

Notification ID {rule_id} • Sub Type—Disable Configuraon

Disabled • Status—Success
Notification ID {rule_id} Deleted • Sub Type—Delete Configuraon

Type—Alert Rules
Alert rule ID {rule_id} created • Sub Type—New Alert Rule

Alert rule ID {rule_id} edited • Sub Type—Edit Alert Rule

Alert rule ID {rule_id} deleted • Sub Type—Delete Alert Rule

Alert rule ID {rule_id} was • Sub Type—Enable Alert Rule

enabled • Status—Success
Alert rule ID {rule_id} was • Sub Type—Disable Alert Rule

disabled • Status—Success
Type—Api Key
Api Key ID {id} was added. • Sub Type—Add New Key

Log Forwarding
Message Details
Api Key ID {id} was edited. • Sub Type—Edit Key

Deleted Api Keys: {id}. • Sub Type—Delete Key

Api Key ID {id} was deleted. • Sub Type—Delete Key

Type—Authencaon
• Sub Type—Login
• Sub Type—Logout
User {user name} has failed to • Sub Type—Login

log in into the tenant, as the • Status—Fail
user is disabled
Type—Broker API
Broker {broker_id} has failed to • Sub Type—Authencaon failed

authenticate • Status—Fail
Type—Broker VMs
Broker VM register request • Sub Type—Register

completed • Status—Success
• Severity—Low
Broker VM register request failed • Sub Type—Register

• Status—Fail
Log Forwarding
Message Details
• Severity—Low
{app_pretty} activated on broker • Sub Type—Applet Acvated

VM {device_id} • Status—Success
• Severity—Low
{app_pretty} failed to activate • Sub Type—Applet Acvated

on broker VM {device_id} • Status—Fail
• Severity—Low
Setting configuration • Sub Type—Applet Set Configuraon

{app_pretty} on broker VM • Status—Success
{device_id}
• Severity—Low
Failed setting configuration • Sub Type—Applet Set Configuraon

{app_pretty} on broker VM • Status—Fail
{device_id}
• Severity—Low
Getting {app_pretty}'s • Sub Type—Applet Get Configuraon

configurations of broker VM • Status—Success
{device_id}
• Severity—Low
Failed getting {app_pretty} • Sub Type—Applet Get Configuraon

configurations for broker VM • Status—Fail
{device_id}
• Severity—Low
{app_pretty} deactivated on • Sub Type—Applet Deacvated

broker VM {device_id} • Status—Success
• Severity—Low
{app_pretty} failed to deactivate • Sub Type—Applet Deacvated

on broker VM {device_id} • Status—Fail
• Severity—Low
Broker VM {device_id} retrieve • Sub Type—Broker Log

logs request created • Status—Success
• Severity—Low
Broker VM {device_id} retrieve • Sub Type—Broker Log

logs failed request • Status—Fail
Log Forwarding
Message Details
• Severity—Low
Broker VM {device_id} was deleted • Sub Type—Remove Device

• Severity—Low
Failed to delete Broker VM • Sub Type—Remove Device

{device_id} • Status—Fail
• Severity—Low
Sent action {action_name} to • Sub Type—Acon on device

device: {device_id} • Status—Success
• Severity—Low
Failed to send action • Sub Type—Acon on device

{action_name} to device: • Status—Fail
{device_id}
• Severity—Low
Failed to start Live Shell with • Sub Type—Acon on device

Broker device: {device_id} • Status—Fail
• Severity—Low
Set configuration for device • Sub Type—Device configuraon

{device_id} • Status—Success
• Severity—Low
Failed to set configuration for • Sub Type—Device configuraon

device {device_id} • Status—Fail
• Severity—Low
Broker VM {device_name} has • Sub Type—Disconnect

disconnected from the Cortex XDR • Status—Fail
server.
• Severity—Low
Pathfinder configuration request • Sub Type—Edit Configuraon

• Severity—Low
Pathfinder configuration request • Sub Type—Edit Configuraon

failed • Status—Fail
Log Forwarding
Message Details
• Severity—Low
Pathfinder credentials request • Sub Type—Edit Credenals

• Severity—Low
Pathfinder credentials request • Sub Type—Edit Credenals

failed • Status—Fail
• Severity—Low
Pathfinder Test request completed • Sub Type—Test

• Severity—Low
Pathfinder Test request failed • Sub Type—Test

• Status—Fail
• Severity—Low
Type—Dashboards
Enabled Dashboard ID • Sub Type—Enable Dashboard

{dashboard_id} • Status—Success
Disabled Dashboard ID • Sub Type—Disable Dashboard

Deleted Dashboard ID • Sub Type—Delete Dashboard

Created Dashboard ID • Sub Type—Create New Dashboard

Edited Dashboard ID • Sub Type—Edit Dashboard

Type—Device Control Permanent Excepons
Log Forwarding
Message Details
Device control permanent • Sub Type—Edit

exceptions were edited • Status—Success
Failed to edit device control • Sub Type—Edit

permanent exceptions • Status—Fail
Exception was added to device • Sub Type—Edit

control permanent exceptions • Status—Success
profile
Failed to add exception to device • Sub Type—Edit

control permanent exceptions • Status—Fail
profile
Type—Device Control Profile
{platform} {profile_type} profile • Sub Type—Create

{profile_name} was created • Status—Success
Failed to create a profile • Sub Type—Create

• Status—Fail
{platform} {profile_type} profile • Sub Type—Delete

{profile_name} was deleted • Status—Success
Failed to delete a profile • Sub Type—Delete

• Status—Fail
{platform} {profile_type} profile • Sub Type—Edit

{profile_name} was edited • Status—Success
Failed to edit a profile • Sub Type—Edit

• Status—Fail
Log Forwarding
Message Details
A whitelist entry {vendor} • Sub Type—Edit

{product} {serial} was added • Status—Success
from a violation event to profile
{profile_name} • Severity—Informaonal
Failed to add exception to device • Sub Type—Edit

control exceptions profile • Status—Fail
Type—Device Control Temporary Excepons
A temporary excepon for {vendor} • Sub Type—Create

{product} {serial} on {target} {target_name}
with {permission} permissions for {me}
{me_units} was created • Severity—Informaonal
Failed to create a temporary • Sub Type—Create

exception from violation • Status—Fail
Device control temporary • Sub Type—Edit

exceptions were updated • Status—Success
Failed to update device control • Sub Type—Edit

temporary exceptions • Status—Fail
Type—Disk Encrypon Profile

Failed to create a host disk • Sub Type—Create

encryption profile • Status—Fail

Log Forwarding
Message Details
Failed to delete a host disk • Sub Type—Delete


Failed to edit a host disk • Sub Type—Edit

Type—EDL Management
Enable EDL • Sub Type—Enable

Disable EDL • Sub Type—Disable

Edit username • Sub Type—Edit

Edit password • Sub Type—Edit

Edit username and password • Sub Type—Edit

EDL Authentication • Sub Type—Authencaon

• Status—Fail
Type—Endpoint Administraon
Log Forwarding
Message Details
Uninstall agent on {scope} • Sub Type—Create

Upgrade {platform} on {scope} to • Sub Type—Create

{versions} • Status—Success
Retrieve endpoint data from • Sub Type—Create

{scope} • Status—Success
Change managing server on {scope} • Sub Type—Create

using the following distribution • Status—Success
IDs {distribution_ids}
Set agent proxy • Sub Type—Create

({proxy_addresses}) for • Status—Success
{host_name}
Delete {host_name} • Sub Type—Delete

Cancel {action_name} • Sub Type—Cancel

(id={group_action_id}) for • Status—Success
{scope}
Disable agent proxy for • Sub Type—Disable

{host_name} • Status—Success
Could not include {endpoint-id} • Sub Type—Agent auto upgrade

in auto upgrade • Status—Fail
Could not exclude {endpoint-id} • Sub Type—Agent auto upgrade

from auto upgrade • Status—Fail
Log Forwarding
Message Details
Could not include {endpoint-id} • Sub Type—Agent auto upgrade

and {x} other endpoints in auto • Status—Fail
upgrade
Could not exclude {endpoint-id} • Sub Type—Agent auto upgrade

and {x} other endpoints from auto • Status—Fail
upgrade
{endpoint-id} was excluded from • Sub Type—Agent auto upgrade

auto upgrade • Status—Success
{endpoint-id} was included in • Sub Type—Agent auto upgrade

auto upgrade • Status—Success
{endpoint-id} and {x} other • Sub Type—Agent auto upgrade

endpoints were included in auto • Status—Success
upgrade
{endpoint-id} and {x} other • Sub Type—Agent auto upgrade

endpoints were excluded from auto • Status—Success
upgrade
(tag_name) to (endpoint_name) and • Sub Type—Assign

5 other endpoints • Status—Success
(tag_name) from (endpoint_name) • Sub Type—Remove

and 5 other endpoints • Status—Success
Endpoint token was viewed for • Sub Type—View Token

hash (hash_id) and agent id • Status—Success
(agent-id)
Set endpoint token with (x) days • Sub Type—Set Token

expiration on (agent-id) • Status—Success
• Severity—Low
Log Forwarding
Message Details
Type—Endpoint Groups
Endpoint group '{group_name}' • Sub Type—Create Group

created • Status—Success
Endpoint group '{group_name}' • Sub Type—Create Group

failed to create • Status—Fail
Endpoint group '{group_name}' • Sub Type—Delete Group

deleted • Status—Success
Endpoint group '{group_name}' • Sub Type—Delete Group

failed to delete • Status—Fail
Endpoint group edited • Sub Type—Edit Group

{modified_fields} • Status—Success
Endpoint group '{group_name}' • Sub Type—Edit Group

failed to update • Status—Fail
Type-Event Forwarding
{operation} Endpoint Event • Sub Type—Change Endpoint Event

Forwarding Forwarding sengs
{operation} GB Event Forwarding • Sub Type—Change GB Event Forwarding

sengs
Generated New Service Account • Sub Type—Event Forwarding

JSON Web Token Authencaon
Log Forwarding
Message Details
Type—Extensions Policy
Device Control policy rules were • Sub Type—Edit

Failed to update device control • Sub Type—Edit

policy rules • Status—Fail
Extensions policy rules were • Sub Type—Edit

Failed to update extensions • Sub Type—Edit

policy rules • Status—Fail
Type—Extensions Profile

Failed to create an extensions • Sub Type—Create

profile • Status—Fail

Failed to delete an extensions • Sub Type—Delete


Log Forwarding
Message Details
Failed to edit an extensions • Sub Type—Edit

Type—Featured Alert Fields
Added {count}new featured • Sub Type—Add

{field_type} {plural} • Status—Success
Failed to add {count}new featured • Sub Type—Add

{field_type}{plural} • Status—Fail
Deleted {count}featured • Sub Type—Delete

Failed to delete {count}featured • Sub Type—Delete

Edited {count}featured • Sub Type—Edit

Failed to edit {count}featured • Sub Type—Edit

Imported new featured • Sub Type—Import

Failed to import new featured • Sub Type—Import

Log Forwarding
Message Details
Replaced all featured • Sub Type—Replace

{field_type} {plural} with a new • Status—Success
list containing {count}values
Failed to replace {count}featured • Sub Type—Replace

Type—Global Excepons
Global exceptions were edited • Sub Type—Edit

Failed to edit global exceptions • Sub Type—Edit

• Status—Fail
{exception_type} was added to • Sub Type—Edit

global exceptions profile • Status—Success
Failed to add exception to global • Sub Type—Edit

exceptions profile • Status—Fail
Type—Host Firewall Profile

Failed to create a host firewall • Sub Type—Create


Log Forwarding
Message Details
Failed to delete a host firewall • Sub Type—Delete


Failed to edit a host firewall • Sub Type—Edit

Type—Host Insights
Endpoint host insights collection • Sub Type—Collect Host Insights from an

initiated successfully Endpoint
Failed initiating host insights • Sub Type—Collect Host Insights from an

collection from an endpoint Endpoint
• Status—Fail
Type—Incident Management
Changed incident {incident_id} • Sub Type—Change Incident Status

status to {new_status} • Status—Success
Changed incident {incident_id} • Sub Type—Change Incident Severity

severity to {new_severity} • Status—Success
Changed incident {incident_id} • Sub Type—Edit Incident Name

name to {new_name} • Status—Success
Deleted incident {incident_id} • Sub Type—Deleted Incident Name

name • Status—Success
Log Forwarding
Message Details
Incident {incident_id} assigned • Sub Type—Assign Incident

to {user_name} • Status—Success
Incident {incident_id} unassigned • Sub Type—Unassigned Incident

Added artifact {artifact_type}: • Sub Type—Add Key Arfact

{artifact_value} to incident • Status—Success
{incident_id}
Added asset {asset_type}: • Sub Type—Add Key Asset

{asset_value} to incident • Status—Success
{incident_id}
Deleted artifact {artifact_type}: • Sub Type—Delete Key Arfact

{artifact_value} from incident • Status—Success
{incident_id}
Deleted asset {asset_type}: • Sub Type—Delete Key Asset

{asset_value} from incident • Status—Success
{incident_id}
Moved {count} alerts from • Sub Type—Move Alerts

incident {src_incident_id} to • Status—Success
incident {dst_incident_id}
Merged {src_incident_ids} with • Sub Type—Merge Incidents

incident {dst_incident_id} • Status—Success
Merged {src_incident_ids} • Sub Type—Merge Incidents

incidents with incident • Status—Success
{dst_incident_id}
Changed assignee of {count} • Sub Type—Bulk Change Incident Assignee

incident{plural} to {user_name} • Status—Success
Log Forwarding
Message Details
Changed status of {count} • Sub Type—Bulk Change Incident status

incident{plural} to {status} • Status—Success
Changed severity of {count} • Sub Type—Bulk Change Incident Severity

incident{plural} to {severity} • Status—Success
Changed scoring of {count} • Sub Type—Change Scoring

incident{plural} to • Status—Success
{manual_score}
Changed scoring of {count} • Sub Type—Change Scoring

incident{plural} to rule-based • Status—Success
scoring
Changed scoring of incident • Sub Type—Change Scoring

#{incident_id} to {manual_score} • Severity—InformaonalStatus—Success
•
Changed scoring of incident • Sub Type—Change Scoring

#{incident_id} to rule-based • Status—Success
scoring
Type—Ingest Data
Requested to ingest • Sub Type—CEF

{num_of_alerts} CEFs • Status—Success
Requested to ingest • Sub Type—LEEF

{num_of_alerts} LEEFs • Status—Success
Requested to ingest • Sub Type—Parsed Alerts

{num_of_alerts} parsed alerts • Status—Success
Type—Integraons
Log Forwarding
Message Details
Created syslog integration • Sub Type—Create Syslog Integraons

{syslog_name} (ID={syslog_id} • Status—Success
Edited syslog integration • Sub Type—Edit Syslog Integraons

{syslog_name} (ID={syslog_id}) • Status—Success
Deleted syslog integration • Sub Type—Delete Syslog Integraons

{syslog_name} (ID={syslog_id}) • Status—Success
Type—Licensing
Host Insights Add-on license has • Sub Type—Expiraon

expired • Status—Success
• Severity—Low
{license_name} license has • Sub Type—Expiraon

expired • Status—Success
{license_name} license • Sub Type—Expiraon

will expire in less than • Status—Success
{time_remaining_in_days} days
Your agents with data • Sub Type—Quota

collection license pool reached • Status—Success
{usage_percentage}% capacity,
{usage} out of {purchased} agents • Severity—Informaonal
installed
Your agents with data collection • Sub Type—Quota

license pool reached full • Status—Success
capacity
Your installed agents license • Sub Type—Quota

pool reached {usage_percentage}% • Status—Success
capacity, {usage} out of
{purchased} agents installed • Severity—Informaonal
Log Forwarding
Message Details
Your installed agents license • Sub Type—Quota

pool reached full capacity • Status—Success
Type—Live Terminal
Connection request sent to host: • Sub Type—Connect

{host} • Status—Success
• Severity—Low
Connection request sent to host: • Sub Type—Connect

{host} • Status—Fail
• Severity—Low
Connection opened • Sub Type—Status

• Severity—Low
Connection opened • Sub Type—Status

• Status—Fail
• Severity—Low
Connection closed • Sub Type—Status

• Severity—Low
Failed to {description} • Sub Type—Status

• Status—Fail
• Severity—Low
{error_detail} in {path} • Sub Type—Delete File

• Status—Fail
• Severity—Low
Delete file {path} • Sub Type—Delete File

• Severity—Low
Delete file {name} in {path} • Sub Type—Delete File

Log Forwarding
Message Details
• Severity—Low
{error_detail} in {path} • Sub Type—Move File

• Status—Fail
• Severity—Low
Move file {path} to {target_path} • Sub Type—Move File

• Severity—Low
Move file {name} from {path} to • Sub Type—Move File

{target_path} • Status—Success
• Severity—Low
{error_detail} in {path} • Sub Type—Copy File

• Status—Fail
• Severity—Low
Copy file {path} to {target_path} • Sub Type—Copy File

• Severity—Low
Copy file {name} from {path} to • Sub Type—Copy File

{target_path} • Status—Success
• Severity—Low
Type—Managed Threat Hunng
Pairing with {name} was removed • Sub Type—Pairing

Registered to MTH service with • Sub Type—Register

email : {email} • Status—Success
Registered to MTH service with • Sub Type—Re-register

Log Forwarding
Message Details
Registered to MTH service with • Sub Type—Register

email : {email} • Status—Fail
Registered to MTH service with • Sub Type—Re-register

Registered to MTH service with • Sub Type—Unregistered

Registered to MTH service with • Sub Type—Unregistered

Type—MSSP
Synced {len(biocs)} BIOC rules • Sub Type—Synchronizaon

and {len(exceptions)} exceptions • Status—Success
Synced {len(inclusions)} starred • Sub Type—Synchronizaon

alerts • Status—Success
Synced {len(whitelists)} • Sub Type—Synchronizaon

exclusion alerts • Status—Success
Synced {len(profiles)} profiles • Sub Type—Synchronizaon

Synced {len(ab_list)} allow/block • Sub Type—Synchronizaon

items • Status—Success
Failed to fetch data from • Sub Type—Synchronizaon

signed_url • Status—Fail
Log Forwarding
Message Details
Failed to sync {len(biocs)} • Sub Type—Synchronizaon

BIOC rules and {len(exceptions)} • Status—Fail
exceptions
Failed to sync {len(inclusions)} • Sub Type—Synchronizaon

starred alerts • Status—Fail
Failed to sync {len(whitelists)} • Sub Type—Synchronizaon

exclusion alerts • Status—Fail
Failed to sync {len(ab_list)} • Sub Type—Synchronizaon

allow/block list items • Status—Fail
Failed to sync {len(profiles)} • Sub Type—Synchronizaon

profiles • Status—Fail
Type—Permission
{user name} was assigned • Sub Type—User Permissions Assigned

permissions of role {role name} • Status—Success
{user name} permissions were • Sub Type—User Permissions Edited

updated from {role name} to {role • Status—Success
name}
{user name} permissions were • Sub Type—User Permissions Revoked

removed • Status—Success
{user name} access has been • Sub Type—User Access Disabled

disabled due to due to last login • Status—Success
timeout
Log Forwarding
Message Details
{user name} access has been • Sub Type—User Access Disabled

manualy disabled • Status—Success
{user name} access has been • Sub Type—User Access Enabled

enabled • Status—Success
{role name} created with the • Sub Type—Role Created

following permissions: {1,2,3,} • Status—Success
{role name} edited, the following • Sub Type—Role Edited

permissions {1,2} were added and • Status—Success
the following permissions removed
{1,2,3} • Severity—Informaonal
{role name} deleted • Sub Type—Role Deleted

Type—Policy & Profiles


• Status—Fail

{profile_name} was created by • Status—Success
{parent_tenant}

by {parent_tenant} by • Status—Fail
{parent_tenant}

Log Forwarding
Message Details
Failed to delete a profile • Sub Type—Delete

• Status—Fail

{profile_name} was deleted by • Status—Success
{parent_tenant}
Failed to delete a profile by • Sub Type—Delete

{parent_tenant} • Status—Fail

Failed to edit a profile • Sub Type—Edit

• Status—Fail
{exception_type} was added to • Sub Type—Edit

exceptions profile {profile_name} • Status—Success
Failed to add exception to • Sub Type—Edit

exceptions profile • Status—Fail

{profile_name} was edited by • Status—Success
{parent_tenant}
Failed to edit a profile by • Sub Type—Edit

{parent_tenant} • Status—Fail
• <X> profiles were exported • Sub Type—Import / Export

• Policy rule <name> was exported • Status—Success
Log Forwarding
Message Details
• <x> policy rules were exported • Severity—Informaonal
• <X> profiles were imported • Sub Type—Import / Export

• Policy rule <name> was • Status—Success
imported • Severity—Informaonal
• <x> policy rules were imported
Type—Prevenon Policy Rules
Policy rules were updated • Sub Type—Edit

Failed to update policy rules • Sub Type—Edit

• Status—Fail
Policy rules reverted to previous • Sub Type—Revert

state due to profile removal by • Status—Success
{parent_tenant}
Type—Public API
Source IP: {source_ip}, API key • Sub Type—Authencaon failed

ID: {key_id} • Status—Fail
Type—Query Center
Query ID {identifier} was • Sub Type—Run Query

executed • Status—Success
Query ID {identifier} was • Sub Type—Schedule Query

scheduled • Status—Success
Query ID {identifier} was removed • Sub Type—Remove Scheduling

from scheduled queries • Status—Success
Log Forwarding
Message Details
Query ID {identifier} was renamed • Sub Type—Rename Query

Query ID {identifier} was removed • Sub Type—Remove Query

Query ID {identifier} was saved • Sub Type—Save Query

Query ID {identifier} was enabled • Sub Type—Enable Query

Query ID {identifier} was • Sub Type—Disable Query

disabled • Status—Success
Query ID {identifier} was • Sub Type—Edit Query

rescheduled • Status—Success
Type—Remediaon
Created remediation action to • Sub Type—Create

{operations} from {scope} • Status—Success
• Severity—Low
Canceled {action_name} • Sub Type—Cancel

(id={group_action_id}) on {scope} • Status—Success
• Severity—Low
Type—Reporng
Downloaded report • Sub Type—Download Report

'{report_names}' ID {report_ids} • Status—Success
Log Forwarding
Message Details
Deleted report(s) • Sub Type—Delete Report

'{report_names}' ID(s) • Status—Success
{report_ids}
Created report template • Sub Type—Create New Report Template

'{template_name}' ID • Status—Success
{template_id}
Disabled report template • Sub Type—Disable Report Template

{template_id}
Enabled report template • Sub Type—Enable Report Template

{template_id}
Edited report template • Sub Type—Edit Report Template

{template_id}
Deleted report template(s) • Sub Type—Delete Report Template

'{template_name}' ID(s) • Status—Success
{template_id}
Emailed report '{template_name}' • Sub Type—Email Report

ID {report_id} to {emails} • Status—Success
Slack report '{template_name}' ID • Sub Type—Slack Report

{report_id} to {channels} • Status—Success
Type—Response
Retrieve {count} file(s) from • Sub Type—Create

• Severity—Low
Retrieve alert data from {scope} • Sub Type—Create

Log Forwarding
Message Details
• Severity—Low
Quarantine {path}, SHA256: {hash} • Sub Type—Create

on {scope} • Status—Success
• Severity—Low
Restore quarantined file with • Sub Type—Create

hash {hash} on {scope} • Status—Success
• Severity—Low
Malware scan on {scope} • Sub Type—Create

• Severity—Low
Abort malware scan on {scope} • Sub Type—Create

• Severity—Low
Isolate {scope} from the network • Sub Type—Create

• Severity—Low
UnIsolate {scope} • Sub Type—Create

• Severity—Low
Kill process {process_name} on • Sub Type—Create

• Severity—Low
Initiate Live Terminal on {scope} • Sub Type—Create

• Severity—Low
Delete {count} hash(es) from • Sub Type—Delete

allow list • Status—Success
• Severity—Low
Delete {cout} hash(es) from block • Sub Type—Delete

list • Severity—LowStatus—Success
Log Forwarding
Message Details
•
Delete isolation comment of • Sub Type—Delete

• Severity—Low
Cancel {action_name} (id= • Sub Type—Cancel

{action_id}) for {scope} • Status—Success
• Severity—Low
Enable {count} hash(es) from • Sub Type—Enable

• Severity—Low
Enable and move {count} hash(es) • Sub Type—Enable

from allow list to block list • Status—Success
• Severity—Low
Enable {count} hash(es) from • Sub Type—Enable

block list • Status—Success
• Severity—Low
Enable and move {count} hash(es) • Sub Type—Enable

from block list to allow list • Status—Success
• Severity—Low
{add_on_name} Add-on activated • Sub Type—Enable

successfully • Status—Success
• Severity—Low
Disable {count} hash(es) from • Sub Type—Disable

• Severity—Low
Disable {count} hash(es) from • Sub Type—Disable

• Severity—Low
{add_on_name} Add-on disabled • Sub Type—Disable

successfully • Status—Success
Log Forwarding
Message Details
• Severity—Low
Move {count} hash(es) to block • Sub Type—Move

list • Status—Success
• Severity—Low
Move {count} hash(es) to allow • Sub Type—Move

list • Status—Success
• Severity—Low
Edit comment of {count} hash in • Sub Type—Edit

• Severity—Low
Updated incident ID of a hash • Sub Type—Edit

from allow list: {hash} to: • Status—Success
{incident_id}
• Severity—Low
Removed incident ID of a hash • Sub Type—Edit

from allow list: {hash} • Status—Success
• Severity—Low
Edit comment of {count} hash in • Sub Type—Edit

• Severity—Low
Updated incident ID of a hash • Sub Type—Edit

from block list: {hash} to: • Status—Success
{incident_id}"
• Severity—Low
Removed incident ID of a hash • Sub Type—Edit

from block list: {hash} • Status—Success
• Severity—Low
Edit isolation comment of {scope} • Sub Type—Edit

to {isolate_comment} • Status—Success
• Severity—Low
Disable {capability} on {scope} • Sub Type—Disable Capability

Log Forwarding
Message Details
• Severity—Low
Removed {ip} from the blocked IP • Sub Type—Unblock

address list of {scope} • Status—Success
• Severity—Low
Type—Rules
IOC created - indicator: • Sub Type—Create

{indicator} id: {rule_id} • Status—Success
severity: {rule_severity} type:
{rule_type} • Severity—Informaonal
BIOC created - name: {rule_name} • Sub Type—Create

id: {rule_id} severity: • Status—Success
{rule_severity} type: {rule_type}
IOC deleted - indicator: {indicator} id: {rule_id} • Sub Type—Delete

severity: {rule_severity} type: {rule_type}
BIOC deleted - name: {rule_name} • Sub Type—Delete

IOC changed - indicator: • Sub Type—Change

Changed {count} IOCs • Sub Type—Change

BIOC changed - name: {rule_name} • Sub Type—Change

Changed {count} BIOCs • Sub Type—Change

Log Forwarding
Message Details
IOC disabled - indicator: • Sub Type—Disable

Disabled {count} IOCs • Sub Type—Disable

IOC Rule #{rule_id} ({rule_name}) • Sub Type—Disable

has been disabled as it reached • Status—Success
{limit} limit of hits in the past
24 hours. • Severity—Informaonal
BIOC disabled - name: {rule_name} • Sub Type—Disable

BIOC rule {rule_id} has been • Sub Type—Disable

automatically disabled because • Status—Success
it reached {hits} matches in the
last {time} - name: {rule_name} • Severity—Informaonal
{rule_type}
Disabled {count} BIOCs • Sub Type—Disable

Analytics BIOC rule disabled - • Sub Type—Disable

name: '{rule_name}' global rule • Status—Success
id: '{global_rule_id}'
Disabled {count} Analytics BIOC • Sub Type—Disable

rules • Status—Success
BIOC Rule #{rule_id} • Sub Type—Disable

({rule_name}) has been disabled • Status—Success
as it reached {limit} limit of
hits in the past 24 hours. • Severity—Informaonal
Log Forwarding
Message Details
IOC enabled - indicator: • Sub Type—Enable

Enabled {count} IOCs • Sub Type—Enable

BIOC enabled - name: {rule_name} • Sub Type—Enable

Enabled {count} BIOCs • Sub Type—Enable

Analytics BIOC rule enabled - • Sub Type—Enable

name: '{rule_name}' global rule • Status—Success
id: '{global_rule_id}'
Enabled {count} Analytics BIOC • Sub Type—Enable

rules • Status—Success
Imported {count} IOCs • Sub Type—Import

Imported {count} BIOCs • Sub Type—Import

{count} IOCs expired • Sub Type—Expire

Exported {count} BIOCs • Sub Type—Export

Log Forwarding
Message Details
BIOC content updated - Palo Alto • Sub Type—Content Update

Networks repository provided a • Status—Success
BIOC update
Type—Rules Excepons
Added new rule exception • Sub Type—Add

Edited rule exception ID: • Sub Type—Edit

{exception_id} • Status—Success
Deleted {exception_ids_len} rule • Sub Type—Delete

exceptions • Status—Success
Deleted rule exception ID: • Sub Type—Delete

{exception_id} • Status—Success
Exported {exception_id} rule • Sub Type—Export

exception • Severity—Informaonaltatus—Success
Exported {exported_exceptions} • Sub Type—Export

rule exceptions • Severity—Informaonaltatus—Success
Imported {exception_id} rule • Sub Type—Import

exception • Status—Success
Imported {imported_exceptions} • Sub Type—Import

rule exceptions • Status—Success
Type—SaaS Collecon
{vendor} Data Collection for • Sub Type—Create Configuraon

{name} created. • Status—Success
Log Forwarding
Message Details
{vendor} Data Collection for • Sub Type—Delete Configuraon

{name} deleted. • Status—Success
{vendor} Data Collection for • Sub Type—Edit Configuraon

{name} edited. • Status—Success
{vendor} Data Collection for • Sub Type—Disable Configuraon

{name} disabled. • Status—Success
{vendor} Data Collection for • Sub Type—Enable Configuraon

{name} enabled. • Status—Success
{vendor} Data Collection for • Sub Type—Configuraon Disconnected

{name} was disconnected with • Status—Fail
error '{disconnected_error}'
Collection authentication failed. • Sub Type—Authencaon Failed

Collection key ID {key_id}. • Status—Fail
Source IP: {source_ip}
Type—Scoring Rules
Scoring rules were updated • Sub Type—Edit

Failed to update scoring rules • Sub Type—Edit

• Status—Fail
Type—Script ExecutionRun • Sub Type—Run script

{script_name} on {scope} • Status—Success
• Severity—Low
Log Forwarding
Message Details
Cancel {action_name} • Sub Type—Cancel

{scope}
• Severity—Low
Abort {action_name} • Sub Type—Abort

{scope}
• Severity—Low
Add {outcome} script, • Sub Type—Add Script

name: {name}, description: • Status—Success
{description}, compatible
for {platform}, script id: • Severity—Informaonal
{script_id}
Edit {script_name}, script id - • Sub Type—Edit

{script_id}: {updated_values} • Status—Success
Delete {script_name}, script id: • Sub Type—Delete

{script_id} • Status—Success
Type—Security Sengs
Changed user login • Sub Type—Change Session Expiraon

expiration from • Status—Success
{old_user_login_expiration} hours
to {old_user_login_expiration} • Severity—Informaonal
hours
Changed dashboard expiration from • Sub Type—Change Session Expiraon

{previous_dashboard_expiration} • Status—Success
to {new_dashboard_expiration}
{action} session’s approved • Sub Type—Change Session’s Approved

domains {domain_list} Domains
Log Forwarding
Message Details
Acon is Enabled, Disabled, or
Changed.
domain_list is in one of the
following formats.
• for domainX, domainY
• from: domainX to: domainY
• (empty)
{action} session’s approved CIDRs • Sub Type—Change Session’s Approved

{CIDR_list} CIDRs
Acon is Enabled, Disabled, or

Changed.
CIDR_list is in one of the following
formats.
• for CIDRX, CIDRY
• from: CIDRX to: CIDRY
• (empty)
{action} user expiration • Sub Type—Change User Expiraon Sengs

{expiration_change} • Status—Success
Acon is Enabled, Disabled or

Changed.
expiraon_change is in one of the
following formats.
• for x days
• from x days to y days
• (empty)
Added domain(s) {domains_list} to • Sub Type—Add Allowed Distribuon List

the Allowed Domains list Domain
Log Forwarding
Message Details
Deleted domain(s) {domains_list} • Sub Type—Delete Allowed Distribuon List

from the Allowed Domains list Domain
Type—Starred Incidents
Incident {incident_id} was • Sub Type—Manual Star

manually starred • Status—Success
Incident {incident_id} was • Sub Type—Manual Un-star

manually unstarred • Status—Success
{count} incident{plural} were • Sub Type—Bulk Star

starred • Status—Success
{count} incident{plural} were un- • Sub Type—"Bulk Un-star

starred • Status—Success
Enabled starring policy {edit_id} • Sub Type—Enable Policy

• Status—Success / Fail
Disabled starring policy • Sub Type—Disable Policy

{edit_id} • Status—Success / Fail
Edited starring policy {edit_id} • Sub Type—Edit Policy

Deleted starring policy • Sub Type—Delete Policy

Created starring policy {res} • Sub Type—Create Policy
Log Forwarding
Message Details
Type—System
Temporary Devops access granted • Sub Type—Devops Access

to user: ({member}) • Status—Success
Alert Noficaon Format

Cortex XDR Agent, BIOC, IOC, Analycs, Correlaon and third-party alerts are forwarded to
external data resources according to the following formats.
Email Account
Alert noficaons are sent to email accounts according to the sengs you configured when
you Configure Noficaon Forwarding. If only one alert exists in the queue, a single alert email
format is sent. If more than one alert was grouped in the me frame, all the alerts in the queue
are forwarded together in a grouped email format. Emails also include an alert code snippet of the
fields of the alerts according to the columns in the Alert table.
Single Alert Email Example
Email Subject: Alert: <alert_name>

Email Body:
Alert Name: Suspicious Process Creation
Severity: High
Source: XDR Agent
Category: Malware
Action: Detected
Host: <host name>
Username:<user name>
Excluded: No
Starred: Yes
Alert: <link to Cortex XDR app alert view>
Incident: <link to Cortex XDR app incident view>
Grouped Alert Email Example
Email Subject: Alerts: <first_highest_severity_alert> + x others

Email Body:
Alert Name: Suspicious Process Creation
Severity: High
Source: XDR Agent
Category: MalwareAction: Detected
Host: <host name>
Username:<user name>
Excluded:No
Log Forwarding
Starred: Yes
Alert: <link to Cortex XDR app alert view>Incident: <link to
Cortex XDR app incident view>
Alert Name: Behavioral Threat Protection
Alert ID: 2412
Description: A really cool detection
Severity: Medium
Source: XDR Agent
Category: Exploit
Action: Prevented
Host: <host name>
Starred: Yes
Alert: <link to Cortex XDR app alert view>
Incident: <link to Cortex XDR app incident view>
Notification Name: “My notification policy 2 ”
Notification Description: “Starred alerts with medium severity”
Body Email Example
{
"original_alert_json":{
"uuid":"<UUID Value>",
"recordType":"threat",
"customerId":"<Customer ID>",
"severity":4,
"generatedTime":"2020-11-03T07:46:03.166000Z",
"originalAgentTime":"2020-11-03T07:46:01.372974700Z",
"serverTime":"2020-11-03T07:46:03.312633",
"isEndpoint":1,
"agentId":"<agent ID>",
"endPointHeader":{
"osVersion":"<OS version>",
"agentIp":"<Agent IP Address>",
"deviceName":"<Device Name>",
"agentVersion":"<Agent Version>",
"contentVersion":"152-40565",
"policyTag":"<Policy Tag Value>",
"securityStatus":0,
"protectionStatus":0,
"dataCollectionStatus":1,
"isolationStatus":0,
"agentIpList":[
"<IP Address>"
],
"addresses":[
{
"ip":[
"<IP Address>"
],
"mac":"<Mac ID>"
}
],
"liveTerminalEnabled":true,
"scriptExecutionEnabled":true,
"fileRetrievalEnabled":true,
"agentLocation":0,
Log Forwarding
"fileSearchEnabled":false,
"deviceDomain":"env21.local",
"userName":"Aragorn",
"userDomain":"env21.local",
"userSid":"<User S ID>",
"osType":1,
"is64":1,
"isVdi":0,
"agentId":"<Agent ID>",
"agentTime":"2020-11-03T07:46:03.166000Z",
"tzOffset":120
},
"messageData":{
"eventCategory":"prevention",
"moduleId":"COMPONENT_WILDFIRE",
"moduleStatusId":"CYSTATUS_MALICIOUS_EXE",
"preventionKey":"<Prevention Key>",
"processes":[
{
"pid":111,
"parentId":<Parent ID>,
"exeFileIdx":0,
"userIdx":0,
"commandLine":"\"C:\\<file path>\\test.exe\" ",
"instanceId":"Instance ID",
"terminated":0
}
],
"files":[
{
"rawFullPath":"C:\\<file path>\\test.exe",
"fileName":"test.exe",
"sha256":"<SHA256 Value>",
"fileSize":"12800",
"innerObjectSha256":"<SHA256 Value>"
}
],
"users":[
{
"userName":"<User Name>",
"userDomain":"<Domain Name>",
"domainUser":"<Domain Name>\\<User Name>"
}
],
"urls":[
],
"postDetected":0,
"sockets":[
],
"containers":[
],
"techniqueId":[
Log Forwarding
],
"tacticId":[
],
"modules":[
],
"javaStackTrace":[
],
"terminate":0,
"block":0,
"eventParameters":[
"C:\\<file path>\\test.exe",
"B30--A56B9F",
"B30--A56B9F",
"1"
],
"sourceProcessIdx":0,
"fileIdx":0,
"verdict":1,
"canUpload":0,
"preventionMode":"reported",
"trapsSeverity":2,
"profile":"Malware",
"description":"WildFire Malware",
"cystatusDescription":"Suspicious executable detected",
"sourceProcess":{
"user":{
"userName":"<User Name>",
"userDomain":"<Domain Name>",
"domainUser":"<Domain Name>"\\"<User Name>"
},
"pid":1111,
"parentId":<Parent ID>,
"exeFileIdx":0,
"userIdx":0,
"commandLine":"\"C:\\<file path>\\test.exe\" ",
"instanceId":"<Instance ID>",
"terminated":0,
"rawFullPath":"C:\\<file path>\\Test.exe",
"fileName":"test.exe",
"sha256":"<SHA256 Value>",
"fileSize":"12800",
"innerObjectSha256":"<SHA256 Value>"
},
"policyId":"<Policy ID>"
}
},
"internal_id":<Internal ID>,
"external_id":"<External ID>",
"severity":"SEV_030_MEDIUM",
"matching_status":"MATCHED",
"end_match_attempt_ts":1604389636437,
"alert_source":"TRAPS",
"local_insert_ts":1604570760,
Log Forwarding
"source_insert_ts":160470366,
"alert_name":"WildFire Malware",
"alert_category":"Malware",
"alert_description":"Suspicious executable detected",
"bioc_indicator":null,
"matching_service_rule_id":null,
"attempt_counter":1,
"bioc_category_enum_key":null,
"alert_action_status":"REPORTED",
"case_id":111,
"is_whitelisted":false,
"starred":false,
"deduplicate_tokens":null,
"filter_rule_id":null,
"mitre_technique_id_and_name":[
""
],
"mitre_tactic_id_and_name":[
""
],
"agent_id":"80d2e314c92f6",
"agent_version":"7.2.1.2718",
"agent_ip_addresses":[
"10.208.213.137"
],
"agent_hostname":"<Agent Hostname>",
"agent_device_domain":"<Device Domain>",
"agent_fqdn":"<FQDN Value>",
"agent_os_type":"AGENT_OS_WINDOWS",
"agent_os_sub_type":"<Operating System Sub-Type> ",
"agent_data_collection_status":true,
"mac":"<Mac ID>",
"agent_is_vdi":null,
"agent_install_type":"STANDARD",
"agent_host_boot_time":[
1604446615
],
"event_sub_type":null,
"module_id":[
"WildFire"
],
"association_strength":null,
"dst_association_strength":null,
"story_id":null,
"is_disintegrated":null,
"event_id":null,
"event_type":[
1
],
"event_timestamp":[
1604389563166
],
"actor_effective_username":[
"<Domain Name>\\<User Name>"
],
"actor_process_instance_id":[
Log Forwarding
"<Actor>\/<Instance ID>"
],
"actor_process_image_path":[
"C:\\<file path>\\test.exe"
],
"actor_process_image_name":[
"test.exe"
],
"actor_process_command_line":[
"\"C:\\<file path>\\test.exe\" "
],
"actor_process_signature_status":[
"SIGNATURE_UNSIGNED"
],
"actor_process_signature_vendor":null,
"actor_process_image_sha256":[
"SHA256 Value>"
],
"actor_process_image_md5":[
"MD5 Value>"
],
"actor_process_causality_id":[
"<Actor>\/<Causality ID>"
],
"actor_causality_id":null,
"actor_process_os_pid":[
1111
],
"actor_thread_thread_id":[
1222
],
"causality_actor_process_image_name":[
"test1.exe"
],
"causality_actor_process_command_line":[
"C:\\<file path>\\test1.EXE"
],
"causality_actor_process_image_path":[
"C:\\<file path>\\test1.exe"
],
"causality_actor_process_signature_vendor":[
"Microsoft Corporation"
],
"causality_actor_process_signature_status":[
"SIGNATURE_SIGNED"
],
"causality_actor_causality_id":[
"AdaxtV\/iNIMAAAc8AAAAAA=="
],
"causality_actor_process_execution_time":[
1604389557724
],
"causality_actor_process_image_md5":null,
"causality_actor_process_image_sha256":[
"SHA256 value>"
],
Log Forwarding
"action_file_path":null,
"action_file_name":null,
"action_file_md5":null,
"action_file_sha256":null,
"action_file_macro_sha256":null,
"action_registry_data":null,
"action_registry_key_name":null,
"action_registry_value_name":null,
"action_registry_full_key":null,
"action_local_ip":null,
"action_local_port":null,
"action_remote_ip":null,
"action_remote_port":null,
"action_external_hostname":null,
"action_country":[
"UNKNOWN"
],
"action_process_instance_id":null,
"action_process_causality_id":null,
"action_process_image_name":null,
"action_process_image_sha256":null,
"action_process_image_command_line":null,
"action_process_signature_status":[
"SIGNATURE_UNAVAILABLE"
],
"action_process_signature_vendor":null,
"os_actor_effective_username":null,
"os_actor_process_instance_id":null,
"os_actor_process_image_path":null,
"os_actor_process_image_name":null,
"os_actor_process_command_line":null,
"os_actor_process_signature_status":[
"SIGNATURE_UNAVAILABLE"
],
"os_actor_process_signature_vendor":null,
"os_actor_process_image_sha256":null,
"os_actor_process_causality_id":null,
"os_actor_causality_id":null,
"os_actor_process_os_pid":null,
"os_actor_thread_thread_id":[
1396
],
"fw_app_id":null,
"fw_interface_from":null,
"fw_interface_to":null,
"fw_rule":null,
"fw_rule_id":null,
"fw_device_name":null,
"fw_serial_number":null,
"fw_url_domain":null,
"fw_email_subject":null,
"fw_email_sender":null,
"fw_email_recipient":null,
"fw_app_subcategory":null,
"fw_app_category":null,
"fw_app_technology":null,
Log Forwarding
"fw_vsys":null,
"fw_xff":null,
"fw_misc":null,
"fw_is_phishing":[
"NOT_AVAILABLE"
],
"dst_agent_id":null,
"dst_causality_actor_process_execution_time":null,
"dns_query_name":null,
"dst_action_external_hostname":null,
"dst_action_country":null,
"dst_action_external_port":null,
"is_pcap":null,
"contains_featured_host":[
"NO"
],
"contains_featured_user":[
"YES"
],
"contains_featured_ip":[
"YES"
],
"events_length":1,
"is_excluded":false
Log Forwarding
Slack Channel
You can send alert noficaons to a single Slack contact or a Slack channel. Noficaons are
similar to the email format.
Syslog Server
Alert noficaon forwarded to a Syslog server are sent in a CEF format RF 5425.
Syslog Header
<9>: PRI (considered a prioirty
field)1: version number2020-03-2
2T07:55:07.964311Z: timestamp of
when alert/log was sentcortexxd
r: host name
CEF Header
HEADER/Vendor="Palo Alto Network
s" (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=(integ
er/0 - Unknown, 6 - Low, 8 - Med
ium, 9 - High)HEADER/Device Even
t Class ID=alert sourceHEADER/na
me =alert name
CEF Body
end=timestamp shost=endpoint_nam
e deviceFacility=facility cat=ca
tegory externalId=external_id re
quest=request cs1=initiated_by_p
rocess cs1Label=Initiated by (co
nstant string) cs2=initiator_com
mande cs2Label=Initiator CMD (co
nstant string) cs3=signature cs3
Log Forwarding
Label=Signature (constant string
) cs4=cgo_name cs4Label=CGO name
(constant string) cs5=cgo_comma
nd cs5Label=CGO CMD (constant st
ring) cs6=cgo_signature cs6Label
=CGO Signature (constant string)
dst=destination_ip dpt=destinat
ion_port src=source_ip spt=sourc
e_port fileHash=file_hash filePa
th=file_path targetprocesssignat
ure=target_process_signature ten
antname=tenant_name tenantCDLid=
tenant_id CSPaccountname=account
_name initiatorSha256=initiator_
hash initiatorPath=initiator_pat
h osParentName=parent_name osPar
entCmd=parent_command osParentSh
a256=parent_hash osParentSignatu
re=parent_signature osParentSign
er=parent_signer incident=incide
nt_id act=action suser=actor_eff
ective_username
Example
<177>1 2020-10-04T10:06:55.192016Z cortexxdr - - - - CEF:0|Palo Alto

Networks|Cortex XDR|Cortex XDR 2.4|XDR Analytics|High Connection
Rate|6|end=1601792870694 shost=WGHRAMG deviceFacility=None
cat=Discovery externalId=98106342 request=https:\/\/iga-
bh.xdr.eu.paloaltonetworks.com\/alerts\/98106342 cs1=iexplore.exe
cs1Label=Initiated by cs2=\“C:\\\\Program Files (x86)\\\\Internet
Explorer\\\\IEXPLORE.EXE\” SCODEF:11844 CREDAT:82946 \/prefetch:2
cs2Label=Initiator CMD cs3=Microsoft CorporationSIGNATURE_SIGNED-
cs3Label=Signature cs4=iexplore.exe cs4Label=CGO name cs5=\“C:
\\\\Program Files (x86)\\\\Internet Explorer\\\\IEXPLORE.EXE
\” SCODEF:11844 CREDAT:82946 \/prefetch:2 cs5Label=CGO CMD
cs6=Microsoft CorporationSIGNATURE_SIGNED- cs6Label=CGO
Signature dst=10.12.4.37 dpt=8000 src=10.10.28.140 spt=58003
fileHash=e582676ec900249b408ab4e37976ae8c443635a7da77755daf6f896a172856a3
filePath=C:\\\\Program Files (x86)\\\\Internet Explorer\\\
\iexplore.exe targetprocesssignature=NoneSIGNATURE_UNAVAILABLE-
tenantname=iGA tenantCDLid=1021319191 CSPaccountname=Information &
eGovernment Authority
initiatorSha256=e582676ec900249b408ab4e37976ae8c443635a7da77755daf6f896a172856a
initiatorPath=C:\\\\Program Files (x86)\\\\Internet Explorer\\\
\iexplore.exe
cgoSha256=e582676ec900249b408ab4e37976ae8c443635a7da77755daf6f896a172856a3
osParentName=iexplore.exe osParentCmd=\“C:\\
\\Program Files (x86)\\\\Internet Explorer\\\
\IEXPLORE.EXE\” SCODEF:11844 CREDAT:82946 \/prefetch:2
osParentSha256=e582676ec900249b408ab4e37976ae8c443635a7da77755daf6f896a172856a3
Log Forwarding
osParentSignature=SIGNATURE_SIGNED osParentSigner=Microsoft
Corporation incident=118719 act=Detected suser=['root']
Agent Audit Log Noficaon Format

To forward agent audit logs, you must have either a Cortex XDR Prevent or Cortex XDR
Pro per Endpoint license.
Cortex XDR forwards the agent audit log to external data resources according to the following
formats.
Email Account
Cortex XDR can forward agent audit log noficaons to email accounts.
Syslog Server
Agent audit logs forwarded to a Syslog server are sent in a CEF format RFC 5425 according to the
following mapping.
Syslog Header
<9>: PRI (considered a prioirty field)1: version n
umber2020-03-22T07:55:07.964311Z: timestamp of whe
n alert/log was sentcortexxdr: host name
CEF Header
HEADER/Vendor="Palo Alto Networks" (as a constant
string)HEADER/Device Product="Cortex XDR Agent" (a
s a constant string)HEADER/Device Version= Cortex
XDR Agent version (7.0/7.1....)HEADER/Severity=(in
teger/0 - Unknown, 6 - Low, 8 - Medium, 9 - High)H
EADER/Device Event Class ID="Agent Audit Logs" (as
a constant string)HEADER/name = type
Log Forwarding
CEF Body
dvchost=domain shost=endpoint_name cat=category en
d=timestamp rt=received_time cs1Label=agentversion
(constant string) cs1=agent_version cs2Label=subt
ype (constant string) cs2=subtype cs3Label=result
(constant string) cs3=result cs4Label=reason (cons
tant string) cs4=reason msg=event_description tena
ntname=tenant_name tenantCDLid=tenant_id CSPaccoun
tname=csp_id
Example:
<182>1 2020-10-04T10:41:14.608731Z cortexxdr - - - - CEF:0|Palo

Alto Networks|Cortex XDR Agent|Cortex XDR Agent 7.2.0.63060|
Agent Audit Logs|Agent Service|9|dvchost=WORKGROUP shost=Test-
Agent cat=Monitoring end=1601808073102 rt=1601808074596
cs1Label=agentversion cs1=7.2.0.63060 cs2Label=subtype cs2=Stop
cs3Label=result cs3=N\/A cs4Label=reason cs4=None msg=XDR
service cyserver was stopped on Test-Agent tenantname=Test
tenantCDLid=123456 CSPaccountname=1234
Management Audit Log Noficaon Format

Cortex XDR forwards the management audit log to external data sources according to the
following formats.
Email Account
Management audit log noficaons are forward to email accounts.
Syslog Server
Management Audit logs forwarded to a Syslog server are sent in a CEF format RF 5425 according
to the following mapping:
Log Forwarding
Syslog Header
<9>: PRI (considered a prioirty field)1: ver
sion number2020-03-22T07:55:07.964311Z: time
stamp of when alert/log was sentcortexxdr: h
ost name
CEF Header
HEADER/Vendor="Palo Alto Networks" (as a con
stant string)HEADER/Device Product="Cortex X
DR" (as a constant string)HEADER/Device Vers
ion= Cortex XDR version (2.0/2.1....)HEADER/
HEADER/Severity=(integer/0 - Unknown, 6 - Lo
w, 8 - Medium, 9 - High)HEADER/Device Event
Class ID="Management Audit Logs" (as a const
ant string)HEADER/name = type
CEF Body
suser=user end=timestamp externalId=external
_id cs1Label=email (constant string) cs1=use
r_mail cs2Label=subtype (constant string) cs
2=subtype cs3Label=result (constant string)
cs3=result cs4Label=reason (constant string)
cs4=reason msg=event_description tenantname
=tenant_name tenantCDLid=tenant_id CSPaccoun
tname=csp_id
Example
3/18/2012:05:17.567 PM<14>1 2020-03-18T12:05:17.567590Z cortexxdr

- - - CEF:0|Palo Alto Networks|Cortex XDR|Cortex XDR x.x |
Management Audit Logs|REPORTING|6|suser=test end=1584533117501
externalId=5820 cs1Label=email 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
Cortex XDR Log Format for IOC and BIOC Alerts

Cortex XDR logs its IOC and BIOC alerts to the Cortex XDR tenant. If you configure Cortex XDR
to forward logs in legacy format, when alert logs are forwarded from the Cortex XDR tenant, each
log record has the following format.
Syslog format:
"/edrData/action_country","/edrData/action_download","/edrData/
action_external_hostname","/edrData/action_external_port","/
edrData/action_file_extension","/edrData/action_file_md5","/
Log Forwarding
edrData/action_file_name","/edrData/action_file_path","/
edrData/action_file_previous_file_extension","/
edrData/action_file_previous_file_name","/edrData/
action_file_previous_file_path","/edrData/action_file_sha256","/
edrData/action_file_size","/edrData/action_file_remote_ip","/edrData/
action_file_remote_port","/edrData/action_is_injected_thread","/
edrData/action_local_ip","/edrData/action_local_port","/
edrData/action_module_base_address","/edrData/
action_module_image_size","/edrData/action_module_is_remote","/
edrData/action_module_is_replay","/edrData/action_module_path","/
edrData/action_module_process_causality_id","/
edrData/action_module_process_image_command_line","/
edrData/action_module_process_image_extension","/
edrData/action_module_process_image_md5","/edrData/
action_module_process_image_name","/edrData/
action_module_process_image_path","/edrData/
action_module_process_image_sha256","/edrData/
action_module_process_instance_id","/edrData/
action_module_process_is_causality_root","/
edrData/action_module_process_os_pid","/edrData/
action_module_process_signature_product","/
edrData/action_module_process_signature_status","/
edrData/action_module_process_signature_vendor","/
edrData/action_network_connection_id","/edrData/
action_network_creation_time","/edrData/action_network_is_ipv6","/
edrData/action_process_causality_id","/edrData/
action_process_image_command_line","/edrData/
action_process_image_extension","/edrData/
action_process_image_md5","/edrData/action_process_image_name","/
edrData/action_process_image_path","/edrData/
action_process_image_sha256","/edrData/action_process_instance_id","/
edrData/action_process_integrity_level","/
edrData/action_process_is_causality_root","/
edrData/action_process_is_replay","/edrData/
action_process_is_special","/edrData/action_process_os_pid","/
edrData/action_process_signature_product","/
edrData/action_process_signature_status","/edrData/
action_process_signature_vendor","/edrData/action_proxy","/edrData/
action_registry_data","/edrData/action_registry_file_path","/edrData/
action_registry_key_name","/edrData/action_registry_value_name","/
edrData/action_registry_value_type","/edrData/
action_remote_ip","/edrData/action_remote_port","/
edrData/action_remote_process_causality_id","/
edrData/action_remote_process_image_command_line","/
edrData/action_remote_process_image_extension","/
edrData/action_remote_process_image_md5","/
edrData/action_remote_process_image_name","/
edrData/action_remote_process_image_path","/
edrData/action_remote_process_image_sha256","/
edrData/action_remote_process_is_causality_root","/
edrData/action_remote_process_os_pid","/edrData/
action_remote_process_signature_product","/
edrData/action_remote_process_signature_status","/
edrData/action_remote_process_signature_vendor","/
edrData/action_remote_process_thread_id","/edrData/
action_remote_process_thread_start_address","/edrData/
Log Forwarding
action_thread_thread_id","/edrData/action_total_download","/
edrData/action_total_upload","/edrData/action_upload","/edrData/
action_user_status","/edrData/action_username","/edrData/
actor_causality_id","/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/actor_process_image_path","/edrData/
actor_process_image_sha256","/edrData/actor_process_instance_id","/
edrData/actor_process_integrity_level","/edrData/
actor_process_is_special","/edrData/actor_process_os_pid","/
edrData/actor_process_signature_product","/
edrData/actor_process_signature_status","/edrData/
actor_process_signature_vendor","/edrData/actor_thread_thread_id","/
edrData/agent_content_version","/edrData/agent_host_boot_time","/
edrData/agent_hostname","/edrData/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_username","/edrData/
causality_actor_primary_user_sid","/edrData/
causality_actor_primary_username","/edrData/
causality_actor_process_causality_id","/edrData/
causality_actor_process_command_line","/edrData/
causality_actor_process_execution_time","/edrData/
causality_actor_process_image_command_line","/
edrData/causality_actor_process_image_extension","/
edrData/causality_actor_process_image_md5","/
edrData/causality_actor_process_image_name","/
edrData/causality_actor_process_image_path","/
edrData/causality_actor_process_image_sha256","/
edrData/causality_actor_process_instance_id","/
edrData/causality_actor_process_integrity_level","/
edrData/causality_actor_process_is_special","/
edrData/causality_actor_process_os_pid","/edrData/
causality_actor_process_signature_product","/edrData/
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_hostname","/edrData/
missing_action_remote_process_instance_id","/facility","/
generatedTime","/recordType","/recsize","/trapsId","/uuid","/
xdr_unique_id","/meta_internal_id","/external_id","/is_visible","/
is_secdo_event","/severity","/alert_source","/internal_id","/
matching_status","/local_insert_ts","/source_insert_ts","/
alert_name","/alert_category","/alert_description","/
bioc_indicator","/matching_service_rule_id","/external_url","/
Log Forwarding
xdr_sub_type","/bioc_category_enum_key","/alert_action_status","/
agent_data_collection_status","/attempt_counter","/case_id","/
global_content_version_id","/global_rule_id","/is_whitelisted"
When alert logs are forwarded by email, each field is labeled, one line per field.
Email body format example.
edrData/action_country:
edrData/action_download:
edrData/action_external_hostname:
edrData/action_external_port:
edrData/action_file_extension: pdf
edrData/action_file_md5: null
edrData/action_file_name: XORXOR2614081980.pdf
edrData/action_file_path: C:\ProgramData\Cyvera\Ransomware
\16067987696371268494\XORXOR2614081980.pdf
edrData/action_file_previous_file_extension: null
edrData/action_file_previous_file_name: null
edrData/action_file_previous_file_path: null
edrData/action_file_sha256: null
edrData/action_file_size: 0
edrData/action_file_remote_ip: null
edrData/action_file_remote_port: null
edrData/action_is_injected_thread:
edrData/action_local_ip:
edrData/action_local_port:
edrData/action_module_base_address:
edrData/action_module_image_size:
edrData/action_module_is_remote:
edrData/action_module_is_replay:
edrData/action_module_path:
edrData/action_module_process_causality_id:
edrData/action_module_process_image_command_line:
edrData/action_module_process_image_extension:
edrData/action_module_process_image_md5:
edrData/action_module_process_image_name:
edrData/action_module_process_image_path:
edrData/action_module_process_image_sha256:
edrData/action_module_process_instance_id:
edrData/action_module_process_is_causality_root:
edrData/action_module_process_os_pid:
edrData/action_module_process_signature_product:
edrData/action_module_process_signature_status:
edrData/action_module_process_signature_vendor:
edrData/action_network_connection_id:
edrData/action_network_creation_time:
edrData/action_network_is_ipv6:
edrData/action_process_causality_id:
edrData/action_process_image_command_line:
edrData/action_process_image_extension:
edrData/action_process_image_md5:
edrData/action_process_image_name:
edrData/action_process_image_path:
edrData/action_process_image_sha256:
edrData/action_process_instance_id:
Log Forwarding
edrData/action_process_integrity_level:
edrData/action_process_is_causality_root:
edrData/action_process_is_replay:
edrData/action_process_is_special:
edrData/action_process_os_pid:
edrData/action_process_signature_product:
edrData/action_process_signature_status:
edrData/action_process_signature_vendor:
edrData/action_proxy:
edrData/action_registry_data:
edrData/action_registry_file_path:
edrData/action_registry_key_name:
edrData/action_registry_value_name:
edrData/action_registry_value_type:
edrData/action_remote_ip:
edrData/action_remote_port:
edrData/action_remote_process_causality_id:
edrData/action_remote_process_image_command_line:
edrData/action_remote_process_image_extension:
edrData/action_remote_process_image_md5:
edrData/action_remote_process_image_name:
edrData/action_remote_process_image_path:
edrData/action_remote_process_image_sha256:
edrData/action_remote_process_is_causality_root:
edrData/action_remote_process_os_pid:
edrData/action_remote_process_signature_product:
edrData/action_remote_process_signature_status:
edrData/action_remote_process_signature_vendor:
edrData/action_remote_process_thread_id:
edrData/action_remote_process_thread_start_address:
edrData/action_thread_thread_id:
edrData/action_total_download:
edrData/action_total_upload:
edrData/action_upload:
edrData/action_user_status:
edrData/action_username:
edrData/actor_causality_id: AdUcamNT99kAAAAEAAAAAA==
edrData/actor_effective_user_sid: S-1-5-18
edrData/actor_effective_username: NT AUTHORITY\SYSTEM
edrData/actor_is_injected_thread: false
edrData/actor_primary_user_sid: S-1-5-18
edrData/actor_primary_username: NT AUTHORITY\SYSTEM
edrData/actor_process_causality_id: AdUcamNT99kAAAAEAAAAAA==
edrData/actor_process_command_line:
edrData/actor_process_execution_time: 1559827133585
edrData/actor_process_image_command_line:
edrData/actor_process_image_extension:
edrData/actor_process_image_md5:
edrData/actor_process_image_name: System
edrData/actor_process_image_path: System
edrData/actor_process_image_sha256:
edrData/actor_process_instance_id: AdUcamNT99kAAAAEAAAAAA==
edrData/actor_process_integrity_level: 16384
edrData/actor_process_is_special: 1
edrData/actor_process_os_pid: 4
edrData/actor_process_signature_product: Microsoft Windows
Log Forwarding
edrData/actor_process_signature_status: 1
edrData/actor_process_signature_vendor: Microsoft Corporation
edrData/actor_thread_thread_id: 64
edrData/agent_content_version: 58-9124
edrData/agent_host_boot_time: 1559827133585
edrData/agent_hostname: padme-7
edrData/agent_id: a832f35013f16a06fc2495843674a3e9
edrData/agent_ip_addresses: ["10.196.172.74"]
edrData/agent_is_vdi: false
edrData/agent_os_sub_type: Windows 7 [6.1 (Build 7601: Service Pack
1)]
edrData/agent_os_type: 1
edrData/agent_session_start_time: 1559827592661
edrData/agent_version: 6.1.0.13895
edrData/causality_actor_causality_id: AdUcamNT99kAAAAEAAAAAA==
edrData/causality_actor_effective_user_sid:
edrData/causality_actor_effective_username:
edrData/causality_actor_primary_user_sid: S-1-5-18
edrData/causality_actor_primary_username: NT AUTHORITY\SYSTEM
edrData/causality_actor_process_causality_id:
edrData/causality_actor_process_command_line:
edrData/causality_actor_process_execution_time: 1559827133585
edrData/causality_actor_process_image_command_line:
edrData/causality_actor_process_image_extension:
edrData/causality_actor_process_image_md5:
edrData/causality_actor_process_image_name: System
edrData/causality_actor_process_image_path: System
edrData/causality_actor_process_image_sha256:
edrData/causality_actor_process_instance_id: AdUcamNT99kAAAAEAAAAAA==
edrData/causality_actor_process_integrity_level: 16384
edrData/causality_actor_process_is_special: 1
edrData/causality_actor_process_os_pid: 4
edrData/causality_actor_process_signature_product: Microsoft Windows
edrData/causality_actor_process_signature_status: 1
edrData/causality_actor_process_signature_vendor: Microsoft
Corporation
edrData/event_id: AAABa13u2PQsqXnCAB1qjw==
edrData/event_is_simulated: false
edrData/event_sub_type: 1
edrData/event_timestamp: 1560649063308
edrData/event_type: 3
edrData/event_utc_diff_minutes: 120
edrData/event_version: 20
edrData/host_metadata_hostname:
edrData/missing_action_remote_process_instance_id:
facility:
generatedTime: 2019-06-16T01:37:43
recordType: alert
recsize:
trapsId:
uuid:
xdr_unique_id: ae65c92c6e704023df129c728eab3d3e
meta_internal_id: None
external_id: 318b7f91-ae74-4860-abd1-b463e8cd6deb
is_visible: null
is_secdo_event: null
Log Forwarding
severity: SEV_010_INFO
alert_source: BIOC
internal_id: None
matching_status: null
local_insert_ts: null
source_insert_ts: 1560649063308
alert_name: BIOC-16
alert_category: CREDENTIAL_ACCESS
alert_description: File action type = all AND name = *.pdf
bioc_indicator:
"[{""pretty_name"":""File"",""data_type"":null,""render_type"":""entity"",
""entity_map"":null},{""pretty_name"":""action
type"",""data_type"":null,
""render_type"":""attribute"",""entity_map"":null},
{""pretty_name"":""="",
""data_type"":null,""render_type"":""operator"",""entity_map"":null},
{""pretty_name"":""all"",""data_type"":null,""render_type"":""value"",
""entity_map"":null},{""pretty_name"":""AND"",""data_type"":null,
""render_type"":""connector"",""entity_map"":null},
{""pretty_name"":""name"",""data_type"":""TEXT"",
""render_type"":""attribute"",""entity_map"":""attributes""},
{""pretty_name"":""="",""data_type"":null,""render_type"":""operator"",
""entity_map"":""attributes""},{""pretty_name"":""*.pdf"",
""data_type"":null,""render_type"":""value"",
""entity_map"":""attributes""}]"
matching_service_rule_id: 200
external_url: null
xdr_sub_type: BIOC - Credential Access
bioc_category_enum_key: null
alert_action_status: null
agent_data_collection_status: null
attempt_counter: null
case_id: null
global_content_version_id:
global_rule_id:
is_whitelisted: false
The following table summarizes the field prefixes and addional relevant fields available for BIOC
and IOC alert logs.
Field Name Definion
/edrData/acon_file* Fields that begin with this prefix describe

aributes of a file for which Traps reported
acvity.
edrData/acon_module* Fields that begin with this prefix describe

aributes of a module for which Traps reported
module loading acvity.
edrData/acon_module_process* Fields that begin with this prefix describe

aributes and acvity related to processes
Log Forwarding

reported by Traps that load modules such as
DLLs on the endpoint.
edrData/acon_process_image* Fields that begin with this prefix describe

aributes of a process image for which Traps
reported acvity.
edrData/acon_registry* Fields that begin with this prefix describe

registry acvity and aributes such as key
name, data, and previous value for which Traps
reported acvity.
edrData/acon_network Fields that begin with this prefix describe

network aributes for which Traps reported
acvity.
edrData/acon_remote_process* Fields that begin with this prefix describe

aributes of remote processes for which Traps
reported acvity.
edrData/actor* Fields that begin with this prefix describe

aributes about the acng user that iniated
the acvity on the endpoint.
edrData/agent* Fields that begin with this prefix describe

aributes about the Traps agent deployed on
the endpoint.
edrData/causality_actor* Fields that begin with this prefix describe

aributes about the causality group owner.
Addional useful fields:
/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 me when Cortex XDR –

Invesgaon and Response ingested the app.
Log Forwarding
/source_insert_ts Date and me the alert was reported by the

alert source.
/alert_name If the alert was generated by Cortex XDR –

Invesgaon 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_descripon Text summary of the event including the alert

source, alert name, severity, and file path. For
alerts triggered by BIOC and IOC rules, Cortex
Log Forwarding

XDR displays detailed informaon about the
rule.
/bioc_indicator A JSON representaon of the rule

characteriscs. For example:
[{""pretty_name"":""File"",""dat
a_type"":null,
""render_type"":""entity"",""ent
ity_map"":null},
{""pretty_name"":""action type""
,
""data_type"":null,""render_type
"":""attribute"",
""entity_map"":null},{""pretty_n
ame"":""="",
"":""operator"",
ame"":""all"",
"":""value"",
ame"":""AND"",
"":""connector"",
ame"":""name"",
""data_type"":""TEXT"",
""render_type"":""attribute"",
""entity_map"":""attributes""},
{""pretty_name"":""="",""data_ty
pe"":null,
""render_type"":""operator"",
""entity_map"":""attributes""},
{""pretty_name"":""*.pdf"",""dat
a_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_acon_status Acon taken by the alert sensor with acon

status displayed in parenthesis:
• Detected
• Detected (Download)
Log Forwarding

• Detected (Post Detected)
• Detected (Prompt Allow)
• Detected (Reported)
• Detected (Scanned)
• Prevented (Blocked)
• Prevented (Prompt Block)
/case_id Unique idenfier for the incident.
/global_content_version_id Unique idenfier for the content version in

which a Palo Alto Networks global BIOC rule
was released.
/global_rule_id Unique idenfier for an alert triggered by a

Palo Alto Networks global BIOC rule.
/is_whitelisted Boolean indicang whether the alert is

excluded or not.
Cortex XDR Analycs Log Format

Cortex XDR Analycs logs its alerts to the Cortex XDR tenant as analycs alert logs. If you
configure Cortex XDR to forward logs in legacy format, each log record has the following format.
Syslog format
sub_type,time_generated,id,version_info/
document_version,version_info/magnifier_version,version_info/
detection_version,alert/url,alert/category,alert/
type,alert/name,alert/description/html,alert/description/
text,alert/severity,alert/state,alert/is_whitelisted,alert/
ports,alert/internal_destinations/single_destinations,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,device/mac,device/
hostname,device/ip,device/ip_ranges,device/owner,device/
org_unit,files
Email body format example.

When analycs alert logs are forwarded by email, each field is labeled, one line per field.
sub_type: Update
time_generated: 1547717480
id: 4
version_info/document_version: 1
Log Forwarding
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 ...
alert/severity: Low
alert/state: Reopened
alert/is_whitelisted: false
alert/ports: "[1,2,3,4,5,6,7,8,9,10,11...]
alert/internal_destinations/single_destinations: []
alert/internal_destinations/ip_ranges:
"[{""max_ip"":""..."",""name"":""..."",""min_ip"":""...""}]"
alert/external_destinations: []
alert/app_id:
alert/schedule/activity_first_seen_at: 1542178800
alert/schedule/activity_last_seen_at: 1542182400
alert/schedule/first_detected_at: 1542182400
alert/schedule/last_detected_at: 1542182400
user/user_name:
user/url:
user/display_name:
user/org_unit:
device/id: 2-85e40edd-b2d1-1f25-2c1e-a3dd576c8a7e
device/url: https:\/\/ddc1 ...
device/mac: 00-50-56-a5-db-b2
device/hostname: DC1ENV3APC42
device/ip: 10.201.102.17
device/ip_ranges:
"[{""max_ip"":""..."",""name"":""..."",""min_ip"":""..."",""asset"":""""}]"
device/owner:
device/org_unit:
files: []
The following table describes each field.
sub_type Alert log subtype. Values are:

• New—First log record for the alert with this
record id.
• Update—Log record idenfies 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 mestamp.
Log Forwarding
id Unique idenfier for the alert. Any given alert

can generate mulple log records—one when
the alert is inially raised, and then addional
records every me 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 mestamp.
version_info/document_version Idenfies the log schema version number used

for this log record.
version_info/magnifier_version The version number of the Cortex XDR –

Analycs instance that wrote this log record.
version_info/detection_version Idenfies the version of the Cortex XDR –

Analycs detecon soware used to raise the
alert.
alert/url Provides the full URL to the alert page in the

Cortex XDR – Analycs user interface.
alert/category Idenfies the alert category, which is a

reflecon of the anomalous network acvity
locaon in the aack life cycle. Possible
categories are:
• C&C—The network acvity is possibly the
result of malware aempng 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 acvity is indicave
of an aacker who is aempng 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 acvity that is indicave
of automated malicious traffic generaon.
Log Forwarding

• Recon—The network acvity is indicave
an aacker that is exploring the network for
endpoints and other resources to aack.
alert/type Idenfies the categorizaon to which the

alert belongs. For example Tunneling Process,
Sandbox Detecon, Malware, and so forth.
alert/name The alert name as it appears in the Cortex

XDR – Analycs user interface.
alert/description/html The alert textual descripon in HTML

formang.
alert/description/text The alert textual descripon in plain text.
alert/severity Idenfies the alert severity. These severies

indicate the likelihood that the anomalous
network acvity is a real aack.
• High—The alert is confirmed to be a
network aack.
• Medium—The alert is suspicious enough to
require addional invesgaon.
• Low—The alert is unverified. Whether the
alert is indicave of a network aack is
unknown.
alert/state Idenfies the alert state.

• Open—The alert is currently acve and
should be undergoing triage or invesgaon
by the network security analysts.
• Reopened—The alert was previously
resolved or dismissed, but new network
acvity has caused Cortex XDR – Analycs
to reopen the alert.
• Archived—No acon was taken on the
alert in the Cortex XDR – Analycs user
interface, and no further network acvity
has occurred that caused it to remain acve.
• Resolved—Network personnel have taken
enough acon to end the aack.
Log Forwarding

• Dismissed—The anomaly has been
examined and deemed to be normal,
sanconed, network acvity.
alert/is_whitelisted Indicates whether the alert is whitelisted.

Whitelisng indicates that anomalous-
appearing network acvity is legimate. If an
alert is whitelisted, then it is not visible in the
Cortex XDR Analycs user interface. Alerts
can be dismissed or archived and sll have a
whitelist rule.
alert/ports List of ports accessed by the network enty

during its anomalous behavior.
alert/internal_destinations/ Network desnaons that the enty reached,

single_destinations or tried to reach, during the course of the
network acvity that caused Cortex XDR –
Analycs to raise the alert. This field contains
a sequence of JSON objects, each of which
contains the following fields:
• ip—The desnaon IP address.
• name—The desnaon name (for example, a
host name).
alert/internal_destinations/ IP address range subnets that the enty

ip_ranges reached, or tried to reach, during the course of
the network acvity that caused Cortex XDR –
Analycs 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 desnaons external to the

monitored network that the enty tried to
reach, or actually reached, during the acvity
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/ Time when Cortex XDR – Analycs first

activity_first_seen_at detected the network acvity that caused
Log Forwarding

it to raise the alert. Be aware that there is
frequently a delay between this mestamp,
and the me when Cortex XDR – Analycs
raises an alert (see the alert/schedule/
first_detected_at field).
alert/schedule/ Time when Cortex XDR – Analycs last

activity_last_seen_at detected the network acvity that caused it to
raise the alert.
alert/schedule/first_detected_at Time when Cortex XDR – Analycs first alerted

on the network acvity.
alert/schedule/last_detected_at Time when Cortex XDR – Analycs last alerted

on the network acvity.
user/user_name The name of the user associated with this alert.

This name is obtained from Acve Directory.
user/url Provides the full URL to the user page in the

Cortex XDR – Analycs user interface for the
user who is associated with the alert.
user/display_name The user name as retrieved from Acve

Directory. This is the user name displayed
within the Cortex XDR – Analycs user
interface for the user who is associated with
this alert.
user/org_unit The organizaonal unit of the user associated

with this alert, as idenfied using Acve
Directory.
device/id A unique ID assigned by Cortex XDR –

Analycs to the device. All alerts raised due to
acvity occurring on this endpoint will share
this ID.
device/url Provides the full URL to the device page in the

Cortex XDR – Analycs 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.
Log Forwarding
device/ip_ranges Idenfies the subnet or subnets that the

device is on. This sequence can contain
mulple 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
Analycs 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 organizaonal unit that owns the device,

as idenfied by Acve Directory.
files Idenfies 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.
Cortex XDR Log Formats

The following topics list the fields of each Cortex XDR log type that the Cortex XDR tenant can
forward to an external server or email desnaon.
With log forwarding to a syslog receiver, the Cortex XDR tenant sends logs in the IETF syslog
message format defined in RFC 5425. To facilitate parsing, the delimiter is a comma and each field
is a comma-separated value (CSV) string.
The FUTURE_USE tag applies to fields that Cortex XDR does not currently implement.
With log forwarding to an email desnaon, the Cortex XDR tenant sends an email with each field
on a separate line in the email body.
• Threat Logs
• Config Logs
• Analycs Logs
• System Logs
Log Forwarding
Threat Logs
Syslog format: recordType, class, FUTURE_USE, eventType, generatedTime, serverTime,
agentTime, tzOffset, FUTURE_USE, facility, customerId, trapsId, serverHost,
serverComponentVersion, regionId, isEndpoint, agentId, osType, isVdi, osVersion, is64,
agentIp, deviceName, deviceDomain, severity, trapsSeverity, agentVersion, contentVersion,
proteconStatus, prevenonKey, moduleId, profile, moduleStatusId, verdict, prevenonMode,
terminate, terminateTarget, quaranne, block, postDetected, eventParameters(Array),
sourceProcessIdx(Array), targetProcessIdx(Array), fileIdx(Array), processes(Array), files(Array),
users(Array), urls(Array), descripon(Array)
Email body format example:
recordType: threat
messageData/class: threat
messageData/subClass:
eventType: AgentSecurityEvent
generatedTime: 2019-01-29T05:07:58.045-08:00
serverTime: 2018-07-02T20:01:39.591Z
endPointHeader/agentTime: 2018-07-02T20:01:03Z
endPointHeader/tzOffset: 180
product:
facility: TrapsAgent
customerId: 245143
trapsId: mac510a2monday-01
serverHost: coreop-qaauta-2606-0-112132729246-266
serverComponentVersion: 2.0.2
regionId: 70
isEndpoint: 1
agentId: dc3af3198f172048082c21ff0956866b
endPointHeader/osType: 2
endPointHeader/isVdi: 0
endPointHeader/osVersion: 10.11.6
endPointHeader/is64: 1
endPointHeader/agentIp: 10.200.37.201
endPointHeader/deviceName: A1260700MC1011
endPointHeader/deviceDomain:
severity: emergency
messageData/trapsSeverity: medium
endPointHeader/agentVersion: 5.1.0.1401
endPointHeader/contentVersion: 26-3625
endPointHeader/protectionStatus: 0
messageData/preventionKey: 9a94965188d2455486dd8d60cf4b3849
messageData/moduleId: COMPONENT_EPM_J01
messageData/profile: ExploitModules
messageData/moduleStatusId: CYSTATUS_JIT_EXCEPTION
messageData/verdict:
messageData/preventionMode: blocked
messageData/terminate: 1
messageData/terminateTarget:
quarantine:
messageData/block: 0
messageData/postDetected: 0
messageData/eventParameters: "[""/Users/administrator/Desktop/JitMac/
j01_test"",""711046b89e2f2c70cdbb41f615c54bd1b4270ecbbb176edeb1bb4fe4619""]"
Log Forwarding
messageData/sourceProcessIdx: 0
messageData/targetProcessIdx: -1
messageData/fileIdx: 0
messageData/processes: "[{""exeFileIdx"":0,""commandLine"":""/
Users/Administrator/Desktop/JitMac/j01_test test=system
depth=1"",""userIdx"":0,""pid"":1359,""parentId"":452}]"
messageData/files:
"[{""sha256"":""711046b89e2f2c70cdbb41f615c54bd1b4270ecbbb176edeb1bb4654619"",
""rawFullPath"":""/Users/administrator/Desktop/JitMac/
j01_test"",""signers"":[""N/A""],""fileName"":""j01_test""}]"
messageData/users: "[{""userName"":""Administrator""}]"
messageData/urls: []
messageData/description: Memory Corruption Exploit
Field Name Descripon
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: AgentAconReport,

AgentDeviceControlViolaon,
AgentGenericMessage, AgentSamReport,
AgentScanReport, AgentSecurityEvent,
AgentStascs, AgentTimelineEvent,
ServerLogPerAgent, ServerLogPerTenant, or
ServerLogSystem.
generatedTime Coordinated Universal Time (UTC) equivalent

of the me at which an event was logged.
For agent events, this represents the me on
the endpoint. For policy, configuraon, and
system events, this represents the me on
Cortex XDR in ISO-8601 string representaon
(for example, 2017-01-24T09:08:59Z).
serverTime Coordinated Universal Time (UTC) equivalent

of the me at which the server generated
the log. If the log was generated on an
endpoint, this field idenfies the me
the server received the log in ISO-8601
string representaon (for example,
2017-01-24T09:08:59Z).
Log Forwarding
agentTime Coordinated Universal Time (UTC) equivalent

of the me at which an agent logged an event
in ISO-8601 string representaon.
tzOffset Effecve endpoint me zone offset from UTC,

in minutes.
facility The Cortex XDR system component that

iniated the event, for example: TrapsAgent,
TrapsServiceCore, TrapsServiceManagement,
and TrapsServiceBackend.
customerId The ID that uniquely idenfies the Cortex

XDR tenant instance which received this log
record.
trapsId Tenant external ID.
serverHost Hostname of Cortex XDR.
serverComponentVersion Soware 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 idenfier for the Cortex XDR agent.
osType Operang 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
Log Forwarding
osVersion Full version number of the operang 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—Crical. Used for events that require
immediate aenon.
• 3—Error. Used for events that require
special handling.
• 4—Warning. Used for events that
somemes require special handling.
• 5—Noce. Used for normal but significant
events that can require aenon.
• 6—Informaonal. Informaonal events that
do not require aenon.
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
severies corresponds to a syslog severity
level:
• 0—Informaonal. Informaonal messages
that do not require aenon. Idencal to
the syslog 6 (Informaonal) severity level.
• 1—Low. Used for normal but significant
Log Forwarding

Corresponds to the syslog 5 (Noce)
severity level.
• 2—Medium. Used for events that
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.
immediate aenon. Corresponds to the
syslog 2 (Crical) severity level.
See also the severity log field.
agentVersion Version of the Cortex XDR agent.
contentVersion Content version in the local security policy.
proteconStatus Cortex XDR agent protecon status:

• 0—Protected
• 1—OsVersionIncompable
• 2—AgentIncompable
prevenonKey Unique idenfier for security events.
moduleId Security module name.
profile Name of the security profile that triggered the

event.
moduleStatusId Idenfies the specific component of Cortex

XDR modules.
• 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
Log Forwarding

• 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
• CYSTATUS_HOOKING_ENTRY_POINT_FAILED
• CYSTATUS_HOTPATCH_HIJACKING
• CYSTATUS_ILLEGAL_EXECUTABLE
• CYSTATUS_ILLEGAL_UNSIGNED_EXECUTABLE
Log Forwarding

• 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
Log Forwarding

• CYSTATUS_RESTORE_FAILED
• CYSTATUS_RESTORE_SUCCEEDED
• CYSTATUS_ROP_MITIGATION
• CYSTATUS_SEH_CRITICAL
• CYSTATUS_SEH_INF_CRITICAL
• CYSTATUS_SHELL_CODE_TRAP_CALLED
• CYSTATUS_STACK_OVERFLOW
• CYSTATUS_SUSPENDED_PROCESS_BLOCKED
• CYSTATUS_SUSPICIOUS_APC
• CYSTATUS_SUSPICIOUS_LINK_FILE
• CYSTATUS_SYSTEM_SCAN_FINISHED
• CYSTATUS_SYSTEM_SCAN_STARTED
• CYSTATUS_THREAD_INJECTION
• CYSTATUS_TLA_MODEL_NOT_LOADED
• CYSTATUS_TOKEN_THEFT_FILE_OPERATION
• CYSTATUS_TOKEN_THEFT_PROCESS_CREATED
• CYSTATUS_TOKEN_THEFT_REGISTRY_OPERATION
• CYSTATUS_TOKEN_THEFT_THREAD_CREATED
• CYSTATUS_TOKEN_THEFT_THREAD_INJECTED
• CYSTATUS_TOKEN_THEFT_THREAD_STARTED
• CYSTATUS_UASLR_CRITICAL
• CYSTATUS_UNALLOWED_CODE_SEGMENT
• CYSTATUS_UNAUTHORIZED_CALL_TO_SYSTEM_SERVI
• 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
Log Forwarding
prevenonMode Acon carried out by the Cortex XDR agent

(block or nofy). The prevenon mode is
specified in the rule configuraon.
terminate Terminaon acon taken on the file.

• 0—Cortex XDR did not terminate the file.
• 1—Cortex XDR terminated the file.
terminateTarget Terminaon acon taken on the target file

(relevant for some child process execuon
events where we terminate the child process
but not the parent process):
• 0—Target file was not terminated.
• 1—Target file was terminated.
quaranne Quaranne acon taken on the file:

• 0—File was not quaranned.
• 1—File was quaranned.
block Block acon taken on the file:

• 0—File was not blocked
• 1—File was blocked.
postDetected Post detecon status of the file:

• 0—Inial prevenon.
• 1—Detected aer an inial execuon.
eventParameters(Array) Parameters associated with the type of event.

For example, username, endpoint hostname,
and filename.
sourceProcessIdx(Array) The prevenon source process index in the

processes array.
targetProcessIdx(Array) Target process index in the processes array. A

missing or negave 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.
Log Forwarding
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—Descripon field of the VERSIONINFO
resource
• 6—File version field of the VERSIONINFO
resource
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 Cortex XDR
agent
• 8—UTC file creaon me
• 9—UTC file modificaon me
• 10—UTC file access me
• 11—File aributes bitmask
• 12—File size in bytes
• 13—Signer field of the code signing
cerficate
users(Array) Details about the acve user on the endpoint

when the event occurred:
• 1—Username of the acve user on the
endpoint.
• 2—Domain to which the user account
belongs.
Log Forwarding
urls(Array) Addional 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 hp\s only)
• 7—Fragment parameters (for hp\s only)
descripon(Array) (Mac only) Descripon of components related

to Cortex XDR. For example, the descripon
of the ROP, JIT, Dylib hijacking modules for
Mac endpoints is Memory Corrupon Exploit.
Config Logs
Syslog format: recordType, class, FUTURE_USE, subClassId, eventType, eventCategory,
generatedTime, serverTime, FUTURE_USE, facility, customerId, trapsId, serverHost,
serverComponentVersion, regionId, isEndpoint, severity, trapsSeverity, messageCode,
friendlyName, FUTURE_USE, msgTextEn, userFullName, userName, userRole, userDomain,
addionalData(Array), messageCode, errorText, errorData, resultData
recordType: system
messageData/class: system
messageData/subClass: Provisioning
messageData/subClassId: 13
eventType: ServerLogPerTenant
messageData/eventCategory: tenant
generatedTime: 2019-01-31T18:15:19.000000+00:00
serverTime: 2019-01-31T18:15:19.000000+00:00
product:
facility: TrapsServerManagement
customerId: 004403511
trapsId: 18520498190303952
serverHost: 14917869646-201.proda.brz
serverComponentVersion: 2.0.9+624
regionId:
isEndpoint: 0
agentId:
severity: notice
messageData/trapsSeverity: informational
messageData/messageCode: 19015
messageData/friendlyName: User Login
Log Forwarding
messageData/msgTextLoc:
messageData/msgTextEn: User username@paloaltonetworks.com has logged
in with role superadmin
endPointHeader/userFullName:
endPointHeader/username:
endPointHeader/userRole:
endPointHeader/userDomain:
endPointHeader/agentTime:
endPointHeader/tzOffset:
endPointHeader/osType:
endPointHeader/isVdi:
endPointHeader/osVersion:
endPointHeader/is64:
endPointHeader/agentIp:
endPointHeader/deviceName:
endPointHeader/agentVersion:
endPointHeader/contentVersion:
endPointHeader/protectionStatus:
messageData/userFullName:
messageData/username:
messageData/userRole:
messageData/userDomain:
messageData/messageName:
messageData/messageId:
messageData/processStatus:
messageData/errorText:
messageData/errorData:
messageData/resultData:
messageData/parameters:
messageData/additionalData: {}

quotas. In this case, the record type is config
which includes logs related to Cortex XDR
administraon and configuraon 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 representaon of the subClass field

for easy sorng and filtering.
eventType Subtype of event.
Log Forwarding
eventCategory Category of event, used internally for

processing the flow of logs. Event categories
vary by class:
• config—deviceManagement,
distribuonManagement,
reportManagement,
securityEventManagement,
systemManagement
• policy—exceponManagement,
policyManagement, profileManagement,
sam
• system—licensing, provisioning, tenant,
userAuthencaon, workerProcessing
• agent_log—agentFlow

(for example, 2017-01-24T09:08:59Z).

2017-01-24T09:08:59Z).


record.
Log Forwarding


endpoint.

event.
special handling.
details.

level:
severity level.
Log Forwarding

severity level.
messageCode System-wide unique message code.
friendlyName Descripve log message name.
msgTextEn Descripon 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.


in minutes.

• 1—Windows
• 2—OS X/macOS
• 3—Android
• 4—Linux

Log Forwarding

6.1.7601.19135.

architecture
architecture

was logged.

• 0—Protected
userFullName Full name of Cortex XDR user.
messageName Name of the message.
messageId Unique numeric idenfier of the message.
processStatus State of the process related to the event.
errorText If known, a descripon of the documented

error.
errorData Parameters related to an event error.
Log Forwarding
resultData Parameters related to a successful event.
parameters Parameters supplied in the log message.
addionalData(Array) Addional informaon regarding event

parameters.
loggedInUser User that is logged in to the Cortex XDR.
Analycs Logs
Syslog format: recordType, class, FUTURE_USE, eventType, eventCategory, generatedTime,
serverTime, agentTime, tzOffset, FUTURE_USE, facility, customerId, trapsId, serverHost,
serverComponentVersion, regionId, isEndpoint, agentId, osType, isVdi, osVersion, is64, agentIp,
deviceName, deviceDomain, severity, agentVersion, contentVersion, proteconStatus, sha256,
type, parentSha256, lastSeen, fileName, filePath, fileSize, localAnalysisResult, reported, blocked,
execuonCount
recordType: analytics
messageData/class: agent_data
eventType: AgentTimelineEvent
messageData/eventCategory: hash
generatedTime: 2019-01-31T18:00:43Z
serverTime: 2019-01-31T18:59:46.586Z
endPointHeader/tzOffset: -480
product:
trapsId: 18520039498190352
serverHost: coreop-f-proda-mnmauto03930348053-311.proda.brz
regionId: 10
isEndpoint: 1
agentId: 3bcf7e5ff56e2891c78684a38b728e49
endPointHeader/deviceName: Jeffreys-MacBook-Pro.local
severity:
messageData/sha256:
87e27ba9128d9c3b3d113c67623a06817a030b3bbb4d2871d1e6da9002206f26
Log Forwarding
messageData/type: macho
messageData/parentSha256:
messageData/lastSeen: 2019-01-31T18:00:43Z
messageData/fileName: crashpad_handler
messageData/filePath: /users/username/library/google/
googlesoftwareupdate/googlesoftwareupdate.bundle/contents/macos/
messageData/fileSize: 353680
messageData/localAnalysisResult:
"{""contentVersion"":""42-6337"",""result"":""Benign"",""trusted"":""None"",
""publishers"":[""developer id application: google, inc.
(eqhxz8m8av)""],""resultId"":0,""trustedId"":0}"
messageData/reported: 0
messageData/blocked: 0
messageData/executionCount: 4179

quotas. In this case, the record type is
analycs which includes hash execuon
reports from the agent.
class Class of Cortex XDR log: config, policy,

system, and agent_log.

vary by class:
systemManagement
sam

(for example, 2017-01-24T09:08:59Z).
Log Forwarding

2017-01-24T09:08:59Z).


in minutes.


record.


endpoint.

• 1—Windows
• 2—OS X/macOS
• 3—Android
Log Forwarding

• 4—Linux


6.1.7601.19135.

architecture
architecture

was logged.

event.
special handling.
details.
Log Forwarding

• 0—Protected
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 me when the file last ran on an
endpoint in ISO-8601 string representaon
(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 XDR did not evaluate the signer
of the file.
• 1—The signer is trusted.
• 2—The signer is not trusted.
reported Reporng status of the file, in integer value:

• 0—Cortex XDR did not report the security
event.
Log Forwarding

• 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.
execuonCount The total number of mes a file idenfied by a

specific hash was executed.
System Logs
Syslog format: recordType, class, FUTURE_USE, subClassId, eventType, eventCategory,
generatedTime, serverTime, FUTURE_USE, facility, customerId, trapsId, serverHost,
serverComponentVersion, regionId, isEndpoint, agentId, severity, trapsSeverity, messageCode,
friendlyName, FUTURE_USE, msgTextEn, userFullName, username, userRole, userDomain,
agentTime, tzOffset, osType, isVdi, osVersion, is64, agentIp, deviceName, deviceDomain,
agentVersion, contentVersion, proteconStatus, userFullName, username, userRole, userDomain,
messageName, messageId, processStatus, errorText, errorData, resultData, parameters,
addionalData(Array)
recordType: system
messageData/class: system
messageData/subClass: Provisioning
messageData/subClassId: 13
eventType: ServerLogPerTenant
messageData/eventCategory: tenant
generatedTime: 2019-01-31T18:15:19.000000+00:00
serverTime: 2019-01-31T18:15:19.000000+00:00
product:
facility: TrapsServerManagement
trapsId: 18520498190303952
serverHost: 14917869646-201.proda.brz
regionId:
isEndpoint: 0
agentId:
severity: notice
messageData/trapsSeverity: informational
messageData/messageCode: 19015
messageData/friendlyName: User Login
messageData/msgTextLoc:
messageData/msgTextEn: User username@paloaltonetworks.com has logged
in with role superadmin
endPointHeader/userFullName:
endPointHeader/username:
endPointHeader/userRole:
Log Forwarding
endPointHeader/userDomain:
endPointHeader/agentTime:
endPointHeader/tzOffset:
endPointHeader/osType:
endPointHeader/isVdi:
endPointHeader/osVersion:
endPointHeader/is64:
endPointHeader/agentIp:
endPointHeader/deviceName:
endPointHeader/agentVersion:
endPointHeader/contentVersion:
endPointHeader/protectionStatus:
messageData/userFullName:
messageData/username:
messageData/userRole:
messageData/userDomain:
messageData/messageName:
messageData/messageId:
messageData/processStatus:
messageData/errorText:
messageData/errorData:
messageData/resultData:
messageData/parameters:
messageData/additionalData: {}

quotas. In this case, the record type is system
which includes logs related to automated
system management and agent reporng
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 representaon of the subClass field

for easy sorng and filtering.

vary by class:
Log Forwarding

systemManagement
sam

(for example, 2017-01-24T09:08:59Z).

2017-01-24T09:08:59Z).


record.


endpoint.
Log Forwarding


event.
special handling.
details.

level:
severity level.
severity level.
Log Forwarding

messageCode System-wide unique message code.
friendlyName Descripve log message name.
msgTextEn Descripon of the event, in English.
userFullName Full username of Cortex XDR user.


in minutes.

• 1—Windows
• 2—OS X/macOS
• 3—Android
• 4—Linux


6.1.7601.19135.

architecture
architecture
Log Forwarding

was logged.

• 0—Protected
userFullName Full name of Cortex XDR user.
messageName Name of the message.
messageId Unique numeric idenfier of the message.
processStatus State of the process related to the event.
errorText If known, a descripon 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.
addionalData(Array) Addional informaon regarding event

parameters.
loggedInUser User that is logged in to the Cortex XDR.
Log Forwarding
Analycs Logs
Format: recordType, class, FUTURE_USE, eventType, category, generatedTime,
serverTime, agentTime, tzoffset, FUTURE_USE, facility, customerId, trapsId, serverHost,
serverComponentVersion, regionId, isEndpoint, agentId, osType, isVdi, osVersion, is64, agentIp,
deviceName, deviceDomain, severity, agentVersion, contentVersion, proteconStatus, sha256,
type, parentSha256, lastSeen, fileName, filePath, fileSize, localAnalysisResult, reported, blocked,
execuonCount
recordType: analytics
messageData/class: agent_data
eventType: AgentTimelineEvent
messageData/eventCategory: hash
generatedTime: 2019-01-31T18:00:43Z
serverTime: 2019-01-31T18:59:46.586Z
endPointHeader/tzOffset: -480
product:
trapsId: 18520039498190352
serverHost: coreop-f-proda-mnmauto03930348053-311.proda.brz
regionId: 10
isEndpoint: 1
agentId: 3bcf7e5ff56e2891c78684a38b728e49
endPointHeader/deviceName: Jeffreys-MacBook-Pro.local
severity:
messageData/sha256:
87e27ba9128d9c3b3d113c67623a06817a030b3bbb4d2871d1e6da9002206f26
messageData/type: macho
messageData/parentSha256:
messageData/lastSeen: 2019-01-31T18:00:43Z
messageData/fileName: crashpad_handler
messageData/filePath: /users/username/library/google/
googlesoftwareupdate/googlesoftwareupdate.bundle/contents/macos/
messageData/fileSize: 353680
messageData/localAnalysisResult:
"{""contentVersion"":""42-6337"",""result"":""Benign"",""trusted"":""None"",
""publishers"":[""developer id application: google, inc.
(eqhxz8m8av)""],""resultId"":0,""trustedId"":0}"
messageData/reported: 0
messageData/blocked: 0
Log Forwarding
messageData/executionCount: 4179

quotas:
• config—Cortex XDR administraon and
configuraon changes.
• system—Automated system management
and agent reporng events.
• analycs—Hourly hash execuon report
from the agent.
• threats—Security events that occur on the
endpoints.
class Class of Cortex XDR log: config, policy,

system, and agent_log.

vary by class:
systemManagement
sam

(for example, 2017-01-24T09:08:59Z).

Log Forwarding

2017-01-24T09:08:59Z).


in minutes.


record.


endpoint.

• 1—Windows
• 2—OS X/macOS
• 3—Android
• 4—Linux
Log Forwarding


6.1.7601.19135.

architecture
architecture

was logged.

event.
special handling.
details.
Log Forwarding

• 0—Protected
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 me when the file last ran on an
endpoint in ISO-8601 string representaon
(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 XDR did not evaluate the signer
of t he file.
• 1—The signer is trusted.
• 2—The signer is not trusted.
reported Reporng status of the file, in integer value:

• 0—Cortex XDR did not report the security
event.
• 1—Cortex XDR reported the security event.
Log Forwarding
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.
execuonCount The total number of mes a file idenfied by a

specific hash was executed.
Log Forwarding
Managed Security
> About Managed Security
> Cortex XDR Managed Security Access Requirements
> Switch to a Different Tenant
> Pair a Parent Tenant with Child Tenant
> Manage a Child Tenant
> About Managed Threat Hunng
> Set up Managed Threat Hunng
> Invesgate Managed Threat Hunng Reports
1035
Managed Security
About Managed Security

Cortex XDR supports pairing mulple Cortex XDR environments with a single interface enabling
Managed Security Services Providers (MSSP) and Managed Detecon and Response (MDR)
providers to easily manage security on behalf of their clients.
Pairing an MSSP/MDR (parent) tenant with a client (child) tenant requires a separate Cortex XDR
license for the parent tenant. To ensure bidireconal tenant access between the parent and child,
both need to approve the pairing from within the Cortex XDR app.
Once pairing is approved, Cortex XDR resets the child data and synchronizes the security acons
configured in the parent tenant, enabling you to view and invesgate Cortex XDR data of a child
tenant, and iniate security acons on their behalf.
Managed Security
Cortex XDR Managed Security Access Requirements

To set up a managed security pairing, you and your child tenants must acvate the Cortex XDR
app, provide role permission, and define access configuraons.
The following table describes what and where you and your child tenants need to define.
Tenant Applicaon Acon
Child Customer Support Portal Add the user name from the
(CSP) Account parent tenant who is iniang
the parent-child pairing and
ensure the user name has
Super User role permissions.
Cortex Gateway Provide the user name added

in CSP with Admin role
permissions to access the
child Cortex XDR instance.
Parent Customer Support Portal Ensure the parent user

(CSP) Account name has Super User role
permissions.
Cortex Gateway Ensure the user name added

to the child tenant’s CSP
account has Admin role
permissions on the parent
Cortex XDR instance.
Managed Security
Switch to a Different Tenant

When using multenancy with Cortex XDR, in the Cortex XDR console use the Tenant Navigator
funcon to switch directly to another tenant that you own. The tenant navigator includes the
following selecons:
• Cortex XDR tenant gateway link
• Cortex XDR tenants to which you have access, divided per CSP account. If there are more than
5 tenants to switch to, a search opon is available. If there are more than 5 tenants within a
specific account, a list of tenants is available for that CSP account.
If you don’t own more than one account, the tenant navigator funcon is not available.
Pivot to Another Tenant

By choosing any tenant listed on the tenant navigator, you are pivoted directly to the main page of
the gateway or tenant.
STEP 1 | In Cortex XDR, click the hub icon.
The Tenant Navigator panel opens. The currently chosen tenant is marked by a green Acve
Session label.
STEP 2 | From the list of available tenants, choose the tenant to which you want to switch (navigate).
You can also type a tenant name in the Search line to filter the list of tenants according to
what you type.
Managed Security
Pair a Parent Tenant with Child Tenant

Aer you and your child tenants have acquired the appropriate role permissions, you can pair your
tenant to your child tenants.
Pairing a Parent and Child Tenant

STEP 1 | In Cortex XDR, select Sengs > Configuraons > Tenant Management.
The Tenant Management table displays the:
• Tenant Name—Name of the child tenant
• Pairing Status—State of a pairing request; Paired, Pending, Failed, Rejected
• Account Name—CSP account to which the child tenant is associated with
• Last Sync—Timestamp of when parent tenant last made contact with child tenant
• Managed Security Acons - a column for each security acon with a status; configuraon
name or Unmanaged. Unmanaged status means that a configuraon for the security acon
has not yet been selected.
STEP 2 | + Pair Tenant.
STEP 3 | In the Pair Tenant window, select the child tenant you want to pair. The drop-down only
displays child tenants your are allowed to pair with.
Child tenants are grouped according to:
• Unpaired—Children that have not yet been paired and are available. If another parent has
requested to pair with the child but the child has not yet agreed, the tenant will appear.
• Paired—Children that have already been paired to this parent.
• Paired with others—Children that have been paired with other parents.
• Pending—Children with a pending pairing request.
STEP 4 | Pair the tenant.

Cortex XDR sends a Request for Pairing to the specified child tenant.
STEP 5 | In the child tenant Cortex XDR console, a child tenant user with Admin role permissions
needs to approve the pairing by navigang to , locate the Request for Pairing noficaon
and select Approve.
Managed Security
STEP 6 | Verify the parent-child pairing.

Aer pairing has been approved, in the child tenant’s Cortex XDR app, when navigang to a
page managed by a parent configuraon, the child user is nofied by a flag who is managing
their security:
In the child tenant’s, pages managed by you appear with a read-only banner. Child tenant users
cannot perform any acons from these pages, but can view the configuraons you create on
their behalf.
Unpairing a Parent and Child Tenant

When you want to disconnue the pairing with a child tenant, in the Tenant Management page,
right-click the tenant row and select Request Unpairing. For the unpairing to take effect, the child
tenant must approve the request.
When a child wants to unpair, the child user needs to select Sengs ( ) > Unpair.
Managed Security
Manage a Child Tenant

Pairing a child tenant enables you to view and invesgate Cortex XDR data of a child tenant, and
iniate security acons on their behalf.
In your Cortex XDR management console, you have access to view the following pages:
• Incidents
• Alerts
• Query Builder
• Query Center and Results
• Causality View
• Timeline View
To iniate security acons on your child tenant, you need to create a Configuraon. Security
acons are managed by configuraons you create in the Cortex XDR app and then assign to each
of the child tenants. Each acon requires its own configuraon and allocaon to a child tenant.
Once a configuraon is created Cortex XDR resets the child tenant data and synchronizes
the security acons configured in the parent tenant.
You can create configuraon for the following acons:

• BIOC Rules and Excepons
• Starred Alerts Policies
• Alert Exclusions
• Profiles
• Allow/Block Lists
The following secons describe how to manage your child tenants.
• Track your Tenant Management
• Invesgate Child Tenant Data
• Create and Allocate Acon Configuraons
• Create a Security Managed Acon
Track your Tenant Management

Aer successfully pairing your child tenant, select Sengs > Configuraons > Tenant
Management to view the child tenant details.
The Tenant Management page displays the following informaon about each of your child
tenants:
Managed Security
Field Descripon
Status Indicator Idenfies whether the child tenant is connected.

( )
TENANT ID The Cortex XDR tenant ID.
TENANT NAME Name you defined during the pairing process.
ACCOUNT ID The CSP account ID.
ACCOUNT NAME Name of the parent tenant.
PAIRING STATUS Status of the child paring process:

• Pending
• Paired
• Approved
• Declined
• Pending
• Paired to another
• Not Paired
LAST SYNC Timestamp of the last security acon sync

iniated by the parent tenant.
BIOC RULES & EXCEPTIONS Name of the configuraon managing the BIOC
rules and excepons acons.
STARRED INCIDENTS POLICY Name of the configuraon managing the starred

incidents policy acons.
ALERT EXCLUSION Name of the configuraon managing the alert

exclusion acons.
PROFILES Name of the configuraon managing the profile

acons.
Invesgate Child Tenant Data

With Cortex XDR managed security, you can invesgate the Cortex XDR child tenant data.
By default, Cortex XDR displays data for your tenant. To display data for of your child tenant,
select the tenant from the drop-down.
Managed Security
Some common tasks that you might perform include:

• Invesgate incidents on a child tenant.
• Invesgate alerts on a child tenant.
• Build and execute an XQL search query to search across the data of a child tenant.
When running an XQL Search, you can execute XQL queries across a single child tenant or up
to 100 child tenants simultaneously.
• For XQL queries on a single child tenant, Cortex XDR provides the parent tenant with
autocompleon and validaon capabilies to all datasets available on the child tenant.
• When execung XQL queries on mulple child tenants simultaneously:
• Autocomplete and validaon are supported on all datasets.
• Queries are executed on each child tenant separately and return up to 1,000,000 results
split across the selected tenants. For example, an XQL query on 10 tenants returns a
maximum of 100,000 per tenant.
• You can select mulple datasets that share the same dataset name from different child
tenants even when their schemas are different. Cortex XDR displays only the common
fields that have the same name and the same data type in both datasets. If the datasets
from two child tenants contain fields with the same name, but different data types, or
one of the datasets contains fields that the other one doesn’t have, these fields will not
be displayed. By default, even when you don’t select fields, Cortex XDR automacally
selects the fields that are common to both child datasets.
In the example below, if you select two child tenants which both contain a dataset called
users, Cortex XDR displays users as a possible source for the query, even though they
contain different fields.
Tenant_1:
users= {“employee_name”: “John”, “employee_number”: 123}
Tenant_2:
users= {“employee_name”: “John”, “employee_number”: "123",
"national_ID": 123456789}
When you start selecng fields from users, Cortex XDR displays only the field
employee_name as an opon for the query since its name and type are the same for
both child tenants.
• Run an XQL Query API on your local and child tenants.
Managed Security
• Use the Query Builder to build and execute an enty-specific query across the data of a child
tenant. You can run either an ad-hoc query or scheduled query on one or more child tenants.
For each query, Cortex XDR returns up to 100,000,000 results across all selected tenants.
• Use the Query Center to view previously run XQL searches and enty queries run on your
tenant and the child tenants.
Create and Allocate Configuraons

To manage security acons on behalf of your child tenant, you need to first create and allocate an
acon configuraon.
STEP 1 | Navigate to each of the following Cortex XDR pages and follow the detailed steps:
• Detecon & Threat Intel > Detecon Rules > BIOC > Rules and Excepons Configuraons
panel
• Incident Response > Incident Configuraon > Alert Exclusions > Alert Exclusions
Configuraon panel
• Incident Response > Incident Configuraon > Starred Alerts > Starred Alerts Configuraon
panel
• Endpoints > Policy Management > Prevenon > Profiles > Profile Configuraon panel
• Incident Response > Response > Acon Center > Currently Applied Acons > Block List/
Allow List > Allow List/Block List configuraon panel
STEP 2 | In the corresponding Configuraon panel (1), + Create New (2) configuraon.
STEP 3 | Enter the configuraon Name and Descripon.
STEP 4 | Create.
The new configuraon (3) appears in the Configuraon pane.
STEP 5 | Navigate to Sengs > Tenant Management.
STEP 6 | In the Tenant Management table, right-click a child tenant row and Edit Configuraons.
STEP 7 | Assign the configuraon you want to use to manage each of the security acons.
You can configure Profiles only as Managed or Unmanaged. All profiles you create are
automacally cloned to your child tenants.
STEP 8 | Update.
The Tenant Management table is updated with your assigned configuraons.
Create a Security Managed Acon

Aer you’ve created and assigned a configuraon for each of your child tenant’s security acons,
you can define the specific managed acon on behalf of the child tenant.
Managed Security
STEP 1 | Navigate to each of the following Cortex XDR pages:

• Rules > BIOC > Rules and Excepons Configuraons panel
• Invesgaon > Incident Management > Exclusions > Alert Exclusions Configuraon panel
• Invesgaon > Incident Management > Starred Alerts > Starred Alerts Configuraon panel
• Endpoints > Policy Management > Prevenon > Profiles > Profile Configuraon panel
• Response > Acon Center > Currently Applied Acons > Block List/Allow List > Allow
List/Block List configuraon panel
STEP 2 | In the corresponding Configuraon panel, select the acon configuraonacon configuraon
you created and allocated to your child tenant.
The corresponding security acon Table displays the acons managing the child tenant.
STEP 3 | Depending on the security acon, select:

• + Add BIOC to create a BIOC Rule.
• + New Excepon to create a BIOC Excepon.
• + Add Exclusion to create an Alert Exclusion.
• + Add Starring Configuraon to create a started alert inclusion.
• + New Profile to create a new endpoint profile.
Profiles you create are automacally cloned to your child tenants.
Managed Security
About Managed Threat Hunng

Cortex XDR provides the Managed Threat Hunng service as an add-on security service. To use
Cortex XDR Managed Threat Hunng, you must purchase a Managed Threat Hunng license and
have a Cortex XDR Pro for Endpoint license with a minimum of 500 endpoints.
Managed Threat Hunng augments your security by providing 24/7, year-round monitoring by
Palo Alto Networks threat researchers and Unit 42 experts. The Managed Threat Hunng teams
proacvely safeguard your organizaon and provide threat reports for crical security incidents
and impact reports for emerging threats that provide an analysis of exposure in your organizaon.
In addion, the Managed Threat Hunng team can idenfy incidents and provide in-depth review
of related threat reports.
Managed Security
Set up Managed Threat Hunng

To get started with Managed Threat Hunng:
STEP 1 | Access the Cortex XDR app and approve the pairing request sent to your Cortex XDR tenant.
1. Navigate to Noficaons and locate the Request for Pairing noficaon.
2. Select Approve and then Yes to confirm.
Aer the request is approved, Cortex XDR displays the Managed Threat Hunng label at
the top of the page.
STEP 2 | Configure noficaon emails for the impact reports and threat inquiries you want Cortex
XDR to send.
1. Select Sengs > Configuraons > Managed Threat Hunng.
2. Enter one or more email addresses to which you want to send reports and inquires and
ADD each one.
STEP 3 | Ensure a successful set up by locang in your defined email address mailbox the Welcome to
the Palo Alto Networks Cortex XDR Managed Threat Hunng Service email. If you did not
receive such an email, contact your Palo Alto sales representave.
STEP 4 | (Oponal) If desired, forward Managed Threat Hunng alerts to external sources such as
email or slack from the Sengs > Configuraons > General > Noficaons page.
This will forward both the alert itself and the detailed report in a PDF format.
Managed Security
Invesgate Managed Threat Hunng Reports

The Managed Threat Hunng team proacvely scans, idenfies, and analyzes your Cortex XDR
tenant for possible threats and creates detailed threat and impact reports to help you track and
manage your Cortex XDR data.
Cortex XDR displays the reports in a dedicated page that allows you to invesgate and
communicate with your Manged Threat Hunng team. When a new report is sent, MTH send a
noficaon to your Noficaon Center. MTH type noficaons will appear at the top of your
noficaon list and offer the following opons:
• Open—Pivot to report in the Managed Threat Hunng table.
• Dismiss—Delete the noficaon from your Noficaons list.
The MTH page is available for users with the Managed Threat Hunng license and have
the necessary permission to view and triage alerts and incidents in Cortex XDR .
To invesgate your reports:

STEP 1 | In the Cortex XDR console, select MTH.
The Managed Threat Hunng page displays a side-by-side view of all your reports and their
corresponding report details and communicaon.
STEP 2 | In the le-pane, select the report you want to invesgate. You can sort the list according to
the report Type, Insert Time, or Severity, and use the search bar to help you locate reports.
Aer selecng a report, the right-pane view displays a summary of the Managed Threat
Hunng findings along with an aachment of the complete report.
STEP 3 | In the right-pane, invesgate the report findings and add your comments.
The comments are a way for you to communicate directly with the Managed Threat Hunng
without the need to send separate emails. When you post a comment, the Managed Threat
Hunters team is nofied and can see and reply to your comments. Comments are listed
chronologically and are visible to all the Cortex XDR tenant users with access to the MTH
page and the Managed Threat Hunng team. You can aach up to ten PDF or image format
files with a maximum of 10MB per file in each comment. Eding and deleng a comments is
available only on comments you wrote.

Cortex XDR Pro Admin

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cortex XDR Pro Admin

Uploaded by

Copyright:

Available Formats

Cortex® XDR Pro Administrator’s

About the Documentaon

Get Started with Cortex XDR Pro............................................................... 29

Use the Interface.................................................................................................................... 146

Endpoint Security.......................................................................................... 155

Invesgaon and Response........................................................................ 287

Broker VM....................................................................................................... 497

Cortex XDR Collectors................................................................................. 589

External Data Ingeson............................................................................... 625

Ingest Logs from Microso Oﬃce 365..................................................................718

Data Management......................................................................................... 811

Error Reporng in Parsing Rules..............................................................................831

Monitor Agent Acvity..........................................................................................................918

Managed Security....................................................................................... 1035

> Cortex XDR Architecture

Cortex XDR Architecture

Cortex XDR Concepts

Causality Analysis Engine

Causality Group Owner (CGO)

Cortex XDR Licenses

Features by Cortex XDR License Type

Log storage • Minimum • Minimum • Minimum of • Minimum

Cortex XDR Add-on Licenses

Endpoint Prevenon Features

Alert and Log Collectors

Files and Folders — — —

Cortex XDR Endpoint Agent License Allocaon

Enforcement of Cortex XDR Pro Endpoint Licenses

Enforcement of Cortex XDR Cloud per Host Licenses

Endpoint License Revocaon

(Non-Persistent) Immediately aer log- Aer 6 hours Aer 7 days

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

Cortex XDR License Expiraon

Cortex XDR License Monitoring

The Cortex XDR License dialog is made of the following secons:

Migrate Your Cortex XDR License

License Conversion Method and Example

License Type Calculaon

Endpoints • For each Cortex 1.0 license, 1 TB = 200 Pro per

Network Data • For each Cortex XDR 1.0 license, 1 TB = 1 TB of

Since Cortex XDR 2.0 pro per TB license

License Version License Details

Post Migraon Cortex XDR 2.0 • Up to 20,000 Pro per Endpoints

Convert Your Cortex XDR License

• (1) Network quota in TB and qualifying number of Pro per Endpoints

STEP 1 | Plan Your Cortex XDR Deployment.

STEP 4 | Set up Cortex XDR.

STEP 9 | Conﬁgure Cortex XDR.

STEP 10 | (Oponal) Set up Outbound Integraon.

STEP 11 | (Oponal) Set up Managed Security.

STEP 12 | Use the Cortex XDR Interface.

Plan Your Cortex XDR Deployment

Deployment Type Deployment Consideraons

If you plan to stream data from a

• US—All Cortex XDR logs and data remain

Deployment Type Deployment Consideraons

Aer the migraon, WildFire India

Cortex XDR Public Key Download Cortex XDR Public Key

Deploy your Network Devices

Acvate Cortex XDR

The sizing calculator is managed on the hub.

STEP 5 | Acvate your tenant.

You can change your tenant subdomain from oldName.xdr.us.paloaltonetworks.com to