Attack Trees and Prioritizing Risk

An attack tree is a diagram that models how an attacker could achieve a goal. The goal sits at the root, and the branches show the different paths and sub-steps required to reach it.

Where STRIDE enumerates threat types, attack trees explore the concrete paths an attacker might take. They are excellent for reasoning about a specific high-value target.

The root node is the attacker's ultimate objective, such as 'steal customer payment data.' Child nodes are the sub-goals or methods that achieve the parent.

You build the tree by repeatedly asking: 'How could an attacker accomplish this node?' Each answer becomes a child, and you keep decomposing until you reach concrete, actionable leaf actions.

Attack trees use two logical relationships between a node and its children:

• OR nodes — any one child is enough to achieve the parent (alternative paths)
• AND nodes — all children must be achieved together (required steps)

This distinction matters enormously: an OR node means an attacker only needs the easiest path, while an AND node forces them to clear every step.

Here is a text attack tree for stealing payment data:

Attack trees become powerful when you annotate leaf nodes with attributes that help prioritize:

• Cost to the attacker
• Difficulty or required skill
• Detectability (will it trip an alarm?)
• Likelihood of success

You then propagate these up the tree. For an OR node, the attacker picks the cheapest/easiest child, revealing your weakest link.

To prioritize, you need a risk score. The classic formula combines two factors:

DREAD is a structured way to score threats across five dimensions. Each is rated, then combined into a priority score:

• Damage — how bad is the impact?
• Reproducibility — how reliably can it be repeated?
• Exploitability — how easy to pull off?
• Affected users — how many are impacted?
• Discoverability — how easy to find?

DREAD is somewhat subjective, so use consistent rating definitions across your team.

A risk matrix plots likelihood against impact to give an at-a-glance priority view:

Once threats are ranked, decide how to handle each. The four options are the same as in STRIDE mitigation:

• Mitigate — add controls to lower likelihood or impact
• Eliminate — remove the risky feature entirely
• Transfer — offload via insurance or a third party
• Accept — formally document tolerating a low risk

Spend your limited budget on the highest-risk items first; do not gold-plate low-risk threats.

A mitigation only makes sense if its cost is justified by the risk it reduces. A control that costs more than the asset it protects is a poor investment.

For each candidate control, weigh:

• How much does the control reduce risk?
• How much does it cost to build and operate?
• Does it introduce friction or new risks?

Prefer controls that block multiple attack paths at once, such as MFA closing many account-takeover branches.

Prioritization is not a one-time exercise. Track each identified threat in a risk register with its score, chosen response, owner, and status.

Revisit the register when:

• A new threat or vulnerability emerges
• The system or its assets change in value
• A mitigation is implemented (re-score the residual risk)

Accepted risks should have an expiry and be re-reviewed, not accepted and forgotten.

Test your understanding of attack trees and risk prioritization.

You learned to rank threats and choose mitigations:

• Attack trees model paths to an attacker goal, using AND (all required) and OR (any sufficient) nodes
• Annotate nodes with cost, difficulty, and detectability to find the weakest link
• Prioritize with Risk = Likelihood x Impact, DREAD scoring, and a risk matrix
• Choose to mitigate, eliminate, transfer, or accept, weighing cost vs benefit
• Track everything in a risk register and revisit it as the system evolves

This completes the Threat Modeling with STRIDE course.