Threats Manager Studio

You may have read that Threats Manager Studio is based on Threat Modeling vNext. But what really is this Threat Modeling vNext? This article tries to answer this question, with the help of some articles published on the Simone On Security blog.

Threat Modeling vNext is an evolution of some of the current approaches. In particular, it represents an evolution of Microsoft’s STRIDE approach. Being designed by Microsoft employees, it is only natural to use that experience as a starting point. Threat Modeling vNext does not represent a revolution, though: many of the original characteristics have been maintained, and others have been changed.

In designing Threat Modeling vNext, we have tried to address some of the problems we faced during our Threat Modeling activities, including:

• The Threat Modeling process has gradually degenerated, moving from an experience where the goal was to identify risks and mitigations without much help from the tool, to a situation where automation has been extremized. Neither those two approaches have given very good results: the first favors the experts, by improving their efficiency and effectiveness, but essentially makes impossible for non-experts to produce anything useful. The second approach tries to simplify the experience for non-experts but sometimes does it at the expense of the experts. The result is that both categories tend to produce mediocre results.
• Sometimes automation is achieved by using complex knowledgebases defining entities, threats, mitigations, and how they must be applied. The problem of this approach is that maintaining those knowledgebases may be very complex, because they need to cover all the possible technologies and scenarios. Moreover, if you select a knowledgebase, you may not be able to switch to another at a later stage. As a result, you may not be able to cover all the topics you need to cover with your specific project.
• Threat Modeling tend to be too expensive as a practice. This is clearly perceived as a problem by the wide public.
• The results obtained with Threat Modeling sometimes are not clearly differentiated from what could be achieved faster, for example with checklists or best practices.
• Threat Modeling tools tend to be closed systems. For example, it is very hard to integrate them with other solutions, including LoB systems.
• Threat Modeling covers part of a Risk Management process: the Risk Analysis. It can do much more: Threat Modeling could be at the center of the Risk Management process.
• And finally, Threat Modeling is mostly an experience for Threat Modelers. Instead, it is a process to understand and manage Security Risks. As such, it interests many roles, including Technical ones like Developers and Architects, and non-Technical roles, like Project Managers and Product Owners. They have different needs and competencies, therefore it stands to reason that they should have access to the Threat Model in specialized ways. Still, many tools do provide only a single view, to cover a specific role.

Those ideas are summarized in the blog with the article Threat Modeling vNext Story, and then with a series of six articles, showing how different roles may need different experiences:

• Threat Modeling vNext for Judith, Lucy, Elliot, George and… You!
• Threat Modeling vNext the Lucy way
• Project Managers and Threat Modeling vNext
• Threat Modeling vNext for the Business Decision-Maker
• Different needs

The final article the series, A single, authoritative and flexible tool for Threat Modeling, discusses the need to get a single tool to address most of those very specific needs, versus having specialized tools.

This is the story and the reason why we have designed Threat Modeling vNext. But what really is it?

First of all, Threat Modeling vNext is a philosophy. It is the idea that Threat Modeling should not be a static process, but something very dynamic and flexible, capable of addressing multiple needs, to integrate with existing processes and to drive a sound Risk Management process. The process should give great liberty, defining only a few rules of the game. You can look at those rules as the letters that compose the alphabet, and therefore the alphabet would represent the concepts on which everything is built. Everyone can use those rules to create elements that would then be composed to create the final experience.

In practical terms, as part of this alphabet we have concepts like the Entities, the Flows and the Trust Boundaries, the Threat Types and the Mitigations. Those concepts are extremely lightweight: for example, you will not find a field to represent a STRIDE category for the Threats, because we do not want to require you to follow a specific categorization. If you really want to, you have the possibility to extend the metadata for objects using the concept of Properties and Property Schemas. You can also derive new concepts from the basic ones, creating for instance what we call Item Templates. Then, you can package it all in what we call Templates, which are nothing less than knowledgebases. Bottom-up composition is the mantra, in Threat Modeling vNext: this means that you can create your own experience by composing simple elements to create the experience you need. This is implemented by Threats Manager Studio (TMS) with the possibility to load Templates at any time: in fact, you may create your Threat Model out of a composition of zero, one or many Templates, as you like. With this approach, knowledgebases become suddenly manageable, because you may have many of them, each one very simple and managed by a part of the Community.

Threat Modeling vNext means also that we want to allow easy integration of Threat Modeling with other processes. Here, the key role is played by Threats Manager Platform, the Open Source Engine and SDK used to build TMS. With this new approach, the Threat Modeling tool would not be something closed, but a container of components, which are called Extensions. This allows to create a module to integrate the tool into Azure DevOps, for example, then everyone can install that module and synchronize its Mitigations as Backlog Items. Or a Company like Amazon could build an Extension to get the definition of some Cloud solution from AWS, to create semi-automatically a Threat Model. It even allows to re-host the Engine, for example in an internal site of your Organization: this would allow your Development Teams to upload their Threat Models and your site would be able to provide a fast evaluation of its quality of eventually submit to some expert for a review.

Your imagination is the limit.

As said above, one important characteristic we want to have out of a Threat Modeling vNext tool, is to allow users with different needs to get specialized views from the single truth, which is represented by the Threat Model itself. For example, Business Decision Makers may use tools like the Overview Dashboard, to get a look at what is the current risk, what they can do and what the effect would be.

Another important issue we are trying to address with Threat Modeling vNext and Threats Manager Studio, is that it is too hard to get quality Threat Models fast. With TMS we have already achieved some remarkable results on that account, including the creation of a Threat Model for a production system in 12 hours, producing a complete report including a Roadmap of mitigations. With the previous process it would not have been possible to achieve the same quality, and even the best among us would have needed at least 40 hours.

Is it perfect? No, it isn’t. But it is a starting point.