Why invest in a threat modeling tool?

There are many threat modeling tools available, but they are really just substitutes for threat modeling best practice, which is for a threat modeling expert to meet with engineers who are experts on the system being modeled in a conference room with a white board.

This sentiment certainly has merit. There is nothing quite like stakeholders meeting together face-to-face to mull over a threat model. However, there is a problem with this approach.

Software development is increasingly about moving fast with a culture of continuous integration and deployment. This, coupled with development teams working on dozens – or even hundreds – of services simultaneously makes the “whiteboard” method of threat modeling increasingly untenable.

Decongesting the Security Bottleneck
Security has traditionally been seen as something of a bottleneck at the end of the development lifecycle and this only becomes more acute as we move towards the Agile “always shipping” culture. The antidote is to hook security seamlessly into this new culture and empower developers to be self-sufficient by facilitating processes that put security knowledge directly into the hands of development teams.

Given this I’d say that the manual whiteboard threat modeling process is often not practical and is certainly not scalable. We need to leverage other methods and this is where threat modeling tools are the perfect choice.

Many of the applications and service components we build and their underpinning architectures are the same or very similar, meaning the security risks and mitigations associated with them repeat over and again, allowing us to create risk patterns and templates. You may be thinking a one-size-fits-all is a clumsy approach for generating a threat model as many threats generated by an automated tool may not be relevant, but that depends on the sophistication of the threat modeling tool.

The IriusRisk threat modeling tool for example, answers this problem with very small risk patterns that relate explicitly to specific service components and their use-cases and risk patterns are generated as building blocks assembled for the model based on an intelligent rules-based questionnaire relating to the architecture.

Utilising this approach has a twofold benefit.

Firstly, it ensures only relevant security risks are identified.

Secondly, this questionnaire “self-service” strategy allows for those answering the architectural questionnaire to have no prior knowledge of security and yet still arrive at a useful and actionable threat model.

How do we hook this threat model into the modern development toolset?
Communicating threat models utilising the whiteboard method has always been somewhat fraught. Do we manage the model through Excel or a shared Google document? Aside from not scaling well the model and identified threats and risks become difficult to track and keep up-to-date with continuous changes, especially in an Agile environment.

The key again is a threat modeling tool that can talk the developer's language and sync with their toolchain such as issue trackers, allowing for tracking of tickets to manage the status of identified risks as they progress through the development process.

The Crux
I view threat modeling tools as complementary to manual “whiteboard” approaches. As with all things there is no silver bullet and tools do not eradicate the need for highly skilled threat modelers. But as most of what we build are boilerplate applications, services and architectures, we can automate most threat modeling processes allowing experts to focus their attention on those more interesting, bespoke and complex systems that will truly benefit from their input.

High-quality threat modeling tools have a solid ROI and allow us to scale and track changes in our increasingly dynamic environments. We should be looking to automate boring repetitive security processes as much as possible in order to increase speed and reduce time, costs and friction.

‍