Attack Trees
Start from the attacker's goal and decompose it into every path that achieves it, so you can see which defense covers several branches at once and which branch nothing covers at all.
Frame the problem
Security starts with a concrete asset, attacker capability and trust crossing.
Goal at the root, paths as branches
STRIDE walks the system and asks what can go wrong at each point. An attack tree walks the *attacker's objective* and asks how it could be achieved. The two find different things, because real attacks chain across components in ways a per-component review does not surface.
Put the goal at the root: "read another tenant's data", "issue a refund to my own card", "deploy code to production". Then decompose: what would have to be true for that to happen? Each child is an alternative path (OR), and where several things must all happen, the children are joined (AND). Keep decomposing until each leaf is something you can evaluate — a specific control that exists or does not.
The payoff is visible in two places. First, shared defenses: a control that appears on many branches (phishing-resistant MFA, tenant-scoped queries enforced in one layer) is worth far more than its per-branch value suggests. Second, uncovered branches: a path with no control on it anywhere is a finding that no per-component review would have produced, because each component along it was individually fine.
GOAL: act as an administrator in production
│
├── (a) Compromise an admin's account
│ ├── phish credentials [MFA-phishing-resistant blocks]
│ ├── credential stuffing from a breach [breached-password check + MFA blocks]
│ ├── steal an active session [HttpOnly + Secure + short TTL + rotation]
│ └── abuse account recovery [ !! no step-up verification on recovery ]
│
├── (b) Abuse an authorization flaw
│ ├── admin endpoint without a server check [route policy required at startup]
│ └── privilege field accepted from body [field allow-list on update]
│
├── (c) Obtain an admin API token
│ ├── token in a public repository [secret scanning + short-lived tokens]
│ ├── token in CI logs [ !! CI logs not scanned, 90-day retention ]
│ └── read the secret manager [scoped machine identity]
│
└── (d) Reach production through the pipeline (AND: needs both)
├── merge malicious code [required review + CODEOWNERS]
└── pipeline deploys without approval [manual approval for prod]
UNCOVERED: account recovery (a), CI log retention (c)
HIGHEST LEVERAGE: phishing-resistant MFA — covers two branches of (a) and weakens (c)Reading the tree for decisions
Trees are analysis tools, so the output should be decisions, not diagrams. Three readings are worth doing every time.
Cheapest branch. Attackers optimise for cost, and the cheapest branch is usually social or procedural rather than technical: account recovery, a helpdesk that resets MFA, a contractor's laptop, a support tool with broad read access. If your defenses are concentrated on the expensive technical branches, you have hardened the path nobody takes.
Highest-leverage control. Count how many leaves each control covers. Phishing-resistant authentication typically covers more branches than any other single control in an account-takeover tree, which is why it consistently outranks a longer password policy despite being harder to roll out.
AND nodes as opportunities. Where a branch requires two things, you only need to break one — and the cheaper one to enforce is usually the second. A deployment path that needs both a malicious merge and an unapproved deploy is broken permanently by requiring approval, without solving the much harder problem of guaranteeing that no malicious code is ever merged.
- Annotate leaves with rough attacker cost and required capability; the tree is for comparing paths, not for precision.
- Mark every leaf with the control that covers it, or with nothing — and the nothings are the report.
- Count control coverage across leaves to find the highest-leverage investment.
- At AND nodes, defend the cheaper conjunct; you do not need both.
- Keep trees small and goal-specific. One goal per tree, ten to twenty leaves, or nobody finishes reading it.
Key points
- Attack trees are goal-directed and find chains across components that per-component reviews miss.
- OR branches are alternative paths; AND nodes require every child, so you only have to break one.
- The cheapest branch is usually procedural — account recovery, helpdesk, support tooling — not technical.
- Count how many leaves each control covers to find the highest-leverage defense.
- A branch with no control on any leaf is the finding; that is what the tree exists to expose.
Boundary control exercise
This lesson uses the shared boundary-control exercise.
Follow the attack
Safe conceptual simulation: capability → missing control → crossed boundary → asset impact.
- 1Attacker → choose a goal, not a vulnerability: they want an outcome, and any path is acceptable.
- 2Goal → enumerate paths: technical exploitation, credential theft, process abuse, supply chain, insider.
- 3Paths → cost estimate: pick the cheapest one that their capability supports.
- 4Chosen path → execute, chaining across whatever components lie on it.
- An uncovered branch means the goal is achievable with no control resisting it at any step.
- Concentrating defense on well-known branches produces high effort with unchanged real risk.
Defend, detect, recover
One prevention is a single point of security failure. Layer it and make failure observable.
- • Build a tree for each of the two or three goals that would be worst for the business, and re-read them when controls change.
- • Invest first in controls that cover multiple leaves rather than in the deepest hardening of one.
- • Include non-technical branches explicitly — recovery flows, support tooling, vendor access — or the tree will flatter you.
- • Instrument the leaves: a detection on each path is what turns an uncovered branch into a survivable one.
- • Watch the procedural branches especially, since they generate the least technical telemetry.
- • After an incident, place it on the tree: which branch, which leaf, and was it marked covered?
- • A control that was believed to cover a leaf and did not is a more important finding than the incident itself.
- • Trees are only as complete as the imagination of the people drawing them; novel paths are absent by construction.
- • Cost estimates for attacker effort are guesses and can be badly wrong for a motivated adversary.
- • A tree ages exactly like a threat model, and stale coverage annotations are worse than none.