Organizations traditionally have struggled to track vulnerabilities in public cloud platforms and services because of the lack of a common vulnerability enumeration (CVE) program like the one that MITRE maintains for publicly disclosed software security issues.
A new community-based database launched this week seeks to begin addressing that issue by providing a central repository of information on known cloud service-provider security issues and the steps organizations can take to mitigate them.
The database — cloudvulndb.org — is the brainchild of security researchers at Wiz, who for some time have been advocating the need for a public catalog of known security flaws on platforms and services run by the likes of AWS, Microsoft, and Google. The database currently lists some 70 cloud security issues and vulnerabilities that security researcher Scott Piper had previously compiled in a document on GitHub titled “Cloud Service Provider security mistakes.” Going forward, anyone is free to suggest new issues to add to the website or to suggest new fixes to existing issues. The goal is to list issues that a cloud service provider might have already addressed.
Centralized Vulnerability Repository
“The centralized database can help organizations review all past security issues in their [cloud service provider] at any time and check if they have not applied necessary remediation actions,” says Alon Schindel, director of data and threat research at Wiz. “For example, organizations can check if they were using a certain service during a critical security issue’s exploitability period and use the recommended detection methods — if available — to check if they were affected.”
For now, the vulnerability database site does not have a system in place to automatically notify users when new security issues are added to it. But the goal is to add an RSS feed or mailing list for that purpose, says Schindel, one of the maintainers of the new database.
Schindel — like many other researchers — has noted how the lack of a formal and standardized system for publicly recording cloud security issues, and sharing information about them, is heightening risks for organizations. In a blog last November, Schindel and another Wiz researcher pointed to vulnerabilities — such as one dubbed ChaosDB in Microsoft Azure and another called OMIGOD in Microsoft Azure — as specific reasons why a cloud vulnerability database has become a critical industry necessity. Both vulnerabilities were serious. And unlike many cloud vulnerabilities, the responsibility for mitigating risk with both vulnerabilities rested not just with the cloud provider but also with their customers.
ChaosDB impacted four Azure services and gave users overly permissive access to storage buckets belonging to other cloud tenants. OMIGOD was a set of four flaws in OMI, a Microsoft cloud middleware technology, that enabled remote code execution and privilege escalation. Though Azure and Microsoft addressed the vulnerabilities promptly, many organizations using the affected services had limited information on the changes they needed to make to address them, the Wiz researchers said.
“Typically, cloud service provider security issues do not have a patch in the traditional sense, as issues are fixed internally by the CSP without the need for any manual user action,” Schindel says. But no CVEs mean that there are no industry conventions for assessing severity, no proper notification channels, and no unified tracking mechanisms.
“This means that it’s difficult for a cloud customer to answer otherwise simple questions like, ‘Is my environment currently vulnerable to this?’ or, ‘Was it ever vulnerable to this?'” he adds.
Inconsistent Practices
Currently all major CSPs accept responsibly disclosed vulnerabilities, and some have an official bug bounty or vulnerability reward program in place. Occasionally, a cloud service provider might even publish details of a fix they might have developed for a reported security vulnerability. However, there is little consistency among the various providers, Schindel says.
“Notification channels vary; vendors usually email affected customers only or send them a notification through a service health system,” he says.
Wiz has been unable to find any consistency in the publication cadence of security issues of the different CSPs, though Microsoft usually included fixes for Azure vulnerability in its monthly patch release cycle.
Wiz will maintain the new site, though anyone is free to contribute to it. The goal is to try and get major CSPs to engage with the effort or to use the site to provide more transparency around vulnerabilities discovered in their services. This can include information such as indicating the time periods during which a security issue might have been exploitable.
“We also hope that the value of such a database will help CSPs standardize their security issues publication processes,” he says.
