Threat Modeling in Practice

Capture Threats on Paper First

This topic works best as a practical framework: clear enough for decision-making and concrete enough for execution.

In Threat Modeling in Practice, the goal is to document choices that teams can execute consistently and repeatably.

This keeps this chapter from being theory and makes it a usable compass for consistent execution.

Immediate measures (15 minutes)

• Use this page to prioritize measures and convert them into backlog items.
• Link each measure to an owner, deadline, and demonstrable evidence.
• Repeat periodically based on risk, changes, and incident lessons.

Why this matters

The core of Threat Modeling in Practice is risk reduction in practice. Technical context supports the choice of measures, but implementation and assurance are central.

Minimum viable threat model

For each critical system, at minimum:

1. Context diagram (actors, systems, external dependencies).
2. Dataflows with trust boundaries.
3. Misuse cases per critical flow.
4. Top risks with priority and owner.
5. Concrete control choices + verification plan.

If any of these is missing, the model is incomplete.

Methodology in 6 steps

Step 1: Scope and assets

• define system boundaries;
• identify crown jewels (data, processes, credentials).

Step 2: Draw the dataflow

• document every data transfer;
• explicitly mark trust transitions.

Step 3: Identify threats

• use STRIDE or ATT&CK-based scenarios;
• focus on realistic risk paths, not theoretical edge cases.

Step 4: Prioritize risks

• impact x likelihood;
• emphasize chain dependencies and detection blind spots.

Step 5: Choose measures

• priority order: eliminate > mitigate > detect > respond;
• link each measure to an owner and implementation timeline.

Step 6: Validate and maintain

• validate with pentest/tabletop;
• update model on architecture changes.

STRIDE practically applied

Output format for teams

Per risk, record:

• risk ID;
• scenario;
• impacted asset;
• current controls;
• missing control;
• owner;
• target date;
• evidence of implementation.

This format makes threat modeling directly usable for backlog and governance.

Link to architecture and governance

• Architecture: input for reference designs and ADRs.
• Engineering: input for backlog and test cases.
• Governance: input for top-risk reporting and investment decisions.

Threat modeling only has value when outcomes lead to execution.

Summary

Threat modeling is not a workshop goal in itself but a decision machine: it makes risk paths visible, prioritizes risks, and links measures to ownership and evidence.