Getty Images/iStockphoto
Wiz launches open database to track cloud vulnerabilities
Wiz researchers Alon Schindel and Amitai Cohen and Scott Piper, cloud security engineer at Block, launched a database to list all known cloud vulnerabilities and security issues.
Wiz launched a community-driven database to improve reporting and transparency for cloud vulnerabilities, which are sometimes swept under the rug.
Motivated by the troublesome disparities between software and cloud vulnerability reporting and disclosure, Wiz threat researchers Alon Schindel and Amitai Cohen along with Scott Piper, principal cloud security engineer at Block, created The Open Cloud Vulnerability and Security Issue Database. The novel project, which debuted Tuesday, offers a way to publicly catalog and classify cloud flaws, which can be helpful in raising enterprise awareness and recognizing threat patterns. Additionally, it was designed to boost communication between cloud service providers (CSPs) and their customers.
Currently, there is no incentive for vendors to disclose cloud vulnerabilities because they are not assigned a Common Vulnerability and Exposure (CVE) identifier and they do not require patching on the user side.
Mitre, a nonprofit organization, manages the CVE Program, though Mitre told SearchSecurity that the CVE Board is the organization responsible for the strategic direction, governance, operational structure, policies, and rules of the CVE Program.
The CVE system doesn't track cloud vulnerabilities, Piper said, because the organization believes in large part that CSPs can fix the issues. However, that's not always the case.
"There are times when customers have to take action or can take action to see if they were historically impacted by these issues," Piper said. "A lot of the security community is guided by CVEs so unless you have one, it's not an issue."
UPDATE: Mitre told SearchSecurity that cloud vulnerabilities can in fact be given CVEs, though the criteria is different than traditional software. "Currently, the CVE Program does not assign CVE IDs and publish CVE Records for cloud-based vulnerabilities unless a cloud service provider (CSP) partner believes the record is useful to their customers, e.g., because of the type of remediation action that customers must take," Mitre said in a statement. "Otherwise, the CVE List would contain many additional thousands of records, expensive to both produce and consume, that would be of limited or no value to downstream consumers."
Mitre the CVE Numbering Authority (CNA) rules were changed two years ago at the request of participating CSPs to enable CVE assignments to cloud vulnerabilities.
"Cloud solutions are intrinsically different from on-prem solutions in that there can be much more effective ways for the vendor to tell each affected customer what to do (e.g., configuration issues)," Mitre said. "Often, CSPs can automatically determine which customers are affected, and automatically generate mitigation or recovery steps that are specific to each customer's environment. When this is successfully executed, the customer avoids several types of costs that would have occurred if CVE Records were used instead (e.g., dismissing all CVE Record alerts that aren't applicable to them, understanding how the CVE Record data applies to their specific environment, translating the CVE Record data into a concrete plan of action, etc.). These costs are non-trivial, which is why the CVE Program struck a balance with (7.4.4[3]) (the assigning CNA is the cloud service provider, and customer or peer action is required)."
But without a CVE, there are no standards for measuring the severity of a flaw or even a way for enterprises to check if they are using a vulnerable version. It can make prioritization difficult for security teams.
"There have been cases, for example, where the same issue has popped up in different services belonging to different providers. That's something worth looking into more, and investing more to defend," Cohen said.
Having a unique identifier such as the CVE also makes discussions more efficient, Cohen said. Without identifiers, or a catchy name, it's hard to talk about cloud vulnerabilities at all.
Growing need for transparency
These problems, among others, were highlighted by several discoveries in recent years, including Wiz's discovery and disclosure of ChaosDB, a bug discovered last year in Azure's Cosmos DB.
Schindel said they noticed significant differences in the way software CVEs and cloud vulnerabilities were published. He also observed that each CSP had its own method of publication, and in most cases the details were not publicly available. Emails or alerts were only sent to impacted customers.
"We tried to investigate if customers remediated the vulnerabilities when they got a notification through email, and we saw remediation was relatively low and we understood there was an issue with the way cloud vulnerabilities and cloud security issues are handled today," Schindel said. "There is no process or standard for how to publish these vulnerabilities with all the relevant details."
One difference he noted between software and cloud vulnerability remediation is that software flaws require fixes that are shared between two different entities. That is not the case with cloud flaws, which can be silently patched.
Such problems have roiled the infosec community recently. First, Tenable CEO Amit Yoran called out Microsoft earlier this month after it silently patched two critical cloud vulnerabilities in the Azure Synapse service reported by the security vendor. James Sebree, principal research engineer at Tenable, published a separate blog which stated that "communication errors and downplaying the severity of issues in their cloud offerings is farm from uncommon behavior for MSRC as of late."
Shortly after Tenable's discovery, Orca Security researchers disclosed a different cloud vulnerability in Azure Synapse, dubbed "SynLapse," which involved insufficient tenant separation and put sensitive customer data at risk. In a technical breakdown of SynLapse, Orca detailed a monthslong struggle with Microsoft to fully remediate the cloud flaw, which involved multiple patch attempts.
Contributing to the database
Wiz credited the project's foundation to Piper, a former AWS consultant who published a GitHub post titled "Cloud service provider security mistakes" that informally tracked known cloud vulnerabilities. Piper started the list, which includes Amazon Web Services, Google Cloud Platform and Microsoft Azure, to keep track of cloud incidents and findings for vendors, customers and security researchers.
Now, the list has expanded into a user interface database, but inclusions must meet certain criteria. Along with being a publicly known security issue in cloud services, vulnerabilities must have a proven impact on cloud customers and require remediation actions on either side of the shared responsibly model, according to the site.
Schindel, Cohen and Piper hope the project will incentivize CSPs to be more transparent. Currently, cloud providers are opaque on security issues and don't address what happened with specific cloud vulnerabilities or what the mitigations are, Piper said.
Another goal of the site is to minimize confusion on the user side. The more information CSPs release about the vulnerability, the less they may be questioned by customers about the threat, Cohen said.
While Schindel said the team knows cloud vendors want their customers to be secure, it does take time and collaboration to properly disclose and address vulnerabilities.
"We hope it will help them see the value of this centralized security issues list and it will help cloud customers to understand this is something they should ask their cloud service providers for," Schindel said. "As a community, we believe it's something that is missing today.
By making the issues more public, cloud providers can see the problems affecting their peers and potentially implement mitigations or ways to improve their own services.
"The more knowledge that exists, hopefully it drives cloud providers to do a better job in general," Piper said.
