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.
Developed formally or through collaboration
Easily integrates with Agile, DevOps, or Waterfall
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
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
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.
Data flow diagrams
| || |
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.
| || |
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 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.
About Security Compass
Security Compass, a leading provider of cybersecurity solutions, enables organizations to shift left and build secure applications by design, integrated directly with existing DevSecOps tools and workflows. Its flagship product, SD Elements, allows organizations to balance the need to accelerate software time-to-market while managing risk by automating significant portions of proactive manual processes for security and compliance. SD Elements is the world’s first Balanced Development Automation platform. Security Compass is the trusted solution provider to leading financial and technology organizations, the U.S. Department of Defense, government agencies, and renowned global brands across multiple industries. The company is headquartered in Toronto, with offices in the U.S. and India. For more information, please visit https://www.securitycompass.com/