What is Causality? ↗
Learn more about Causality in Cortex XSIAM.
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.
Even the most complicated investigations take just a few moments for a novice analyst, during which causality reveals answers to critical questions, such as:
What was the root cause?
What might be the damage?
What’s the scope? Are there any related issues?
Who’s involved?
Which steps are required to contain, mitigate and recover?
Are similar threats prevalent in the environment?
What can be done to reduce the risk of the same thing happening again?
To achieve this, Palo Alto Networks invested and patented the causality engine and the ways it works.
Causality chains are built using a deep understanding of each operating system (OS) and the way it works, which processes fulfil the various functions and more. Causality chains in Windows, macOS, and Linux work with the same guidelines, with different processes and methods used to decide how to build chains.
There are some processes in the OS that have very specific roles to fill. For example, services.exe and explorer.exe are used mainly to spawn other processes. This means that causality chains don’t show these processes by default and start from their child processes as these are only OS processes doing their job; yet, you can manually add them by right clicking on the Causality Group Owner (CGO) and adding the parent process.
Cortex XSIAM tracks Remote Procedure Call (RPC) requests between processes and it doesn't break the casualty chain into sub chains, so the analyst still sees the full chain of execution, including actions done via RPC. Same goes for code injection, as Cortex XSIAM tracks the new threads that are started as a result of such actions and can tie anything that happens as a result to the original injecting processes and its causality chain.
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.