Scenario Planning to Manage Security in DevSecOps

best practices in DevSecOps

DevSecOps involves the injection of security into DevOps practices and processes. In other words, DevSecOps is DevOps done right.

The intent is to move quickly while still maintaining a reasonable security posture. One of the biggest challenges that still remain in DevSecOps today is alignment or collaborations. To be clear, the definition of alignment here is not limited to technical teams. In fact, we are not aligned with compliance, risk, and business teams.

Because we are not aligned, this leads to a reactive security posture in DevSecOps. We are reacting to incidents from production. Part of the reason we are so reactive is that our approach to software security isn’t based on using security scenarios early in the DevSecOps life cycle.

So, what does security scenario planning mean?

It is not enough to simply use SAST tools. Yet many teams do exactly that.

We need to go beyond and include other use cases that our SAST rules don’t catch but our downstream testing scenarios will be able to catch. In order to expand the scenarios, we need to think about what is most important to protect. That means we need to have a clear understanding of the business value and the potential impact of these values.

However, the value will be different depending on who you talk to.  

Security teams have a different perspective than development teams. Likewise, risk teams may have a different concept of value than infrastructure teams. This lies at the heart of misalignment — each team defines value differently. On their own, they believe they are offering real value. To get past this, we need to think as a cross-functional team to define the security impact scenarios.

We should talk to different stakeholders like compliance, infrastructure, risk, and security teams. From these conversations, we will get a rich set of scenarios and the relative importance across a broad range of perspectives.

Security scenarios will help to predict outcomes

These security scenarios will enable teams to predict possible outcomes of either security breach or irregular activity in systems because of security gaps. In order to be proactive, we must consider these possible security attacks before they happen. Operationally, the approach does not need to be sophisticated when you start at a low maturity level.

Since most teams are already familiar with functional use cases, think of starting with abuse cases. Abuse cases can easily be generated with the help of Security or Operational teams based on current system attacks. The workflow is the same, except you are trying to break the system functionally instead of stating the normal usage. We are then able to proactively mitigate these abuse cases.

Once you understand how to utilize abuse cases, leverage the efforts of other security communities that have helped to create a set of prevalent vulnerabilities.

Leveraging established security vulnerability frameworks

OWASP, for instance, has developed a top 10 list of common vulnerabilities. You can use this list, but don’t blindly accept the list and start recommending mitigations across all your applications.

You have to make the list context-specific based on which applications are the most important. Think about guardrails you need to start putting in place to avoid the same vulnerabilities across different applications. This way, you are leveraging the work from others like OWASP but remaining contextually relevant.

As your teams continue to mature in their security knowledge, this can evolve into more advanced techniques like data flow diagrams and threat modeling. We will still consider scenarios, but our approach is based on a lower level that requires a deeper understanding of data flows through our application.

As you continue to mature, you can add more security standards and frameworks. The goal is to create re-usable security scenarios by leveraging the work of others. Eventually, you will end up with a list of proactive controls that can be reused across many different applications. This way, you will evolve from reacting to vulnerabilities in code to building security into software proactively.

In the end, you need to move away from a reactive security posture to a more proactive one. This means using a cross-functional approach to identifying security scenarios for our domain or organization. The scenarios can also be constructed by leveraging the efforts of other communities like OWASP. In the end, a proactive approach enables us to anticipate security attacks and build the necessary resilience proactively.

To learn how you can inject security in your DevOps processes, you can listen to our webinar.

About the Author

Hasan Yasar

Hasan Yasar is the Technical Director of Continuous Deployment of Capability group in Software Engineering Institute, CMU. Hasan leads an engineering group to enable, accelerate and assure Transformation at the speed of relevance by leveraging, DevSecOps, Agile, Lean AI/ML, and other emerging technologies to create a Smart Software Platform/Pipeline. Hasan has more than 25 years’ experience as senior security engineer, software engineer, software architect, and manager in all phases of secure software development and information modeling processes. He is also an Adjunct Faculty member in CMU Heinz Collage and Institute of Software Research where he currently teaches “Software and Security” and “DevOps: Engineering for Deployment and Operations ”.

More Content by Hasan Yasar
Previous Article
How Secure Is Canada’s COVID Alert App? Evaluation of Android App v1.0.3
How Secure Is Canada’s COVID Alert App? Evaluation of Android App v1.0.3

Our consulting team performed an evaluation of the Android version of Canada’s COVID alert app to evaluate ...

Next Article
Cutting Cybersecurity Budgets to Save Costs During Slowdown
Cutting Cybersecurity Budgets to Save Costs During Slowdown

Organizations are considering cybersecurity budget cuts to save costs during the current slowdown. Read why...