Threat Modeling Is a Design Conversation

Here is what a useful threat model often looks like: no diagram worth keeping. Picture four people at a whiteboard for forty minutes, arguing about whether a password-reset link should log the user in. The backend engineer says yes, because it saves a step. The support lead says every account-takeover ticket they handled this year started with someone else's inbox. The product manager asks what the drop-off is at the extra login screen. Nobody knows. They write it down as a question, choose the safer option for now, and move on.

That is threat modeling. Not the tool, not the report, but the moment when people with different knowledge are forced to say what they assume out loud.

AI assistants can now list plausible threats for almost any architecture in seconds. But a list of threats is not a threat model, any more than a list of possible bugs is a code review. The value is in deciding which threats matter, for whom, and what the team will pay to address them.

Where the vocabulary came from

STRIDE is older than most of the systems people apply it to. Loren Kohnfelder and Praerit Garg described it on 1 April 1999 in a paper called "The Threats to Our Products", published in Microsoft's internal Interface journal. Adam Shostack, writing on its twentieth anniversary, called it the first paper to give a structured way to find threats.

The six letters map to the property each threat violates:

• Spoofing violates authentication
• Tampering violates integrity
• Repudiation violates non-repudiation, or accountability
• Information disclosure violates confidentiality
• Denial of service violates availability
• Elevation of privilege violates authorization

STRIDE is a prompt, not a taxonomy you must complete. Its job is to stop a group from fixating on the one threat everyone already worries about.

Shostack's book, Threat Modeling: Designing for Security (Wiley, 2014), did a great deal to turn this into a practice working engineers could adopt. It also popularised a simpler frame that has outlasted many methodologies. In its current wording the four questions are:

1. What are we working on?
2. What can go wrong?
3. What are we going to do about it?
4. Did we do a good job?

The wording has changed since 2014. Shostack notes on his GitHub page that "we" replaced "you" to be inclusive and collaborative, and "are" replaced "should" in the third question to focus on action. Those are small edits that say a lot. The questions are addressed to a team, and the third one expects a decision, not a recommendation. A second edition, retitled Threat Modeling: Designing for Security in an AI World, is listed on his site for February 2027.

The manifesto put people first

In November 2020 a working group including Zoe Braiterman, Adam Shostack, Jonathan Marcil, Stephen de Vries, Irene Michlin and Kim Wuyts published the Threat Modeling Manifesto. It was deliberately modeled on the Agile Manifesto, and its values read like a correction to how threat modeling had been sold:

• A culture of finding and fixing design issues over checkbox compliance
• People and collaboration over processes, methodologies, and tools
• A journey of understanding over a security or privacy snapshot
• Doing threat modeling over talking about it
• Continuous refinement over a single delivery

One of its principles is the line I quote most: "Dialog is key to establishing the common understandings that lead to value, while documents record those understandings, and enable measurement." The document is the receipt. The dialog is the purchase.

OWASP's Threat Modeling Cheat Sheet makes the same point in plainer language: "Threat modeling is also typically a team effort," and the model should be reviewed by all stakeholders, "not just the development or security teams."

A worked example: password reset

Here is a compressed version of that hypothetical whiteboard session, written up the way a team should record it.

What are we working on?

A web application with email-based password reset. The flow:

1. User submits an email address on /forgot.
2. Server generates a token, stores it, and emails a link to /reset?token=....
3. User opens the link, sets a new password.
4. Server updates the password hash and marks the token used.

Trust boundaries: the browser, our API, the database, the transactional email provider, and the user's mailbox, which we do not control at all.

What can go wrong?

We walked STRIDE across each step. Not every letter produced something, and that is fine.

#	STRIDE	Threat	Where	Mitigation	Owner
1	Information disclosure	/forgot reveals whether an email is registered through different messages or response times	Step 1	Identical response and similar timing for known and unknown addresses	Backend
2	Spoofing	Attacker guesses or brute-forces a reset token	Step 3	Token from a CSPRNG, long enough to resist guessing, single use, short expiry; rate-limit token attempts	Backend
3	Tampering	Reset link built from the request's Host header, so an attacker can point it at their own domain	Step 2	Hard-code or allowlist the base URL	Backend
4	Information disclosure	Token leaks to third-party scripts or analytics via the Referer header	Step 3	Referrer-Policy: no-referrer on the reset page; no third-party scripts there	Frontend
5	Denial of service	Attacker floods a victim's inbox with reset emails	Step 1	Per-account and per-IP rate limits	Backend
6	Elevation of privilege	Reset link logs the user in, so a compromised inbox becomes a live session	Step 4	Send the user to the normal login after reset	Product + Backend
7	Repudiation	User claims they never reset; no record of who did or from where	Step 4	Log reset request and completion with IP and user agent; notify the account by email	Backend + Support
8	Spoofing	Old sessions survive the reset, so an attacker who already had a session keeps it	Step 4	Offer to end other sessions, or end them automatically after a suspected compromise	Backend

Most of these line up with the OWASP Forgot Password Cheat Sheet, which is exactly the point. You do not need to invent the controls. You need a room that agrees which ones apply here and who will build them.

What are we going to do about it?

Rows 1 to 5 and 8 went straight into the sprint. They were cheap and uncontroversial.

Row 6 was the argument. The team chose to send users to the login page after reset and to measure the drop-off, with an agreement to revisit if it was material. That decision belongs to product as much as to security, which is why product was in the room.

Row 7 surfaced something nobody had considered: support had no way to see reset history when handling a disputed account. That became a small admin-panel ticket, and it would never have appeared from a security review alone.

Did we do a good job?

We checked three things. Every row has an owner and a ticket. The model lives next to the code, so a change to the flow prompts an update. And we asked one uncomfortable question: what happens if the email provider itself is compromised? We had no good answer, so we wrote it down as an accepted risk with a named approver. An honest gap is better than a hidden one.

Where AI fits, and where it does not

Use a model to draft the first pass at question two. It will produce a decent STRIDE table for a well-known flow like this one in seconds, and it will sometimes catch a row the team missed.

It will not tell you that your support team cannot see reset history, that your largest customer's SSO setup makes row 6 moot for them, or that the product manager will fight a login step because of a conversion target. Those come from people who know the system and the business. The manifesto's second value, people and collaboration over tools, matters more now that the tools are good, not less.

Keep the sessions short, keep them close to design changes, and keep asking the four questions out loud.

Sources

1. Shostack: 20 Years of STRIDE, Looking Back, Looking Forward — Kohnfelder and Garg's 1 April 1999 paper in Microsoft's Interface journal.
2. Shostack's Four Question Framework (GitHub) — current wording of the four questions, why it changed, and the 2014 Wiley book as the earliest citation.
3. Threat Modeling book page, Shostack + Associates — the 2014 first edition and the second edition listed for February 2027.
4. Threat Modeling Manifesto — values, principles, and working group members.
5. Shostack: Threat Modeling Manifesto announcement — 17 November 2020 release, modeled on the Agile Manifesto.
6. OWASP Threat Modeling Cheat Sheet — STRIDE property mapping, data flow diagrams, and threat modeling as a team effort.
7. OWASP Forgot Password Cheat Sheet — the controls behind the worked example's mitigations.