Attack Trees vs Attack Paths in Automotive Cybersecurity: When to Use Each

Automotive cybersecurity engineers face a critical modeling decision when performing Threat Analysis and Risk Assessment (TARA): should they use attack trees, attack paths, or both? These two approaches represent fundamentally different ways of thinking about how adversaries compromise vehicle systems. Understanding when and how to apply each technique is essential for thorough threat modeling under ISO/SAE 21434 and UNECE R155.

This guide provides a deep technical comparison of attack trees and attack paths, traces their academic origins, demonstrates both with real automotive scenarios, and shows how modern tooling can unify both models into a single knowledge graph for comprehensive risk analysis.

Origins and Foundational Concepts

Attack Trees: Hierarchical Goal Decomposition

Attack trees were formalized by Bruce Schneier in his seminal 1999 paper “Attack Trees: Modeling Security Threats.” The concept itself has roots in fault-tree analysis from reliability engineering, adapted for adversarial security modeling. Schneier proposed a top-down decomposition where the root node represents the attacker’s ultimate goal, and child nodes represent sub-goals or methods that achieve the parent goal.

Each node in an attack tree is connected to its children by either an AND gate (all children must be achieved) or an OR gate (any one child suffices). Leaf nodes represent atomic attack actions that cannot be further decomposed. This hierarchical structure enables systematic enumeration of all possible ways to achieve an attack goal, along with quantitative analysis of cost, time, skill requirements, and probability.

The power of attack trees lies in their completeness guarantee: if the decomposition is thorough, the tree captures every conceivable combination of actions that leads to the root goal. This makes them particularly valuable for security certification processes where assessors require evidence of comprehensive threat coverage.

Attack Paths: Sequential Exploitation Chains

Attack paths emerged from graph-based security modeling and network penetration analysis in the early 2000s. Unlike the top-down goal decomposition of attack trees, attack paths model the sequential chain of actions an attacker follows from an initial entry point to a target asset. Each step in the path represents an exploit or lateral movement action that transitions the attacker from one system state to the next.

Attack paths are directional and temporal: they reflect the order in which exploits must occur. This makes them natural for modeling multi-stage attacks across networked vehicle architectures where an attacker must traverse multiple trust boundaries. Attack path analysis is closely related to attack graph theory from academic research by researchers such as Sheyner, Jha, and others who formalized the concept of automatically generating attack graphs from network configurations and vulnerability databases.

The strength of attack paths is their operational realism. They model attacks the way adversaries actually execute them, step by step, through real interfaces and real vulnerabilities. This makes them invaluable for penetration testing, red team exercises, and post-incident forensic reconstruction.

Structural Comparison

Attack Tree Structure

An attack tree is a rooted directed acyclic graph (DAG) organized in levels. Consider a simplified attack tree for the goal “Execute arbitrary code on the Telematics Control Unit (TCU):”

Each leaf node can be annotated with feasibility parameters: elapsed time, expertise level, equipment required, knowledge of item, and window of opportunity. The tree structure allows propagation of these values upward using standard rules: for AND gates, values are summed; for OR gates, the minimum (easiest path) is selected.

Attack Path Structure

An attack path is a linear or branching sequence of steps. Consider an attack path for the same TCU compromise, but modeled from the attacker’s perspective as a sequential chain:

The path shows exactly which interfaces and components the attacker interacts with in sequence. Each arrow represents a trust boundary crossing or privilege escalation that maps to a specific vulnerability, misconfiguration, or design weakness.

ISO/SAE 21434 Context: Attack Feasibility Rating

ISO/SAE 21434 Clause 15 and Annex G define attack feasibility assessment methods that directly relate to both modeling approaches. The standard provides two primary methods:

Attack Potential-Based Approach

The attack potential method evaluates five factors for each attack: elapsed time, specialist expertise, knowledge of the item, window of opportunity, and equipment required. Each factor is scored, and the sum determines an overall attack potential value that maps to a feasibility rating (High, Medium, Low, Very Low).

Attack trees naturally support this method because each leaf node represents an atomic attack step that can be independently scored. The tree’s AND/OR structure provides clear aggregation rules: AND gates sum the attack potentials (the attacker must overcome all barriers), while OR gates take the minimum (the attacker chooses the easiest path).

CVSS-Based Approach

The CVSS-based method maps Common Vulnerability Scoring System base metrics to the automotive context. This approach works well with attack paths because each step in the path can reference a specific CVE or vulnerability class with a CVSS score. The overall path feasibility is constrained by its weakest link, namely the step with the lowest exploitability score, since every step must succeed for the path to complete.

In practice, many automotive TARA practitioners combine both approaches: using attack trees for systematic completeness during the concept phase, and attack paths during development and verification phases when specific components and their vulnerabilities are better understood.

Automotive Example: Remote Code Execution via Telematics

Attack Tree Perspective

When modeling “Achieve remote code execution on TCU” as an attack tree, the analyst starts with the goal and systematically decomposes it. The first level identifies all remote interfaces: cellular, Wi-Fi, Bluetooth, satellite (for V2X), and the OTA update channel. Each interface branches into specific vulnerability classes: memory corruption bugs in the protocol stack, authentication bypass in the management interface, or cryptographic weaknesses in the communication channel.

The tree might have 30 to 50 leaf nodes across all branches, providing comprehensive coverage of every conceivable remote attack vector. An analyst can prune branches where controls are already in place (e.g., if the Bluetooth interface uses pairing with PIN and has limited range, that branch has a very high attack potential, meaning low feasibility) and focus security investment on the highest-risk branches.

Attack Path Perspective

The same TCU scenario modeled as attack paths produces concrete exploitation chains. One path might be: “Attacker on the Internet sends a crafted MQTT message to the TCU’s cloud backend, exploiting a deserialization vulnerability in the backend API (Step 1), which returns a malicious configuration payload to the TCU (Step 2), causing a buffer overflow in the configuration parser (Step 3), achieving code execution on the TCU application processor (Step 4), from which the attacker pivots to the CAN gateway (Step 5).”

This path-based view reveals critical dependencies: if the backend API validates input correctly, the entire path is blocked at Step 1. This insight directly informs security control placement, suggesting that input validation at the cloud API is the most cost-effective mitigation point.

Automotive Example: CAN Bus Message Injection

Attack Tree Perspective

For the goal “Inject arbitrary CAN messages onto the vehicle bus,” an attack tree decomposes into physical access paths (OBD-II port, direct wiring, aftermarket device compromise) and remote paths (through compromised ECUs with CAN access). Each branch further decomposes: the OBD-II path requires physical access to the vehicle interior and a CAN-capable tool; the compromised ECU path requires first compromising an ECU with both external connectivity and CAN bus access.

The tree reveals that the OBD-II path has lower attack potential (any technician with a $20 CAN adapter can do it) but requires physical proximity, while the remote path through a compromised infotainment unit has higher potential but no physical access requirement. This comparison directly influences whether the security response should focus on OBD-II port protection or network segmentation.

Attack Path Perspective

An attack path for CAN message injection might trace: “Attacker connects to the vehicle’s Wi-Fi hotspot using default credentials (Step 1), accesses the infotainment unit’s internal network (Step 2), exploits a known vulnerability in the infotainment OS to gain root access (Step 3), uses the infotainment unit’s CAN interface to send crafted messages through the central gateway (Step 4), the gateway forwards messages to the powertrain CAN bus because no message authentication (SecOC) is deployed (Step 5).”

This path immediately highlights the critical role of the central gateway’s filtering policy and the absence of SecOC as the two most impactful weaknesses to address.

Pros and Cons Comparison

Dimension	Attack Trees	Attack Paths
Completeness	Systematic goal decomposition ensures comprehensive coverage of all attack methods	May miss attack vectors not considered by the analyst; depends on creativity and knowledge
Operational realism	Abstract; does not reflect the temporal sequence of attacker actions	Directly models how attacks are executed step by step; maps to penetration testing
Quantitative analysis	Strong; AND/OR propagation rules enable formal cost, time, and probability calculations	Good; each step can be scored independently, overall path constrained by weakest link
Communication	Effective for management reporting and compliance documentation; clear visual hierarchy	Effective for technical teams and red/blue team collaboration; maps to kill chains
Scalability	Large trees become unwieldy; exponential growth with complex systems	Individual paths are simple; but the total number of paths can be combinatorially explosive
Lifecycle stage	Best suited for concept and early design phases when architecture is defined but not implemented	Best suited for development, verification, and post-production monitoring phases
ISO/SAE 21434 alignment	Directly supports attack potential-based feasibility (Annex G)	Directly supports CVSS-based feasibility and vulnerability analysis
Mitigation insight	Identifies which sub-goals to block to invalidate entire attack branches	Identifies specific chokepoints where a single control blocks the entire chain
Tool support	Supported by most commercial TARA tools; can be built in spreadsheets	Requires graph-based tooling; harder to model in traditional document-centric approaches
Reusability	Sub-trees can be reused as patterns across similar components	Paths are context-specific; harder to generalize across different architectures

When to Use Each Approach

Use Attack Trees When:

• Performing initial TARA during concept phase: Attack trees excel at brainstorming all possible attack methods before a specific architecture is finalized. They help answer: “What are all the ways an attacker could compromise this function?”
• Preparing for type approval or certification: Assessors expect comprehensive threat enumeration. Attack trees provide auditable evidence that all attack vectors were considered and evaluated.
• Communicating with management: The hierarchical structure is intuitive for non-technical stakeholders. Risk values propagated to the root make it clear which branches pose the greatest threat.
• Building reusable threat libraries: Sub-trees for common automotive attack patterns (e.g., OBD-II physical attacks, Bluetooth pairing attacks) can be templated and reused across vehicle programs.
• Comparing architectural alternatives: When evaluating two gateway architectures, building attack trees for each reveals which design has fewer viable attack branches.

Use Attack Paths When:

• Planning penetration testing: Attack paths define concrete test cases. Each path becomes a penetration test scenario with defined entry point, intermediate steps, and success criteria.
• Performing vulnerability-driven analysis: When a new CVE is disclosed for a component in the vehicle, attack path analysis determines whether the vulnerability is reachable from an external interface and what damage an attacker can achieve after exploitation.
• Designing network segmentation: Attack paths reveal which trust boundaries an attacker must cross. This directly informs gateway filtering rules, VLAN design, and firewall policies.
• Supporting incident response: After a security incident, reconstructing the attack path from logs helps understand what happened, what was compromised, and what evidence to collect.
• Integrating with runtime detection: Attack paths map to detection signatures. Each step in the path generates observable events that a Vehicle SOC can monitor.

Use Both Together When:

• Full ISO/SAE 21434 lifecycle compliance: Use trees in concept phase for completeness; refine into concrete paths during development as specific components and vulnerabilities become known.
• Building a comprehensive threat model: Trees ensure nothing is missed; paths ensure the analysis reflects operational reality.
• Justifying security investments: Trees show all possible risks; paths show the most realistic and impactful attack scenarios that justify immediate investment.

Unified Modeling in a Knowledge Graph

The traditional limitation of attack trees and attack paths is that they exist as separate artifacts, typically in different documents or tools. Modern threat modeling approaches unify both into a single knowledge graph where nodes represent system components, vulnerabilities, attack actions, and security goals, while edges capture relationships like “exploits,” “leads to,” “is mitigated by,” and “requires.”

In this unified model, an attack tree is a specific view (a directed acyclic subgraph rooted at a goal node), while an attack path is a specific traversal (a sequence of edges from an entry point to a target). Both views are derived from the same underlying graph, ensuring consistency and enabling powerful queries like “Which single control blocks the most attack paths?” or “Which attack tree branch has the most concrete, vulnerability-backed paths?”

How ThreatZ Models Both Approaches

ThreatZ maintains a Neo4j-backed knowledge graph where vehicle components, interfaces, vulnerabilities, threat scenarios, and security controls are stored as interconnected nodes. When an engineer defines a system architecture, ThreatZ automatically generates both attack trees (by goal decomposition using its AI-powered threat scenario engine) and attack paths (by graph traversal from external interfaces through vulnerable components to safety-critical targets).

This dual approach provides several advantages:

• Automatic completeness checking: The knowledge graph can identify attack tree branches that have no corresponding concrete paths (indicating theoretical threats with no current practical instantiation) and attack paths that are not captured in any tree (indicating gaps in the threat enumeration).
• Dynamic feasibility updates: When a new vulnerability is disclosed or a security control is deployed, feasibility ratings are recalculated across all affected trees and paths simultaneously.
• Traceability from requirement to control: Each security requirement traces to the threat scenario it addresses (from the tree) and the specific attack step it blocks (from the path), satisfying ISO/SAE 21434’s traceability requirements.
• Risk prioritization: By combining tree completeness with path realism, ThreatZ produces a risk ranking that reflects both theoretical exposure and practical exploitability.

Practical Recommendations for Automotive Teams

Based on our experience with dozens of TARA implementations across OEMs and Tier-1 suppliers, here are concrete recommendations for incorporating both techniques:

1. Start with attack trees at the function level. For each safety-critical or security-relevant function, build a tree rooted at the compromise of that function’s primary cybersecurity property. Keep trees focused: one tree per function per property (e.g., “Compromise integrity of steering assist function”).
2. Derive attack paths from the architecture. Once the E/E architecture is defined with specific ECUs, buses, and interfaces, trace paths from every external interface to every safety-critical component. Tools like ThreatZ automate this graph traversal.
3. Cross-reference trees and paths. For each leaf node in an attack tree, verify that at least one concrete attack path instantiates it. For each attack path, verify that the goal it achieves is captured in a tree. Resolve discrepancies.
4. Use trees for reporting and paths for testing. Include attack trees in your cybersecurity case (ISO/SAE 21434 Clause 6.4.6) to demonstrate comprehensive analysis. Convert attack paths into penetration test plans for verification (Clause 10.4).
5. Maintain both in a single tool. Disconnected spreadsheets for trees and separate documents for paths will diverge over time. A graph-based tool ensures consistency as the architecture and vulnerability landscape evolve.

Key Takeaways

• Attack trees provide hierarchical, goal-oriented completeness; attack paths provide sequential, exploit-oriented realism.
• Attack trees originate from Bruce Schneier’s work and are aligned with ISO/SAE 21434’s attack potential method; attack paths align with CVSS-based approaches and penetration testing.
• Neither approach alone is sufficient for a thorough automotive TARA; the best practice is to use both in complementary fashion across the development lifecycle.
• Unified knowledge graph modeling eliminates the consistency gap between the two approaches and enables powerful cross-analysis.
• ThreatZ automates both attack tree generation and attack path discovery from a single vehicle architecture model, ensuring comprehensive and consistent threat coverage.