Some final thoughts on Threat Modeling...

I want to wrap up the threat modeling posts with a summary and some comments on the entire process.  Yeah, I know I should have done this last week, but I got distracted :). 

First, a summary of the threat modeling posts:

Part 1: Threat Modeling, Once again.  In which our narrator introduces the idea of a threat model diagram

Part 2: Threat Modeling Again. Drawing the Diagram.  In which our narrator introduces the diagram for the PlaySound API

Part 3: Threat Modeling Again, Stride.  Introducing the various STRIDE categories.

Part 4: Threat Modeling Again, Stride Mitigations.  Discussing various mitigations for the STRIDE categories.

Part 5: Threat Modeling Again, What does STRIDE have to do with threat modeling?  The relationship between STRIDE and diagram elements.

Part 6: Threat Modeling Again, STRIDE per Element.  In which the concept of STRIDE/Element is discussed.

Part 7: Threat Modeling Again, Threat Modeling PlaySound.  Which enumerates the threats against the PlaySound API.

Part 8: Threat Modeling Again, Analyzing the threats to PlaySound.  In which the threat modeling analysis work against the threats to PlaySound is performed.

Part 9: Threat Modeling Again, Pulling the threat model together.  Which describes the narrative structure of a threat model.

Part 10: Threat Modeling Again, Presenting the PlaySound threat model.  Which doesn't need a pithy summary, because the title describes what it is.

Part 11: Threat Modeling Again, Threat Modeling in Practice.  Presenting the threat model diagrams for a real-world security problem .[1]

Part 12: Threat Modeling Again, Threat Modeling and the firefoxurl issue. Analyzing the real-world problem from the standpoint of threat modeling.

Part 13: Threat Modeling Again, Threat Modeling Rules of Thumb.  A document with some useful rules of thumb to consider when threat modeling.

 

Remember that threat modeling is an analysis tool. You threat model to identify threats to your component, which then lets you know where you need to concentrate your resources.  Maybe you need to encrypt a particular data channel to protect it from snooping.  Maybe you need to change the ACLs on a data store to ensure that an attacker can't modify the contents of the store.  Maybe you just need to carefully validate the contents of the store before you read it.  The threat modeling process tells you where to look and gives you suggestions about what to look for, but it doesn't solve the problem.  It might be that the only thing that comes out from your threat modeling process is a document that says "We don't care about any of the threats to this component".  That's ok, at a minimum, it means that you considered the threats and decided that they were acceptable.

The threat modeling process is also a living process. I'm 100% certain that 2 years from now, we're going to be doing threat modeling differently from the way that we do it today.  Experience has shown that every time we apply threat modeling to a product, we realize new things about the process of performing threat modeling, and find new, more efficient ways of going about the process.   Even now, the various teams involved with threat modeling in my division have proposed new changes the process based on the experiences of our current round of threat modeling.  Some of them will be adopted as best practices across Microsoft, some of them will be dropped on the floor. 

 

What I've described over these posts is the process of threat modeling as it's done today in the Windows division at Microsoft.  Other divisions use threat modeling differently - the threat landscape for Windows is different from the threat landscape for SQL Server and Exchange, which is different from the threat landscape for the various Live products, and it's entirely different for our internal IT processes.  All of these groups use threat modeling, and they use the core mechanisms in similar ways, but because each group that does threat modeling has different threats and different risks, the process plays out differently for each team.

If your team decides to adopt threat modeling, you need to consider how it applies to your components and adopt the process accordingly.  Threat Modeling is absolutely not a one-size-fits-all process, but it IS an invaluable tool.

 

EDIT TO ADD: Adam Shostak on the Threat Modeling Team at Microsoft pointed out that the threat modeling team has a developer position open.  You can find more information about the position by going to here:  https://members.microsoft.com/careers/search/default.aspx and searching for job #207443.

[1] Someone posting a comment on Bruce Schneier's blog took me for task for using a browser vulnerability.  I chose that particular vulnerability because it was the first that came to mind.  I could have just as easily picked the DMG loading logic in OSX or the .ANI file code in Windows for examples (actually the DMG file issues are in several ways far more interesting than the firefoxurl issue - the .ANI file issue is actually relatively boring from a threat modeling standpoint).

Comments

• Anonymous
  October 01, 2007
  PingBack from http://www.artofbam.com/wordpress/?p=4297

• Anonymous
  October 01, 2007
  I'd sure like to see Microsoft's analysis of the threat model for ActiveX in the HTML control, including security zones.

• Anonymous
  October 01, 2007
  Larry Osterman includes all the links to his threat modeling series here . A must-read for folks designing

• Anonymous
  October 01, 2007
  Larry Osterman includes all the links to his threat modeling series here . A must-read for folks designing

• Anonymous
  October 01, 2007
  The comment has been removed

• Anonymous
  October 01, 2007
  Eam: Why not?  First off, LUA is all about enabling the transition to normal user accounts - think of it as a forcing function.   And threat modeling as an analysis tool is valid, even if the user IS running as an administrator.  And if you're writing network facing services, it's especially useful.

• Anonymous
  October 01, 2007
  By the way, did you realize you have been slashdotted?

• Anonymous
  October 01, 2007
  Eam, Larry: I think you may both be confusing LUA (Limited User Account) with UAC (User Account Control). If you don't want people to run as admin (which I agree with), then LUA is the alternative, i.e. they should have limited accounts!

• Anonymous
  October 02, 2007
  John: You're absolutely correct. My mistake.

• Anonymous
  October 02, 2007
  The comment has been removed

• Anonymous
  October 02, 2007
  eam: You're absolutely right.  And we've known that most malware written today is stopped completely by LUA.  UAC is the first step towards forcing users to run with LUA. The good news is that applications are starting to get a clue and the forcing function appears to be working.

• Anonymous
  October 02, 2007
  Larry Osterman na swoim blogu zamieścił serię artykułów na ten temat. Ciężkie, ale warte poznania. Nawet mimo tego, że David LeBlanc na temat przydatności threat modellingu ma nieco inne zdanie, choć wcale nie jednoznacznie negatywne. Temat i

• Anonymous
  October 03, 2007
  LUA is great, but it doesn't solve the malware problem. Once everybody is running as LUA, the malware writers will just make malware that runs correctly as LUA also.

• Anonymous
  October 03, 2007
  The comment has been removed

• Anonymous
  October 15, 2007
  I've been reading a set of posts by Larry (who used to work just down the hall from me...) on threat

• Anonymous
  October 15, 2007
  I've been reading a set of posts by Larry (who used to work just down the hall from me...) on threat