At the recent Black Hat USA 2021, security experts from cloud infrastructure company Wiz argued that a CVE database for cloud vulnerabilities is needed, starting a debate in the cloud and cybersecurity communities.
Without the support of the CVE system, a list of entries containing an identification number and at least one public reference for security vulnerabilities, it is difficult to track and manage issues that affect cloud services.
The current lack of a repository for cloud vulnerabilities gained momentum at the computer security conference in Las Vegas. Ami Luttwak, co-founder & CTO at Wiz, and Shir Tamari, head of research at Wiz, explained the current status while discussing a possible vulnerability on AWS and the importance of awareness:
IAM vulnerabilities are not tracked by NIST, do not have a CVE, and do not have scanning tools that provide IAM vulnerability scanning results. The result is that most customers are running with vulnerable IAM policies and have no process to fix them. Furthermore, we discovered that AWS issues hundreds of security updates to its IAM policies, but security teams lack tools to scan for them and prioritize fixing them. It is vital to raise the community awareness of the issue of IAM CVEs because identity-related vulnerabilities are a key attack surface in cloud environments.
They started a Slack channel to work on the CVE proposal and document their findings in an article. Brian Martin, CSO at attrition.org, reflects:
As one of two people (the other being Jake Kouns) that may have the longest history in this specific space, I wanted to give some history (...). First, for perspective, CVE covers at least 56 pure cloud / site-specific vulnerabilities, the first going back as far as 2000 (...) At times, some of the CVE (Editorial) Board has advocated for CVE to expand to cover cloud vulnerabilities while others argue against it.
As reported on Dark Reading, Amazon disputes that Wiz's findings are vulnerabilities. Florencio Cano, senior security analyst at Red Hat, comments on the AWS example:
I agree we need something similar to CVEs for cloud offerings. However, I think it should be focused on vulnerabilities, not risks. Weak defaults are not vulnerable defaults and a correct configuration is not a mitigation for a vulnerability. We also have to be careful about which service will "own" the vulnerability.
This is not the first time a discussion about CVE for cloud has started. Three years ago Kurt Seifried, director of IT at Cloud Security Alliance (CSA), and Victor Chin, then research analyst at CSA, wrote an article to highlight the challenges of the current CVE rules. They explained the main limitation:
For example, one of the Inclusion rules, INC3, states that a vulnerability should only be assigned a CVE ID if it is customer-controlled or customer-installable (...) INC3, as it is currently worded, is problematic for a world that is increasingly dominated by cloud services. (...) This is because cloud services, as we currently understand them, are not customer controlled. As a result, vulnerabilities in cloud services are generally not assigned CVE IDs. Information such as workarounds, affected software or hardware versions, proof of concepts, references and patches are not available as this information is normally associated to a CVE ID.
In a recent article, Jim Reavis, co-founder and chief executive officer at CSA, gave an update on how CSA wants to address the problem. While a solution is still discussed, Martin raises a warning:
The only thing worse than such a project not getting off the ground is one that does, becomes an essential part of security programs, and then goes away.
