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: 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 (16)
  1. Resuna says:

    I’d sure like to see Microsoft’s analysis of the threat model for ActiveX in the HTML control, including security zones.

  2. Anonymous says:

    Larry Osterman includes all the links to his threat modeling series here . A must-read for folks designing

  3. Anonymous says:

    Larry Osterman includes all the links to his threat modeling series here . A must-read for folks designing

  4. Anonymous says:

    Hey baby:

    I came upon this mess from Bruce Schneier’s site, and I have to say the whole thing, at least at the moment, seems like an exercise in futility.

    You can model all the threats you want, but the fact is that no one who has made a serious attempt to hack a Windows machine has failed. And this is all due to one reason: the default account being an administrator.

    The only way to "raise the bar" for Windows security is to change this practice. I mean *actually* change it — LUA is a joke.

    I’m not taking "pot shots at Microsoft" as you accused another commenter of doing. I’m an ASP.NET/C# programmer running Windows XP as a limited user at home, and I think this is the best setup for the work I do.

  5. 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.

  6. Anonymous says:

    By the way, did you realize you have been slashdotted?

  7. JohnCKirk says:

    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!

  8. Anonymous says:

    John: You’re absolutely correct. My mistake.

  9. Anonymous says:


    I’m not debating the usefulness of threat modeling, and I think you’ve done a great job explaining it here.

    My point is that, while it’s nice Microsoft is trying to "enable the transition" to normal accounts, there’s no real security until they actually *make* the transition.

    Here Jeff Atwood finds that a number of drive-by downloads just don’t work as a limited user, even on a vulnerable browser:

    There’s not even a "Malware detected, cancel or allow?" prompt, which most regular people would not read and dismiss with a quick "allow."

    Even if Microsoft modeled all sorts of threats and made perfect software, people are still going to run poor-quality third party applications. If those apps are running with admin privileges, the user is in trouble.

  10. 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.

  11. Anonymous says:

    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

  12. Anonymous says:

    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.

  13. Gabe: Absolutely.  There’s absolutely nothing that a botnet client does that can’t be done by a normal user.  It sucks, but it’s true.

  14. Anonymous says:

    I’ve been reading a set of posts by Larry (who used to work just down the hall from me…) on threat

  15. Anonymous says:

    I've been reading a set of posts by Larry (who used to work just down the hall from me…) on threat

Comments are closed.

Skip to main content