SDL-TMP-011 — Threat Modeling Method & Template

1. Purpose

The risk assessment (SDL-TMP-010) asks what could go wrong and how bad is it. The threat model asks where exactly, element by element, and hands the answers back with scores attached.

Keeping them as two documents is deliberate. The risk assessment is readable by a product manager and an assessor; the threat model is a technical decomposition that only makes sense next to a data-flow diagram. Merging them produces a document that serves neither reader.

2. Method

Five steps, in this order. The order matters: enumerating threats before the boundaries are drawn produces a list of everything anyone has ever worried about, ranked by who spoke loudest.

1. Draw the data-flow diagram of the planned system, with trust boundaries marked. Planned, not built — this is a Phase 2 activity and its purpose is to change the design while changing it is still cheap.
2. Enumerate the attack surface: every interface, service and data store that crosses a boundary. One row each.
3. Define the threat actors and their capabilities.
4. Apply STRIDE to each element, recording only threats relevant to the intended use or foreseeable misuse.
5. Derive security requirements, and hand each threat back to the risk assessment with an L × I score.

Workshop: PSL moderates; firmware lead, hardware engineer and QA attend. Three hours for a new product. The hardware engineer is not optional — on embedded products a majority of the interesting findings are physical, and a software-only room will not raise them.

Tooling: the DFD is maintained in the project repository (threat-model/<product>.drawio) and the reviewed export is the document. The diagram is a source artifact, not an illustration pasted in afterwards.

3. Scope rules

• STRIDE per element, not per diagram. Applying STRIDE to the system as a whole yields six paragraphs of prose and no requirements.
• Record only relevant threats. A threat that does not apply to the intended use or a foreseeable misuse is noise, and noise is what makes threat models go unread at the second revision.
• Include the physical boundary. Debug ports, flash chips, enclosure access, commissioning tags. For a device mounted on a customer's machinery, physical access is a design assumption, not an edge case.
• A threat with no requirement and no risk reference is not finished. Either it produces a measure, or it is handed to the risk assessment to be accepted with a documented decision.

4. Template — SEC-TM-\<product\>

4.1 Header

Document ID and revision · product and project number · reference (CRA anchor, companion risk assessment) · methodology statement — state it explicitly in every threat model, because Annex VII expects the method to be evident from the document rather than inferred · participants and workshop date · approved by.

4.2 Methodology as applied

The five steps of §2, written as they were actually performed, including deviations. A threat model claiming a method it did not follow is worse than one that describes a shortcut honestly.

4.3 System overview and trust boundaries

Elements and the boundaries between them, numbered TB-n. Include local boundaries inside the device — physical enclosure, storage versus application — not only network ones.

4.4 Attack surface inventory

The planned default state column is what connects this document to secure-by-default: it is where the checklist (SDL-CHK-030) gets its expectations, and where the minimal-attack-surface plan gets its keep/disable/remove decisions.

4.5 Threat actors

Three to five actors. Capability means what they can actually do — "physical access, consumer tools" or "lab equipment, firmware analysis" — not a label like "advanced".

4.6 STRIDE findings

The last column is the handover, and every row must have one.

4.7 Derived security requirements

Which SR-* are mandatory before architecture freeze, and which hardware constraints the findings jointly confirm.

4.8 Maintenance rule

Re-run as a delta workshop whenever an interface, protocol or trust boundary changes, and at least once per major release. All revisions retained.

5. Relationship to the other documents

6. Records

Threat models at every revision, DFD sources, workshop participant lists. Quality records, part of the technical documentation, retained 10 years after the last unit is placed on the market.

Revision history