What Makes a Good Threat Model
While trying to create threat model template for customers, I analyzed many threat models inside and outside Microsoft. It was insightful to see the patterns of what was useful across threat models and what was noise.
A good threat model has the following components:
- Security objectives. What must you do vs. what's nice to do? These set the boundaries of what's in scope vs. what's out of scope.
- Key Scenarios. Where and how will your software be used? These put your software in context and gives you context while evaluating.
- Security mechanisms. These shine the spotlight on explicit security engineering decisions.
- Trust boundaries. These help you focus on critical places where security trust levels change. These also help prioritize entry points.
- Data flows. These help you trace data through the system, to expose potential issues.
- Entry points. Where do you accept input? These are primary attack vectors.
- Exit points. Where do you write output?
- Threats. A list of these helps you put perspective when ranking vulnerabilities. What's the worst that can happen? What can you live with?
- Vulnerabilities. A list of these helps you identify actionable places in your software to address security concerns.
A good threat model serves the following purposes:
- Informs your design
- Scopes your security testing
- Helps reviewers evaluate your security decisions
By far, the most tangible output of the threat modeling activity is a prioritized list of vulnerabilities. These are action items for your developers and input for your testers. The developer makes a call on whether and how to fix, and the tester will test the fix.
This sample Template for a Web Applications Threat Model comes very close to showing what I've empirically seen to be useful, though there's always a gap between reality and real-time.
