Threat Modeling (Adam Shostack)
Main Argument
Security is something you reason about and design in, not a feature you add later. The way to do it is structured, not heroic: anyone can find what can go wrong with a system by working through a small set of questions and structured enumerations, rather than relying on the intuition of a lone security expert. The durable content is this disciplined adversarial reasoning and the boundary-and-privilege concepts it rests on, not the specific tools or checklists.
Key Takeaways
- Threat modeling answers four questions: what are we working on, what can go wrong, what are we going to do about it, and did we do a good job?
- Structure beats imagination. Enumerations like STRIDE (spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege) make "what can go wrong" systematic instead of a one-off brainstorm.
- Trust boundaries are where trust changes; anything crossing one must be validated rather than assumed safe. They tell you where defenses belong.
- Least privilege bounds the damage: give each component only the access it needs, so a compromise stays contained.
- You cannot mitigate everything, so threat modeling is inseparable from prioritization: each threat gets an explicit decision to mitigate, accept, transfer, or eliminate.
- Do it during design, when flaws are cheapest to remove, and revisit it as the system changes.