The shared responsibility model upon which cloud service security agreements are built is fundamentally broken, a trio of RSA Conference speakers warned on Tuesday, in a session calling for the adoption of a centralized cloud vulnerability database that would help standardize practices for public bug disclosure.
“We have a lot of vulnerabilities that are out there today that aren't being captured through normal processes [and] fall through the cracks pretty regularly,” said presenter Pete Chronis, SVP and chief information security officer of mass media company ViacomCBS. And this circumstance makes it very difficult for security teams “to keep track of them all.”
“Many of us have tools that help us systematically identify and quantify risk,” Chronis continued. “But these cloud vulnerabilities fall outside that world and we need a different mechanism or additional mechanism to help us deal with that.” Without that, it will be “difficult to defend your organization.”
To that end, a collective of more than 130 members with backgrounds that include finance, security, data and compliance, are currently working on the development of a new open-source “Cloud CVE Database” that would provide such a mechanism, according to fellow presenter Ami Luttwak, and chief technology officer co-founder of cloud security company Wiz. “This is the starting point of a new era,” he stated.
Luttwak and Chronis took the stage alongside a third speaker, John Yeoh, global VP of research at the Cloud Security Alliance. Yeoh detailed a second initiative, spearheaded by the CSA: a centralized, open-source, GitHub-based "Global Security Database" that is intended to fill in key gaps in the current vulnerability identifier space. This database will be community-driven, and built for speed and automation, while being inclusive of all existing vulnerability identifier systems (e.g. CVE and NVD).
In the B.C. age – before cloud, that is – end-user organizations were generally responsible for securing their network architectures. But with cloud companies and their user bases now splitting responsibilities, companies are grappling with troubling inconsistencies in vulnerability/patch management and disclosure, the presenters explained. For instance, cloud services providers sometimes fail to utilize a standard channel for communicating update notifications, or their identification of vulnerabilities lacks transparency or specifics, or they don’t offer severity scoring, remediation guidelines or a tracking system.
This Global Security Database will encompass all categories of bugs, not just those existing in the cloud – but the Cloud CVE Database would eventually be one of many vulnerability intelligence sources that would all feed into this universal repository.
Meanwhile, the proliferation of cloud-based services has created unique and complex new categories of configuration and identity vulnerabilities. And because resources are limited to address the vast number of bugs discovered each year, there can often be a “latency between how we report vulnerabilities and how they're disclosed and how they’re identified,” added Yeoh.
This can result in cloud end users going months or longer without properly applying fixes or securing their configurations, or perhaps not even realizing when an important patch applies to them.
Chronis pointed out that if a certain cloud vulnerability is highly critical, it might make the news headlines and thus find its way into your company’s threat intelligence feeds. But this is still not the ideal process. “What we really rely on for risk management processes are clear, repeatable processes that don't fail,” he said.
Cloud users and vendors could potentially address this need by utilizing the “Cloud CVE Database” as a definitive source for disclosing and looking up vulnerabilities, said Luttwak.
This database would ideally provide a unique identifier for each bug, along with such key information as severity scores, lists of affected platforms, the time period during which the issue has existed, the risk associated with exploitation, instructions for remediation and detection, and more.
“We need transparency for providers to give [vulnerability information] to us in a very clear way,” said Luttwak. “Don't send an email with fuzzy language. No. It has to be in the database. There has to be an identifier, severity and a clear risk… And that's what we were imagining” for the cloud database, he continued.
This cloud database, and the all-encompassing Global Security Database, will ideally give CISOs and their teams, a more unified view of risk management, the presenters said.