An attack tree is a hierarchical decomposition of an attacker's goal. Bruce Schneier introduced the notation in a 1999 Dr. Dobb's Journal article and elaborated on it in Secrets and Lies. The idea is simple: write the attacker's objective at the top; underneath, write each way an attacker could achieve it; under each of those, write what's needed to make that step work; repeat until you bottom out at concrete actions.
Attack trees are the threat-modeling equivalent of a recipe. They make chained, multi-step attacks visible — the kind STRIDE catalogs only in pieces — and they let you reason about which leaf to mitigate first to break the most root paths.
A worked example
Goal: read the contents of a competitor's encrypted backup that we obtained from a careless courier. There are several routes.
The notation
- Root (goal): what the attacker is trying to accomplish, in one sentence.
- OR nodes: the goal is achieved if any of the children succeed. This is the default at most levels.
- AND nodes: the goal is achieved only if all children succeed. Used when several preconditions must combine (e.g., "get the key" AND "get the ciphertext").
- Leaves: concrete attacker actions. The leaves are where defenders place controls.
- Annotations: add cost, time, required skill, detectability to each leaf. Then propagate up: the cost of an OR node is the minimum child cost; the cost of an AND node is the sum.
Why attack trees work
- They reveal cheapest-path attacks. The defender's instinct is to harden the most technical step (the cipher); the attacker's instinct is to take the cheapest path (phishing). Attack trees make the asymmetry visible.
- They model chained attacks. Real breaches are chains: phish → foothold → lateral → privilege escalation → exfiltration. STRIDE catalogs the steps; an attack tree shows the chain.
- They're testable. "Did we close this leaf?" is a yes/no question. Track leaf closures over time; the tree becomes a verification artifact.
- They're communicable. Non-security people read attack trees easily — the structure is intuitive in a way that policy JSON is not.
Where attack trees fail
- Exhaustiveness is an illusion. Real attackers find branches you didn't draw. Treat your tree as a starting point, not a complete enumeration.
- Cost estimates drift. Phishing was harder 15 years ago than today; quantum cracking is closer than it was 5 years ago. Periodic re-costing matters.
- Trees grow without bound. A real-world attack tree for a large system can run to dozens of pages. Use them surgically — one tree per high-value goal — rather than trying to model the whole system.
ADTool (academic), SecuriCAD (commercial), and various Mermaid/Graphviz patterns let you keep trees in version control. For most teams, a markdown file with indented bullets is enough — the structure itself is the value.
Attack trees are the narrative form of threat modeling. STRIDE gives you categories; DREAD gives you scores; PASTA gives you process; attack trees give you stories — the actual chain an attacker would walk to reach a specific objective.
The discipline is to draw one tree per high-value goal, annotate each leaf with cost and feasibility, and use the cheapest path to decide where to spend defensive effort. Done that way, attack trees produce roadmap items, not paperwork.
References
Formatted in APA 7. Alphabetized by first author's last name.
- Kordy, B., Piètre-Cambacédès, L., & Schweitzer, P. (2014). DAG-based attack and defense modeling: Don't miss the forest for the attack trees. Computer Science Review, 13–14, 1–38. https://doi.org/10.1016/j.cosrev.2014.07.001
- Schneier, B. (1999). Attack trees. Dr. Dobb's Journal, 24(12). https://www.schneier.com/academic/archives/1999/12/attack_trees.html
- Schneier, B. (2000). Secrets and lies: Digital security in a networked world. Wiley.
- Shostack, A. (2014). Threat modeling: Designing for security. Wiley.