Threat modeling for teams that have never done it
The word scares people: threat modeling sounds like something for specialists with certifications and frameworks. In practice it’s four questions and a whiteboard, an hour-long exercise any team can run on its own, and one that can change how you look at your own architecture.
The demystification
Threat modeling is not a framework you have to be certified in. It is not a forty-page document. It is not something you need a hired specialist to get started with.
It’s a structured way of asking a question your team should already be asking:
“How could this go wrong, on purpose?”
Ordinary design thinking asks how things can fail. Threat modeling asks how things can be attacked. The difference is an adversary with intent, and that difference changes what you see.
The exercise: four questions, one whiteboard, one hour
The four questions below are not mine. They are the frame Adam Shostack formulated, first in Threat Modeling: Designing for Security (2014) and given here in their current wording, with the Manifesto’s “enough” in the fourth, and the Threat Modeling Manifesto builds on them. I repeat them because they are the best ones out there, and because knowing they have a source makes them easier to defend in a meeting than “something the tech lead came up with”.
Gather the team in front of a whiteboard. Draw the system; boxes and arrows will do. Then ask the four questions, in order:
1. What are we working on? Draw the data flow: where data comes in, where it’s stored, where it goes out, who talks to what. The first findings often arrive right here: an arrow nobody knew about, or an integration half the team had forgotten. The map alone is worth the hour.
2. What can go wrong? Now you think like an attacker, along every arrow and every box: what if the input here is hostile? What if someone impersonates this service? What if this log is read by the wrong person? What if this API is called a million times? No right answer is required, just the systematic walk along the map. Write it all down; judge nothing yet.
If the team runs out of ideas after ten minutes, and most do the first time, there is a checklist: STRIDE, devised by Loren Kohnfelder and Praerit Garg at Microsoft in 1999 and in use ever since; the original memo is still online. Six categories to hold up against every box and every arrow: Spoofing (pretending to be someone), Tampering (altering data), Repudiation (denying having done something, with no trail to contradict it), Information disclosure (leakage), Denial of service and Elevation of privilege. Six words on a sticky note is the whole tool, and it takes you from “we can’t think of anything more” to another half hour of findings.
3. What are we going to do about it? Sort the findings into four piles: fix (close the hole), reduce (make the damage smaller: least privilege, rate limiting), accept (deliberately, documented; some risks you can live with), investigate (we don’t know enough yet). Every pile gets owners and lands where work actually happens: in the backlog, not in an archive.
4. Did we do a good enough job? Set a date for the next round. The system changes; the model has to follow. A threat model from last year describes a system that no longer exists, and it follows the same law of decay as all other documentation.
Why the team itself, not an expert
A hired specialist will probably find more, and find it faster. Even so, the team’s own hour is worth more, for three reasons:
The team knows the system: the shortcuts, the exceptions, “that weird integration” no report catches. The team has to live with the findings, and ownership of risk is built like all other ownership: through participation, not delivery. And most important of all: the exercise trains an eye. The aim is that after a few rounds the questions come up on their own, in design discussions and pull requests; the Manifesto calls it a journey of understanding rather than a snapshot. That eye is the real deliverable, and it cannot be hired in.
The expert has a place: as reinforcement once the eye is established, and for the systems where the stakes are highest. But the order is team first.
Start ugly
Don’t wait for maturity, tools or somebody with the right title.
Book an hour. Draw the system. Ask the four questions.
The first model will be incomplete. It’s supposed to be. It’s still infinitely better than the perfect model you never made.
The arrow nobody knew about? It often turns up in the first quarter of an hour.