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.