Attack Trees: Visualising Threat Scenarios

The root node states the attacker's goal — "compromise customer database," "take over an administrator account," "disrupt payment processing." Each child node is a sub-goal or method that contributes to achieving the parent. The tree keeps branching until leaf nodes represent concrete, atomic attack steps — specific enough that you could reasonably estimate the cost, skill, and likelihood of each one.

Child nodes under a parent are connected either as OR nodes (any one child alone is sufficient to achieve the parent) or AND nodes (all children are required together). This distinction matters enormously for analysis: an OR-connected set of children means the defender has to close off every path, while an AND-connected set means blocking any single child breaks that entire branch.

Consider the goal "gain unauthorised admin access to the internal HR system." That goal might decompose into three OR branches: compromise an existing admin's credentials, exploit a vulnerability in the application directly, or gain access via a trusted third-party integration. The credential-compromise branch itself decomposes further, this time with more nuance — phishing the admin (a single sufficient step), or an AND-branch combining "obtain the admin's password via a data breach dump" with "bypass MFA via SIM-swap," since password alone isn't sufficient if MFA is enforced.

• •Root: Gain unauthorised admin access to HR system (OR)
• • Branch A: Compromise an existing admin credential (OR)
• • Leaf: Phish the admin via a spoofed SSO login page
• • AND-branch: Credential-stuff from a breach dump + SIM-swap to bypass SMS MFA
• • Branch B: Exploit an application vulnerability directly (OR)
• • Leaf: Exploit an unauthenticated RCE in an outdated plugin
• • Leaf: Exploit an IDOR to access another user's admin session
• • Branch C: Abuse a trusted third-party integration (OR)
• • Leaf: Compromise the SSO provider's admin console
• • Leaf: Abuse an overprivileged API key held by a connected vendor tool

A tree with just goal decomposition is useful for communication, but attack trees become genuinely analytical once leaf nodes are annotated with attributes — typically cost to the attacker, required skill level, likelihood of success, and whether the step is detectable. Some practitioners also annotate with a boolean "possible/impossible" flag once known mitigations are applied, which lets the tree double as a control-effectiveness map.

With cost or likelihood values assigned to leaves, those values can be propagated up through the tree: the cost of an OR node is the minimum cost among its children (an attacker takes the cheapest path), while the cost of an AND node is the sum of its children's costs (all steps must be paid for). This bottom-up propagation is what lets you identify the actual cheapest viable path to the root goal — often called the weakest path — rather than relying on intuition about which branch looks scariest.

Once the cheapest path is identified, the highest-leverage defensive investment is usually the one that closes that specific path, since an attacker rationally pursuing the goal will gravitate toward the lowest-cost route. Closing the cheapest OR branch doesn't eliminate the goal — the attacker just moves to the next-cheapest branch — but it raises the overall cost of the attack, and repeating the exercise after each mitigation shows whether the marginal cost increase is worth the investment.

This is also where attack trees complement AND-branch analysis for defence-in-depth decisions: if a branch requires two independent conditions (stolen password AND bypassed MFA), breaking either condition breaks the whole branch, so the defender only needs one working control on that path rather than closing every leaf.

Attack trees assume a single goal per tree and a purely hierarchical decomposition. Attack graphs generalise this into a directed graph where nodes can represent system states and edges represent transitions, allowing multiple goals and shared sub-paths to be represented without duplication. Attack graphs are more expressive and better suited to automated generation from vulnerability scan data across a large network, but they're harder to read by hand — attack trees remain the more common choice for manual, communication-oriented threat modelling exercises.

Attack trees are rarely a standalone methodology; they're a modelling technique used inside a broader process. PASTA explicitly uses attack tree construction as its Stage VI (Attack Modeling). STRIDE-generated threats can be expanded into attack trees when a particular threat is high-impact enough to warrant deeper decomposition of how it would actually be carried out. Red teams also use attack trees to plan and scope engagements, since the tree structure naturally maps to an engagement plan with clearly bounded objectives per branch.

Keep trees scoped to one specific, concrete goal rather than something broad like "compromise the company," which produces an unmanageably large tree with little analytical value. Involve people who think like attackers — offensive security staff or red teamers — when building the tree, since defenders alone tend to under-enumerate creative attack paths. And revisit trees after major architectural changes or after new threat intelligence emerges; a tree built a year ago may no longer reflect the cheapest path if new tooling has changed the economics of a given branch.