A development team can threat model a feature in one hour if it answers four questions in order and leaves with tickets rather than a document. The questions come from the Threat Modeling Manifesto: what are we working on, what can go wrong, what are we going to do about it, and did we do a good enough job. Nobody needs a security architect, because the work does not depend on one person's innate ability.
The hour at a glance
| Minutes | Question | Output |
|---|---|---|
| Before | - | One person drafts the data flow diagram |
| 0-10 | What are we working on | Corrected diagram, numbered entry points |
| 10-30 | What can go wrong | Threat list, grouped by STRIDE category |
| 30-45 | What are we going to do about it | A response for every threat |
| 45-55 | Tickets and tests | One ticket and one test per mitigation |
| 55-60 | Did we do a good enough job | Completeness check |
Before the session
Pick one feature, not a whole product. Finding issues at design time is far more efficient than resolving flaws in production, so run the session before the build starts.
Invite a developer, the requirements owner and, if infrastructure is involved, someone from operations. One of them brings a draft data flow diagram, made in a tool whose files the team can edit later.
Minutes 0-10: what are we working on
The group corrects the draft. The OWASP Threat Modeling Cheat Sheet asks for a clear view of trust boundaries, data flows, data stores, processes and external entities, which often represent possible attack points. Check that each one is on the page.
If some participants are not technical, brainstorm the flows on a whiteboard instead of insisting on DFD notation.
Number the entry points as you go, using major.minor notation for layered ones (1, 1.2, 1.2.1), as the OWASP community process page does, and mark the exit points too. An error message on a login page can enable attacks through the matching entry point, such as account harvesting ("username not found") or SQL injection (via SQL exception errors).
Minutes 10-30: what can go wrong
Start with STRIDE for a technical design. Walk each component, data flow and trust boundary through the six categories and record which entry point ID each threat touches.
| Category | Violates | Example |
|---|---|---|
| Spoofing | Authentication | Stolen authentication token used to impersonate a user |
| Tampering | Integrity | Unintended database updates through the application |
| Repudiation | Accounting | Logs manipulated to cover actions |
| Information Disclosure | Confidentiality | Data extracted from a database of user accounts |
| Denial of Service | Availability | User locked out by many failed authentication attempts |
| Elevation of Privileges | Authorization | A JWT tampered with to change the role |
For a business rule, add misuse cases: actions performed out of order, repeatedly, concurrently or for an unintended outcome. For one multi-step attacker goal, use an attack tree. Do not add techniques to look thorough; state why each fits and what it leaves uncovered.
Likelihood times impact sounds tidy, but both are hard to estimate and the product ignores the cost of the fix. In one hour, a rough high, medium or low per threat is enough.
A worked example: password reset
Take a password reset. The diagram shows the browser, the web application, the user database and a mail service, with a trust boundary between the internet and the application. The reset request is entry point 3 and the emailed link is 3.1 (illustrative IDs).
The group finds four threats. A reset link works for someone other than the owner (spoofing). A "no account with that address" message reveals who is registered (information disclosure). Reset events are not logged (repudiation). Someone triggers repeated resets against a victim (denial of service).
Minutes 30-45: what are we going to do about it
Every threat gets one of four responses:
- Mitigate: reduce the likelihood that the threat materialises.
- Eliminate: remove the feature or component causing it.
- Transfer: move contractual or financial responsibility to another party.
- Accept: do nothing, because the other options do not fit business constraints.
Transfer does not reduce likelihood or harm by itself, so write down who owns the remaining controls and the residual risk. For accepted threats, record who accepted the risk and why.
Minutes 45-55: tickets and tests
Turn each agreed mitigation into a requirement a developer can pick up. One row per threat is enough:
| Threat ID | STRIDE | Ticket | Test |
|---|---|---|---|
| 3.1-S | Spoofing | Make reset links single-use and short-lived | Used or expired link is rejected |
| 3-I | Information Disclosure | Return one generic response for any address | Known and unknown addresses give identical responses |
| 3-R | Repudiation | Log every reset request | A reset attempt appears in the log |
The test column makes the model more than a diagram. Each mitigation needs a check that fails when the control is missing. Abuse cases translate directly: replay the request, send the steps out of order, send two requests at once. Put the tickets in the feature's own backlog with the threat ID in the title.
Minutes 55-60: did we do a good enough job
Start with a plain check: are there records showing a diagram, a threats list and a control list? If any is missing, the session is not finished. Confirm that every threat has a response, that each mitigation says how the team will implement it, and that accepted risks say why.
Then keep the model alive. Update it alongside the system, and when the design changes, rerun only the affected parts.
Where to start
- Choose one upcoming feature and book an hour with a developer, the requirements owner and someone from operations.
- Have one person draft the data flow diagram with trust boundaries marked. The group corrects it and numbers the entry points in the first ten minutes.
- Run STRIDE across each component and flow for 20 minutes, recording the affected entry point ID with every threat.
- Assign a response to each threat, note who owns any accepted or transferred risk, then create one ticket and one test per mitigation.
- Store the diagram, threat list and control list with the feature's documentation. If you want an outside view of the first model, our consulting service can review it, and the recorded threats make a good scope for a later penetration test.
