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.