Concepts - Administrator Guide - Cortex XDR - Cortex - Security Operations

Cortex XDR Pro Administrator Guide

Cortex XDR
Creation date
Last date published
Administrator Guide

Learn more about the Cortex XDR main concepts.

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

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

With a Cortex XDR Pro per GB license, a sensor can be any of the following:

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

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

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

With a Cortex XDR Pro per Endpoint license, a sensor can be any of the following:

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

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

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

Log stitching allows you to:

  • Run investigation queries based on stitched network and endpoint logs

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

  • Investigate correlated network and endpoint events in the Network Causality View

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

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

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

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

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

Causality Group Owner (CGO)

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


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