DevSecOps offers great potentials, but it is also a challenge in practice for many CISOs and DevOps teams. Today, companies typically leverage several automated tools. However, they are to a large extent separate silos that identify separate lists — most often long lists — of risks and vulnerabilities. This creates complexities, inefficiencies, costs, and risks, and do often slows down DevOps organizations.

A key capability has been missing in the toolset. A capability that empowers both DevOps Teams and CISO by continuously:

Contextualizing Risks; there are plenty of different risks. But what is the holistic risk exposure of my high-value assets? Are we good, or do we need to take action?

Pin-Pointing Actions; there are plenty of ways that we can reduce risks. But what possible actions shall I prioritize? What shall I not prioritize? It is simply not feasible to do everything everywhere.

Conducting Automated Attack Simulations; we should do these analyses continuously but it is simply not possible to do it manually. It would be great to integrate automated holistic analyses in our CI/CD.

This article includes:

DevSecOps is a major evolution of the cybersecurity practice. So, before going into practical details, let’s take a starting point from the overall
business perspective. In the overall requirements, challenges, and
opportunities that DevOps and DevSecOps bring to organizations, CISOs,
and DevOps teams in practice.

Let us explore a typical illustrative example:
An organization — DevOpsCo — has a DevOps way of working. It could have two, ten, fifty, or even hundreds of DevOps teams. Each team is Developing and Operating their part of the overall company system environment. It is not uncommon that one team push several releases per day. And each release naturally has an impact on the security posture of the environment. And not only on the team’s environment but also on other teams’ environments and the total infrastructure.

This small illustration does in itself illustrate both how important it is to embed security into the DevOps workflows to make DevSecOps practically viable and the magnitude of the challenge. But this dynamic is just one part of the challenge. A longer list of key challenges includes the following:

* Multiple DevOps teams all make frequent releases, and each release impact both their own team’s, other teams’, and the total organization’s cybersecurity risk posture.

* It can very easily happen that teams make security mistakes. Just one example of this is how easy it is to make mistakes in terms of setting up IAM policies. In both cloud environments and on-prem environments, it can very easily happen that IAM is set up in a way that grants too much/ wrong access that creates weak security postures and high business risks.

* In addition, there is the challenge to keep up to date with new vulnerabilities, security updates, etc, and put them into context to what needs to be addressed to continuously manage risk over time.

* DevOps teams are not the security experts. Even if we think that it would be great if they were, this will never be the case. It is actually not even desirable as it would require too many security resources.

* CISO-function crucially needs mechanisms that both empower the DevOps teams with automated actionable insights and provides the CISO function with a continuous overview, tracking, and management of the cybersecurity risk posture.

* We all live in a world of scarce resources. Identifying long lists of risks and best practices is a good starting point. But we truly need to identify what risks are key, what actions have the best effect, and when is our security good enough. This prioritization needs to be done from a holistic perspective. And it is not practically viable to do it manually, it is just too complex and time-consuming.

“Sec” in DevSecOps is not a discrete step or phase, but an integrated part of the activities required to deliver software or service in a secure fashion, as illustrated in the typical DevSecOps loop.

Today different activities and tools of the AppSec program will typically attach to different phases of the DevOps loop. Security training of developers, design reviews based on threat modeling, design and code reviews as well as SAST tools like SonarQube for source code inspection are all part of the Plan and Code phases. In the Build and Packaging phases, you typically find security scanning of vulnerabilities in the supply chain dependencies through solutions from companies like Debricked or Snyk.

Moving into the Test phase, security testing is done and often automated by DAST tools, and from the Release phase and onwards a set of more traditional cyber operational tools are employed, including vulnerability scanners for the infrastructure, WAFs, and various types of log monitoring and correlation tools including SIEMs.

Interestingly, a perfect secure development process will still not be a guarantee against breaches of the application after it has transitioned into a live, deployed state. The application context, such as e.g. the Identity and Access Management (IAM) configuration will often be different from a test environment and is bound to change over time. Time will also cause changes to interdependent services and will cause new vulnerabilities to be discovered, both inside the application as well as in the infrastructure on which the application depends. Time is clearly not on the defender’s side.

Furthermore, continuous deployment into public Cloud environments such as Amazon Web Services, Microsoft Azure, and Google Cloud Platform creates an even more challenging situation as both the control plane (asset management operations) and data plane (the application and related service assets) are available over the Internet and often delegated directly to DevOps team.

And, maybe most importantly, the different tools are to a large extent separate silos. Silos that identify separate lists — most often long lists — of risks and vulnerabilities. This creates complexities, inefficiencies, costs, and risks, and do often slows down DevOps organizations.

As described in the earlier sections; DevSecOps is a natural way forward for DevOps organizations. But it also imposes several quite significant challenges. To make DevSecOps practically viable, automated tooling has a key role. Today, companies typically leverage a number of automated tools for DevSecOps. However, they are to a large extent separate silos that identify separate lists, most often long lists, of risks and vulnerabilities.

A key capability has been missing in the toolset. A tool that continuously:

Contextualizes Risks. What is the holistic risk exposure of my high-value assets? Are we good, or do we need to take action?

Pin-Points Actions. There are plenty of ways that we can reduce risks. But what of all possible actions shall I prioritize? And what shall I not prioritize? It is simply not feasible to do everything everywhere.

Conducts Automated Attack Simulations. We should do these analyses continuously but it is simply not possible to do it manually. It would be great to integrate automated holistic analyses in our CI/CD.

These capabilities empower DevOps teams to get continuous insights on key questions as “Are we secure enough?”, “What are the weakest links?”, and “What of all things possible should we do to improve our security posture?”. It enables the CISO function to get an overview and tracking of the security risk posture and get pin-pointed insights when and where needed.

So how can we address the challenges and get the capabilities needed?

Historically, the answer has most often been to implement more generic guidelines on patching, authentication, etc — which means that you will typically overspend in lower-risk areas and underspend in high-risk areas — and/or to try to conduct these analyses manually — which then often turns into not doing them at all or doing them at a too high level only.

Now, new technology enables organizations to get these central capabilities needed through automated tooling. By leveraging AI-based, automated attack simulations, organizations are able to cut through complexity, gain key insights, and take proactive actions where it really matters.

One leading company that is leveraging fully automated attack simulations is Klarna. Klarna is a payments company that is one of Europes’ largest banks and one of the world’s highest-valued and fastest-growing fintech.
Klarna leverages automated attack simulations to continuously manage its security risk posture in highly dynamic cloud environments.

The concepts that Klarna leverages consist of three steps. In the first step, the tool generates digital twin models of the systems in scope. The second step is to simulate thousands of attacks towards the digital twins, capturing all possible ways attackers can potentially reach your high-value assets. The third step is to provide the user with key insights from the simulations; risk levels, key risks, and effective risk mitigation actions.

By leveraging automated attack simulations:

* DevOps Teams get automated and continuous insights on the cybersecurity risk posture of their environment. When the risk exposure is too high/ posture is too weak, they get automated insights on what are the weak spots in the architecture and suggested mitigation actions. The analyses can be fully integrated into the CI/CD pipelines.

* CISO Function gets automated and continuous insights on the posture of the total environment. How does my overall risk posture improve over time? How do the different teams perform? How do the different teams’ environments interact, when/how does one team create risk for another team and provide those insights automated to the teams?

*Automated and Continuous, throughout the DevOps Cycle. securiCAD
provides fully automated in-depth analyses. It can easily be integrated in the CI/CD pipelines. And it is not interfering with your live environment as all the simulations are conducted on digital twins of your environments.

While simulation is probably one of the few ways to risk assess a large-scale environment in continuous change, the key is to build the model continuously based on the real environment. Automation is an important leap to moving away from human subjective assessment and the rigidity of formal strict security frameworks, and to keeping consistent security.

Through automated simulations, companies can take on the challenge of looking at the whole while having clear control of all the details and moving pieces. The simulation capability increases both the capability to see how changes in one team’s environment can affect others and to make assessments more consistent. In the end, it increases security where it really counts.