Threat Modeling Again, Pulling the threat model together

  • Article

So I've been writing a LOT of posts about the threat modeling process and how one goes about doing the threat model analysis for a component.

The one thing I've not talked about is what a threat model actually is.

A threat model is a specification, just like your functional specification (a Program Management spec that defines the functional requirements of your component), your design specification (a development spec that defines the architecture that is required to implement the functional specification), and your test plan (a test spec that defines how you plan on ensuring that the design as implemented meets the requirements of the functional specification).

Just like the functional, design and test specs, a threat model is a living document - as you change the design, you need to go back and update your threat model to see if any new threats have arisen since you started.

So what goes into the threat model document?

  • Obviously you need the diagram and an enumeration and description of the elements in your diagram. 
  • You also need to include your threat analysis, since that's the core of the threat model.
  • For each mitigated threat that you call out in the threat analysis, you should include the bug # associated with the mitigation
  • You should probably have a one or two paragraph description of your component and what it does (it helps an outsider to understand your diagram), similarly, having a list of contacts for questions, etc are also quite useful.

The third item I called out there reflects an important point about threat modeling that's often lost.

Every time your threat model indicates that you have a need to mitigate a particular threat, you need to file at least one bug and potentially two.  The first bug goes to the developer to ensure that the developer implements the mitigation called out in the threat model, and the second bug goes to a tester to ensure that the tester either (a) writes tests to verify the mitigation or (b) runs existing tests to ensure that the mitigation is in place.

This last bit is really important.  If you're not going to follow through on the process and ensure that the threats that you identified are mitigated, then your just wasting your time doing the threat model - except as an intellectual exercise, it won't actually help you improve the security of your product.

 

Next: Presenting the PlaySound threat model!