Written by Laurent Dupont

Threat Modeling Playbook - Part 5 Innovate with threat model technology

Unveiling a successful threat modeling strategy hinges on garnering support from stakeholders and strategic resource distribution. In this series of blogs, we unravel the complexities of involving key participants, addressing their concerns, and showcasing potential benefits through our Threat Modeling Playbook. We explore various approaches to acquiring threat modeling proficiency, ranging from a self-initiated start to engaging experts or implementing comprehensive training programs. Importantly, we stress the significance of showcasing a return on investment by aligning recommendations with tangible security enhancements.

At its core, threat modeling is a process that brings the right people together to think about (and hopefully improve) the security of an application or IT system. Technology should always be judged in its ability to support that process, and never as a goal in itself.

In this section, we will talk about a number of guidelines that provide guidance on selecting the right technology and integrating it in your way of working so that the technology maximally supports the threat modeling process, and not the other way around.

Select the right tools

Every threat modeler will make use of some technology. This can be very simple such as a piece of paper or more advanced such as specialist threat model tools. When deciding on a tool there is one core rule that should always be followed: a tool should support your process, and never change your process to accommodate a tool. As a result of this rule, you should first gather the requirements for your tool(s).

Start with the tools already used within your organization for other purposes. Perhaps they can either partially or completely fulfill the requirements already.

For example, the architects might already use a diagramming tool to create their diagrams. Each of the questions of the threat model process might have one or more tools being used. Typically, the models will be created in a drawing program such as MS Visio or Diagram.net (formerly Draw.io). The threat model itself is documented in a word processor whereas a spreadsheet is often used to calculate the risk scoring.

Identifying the toolset currently in use will make it easier to incorporate the threat model practice in the existing toolset. This will create less friction and should help the adoption of threat model practices in your organization. Every organization is different, and each one implements the threat model practice and processes in a different way to fit the needs of that organization. This means there is no definitive list of tools that are ‘fixed’ for a certain level of maturity of the threat model process.

Since the tools are supposed to fulfill the requirements, it is important that you document the use of tools when you use them during the threat model process.

The tooling should be tailored to your organization. It should fit the size of the number of threat models needed. It should support the complexity of those threat models as well as the maturity of your threat model process. Of course, the tools should fit within the budget you have available.

As an example, we will discuss one of the cheapest and readily available tools, the flipchart. There are several good reasons to use flipcharts, whiteboards, or magic paper in an organization that is new to threat modeling. Creating models is the cooperative work of different stakeholders. Standing around a whiteboard will enable all your stakeholders to take a marker and make changes to the model(s). It will force the active participation of your stakeholders and will facilitate a consensus on the system scope. The same reasoning is valid for the other times during a threat model that the stakeholders work together. A threat model is a consensus between these stakeholders and as such there is a need for conversation to discuss the doomsday scenarios, scope, models, threats, mitigations, risks, etc. Flipcharts are a cheap tool that can be used to create initial threat models in any organization at the start of its threat model journey. It will stay a very relevant tool as your organization grows in maturity, but there will probably be a need for a tool that starts from a digital version of the model for updating the threat model. A flipchart is not the most ideal tool for that so it will be replaced in organizations that have created an initial threat model and are adding significant functionality that requires an update of the existing model.

Creating a threat model using remote participation is certainly possible but this requires specific tools and some experience within the team to pull off in an efficient way.

Processing the outcome of tools

The primary goal of a threat model is to allow the decision-makers to use an objective, risk-based approach to mitigate threats against a system.

However, there are many other reasons to do threat modeling. These reasons could be:

To create awareness with your stakeholders
To document due diligence
To serve as documentation on the system
To feed input into other practices, such as security reviews and penetration testing
Feedback lessons learned into other systems and threat models
To share threat modeling knowledge
…

To cover all these requirements your threat model needs to be accessible by different groups of people, some of them needing only access to certain parts of the threat model.

Once the first threat model creation has started you will need to persist in the results of these sessions. Any tool(s) you select should therefore fulfill two requirements:

Allow/facilitate the conversations between your stakeholders that happen during threat modeling
Persist the threat model in such a way that it can be easily updated and is available to all stakeholders. The threat model contains the modeling artifacts as well as supporting

When you evaluate tools to persist threat models, operational security must also be guaranteed. A threat model will contain sensitive information in the form of unsolved security problems and the access should be limited as much as possible. This creates a field of friction between operational security and the other requirements for threat modeling. A vision of how to handle both sets of requirements should be decided on and serve as a guideline during tool selection.

Combining the two requirements from above with operational security might lead you to have several places/tools where (partial) information can be shared with your different shareholders.

Integration in your threat modeling methodology

Let`s first remind ourselves of the rule we stipulated in Chapter 4.1: a tool should support your process, never change your process to accommodate a tool. As a result of this rule, you should first gather the requirements for your tool(s).

There can be several tools already in use in your organization. Where possible you should reuse these tools since this will limit the friction to implement the process, and limit the costs (both in potential licensing and learning curve).

While looking at the Dev(Sec)Ops process and reviewing typical tools being used here, we can distinguish several possible things to harmonize:

Several architecture diagrams might already exist, they can potentially be re-used. These diagrams tend to need extensions for threat Most diagramming tools can handle this well.
A wiki-like tool where developers put information on the sprints, stories might already exist. This might be the most current version of the documentation of the system, a threat model could be considered part of that documentation.
To follow up the actions coming from a threat model (i.e. implementing approved mitigations) you should use the same ticket tracking tool used for other development activities.
The risk calculation methodology used to score security problems (for example from a penetration test) should be re-used during threat modeling so that different risks can easily be compared to each other.

Make sure that the threat model tools fits within your Dev(Sec)Ops pipeline, either by re-using tools or by acquiring tools that support that process. The output of the threat model process can be viewed as development artifacts. The best example of this is to treat threat models as code. Threat modeling as code follows the trend to have everything ‘as code’. The different elements of a threat model are described, often in a text format that is both human and machine readable. From this, some of the frameworks can generate documentation, automate tests, automate the risk calculation etc. This style of threat modeling lends itself very well to continuous development practices. The threat model process will also be a continuous process with a heavy focus on tool support and integration in the development team.

Threat modeling as code is not a mature field of expertise at the time of writing this document (2020). Additionally, not that many organizations are ready to do infrastructure as code, threat modeling as code etc. therefore we consider this to be an optional step in the playbook reserved for organizations with the highest level of maturity in both threat modeling practices as agile processes and tools.