Continuous Security: Threat Modeling in DevSecOps

A fundamental goal of DevOps is to shorten software release cycles and bring software products to customers faster and with greater quality than ever. DevSecOps extends that goal to include security along with quality and speed. Naturally, much of the effort that has gone into incorporating security into DevOps has been focused on additional tooling and automation of test-driven security in the CI/CD pipeline. This helps to validate the security of changes to application code and configuration implementations. While this is a necessary part of continuous security, it doesn’t particularly address security in design and architecture. That’s where threat modeling has traditionally played a role in developing secure applications. But the question is, does threat modeling fit in agile development and DevSecOps, where speed and automation rule the day?

In this article, we present a brief overview of threat modeling and how it can fit in a DevSecOps model for application delivery.

What is Threat Modeling?

First, let's begin with a couple of simple definitions (from Merriam-Webster).

Threat – The possibility that something bad or harmful could happen.

Model – A description or analogy used to help visualize something that cannot be directly observed.

Combining these two, we arrive at a general purpose and decidedly non-technical definition for a threat model:

Threat Model – A description used to help visualize the possibility that something bad or harmful could happen.

In the context of software applications, a methodical or structured approach to threat modeling is required. However, it is important to keep the definition above in mind when performing threat modeling on software applications. When performing threat modeling in this context, it can become all too easy to get bogged down in too many formalisms, like specific categorizations, diagram types, and tools – sometimes at the cost of staying focused on what is important, which is identifying and visualizing the possibility that something bad or harmful could happen.

In the context of application threat modeling, I’ll offer this more technical definition:

Threat Modeling – A structured approach to evaluating and mitigating risks to application security by modeling the application as an attacker sees it, considering the attacker's interests – such as entry and exit points, data flows, and critical assets of that application.

The advantage we have when threat modeling our applications is that unlike an attacker, we have full knowledge of design and implementation details that they do not (hopefully). Armed with that knowledge, we can follow a structured methodology to build a threat model of our applications that helps identify and manage risks.

Threat Modeling Methodology

In this section we will provide a brief overview of a common methodology to threat modeling, broken down into five phases:

Requirements and Objectives

During this initial phase, the goal is to analyze the business environment in which the application operates, focusing on the application’s major use scenarios, the organization’s business and security objectives, the application’s risk profile or business criticality, any regulatory compliance requirements, and the organizational drivers behind the security requirements that must be addressed.

The outcome of this phase provides the business context and drivers for building the threat model.

Decompose and Model

During this phase, the goal is to perform a detailed review of the architecture and design of the application and decompose it into a model that helps visualize the possible threats. This is where the threat model first begins to take shape by decomposing the application into its major architectural components, system boundaries and communications pathways and diagramming those to model the application in a way that achieves two important goals:

1. Understand how data flows between major components of the system, to identify the entry and exit points that constitute the exposed attack surface.
2. Identify the boundaries where program data or execution context changes its level of trust. These are known as the "trust boundaries.”

To achieve these goals, a common approach to threat modeling is to use data flow diagrams (DFDs), because of their simplicity and ability to represent the flow of data through a system, which makes it easier to identify the attack surface and trust boundaries. If existing design and architecture documents are not readily available, it is relatively easy to construct DFDs to a level deep enough to understand the system and begin to identify threats; typically, no more is required than a Level 0 context diagram, and a Level 1 diagram for the major processes.

The following figure illustrates a simple example a Level 1 DFD for a web application, showing the trust boundaries, noted as red dashed lines, and potential attack surface, where data flows across these trust boundaries.

Other architecture documents that may be useful when understanding the system include system architecture diagrams (physical or logical), software architecture documents, user stories, etc. Use whatever is available to help understand the system well enough to identify the attack surface, the key components or assets that may come under attack, and where trust levels change between components. With these things identified, it is then possible to begin the process of enumerating the threats to the application.

Threat Enumeration

This is where the real fun of threat modeling begins; when we get to put on our black hat and brainstorm about how our application might be attacked by looking at the model created above and asking: "What bad could happen?" The goal is to identify and classify potential weaknesses to the security of the application, based on how it might be attacked.

When we set out to identify and enumerate the threats to an application, it can be useful to have something that helps us to think about those threats, rather than starting with an empty canvas (or whiteboard). Microsoft created a mnemonic device, called STRIDE, which can be very useful as a means of eliciting threats based on six different threat categories that loosely correspond to attacker goals. Each letter in the STRIDE acronym corresponds to a different category as follows:

Equipped with an understanding of the application and how the different components of the model interact with each other, along with tools such as STRIDE, the goal is to take a systematic approach to identifying and listing the potential threats to a system. This typically begins with a list of threat statements, which often takes a form like the following:

Threat actor performs some action to achieve some goal or has some impact.

For example, based on the DFD above, we can begin to create a list of threats:

1. Remote attacker injects SQL code into book search form to retrieve arbitrary data from the database. (tampering, information disclosure)
2. Remote attacker manipulates URL parameters to access other users’ account information and borrowing history. (spoofing, tampering, information disclosure)
3. Attacker submits unexpected data to the application to cause uncaught exceptions that reveal system or application details. (tampering, information disclosure)

One of the challenges with identifying and enumerating potential threats to the application is knowing when you are done. There’s no easy answer to that question. It is important that the threat modeling team believes they have considered all credible threats to the application based on the model created. For a threat to be credible, there must be a legitimate threat actor (or agent) with known goals. There must also be known attack methods or attack vectors that could be utilized. And there must be an exposed attack surface through which the threat actor could apply those methods to achieve the goal.

Once the application is decomposed into a model that helps visualize the threats, and the team is convinced they have identified the relevant, credible threats, it’s time analyze and validate the mitigations and countermeasures that address those threats.

Mitigation Analysis

The next step of creating a threat model is to identify and analyze countermeasures that are available that would mitigate the risks associated with the threats identified in the previous phase, and document those as part of the threat model. These countermeasures may include both technical and policy controls and are used to guide the application team in addressing the associated risks as they validate the current architecture and security requirements.

Validation

The last step of threat modeling is to identify countermeasures that may have been designed or that exist in the application or system, through a review of the existing security architecture and controls that have been incorporated into the design and architecture of the application. These countermeasures include all technical and policy controls designed to mitigate the risks associated with the threats identified in the threat model. All threats that have no countermeasure in place are considered vulnerabilities, which can then be prioritized and ranked so that the risk they expose to the organization can be appropriately managed.

Okay, it’s not really the LAST step, because as we know, modern application development in an agile, DevOps world, doesn’t really have an end. There is no “done.” And it turns out, threat modeling can fit in quite nicely in that world.

Threat Modeling in DevSecOps

DevSecOps extends the DevOps model by giving security a seat at the table throughout each phase of the DevOps process. Threat modeling fits this model quite well; it is inherently a collaborative activity involving security and the development team. The iterative nature of the threat modeling methodology as depicted previously also fits the DevOps process. Every time that a new “Plan” phase is reached, there is an opportunity to threat model. With each sprint or iteration of the process, the threat model can be reviewed and revised by repeating the steps:

• Requirements & Objectives
  • What new use cases or user stories are being introduced?
  • Have any of the business or security objectives changed?
  • Are there any new compliance requirements?
  • Has the overall risk profile of the application changed?
• Decompose & Model
  • Are there any major new components or processes in the design?
  • Are there any changes to the attack surface or trust boundaries?
• Threat Enumeration
  • Do any of the changes mitigate previously identified threats?
  • What new threats are there based on the changes to the model?
• Mitigation Analysis
  • Identify the appropriate countermeasures based on newly identified threats.
• Validation
  • Are these countermeasures already in place?
  • Do those countermeasures sufficiently mitigate the risk?
  • Does anything new need to be added to the design to address new risk exposures?

Once threat modeling has become a regular part of the DevOps process, this need not be a burdensome activity. And in fact, it may be that in some sprints or iterations, the changes are so minimal that the threat model is simply validated as still being an accurate reflection of the risk exposure of the application, and the team moves on to implementation activities.

But What About Automation?

DevOps so often is about automating all the things. That’s good! After all, delivering products to customers faster is one of the goals. Although manual activities may seem to be the exception in DevOps, there is still a need for certain things to happen that require some manual activity. Threat modeling is one. Tooling can assist in the mechanics of building the model, such as automating or assisting the creation of data flow diagrams, and even automating generation of threats for well-known and understood components and data flows. Anything that helps make the process more efficient and accurate is good. But it doesn’t replace the creativity and critical thinking that human beings bring to threat modeling when they can look at an architecture and ask – “What bad can happen?”

Leverage tools like the Microsoft Threat Modeling Tool, or OWASP Threat Dragon to make the process more efficient. You might even explore tools like OWASP pytm, a Pythonic framework for “threat modeling as code.” Just don’t forget to include human beings in the process!

Conclusion

Continuous security requires more than just automated test-driven security tooling like vulnerability scanning, static code analysis and configuration checks in the CI/CD pipeline. Assessing risk is necessary to ensuring that the right security controls are built into an application from the start, and through every iteration of the development lifecycle. Threat modeling, at its essence, is a risk management exercise; one that can play a significant role in delivering products to customers faster and with greater quality and security than ever.

Interested to learn about how Bishop Fox can help you anticipate application attacks? Read our Threat Modeling Methodology.