2024 State of Cloud Security Report Shows That More Risk Prioritization is Needed

Originally published by Orca Security.

Written by Shir Shadon and Deborah Galea.

Orca Security has released the 2024 State of Cloud Security Report, which leverages unique insights into cloud risks captured by the Orca Cloud Security Platform. Based on risks found in actual production environments, this report highlights the most commonly found, yet dangerous cloud security risks and how these can be avoided.

The report was compiled by the Orca Research Pod, who analyzed data captured from billions of cloud assets on AWS, Azure, Google Cloud, Oracle Cloud, and Alibaba Cloud scanned by the Orca Cloud Security Platform in 2023. In this blog, we provide an overview of the main findings and discuss some of the most disturbing statistics.

Download Report

Executive Summary

Based on the findings, the Orca Report concludes the following:

• Basic security practices are still lacking: This highlights that instead of chasing what's new and cool, sticking to known and robust cloud security practices is actually what’s going to bring organizations the biggest benefit.
• Many risks reside on exposed and public assets: This seems to indicate that risk prioritization and remediation of the most critical risks is not occurring (fast) enough, since we still found many risks on assets that are exposed to the Internet, store sensitive data, or enable lateral movement inside the environment.
• Cloud security postures showed improvement: In 2023, we saw a 1-5% increase in industry average security scores, with the biggest improvement in Public Sector & Education at 5.2%. While you could argue that the gains are modest, we still see this as a positive sign that organizations are doing their part to increase cloud security.

Cloud security scores showing slight improvement across all industries

Key report findings

Below we’ve highlighted the five most disturbing statistics from the report:

• 81% of organizations have public-facing neglected assets with open ports: Neglected assets, with an unsupported operating system or no patching for 180 days, are already vulnerable, but if they are public-facing, especially through the widely targeted ports 80, 443, 8080, 22, 3389 or 5900, they become prime targets for attackers who routinely scan for open ports and known vulnerabilities.
• 21% of organizations have at least one public-facing storage bucket with sensitive data: The fact that one-fifth of organizations have their data storage set up this way should be a wake up call. Making these assets public can put organizations at risk of data exfiltration, ransomware, reputational damage, and regulatory penalties. In general, data stores that contain sensitive data should never be publicly accessible.
• 62% of organizations have severe vulnerabilities in code repositories: These vulnerabilities, with a CVSS score of higher than 7, exist in code that could imminently be pushed to production environments and cause data breaches, system compromises, and supply chain attacks.
• 61% of organizations have a root user or account owner without MFA: While there can be many reasons why an organization hasn’t implemented MFA for their account’s root user, the most likely reason is because it’s hard to manage MFA for shared accounts. However, there are solutions for this, as specified further in the report.
• 82% of organizations have a Kubernetes API server that is publicly accessible: This finding marks a 12% increase from our 2022 report, underscoring the urgency to bolster security measures as Kubernetes adoption surges. While intentional public access exists for testing, the majority of publicly accessible API servers stem from misconfigurations.

Why are these the most disturbing findings? This is because not only do these involve dangerous risks, but the context in which they are found is alarming: involving sensitive data or exposing power users, or found on public-facing assets (sometimes with widely targeted open ports), in code repositories with heightened chance of propagation, or on servers that could be used for supply chain attacks.

Two decades of vulnerabilities

The report also found that 91% of organizations have at least one vulnerability 10+ years old, and 46% have a vulnerability of 20+ years old. While it may seem stunning to see vulnerabilities in cloud environments that actually predate cloud computing, it is perhaps not that surprising. As organizations move applications from on-premises environments to the cloud, existing vulnerabilities are often moved with them.

While the weight of 20+ years of vulnerabilities can seem overwhelming, a context-focused approach to vulnerability management is recommended, focusing on remediating the vulnerabilities most likely to be actively exploited and do the most damage in your environment, as well as re-architecting legacy applications.

Download Report

How can risk prioritization help?

Since cloud security resources are limited and vulnerabilities and risks endless, it's important to know where your efforts will result in the biggest security improvement. Therefore it is important to understand the cloud risk context to know which risks enable dangerous attack paths and patch those first.

Even though exactly the same vulnerability exists on two cloud assets, it certainly doesn’t mean that the risk is the same. Let’s illustrate this with an example: Server 1 and Server 2 are both Apache web servers. They are both using a vulnerable library (CVE-2018-1176). Without risk prioritization, the risk on Server 1 and Server 2 is exactly the same, i.e. the CVSS score of the vulnerability is 8.8.

However, if you take context into consideration you will see that Server 1 is Internet-facing and easily accessible to attackers. In addition, Server 1 is part of a dangerous attack path since it exposes a key to a crown jewel asset that contains PII. On the other hand, Server 2 is an intranet server that is not publicly accessible and exposes no other exploitable risks. It’s important that security teams can instantly see the difference and start remediating the risk on Server 1 first, while only getting to Server 2 after other more critical vulnerabilities are fixed first.