Embracing Threat Modeling for Agile Resilience

Many years ago in software development the relationship between development and operations had given rise to DevOps —a union that has reshaped how we conceive and deliver software systems. The transition from traditional methodologies to the agile, integrated approach of DevOps marked a seismic shift. DevOps stitched together siloed development and operations, fostering rapid iteration and deployment. However, this acceleration brought forth a critical concern—security, often treated as an afterthought in the race towards faster releases.

The evolution towards DevSecOps emerged as a response to this concern, emphasizing the importance of security practices into the heart of DevOps workflows. DevSecOps represents a cultural shift, advocating not only for the integration of security but for its elevation as a shared responsibility across development, security, and operations teams. In this environment, software features were delivered rapidly, but with security still built in. Often, this security was built in through scanning tools integrated into the SDLC to provide feedback (or noise, depending on your position of DevSecOps) to the development team.

But integrating tools in the SDLC (software development lifecycle) can only do so much and is often viewed as a reactive approach to security. This is where threat modeling comes in.

From Early Identification to Ongoing Adaptation

Threat modeling is the practice of identifying security threats or risks early in the development of a system (or on an ongoing basis. More on that in a bit). It involves a systematic analysis of potential threats, vulnerabilities, and the impacts on a system’s security. The process typically encompasses the identification, categorization, and prioritization of potential threats, considering various attack vectors and potential weaknesses within a system’s design, architecture, or implementation.

However, threat modeling can often be difficult to implement in the SDLC due to its labor-intensive nature. But this doesn’t mean that the practice should fall to the wayside. Quite the contrary, DevSecOps necessitates an expanded scope for threat modeling, moving past the confines of design-centric threats to encompass operational and supply chain threats. These threats, arising post-deployment, present a distinct challenge—ranging from potential lateral movements by attackers to configuration alterations susceptible to exploitation.

While traditional threat modeling remains a critical skill and has its place in the modern development lifecycle, DevSecOps requires recalibration. The high-speed, iterative nature of DevSecOps calls for a more integrated and agile approach to threat modeling, combining seamlessly with the ongoing design discussions and rapid decision-making processes. Additionally, the feedback from the operational and supply chain data provides needed insight into how the system is impacted by real world context further feeding the threat model with valuable information.

Threat modeling in DevSecOps

Within this evolution lies a transformation in the role of threat modeling. Traditionally, threat modeling involved meticulous pre-development sessions often involving members from security, development, and business. This group would scrutinize designs to identify any potential threats or risks. However, in the DevSecOps model, this would often create delays in getting features out the door. Additionally, many organizations would opt for the less thorough approach and utilize tools for threat modeling. While still effective and less time-consuming, the output is often not as in-depth.

So how do we solve this in the DevSecOps realm?

The significance of threat modeling in DevSecOps exceeds its traditional role as a preemptive measure during the design phase. It becomes a cornerstone for ensuring the resilience and security of applications throughout their lifecycle. Integration of threat modeling into DevSecOps isn’t merely about early identification; it’s about fostering a proactive security culture. This can be accomplished by development teams asking the questions: What are we building, what are the threats to what we are building, what are we going to do about the threats, and did we do a good job?

While these questions are basic and foundational to threat modeling, bringing this into the DevSecOps methodology can be challenging, but rewarding. There is still a requirement to involve operational and development resources that are acquainted with the nuances of running an application in a live environment as well as their security counterparts who are able to integrate their knowledge of cybersecurity. This collaborative approach empowers teams to address vulnerabilities not only at the design stage but also during ongoing iterations.

Furthermore, this proactive stance aligns seamlessly with DevSecOps’ ethos of continuous improvement and adaptation. Threat modeling isn’t a one-time endeavor but an iterative, dynamic process integrated into the fabric of development cycles. As the application evolves, so must the threat model, adapting to new insights and changes in the operational landscape.

Can this be done in practice?

Harmonizing Threat Modeling and Rapid DevSecOps Iterations

DevSecOps introduces an ad-hoc decision-making pattern—where security considerations can’t wait for formal (and often lengthy) threat modeling sessions. This poses a challenge: how can threat modeling connect with these impromptu discussions?

One prominent trend on the horizon is the integration of automation into threat modeling processes through scripts and tools within the CICD. Tools like Threagile can enable teams to codify their architecture, threats, and mitigations and have that as an artifact created and maintained in their CICD. Other automated tools and technologies are emerging, designed to assimilate seamlessly into the rapid release cycles of DevSecOps. These tools provide real-time threat insights, enabling teams to identify vulnerabilities swiftly without compromising the speed of deployment.

However, when tools cannot be leveraged, simply asking questions about what can go wrong with what we are building during the user story creation process can bring about the needed understanding of the threats. Once the threats have been recognized in this process, the team can create abuse cases and new requirements that mitigate or remediate the identified threats.

Overcoming the challenges of integrating threat modeling into DevSecOps requires a dual approach: a strategic shift in threat modeling methodologies and a cultural evolution that instills a proactive security mindset within the fabric of DevSecOps teams. This metamorphosis, blending people, processes, and tools, lays the foundation for a symbiotic relationship between threat modeling and the rapid, iterative nature of DevSecOps. While there is an abundance of tools and techniques that can be leveraged in developing threat models, the purpose of the task remains: identify what can go wrong, and develop a plan to address it. How we accomplish that depends on the organization.

Want to learn more?

Check out this threat modeling course on Udemy taught by Derek Fisher:
https://www.udemy.com/course/advanced-strategies-in-threat-modeling