Is threat modeling a roadblock to application development?
Is threat modeling a roadblock for security in your organization when it should be an enabler? If it is, you’re not the only one. Traditional threat modeling is no longer meeting the needs of the modern development team that relies on speed and automation. How do organizations keep pace with the industry while growing their numbers?
To explore this, we’ve worked with standards communities, regulatory bodies, academic research, and some of the biggest companies in the world to develop an alternative perspective of how threat modeling can help drive security forward without creating a barricade. So is threat modeling a blocker? Yes.
But it doesn’t have to be.
Traditional threat modeling processes have blockers
We need to begin by looking at traditional threat modeling and pinpointing where slowdown occurs. No single model can account for every business case, so we see a large variety of them. At the same time, they each aim to accomplish a specific goal by either addressing a development phase, working with various levels of security expertise or producing unique outputs. This kind of granularity works well when you need an assortment of tools to address a variety of factors — but when a company increases in size or doubles the projects that require threat modeling, it’s no longer a realistic strategy. At the end of the day, traditional threat modeling is slow.
Approach |
Characteristic |
|||||||
Structure |
Developed formally or through collaboration |
|||||||
Agile integration |
Easily integrates with Agile, DevOps, or Waterfall |
|||||||
Age |
Well-established or relatively new |
|||||||
Separation of concerns |
Focus on software independent of either computation or platform |
|||||||
Traceability and testing |
May focus more on testing and requirements |
|||||||
Security expertise |
Some require extensive security knowledge |
|||||||
Output and reporting |
Technical and nontechnical artifacts reach different audiences |
|||||||
Depth of security taxonomy |
Extensive detail about required controls, or a high level assessment |
|||||||
Security posture |
Offensive or defensive about security |
Table 1: Threat modeling approaches and their defining characteristics.
Traditional threat modeling and why slowdown happens
Each threat modeling approach has its strengths and weaknesses. Imagine how these approaches transfer to tens, hundreds, or thousands of projects. Through our conversations with large companies using threat modeling, we discovered that they preferred using data flow diagrams, checklists, and misuse cases for threat modeling. See the following table for a breakdown of their challenges and a summary of the resulting slowdown.
Popular approach |
Challenge |
Slowdown |
Data flow diagrams (Phase: Design) |
|
Data flow and block diagrams may become inconsistent with each other over time, and diagrams can become exponentially complex with each additional API node causing a network effect. |
Checklists (Phase: Requirements) |
|
Not all parts of an application can be addressed by one list, and it’s difficult to know if an application conforms to a list. Keeping lists updated is time-consuming and requires expertise. |
Misuse cases (Phase: Testing) |
|
Misuse cases can become unreliable due to bias or exaggeration. |
Table 2: Popular approaches to threat modeling create challenges in growing organizations that slow down development.
Revamp your threat modeling approach
Organizations today are still using threat modeling, but they need a better way to do it as they grow. Where do they start?
Firstly, you need to seamlessly integrate threat modeling artifacts across the lifecycle. This means that threat modeling artifacts are well understood at each phase, and they don’t distract from the overall process flow or the work of other teams.
Secondly, the threat model should be simple to generate. It should be scalable across fast-paced development environments with thousands of applications without requiring the consistent use of a limited pool of resources.
Finally, it needs to be easily understood across the software lifecycle. Anyone should be able to look at a threat modeling artifact in any phase of the development life cycle and understand what it means.
To avoid a slowdown in the development process, threat modeling should:
- Reduce the network effect
- Produce consistent output
- Include exception policies
- Ensure the latest security coverage
- Ensure that output reflects the entire system
- Assess importance realistically
- Reduce the discrepancy of threat modeling artifacts across the software lifecycle
How can we do this?
A new approach to threat modeling
We’ve outlined how traditional threat modeling processes can slow down large and growing businesses. We need a way to update threat modeling to address contemporary challenges that require the flexibility and speed we see in DevSecOps. This is the lightweight approach we’re looking for.
To scale threat modeling across people, systems, and data, we need a way to deliver common artifacts across the software lifecycle without becoming excessive and monolithic. Instead, we want a lightweight representation of these elements that we can easily reformat as needed. This common artifact should be able to produce:
- Data sharing with lists
- Application taxonomies
- Traceable risk
If these sound familiar to you, it’s because we have already started doing this. To learn more about this new approach to threat modeling, read the second part of this blog.