BETA2 NOW AVAILABLE!

BETA2 of Microsoft Threat Analysis & Modeling v2.0 (formerly codenamed “ACE Torpedo”) is now available for download here.

This is a significant milestone for us in our efforts to help realize the full potential of threat modeling in helping software development teams develop and maintain more secure applications. As mentioned earlier, we’ve been working with threat modeling for a few years now and this second version of our process really came out of a need to address some of the key observations we made during the lifetime of v1. I’ll be talking about some of these observations and how they translated into objectives that we needed to meet with this version going forward right here on this blog.

One of the very first things we need to do is to get some definitions out of the way. The phrase “threat modeling” is quite overloaded – in fact, the word “threat” seems overloaded quite a bit. In our process, we look at threat from a defenders perspective. If you start looking at threats from an adversarial or attacker’s perspective, you’re really not looking at threats at all, you’re looking at attacks – or in other words, the means to an end. We define threats as (to put it simply) an undesired event. By looking at these undesired events form a defender’s perspective, and not the adversarial, you ensure that you capture all the threats to your business. For example, if your admin goes in and accidentally deletes all your customer’s credit card numbers, isn’t that an undesired event that will have a negative impact on your business? What if there is a severe weather storm that causes a power surge that takes our your entire data center. Isn’t that a threat?

So the very first thing that needs to happen when threat modeling is that the development teams along with the business owners need to formally understand what are their threats.

You cannot begin to construct a defense before you understand what it is that you’re defending.

Coming up with these threats is where we saw one of our first challenges: why was it that when we took specs of the same application but gave it to two different development teams or even security teams, you got different threat models. The entire exercise tended to be subjective and very much an art form. It’s not going to work like this, it has to be objective. Given the same input, we need to produce the same output. Inherent in all applications we develop are underlying threats, the trick is to tease these threats out in a consistent and objective manner. Granted, not all development teams are going to respond to all the threats in the same way. You cannot tell people how to manage risk, all you can do is empower them to make effective risk management decisions. And this is essentially what we’re trying to do: you tell us what you’re trying to build and we’ll tell you what are some of the bad things that can happen. It is then up to you to decide, given your business objectives, how you want to respond to the risk associated with these threats.

I’m very excited about this release and am even more excited at what we have in the works around threat modeling…

-Talhah