“[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.
On the head - not only is TM a security culture accelerator with the application teams but also a catalysator for the security divisions (e.g. SOC, Incident Response, Risk Management, ...) to work efficiently together and thereby also create greater exceptance!! 💪
@Michael Bernhardt for that addition.
I’ve had the privilege to teach TM to everyone interested (when I was at Intel, Inc. - more than 1000 participants in about 1.5 years) and then observe the results.
While there may be other security accelerators of which I’m unaware, I can say from much experience that once people get a chance to play with attacks and defences in a safe environment, i.e., a learning situation, the vast majority of people “get security” deeply, strongly, become advocates who understand the “why” behind policies, processes, controls.
Learning and playing with TM brings the need for security “home”, integrates it into a person’s practices, organically. Naturally!
It’s a shame that most organizations are missing this easy path to a security culture because they reserve TM for techies, or worse, technical leaders, or the very worst, just security technical leaders.
Of course, this presumes that learning opportunities are designed in such a way that they can support both absolute beginners with little technical knowledge through experts. Therein lies the teacher’s challenge.