Cloud Security Detection Doesn’t Reduce Risk. Here Are Six Remediation Steps That Do.

Originally published by Dazz.

Written by Eshel Yaron, Software Engineer, Dazz.

As organizations migrate their software development lifecycle from on-premises to the cloud, our tools have changed to deal with fast-paced CI/CD pipelines. Similarly, the tools we use to detect application vulnerabilities, infrastructure misconfiguration, and other flaws have evolved to keep up with the pace of the cloud. As we grow our development efforts and get ever more efficient, we detect an increasing number of issues.

Until now, cloud security has been covered (mostly) by two categories: Cloud Workload Protection Platforms (CWPP) and Cloud Security Posture Management (CSPM). CWPP scans workloads against known vulnerabilities, while CSPM tools are focused on finding infrastructure misconfigurations, such as a publicly-accessible S3 bucket, a storage policy violation. Each of these detections is useful and cost-effective, but leaves a lot to be desired on a technical level.

Some of the newer CSPM and Cloud-Native Application Protection Platform (CNAPP) tools have taken an extra step, delivering policies that take into account multiple cloud resources and the relationship between them, which improves security teams’ ability to prioritize detections. This shift in focus from detection to prioritization reflects an understanding that the end goal should be about reducing risk, not just pointing it out. With the ever-growing attack surface in complex, fast-moving, multi-cloud environments, we need to find efficient ways to reduce the probability of a breach or exposure.

Gartner has predicted that, through 2025, more than 99% of cloud breaches will be preventable and caused by misconfigurations and end-user mistakes.

To remediate cloud security issues and actually reduce risk, here are six steps that you can incorporate into your process:

1. Find code owners. Attribute security findings to the right owners. This includes identifying the person who technically introduced the flaw into the codebase or infrastructure, as well as who organizationally is the most appropriate person to implement the fix.

2. Reduce to the root. Reduce alerts to their root causes, and provide context to the code owner. This should include the issue, infrastructure, region, business, application, if available, and proposed fix.

3. Map the pipeline. so developers can not only understand an issue’s root cause, but also trace it through the pipeline. This requires integrating metadata from source code management, history logs, and CI/CD logs and configurations to build a baseline of how the organization deploys to the cloud.

4. Get buy-in. Get engineers’ buy-in by implementing a remediation process that speaks their language and snaps into their tech environment.

5. Streamline the process. Streamline the repetitive tasks that engineers face during the remediation process by normalizing visibility across disparate cloud environments, automatically opening tickets to save manual steps, grouping fixes for bulk action, and enabling developers to batch-dismiss similar findings.

6. Prevent recurrence. Make sure that when you provide remediation guidance to your development team, it zeroes in on “patient zero,” or the source of the problem. By fixing at the source (and identifying similar problems throughout your pipelines) you’ll reduce or eliminate issue recurrence.