Evolving Threat Modeling to Fit DevOps

threat modeling for DevOps

Current challenges with threat modeling

We need to give a lot more thought to make our applications and systems secure and robust. Many security teams use data flow diagrams as a means to generate security requirements for identifying threats. 

Unfortunately, developers cannot easily integrate data flow diagrams into their workflows because of its complexity. In fact, data flow diagrams weren’t originally designed for risk management. So we are still using legacy threat modeling processes to build security in modern systems. It doesn't fit; and it’s not the right tool for application security. 

There are some well-known challenges with threat modeling methodologies today. 

  • You aren’t given enough time to draw diagrams for threat identification. 

  • To make this valuable, the analysis is limited to a small part of the overall system.

  • The diagrams created are rarely kept up-to-date because of the speed at which we're moving and changing. 

  • The feedback loop isn’t strong enough.

The disconnect between security and DevOps

In DevOps, our intent is to create a Minimum Viable Product (MVP). 

We want to conduct threat modeling as part of this MVP, but find ourselves slowing down since we must think about multiple attack scenarios, potential threats, and possible mitigations.

Unfortunately, the rest of our DevOps teams can’t wait for this information because they need to meet a release deadline. This is the first problem we face. To mitigate this risk, many teams rely on late-cycle penetration testing or a DAST scan. Therefore, security testing gets pushed to the right of the SDLC, whereas in DevOps we're trying to shift security to the left. Therein lies the current tension between these two teams.

The second problem we face is not taking into account the different perspectives on risk and security. Security experts already know about security risks. Development teams are becoming more aware of the Ops risks but they are not aware of risks to other teams. What's missing here is alignment and collaboration. We don't make the right stakeholders aware of a problem or that something of the ordinary has occurred. So how can others possibly fix it? How can others be aware of the bigger implication? Relationships and involving more stakeholders is something we're still hugely missing. 

The third disconnect between Security and DevOps is model versioning. In functional testing, we have inputs to our tests, we have code for our tests, and we have the expected and actual output. That becomes part of our documentation. So why aren't we doing the same thing with threat modeling? This information is not perpetually stored somewhere in a repository so we can conduct version control. We can represent our threat models as JSON or something similar. We also have a wealth of information and stats from our monitoring tools but we are not using them effectively. 

Shift-left, Shift-up

It's no longer just about the horizontal shift-left testing across DevOps pipelines.

Now we have to shift vertically up (shift-up) in the organization to the business teams. We're going to have different people at different levels that are going to extract value about risk from a threat model.

This broadens the scope of what a team or an individual conducting threat modeling provides as an input. We can map cross-functional elements of a threat model to concrete requirements that a development team can execute. The definition of threat model has expanded. It's not just about data flows, but now incorporates concepts like risk. 

Balancing speed and risk

We need to balance both speed and risk. It's not either this or that.

This is not going to come nice and tidy; it's not perfect. Information has to come from all the stakeholders. We will discover risks we had not considered previously because it was never articulated. We didn't think that certain scenarios could occur.

Sometimes we will find more risk, have to add a bit more time, a bit more money, and slow down slightly because it maybe something new. In this sense, threat modeling is about a cross-functional approach that integrates risk, security, and development perspectives.

If you want to learn about the right threat modeling approach for your organization, download our threat modeling whitepaper now.

About the Author

Ruth G. Lennon

Ruth Lennon has 20 years of experience as a lecturer in the Department of Computing at the Letterkenny Institute of Technology, Ireland. Ruth's research interests focus on enterprise-scale systems with particular focus on DevOps and Cloud technologies. She has been a member of many technical panels and committees including NSAI/TC 2/SC 11 on distributed systems and ISO/IEC JTC 1/AG 3 "Open Source Software". Ruth is a member of the working group developing the P2675 DevOps standard. Ruth’s goal in DevOps is to ensure that security and performance are seen as core to development projects just as it is in configuration projects. Ruth has worked on security projects in the area of threat modeling and security reviews. In addition, Ruth is a member of the ACM, ACM-W, IEEE, IEEE-WIE, and the IEEE Computer Society. Ruth also chairs the ACM-W Europe.

More Content by Ruth G. Lennon
Previous Article
Accelerating Digital Transformation in Banking: Why a Strong Security Program Is Key
Accelerating Digital Transformation in Banking: Why a Strong Security Program Is Key

Building security into a bank’s digital transformation plan enables financial institutions to move at the s...

Next Article
Scenario Planning to Manage Security in DevSecOps
Scenario Planning to Manage Security in DevSecOps

One of the biggest challenges that remain in DevSecOps today is alignment between teams. Read how scenario ...