Cortex XDR Prevent Admin

Cortex® XDR™ Prevent
Administrator’s Guide
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
©2018–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
February 15, 2022
Cortex® XDR™ Prevent Administrator’s Guide 2 ©2022 Palo Alto Networks, Inc.
Table of Contents
Cortex® XDR™ Overview................................................................................ 7
Cortex® XDR™ Prevent Architecture.....................................................................................8
Cortex XDR versus Tradional Endpoint Protecon........................................................ 11
Exploit Protecon Overview.......................................................................................12
Malware Protecon Overview....................................................................................12
Cortex XDR Licenses................................................................................................................15
Features by Cortex XDR License Type..................................................................... 15
Cortex XDR Endpoint License Allocaon................................................................ 19
Cortex XDR License Expiraon..................................................................................20
Cortex XDR License Monitoring................................................................................ 21
Get Started with Cortex® XDR™ Prevent................................................. 23

Set up Cortex XDR Prevent Overview................................................................................ 24
Plan Your Cortex XDR Deployment......................................................................................26
Migrate from Traps Endpoint Security Manager to Cortex XDR........................ 27
Manage User Roles................................................................................................................... 34
Permission Management.............................................................................................. 34
Access Management..................................................................................................... 37
Predefined User Roles for Cortex XDR.................................................................... 44
Manage User Scope....................................................................................................113
Acvate Cortex XDR..............................................................................................................116
Set Up Cloud Identy Engine.............................................................................................. 118
Manage Your Log Storage within Cortex XDR................................................................ 119
Set up Endpoint Protecon..................................................................................................121
Plan Your Agent Deployment...................................................................................121
Enable Access to CortexXDR................................................................................... 123
Proxy Communicaon................................................................................................ 131
Integrate External Threat Intelligence Services....................................................132
Configure Cortex® XDR™.................................................................................................... 134
Set up Your Cortex Environment.............................................................................134
Set up Outbound Integraon...............................................................................................137
Use the Cortex XDR Interface.............................................................................................138
Manage Tables..............................................................................................................140
Endpoint Security.......................................................................................... 145

Communicaon Between Cortex® XDR™ and Agents................................................. 146
Agent-Iniated Communicaon...............................................................................146
Server-Iniated Communicaon.............................................................................. 146
Manage Cortex XDR Agents................................................................................................148
Table of Contents
Create an Agent Installaon Package.....................................................................148

Set an Applicaon Proxy for Cortex XDR Agents............................................... 150
Move Cortex XDR Agents Between Managing XDR Servers........................... 151
Upgrade Cortex XDR Agents................................................................................... 153
Set aCortex XDR Agent Crical Environment Version....................................... 154
Delete Cortex XDR Agents.......................................................................................155
Uninstall the Cortex XDR Agent............................................................................. 155
Set an Alias for an Endpoint.....................................................................................156
Define Endpoint Groups........................................................................................................158
File Analysis and Protecon Flow...................................................................................... 160
Exploit Protecon for Protected Processes.......................................................... 160
Malware Protecon.....................................................................................................160
About Content Updates........................................................................................................ 164
Endpoint Protecon Capabilies.........................................................................................166
Endpoint Protecon Modules.............................................................................................. 171
Endpoint Security Profiles.....................................................................................................180
Add a New Exploit Security Profile........................................................................ 181
Add a New Malware Security Profile..................................................................... 186
Add a New Restricons Security Profile................................................................196
Manage Endpoint Security Profiles......................................................................... 197
Customizable Agent Sengs............................................................................................... 200
Add a New Agent Sengs Profile.......................................................................... 203
Endpoint Data Collected by Cortex XDR.............................................................. 209
Configure Global Agent Sengs............................................................................. 218
Apply Security Profiles to Endpoints................................................................................. 221
Excepons Security Profiles................................................................................................. 222
Add a New Excepons Security Profile................................................................. 223
Add a Global Endpoint Policy Excepon............................................................... 225
Hardened Endpoint Security................................................................................................ 230
Device Control............................................................................................................. 231
Host Firewall.................................................................................................................237
Disk Encrypon............................................................................................................248
Invesgaon and Response........................................................................ 255

Invesgate Incidents.............................................................................................................. 256
Cortex XDR Incidents.................................................................................................256
Manage Incident Starring.......................................................................................... 259
Triage Incidents............................................................................................................ 260
Manage Incidents........................................................................................................ 260
Invesgate Alerts.................................................................................................................... 270
Cortex XDR Alerts...................................................................................................... 270
Table of Contents
Triage Alerts.................................................................................................................. 280

Manage Alerts.............................................................................................................. 280
Alert Exclusions............................................................................................................283
Causality View..............................................................................................................286
Invesgate Endpoints.............................................................................................................289
Acon Center............................................................................................................... 289
View Details About an Endpoint............................................................................. 293
Retrieve Files from an Endpoint.............................................................................. 299
Retrieve Support Logs from an Endpoint.............................................................. 300
Scan an Endpoint for Malware.................................................................................301
Invesgate Files.......................................................................................................................303
Manage File Execuon...............................................................................................303
Manage Quaranned Files........................................................................................ 304
Review WildFire® Analysis Details......................................................................... 305
Import File Hash Excepons.....................................................................................306
Response Acons....................................................................................................................308
Isolate an Endpoint..................................................................................................... 309
Iniate a Live Terminal Session................................................................................310
Broker VM....................................................................................................... 315

Broker VM Overview............................................................................................................. 316
Set up Broker VM...................................................................................................................319
Configure the Broker VM..........................................................................................319
Acvate the Local Agent Sengs........................................................................... 338
Manage Your Broker VMs.....................................................................................................341
View Broker VM Details............................................................................................341
Edit Your Broker VM Configuraon........................................................................343
Collect Broker VM Logs.............................................................................................345
Reboot a Broker VM...................................................................................................345
Shut Down a Broker VM...........................................................................................345
Upgrade a Broker VM................................................................................................ 345
Open a Remote Terminal...........................................................................................346
Remove a Broker VM................................................................................................. 349
Broker VM Noficaons....................................................................................................... 350
Monitoring....................................................................................................... 351
Cortex XDR Dashboard.........................................................................................................352
Dashboard Widgets.................................................................................................... 352
Predefined Dashboards.............................................................................................. 361
Build a Custom Dashboard....................................................................................... 364
Manage Dashboards................................................................................................... 365
Table of Contents
Run or Schedule Reports...........................................................................................366

Monitor Cortex XDR Incidents............................................................................................368
Monitor Cortex Gateway Management Acvity............................................................. 369
Monitor Administrave Acvity..........................................................................................370
Monitor Agent Acvity..........................................................................................................373
Monitor Agent Operaonal Status..................................................................................... 376
Log Forwarding...............................................................................................379
Log Forwarding Data Types..................................................................................................380
Integrate Slack for Outbound Noficaons..................................................................... 381
Integrate a Syslog Receiver.................................................................................................. 382
Configure Noficaon Forwarding..................................................................................... 385
Cortex® XDR™ Log Noficaon Formats........................................................................ 387
Management Audit Log Messages.......................................................................... 387
Alert Noficaon Format.......................................................................................... 425
Agent Audit Log Noficaon Format..................................................................... 435
Management Audit Log Noficaon Format........................................................ 437
Cortex® XDR™ Log Formats....................................................................................438
Managed Security..........................................................................................471
About Managed Security...................................................................................................... 472
Cortex XDR Managed Security Access Requirements................................................... 473
Switch to a Different Tenant................................................................................................474
Pivot to Another Tenant............................................................................................ 474
Pair a Parent Tenant with Child Tenant.............................................................................475
Pairing a Parent and Child Tenant...........................................................................475
Unpairing a Parent and Child Tenant......................................................................476
Manage a Child Tenant..........................................................................................................477
Track your Tenant Management.............................................................................. 477
Invesgate Child Tenant Data.................................................................................. 478
Create and Allocate Configuraons........................................................................479
Create a Security Managed Acon......................................................................... 479
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 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.
> Cortex® XDR™ Prevent Architecture

> Cortex XDR versus Tradional Endpoint Protecon
> Cortex XDR Licenses
7
Cortex® XDR™ Prevent Architecture

As new malware variants pop up around the globe and new soware bugs and vulnerabilies are
discovered, it is challenging to ensure that your endpoints remain secure. With Cortex XDR, a
cloud-based endpoint security service, you save the me and cost of building out your own global
endpoint security infrastructure. This simplified deployment, which requires no server licenses,
databases, or other infrastructure to get started, enables you to quickly protect your endpoints.
With Cortex XDR, Palo Alto Networks deploys and manages the security infrastructure globally
to manage endpoint security policy for both local and remote endpoints and to ensure that the
service is secure, resilient, up to date, and available to you when you need it. This allows you
to focus less on deploying the infrastructure and more on defining the polices to meet your
corporate usage guidelines.
Cortex XDR is comprised of the following components:
• Cortex XDR web interface—A cloud-based security infrastructure service that is designed to
minimize the operaonal challenges associated with protecng your endpoints. From Cortex
XDR, you can manage the endpoint security policy, review security events as they occur, and
perform addional analysis of associated logs.
You can host your Cortex XDR tenant in either the US Region or EU Region.
• Cortex XDR Agents—Each local or remote endpoint is protected by the Cortex XDR agent,
which is installed and connuously runs on the endpoint. The Cortex XDR agent enforces your
security policy on the endpoint and sends a report when it detects a threat. Cortex XDR agents
support secure communicaon with Cortex XDR using Transport Layer Security (TLS) 1.2.
• Palo Alto Networks cloud-delivered security services:

• Cortex Data Lake—A cloud-based logging infrastructure that allows you to centralize the
collecon and storage of logs generated by your Cortex XDR agents regardless of locaon.
The Cortex XDR agents and Cortex XDR forward all logs to the Cortex Data Lake. You can
view the logs for your agents in Cortex XDR. With the Log Forwarding app, you can also
forward logs to an external syslog receiver.
You can host your Cortex Data Lake instance in either the United States (US) Region
or European Union (EU) Region.
• Directory Sync Service—The Directory Sync Service enables Palo Alto Networks cloud-
based applicaons to leverage computer, user, and group aributes from your on-premises
Acve Directory for use in policy and endpoint management. The Directory Sync Service
uses an on-premises agent to collect those aributes from your on-premises Acve
Directory. The Directory Sync Service agent runs in the background to collect the Acve
Directory informaon and syncs it with the cloud-based Directory Sync Service that you
configure using the Hub.
You can host your Directory Sync Service instance in either the US Region or EU
Region.
• WildFire cloud service—The WildFire® cloud service idenfies previously unknown malware
and generates signatures that Palo Alto Networks firewalls and Cortex XDR can use to then
detect and block that malware. When a Cortex XDR agent detects an unknown sample (an
aempt to run a macro, DLL, or executable file), Cortex XDR can automacally forward the
sample for WildFire analysis. Based on the properes, behaviors, and acvies the sample
displays when analyzed and executed in the WildFire sandbox, WildFire determines the
sample to be benign, grayware, phishing, or malicious. WildFire then generates signatures to
recognize the newly-discovered malware and makes the latest signatures globally available
every five minutes. For more informaon, see WildFire® Analysis Concepts.
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.
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
• Malware Protecon for Mac

• Malware Protecon for Linux
• Malware Protecon for Android
Malware Protecon 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 Protecon 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.
• 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 Protecon 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 Protecon 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.
Cortex XDR Licenses

• Features by Cortex XDR License Type
• Cortex XDR Endpoint License Allocaon
• Cortex XDR License Expiraon
• Cortex XDR License Monitoring
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.
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
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)
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
Analysis
Analycs, —
including
Identy
Analycs
Alert and Log Collectors
Cortex XDR —
agent alerts
Prisma Cloud — — —
and Prisma
Cloud Compute
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
(AutoFocus,
VirusTotal)
Outbound
integraon and
+ agent audit + agent audit
noficaon
logs logs
forwarding
(Slack, Syslog)
Broker VM
Agent Proxy
Syslog 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
+ a minimum of
(requires an
500 endpoints
addional
Managed Threat
Hunng License)
Cortex XDR Endpoint 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
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 Aer 30 days Aer 180 days Aer 180 days
mobile devices
(Non-Persistent) Immediately aer log-off Aer 6 hours Aer 7 days

VDI and Temporary for VDI, otherwise aer
Session 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.
Cortex XDR displays a le with your Cortex XDR Prevent license type, total number of concurrent
agents permied by your license, number of installed agents, and the expiraon date of your
license.
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.
Get Started with Cortex® XDR™
Prevent
> Set up Cortex XDR Prevent Overview
23
Get Started with Cortex® XDR™ Prevent
Set up Cortex XDR Prevent Overview

Before you can use Cortex XDR Prevent, you must set up and acvate the Cortex XDR app and
set up related apps and services.
STEP 1 | Plan Your Cortex XDR Deployment.
STEP 2 | Acve Cortex Data Lake.
STEP 3 | Set up Cortex® XDR™

1. Acvate Cortex XDR.
2. Assign User Roles and Permissions.
3. Allocate Log Storage.
STEP 4 | (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 5 | 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 6 | (Oponal) Set up Outbound Integraon.

• Integrate with Slack.
• Integrate with a Syslog Server.
• Integrate with Cortex XSOAR.
STEP 7 | (Oponal) Set up Managed Security.
STEP 8 | Get started using Cortex XDR!
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 receive
Deployment Type Deployment Consideraons

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.
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.
Migraon from the Traps Endpoint Review to determine if upgrading is right for you.
Security Manager
Migrate from Traps Endpoint Security Manager to Cortex XDR

You can easily migrate the management of your Traps™ agents from Endpoint Security Manager
(ESM) to Cortex® XDR™.
Before you migrate to Cortex XDR:
Review Differences Between Endpoint Security Manager and Cortex XDR to determine
whether upgrading to Cortex XDR is right for you.
Upgrade your ESM and Traps agent to a version that supports migraon to Cortex XDR:
Table 1: Supported Migration Paths
Traps agent Cortex XDR agent
4.2.7 (all OS versions) • 5.0.10

• Major releases starng with 7.1 (for
example 7.2.0)
4.2.8 (Windows only) 7.3.1
Aer you upgrade to a major Cortex XDR release version, you can subsequently connue to
upgrade to a desired minor (maintenance) release in Cortex XDR.
Sanize your Security policy. Because the policy structure for Cortex XDR is different than
for ESM, you cannot migrate rules from an exisng deployment. Before you migrate to Cortex
XDR, Palo Alto Networks recommends that you review exisng user rules for each policy type
and remove any that you no longer need. For example, remove all rules that are resolved in
content updates or that apply only to earlier versions of the Traps agent.
Review restore candidates. Before you migrate to Cortex XDR, review all quaranned files and
determine whether they need to be restored or whether they require addional acon to
remediate the endpoint. Aer you upgrade the agent to an agent version supported by Cortex
XDR, the agent will not communicate with ESM and, therefore, will not respond to requests
from ESM to restore files.
Review security events. Review and address all events that require remediaon before you
migrate to Cortex XDR. During the migraon, Cortex XDR migrates any security events the
Traps agent sent to the ESM before the new Cortex XDR agent was installed on the endpoint.
Any unsent security events on the endpoint will not be migrated to Cortex XDR.
STEP 1 | Acvate Cortex XDR.
Aer you receive your Cortex XDR Prevent license, you can acvate Cortex XDR from the hub.
During acvaon, you can also associate Cortex XDR with a Cortex Data Lake instance and a
Directory Sync Service instance.
STEP 2 | Import hash overrides as hash excepons in Cortex XDR.

1. From the ESM Console, select Sengs.
2. Generate a Tech Support File and download it when it finishes.
3. Extract the TechSupport ZIP file, which contains two zipped files (one for Core and
one for Console).
4. Extract the Console ZIP file.
5. Open the DBQueries folder and locate the Verdict_Override_Exports.csv file.
This file contains all the hash overrides defined in the ESM Console.
6. Review the number of entries in the Verdict_Override_Exports.csv file.
If you have more than 5,000 hashes, divide the hashes and verdicts into files that contain
5,000 or fewer hashes and verdicts.
7. In Cortex XDR, Import File Hash Excepons for each file.
STEP 3 | Migrate trusted signers and allow list paths.

1. From Cortex XDR, Add a New Malware Security Profile for any plaorms to which you
want to add signers or paths to your allow list. Use the default profile sengs or modify
an exisng profile that you already created.
2. To allow trusted signers previously seen in your environment, add the signer name
(Windows) or SHA256 of the cerficate that signs the file (macOS) to the Allow List
Signers list of the appropriate Malware Security Profile.
®
3. Evaluate the WildFire rules for each plaorm on the ESM Console and idenfy any
paths you want included in your allow list that are sll relevant and add them to the
Allow List Folders area of the appropriate Malware Security Profile on Cortex XDR.
There may be more than one WildFire rules with the allow list. While ESM
merges WildFire rules, this capability is not available in Cortex XDR.
Ensure that you migrate paths to the appropriate Malware Security Profile for each
plaorm:
• Copy paths in macOS WildFire rules to the Mach-O Files whitelist in a macOS profile.
• Copy paths in Windows WildFire rules for Executables and DLL files to the Portable
Executables and DLLs allow list in a Windows profile.
• Copy paths in Windows WildFire rules for Office files to the Office Files allow list in a
Windows profile.
4. Apply Security Profiles for each group of target objects to which the profile (and any
associated hash excepons) applies.
You can return to the Malware Profile to specify the target objects aer you upgrade the
Traps agent.
STEP 4 | Migrate rules which disable protecon on processes.

For each remaining rule that disables protecon on a specific process or that disables a specific
protecon module on the process, record the target endpoints to which the excepon applies.
Aer you upgrade the Traps agent, you can return to Cortex XDR to apply any excepons for
specific endpoints.
STEP 5 | Upgrade the Traps agent to a Cortex XDR agent version that supports migraon.
See Supported Migraon Paths to learn about the ESM and Traps versions that
support migraon to Cortex XDR. If you use an earlier ESM and Traps version that does
not have direct migraon support, you have three opons for migraon:
• Upgrade the earlier version to a version which supports migraon using acon rules
and then use the workflow below to upgrade the Traps agent.
• Upgrade the Traps agent using a third-party soware deployment tool, such as
JAMF or SCCM. With this method you must uninstall the agent and install a fresh
installaon package of Traps 5.0 instead of an upgrade package.
• Manually uninstall the earlier Traps agent and install a fresh installaon package of
Traps 5.0.
To upgrade from a Traps agent version that supports migraon, connue with the
following workflow:
1. From Cortex XDR, Create an Agent Installaon Package with the installaon type set to
Upgrade from ESM.
For Linux endpoints, you must use the default shell package instead of the
package manager.
2. Download the package to a locaon reachable from the ESM.
3. From the ESM Console, disable service protecon.
4. Create an agent acon rule to upgrade the Traps agent using the package created from
Cortex XDR. If you need the agent to communicate through a proxy server, you can
specify a Proxy List in the acon rule. The list supports up to ten proxy servers, comma-
separated, and in the format <serverIPaddress>:<port>.
Because this procedure is valid only for a specific version of Traps agents, we
recommend that you use a condion for the acon rule to upgrade the agents
matching the Traps agent version.
5. Save and Apply the rule.
STEP 6 | Customize your Endpoint Security Policy and set excepons, as needed, for specific
endpoints.
If you have policy excepons, you can either configure global endpoint policy excepons or
add condions to the allow list within endpoint security profiles that apply to the specific
endpoints.
Differences between Endpoint Security Manager and Cortex XDR

The following table compares capabilies between the Traps™ Endpoint Security Manager (ESM)
and Cortex® XDR™.
Feature Endpoint Security Manager Cortex® XDR™
Visibility
Visibility into all file Hash Control Enhanced file acvity

execuons—including when monitoring and visibility
Office files open and DLL files within invesgaon and
load into sensive processes search when enhanced data
—and the file’s associated collecon is enabled.
WildFire Report.
Administrave control to Hash Control Response > Acon Center >

override verdicts for files that Allow List and Block List
ran previously. Set verdicts
from Benign to Malware and
Malware to Benign.
Import never seen hashes and Hash Control Response > Acon Center >
set verdicts for them. Import Hash Excepons
From the Acon Center,
you can also add hashes
individually to the block list or
allow list.
Display quaranned files that Hash Control Response > Acon Center >
are eligible to be restored to Quarane
their original locaon on the
endpoint.
Security events search criteria Security Events—Endpoint, Mul-faceted filters and

user name, and process. search capabilies.
Log forwarding SIEM, Syslog, Panorama, Log forwarding to a Syslog

Email receiver or email server
is available with the Log
Forwarding app.
Policy Management
Excepon creaon and policy You can create almost any Palo Alto Networks can
configuraon policy rule that Palo Alto also create granular policy
Networks Research teams changes, using either
(oen at the instrucon of support excepons or
Support) can create. content updates. You can
also edit profiles, create
You can also allow very
excepons, and disable
specific flows including
specific capabilies, such
adding to allow list specific
as for a specific module or
DLL files for EPMs, and
process.

allowing specific child
processes.
Excepons for Acve Assign rules to any AD object. Assign rules to any AD object.
Directory (AD) objects
Change mode per process Report or block an event Report or block an event
based on the process. based on the category and
not the process.
View protected processes Visibility from the ESM Visibility from Cortex
Console (Policies > Exploit > XDR (select or search for
Process Management). Protected Processes in the
relevant exploit protecon
capability from Endpoints
> Policy Management >
Profiles > + New Profile >
<plaorm> > Exploit Profile).
View policy from the Traps The Traps console displays N/A
console the policy rules and
excepons that apply on the
agent.
Condions Sengs > Condions— Endpoints > Endpoint

Condions based on file Management > Endpoint
properes and registry values. Groups—Create dynamic
groups based on condions
such as host name, domain,
workgroup, IP addressing,
endpoint type (for example,
VDI), endpoint operang
system, and agent version.
Does not support condions
based on registry values.
Agent and ESM sengs Granular control over sengs Fixed sengs but reduced
such as the Heartbeat heartbeat interval (5 minutes)
Interval (the frequency and reporng interval
at which the Traps agent (1 hour).
aempts to check in), the
Reporng Interval (the
frequency at which the
Traps agent sends report
noficaons, including
changes in service, crash
events, and new processes),
and the Heartbeat Grace

Period (the allowable me
period for a Traps agent that
has not responded, aer
which the status changes to
disconnected).
Content updates Choice of manual or Automated content updates

automated content update delivered directly to your
installaon. Cortex XDR tenant by Palo
Alto Networks.
Endpoint and Tenant Management
Role-based access control Granular access control for Predefined roles to allow
different areas and flows in access to Cortex XDR
the ESM Console. features.
Agent revocaon Automac and manual license Automac license revocaon

revocaon. and manual endpoint removal
capability.
Custom noficaon message Customizable noficaon Customizable noficaon

messages. messages.
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.
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 CSP account and
tenant name. 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 tenant. 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
permissions. 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 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.
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. 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. 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. 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 describes 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
• Table 9: Privileged Responder
• IT Admin
• Privileged IT Admin
• Privileged Security Admin
• Viewer
• Scoped Endpoint Admin
• Security Admin
Table 2: XDR Account Admin
Navigaon Components Permissions Addional

Headings Acon
Permissions
None View View/Edit Edit/None
XDR Account Admin

Full access to the given app(s), including all instances added of the app(s) in the
future. App Administrator can assign roles for app instances, and it can also
acvate app instances specific to that app.
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 — — —

Headings Acon
Permissions
Asset — — —
Inventory
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

Headings Acon
Permissions
Profiles
Host Firewall — — —
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

Headings Acon
Permissions
>Integraons Public API — — —
Threat — — —
Intelligence
EDL — — —
Configuraon
Table 3: Instance Administrator

Headings Acon
Permissions
Instance Administrator
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.
& 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
Endpoint — —
Administraons

Headings Acon
Permissions
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
Threat — — —
Intelligence

Headings Acon
Permissions
EDL — — —
Configuraon
Table 4: Deployment Admin

Headings Acon
Permissions
Deployment Admin
Manage and control endpoints and installaons, and configure broker VMs.
& 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

Headings Acon
Permissions
—
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
Table 5: Investigator

Headings Acon
Permissions
Invesgator
View and triage alerts and incidents.
& REPORTS
Monitoring
Reports — — —
INCIDENT
RESPONSE

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

Headings Acon
Permissions
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
—

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

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


Services
Pathfinder
Applet
—
Data
Collecon
Alerts
Mapping
Threat — — —
Intelligence
EDL — — —
Configuraon
Table 6: Investigation Admin

Headings Acon
Permissions
Invesgaon Admin
View and triage alerts and incidents, configure rules, view endpoint profiles and
policies, and Analycs management screens.
& REPORTS
Monitoring
Reports — — —
INCIDENT
RESPONSE

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

Headings Acon
Permissions
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
—
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
Table 7: Responder

Headings Acon
Permissions

Headings Acon
Permissions
Responder
View and triage alerts, and access all response capabilies excluding Live
Terminal.
& 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
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
Table 8: Privileged Investigator

Headings Acon
Permissions
Privileged Invesgator

Headings Acon
Permissions
View and triage alerts, incidents and rules, and view endpoint profiles and
policies, and Analycs management screens.
& 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
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
Table 9: Privileged Responder

Headings Acon
Permissions
Privileged Responder

Headings Acon
Permissions
View and triage alerts and incidents, access all response capabilies, and
configure rules, policies, and profiles.
& REPORTS
Monitoring
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

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
Table 10: IT Admin

Headings Acon
Permissions
IT Admin
Manage and control endpoints and installaons, configure broker VMs, view
endpoint profiles and policies, and view alerts.
& 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
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
—

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
Table 11: Privileged IT Admin

Headings Acon
Permissions
Privileged IT Admin
Manage and control endpoints and installaons, configure brokers, create
profiles and policies, view alerts, and iniate Live Terminal.
& REPORTS
Monitoring
Reports — — —

Headings Acon
Permissions
INCIDENT
RESPONSE

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

Headings Acon
Permissions
—
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
—
Request
WildFire

Headings Acon
Permissions
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
Table 12: Privileged Security Admin

Headings Acon
Permissions
Privileged Security Admin

Triage and invesgate alerts and incident, respond, and edit profiles and
policies.
& 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

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
Alerts
Mapping

Headings Acon
Permissions
Threat — — —
Intelligence
EDL — — —
Configuraon
Table 13: Viewer

Headings Acon
Permissions
Viewer
& 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

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

Headings Acon
Permissions
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
Table 14: Scoped Endpoint Admin

Headings Acon
Permissions
Scoped Endpoint Admin

Access only to product areas that support endpoint scoped based access
control (SBAC) - Endpoint Administraon, Acon Center, Response,
Dashboards and Reports.
& REPORTS
Monitoring
Reports — — —
INCIDENT
RESPONSE

Alerts Incidents
Query
Library
Center

Headings Acon
Permissions
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
Run Standard
Script

Headings Acon
Permissions
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
Table 15: Security Admin

Headings Acon
Permissions
Security Admin
Triage and invesgate alerts and incidents, respond (excluding Live Terminal),
and edit profiles and policies.
& 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
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, 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 does not support SBAC.
• 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.
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.
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 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 Set up Cortex XDR Prevent 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.
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.
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

• 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.
A Cortex XDR Prevent license grants you 30 days retenon.
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 enable access, 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 your Cortex XDR tenant is available, the status changes to the green check mark.
STEP 2 | Plan Your Agent Deployment.
STEP 3 | Enable Access to CortexXDR.
STEP 4 | Create an Agent Installaon Package.
STEP 5 | Define Endpoint Groups.
STEP 6 | (Oponal) Set up Proxy Communicaon.
STEP 7 | Customize your Endpoint Security Profiles and assign them to your endpoints.
STEP 8 | (Oponal) Configure Device Control profiles to restrict access to USB-connected devices.
STEP 9 | 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.
STEP 10 | Verify that the Cortex XDR agent can connect to your Cortex XDR instance.
If successful, the Cortex XDR displays a Connected status. In your Cortex XDR consule,
navigate to Endpoints > All Endpoints to view the status of all your agents.
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).
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 CortexXDR

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 | 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 • SHA1 Fingerprint—47 BE AB C9 22 EA E8 0E 78 78 34 62

Cerficate Authority A7 9F 45 C2 54 FD E6 8B
- G2 (Godaddy)
• 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 • SHA1 Fingerprint—27 96 BA E6 3F 18 01 E2 77 26 1B A0

Root Cerficaon D7 77 70 02 8F 20 EE E4
Authority Cerficate
• 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
GlobalSign (Google) • SHA1 Fingerprint—75 E0 AB B6 13 85 12 27 1C 04 F8 5F

DD DE 38 E4 B7 24 2E FE
• SHA256 Fingerprint—CA 42 DD 41 74 5F D0 B8 1E B9 02
36 2C F9 D8 BF 71 9D A1 BD 1B 1E FC 94 6F 5B 4C
99 F4 2C 1B 9E
Cerficate Fingerprint
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 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 Deployment for supported regions).
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 16: 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 XDR • EU— 35.227.237.180
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— traps-

35.223.6.69 management-
Used for the first request in registraon
• Port—443 service
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

Used to download content updates. • Port—443
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-

tenant>.traps.paloaltonetworks.com management-
• US—34.98.77.231
service
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-

• US—34.98.77.231
service
Used for all other requests between the agent • EU—34.102.140.103
and its tenant server including heartbeat,
uploads, acon results, and scan reports. • 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.188
Port—443
api-<xdr- IP address by region: —

• US—35.222.81.194
Used for API requests and responses. • EU— 34.90.67.58
• 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-

• US—35.224.140.142
service
Used for get-verdict requests. • EU—2 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
distributions.traps.paloaltonetworks.com
• IP address— traps-
35.223.6.69 management-
• Port—443 service
• 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
Log Forwarding to a Syslog Receiver
See Integrate a Syslog Receiver. — —
Table 17: Required Resources for Federal (United States - Government)
distributions-prod- • IP address— traps-management-

fed.traps.paloaltonetworks.com 104.198.132.24 service
Used for the first request in • Port—443
registraon flow where the
agent passes the distribuon
ID and obtains the ch-<xdr-
tenant>.traps.paloaltonetworks.com
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-installers-prod- • IP ranges in GCP cortex-xdr

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

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
fr.storage.googleapis.com
Used to download content updates.
panw-xdr-evr-prod- • IP ranges in GCP cortex-xdr

Used to download extended verdict
request results in scanning.
app- • IP address— —
proxy.federal.paloaltonetworks.com104.155.148.118
• Port—443
dc-<xdr- • IP address— traps-management-

tenant>.traps.paloaltonetworks.com130.211.195.231 service
Used for EDR data upload. • Port—443
ch-<xdr- • IP address— traps-management-

Used for all other requests between the • Port—443
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
• Port—443

Used for API requests and responses.
cc-<xdr- • IP address— traps-management-

Used for get-verdict requests. • Port—443
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-

fed.traps.paloaltonetworks.com 104.198.132.24 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
Log Forwarding to a Syslog Receiver
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.
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. 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.
• 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.
Configure Cortex® XDR™

Before you can begin using Cortex XDR, complete the following configuraon:
Set up Your Cortex XDR Environment
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
• Distribuon List Emails
• Define Incident Mean Time to Resolve (MTTR)
• Impersonaon Role
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:

• Quick Launcher
The shortcut value must be a keyboard leer, A through Z.
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 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 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, 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 Cortex XDR Interface

Before you can get started with Cortex XDR, you must Set up Cortex XDR Prevent.
Cortex XDR provides an easy-to-use interface that you can access from the hub. When you
log in to the Cortex XDR management console, you see your default dashboard. If you haven’t
customized the dashboard or changed the default, you see the Incident Management Dashboard.
Each SAML login session is valid for 8 hours.
In addion to your main dashboard, and depending on your assigned role, you can explore the
menus for other features, as detailed in the following table.
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.
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.
• 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.
• 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.
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.
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 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 XDR noficaons.
User From the User, see who is logged into 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.
• 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
> Communicaon Between Cortex® > Endpoint Protecon Modules
XDR™ and Agents > Endpoint Security Profiles
> Manage Cortex XDR Agents > Customizable Agent Sengs
> Define Endpoint Groups > Apply Security Profiles to Endpoints
> File Analysis and Protecon Flow > Excepons Security Profiles
> About Content Updates > Hardened Endpoint Security
> Endpoint Protecon Capabilies
145
Endpoint Security
Communicaon Between Cortex® XDR™ and Agents

To stay up to date with the latest policy and endpoint status, Cortex XDR communicates regularly
with your Cortex XDR agents. For example, when you upgrade your endpoints to the latest
release, Cortex XDR creates an installaon package and distributes it to the agent on their next
communicaon. Similarly, the agent can send back data from the endpoint to Cortex XDR, such
as data gathered on the endpoint or tech support files. In Cortex XDR, there are two types of
communicaon:
• Agent-Iniated Communicaon
• Server-Iniated Communicaon
Agent-Iniated Communicaon
The Cortex XDR agent iniates communicaon with Cortex XDR every five minutes by sending
a heartbeat to the server. An agent heartbeat includes data about the Cortex XDR agent, and
informaon gathered by the agent on the endpoint. For example, policy updates are performed via
heartbeat: in each heartbeat the Cortex XDR agent sends to the Cortex XDR server the content
version it uses. The Cortex XDR server compares this number with the number of latest content in
use, and sends the agent a message to download newer content if it exists.
However not all agent-server communicaon is sent over the five-minute heartbeat. If a security
event occurs on the endpoint, the agent immediately sends the server a security event message
so you can respond immediately to the event and iniate invesgaon and remediaon acons on
the endpoint. If the message is not crical, such as status reports, the agent sends them once an
hour.
Server-Iniated Communicaon
(Traps agent 6.1 and later releases) Cortex XDR can iniate some acons immediately on the
endpoint through a web socket that is maintained between Cortex XDR and the Cortex XDR
agent, improving the response acon me and prevenng delays. Examples of these acons
include:
• Quaranne file and restore file
• Terminate process
• Isolate endpoint and cancel endpoint isolaon
• Iniate Live Terminal
• Set endpoint proxy disable endpoint proxy
• Retrieve endpoint files
• Retrieve security event data
• Retrieve support file
• Perform heartbeat
The acons that can be performed via web socket are only acons that your current agent
version already supports.
Endpoint Security
If the web socket communicaon fails, the acon will be executed on the next successful Cortex
XDR agent heartbeat. You can use Cytool to display the current web socket connecon status by
running the websocket command on the endpoint.
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
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. For more informaon, see
Migrate from 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.
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.
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.
Endpoint Security
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.
• 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. Addionally, you cannot upgrade a Golden
Image from Cortex XDR agent 6.1.x or an earlier release to a Cortex XDR agent
7.1.0 or a later release.
• 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.
Endpoint Security
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
(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.
Endpoint Security
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.
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.
Endpoint Security
• 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.
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.
Endpoint Security
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.
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 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
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.
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:
Endpoint Security
Phase 1: Evaluaon of Child Process Protecon 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
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: Evaluaon of the Restricon 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 Determinaon

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:
Endpoint Security
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.
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.
Endpoint Security
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: Evaluaon 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
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 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
XDRreduces 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 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
agent protects these processes from
aacks which try to exploit known
process vulnerabilies.
Endpoint Security
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
acvity for malicious causality
chains.
Endpoint Security
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 — — —

Analyze and prevent malicious DMG
Endpoint Security
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.
Opcal Drive — — —
Endpoint Security

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 Security
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
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.
Endpoint Security
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
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
Endpoint Security

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
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
Endpoint Security

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 — — —
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)
Endpoint Security

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
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
Endpoint Security

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 — — —
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.
Endpoint Security
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
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
Endpoint Security

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.
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
Endpoint Security

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
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.
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.
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
Endpoint Security
Profile Name Descripon

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.
2. Select the plaorm to which the profile applies and Exploit as the profile type.
3. Click Next.
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.
Endpoint Security
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 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.
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
Endpoint Security
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.
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
Endpoint Security
Windows Processes Protected by Exploit Security Policy

• 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
• 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
Endpoint Security
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
• 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
Endpoint Security
Mac Processes Protected by Exploit Security Policy

• 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
• 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.
Endpoint Security
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:
New Profile.
2. Select the plaorm to which the profile applies and Malware as the profile type.
STEP 2 | Idenfy the profile.

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
Endpoint Security
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-
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
Endpoint Security
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).
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 XDR.
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,
Endpoint Security
cscript.exe, mshta.exe, excel.exe, word.exe or powerpoint.exe, the Cortex XDR agent

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:
New Profile.
2. Select the plaorm to which the profile applies and Restricons as the profile type.
3. Click Next.
Endpoint Security
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\*).

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
• Edit a security profile
• Duplicate a security profile
Endpoint Security
• View the security profile rules that use a security profile

• Populate a new policy rule with a security profile
• Delete a security profile
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
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
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.
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.
Endpoint Security
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.
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.
New Profile.
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).
Endpoint Security
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
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
Endpoint Security
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
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 | (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
Endpoint Security
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.
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.
Endpoint Security
STEP 11 | 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.
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
Endpoint Security
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.
STEP 13 | 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.

Endpoint Security
Endpoint Data Collected by Cortex XDR

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 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
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
Endpoint Security

• Rename • SHA256 and MD5 hash for
• Move the file aer modificaon
• Modificaon (Traps 6.1 • SetInformaonFile for

and later) mestamps (Traps 6.1 and
later)
• Symbolic links (Traps 6.1
and later) • File set security (DACL)
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)
• 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
Endpoint Security
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)
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
Endpoint Security

• 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.
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 18: Windows Event Logs
Path Provider Event IDs Descripon
Applicaon EMET
Endpoint Security
Applicaon Windows Error WER events for applicaon

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

User Profiles Service 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 (11),

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

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

DriverFrameworks- loaded - for potenal BadUSB
UserMode/ detecon
Operaonal
Microso-Windows- 4103, PowerShell execute block

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

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

TerminalServices- remote server
RDPClient/
Operaonal
Endpoint Security
Microso-Windows- 1006, 1009 Modern Windows Defender

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

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

Windows Firewall Windows Firewall 2005, Advanced Security Local
With Advanced With Advanced 2006, Modificaons (Levels 0, 2, 4)
Security/Firewall Security 2009, 2033
Security 4698, 4702
Security 4778, 4779 TS Session reconnect (4778),

TS Session disconnect (4779)
Security 5140 Network share object access

without IPC$ and Netlogon
shares
Security 5140, Network Share create (5142),

5142, Network Share Delete (5144),
5144, 5145 A network share object was
checked to see whether client
can be granted desired access
(5145), Network share object
access (5140)
Security 4616 System Time Change (4616)
Security 4624 Local logons without network

or service events
Security 4625 An account failed to log on/ log

off
Security 1102 Security Log cleared events

(1102)
Security 4647 User iniated logoff
Security 4634 User logoff for all non-network

logon sessions
Endpoint Security
Security 4624 Service logon events if the

user account isn't LocalSystem,
NetworkService, LocalService
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 4672 Special Privileges (Admin-

equivalent Access) assigned
to new logon, excluding
LocalSystem
Security 4732 New user added to local

security group
Security 4728 New user added to global

security group
Security 4756 New user added to universal

security group
Security 4733 User removed from local

Administrators group
Security 4886, Cerficate Services received

4887, 4888 cerficate request (4886),
Approved and Cerficate
issued (4887), Denied request
(4888)
Security 4720, New User Account

4722, Created(4720), User Account
4725, 4726 Enabled (4722), User Account
Disabled (4725), User Account
Deleted (4726)
Security 4624 Network logon events
Security 4880, CA Service Stopped (4880),

4881, CA Service Started (4881), CA
4896, 4898 DB row(s) deleted (4896), CA
Template loaded (4898)
Endpoint Security
Security 4634 Logoff events - for Network

Logon events
Security 6272, 6280 RRAS events – only generated

on Microso IAS server
Security 4689 Process Terminate (4689)
Security 4648, 4776 Local credenal authencaon

events (4776), Logon with
explicit credenals (4648)
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

• Protocol (TCP/UDP)
Endpoint Security

• Listen • Aggregated send/
• Stascs receive stascs for the
connecon
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
Event Log • Authencaon • Provider Name

• Data fields
Endpoint Security

• Message
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.
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.
Endpoint Security
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.
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.
Endpoint Security
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
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 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, you customize
sengs in a security profile and aach the profile to a policy. Each policy that you create must
apply to one or more endpoints or endpoint groups.
STEP 1 | From Cortex XDR, create a policy rule.
Do either of the following:
• Select Endpoints > Policy Management > Prevenon > Policy Rules > + New Policy to
begin a rule from scratch.
• 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 for the plaorm you selected. To change the plaorm,
go Back to the general policy sengs.
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
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)
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
2 1 Detecon No excepon created
Endpoint Security
Day Number BIOC/IOC Detecons Acon
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:
New Profile.
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. 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
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.
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.
Cortex XDR provides the following hardened endpoint security capabilies:
• Device Control
• Host Firewall
• Host Firewall for Windows
• Host Firewall for macOS
• Disk Encrypon
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 —
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 —
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 —
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.
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.
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. Select
Plaorm and click Device Configuraon > Next.
STEP 2 | 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 3 | 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.
STEP 4 | 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 5 | (Oponal) To define excepons to your Device Configuraon profile, Add a New Excepons
Profile.
STEP 6 | Apply Device Control Profiles to Your Endpoints.
Add a New Excepons Profile

Go to Endpoints > Policy management > Extension > Profiles and select + New Profile. Select
Plaorm and click Device Excepons > Next
STEP 2 | 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.
STEP 3 | 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.
Endpoint Security

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 5 | 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.
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.
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.
Endpoint Security
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
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.
Endpoint Security
Excepon Name Descrip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.
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 Security
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.
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.
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
Endpoint Security
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:
Plaorm Requirements and Limitaons
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.
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.
Endpoint Security
• 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
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.
Endpoint Security
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.
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
Endpoint Security
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,
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
Endpoint Security
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
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 Profile, click +New Profile. Select the
plaorm and click Host Firewall > Next.
STEP 2 | Fill-in General Informaon.

Enter the profile name and oponal descripon.
STEP 3 | 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 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
Endpoint Security
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.
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 5 | Save the profile.

When you are done, click Create. You can now configure a host firewall policy.
Endpoint Security
Manage Profiles
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 > Extension
Policies, you can:
• Edit profile—Right-click the profile and Edit. Change the profile sengs and Save. The change
takes effect in all policies enforcing this profile.
• Delete profile—Right-click the profile and 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 .
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.
STEP 1 | Create a policy.
From Endpoints > Policy Management > Extensions > Policy Rules, click +New Policy
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.
Endpoint Security
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
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.
Endpoint Security

Go to Endpoints > Policy Management > Extensions Profiles > Profiles and select + New
Profile. Select the Plaorm and click Host Firewall > Next
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.
Endpoint Security
Field Descripon
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.
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
Endpoint Security
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 > +New Policy.
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
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:
Endpoint Security
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
informaon to AD DS for to 5 minutes to report
operang system drives. the disk encrypon status
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
Endpoint Security
Requirement / Limitaon Windows Mac

Choose drive encrypon encrypted through another
method and cipher MDM.
strength. • In line with the operang
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
is compliant with the Cortex XDR disk
encrypon policy.
• Not Compliant—Indicates that the Cortex
XDR agent encrypon status on the
Endpoint Security
Field Descripon
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.
Configure a Disk Encrypon Profile

Go to Endpoints > Policy Management > Extensions > Profiles and select + New Profile.
Choose the Plaorm and select Disk Encrypon. Click Next.
Endpoint Security
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.
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.
Endpoint Security

Go to Endpoints > Policy Management > Extensions > Policy Rules > +New policy.
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.
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 | Now, Monitor the Endpoint Encrypon Status.
Endpoint Security
Invesgaon and Response
> Invesgate Incidents
> Invesgate Alerts
> Invesgate Endpoints
> Invesgate Files
> Response Acons
255
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
• Manage your Incident Starring
• Triage your Incidents
• Manage your Incidents
Cortex XDR 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.
• 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.
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.
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
Field Descripon
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.
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
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
Field Descripon
• 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.
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.
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.
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
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 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
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
• Process Execuon
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 Alerts
• Cortex XDR Alerts
• Triage Alerts
• Manage Alerts
• Alert Exclusions
• Causality View
Cortex XDR 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 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”.
<company domain>\<username>
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 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.
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.
Field Descripon
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)
• Prevented (Override-Lockout)
• Prevented (Post Detected)
• Prevented (Prompt Block)
• Prevented (Random-Drop)
Field Descripon
• 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. Alerts that match
an alert starring policy also display a purple star.
ALERT SOURCE Source of the alert: XDR Agent.
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.
CGO CMD Command-line arguments of the Causality Group

Owner.
Field Descripon
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
• 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
Field Descripon
• 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.
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.
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.
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
• Process Execuon
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

Event Type is Network Connecon) this is 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.
MITRE ATT&CK TECHNIQUE Displays the type of MITRE ATT&CK technique

and sub-technique on which the alert was
triggered.
MODULE For XDR Agent alerts, this field 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

Event Type is Network Connecon) this is 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, or Unknown. Right-click an alert
to Change Severity.
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

TARGET PROCESS NAME The name of the process whose creaon

TARGET PROCESS SHA256 The SHA256 value of the process whose creaon
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.
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.
<company domain>\<username>
Field Descripon
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
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 Cortex XDR 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 | If deemed malicious, consider responding by isolang the endpoint from the network.
STEP 4 | Remediate the endpoint and return the endpoint from isolaon.
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.
• Copy Alerts
• Analyze an Alert
• Pivot to Views
• Create Profile Excepons
• Add File Path to Malware Profile Allow List
• Retrieve Addional Alert Details
• Export Alert Details to a File
• Add an Alert Exclusion Policy
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.
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.
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.
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-
separated values (TSV) file.
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.
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.
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.
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:
• 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.
Invesgate Endpoints
• 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.
• 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.
• 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).
Field Descripon
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 30-day
expiraon limit 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.
• 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.
Field Descripon
• 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
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.
• 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
• 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)
Security Operaons • Retrieve Endpoint Files

• Iniate Malware Scan
• Abort Malware Scan
• Iniate Live Terminal
Field Acon
• 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:
• 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
Field Descripon
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.
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 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.
Field Descripon
• 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.
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.
Field Descripon
• 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.
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.
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.
Field Descripon
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 send addional forensic data to Palo Alto Networks Technical Support, 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 then download and send them to Technical Support.
STEP 2 | Select Retrieve Support File and click Next.
STEP 3 | Select the target endpoints (up to 10) from which you want to retrieve logs.
If needed, Filter the list of endpoints. For more informaon, refer to Filiter Page
Results.
In the next heart beat, the agent will retrieve the request to package and send all logs to Cortex
XDR.
STEP 6 | To track the status of a support log retrieval acon, return to the Acon Center.
When the status is Completed Successfully, you can right-click the acon, select
Addional data, and download the support logs. 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 7 | To view addional data and download the support logs, right-click the acon and select
Addional data.
You will see all endpoints from which files are being retrieved, including their IP Address,
Status, and Addional Data.
STEP 8 | When the acon status is Completed Successfully, you can right-click the acon and
download the retrieved logs.
Cortex XDR retains retrieved files for up to 30 days.
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.
• 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.
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.
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
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.
Module Windows Mac Linux
Iniate a Live Terminal

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 —
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.
Response acons are not supported for Android endpoints.
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 • A Cortex XDR agent 6.0 or a later release

• (VDI) Configure your network isolaon allow list in the
Agent Sengs Profile to ensure VDI sessions remain
uniterrupted.
Mac • A Cortex XDR agent 7.3 or a later release

• macOS 10.15.4 or a later release
• Ensure the 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.
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.
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.
• PowerShell 5.0 or a later release
• 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 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.
Broker VM
> Broker VM Overview

> Set up the Broker VM
> Manage Your Broker VMs
> Broker VM Noficaons
315
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 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

distributions.traps.paloaltonetworks.com
your Cortex XDR tenant. Used by tenants
deployed in all regions.
br-<xdr- Broker Service server for Federal (US

Government) deployment.
tenant>.xdr.federal.paloaltonetworks.com
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—Use the VHD image.
• Microso Azure—Use the VHD (Azure) image to Create a Broker VM Azure Image.
• 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.
STEP 4 | Navigate to https://<broker_vm_ip_address>/.
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 Cerficates 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. 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 covert the image to Amazon
Web Services (AWS) AMI.
To convert the image:
Broker VM
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, for example: broker-vms
STEP 3 | Open a command prompt and run:
gcloud config set project <project-name>
STEP 4 | Upload the VMDK image to the bucket, run:
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
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:
gcloud beta 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:
• Enter a meaningful Name for this image, for example: 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.
• 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
Broker VM
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:
Requirement Descripon
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.
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.
Broker VM
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.
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.
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 exi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
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.
Broker VM
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.
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.
Broker VM
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
• Agent Proxy—tms_proxy
• Syslog Collector—anubis
• WEC—wec
• Network Mapper—network_mapper
• Pathfinder—odysseus
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.
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
Broker VM
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 For
configuraon file, vi /etc/ restart_routes
network/routes. to take affect,
restart the
Eding the file triggers
machine and
an editor (VI). Enter the
broker VM.
parameters in a new line,
save, exit, and execute the
restart_routes command
to apply the updates.
route Modify your IP address sudo /sbin/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
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
Broker VM
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 ./-i eth0 -w /

command. 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.
Monitoring
> Cortex XDR Dashboard
> Monitor Cortex XDR Gateway Management Acvity
> Monitor Administrave Acvity
> Monitor Agent Acvity
> Monitor Agent Operaonal Status
351
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
• Incident Management Widgets
• Invesgaon Widgets
• System Monitoring
• User Defined Widgets
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.
Agent Status Breakdown Displays the total number of Cortex XDR by

the agent status.
Monitoring
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.
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.
Monitoring

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,
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.
Select the me scope in the upper right to
view the number of CVEs over the last 24
hours, 7 days, or 30 Days.
Hover over the graph to view the number of
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,
Monitoring

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.
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.
Monitoring
My Open Incidents by Severity Displays a breakdown of open incidents

assigned to the logged-in user, grouped by
severity, over the last 30 days. Click a severity
level to open a list of incidents filtered by that
severity level.
My MTTR Displays the Mean Time to Resolve (MTTR)

incidents assigned to the logged-in user,
compared to the defined Target MTTR.
Available date filters are 24 hours, 7 days, and
30 days.
Newest Incidents Displays the following details for the 5 most

recent incidents:
• Starred
• Severity
• ID
• Score
• 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:
Monitoring

• 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.
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.
Monitoring

Select a severity to open a filtered view of
incidents by the selected severity.
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.
Select the me scope in the upper right to
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.
Monitoring
Daily Consumpon A breakdown comparing the product/vendor

consumpon versus your allowed daily limit
over the past 24 hours, displayed in UTC.
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
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
• Incident Management Dashboard
• My Dashboard
• Security Admin Dashboard
• Security Manager Dashboard
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)
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 XDR 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:

• 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
alphabecal order.
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:

• High
• Medium
• Low
• Informational
Monitoring
Field Descripon
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:
• Scan
• File retrieval
• Terminate process
• Isolate
• Cancel isolation
• Payload execution
• Quarantine
• Restore
• Block IP address
• Unblock IP address
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
Monitoring
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
379
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 regrading 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 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 .
Use this workflow to configure noficaons for alerts. 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 ).
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 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 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® XDR™ 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® XDR™ 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 (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
Type—Agent Configuraon
Agent global uninstall password • Sub Type—Global uninstall password

updated • Status—Success
• Severity—Informaonal
Agent auto upgrade configuration • Sub Type—Agent auto upgrade

Log Forwarding
Message Details
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
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
Log Forwarding
Message Details
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

Notification ID {rule_id} Enabled • Sub Type—Enable Configuraon

Log Forwarding
Message Details
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

Api Key ID {id} was edited. • Sub Type—Edit Key

Log Forwarding
Message Details
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
• Severity—Low
{app_pretty} activated on broker • Sub Type—Applet Acvated

VM {device_id} • Status—Success
Log Forwarding
Message Details
• 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
• Severity—Low
Broker VM {device_id} was deleted • Sub Type—Remove Device

Log Forwarding
Message Details
• 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
• Severity—Low
Pathfinder credentials request • Sub Type—Edit Credenals

Log Forwarding
Message Details
• 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
Device control permanent • Sub Type—Edit

exceptions were edited • Status—Success
Log Forwarding
Message Details
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
A whitelist entry {vendor} • Sub Type—Edit

{product} {serial} was added • Status—Success
Log Forwarding
Message Details
from a violation event to profile • Severity—Informaonal
{profile_name}
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

Failed to delete a host disk • Sub Type—Delete

Log Forwarding
Message Details

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
Uninstall agent on {scope} • Sub Type—Create

Log Forwarding
Message Details
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
Could not include {endpoint-id} • Sub Type—Agent auto upgrade

and {x} other endpoints in auto • Status—Fail
upgrade
Log Forwarding
Message Details
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
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
Log Forwarding
Message Details
Endpoint group '{group_name}' • Sub Type—Edit Group

failed to update • Status—Fail
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
Type—Prevenon Policy Rules
Policy rules were updated • Sub Type—Edit
Log Forwarding
Message Details
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
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

Log Forwarding
Message Details
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
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}
Log Forwarding
Message Details
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

• 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

Log Forwarding
Message Details
• 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
•
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

Log Forwarding
Message Details
• 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
• 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

Log Forwarding
Message Details
• 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

• 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
Log Forwarding
Message Details
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

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
Log Forwarding
Message Details
{limit} limit of hits in the past
24 hours.
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
IOC enabled - indicator: • Sub Type—Enable

Enabled {count} IOCs • Sub Type—Enable

BIOC enabled - name: {rule_name} • Sub Type—Enable

Log Forwarding
Message Details
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

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
Log Forwarding
Message Details
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
{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
Log Forwarding
Message Details
{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
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}
Log Forwarding
Message Details
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—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

Log Forwarding
Message Details
Created starring policy {res} • Sub Type—Create Policy

Type—System
Temporary Devops access granted • Sub Type—Devops Access

to user: ({member}) • Status—Success
Alert Noficaon Format

Cortex XDR Agent 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
Log Forwarding
Category: MalwareAction: Detected

Host: <host name>
Username:<user name>
Excluded:No
Starred: Yes
Alert: <link to Cortex XDR app alert view>Incident: <link to
Cortex XDR app incident view>
Alert Name: Behavioral Threat Protection
Alert ID: 2412
Description: A really cool detection
Severity: Medium
Source: XDR Agent
Category: Exploit
Action: Prevented
Host: <host name>
Starred: Yes
Alert: <link to Cortex XDR app alert view>
Incident: <link to Cortex XDR app incident view>
Notification Name: “My notification policy 2 ”
Notification Description: “Starred alerts with medium severity”
Body Email Example
{
"original_alert_json":{
"uuid":"<UUID Value>",
"recordType":"threat",
"customerId":"<Customer ID>",
"severity":4,
"generatedTime":"2020-11-03T07:46:03.166000Z",
"originalAgentTime":"2020-11-03T07:46:01.372974700Z",
"serverTime":"2020-11-03T07:46:03.312633",
"isEndpoint":1,
"agentId":"<agent ID>",
"endPointHeader":{
"osVersion":"<OS version>",
"agentIp":"<Agent IP Address>",
"deviceName":"<Device Name>",
"agentVersion":"<Agent Version>",
"contentVersion":"152-40565",
"policyTag":"<Policy Tag Value>",
"securityStatus":0,
"protectionStatus":0,
"dataCollectionStatus":1,
"isolationStatus":0,
"agentIpList":[
"<IP Address>"
],
"addresses":[
{
"ip":[
"<IP Address>"
],
"mac":"<Mac ID>"
}
],
Log Forwarding
"liveTerminalEnabled":true,
"scriptExecutionEnabled":true,
"fileRetrievalEnabled":true,
"agentLocation":0,
"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":[
Log Forwarding
],
"techniqueId":[
],
"tacticId":[
],
"modules":[
],
"javaStackTrace":[
],
"terminate":0,
"block":0,
"eventParameters":[
"C:\\<file path>\\test.exe",
"B30--A56B9F",
"B30--A56B9F",
"1"
],
"sourceProcessIdx":0,
"fileIdx":0,
"verdict":1,
"canUpload":0,
"preventionMode":"reported",
"trapsSeverity":2,
"profile":"Malware",
"description":"WildFire Malware",
"cystatusDescription":"Suspicious executable detected",
"sourceProcess":{
"user":{
"userName":"<User Name>",
"userDomain":"<Domain Name>",
"domainUser":"<Domain Name>"\\"<User Name>"
},
"pid":1111,
"parentId":<Parent ID>,
"exeFileIdx":0,
"userIdx":0,
"commandLine":"\"C:\\<file path>\\test.exe\" ",
"instanceId":"<Instance ID>",
"terminated":0,
"rawFullPath":"C:\\<file path>\\Test.exe",
"fileName":"test.exe",
"sha256":"<SHA256 Value>",
"fileSize":"12800",
"innerObjectSha256":"<SHA256 Value>"
},
"policyId":"<Policy ID>"
}
},
"internal_id":<Internal ID>,
"external_id":"<External ID>",
"severity":"SEV_030_MEDIUM",
Log Forwarding
"matching_status":"MATCHED",
"end_match_attempt_ts":1604389636437,
"alert_source":"TRAPS",
"local_insert_ts":1604570760,
"source_insert_ts":160470366,
"alert_name":"WildFire Malware",
"alert_category":"Malware",
"alert_description":"Suspicious executable detected",
"bioc_indicator":null,
"matching_service_rule_id":null,
"attempt_counter":1,
"bioc_category_enum_key":null,
"alert_action_status":"REPORTED",
"case_id":111,
"is_whitelisted":false,
"starred":false,
"deduplicate_tokens":null,
"filter_rule_id":null,
"mitre_technique_id_and_name":[
""
],
"mitre_tactic_id_and_name":[
""
],
"agent_id":"80d2e314c92f6",
"agent_version":"7.2.1.2718",
"agent_ip_addresses":[
"10.208.213.137"
],
"agent_hostname":"<Agent Hostname>",
"agent_device_domain":"<Device Domain>",
"agent_fqdn":"<FQDN Value>",
"agent_os_type":"AGENT_OS_WINDOWS",
"agent_os_sub_type":"<Operating System Sub-Type> ",
"agent_data_collection_status":true,
"mac":"<Mac ID>",
"agent_is_vdi":null,
"agent_install_type":"STANDARD",
"agent_host_boot_time":[
1604446615
],
"event_sub_type":null,
"module_id":[
"WildFire"
],
"association_strength":null,
"dst_association_strength":null,
"story_id":null,
"is_disintegrated":null,
"event_id":null,
"event_type":[
1
],
"event_timestamp":[
1604389563166
],
Log Forwarding
"actor_effective_username":[
"<Domain Name>\\<User Name>"
],
"actor_process_instance_id":[
"<Actor>\/<Instance ID>"
],
"actor_process_image_path":[
"C:\\<file path>\\test.exe"
],
"actor_process_image_name":[
"test.exe"
],
"actor_process_command_line":[
"\"C:\\<file path>\\test.exe\" "
],
"actor_process_signature_status":[
"SIGNATURE_UNSIGNED"
],
"actor_process_signature_vendor":null,
"actor_process_image_sha256":[
"SHA256 Value>"
],
"actor_process_image_md5":[
"MD5 Value>"
],
"actor_process_causality_id":[
"<Actor>\/<Causality ID>"
],
"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
],
Log Forwarding
"causality_actor_process_image_md5":null,
"causality_actor_process_image_sha256":[
"SHA256 value>"
],
"action_file_path":null,
"action_file_name":null,
"action_file_md5":null,
"action_file_sha256":null,
"action_file_macro_sha256":null,
"action_registry_data":null,
"action_registry_key_name":null,
"action_registry_value_name":null,
"action_registry_full_key":null,
"action_local_ip":null,
"action_local_port":null,
"action_remote_ip":null,
"action_remote_port":null,
"action_external_hostname":null,
"action_country":[
"UNKNOWN"
],
"action_process_instance_id":null,
"action_process_causality_id":null,
"action_process_image_name":null,
"action_process_image_sha256":null,
"action_process_image_command_line":null,
"action_process_signature_status":[
"SIGNATURE_UNAVAILABLE"
],
"action_process_signature_vendor":null,
"os_actor_effective_username":null,
"os_actor_process_instance_id":null,
"os_actor_process_image_path":null,
"os_actor_process_image_name":null,
"os_actor_process_command_line":null,
"os_actor_process_signature_status":[
"SIGNATURE_UNAVAILABLE"
],
"os_actor_process_signature_vendor":null,
"os_actor_process_image_sha256":null,
"os_actor_process_causality_id":null,
"os_actor_causality_id":null,
"os_actor_process_os_pid":null,
"os_actor_thread_thread_id":[
1396
],
"fw_app_id":null,
"fw_interface_from":null,
"fw_interface_to":null,
"fw_rule":null,
"fw_rule_id":null,
"fw_device_name":null,
"fw_serial_number":null,
"fw_url_domain":null,
"fw_email_subject":null,
"fw_email_sender":null,
Log Forwarding
"fw_email_recipient":null,
"fw_app_subcategory":null,
"fw_app_category":null,
"fw_app_technology":null,
"fw_vsys":null,
"fw_xff":null,
"fw_misc":null,
"fw_is_phishing":[
"NOT_AVAILABLE"
],
"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.
Log Forwarding
Secon Descripon
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
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
Log Forwarding
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
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.
Log Forwarding
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
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-
Log Forwarding
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:
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
Log Forwarding
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 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
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,
Log Forwarding
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""]"
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"",
Log Forwarding
""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).
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,
Log Forwarding

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
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
Log Forwarding

• 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
Corresponds to the syslog 5 (Noce)
severity level.
• 2—Medium. Used for events that
Corresponds to the syslog 4 (Warning)
severity level.
Log Forwarding

• 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
• CYSTATUS_CYINJCT_MAPPING
• CYSTATUS_CYVERA_PREVENTION
• CYSTATUS_DANGEROUS_SYSTEM_SERVICE_CALLED
• CYSTATUS_DEMO_EVENT
• CYSTATUS_DEP_SEH_INF_VIOLATION
Log Forwarding

• 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
• CYSTATUS_INJ_APPCONTAINER_FAILURE
• CYSTATUS_INJ_CTX_FAILURE
• CYSTATUS_JAVA_FILE
• CYSTATUS_JAVA_PROC
• CYSTATUS_JAVA_REG
Log Forwarding

• CYSTATUS_JIT_EXCEPTION
• CYSTATUS_LINUX_BRUTEFORCE_PREVENTED
• CYSTATUS_LINUX_ROOT_ESCALATION_PREVENTED
• CYSTATUS_LINUX_SHELLCODE_PREVENTED
• CYSTATUS_LINUX_SOCKET_SHELL_PREVENTED
• CYSTATUS_LOCAL_ANALYSIS
• CYSTATUS_MACOS_DLPROT_CWD_HIJACK
• CYSTATUS_MACOS_DLPROT_DUPLICATE_PATH_CHECK
• CYSTATUS_MACOS_G02_BLOCK_ALL
• CYSTATUS_MACOS_G02_SIGNER_NAME_MISMATCH
• CYSTATUS_MACOS_G02_SIGN_LEVEL_BELOW_MIN
• CYSTATUS_MACOS_G02_SIGN_LEVEL_BELOW_PARENT
• CYSTATUS_MACOS_MALICIOUS_DYLIB
• CYSTATUS_MACOS_ROOT_ESCALATION_PREVENTED
• CYSTATUS_MALICIOUS_APK
• CYSTATUS_MALICIOUS_DLL
• CYSTATUS_MALICIOUS_EXE
• CYSTATUS_MALICIOUS_EXE_ASYNC
• CYSTATUS_MALICIOUS_MACRO
• CYSTATUS_MALICIOUS_STRING_DETECTED
• CYSTATUS_MEMORY_USAGE_LIMIT_EXCEEDED
• CYSTATUS_NOP_SLED_DETECTED
• CYSTATUS_NO_MEMORY
• CYSTATUS_NO_REGISTER_CORRECTED
• CYSTATUS_PREALLOCATED_ADDR_ACCESSED
• CYSTATUS_PROCESS_CREATION_VIOLATION
• CYSTATUS_QUARANTINE_FAILED
• CYSTATUS_QUARANTINE_SUCCEEDED
• CYSTATUS_RANSOMWARE
• CYSTATUS_RESTORE_FAILED
• CYSTATUS_RESTORE_SUCCEEDED
• CYSTATUS_ROP_MITIGATION
• CYSTATUS_SEH_CRITICAL
• CYSTATUS_SEH_INF_CRITICAL
Log Forwarding

• 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
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.
Log Forwarding

• 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.
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)
Log Forwarding

• 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.
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
Log Forwarding

• 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
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:
Log Forwarding
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.
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
Log Forwarding

• system—licensing, provisioning, tenant,
userAuthencaon, workerProcessing
• agent_log—agentFlow

(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.
messageCode System-wide unique message code.
Log Forwarding
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


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.
Analycs Logs
Syslog format: recordType, class, FUTURE_USE, eventType, eventCategory, generatedTime,
serverTime, agentTime, tzOffset, FUTURE_USE, facility, customerId, trapsId, serverHost,
Log Forwarding
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
messageData/executionCount: 4179
Log Forwarding

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).

2017-01-24T09:08:59Z).

Log Forwarding

in minutes.


record.


endpoint.

• 1—Windows
• 2—OS X/macOS
• 3—Android
• 4—Linux


6.1.7601.19135.
Log Forwarding

architecture
architecture

was logged.

event.
special handling.
details.

• 0—Protected
sha256 Hash of the file using SHA256 encoding.
type Type of file:
Log Forwarding

• 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.
• 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.
Log Forwarding
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:
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:
Log Forwarding
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:
systemManagement
sam

Log Forwarding

(for example, 2017-01-24T09:08:59Z).

2017-01-24T09:08:59Z).


record.


endpoint.

event.
special handling.
Log Forwarding

details.

level:
severity level.
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.
Log Forwarding


in minutes.

• 1—Windows
• 2—OS X/macOS
• 3—Android
• 4—Linux


6.1.7601.19135.

architecture
architecture

was logged.
Log Forwarding

• 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.
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
Log Forwarding
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
messageData/executionCount: 4179

quotas:
• config—Cortex XDR administraon and
configuraon changes.
• system—Automated system management
and agent reporng events.
Log Forwarding

• 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).

2017-01-24T09:08:59Z).


in minutes.
Log Forwarding


record.


endpoint.

• 1—Windows
• 2—OS X/macOS
• 3—Android
• 4—Linux


6.1.7601.19135.

Log Forwarding

architecture
architecture

was logged.

event.
special handling.
details.

• 0—Protected
sha256 Hash of the file using SHA256 encoding.
type Type of file:

• 0—Unknown
• 1—PE
Log Forwarding

• 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.
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.
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
471
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
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 it’s 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:

• 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:
Field Descripon
Status Indicator Idenfies whether the child tenant is connected.

( )
TENANT ID The Cortex XDR tenant ID.
Managed Security
Field Descripon
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 one or more of your child
tenants, select the tenants 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.
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:
• 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:

• 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 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.

Cortex XDR Prevent 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 Prevent Admin

Uploaded by

Copyright:

Available Formats

Cortex® XDR™ Prevent

About the Documentaon

Get Started with Cortex® XDR™ Prevent................................................. 23

Endpoint Security.......................................................................................... 145

Create an Agent Installaon Package.....................................................................148

Invesgaon and Response........................................................................ 255

Triage Alerts.................................................................................................................. 280

Broker VM....................................................................................................... 315

Run or Schedule Reports...........................................................................................366

> Cortex® XDR™ Prevent Architecture

Cortex® XDR™ Prevent Architecture

• Palo Alto Networks cloud-delivered security services:

Cortex XDR versus Tradional Endpoint Protecon

Exploit Protecon Overview

Malware Protecon Overview

• Malware Protecon for Mac

Malware Protecon for Windows

Malware Protecon for Mac

Malware Protecon for Linux

Malware Protecon for Android

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 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-oﬀ 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

Set up Cortex XDR Prevent Overview

STEP 1 | Plan Your Cortex XDR Deployment.

STEP 2 | Acve Cortex Data Lake.

STEP 3 | Set up Cortex® XDR™

STEP 5 | Set up Endpoint Protecon.

STEP 6 | (Oponal) Set up Outbound Integraon.

STEP 7 | (Oponal) Set up Managed Security.

STEP 8 | Get started using Cortex XDR!

Plan Your Cortex XDR Deployment

Deployment Type Deployment Consideraons

If you plan to stream data from a Cortex

• US—All Cortex XDR logs and data remain within

Deployment Type Deployment Consideraons

Aer the migraon, WildFire India

Migrate from Traps Endpoint Security Manager to Cortex XDR

Table 1: Supported Migration Paths

Traps agent Cortex XDR agent

4.2.7 (all OS versions) • 5.0.10

4.2.8 (Windows only) 7.3.1

STEP 2 | Import hash overrides as hash excepons in Cortex XDR.

STEP 3 | Migrate trusted signers and allow list paths.

STEP 4 | Migrate rules which disable protecon on processes.

Diﬀerences between Endpoint Security Manager and Cortex XDR

Feature Endpoint Security Manager Cortex® XDR™

Visibility into all ﬁle Hash Control Enhanced ﬁle acvity

Administrave control to Hash Control Response > Acon Center >

Security events search criteria Security Events—Endpoint, Mul-faceted ﬁlters and

Log forwarding SIEM, Syslog, Panorama, Log forwarding to a Syslog