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:
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: http://members.microsoft.com/careers/search/default.aspx and searching for job #207443.
 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).