Why cloud vulnerabilities need CVEs

When considering vulnerability management’s purpose in a modern world, it’s imperative to recognize the huge transition to new technologies and how you manage risk within these different paradigms and environments (e.g., the cloud). Patch network security isn’t applicable in the same way for cloud environments, and few cloud providers assign Common Vulnerabilities and Exposures (CVE) identifiers to vulnerabilities.

For vulnerability management teams who talk exclusively in this CVE-based construct, the lack of CVEs in cloud services is a significant challenge. With cloud-specific vulnerabilities littering the news every week, the question of whether cloud service providers should use CVE identifiers (or something like it) is more relevant than ever.

How cloud services impact risk and vulnerability management’s role

To understand why this discussion needs to happen, consider how cloud services change the role of vulnerability managers. In a traditional network, the vulnerability analyst is responsible for patching the infrastructure. However, with a cloud service, the organization doesn’t manage the infrastructure, so patch management is offloaded to the cloud service provider. That means the responsibility of a vulnerability team has shifted from patch management to configuration management.

When it comes down to it, configuration management is where the bulk of an organization’s controllable risk lies. There’s obviously a lot of risk in the cloud still, but the vulnerability management team no longer controls that. There are some pros and cons to this, of course. The benefit is the cloud provider takes on the bulk of the security risk as well as the work to patch vulnerabilities. On the flip side, vulnerability managers find themselves in new territory where they have little to no control over the security of their organization’s infrastructure.

One infamous example that illustrates the importance of configuration management and whether a CVE identifier is justified for cloud services is MongoDB’s default password configuration issues. The question here is whether the default configuration should have had a CVE identifier? If that had occurred in a standalone software, it very likely would have a CVE. And this misconfiguration affected hundreds of thousands of servers.

That right there is the other important point in this debate: cloud is highly replicable in so many different places. If a Terraform deployment configuration is messed up in a single cloud environment, it will likely replicate in an organization’s entire cloud environment. The implication is clear – cloud vulnerabilities can lead to security issues on a massive scale.

How does the lack of a CVE impact vulnerability management?

Interestingly, cloud providers can assign their CVE IDs, but many don’t, which leaves vulnerability analysts in a difficult spot. CVEs are a huge benefit for identifying potential risks and for being able to track and analyze specific vulnerabilities to ensure they are remediated.

Without a common identifier, vulnerability analysts must contend with the often convoluted and frustrating task of tracking down misconfigurations based on vague alerts, such as misconfigured S3 bucket, and ever-changing names (heavily misconfigured S3 bucket). This process can take weeks or even months to come to its conclusion – either remediation or acceptance of the risk.

What gets a CVE?

One of the nuances of this debate is what constitutes a vulnerability in the traditional sense? And what gets a CVE? Consider the Microsoft incident in which a signing key was stolen and misused by Chinese hackers. While the hack that resulted in the stolen key was not a CVE, the improper key validation sure seems like a vulnerability deserving a CVE identifier. At the very least, it would help vulnerability analysts understand their risk.

Perhaps that is the key to defining a CVE in cloud services: will a CVE identifier help security analysts take action that may inform or educate organizations about their risk and/or take action to mitigate that risk? If yes, then it gets a CVE identifier.

If not a CVE, then what?

The whole point of a CVE is to provide a way to identify unique vulnerabilities accurately and communicate the information across the industry quickly. However, when it comes to cloud vulnerabilities, there is no unique identification system and few places to talk about common misconfigurations within the industry.

Organizations look to benchmarking compliance frameworks like the Center for Internet Security (CIS) which came up with a set of standards for cloud security. Then there are government-developed standards such as NIST 800-171 and 800-53, but those are broad frameworks and aren’t geared to this need.

We can also look at Cloud Security Posture Management (CSPM) vendors that automate the detection and remediation of misconfigurations across cloud resources. They’ve all developed their own identification standards. But if an organization has adopted a multicloud strategy and is using multiple CSPM tools, there’s no way to consolidate those together.

So where does this leave us? As an industry, it seems like we should have a unique identifier so we can talk about cloud misconfigurations in a more defined and actionable way. Perhaps it is CVE for the cloud. We could call it common cloud vulnerability enumeration (CCVE), or something similar.

Imagine, instead of a vague alert like “default password on Mongo DB,” with this version, an analyst might get an alert for “CCVE 1-1.2” and know that it means “default password on Amazon S3 buckets.” This level of detail and standard definition would tremendously simplify the workflow to track and remediate that misconfiguration.

What’s the incentive for a CVE-like identifier for cloud services?

Research has found a typical organization can only remediate about 10 percent of vulnerabilities in their environment in a month. At that rate, organizations are looking at a massive buildup of open vulnerabilities. This vulnerability debt just continues to grow each year. And unlike financial debt, you can’t declare bankruptcy on vulnerability debt. The only path forward is to fix it or ignore it and hope for the best.

Tracking down and remediating every vulnerability is already an upstream battle. Perhaps cloud-specific CVE-inspired identification is one step the industry can take to help ease the task of tracking and fixing these issues. If not, then it’s time for an open discussion to find a better solution. Because our collective vulnerability debt continues to pile up, and it won’t be long before we’re all asking how much risk is too much.