Microsoft's Larry Osterman On Threat Modeling

Schneier has pointed out an excellent series of blog posts about threat modeling by Microsoft's Larry Osterman. The series focuses on the PlaySound API as an example. "As you go about filling in the threat model threat list, it's important to consider the consequences of entering threats and mitigations. While it can be easy to find threats, it is important to realize that all threats have real-world consequences for the development team. At the end of the day, this process is about ensuring that our customer's machines aren't compromised. When we're deciding which threats need mitigation, we concentrate our efforts on those where the attacker can cause real damage."

Comments

Re:That's got to be a hell of a job

[ScytheBlade1]

I've got his RSS feed in my RSS reader (http://blogs.msdn.com/larryosterman/rss.xml). I enjoy reading about the details of what goes on inside of MS, and I really do enjoy getting the story straight from the horse's mouth. For example, the whole "playing a video kills my network performance" thing. Slashdot is, well, Slashdot. It'll spin it how it wants to.

Larry started doing this threat modeling bit a while back, as the first article is dated some time ago. He's taken his time, and demonstrated what to do and how to do it in great detail. It's perfectly clear that he actually knows how to program things, correctly. And securely. This series of posts on threat modeling was wonderfully insightful into how things should be done.

Just because it's MS doesn't mean that it needs to be senselessly bashed. This would be one of the reasons as to why it shouldn't be. This guy knows what he's doing, and he does it well. Gasp, he works for MS.

Re:That's got to be a hell of a job

[beckerist]

Meh, I'm a newb to advanced security. For the rest of you (like me:) http://en.wikipedia.org/wiki/Threat_model

Basically, in a nutshell, a "threat model" is a designers / programmers way of saying "all potential flaws in our application." An example: a 1 meter hole in the side of the Death Star.
Just thought I'd pass that along as I learned it...eh...3 minutes ago.

Re:Look at how YOU would do it.

[toadlife]

When you open "My Computer" or "Windows Explorer" or even "Control Panel" on a Windows box you're opening IE. No, you are not. Explorer is explorer, not internet explorer. It uses some of the same dlls that Internet explorer uses, but that kind of library sharing is standard practice in any large desktop enviroment, weather it be OSX or KDE or Gnome.

Microsoft *could* reinvent the wheel 20 times in order to make sire every single app has their own libraries tpo use, but that would be stupid.

Re:Look at how YOU would do it.

[toadlife]

Yeah, you could "remove" Safari but the libraries that provide all of Safari's functionality would remain. You could also remove IE from Windows, but most of it's functionality would remain as IE most just calls external dlls - dlls that other parts of the system share.

If you really wanted to remove Safari from OSX, you would have to remove the entire webkit framework that it and many other OSX applications rely on, and I really don't think you would want to do that.

Re:I prefer Attack Trees.

[swillden]

A threat model is about admitting we have a bad product, saying that fixing it properly is too hard /expensive so we will try and work out what the largest holes are and fix those first.

Nonsense.

Threat modeling is a crucial exercise for any system that wants to be secure. Note that "system" is more than just "software", so just testing your software against all possible inputs is insufficient, even if it were actually possible.

For example, let's suppose the system under consideration is the Windows access control system, responsible for ensuring that only authorized users can read/write files. What are the attack vectors? How many of them can be addressed with input validation testing? How can your approach to security analysis/testing address an attacker who reads/writes data from the disk directly, bypassing your software (assuming you're writing Windows) entirely? Is this a threat that you need to mitigate? If so, what can you do to address it? Encrypt the data? Fine, where do you put the keys? Or, if the user enters the decryption key, how do you ensure that an attacker can't get that key? Can the attacker spoof the key entry screen? Why or why not? Can the attacker get it by shoulder surfing? Is that a threat you need to mitigate? What other ways might the attacker get the key?

Obviously, filesystem access control is a complex system and there are multiple software, hardware and social engineering attacks against it. Some can be mitigated by properly-implemented software, some can be mitigated (or, more accurately, shifted) by appropriate application of cryptography, some might require hardware modification and some might simply be out of scope. Threat modeling allows you to clearly define and document all of the analysis you have done, and all of the decisions you have made. It provides the basis for design and implementation -- which must both then be done properly or the other analysis was all irrelevant. The sort of testing you described is just one piece of proper implementation.

Security is much harder than you seem to think it is, and threat models are a key component of doing it right. I find it rather nice that Microsoft seems to be learning this lesson, even if it is something they should have done 10+ years ago.