STRIDE Threat Modeling in DevOps: A Perfect Fit

In this article, I explain why STRIDE threat modeling in DevOps is a perfect fit.

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

New to STRIDE? Read my STRIDE threat modeling example to see it in action.

What is STRIDE

STRIDE threat modeling is a method to determine potential threats that may impact applications and IT systems. It is possible to perform STRIDE 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 is a development method that has wide adoption within the industry. It merges ‘Development’ activities, with ‘Operations’ activities (and everything in between) 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, and in particular STRIDE can help.

Benefits of STRIDE within DevOps

STRIDE 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. STRIDE 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 STRIDE 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 STRIDE 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. STRIDE 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 STRIDE Threat Modeling in DevOps

Step 1: Provide a STRIDE Introduction Training to the DevOps Team

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

• What is threat modeling
• What is STRIDE
• How to threat model an application
• Show an example STRIDE threat model
• Show example STRIDE threats
• When to perform threat modeling
• How to document the threat modeling results
• How to perform STRIDE continuously/periodically

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

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

Step 2: Perform the Initial STRIDE Threat Model

Once a DevOps team is trained, the team should create an initial STRIDE-based threat model. The initial threat model should contain a Data Flow Diagram, an initial set of STRIDE 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 STRIDE into DevOps Business as Usual (BaU)

DevOps teams should ensure that STRIDE 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 STRIDE 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 STRIDE threat modeling continuously, and so this is informing a team about potential threats continuously as well.

STRIDE Threat Modeling in DevOps Conclusion

STRIDE threat modeling in DevOps can help teams to improve security within a DevOps process and ultimately the application or system in scope.

Many DevOps teams are struggling to answer the question ‘how do we proactively deal with security’. STRIDE threat modeling provides an actionable method to take charge of security and thus perform ‘Shift-Left’ security.