What are the four questions in Shostack's four-question threat modeling frame?

## The frame Shostack's four questions are the smallest complete description of what a threat modeling exercise does. In their usual wording: 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 enough job?** They are also the spine of the Threat Modeling Manifesto, which is why almost every modern description of the practice reduces to them. Their value is that they are short enough to remember in a design review and general enough to apply to a mobile client, a batch pipeline or a cluster. ## What each question hands back **Question one produces a model.** Not a document, a *model*: what the parts of the system are, what data moves between them, who runs each part, and where control changes hands. The answer is normally a data-flow diagram with trust boundaries drawn on it, agreed by the people who actually build the thing. The critical property is that it describes the system as it is or as it is about to be, not as an old design document once described it. **Question two produces threats.** Given the model, what could an attacker in some position do to some asset. This is where a structured enumeration technique fits: the frame deliberately does not pick one for you, and the choice is a separate decision from the loop itself. **Question three produces decisions.** Every threat gets a disposition and a name attached to it. A threat that ends the session with no decision is not output; it is a note. **Question four produces evidence, or a re-entry.** It asks whether the three answers above were good enough: was the model right, did enumeration reach the whole of it, and did the decisions actually land in the running system. ## Why the order is not decorative Each question is scoped by the answer to the one before it. You cannot enumerate threats against a system nobody has drawn, because you have no elements or flows to enumerate against - teams that skip question one end up listing generic vulnerability classes rather than threats to *this* design. Question three is scoped by question two: you can only decide about threats you named. Question four is scoped by all three, which is exactly why it is the one that is skipped - by the time it is due, the session is over and everyone has moved on. The order also explains a common interview probe: if the model changes, the answers downstream of it are suspect. A new integration added after the exercise is a change to question one, and it invalidates part of question two whether or not anyone reopens the file. ## A loop, not a checklist The frame is drawn as a cycle. A pass through it ends either with a defensible *yes* to question four or with a return to the question that failed - a wrong model sends you to one, thin enumeration to two, undelivered mitigations to three. Teams that treat the four questions as a template fill it in once at kickoff and never return; teams that treat it as a loop re-enter it when the architecture changes and when the decisions from question three were due to be delivered. A concrete shape of this: a national exam-results release portal is walked through the loop the week before results day. Question one is deliberately answered from the live release architecture - the caching tier and the pre-release staging path that exist today - rather than from last year's design doc. That single choice changes question two's output, because an authenticated candidate probing for early access can only reach the paths that actually exist now. Answering question one from a stale picture would have produced a threat list about a system nobody is running. ## What the frame does not do It is not a methodology, and saying so is usually a plus in an interview. It does not enumerate threat categories, it does not score or order what you find, and it does not tell you who should be in the room. It gives four checkpoints that any of those techniques can be slotted into, and a definition of done that is stronger than *we held a meeting*. ## The usual failure Most people can recite three questions. The fourth is the one that separates someone who has read about threat modeling from someone who has run it, because it is the only question that asks about the quality of your own work rather than about the system.