Security vulnerabilities result from interactions between thousands of well-intentioned decisions. What systems or libraries do we use? Should I click yes or no on this authorization prompt? Should we make this system more simple or more safe? Only in the aftermath of security incidents do the regrettable decisions become clear.
Security experts are predictors. They are trained to understand how the conditions caused by technical decisions create risk, and can steer the ship toward calmer waters. Bad decisions made without security expertise tend to propagate and amplify before they can be identified and corrected. As a former team member put it:
A river of code and we’re standing here with buckets trying to keep things dry
How can security experts influence critical technical decisions as they are being made, rather than deal with the consequences? If an ounce of prevention is worth a pound of cure, then an hour spent threat modeling is worth a week of sprint work. It creates a channel for risk communication between security experts and decision makers that can prevent the cost of correcting bad decisions later down the line.
There are many different ways to threat model — a Carnegie Mellon blog discusses 12 Available Methods. Each organization has unique threat modeling practices and evolve their approach over time.
Threat modeling is a creative process, which makes it resource intensive. Security experts aren’t cheap, and threat modeling slows decision making. If you spend time on a process that’s not optimally-focused on reducing risk, you run into scaling limits — no more security experts, too much burden on decision making, or both.
The following ideas have helped me scale threat modeling processes at growing software organizations.
Document the process
This may seem obvious, but invest in well-reviewed “how threat modeling works” documentation. It helps you remember to follow all the steps. It helps other teams know what you mean when you say “threat modeling”. It’s repeatable when performed by different people on your team and can be improved over time.
An example high-level process:
- Create a “Threat model” Jira ticket in the SEC…