New Threat Modeling Tool and ‘hip’ video released


So everyone is talking about the new .NET 2.0 based threat modeling (Beta) that has just been released. From my initial fly-by, it looks like a very different approach than the older tool which relied on software developers to learn and master the concepts of STRIDE and DREAD in the analysis.


I go around all the time talking to ISVs about writing secure code, and when I show them the older tool and process, they generally roll their eyes at me like I'm living on another planet. They all subscribe to the concepts of 'Threat Modeling", but the idea of spending hours, weeks, or even months setting up the model and all of its attributes came across like some kind of punishment. Everyone seemed to know it just wasn't going to happen.


The new tools seems to drastically simpliyfy the process, eliminates the STRIDE and DREAD categorizations, and creates tools to automatically generate threat trees based upon basic business descriptions of roles and processes. It also seems to allow for the creation of models from pre-defined starter templates, which many shops have asked for.


The tools looks great, and I plan on pushing it to my ISVs right away.


<Personal RANT >


There is also an associated marketing video which has recently been released, which sells the idea that the tool can be used by people who know little or nothing about security - to help secure a system.


I've always disliked this type of marketng, which in my opinion does more harm than good. It sets the expectatoin, that somehow, you can use this magical tool to 'secure' your system. 


Back in the 90's, as an industry, we tried selling the idea of 'RAD' (Rapid Application Development), in which programmers didn't need to understand the underlying architecture to 'glue' together their software. While the idea of reusable components is great, many project managers got the wrong idea about this which eventually  led to DECADES of crappy, buggy software that didn't scale well and was a nightmare to maintain. We all know that there are just no shortcuts to quality software - all programmers need to understand that underlying technology stacks and design patterns to write quality software..


So why are we now trying to sell the same idea for security, that developers don't have to understand basic security mechanics and architecture, and can just use this magic 'RAD' tool to secure a system! That's analagous to telling civil engineers that they can use a RAD software tool to design bridges, but they don't need to bother with the fundamentals of physics and load analysis!


In my mind, this is why so much bad software has been created over the last 30 years - because management are sold on the idea that there are shortcuts in software engineering, that programmers can simply cut and paste components together, and use magical tools like this to do the real work for them.


So I see a great tool here that I'm going to start selling to my customers. But please, spare us the markenting videos with fancy graphics and drum-beats in the background. We had enough of them in the 90's. Send developers to the Patterns and Practices software engineering site instead.


<Personal RANT/>


 


 


Comments (3)
  1. talhahm says:

    Hi Andrew,

    Thanks for posting about this. Your observations above around the need for a more simpler and non-security SME focused process/tool is exactly the reason for doing what we’re doing around threat modeling.

    I also completely agree with your rant as well but I would like to point out that messaging around the tool never says that you can secure a system just by using the tool. It says you can develop a strong strategy with the help of the process and yes in that process security subject-matter expertise is not needed in order to produce a feature-rich threat model – the tool is a feature of the process and the process also has a huge dependency on these Attack Libraries that, in fact, are created and verified by security SMEs.

    With this process, we’re acknowledging the difference between what the non-security SME (development teams) and the security SMEs are good at and building a process around that. I’ll be blogging about this in my blog (blogs.msdn.com/threatmodeling) after we get the stuff live… 🙂

    Thanks.

    -Talhah

Comments are closed.

Skip to main content