已有22年历史的CVE（CommonVulnerabilitiesandExposures）系统存在巨大缺陷，无法有效解决拥有数百万应用程序和后端服务的云服务中存在的危险缺陷。云提供商通常不会共享在其平台上发现的错误的详细信息，从而使客户面临风险。因此，必须存在一种类似于CVE的云错误管理方法，以帮助客户权衡风险、影响和风险缓解。这就是越来越多的安全公司正在推动更好的云漏洞和风险管理的观点。他们认为需要打破当前的模型，因为根据CVE识别规则，只有最终用户和网络管理员才能通过分配的CVE跟踪编号直接管理漏洞。MITRE是CVE系统背后的非营利组织，不会为被认为是云提供商责任的安全问题分配CVEID。假设是，云提供商拥有问题，那么分配不受客户控制或由管理员修补的CVE超出了CVE系统的权限。SummitRoute的云安全研究员斯科特·派珀(ScottPiper)在最近的一篇博客文章中写道：“云提供商可以解决所有问题的假设是错误的，因此不需要跟踪号。”这种观点有时是不正确的，因为即使云提供商可以解决问题，相关人员仍然认为值得记录。Piper的批评是一个精选列表的一部分，该列表包含数十个记录在案的云服务提供商错误实例，他通过以下真实示例对其进行了验证。例如，在过去一年中，AmazonWebServices消除了一系列跨账户漏洞。此外，Microsoft最近修补了两个讨厌的Azure错误（ChaosDB和OMIGOD）。去年，Alphabet的谷歌云平台处理了一些漏洞，包括策略绕过漏洞。云安全公司Wiz的云研究人员AlonSchindel和ShirTamari在一篇帖子中写道：随着技术人员不断发现新型漏洞，专家们发现越来越多的问题不符合当前的[MITRECVE报告]模型。因此，安全行业呼吁采取行动：需要一个集中的云漏洞数据库。研究人员承认，云服务提供商确实能够对云错误做出快速反应并迅速解决问题。然而，识别、跟踪和帮助受影响者评估风险的过程仍然需要简化。例证：当研究人员在8月发现一系列跨账户AWS漏洞时，亚马逊迅速采取行动通过更改AWS（亚马逊网络服务）默认设置和更新用户设置指南来解决漏洞。AWS随后立即向受影响的客户发送电子邮件，敦促他们更新任何易受攻击的配置。但是上述方式也存在一定的问题，即很多用户并没有意识到易受攻击的配置，也不知道应该采取什么措施来应对漏洞。要么电子邮件从未到达合适的人，要么迷失在其他问题的海洋中。Schindel和Tamari写作。研究人员表示，在云方面，受影响的用户应该能够轻松跟踪该漏洞，以及该漏洞是否已在其组织中得到解决，以及哪些云资源已被确定范围并得到修复。云漏洞的CVE方法也得到了云安全联盟(CSA)的支持，该联盟将谷歌、微软和甲骨文视为执行成员。CloudBugCVE方法：共享行业目标这些努力共享许多相同的目标，包括：所有云服务提供商使用的标准化通知渠道。标准化错误或问题跟踪。努力评分以帮助确定缓解工作的优先级。漏洞及其检测的透明度。8月，BrianMartin在他的博客CurmudgeonlyWays中指出，MITRE在覆盖云漏洞方面的历史参差不齐。有时，一些CVE（编辑）委员会主张将CVE扩展到云漏洞，而另一些则反对。至少一位支持CVE覆盖的倡导者表示，他们应该获得一个CVEID，而其他支持和不同意这一观点的人认为，如果云被覆盖，[这些错误]应该获得他们自己的ID程序。他写了。Martin还指出，即使创建了类似CVE的系统，问题仍然存在：谁来运行它？在他看来：唯一比这样的项目没有启动更糟糕的是，它启动了，成为安全计划的重要组成部分，然后因为各种原因无法继续下去，直到消失。7月，在CSA的主持下，全球安全数据库工作组被授权进一步扩大CVE跟踪的想法。它的目标是提供CVE的替代方案，以及该组织提出的一种通用的漏洞识别方法。工作组认为，云迁移带来的IT基础设施“随需应变”和持续增长需要相应的网络安全成熟度。CSA联合创始人兼首席执行官JimReavis在介绍工作组时说：“我们可以看到，我们需要弄清楚如何根据现有技术的数量在软件、服务和其他IT基础设施中制造漏洞。的标识符。共同的设计目标是使漏洞标识符易于查找、快速分配、可更新和公开可用——不仅在云中，而且在整个IT基础架构中也是如此。本文来自：https://threatpost。com/cve-cloud-bug-system/179394/如有转载请注明原文地址。
