Concepts - Administrator Guide - Cortex XSIAM - Cortex - Security Operations

Cortex XSIAM Administrator Guide

Cortex XSIAM
Creation date
Last date published
Administrator Guide

Learn more about the Cortex XSIAM 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 XSIAM 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 XSIAM license type.

  • 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

  • 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 XSIAM can analyze, you only need to deploy one type of sensor to begin detecting and stopping threats with Cortex XSIAM.

To provide a complete and comprehensive picture of the events and activity surrounding an event, Cortex XSIAM 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 XSIAM 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 XSIAM 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 XSIAM 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.

Automation and Integrations

Cortex XSIAM ingests aggregated alerts and indicators of compromise (IOCs) from detection sources, such as security information, network security tools, threat intelligence feeds, and mailboxes, and then executes automatable, process-driven playbooks to enrich and respond to these incidents. These playbooks coordinate across technologies, security teams, and external users for centralized data visibility and action.

Content Packs

All Cortex XSIAM content is organized in packs. Packs are groups of artifacts that implement use cases in the product. Content packs are created by Palo Alto Networks, technology partners, consulting companies, MSSPs, customers, and individual contributors. Content packs may include a variety of different components, such as integrations, scripts, playbooks, and widgets.


Playbooks are self-contained, fully documented prescriptive procedures that query, analyze, and take action based on the gathered results. Playbooks enable you to organize and document security monitoring, orchestration, and response activities. There are several out-of-the-box playbooks that cover common investigation scenarios. You can use these playbooks as-is, or customize them according to your requirements. Playbooks are written in YAML file format using the COPS standard.

A key feature of playbooks is the ability to structure and automate security responses, which were previously handled manually. You can reuse playbook tasks as building blocks for new playbooks, saving you time and streamlining knowledge retention.