How Does Threat Modeling Fit Into the Fast World of DevSecOps?

DevSecOps is all about making quality software happen faster. But the threat modeling process has a reputation for time-consuming complexity that many organizations believe slows down the software development life cycle (SDLC). How can we meld the two to get the security benefits from threat modeling without putting gates in front of the software development process?

This blog post reviews threat modeling and how it fits naturally into the DevSecOps process.

What Is Threat Modeling?

Threat modeling examines the design of system operations and how data flows across subsystem boundaries. It then identifies all points of attack that hackers could exploit and how they could do so. Last, it designs solutions to keep the system and its data safe.

According to leading expert Adam Shostack, the threat modeling process asks the following questions:

• What are we building? Assess where data flows in a system, the boundaries that it crosses and the technology used for every hand-off.

• What can go wrong? Question every possible means of exploiting the hand-offs.

• What are we going to do about that? Design defenses against each exploit.

• Did we do a good job? The final and most important question invites us to reflect back on the process, review it, and remind us that the work is never really done: There is always room for improvement.

The team then prioritizes the threat risks and works them into development.

When Should You Perform Threat Modeling?

The ideal time to perform threat modeling is in the earliest stages of the SDLC, during the architecture phase of application development. The earlier you can identify the threats, the more efficiently you can devise solutions to thwart the attack vectors.

It’s better to bake security into the application from the start, but it’s never too late to reap the benefits of threat modeling, even for legacy applications. Such an exercise can be valuable for everyone involved, no matter when it happens in the SDLC.

The History of Threat Modeling

The earliest attempts at threat modeling started in the 1990s with the idea of attack trees. This led to Microsoft’s Loren Kohnfelder and Prerit Garg circulating a document called “The Threats to Our Products” that is widely considered to be the first formal description of a threat modeling process.

Since then, the industry has rallied around organizations like Open Web Application Security Project (OWASP) that rate the top threats, what they are, and what should be done about them. OWASP has also released a similar threat assessment for digital API security to address software-as-a-service (SaaS) APIs.

And today, with the likes of Yahoo, Uber, and First American Financial having millions of user records stolen by hackers, every organization must be aware of digital threats. The 2020 security reports paint an alarming picture:

• Well over 18,000 vulnerabilities were recorded in 2020, with close to a quarter of those being of high severity.

• Companies paid an average of $3.86 million to fix a data breach.

• Malware and ransomware attacks increased 358% and 435%, respectively.

Threat Modeling Tips

The threat modeling process can get quite complex. One approach, the venerable STRIDE methodology, recommends a separate technical analysis for each major type of attack:

• Spoofing: Violate authentication by some sort of impersonation.

• Tampering: Violate the system in a way that allows further exploits.

• Repudiation: Violate detection by hiding evidence of attacks or falsify logs to look normal during attacks to mask intent and allow the attack to continue.

• Information Disclosure: Violate confidentiality by finding ways to extract sensitive data from anywhere in the system.

• Denial of Service (DoS): Violate user access to systems by deliberately exhausting resources required for proper system execution.

• Elevation of Privilege: Violate authorization by tricking the system into granting more privileges to an account that allow deeper access into the system.

Data flow diagrams (DFDs), STRIDE, and newer methodologies like it, provides a framework to answer such questions as:

• “What are we building?” DFDs are one approach to lay out the system and its various trust boundaries as a first step toward understanding security threats.

• “What can go wrong?” STRIDE focuses on this question, to examine each attack type given how the system is built.

For example, a denial-of-service attack on the Kubernetes API Server in 2019 exploited a loophole that allowed huge amounts of data to be passed into the API “payload,” bogging the system down.

Ways to mitigate the threat included:

• Payload size limits for any call

• API call limits for a specific user or IP address

This repelled future DoS attacks for the API Server.

Such efforts require deep dives into system functionality, and must be done for each type of attack. Solutions are possible but take time to research, design, build, test and deploy.

Why Traditional Threat Modeling Challenges DevSecOps

Traditional threat modeling requires analysis meetings with all stakeholders, including IT professionals and cybersecurity experts. These meetings yield a lot of knowledge transfer and intelligence about threats and mitigation strategies that all parties find valuable.

However, the meetings themselves are time-consuming and can tie up a lot of people for days. Because of this, they cannot be called prior to every sprint. Such meetings run counter to the culture of DevSecOps, which is all about speeding up the software development life cycle.

Popular DevOps trends that speed up development:

• Drive automation and testing as far upstream as possible in the build pipeline (“shift left”).

• Automation isn’t just for application code, but also for system infrastructure, where new technologies allow infrastructure to be defined by code and thus made testable.

• This automation drives faster continuous integration/continuous delivery (CI/CD), allowing features and bug fixes to be deployed more often and with greater confidence

The result: Software development gets faster and faster, with some teams deploying new code into production as often as every two to four weeks. Where is there time for lengthy security meetings with that kind of cadence?

Threat Modeling Team Education to Inform the DevOps Process

Education is key to injecting a threat modeling mindset into the secure SDLC, as emphasized by IBM security expert Brandon Jeanmarie. But large, long meetings can’t happen frequently. Therefore, he recommends a “just-in-time” approach to educating members of the development team when working with clients:

• Threat modeling isn’t hard to understand: Take opportunities to break it down for developers and managers so they understand the possibilities of what can be done, starting “now” where they are currently at in their system development.

• All system stakeholders benefit from learning: Give an exposure to threat modeling that makes sense to each team member’s role. Once aware, they can participate in the solution during sprint story planning and prioritize accordingly.

• Education can also be “shifted left”: Move the awareness of threat modeling as far upstream in the pipeline as possible. This creates good practices in DevSecOps and lets threat identification and mitigation get introduced as early as possible.

• Threat modeling tools can “extend right”: Third-party tools can provide the benefit of automatic threat detection and threat mitigation automation in later stages of the SDLC, including into production where they can continue to protect the system.

Jeanmarie concludes that situational, role-based education results in a “secure-by-design” mindset that enriches the DevSecOps of an organization. And this can be done without frequent, extensive meetings. Once this knowledge is part of the culture, everyone can help when it’s their turn to mitigate threats.

4 Steps to Drive Threat Modeling into Agile Story Design

Security advocate Alyssa Miller takes threat modeling a step further “left.” She examined how threat modeling could fit into DevSecOps more gracefully. Her suggestion:

Narrow the scope of threat modeling to the requirements of each user story. That’s about the “furthest left” you can get in DevSecOps.

The procedure involves bringing the business user into the story analysis conversation. This works because story requirements are upstream from technical details. Ask the business user these questions:

• What are the critical assets involved in the new feature?

• What’s the worst thing that could happen to each critical asset?

The conversation then naturally teases out security requirements that get written into the story as plain language that everyone can understand, such as:

• Critical functions F1 and F2 must be protected from unauthorized use.

• Private data XYZ must be protected from exposure.

• Monetary transaction for purchase P must be shielded from theft while in flight.

These plain-language statements, added to the story, will then cause a cascade of activity downstream in the development pipeline.

Refactoring the process of threat modeling in this fashion enabled her to define it more succinctly: “Identify the likely threats to a system to inform the design of security countermeasures.”

Miller believes this moves DevSecOps culture to the earliest part of the SDLC and empowers the entire development team to include situational threat modeling into the overall goal of continuous improvement. This happens because everyone has a security mindset and takes that awareness into sprint planning meetings and all downstream activities:

1. Plan: Put security requirements into the story.

2. Build: Put threat mitigation measures (security controls) into the SDLC.

3. Test: Write stories with threat mitigation use cases and make them into test cases.

4. Deploy: Create and alarm on monitors that implement the test cases.

Miller concludes that by this process, threat modeling can be included without breaking the speed of DevSecOps.

Conclusion

The culture of DevSecOps is all about breaking down the SDLC into pieces that can be automated to “shift-left” quality early in the cycle and “extend-right” tools that help cover the entire software delivery pipeline. Educating the entire team about threat modeling and how it can also be decomposed into the SDLC, starting with requirements, allows threat awareness to permeate and inform every step of DevSecOps.