Threat modelling a feature with STRIDE in one working session

Goal

Find the security-relevant ways a feature can fail before it is built, in a session short enough that a team will repeat it for the next feature, and leave behind decisions that a later review can check.

Prerequisites

A feature or change with a known scope; the people who know its data flows (typically one developer and one operator); a whiteboard or diagram tool. The Threat Modeling Manifesto's four questions serve as the agenda: what are we working on, what can go wrong, what are we going to do about it, did we do a good enough job.

Steps

1. Model: draw a data-flow diagram of the feature with external entities, processes, data stores, data flows and trust boundaries (browser to server, service to database, one tenant to another). The OWASP cheat sheet calls the DFD arguably the most common approach to system modelling and names trust boundaries, flows, stores, processes and external entities as the usual attack points.
2. Number the elements and boundary crossings so that each threat can refer to one.
3. Enumerate: for every element, ask the six STRIDE questions. The Microsoft documentation defines the six categories; the OWASP cheat sheet tabulates the property each one violates: Spoofing (authentication), Tampering (integrity), Repudiation (accounting), Information disclosure (confidentiality), Denial of service (availability), Elevation of privilege (authorisation). Write one line per threat: element, category, what an attacker does.
4. Rank roughly by likelihood and impact. Do not spend the session on scoring precision; the cheat sheet notes that both are hard to calculate.
5. Respond: for each threat record one of the four responses the cheat sheet lists (mitigate, eliminate, transfer, accept) and, for mitigations, a testable requirement such as "every write to store 3 carries the tenant id from the session; covered by test X".
6. Review: answer "did we do a good enough job" with the cheat sheet's questions: does the diagram match the system, has every threat a response, can each mitigation be tested.
7. Store the diagram and the threat table next to the design (an ADR or design document) and revisit them when a trust boundary changes.

Expected result

A one-page diagram, a threat table, and a list of requirements and accepted risks with names attached. Later reviews can check whether the mitigations exist rather than re-deriving the threats.

Limits and test basis

STRIDE prompts categories, not specific attacks; it will not surface business-logic abuse or supply-chain problems unless the model includes those flows. The result is only as good as the diagram. The procedure is a synthesis of the cited guidance; no count of defects found per session is claimed.