Learn more about the Cortex XSIAM main concepts.
Cortex XSIAM
Cortex XSIAM, or extended security intelligence and automation management, is a cloud-delivered, integrated SOC platform that unifies key functions, including EDR, XDR, SOAR, ASM, UEBA, TIM, and SIEM. Cortex XSIAM streamlines your cybersecurity infrastructure by consolidating multiple products into a unified platform.
Sensors
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.
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 XSIAM 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 XSIAM, 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 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.
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 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.
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 XSIAM 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 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.
Data is ingested by Cortex XSIAM 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 XSIAM 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 XSIAM:
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 XSIAM 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 XSIAM 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 XSIAM are maintained in the data's original state. There are two types of raw logs:
Unstructured logs: Any unstructured log coming in to Cortex XSIAM 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 XSIAM 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.
Automation and Integrations
Cortex XSIAM ingests raw data, 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 pre-built collections of security tools, configurations, and content designed to enhance the capabilities of the Cortex XSIAM platform. Content packs are created by Palo Alto Networks, technology partners, consulting companies, MSSPs, customers, and individual contributors. The content packs may include a variety of different components, such as integrations, scripts, playbooks, and widgets.
Playbooks
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.