New Vulnerability Database Catalogs Cloud Security Issues

Organizations have traditionally struggled to track vulnerabilities in public cloud platforms and services due to the lack of a common vulnerability enumeration (CVE) schedule like the one MITER maintains for security issues. publicly disclosed software.

A new community database launched this week seeks to begin to address this problem by providing a central repository of information about security issues known to cloud service providers and the steps organizations can take to mitigate them.

The database – – is the brainchild of security researchers at Wiz, who have been advocating for some time the need for a public catalog of known security vulnerabilities in AWS managed platforms and services. Microsoft and Google. The database currently lists some 70 cloud security issues and vulnerabilities that security researcher Scott Piper previously compiled in a document on GitHub titled “Cloud Service Provider Security Errors.” In the future, 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 may 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 whether they have not applied the necessary corrective actions,” said Alon Schindel, director of data and threat research at Wiz. “For example, organizations can check whether they used a certain service during the exploitability period of a critical security issue and use recommended detection methods – if available – to check if they were affected.”

Currently, 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, standardized system for publicly logging cloud security issues and sharing information about them increases risks for organizations. In a blog last November, Schindel and another Wiz researcher pointed to vulnerabilities — such as one called ChaosDB in Microsoft Azure and another called OMIGOD in Microsoft Azure — as specific reasons why a database of cloud vulnerabilities has become an essential industry necessity. Both vulnerabilities were severe. And unlike many cloud vulnerabilities, the responsibility for mitigating the risks associated with both vulnerabilities lay not only with the cloud provider, but also with its customers.

ChaosDB impacted four Azure services and gave users overly permissive access to storage buckets owned by other cloud tenants. OMIGOD was a set of four flaws in OMI, a Microsoft cloud middleware technology, which allowed remote code execution and elevation of privilege. Although Azure and Microsoft quickly patched the vulnerabilities, many organizations using the affected services had limited information about what changes they needed to make to fix them, Wiz researchers said.

“Typically, cloud service provider security issues don’t have a fix in the traditional sense, because the issues are resolved internally by the CSP without requiring any manual user action,” says Schindel. But the lack of CVE means there are no industry conventions for assessing severity, no proper reporting channels, and no unified tracking mechanisms.

“This means it’s difficult for a cloud customer to answer otherwise simple questions like, ‘Is my environment currently vulnerable to this?’ or ‘Has he ever been 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. Sometimes a cloud service provider may even release details of a fix they may have developed for a reported security vulnerability. However, there is little consistency between different providers, says Schindel.

“Notification channels vary; providers typically email only affected customers or notify them through a service health system,” he said.

Wiz was unable to find consistency in the cadence of releasing security issues across the various CSPs, although Microsoft typically includes patches for the Azure vulnerability in its monthly patch release cycle.

Wiz will maintain the new site, although everyone is free to contribute. The goal is to try to get major CSPs to join the effort or use the site to provide more transparency about vulnerabilities discovered in their services. This may include information such as indicating time periods during which a security issue could have been exploitable.

“We also hope the value of such a database will help CSPs standardize their processes for posting security issues,” he said.