Original post by @BrookShoenfield
@izar wrote something that I think is critically important for those who are wondering how to “sell” threat modelling to decision makers and developers. It bears repeating, underline, echo, big ditto from me:
“[T]hreat models are a great hanger to hang most if not all other activities of the SSDLC on. If you have a threat model you can rely on it to provide a framework for security testing that you wouldn’t have beforehand, and you might end up either looking in the wrong places or putting too much energy and time into probing things that do not guarantee your security. Likewise, if you know you have a high level of exposure to injection issues, you can orient your pentesters in that direction and get a better return on the investment that is a pen test. You need to onboard new people? Point them in the direction of the threat model and not only they’ll get a detailed view of the system they will be working on, they will also learn of those areas that are more brittle or need more care for one reason or another. Need to make sure you are interfacing right with another team or another system ? Compare threat models! See if you have the same attackers in mind, if you are executing security contracts and if the responsibility is being shared correctly.
At the end of the day I think I have had the best results in convincing people to threat model when I manage to get them to see that the benefits carry beyond the time spent doing the actual threat model, and benefits compound as the result is shared and used correctly.”
Benefits are not confined to secure design, though it’s hard to secure a design without (somewhere in the chain of analyses) a threat model. to bullet a few of Izar’s points:
- Focused testing
- System understanding
- Foundational security reasoning
- Security assumptions and “contracts” between components
And another I’ll add: if threat modelling includes everyone involved, the practice of considering attacks and figuring out their best defences builds a culture of security that puts all security activities into perspective, makes their importance obvious. Threat modelling, it turns out, is The security culture accelerator.
BTW, “somewhere in the chain of analyses” means that even where designs are expected to conform to the organization’s standards and requirements such that formal threat modelling isn’t necessary, the standards and requirements will be based upon a threat model. Threat modelling is our underlying, foundational technique for arriving at the security that will need to be implemented, ergo, security requirements or a security architecture.
/brook