Welcome again to a new post in the Threat Modeling vNext series!
We started a while back introducing a new approach to Threat Modeling, called Threat Modeling vNext, which represents a way to evolve it to a more flexible, modern and integrated process. We have discussed how Quality is an important factor, how it is a major problem for too many Threat Models, and then we have seen what quality means, through a series of posts which have span the last couple of months.
But really, what is Threat Modeling vNext and why it can help to address all the issues we are currently facing with Threat Modeling?
To answer this question, we have to step back in time, to how things were done in the recent past. My personal experience may differ from yours, dear reader, but I gather it is quite common. In essence, the available tools and guidance I have been able to rely on in the past were enough to start, and even provided a good set of information to learn the basics of the experience. This is how I learned the art, and I am still grateful to tools like Microsoft Threat Modeling Tool for having helped me to start. Nevertheless, as you become more proficient, you start seeing the shortcomings of an approach that is entirely based on Templates to identify Threats and that does not focus in any way on Mitigations.
These shortcomings have been the reason why we have started to think again about the Threat Modeling process: how can we provide a better experience to the expert? How can we increase effectiveness and efficiency by tackling the issues of the current processes as they are implemented by the current tools? As a result, what has become Threat Modeling vNext has been initially devised as a very limited change to the old approach, based mostly on the possibility to manually identify Threats and then associate Mitigations. What we wanted to do was to go beyond the possibilities offered by the available tools, mostly Microsoft Threat Modeling Tool, and give the expert the possibility to contribute with first-class Threats and Mitigations. In fact, the Threat Modeling Tool would allow to do that, at least in part, but the custom Threats you would add to a Threat Model would be completely disconnected from the diagram and look too much as a second thought, which is not acceptable given that those Threats typically are more relevant to the analyzed solution than anything identified automatically by the tool itself, provided that the Threat Modeler is proficient enough. But the most important shortcoming is related to the Mitigations, which are simply not supported by Microsoft Threat Modeling Tool.
Of course there are other tools out of here, like OWASP’s Threat Dragon, but they are free and too limited for being really useful, or they have a cost and do not exactly fit our vision, like Threat Modeler, Irius Risk or Foreseeti’s SecuriCAD.
So, Threat Modeling vNext started as the identification of a gap in the current tooling and with an analysis of what our group of Threat Modeling experts in Microsoft thought we would need from the ideal Threat Modeling tool.
And it grew to more, much more actually.
After we started thinking about what we needed out of a Threat Modeling tool, we were faced with the reality that the world is mostly inhabited by people who don’t really know Threat Modeling. On the contrary, Threat Modeling experts are as common as the fabled unicorn. And the two categories have quite different needs: in fact, while experts need to get lightweight guidance just to make sure nothing important is left out and tools to improve efficiency and effectiveness, beginners need a more guided approach and would even require to get feedback about the quality of their job, to identify mistakes and get guidance on how to fix them. Those needs are so different, that one would argue that experts and non-experts do need different tools, but the two Communities need to be as connected as it is possible to get, and separating them apart by adopting different tools would not be acceptable.
We also discovered that other roles would greatly benefit from having access to the Threat Model, like Project Managers and Business Stakeholders. Of course more Business-oriented roles would not respond well to technical information and instead they would need to get only the essential information required by their role. For example, a Business decision maker would need to know in a very concise way what is the risk, possibly in monetary terms, and what is being done to address it. A Project Manager would be more interested in the integration of the Threat Model with the tool of choice adopted for tracking the projects she manages, like Jira or Azure DevOps. Other roles like Risk Managers would also want to have a say on Risks and Mitigations, and sometimes a good platform for managing risk decisions like those related to the Exception process, or the integration with internal systems.
What we have learned is that Threat Modeling have a potential to provide value to Businesses which is still untapped. We have also learned that we need to evolve Threat Modeling from being a tool for few initiates, to be something providing value to most roles in an Organization, by delivering a personalized experience and by integrating it with the tools and processes that make sense for the context where it is adopted.
This is what Threat Modeling vNext is all about.
Next week we will spend a little more time to discuss the vision, by getting a closer look at how various personas would interact with the Threat Modeling vNext process and how they could use an hypothetical tool designed to implement it.