Threat Modeling for People Who Think Threat Modeling Is for Other People

Threat modeling sounds like a thing that happens in rooms you are not invited to, run by people with certifications. In practice the version that catches most real problems is four questions asked over a whiteboard for one hour, and any engineer can run it.

The four questions, stolen from Adam Shostack because everyone steals them from Adam Shostack. What are we building. What can go wrong. What are we going to do about it. Did we do a decent job.

The first question does most of the work. Draw the system, boxes and arrows, and mark two things on the drawing: where data crosses a trust boundary, and where the stuff worth stealing lives. Trust boundaries are anywhere the level of trust changes, internet to your API, your API to your database, your service to a third party. Almost every finding in every session I have run lives on one of those lines, because boundaries are where assumptions go to die.

For what can go wrong, you do not need to be creative, you need to be systematic. Walk each boundary and ask the boring questions. Can someone pretend to be someone else here. Can they tamper with what crosses. Can they read what they shouldn't. Can they flood it. For an hour long session with normal engineers, that checklist beats free form brainstorming every time, because free form produces movie plots and checklists produce findings.

Then rank what you found by "attacker effort versus damage," fix the cheap catastrophic ones now, ticket the rest, and calendar a revisit when the architecture changes.

The mistake is thinking this is a specialist activity requiring specialist tools. It is a structured hour of pessimism. The people who built the system are the best qualified pessimists available, they just need the four questions.