Learn more about the Cortex XDR main concepts.
Cortex XDR
With Endpoint Detection and Response (EDR), enterprises rely on endpoint data as a means to trigger cybersecurity incidents. As cybercriminals and their tactics have become more sophisticated, the time to identify and contain breaches has only increased. Cortex Extended Detection and Response (XDR) goes beyond the traditional EDR approach of using only endpoint data to identify and respond to threats by applying machine learning across all your enterprise, network, cloud, and endpoint data. This approach enables you to quickly find and stop targeted attacks and insider abuse and remediate compromised endpoints.
Sensors
Cortex 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.
Causality
Causality is the idea of telling a story in a simple and coherent manner and in a proper context. With the purpose of leading security teams to actionable outcomes.
Palo Alto Networks products, such as Next-Generation Firewall (NGFW) or the Cortex XDR Agent, can be configured to send rich and detailed data about all activities to the Strata Logging Service, not only items related to attacks. This means that millions of data points are collected about every entity every single day. Analyzing so much data as log lines is practically impossible, so Cortex XDR takes these data points and continuously stitches them automatically to ‘Causality Chains’. This automates the dot-connection process that an investigator would otherwise have to do manually during an investigation. This process happens constantly for all collected data points, such as processes, files, network connections, and more, regardless of prevention, detection, or alerts of any kind. With causality, when analysts decide to investigate alerts or go on a hunt, they don't need to manually connect the dots getting distracted with millions of irrelevant data points, and instead they can focus only on data related to the investigation.
Processes that are used to spawn other sub processes are called spawners. Those processes are known to start other processes as part of the normal flow of the operating system (OS). Examples of such processes are explorer.exe, services.exe, wininit.exe, userinitt.exe, and more. When spawner processes are started by a non-spawner process, they are not considered spawners. In Cortex XDR, we don’t distinguish between a Causality Group Owner (CGO) and spawner, calling both CGO.
userinit.exestartsexplorer.exe:explorer.exeis considered a spawner, as this is what we expect to see in the OS.cmd.exestartsexplorer.exe:explorer.exeis NOT considered as a spawner as it’s not the role ofcmd.exeto startexplorer.exe.
The child processes of a spawner are considered as CGOs and they start off the causality chain.
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.
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.
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. A CGO is always the child of a spawner, so it’s the first process in the operating system (OS) chain of execution that is not loaded by default as part of what’s expected in a normal OS flow. All sub-processes started by the CGO are linked to it, and help analysts quickly identify the root cause of why something happened.
Note
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.
Each causality chain gets a unique ID called a CID. All actions on this chain, such as process execution, registry changes, and network connections, receive the same ID. This means that whenever the user queries about a given action, for example who connected to a malicious IP, the response not only includes the process who performed it or the user, it includes all actions related to the same CID. This shows the entire chain of execution alongside all other actions performed with the connection to the malicious IP.
This concept is important because any alert that is triggered about any action is also mapped to the same CID, meaning that one chain of execution displays all processes and alerts associated with the relevant CID. Alerts on the same CID is also one of the methods Cortex XDR uses to group alerts into an incident.
Log Stitching
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.
Data is ingested by Cortex XDR from various sources, such as the Cortex XDR agent, Palo Alto Networks Next-Generation Firewall (NGFW), Prisma Access, and many third party sources, such as Check Point, Cisco, Fortinet, Azure AD, Active Directory, and more.
As data is ingested, Cortex XDR applies a data digestion layer that looks at the data coming in trying to understand if there are any pieces of information that represent the same session but from different points of views, and unifies them into a single session ‘story’ that can be queried, investigated, and also used for detection and machine learning (ML).
Actor types
The following actor types are available in Cortex XDR:
Note
For more information on the specific xdr_data dataset fields grouped according to the different actors, see the Cortex XQL Schema Reference Guide.
The action fields include the actual activities that took place and recorded by the agent. It includes the IPs and domains communicated with, the files accessed, written, deleted, and more, registry changes, and processes which were started.
To search for a connection to an IP, look at the field
action_remote_iporaction_local_ip.To search for a file name that was changed, look for the field
action_file_name.To search for a process that was started, look for the field
action_process_image_name.
The actor fields represent the process which performed the action. To search for a process which wrote a file, look for actor_process_image_name for the process name and action_file_name for the file name.
The OS actor is the process identified by the operation system as the process that performed the action. In some cases, such as injection or RCP, the process doing an activity is not the process that requested it.
The Causality actor—also referred to as the causality group owner (CGO)—is the parent process in the execution chain that the Cortex XDR/XSIAM agent identified as being responsible for the entire chain of execution. Seeing the processes and alerts down to the root cause speeds up the investigation process.
The DST Action actor is the receiving process for actions performed remotely from one host to another. Cortex XDR can connect the dots when events happen between machines. If process A on host A connects to process B on host B, process A will be the actor process and process B will be the destination actor that receives the connection.
Similar to an OS actor, the actor seen by the operating system (OS) is not necessarily the true actor that’s doing an action. The DST OS actor keeps parity with what the OS sees from a process point of view as Cortex XDR keeps track of actions like RPC and injections. The DST OS actor is the process identified by the operating system on the remote host as the process that performed an action that was responsible for the entire chain of execution.
Similar to the Causality Actor, the DST Causality actor, also called the DST GCO, is the process identified by the operation system on the remote host as the process that performed an action that was responsible for the entire chain of execution.
Raw logs
Raw logs saved in Cortex XDR are maintained in the data's original state. There are two types of raw logs:
Unstructured logs: Any unstructured log coming in to Cortex XDR is left completely unchanged, and only metadata is added to the raw data. On top of this data, stories and models are created that don't "touch" the original data.
Structured logs: For structured logs, such as CEF, LEEF, and JSON, Cortex XDR decouples the key-value pairs, and saves them in a table format. The essence of the data is left unchanged as the values are unaltered, with the exception of timestamps that can be altered to an epoch format; yet, the field still holds the same information, but in a new format.
It is not possible for any user to alter the raw data once it's been ingested. Only users with the designated permissions, such as an Instance Administrator, can delete a raw data table.