I took some time to download and install Microsoft’s latest application threat modeling tool. It is certainly a departure from the method documented in the Threat Modeling book. Not only that, the tool or the developers of the method manage to continue the confusion between threat, vulnerability and attack. They simply stop using the term vulnerability altogether. I may be picking nits here, but we need some consistency. That consistency can be had only if we agree on terms. How then can we have a meaningful conversation or, even better, how can we manage to use a tool that redefines terms without telling us. For example, the new tool quite nicely manages to automagically create “threats” based on our previously defined role, data, component and use cases. This really is quite nice. It forces the would-be modeler to really identify assets, actors and access controls within an application. But I digress. The “threat” you end up with seems to some sort of generic threat, but mysteriously you only have the ability to add attack countermeasures. But wait, where’s the attack? Sure we *could* say that the attack is the threat, but that is going a bit to the extreme isn’t it? I mean a threat is always an attack? I don’t think so, unless you say your building was attacked by a fire yesterday. So the confusion begins. Where is the vulnerability that realizes this threat? It seems to me that the guys were trying to hide|abstract|remove this ability. Correct me if I’m wrong (and I may be), but I thought the point of this threat modeling exercise was to use the identification of threats to detect and correct vulnerabilities that realize these threats. The tool goes a long way to make sure you understand what you’re doing in terms of understanding the application’s structure and function, but it leaves the analyst in a lurch when it comes time to use the identified threats as the source material for vulnerability analysis. I must say that their “attack” library is an excellent idea. Again though, they manage to confuse terms. They seemingly exchange attack for threat again. If we look deep enough into this library we finally see the term vulnerability pop up. Oddly enough, it actually *is* vulnerability information. What is odd is that some of the attacks appear to be threats, while others seems to be vulnerabilities. For example, the HTTP Replay Attack isn’t really an attack or a threat in my view. The threat in this case is that a user may attempt to spoof the identity of another user. The vulnerability is that the application, to use MS’s tool, utilizes “Ineffective or lacking verification of uniqueness of a request”. So where does the “HTTP Replay Attack” go? Well, I guess you can append it to the threat if you must, but why? The general threat and detailed vulnerability are the definition of a replay attack. Did I beat that enough? It is really not all bad because this “attack” library is quite nice. We happen to use something quite similar in my organization. We have a large list of well-known threats and when building our models we use these to define the high-level threats that are present. We customize the vulnerability information somewhat since it is application specific. Yes, I know, the vulnerability isn’t application specific in the strictest sense, but we like to put application specific information into our vulnerabilites so the readers know where to find them. Who knows, maybe the tools will grow on me, but with this sort of confusion I seriously doubt it.

Update: I read some of the other posts here. To be fair, it seems the tool’s focus has shifted somewhat. It no longer aims to be a purely security sme tool, but a developer, business and sme tool. With this in mind, I can understand why they’ve made some of the decisions with the tool. I still don’t entirely agree with some of the approach, but I guess the proof will be in the using.  In addition, it may be my “interesting” vantage point. From my view of the world, the devs won’t likely adopt a practice such as this for time time (especially since we’re not an MS dev shop). Because of this, we perform much of the discovery and threat identification. Take my views with a grain of salt.