An attack tree puts the attacker's goal at the root and breaks it down into the different ways to achieve it. Branches are either OR (any one child is enough) or AND (all children are needed). This sample decomposes "steal customer PII" for a typical web company. Attack trees are not UML: UML covers software structure and behaviour; attack trees are one of the standard security notations used alongside it.
1. The Diagram
Reading from the top:
The root is the outcome the business fears: customer PII leaving the production database.
Three OR branches give independent routes: exploit the application, use a stolen admin credential, or copy a backup.
Exploit app vulnerability is itself an OR: SQL injection in the search API or SSRF to the cloud metadata service would each work.
Use stolen admin credential is an AND (yellow arc): the attacker needs the password and must get past MFA.
Defeat MFA is an OR of MFA-fatigue push spam or a SIM swap against SMS codes.
Copy exposed backup needs both a publicly reachable bucket and an unencrypted backup. Fixing either one kills the branch.
Red leaves are concrete attacker actions; each should map to a control (WAF and parameterised queries, IMDSv2, number-matching MFA, bucket policies, encryption).
2. How to Read It
Plain fan-out means OR; an arc across the edges means AND. Some tools draw AND as a D-shaped gate instead. Tree layout is top-down; the same tree can be written as an indented outline, which is how many teams keep it in a repository.
3. Variant: Annotated with Attacker Cost
Give each leaf a value (estimated attacker cost here; probability, skill or detection risk are also common) and propagate upward: an OR node takes the minimum of its children, an AND node the sum. The cheapest route is not the SQL injection everyone worries about but phishing plus MFA fatigue at about $1.5k. That tells you to buy number-matching MFA or FIDO2 keys before another code scanner.
4. Pros, Cons, and When to Use
Pros
Thinks like the attacker, starting from the outcome that matters.
AND nodes show where one control blocks a whole branch.
Values on leaves turn opinions into a ranked list of fixes.
Simple enough to write as an outline in a pull request.
Reusable: the same subtree (for example "defeat MFA") appears in many models.
Cons
Only as complete as the team's imagination; missing branches are invisible.
Grows exponentially for broad goals; keep one goal per tree.
Leaf values are estimates and can give false precision.
Does not show system structure, so pair it with a DFD.
When to use
Prioritising security spend against a specific feared outcome.
Red-team planning and post-incident analysis.
Explaining risk to executives in one picture.
When not to use
Enumerating threats element by element (use STRIDE on a DFD).
Documenting how a protocol works (use a sequence diagram).
5. Diagrams-as-Code
Mermaid flowchart (AND/OR shown in the node text, since Mermaid has no arc):
flowchart TD
G["Steal customer PII (OR)"]
G --> A["Exploit app vulnerability (OR)"]
G --> B["Use stolen admin credential (AND)"]
G --> C["Copy exposed backup (AND)"]
A --> A1[SQL injection in search API]
A --> A2[SSRF to cloud metadata service]
B --> B1[Phish admin password]
B --> B2["Defeat MFA (OR)"]
B2 --> B2a[MFA fatigue push spam]
B2 --> B2b[SIM swap for SMS codes]
C --> C1[Find public storage bucket]
C --> C2[Backup stored unencrypted]
6. Related
Flowcharts — the closest general notation; attack trees are a specialised tree diagram