How to scale your threat modeling capability
So, you have one or two, maybe tens, or maybe even hundreds of applications already built and deployed. You want to create threat models for those applications. But, why? Come on, you know why—to identify potential flaws that have been there since the applications were created. And of course you also want to create threat models for new applications that are being built as we speak.
No matter how large or small your software security group (SSG) is, they likely have a full workload. Or, maybe your organization doesn’t have a SSG at all. Instead, you have a small number of developers with deep software security knowledge. In either case, you may not have the staff necessary to work on the threat models you would like to create. Should you abandon your goal of threat modeling the existing and/or new applications? Not so fast…there may still be a way.
Scaling your threat modeling capability
There are two common options to address scalability:
- Scale horizontally. This involves increasing the number of units doing the work (e.g., adding more computers).
- Scale vertically. This involves increasing the capacity of whatever is doing the work (e.g., more/faster CPUs, more/faster memory, bigger/faster disks).
How does this translate into scaling your threat modeling effort? Well, for horizontal scaling you need to increase the number of units doing the work. As such, you’ll want to either expand your SSG or bring in resources who will be able to conduct threat modeling. For vertical scaling, you’ll need to increase the capacity of whatever is getting the work done. Maybe you ask the SSG team to work more hours or increase the brain function of those conducting the analysis so they can work more! These aren’t realistic options…at least not to me.
A good option would be to bring in more people to carry out the threat modeling.
Creating your threat models
When building a threat model here at Synopsys, we kick things off with a component diagram. This represents major functional components, communication paths between those components, and some representation of trust boundaries.
Once the diagram has been annotated, you can start your analysis. As we look at this progression, how much of this work needs to be done by the SSG?
If you were part of a SSG and tasked with creating this diagram, how would you do it? If you knew nothing about the application, you would talk to the application team and have them describe how the application was built. Based on that information you could create the component diagram.
Light Bulb! Wait a minute, wouldn’t it be more efficient if the application team presented the component diagram to the SSG when they were describing the system to them? The application team knows what components exist and how those components communicate with each other. If that’s possible, you now have more people working on the threat model and it’s one less thing for the SSG to do. Thus, their capacity has increased and you just scaled the threat modeling capability of your SSG.
Sharing the workload
Those paying attention noticed that you increased the capacity of the SSG by having the application team do some additional work. It’s true—there is no free lunch here. However, creating a component diagram requires little software security expertise. It also requires a very good understanding of how the application was built or is planned to be built. This is the knowledge domain of the application team. The application team will still need to describe the system to the SSG so that the rest of the threat model can be created (annotate component diagram with assets, threat agents, etc.). And now the SSG will have a bit more time to do their work since they won’t have to create the component diagram.
The bottom line
Not all elements of threat modeling require deep software security knowledge. By sharing the workload to create the threat model, varying degrees of scale can be achieved and more threat models can be created and analyzed. Good luck finding those flaws!!
Six steps to effective threat modeling
