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.
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, 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 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 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.
The primary goal of a threat model is allowing 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 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 modelling
- 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 modelling artefacts as well as supporting evidence.
When you evaluate tools to persist threat models, the 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 the operational security and the other requirements for threat modeling. A vision on 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 the operational security might lead you to have several places / tools where (partial) information can be shared with your different shareholders.
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, limit the costs (both in potential licensing and learning curve).
While looking at the Dev(Sec)Ops 18 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 modeling. Most diagramming tools can handle this well.
- A wiki like tool where developers put information on the sprints, stories etc. 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 artefacts. 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.
Treat 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.
| << Previous page | Main page | Glossary of terms >> |
|---|