Let’s be straight here. I'm sure a lot of you have the sneaking suspicion that this article and threat modelling in general are as interesting as watching paint dry. It’s not as fun as a story about how a company got hacked or how developers ignored security until just before deployment and had to undo months of work after we tested them for security. I mean, we have those, too. But bear with me.
The reason you should be threat modelling is pretty simple. You want to know how your application can get hacked. You want a complete analysis, take actionable data and intelligence from it and mitigate or resolve the issues as best you can.
Read more: Threat Modelling like Sherlock Holmes
I strongly believe that threat modelling is not only a ‘good-to-have’ activity, but an essential one for a fast-moving product team. That's simply because it allows you to be faster, with more focus and the right prioritisation. Let me demonstrate quickly:- Want to be able to identify and prioritise DAST and SAST test scenarios? Map out threat scenarios by threat category and attacks. It can help you easily identify the most relevant types of tests needed to be run in DAST and SAST.- Want to identify the most relevant mitigation practices for an app based on risks? Threat scenarios derived from threat models will help identify the most relevant security practices.- Want to run simulations for security in your environment? Scenarios from Threat models will help you run simulations/table-top exercises.These are just some of the benefits of an effective threat model, not to mention many others in the realm of Secure SDLC, Incident Management and so on.
Check it out: Presenting "Threat Modelling wins fo Agile AppSec" at (ISC)² San Diego, September 2020
But threat modelling can elevate your security practices beyond even that. Here are 3 key success factors in making threat modelling work for your Security in a DevOps implementation:
Many folks see threat modelling as an ERA style document, akin to a procedure or a guideline. But that’s not really right. A threat model is more like a tactical “playbook” that needs to give actionable intelligence to the various groups consuming it.
Large documents with complex diagrams is not the way to go, especially in a rapid, continuous delivery type of environment. It’s much better to create a baseline threat modelling document which is simplified into a mindmap, customised for different groups of consumers.For instance, I would create an “Attack Model” for security testers, identifying the different kinds of threat scenarios drilling down into the types of attacks that could potentially lead to these risks being “brought to life”.For Devs, Architects and DevOps folks, I would look at “mitigation models” that would evolve from the “attack model” to provide specific security measures to resolve or mitigate these issues. These folks could identify missing security pieces and fit it into their release process.
Read more: Using and Scaling Threat Modelling
I love working with mindmaps and similar intuitive tools as they allow a drill-down path for each branch and provide a simplified representation of items, as opposed to a massive document which looks overwhelming. Tools for threat modelling do exist, but I find that some of them are more work and far too generic to make much sense for a rapid-release, DevOps environment.
The reason we use Agile and DevOps is due to iterative requirements. Applications undergo constant change and one of the principal complaints that product teams have is that security is usually lagging behind. I believe that a lot of that security lag can be filled in with iterative threat modelling.
For instance, threat modelling should begin at the sprint planning meeting and diverge into security requirements/ attack test cases that can be used across the sprint. Again, to achieve this we need the threat modelling process to be simple, visual and easy-to-use.
Download: ThreatPlaybook, an open-source framework for threat modelling as code
Lack of iterative threat models result in lack of iterative security requirements, lack of updated attack test cases, which results in a huge amount of “catch-up” to be done by the security team. This inevitably causes delays in product releases, or worse, a vulnerable product being released to production.
The risk assessment school of thought in enterprise security has made an ‘asset-driven’ approach a de-facto model of risk assessment. While this might work for risk assessments at an enterprise level, for threat modelling, a ‘system-driven’ approach is probably better.
In a system driven approach, it’s easier to manage data-flows, explore critical assets and look at security threats from the perspective of the entire system rather than an asset-outward approach that tends to be myopic and difficult to understand. In an Agile and DevOps environment, there’s a definite need for speed. There’s a need to keep pace with constantly evolving requirements and specifications.
Threat modelling is often perceived as a peripheral activity in application security. However, effective threat modelling is the basis for more comprehensive and efficient Security in DevOps practice.Learn how we45's Threat Modelling practice can help you uncover your application's most critical flaws.
