Introduction to Cortex XDR

As the world continues to see an escalation in the volume, sophistication and impact of data breaches and attacks, security operation centers are dealing with an ever-increasing volume of alerts from multiple security products. Security analysts are often manually correlating events from public cloud, identity access, endpoint products and network and firewall events. 

The goal of Cortex XDR is to increase operational efficiency of the security operations center. Cortex XDR accomplishes this through reducing alerts by combining similar events, stitching together logs from different sources and preventing as many threats as possible early in the attack cycle.

Cortex 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, insider abuse and remediate compromised endpoints. Cortex XDR combines functionality from Endpoint Protection, Endpoint Detection and Response, Network Traffic Analysis and User Behavior Analytics into a single console.

Cortex XDR architecture

The foundation of Cortex XDR is the Cortex Data Lake. Logs and events from the PAN-OS Next Generation Firewall, Prisma Access, GlobalProtect, Prisma Cloud, Endpoints, Public Cloud and third-party data such as identity providers, NetFlow and Syslog are collected in the Data Lake. As these events are streamed to the Cortex Data Lake, XDR performs machine learning to normalize logs and stitch these events together using the Analytics Engine. 

The Cortex XDR Console is managed in a cloud-hosted web application. There are no web or database servers to deploy or update for management of the Cortex XDR Agents. 

The Cortex XDR Agent can be installed on Windows, Linux, macOS, iOS, Android and Kubernetes endpoints. 

The Cortex XDR Console can ingest logs using native APIs from Okta, PingOne, Azure, Google Cloud, AWS, Workday, ServiceNow, Proofpoint, Office 365 and more.

Data from third-party firewalls, DHCP servers, NetFlow and Syslog can be ingested into the Cortex Data Lake via the Broker VM. The Broker VM can also provide connectivity to the Cortex XDR Console via Local Agent Proxy for air-gapped environments. 

Endpoint protection flow

Cortex XDR takes a more efficient and effective approach to preventing attacks by eliminating the need for signature-based endpoint security products. Rather than keeping up with the ever-growing list of known threats and malicious files, Cortex XDR sets up a series of roadblocks—referred to as traps—that prevent the attacks at their initial entry points; the point where legitimate executable files are about to unknowingly allow malicious access to the system.

Exploit protection

Let's consider a scenario where a user has received a specially crafted PDF document that exploits a known vulnerability in the PDF reader. If the user attempts to open the PDF file, Cortex XDR will inject code in the PDF reader application that will monitor known attacks such as buffer overflows and heap corruption.

In addition to automatically protecting processes from such attacks, the Cortex XDR agent collects forensic and telemetry data to report to the XDR Console and notifies the user and SOC about the event.

Malware protection flow

The Cortex XDR agent provides malware protection in a series of four evaluation phases:

Phase 1: Evaluation of Child Process Protection Policy

In this example, if a user tries to open a Microsoft Word document (using the winword.exe process) containing a macro that tries to launch a blocked child process, such as PowerShell.exe, the Cortex XDR agent blocks the child process and reports the event to Cortex XDR. 

Phase 2: Evaluation of the Restriction Policy

In this example, you might have a restriction rule that blocks executable files launched from network locations or external drives. The Cortex XDR agent blocks the file from executing and reports the security event to Cortex XDR.

Phase 3: Hash Verdict Determination

To determine a verdict for a file, the Cortex XDR agent evaluates the file in the following order:

1. Hash Exception – A hash exception enables you to override the verdict for a specific file without modifying the settings in the Malware Security profile. For example, you may want to override a benign verdict or allow a file that has a malware verdict to run due to false positive.
2. Highly Trusted Signers – Files that are signed with a certificate from a highly trusted source, such as Microsoft or Apple, are permitted to run and files signed by an untrusted signer are blocked.
3. WildFire Verdict – 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 blocks, quarantines the file and reports the security event to the Cortex XDR console. If the verdict is benign, the Cortex XDR agent moves on to the next stage of evaluation using Local Analysis.
4. Local Analysis – When an unknown executable, DLL or macro attempts to run, the Cortex XDR Agent will use the Local Analysis Engine to determine if the file is malware by using a static set of patterns-matching rules that inspect multiple file features and attributes, and a statistical model that was developed with machine learning on WildFire threat intelligence. The Cortex XDR Agent can rely on the local analysis verdict until an official verdict from WildFire.

Phase 4: Evaluation of Malware Security Policy

If the prior phases do not identify the file as malware, the Cortex XDR Agent observes the behavior of the file and applies additional malware protection rules. 

If a file exhibits malicious behavior, such as encryption-based activity common with ransomware, the Cortex XDR Agent blocks the file and reports the security event to the Cortex XDR Console.

Incident investigation

Cortex XDR will identify attack methods in each incident using the MITRE ATT&CK framework. The MITRE ATT&CK framework is a common knowledge base that security analysts can leverage to understand threat models and methods of attacks. 

The Causality Analysis Engine correlates activity from  events streamed to the Cortex Data Lake to establish causality chains that identify the root cause of  alerts. When a malicious file, behavior or technique is detected, Cortex XDR correlates all available data across your events to display the sequence of activity that led to the alert, called the causality chain. The causality chain is built from processes, events, insights and alerts associated with the incident. The Causality Group Owner (CGO) is the process in the causality chain that the Causality Analysis Engine has identified as being responsible for the activities that led to the alert.

Depending on the outcome, security analysts can isolate the endpoint, initiate a Live Terminal to perform file system investigations or run scripts remotely or block files.

Analysts can also leverage the XQL query language to search across events in the Cortex Data Lake to create reports, build custom widgets or perform threat hunting. 

Conclusion

Cortex XDR increases operational efficiency of the security operations center by improving your security posture with complete visibility from endpoints, network, identity and public cloud incidents. Cortex XDR reduces the alert overload seen by many analysts in the security operations center by combining similar incidents by stitching together logs from different sources.