Share via

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!

Comments

  • Anonymous
    September 14, 2007
    PingBack from http://msdnrss.thecoderblogs.com/2007/09/14/threat-modeling-again-pulling-the-threat-model-together/

  • Anonymous
    September 14, 2007
    Awesome description of the objective as artifact and as actionables: "If you're not going to follow through on the process and ensure that the threats that you identified are mitigated, then [you're] just wasting your time doing the threat model." You threw me at first, since some mitigations involve identification of contingency procedures (that is, what is worked out for the eventuality of an occurence, not only what is done up front to limit the consequences, reduce the hazard, etc.), similar to mitigation in risk analysis.  I can see how, generally, what you'd have to do in the case of an embedded feature like PlaySound is close the door.  Shut.  Now. I'll be seeing if you have any other kind of mitigation in your PlaySound model, although I can imagine that they all turn into black-and-white here's the defect report, here's the repair-confirmation test requirement, etc. I think bug reports for carrying and tracking the actionables is outstanding.  "Wow," I said, "oh duhh, Dennis (slaps forehead on desk)." Great series.  

  • Anonymous
    September 14, 2007
    what I always wondered is why there are no mitigation (runnable scripts) when a security patch is issued the SDL is excellent, but without quickfix mitigation (scripts) SDL is useless when there are bugs, sort of like a transaction without rollback or compensation mechanism my dream would be Windows shutting down stuff and lock it after x time of no usage (be it port, service or feature)

  • Anonymous
    September 14, 2007
    stefan, I guess I'm confused as to what you're looking for. The threat modeling process works BEFORE the security patches happen and is a mechanism to avoid them.  If someone has to issue a security patch, it's an indication that the threat modeling process has broken down (I have a couple of posts for later in the series about how that can happen).

  • Anonymous
    September 15, 2007
    All I need to know about threat modeling I learned from Larry Osterman.  Thanks a lot for the series.

  • Anonymous
    October 01, 2007
    I want to wrap up the threat modeling posts with a summary and some comments on the entire process. Yeah,

  • Anonymous
    October 02, 2007
    Larry, I do acknowledge the fact that the threat modelling works BEFORE the patches. IIS 6 and SQL 2005 show that SDL works as they are immensely better (more secure) than their competitors. I was only pointing out there should be a way to mitigate security bugs as they are found; ie as the threat modelling process identifies areas (entry points) where security bugs are likely to happen, an extension to the process itself could also be to develop a possible mitigation or lockdown of an area in form of a script, GPO, registry value which could be applied by a syadmin as soon as a vulnerability is discovered.

  • Anonymous
    February 14, 2008
    One of the critiques of the threat modeling blog posts process is that it can seem interminable. And

  • Anonymous
    February 14, 2008
    One of the critiques of the threat modeling blog posts process is that it can seem interminable. And