STRIDE Threat Model Template

The Threat Modeling Manifesto¹, written by 15 practitioners including Adam Shostack, frames the job as four questions. What are we working on? What can go wrong? What are we going to do about it? Did we do a good enough job?

Answer the first while the design can still change. OWASP's cheat sheet says threat modeling is ideally performed early, such as during the design phase².

Gather the architecture document, diagrams, infrastructure config, API specs and design review notes. If nothing current exists, write a short solution architecture document first. When an RFC or design doc is still open, model its leading option and add what you find to it.

Next, set the edge of the model. In a 2021 AWS Security Blog post, principal security solutions architect Darran Boyd advises modeling one feature at a time³ rather than a whole workload. A critical threat left open then blocks only that feature's launch. A sensible default is the service under review plus everything it talks to directly.

OWASP calls the data flow diagram arguably the most common way to model a system². It needs four kinds of element, plus the trust boundaries between them:

• External entity (a rectangle): a person or system outside your control that sends or receives data.
• Process (a circle): code you run, such as a service, job or function.
• Data store (two parallel lines): anything that keeps data, such as a database, bucket or file.
• Data flow (an arrow): data moving between two elements.
• Trust boundary (a dotted line): where data passes between parts trusted differently, such as the internet and your network.

The type decides which threats you check, so type each element by what it does, not who owns it. Code running in your account is a process, even if another team maintains it. A queue that keeps messages for days is a data store.

Add what the drawing leaves out: any element named only in prose, because an element nobody drew never shows up as a gap. Split any arrow that bundles several connections into one flow per pair of endpoints.

Each STRIDE threat breaks a security property, and not every threat applies to every kind of element. A 2006 Microsoft article on the STRIDE approach⁴ charts which ones do.

So each external entity raises 2 questions, each data flow 3, each data store 3 and each process 6. OWASP's free Threat Dragon tool adds repudiation for data stores⁵, making 4, and the template on this page does the same. Pick one chart and write it down, so everyone counts the same way.

Multiply it out. On Threat Dragon's chart, a design with 2 external entities, 5 processes, 3 data stores and 10 data flows raises 76 questions: 4 + 30 + 12 + 30. The total exists before anyone thinks of a threat, so it is a fair yardstick. "43 of 76 answered" tells a reviewer far more than a list of 43 threats.

For each question that applies, describe the attack in this system's terms: who does it, what they need first, and what they get. A threat you could paste onto any system has been named, not answered.

Then give each threat one response. OWASP's cheat sheet lists the four responses Adam Shostack describes²:

Prefer removing an exposure to guarding it: a field the server no longer accepts needs no validation. NIST's Secure Software Development Framework suggests you record the response to each risk⁶, including how mitigations will be achieved and why any exception was approved.

A row without a threat can mean four different things, and one status column hides the difference. Give each one a state:

• Ruled out: the threat can't happen here, and the reason is on the row.
• No reason given: marked not applicable without saying why. Treat it as unchecked.
• Never opened: nobody has asked it yet.
• Blocked: it waits on a missing fact, such as which role a job runs under. Give it an owner and a date.

Report coverage as a fraction, broken down by state. Then rank the trust boundaries by how many questions remain open, and work the worst one first. Take all its crossings together: one design decision, such as authenticating every connection between two tiers, can close many questions at once.

The last question, did we do a good enough job, gets answered in review. OWASP suggests checking that the diagram reflects the real system and every threat has an agreed response², and that the mitigations can be tested. Record the coverage figure on the day of sign-off, so later readers can tell what was known before release.

Re-run the model when a change moves the count, such as a new trust boundary, third party or store of customer data. Record the bigger decisions it produces, such as removing a feature, in an architecture decision record.

To skip the counting, open the template on this page in River. It reads your design documents, lists every element and flow, and opens a row for each question that applies.