I'd like to share a tool that I have been working on that helps security and engineering teams to threat model. I'd also like to share the threat modelling process it was designed to help with. Both are meant as contributions to help make threat modelling easier (at least for some people).
I'm not going to go over the process in detail, I've captured that in this overview in the documentation. I will give some context about the origin of the process and the tooling though.
I have been doing some form of threat modelling for many years. Originally the process was using my experience as a penetration tester to ask questions and focus on areas where vulnerabilities usually live. The output was only ever a list of potential vulnerabilities that were discovered. As I did more architecture and design work and found myself needing to create generic frameworks to mitigate threats and vulnerabilities, I found myself more and more modelling systems as a means for designing solutions. That modelling then changed my approach to threat modelling as I sought for a more systematic approach, that could be consistent and lend itself to giving some assurance.
Of course there were existing threat modelling tools to try to leverage to provide a more systematic approach. I was not impressed. The tooling I discovered needed me to invest a lot of time and effort and often the result was a plethora of threats that I knew were mostly noise and offered little value. Many of the tools required complete indoctrination into the tools methodology, and if your use case wasn't in the sweet spot for the tool, you were out of luck. These problems are by no means unique to threat modelling tools, or security tools, or really any tools.
So I started exploring developing my own approach. I started to define a template of information that needed to be gathered in order to determine the threats against a system. That template went through many iterations. Initially it wanted so much information that it was difficult to populate, but the goal was not to miss any threats! Through repeated use it became clear the balance between the burden of data collection and finding all the threats needed to be refined. That became the process then, refine the template and evaluate the findings, determining what could be stripped out that offered little value. Eventually the template began to require fewer changes, and I got more confidence that it found an acceptable amount of threats for the effort required.
I would say it was a success! But with success comes different problems. The teams I worked with could acknowledge that the template was doing a good job, but it was still not accessible to them to populate without a lot of hand holding. As more teams wanted to benefit from using the template, the problem of scale emerged, as I was having difficulty keeping up with the demand - and that is not even mentioning the repetition of providing the same guidance to each team. The next step was to produce detailed documentation so teams didn't need to come to me as the first step to populating the template. This helped, but I was still reviewing the output, and the feedback loop for mistakes was too long.
Could tooling help to solve this? The problem was the template was just a document, I wasn't capturing information in an app where it would be simpler to detect incorrect input. I should write my own app! Wow did I discover that was going to take a long time and a lot of work and likely just result in an inflexible approach that frustrated me about other tooling I had used. I didn't want teams to have learn a new app, and I knew the business didn't (and shouldn't) want to commit to a process tied to an app. I wanted teams to have the flexibility and familiarity that a document provides. Actually one of the key features that many document solutions provide is the ability to provide inline comments, and this had proved invaluable in reviewing and communicating with teams asynchronously. Replicating that in an app seemed to be well beyond what a part-time tool development effort could achieve.
But I could do some basic tooling still. Some automation that highlighted the really common errors teams were making that were the real time intensive parts of reviewing threat models. So scripts were written. The format of the document was assumed, information was extracted and verification was applied. With something working I then moved it to an AWS Lambda function so teams could benefit from just a simple request in the browser. Now whenever someone created a new threat model and asked me to review it, the first thing I told them was to run the tool and fix the errors. This was a huge help to me. What surprised me was how positive the reaction was from teams, they loved that they could use a tool to help validate their threat model!
There was a real 'golden age' for a period of time as I refined the tool to deliver more value to both me and the teams, and it enabled even more threat models to be created and threat models to be updated as well. Unfortunately with success, scaling becomes a problem that won't go away, and it was clear more changes were needed to support demand, but the tooling I had was creaking at the seams.
Regardless of being a victim of its own success, and forgive me for thinking so, but what I had created seemed like an approach to threat modelling that others in the industry might find useful, and the seeds were planted for how I could share this with the world. In its current state it was not shareable, it needed to be re-written from scratch (and independently of the company I was working for). There was also the danger of hubris over the template I had created, as it would not suit everyone's situation.
So I made the decision to build something that could support a flexible format for the template but still be able to provide validation. I would provide an example template that others can use if they so choose, but if someone wanted to do something completely different they can do that also. I also made the decision that the tooling needed to support the management of threat models, as I had first hand experience of a successful threat modelling process, and managing all those threat models required processes as well.
And that is how threatware was born. The documentation hopefully gives all the detail you need, and while I use it daily, I would still only consider it in beta, as there are still occasional issues that need to be resolved.
If you need to do threat modelling, you might find it useful. I threat model and it helps me a lot.
