Boost Pipeline Efficiency with Threat Modeling – SecAdvent Day 3

When you hear the term threat modeling what do you think of?

Perhaps your mind is filled with visions of large Data Flow Diagrams (“DFD”s), STRIDE, DREAD, and PASTA frameworks, and long-cycle efforts that don’t really fit in a DevOps pipeline. Or maybe you don’t have a good idea of what threat modeling is at all and have never had the opportunity to participate in a formal threat modeling process. Whatever your conception of threat modeling is, an indisputable fact is that threat modeling is extremely valuable in pushing security left, ensuring that it is “baked-in” from the very beginning of the pipeline. In practice, threat modeling is one of those practices that not only helps the security posture of our software, but can actually make our pipelines more efficient.

What is Threat Modeling?

This seems on the surface like it should be a simple question, “what is threat modeling?”  However, ask that question of 20 different people in technology and you’re likely to get 20 different answers. The first step in discussing how threat modeling will make our pipelines more efficient begins with defining what it even is and why we do threat modeling. On November 17, 2020, a working group of 15 industry professionals released the Threat Modeling Manifesto. Meant to be a community document providing guidance for how threat modeling should be effectively implemented, it begins with this definition of threat modeling:

Threat modeling is analyzing representations of a system to highlight concerns about security and privacy 
characteristics. At the highest levels, when we threat model, we ask four key questions:

What are we working on?
What can go wrong?
What are we going to do about it?
Did we do a good enough job?

At its core, threat modeling is simply looking at a system or part of a system and asking “what could go wrong”. While the many frameworks and methodologies developed over the years may have made it seem more complex, that’s really the heart of what we’re trying to do when we threat model. The goal of threat modeling then is to understand those threats so that we can effectively build countermeasures to address the threats and mitigate the risk they introduce.

This is the core value of performing threat modeling as part of our pipeline.

In November 2020, a group of 15 industry professionals released the threat modeling manifesto. The goal was to create a guide that would allow organizations to develop or revise a threat modeling methodology while maintaining focus on key practices and principles.

Bringing threat modeling to DevSecOps

It is not uncommon to hear people suggest that threat modeling is not compatible with DevSecOps and the CI/CD pipeline that many strive to achieve. Thinking of traditional threat modeling approaches, it’s easy to see why. Typically, these threat modeling activities involved mapping out data flows of entire applications, documenting where data was stored, processed and where it would cross trust boundaries. From there, threats were identified and classified, attack trees were drawn to show how threats could turn into actual attacks, those attacks were prioritized and ultimately lengthy documentation was produced. Of course all this takes onerous amounts of time and effort, meaning that if implemented this way in a DevSecOps pipeline it would significantly slow the pipeline right from the start.

However, this is just one methodology for threat modeling. The reality is DFDs, attack trees, and the many frameworks like STRIDE, DREAD, and PASTA are not requirements of threat modeling. We can toss out that whole approach and focus on what is at the core of threat modeling and still get value from it. So consider the concept of pushing left. If you want to push as far left as possible in the pipeline, well the farthest left you can go is the user story on the backlog. That’s where the whole cycle begins, so let’s focus on building threat modeling into that process.

When we think about user stories, they are most often written by someone with business context. They describe functionality or a desired user experience. The authors of these user stories have a perspective that is important for the developers that will eventually implement that user story. They can discuss the crucial assets and potential threats that could impact those assets in plain language terms. Simply providing that information is a form of threat modeling and is exactly how we can drive this practice into our pipelines. Instead of complex unnatural security or even technology terminology, let’s focus on plain language that is more universally understood. For assets we can break them down into a handful of key categories:

• Private Data
• Critical Functions
• Financial Assets
• People Assets
• Secret Data

These are terms that anyone can understand. Now each organization can of course tailor these in anyway they’d like, these are just examples to show how plain language makes this process easier. With these critical assets understood, now we can talk about threats in similar plain language. For example:

• Theft
• Fraud
• Exposed Data
• Interrupted Business

Again, easy and straightforward. If we add this context to our user stories, when a developer is assigned that user story for an upcoming sprint, they have a clear definition of what elements are most crucial to the business and therefore can develop defenses to protect against the things that could go wrong.

The goal of threat modeling then is to understand those threats so that we can effectively build countermeasures to address the threats and mitigate the risk they introduce.

Driving value throughout the pipeline

The value of threat modeling is more than just getting security involved early in the process. Threat modeling produces important context that can enable more efficiency throughout the rest of the pipeline and actually improve overall DevSecOps maturity.

By identifying threats at the user story level, developers or architects can easily consume that information and use it in planning the design of security countermeasures. In a true DevSecOps culture where security and developers are working together, this is a perfect collaboration point. Security and the architects or developers can discuss the threats and the requirements for those security controls.

As the pipeline moves on, those designs are implemented during the building phase of the pipeline. As code is written and built, security features are already a part of the new or modified software. Now as the code moves into the testing phase, the documented threats, the security requirements, and the implementations of countermeasures can be leveraged to prioritize and automate security test cases. Finally, as the pipeline hits deployment, all this previous information can be used  to facilitate monitoring capabilities that are focused on the key concerns and attack types for that new user story implementation.

Having this information progress through the pipeline removes the need for specific security gates, speeding up the overall pipeline. It improves the ability to automate testing and increase its effectiveness. In turn, the handoff to operations at deployment time has enabled ease of monitoring and understanding of the changes thus creating more effective production controls. The collaboration that is fostered throughout is a key characteristic of mature DevSecOps cultures and thus the organization overall sees tangible benefits from the implementation of this threat modeling approach.

Wrapping it up

The final component to all of this, and what should be a pillar of any DevSecOps culture is the governance. By starting documentation of threats and the user story and building off of that information through the course of the pipeline, it is easy to demonstrate compliance with secure development policies and requirements. An environment of continuous improvement is created and metrics are easily available to measure the improved security posture that results.

Threat modeling enables not only security within the DevSecOps pipeline but also drives tangible business value through improved and more efficient delivery. Once we get past the traditional views or the mystery surrounding threat modeling, we can see how it easily plugs into the pipeline and can establish collaboration across various disciplines. It is a crucial component when organizations consider their application security programs and is a natural starting point for improving security posture of software.