How it is created — SDL-TMP-011 Threat Modeling Method & Template

1. Why this artifact exists

The risk assessment tells you a stolen node leading to mesh compromise scores 12. It does not tell you which interface, which data store, or which of the four ways in. Those answers are what turn a risk into a requirement someone can implement, and they only appear when you decompose the system element by element.

Keeping the method separate from the risk method is a deliberate split. The risk assessment is read by product managers and assessors; the threat model is a technical decomposition that is unreadable without the data-flow diagram beside it. Merged, you get a document that the first audience skips and the second cannot use.

The method document also settles the question every threat model otherwise re-litigates: how much is enough. Applying STRIDE to every element of a large diagram produces hundreds of rows and no decisions. The scope rules here are what keep the output at the size where it still gets read on its second revision.

2. Inputs

• The risk method, because the two hand work to each other and their scales and IDs have to interlock.
• Your product architecture at the level of interfaces and data stores — enough to draw a data-flow diagram, not a finished design.
• Who is available for a three-hour workshop. This determines the method more than any methodology choice: the hardware engineer's availability is why physical threats get found.
• Your secure-defaults checklist and attack-surface plan, which will consume the inventory this method produces.

3. Steps

1. Fix the order of the five steps and explain why it matters. Boundaries, then surface, then actors, then STRIDE, then requirements. Enumerating threats before the boundaries exist produces a list of everything anyone has ever worried about, ranked by who spoke loudest in the room.
2. Require the DFD as a source artifact in the repository, not a picture pasted into a document. A diagram that cannot be diffed will not be updated, and a threat model whose diagram is stale is misleading rather than merely old.
3. Insist the model is drawn on the planned system.* This is a design-phase activity whose value is changing the design; run against a built system it can only ratify decisions already made.
4. Make the hardware engineer a required participant. On embedded products most of the interesting findings are physical — debug ports, desoldered flash, swapped tags — and a software-only room will not raise them. This one line changes the output more than any methodology refinement.
5. Say STRIDE applies per element, not per diagram. Whole-system STRIDE yields six paragraphs of prose and no requirements.
6. Write the relevance filter in. Record only threats that apply to the intended use or a foreseeable misuse. Completeness is not the goal; a model people still read at revision three is.
7. Add a "planned default state" column to the attack surface inventory. This is the connector: the secure-defaults checklist takes its expectations from it, and the attack-surface plan takes its keep/disable/remove decisions from it. Without that column both documents start from scratch and drift apart.
8. Require every threat row to end in a requirement or a risk reference. A threat that produces neither is unfinished. This single rule is what stops threat models from becoming inventories of worry.
9. Make the methodology statement mandatory in every product threat model. The technical documentation expects the method to be evident from the document, not inferred by a reader who has also found this template. Ask for the method as applied, including deviations — an honest shortcut is worth more than a claimed process that was not followed.
10. Define the maintenance trigger — any change to an interface, protocol or trust boundary, and at least once per major release — and retain all revisions.

4. Done when

• The five steps are ordered, with the reason the order matters written down.
• The DFD lives in the repository and the document is its reviewed export.
• The participant list requires hardware competence, not just software.
• STRIDE is scoped per element, with an explicit relevance filter.
• The attack surface table carries the planned default state, and downstream documents consume it.
• Every threat row hands off to a requirement or a scored risk.
• Each product threat model states the method as applied.

5. Common mistakes

Modelling the built system instead of the planned one. A software-only workshop, which reliably misses the physical boundary. STRIDE applied to the diagram rather than to elements. Threat rows with no handover, so the model documents concerns nobody owns. A diagram that stops being updated because it lives in a slide. And chasing completeness until the model is too large to review, at which point its second revision never happens.

6. In TRA Studio

The threat model is where security requirements are born, and requirement traceability is only as good as that origin. Derive requirements here with an ID that survives into the requirements sheet, then assign those requirements to lifecycle activities. What you want to be able to answer is not just "is this requirement assigned" but "which threat made us write it" — a requirement whose origin has been lost is one nobody can decide to retire when the design changes.