Big gaps exist in the 22-year-old Common Vulnerability and Exposures (CVE) system that do not address dangerous flaws in cloud services that drive millions of apps and backend services. Too often, cloud providers needlessly expose customers to risk by not sharing the details of bugs discovered on their platform. A CVE-like approach to cloud bug management must exist to help customers weigh exposure, impact and mitigate risk.
That is the opinion of a growing number of security firms pushing for a better cloud vulnerability and risk management. They argue because of CVE identification rules, which only assign CVE tracking numbers to vulnerabilities that end-users and network admin can directly manage, the current model is broken.
MITRE, the non-profit organization behind the CVE system, does not designate CVE IDs for security issues deemed to be the responsibility of cloud providers. The assumption is that cloud providers own the problem, and that assigning CVEs that are not customer-controlled or patched by admins falls outside of the CVE system purview.
[Editor’s Note: This article was originally published in the free Threatpost eBook “Cloud Security: The Forecast for 2022.” In it we explore organizations’ top risks and challenges, best practices for defense, and advice for security success in such a dynamic computing environment, including handy checklists. Please download the FREE eBook for the full story]
“[It is a false] assumption that all issues can be resolved by the cloud provider and therefore do not need a tracking number,” wrote Scott Piper, a cloud-security researcher with Summit Route, in a recent blog. “This view is sometimes incorrect, and even when the issue can be resolved by the cloud provider, I still believe it warrants having a record.”
Piper’s critiques are part of his introduction to a curated list of dozens of documented instances of cloud-service provider mistakes that he says prove the point.
Over the past year, for example, Amazon Web Services snuffed out a host of cross-account vulnerabilities. As well, Microsoft recently patched two nasty Azure bugs (ChaosDB and OMIGOD). And, last year, Alphabet’s Google Cloud Platform tackled a number of bugs, including a policy-bypass flaw.
“As we uncover new types of vulnerabilities, we discover more and more issues that do not fit the current [MITRE CVE reporting] model,” wrote cloud researchers Alon Schindel and Shir Tamari with the cloud security firm Wiz, in a post. “Security industry call to action: we need a [centralized] cloudvulnerability database.”
The researchers acknowledged that cloud service providers do respond quickly to cloud bugs and work fast to mitigate issues. However, the process of identifying, tracking and helping those affected to assess risk needs streamlining.
An example: When researchers found a series of cross-account AWS vulnerabilities in August, Amazon moved quickly to mitigate the problem by changing AWS defaults and updating the user set-up guides. Next, AWS emailed affected customers and urged them to update any vulnerable configurations.
“The problem here is that [many] users weren’t aware of the vulnerable configuration and the response actions they should take. Either the email never made it to the right person, or it got lost in a sea of other issues,” Schindel and Tamari wrote.
In the context of cloud, affected users should be able to easily track a vulnerability and whether it has already been addressed in their organizations, as well as what cloud resources have already been scoped and fixed, the researchers said.
The CVE approach to cloud bugs also has the support of the Cloud Security Alliance (CSA), which counts Google, Microsoft and Oracle as executive members.
Cloud Bug CVE Approach: Shared Industry Goals
The efforts share many of the same goals, including:
- Standardized notification channels to be used by all cloud service providers
- Standardized bug or issue tracking
- Severity scoring to help prioritize mitigation efforts
- Transparency into the vulnerabilities and their detection
In August, Brian Martin, on his blog Curmudgeonly Ways, pointed out that MITRE’s history covering cloud vulnerabilities is mixed.
“At times, some of the CVE (editorial) Board has advocated for CVEs to expand to cover cloud vulnerabilities, while others argue against it. At least one who advocated for CVE coverage said they should get CVE IDs, [with] others that supported and disagreed with the idea saying that if cloud was covered, [those bugs] should get their own ID scheme,” he wrote.
Martin also pointed out that even if a CVE-like system were created, the question remains: Who will run it?
“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,” he said.
In July, under the auspices of CSA, the Global Security Database Working Group was chartered to go one step further than the idea of expanding CVE tracking. Its goal is to offer an alternative to CVEs and what the group called a one-size-fits-all approach to vulnerability identification. The working group believes the “on-demand” nature and continued growth of IT infrastructures brought on by cloud migration necessitate a corresponding maturity in cybersecurity.
“What we see is a need to figure out how to create identifiers for vulnerabilities in software, services and other IT infrastructure that is proportional to the amount of technology in existence,” said Jim Reavis, cofounder and chief executive officer of CSA, when introducing the working group. “The common design goal is for vulnerability identifiers to be easily discovered, fast to assign, updatable and publicly available” – not just in the cloud, but across IT infrastructure.
Moving to the cloud? Discover emerging cloud-security threats along with solid advice for how to defend your assets with our FREE downloadable eBook, “Cloud Security: The Forecast for 2022.” We explore organizations’ top risks and challenges, best practices for defense, and advice for security success in such a dynamic computing environment, including handy checklists.
