Threat Modeling and DevOps

In this article, I explain why threat modeling and DevOps are a great fit, and how you would go about implementing threat modeling within DevOps.

If your organization is using DevOps to provide applications and development, you should use threat modeling to identify potential threats early within your DevOps (and DevSecOps) development cycle.

What are some threat modeling methods:

What is STRIDE threat modeling
What is PASTA threat modeling
What is Trike threat modeling

What is Threat Modeling

Threat modeling is a method to determine potential threats that may impact applications and IT systems. It is possible to perform threat modeling proactively, and by security as well as non-security practitioners. It is a helpful process that teams can use themselves, rather than relying upon the security department.

What is DevOps

DevOps (and sometimes called DevSecOps in a security context) is a development method that has wide adoption within the industry. It merges ‘Development’ activities, with ‘Operations’ activities (and everything in between, including security) into one team instead of siloed teams. Not only does it merge teams and activities but also modernizes how development and operations are performed using the latest tooling and methodology.

Another aspect of DevOps is the related concept of DevSecOps and Shift-Left security. Essentially this means that DevOps teams are now responsible for their security instead of relying on a separate security department for providing and managing security.

Being responsible for security within a DevOps team is a dramatic change that many teams are frankly not prepared or trained for.

That’s where threat modeling can help.

Benefits of Threat Modeling and DevOps

Threat Modeling can help DevOps teams with the following:

Proactively think about security: As part of DevSecOps and Shift-Left security, DevOps teams are responsible for the security of their application or IT system. Threat modeling is a helpful activity to proactively think about security, even if the team does not have a lot of security knowledge or experience. So introducing threat modeling will help a team to proactively think about security, rather than passively based on external triggers (such as an audit, a security incident, or having to adhere to an IT control framework).
Work as a team on the topic of security: Security is a tough topic for many people, including many members of DevOps teams. Some team members may be very technical and have lots of security experience. However, many other team members may not. Having threat modeling sessions can help to discuss security as a team and to spread team knowledge amongst all team members.
Determine threats early on (starting in the design phase): Thinking about threats, thinking about what can go wrong often occurs at the end of the development lifecycle, or when an application is already in production. This may be too late, because threats may be applicable, and may be lacking relevant countermeasures to mitigate the threat. Threat modeling can help to determine potential threats early on and even in the early design phase. This will help a DevOps team to think about threats during the development lifecycle.
Develop security requirements: Once threats are known, it is possible to develop security requirements to create mitigations or countermeasures to threats. The earlier this occurs, the better because security requirements can be included at an early stage in the development lifecycle.

How to Introduce Threat Modeling in DevOps

Step 1: Provide a Threat Modeling Introduction Training to the DevOps Team

DevOps teams need to know how to perform threat modeling. To achieve this, set up a threat modeling training session. In this training, a threat modeling expert should teach a DevOps team about the details of threat modeling in DevOps, including:

What is threat modeling
What are the threat modeling methods, like STRIDE modeling, PASTA modeling, Trike modeling
How to threat model an application
Show examples
Show example threats
When to perform threat modeling
How to document the threat modeling results
How to perform threat modeling continuously/periodically

The result of the training should lead to DevOps teams being able to perform threat modeling themselves.

Further, teams should understand the benefits of threat modeling in DevOps.

Step 2: Perform the Initial Threat Model

Once a DevOps team is trained, the team should create an initial threat model. The initial threat model should contain a Data Flow Diagram, an initial set of threats, any countermeasures or mitigations that were already identified, and notes based on the sessions and discussions held.

This initial threat model will form the basis of future (continuous) threat modeling sessions.

Step 3: Include Threat Modeling into DevOps Business as Usual (BaU)

DevOps teams should ensure that threat modeling is embedded within the continuous DevOps process.

This means that the DevOps teams should use the learnings from the training, use the initial threat model already created, and actually use the threat modeling continuously or periodically within sprints (and this can consist of performing threat modeling every sprint, or every few sprints).

As of result of this step, the DevOps teams will use threat modeling continuously, and so this is informing a team about potential threats continuously as well.