Home / Attack Graphs

Attack Trees and Attack Graphs

Attack trees and attack graphs are the workhorses of attack modeling. Trees explain alternative strategies to reach a goal. Graphs compute the paths that become possible when privileges and reachability change over time. If you want a model that drives engineering decisions, these two families are a strong starting point.

Attack Trees

An attack tree starts with a goal and decomposes it into sub goals until you reach actions that are concrete enough to test. Trees are easy to communicate and easy to extend. They are also the natural place to record assumptions, such as whether an attacker can obtain credentials or access a maintenance port.

Attack Graphs

An attack graph represents states and transitions. A node can represent a capability, a privilege, or a condition that becomes true. An edge represents an exploit or action that moves the attacker forward once prerequisites hold. Graphs allow you to ask computational questions: what is reachable, what is the shortest or most likely path, and which control breaks the most paths.

Practical Graph Construction with MulVAL Style Logic

One practical approach is logic based graph generation, where you encode facts about the environment, vulnerabilities, and attacker capabilities, then infer reachable states. MulVAL is a well known example of this approach. In modern environments, the inputs often come from asset inventories, configuration management, identity graphs, and vulnerability scanners.

Scoring and Prioritization

Scoring is not just about severity. In attack graphs, you care about how a vulnerability changes reachability. A vulnerability with a high CVSS score might not matter if it is not on a reachable path. Conversely, a medium issue on a critical choke point can dominate risk. Prioritize by path criticality, exploit prerequisites, and control leverage.

OT and CPS Extensions

In OT and cyber-physical systems, a pure cyber graph is incomplete. Add process constraints and plant realities: which engineering workstations can reach which controllers, which protocols are in use, what safety interlocks exist, and what physical impact is possible from a given control change. The goal is to connect cyber progression to operational consequence.

From Model to Defense

Use technique knowledge bases to operationalize your graph. Map each step to MITRE ATT&CK techniques, then map mitigations and detections through MITRE D3FEND or internal control catalogs. This creates a measurable link from attack paths to defensive coverage.

Key References

  1. Schneier: Attack Trees (1999)
  2. Sheyner, Jha, Wing: Automated Generation and Analysis of Attack Graphs (2002)
  3. Ou et al.: MulVAL (2005)
  4. FIRST: CVSS v3.1 Specification
  5. MITRE ATT&CK for ICS
  6. MITRE D3FEND
  7. NIST SP 800-82 Rev. 2 (ICS Security)

FAQ

What is the key difference between an attack tree and an attack graph?
A tree decomposes a goal into alternative strategies. A graph represents states and transitions so you can compute reachability and multi-stage paths as privileges and conditions change.
Do I need CVSS to prioritize paths?
No. CVSS can help, but path criticality is often more important. Prioritize by reachability, prerequisites, and which controls break the most high impact paths.
What are common mistakes in graph projects?
Overly detailed nodes, missing prerequisites, stale asset inventory, and ignoring identity and trust boundaries. In OT, the biggest mistake is failing to link cyber steps to process consequence.
How do I operationalize a graph?
Map steps to ATT&CK techniques, then map detections and mitigations to your control catalog. Track coverage by path segments and validate with targeted tests.


Jump To

Companion hubs

If you want a dedicated collection of attack graph resources and tooling, see:

Contact