定性与定量:改变的时间我们如何评估第三方漏洞的严重性?

作者: Roger Morrison
创建日期: 26 九月 2021
更新日期: 21 六月 2024
Anonim
定性与定量:改变的时间我们如何评估第三方漏洞的严重性? - 技术
定性与定量:改变的时间我们如何评估第三方漏洞的严重性? - 技术

内容


资料来源:BrianAJackson / iStockphoto

带走:

现在该改变一下我们如何评估开源组件风险的想法了。

简而言之,开发一种评估软件开发社区应多么重视漏洞的系统是一个挑战。代码是人类编写的,并且始终会存在缺陷。那么,如果我们假设没有什么是完美的,那么问题是,如何以允许我们继续高效开展工作的方式,根据组件的风险对它们进行最佳分类?

事实

尽管可以采用多种不同的方法来解决此问题,但每种方法都有其有效的理由,但最常见的方法似乎是基于定量模型的。

一方面,仅基于与漏洞本身相关的因素,使用定量方法来判断漏洞的严重性可能是有用的,因为它更具客观性和可衡量性。

该方法论着眼于如果利用此漏洞会造成什么样的破坏,并考虑在整个软件行业中组件,库或项目的使用程度如何,以及各种因素(例如它可以使攻击者获得何种访问权限)如果他们使用它破坏目标,会造成严重破坏。诸如容易潜在利用的可能性之类的因素在影响得分方面起着重要作用。 (有关安全性的更多信息,请查看网络安全性:新进展如何带来新威胁-反之亦然。)

如果我们想从宏观的角度来看,从定量的角度来看,漏洞是如何伤害畜群的,而不是把重点放在可能遭受攻击的公司身上。

国家漏洞数据库(NVD),也许是最著名的漏洞数据库,针对其版本2和3的通用漏洞评分系统(CVSS)都采用了这种方法。在解释其评估漏洞的度量标准的页面上,他们编写了以下方法:

其定量模型可确保可重复的准确测量,同时使用户能够查看用于生成分数的潜在漏洞特征。因此,CVSS非常适合作为需要准确和一致的漏洞影响评分的行业,组织和政府的标准度量系统。

根据发挥作用的量化因素,NVD可以得出严重程度得分,其严重程度得分从1到10不等,其中10个是最严重的-以及LOW,MEDIUM和HIGH的类别。

没有错误,没有压力-在不破坏生活的情况下创建可改变生活的软件的分步指南

当没有人关心软件质量时,您就无法提高编程技能。

考虑影响?

但是,NVD似乎正在努力根据某种漏洞在造成损害方面的影响力来弄清我们所说的漏洞的定性度量。公平地讲,它们在考虑机密性,完整性和可用性的因素的情况下,在评估漏洞对系统的影响方面将影响纳入其中。这些都是要考虑的重要元素,例如更易于测量的访问向量,访问复杂性和身份验证,但是当漏洞导致组织实际损失时,它们并没有承担将现实世界的影响联系在一起的任务。


以Equifax漏洞为例,该漏洞暴露了大约1.45亿人的个人身份信息,包括其驾驶执照详细信息,社会安全号码以及其他可被不法角色用来进行大规模欺诈操作的位。

Equifax在其Web应用程序中使用的是Apache Struts 2项目中发现的漏洞(CVE-2017-5638),攻击者可以通过该漏洞进入前门,并最终怀抱满载多汁的个人信息。

虽然NVD正确地将其严重性得分设为10和HIGH,但他们的决定是由于他们对其潜在损害进行了定量评估,并且不受Equifax违规行为公开后发生的广泛损害的影响。

这不是NVD的监督,而是其既定政策的一部分。

NVD提供CVSS“基本分数”,代表每个漏洞的固有特征。我们目前不提供“时间分数”(由于漏洞外部事件而随时间变化的指标)或“环境分数”(为反映漏洞对您的组织的影响而定制的分数)。

对于决策者而言,定量测量系统的重要性应该降低,因为它正在寻找将危害扩散到整个行业的机会。如果您是银行的CSO,则应该关注如果利用漏洞利用来窃取客户的数据或更糟的是他们的金钱,该漏洞可能带来的质量影响。 (在“技术中最可怕的五种威胁”中了解不同类型的漏洞。)

是时候更换系统了吗?

因此,鉴于损坏的范围有多大,在Equifax案例中使用的Apache Strusts 2中的漏洞应该获得更高的排名,还是对于像NVD这样的系统而言,这种转变过于主观?跟上?

我们认为,提供必要的数据来得出NVD所描述的“环境得分”或“时间得分”将是极其困难的,这使自由CVSS团队的管理者容易受到无休止的批评和大量工作NVD以及其他用于在出现新信息时更新其数据库的工具。

当然,关于如何计算这样的分数存在一个问题,因为除非披露法律要求,否则极少数组织可能会提供有关违规影响的必要数据。从优步的案例中我们可以看出,公司愿意迅速付款,以期使违规信息无法到达媒体,以免遭到公众的强烈反对。

也许需要一个新的系统,该系统可以融合漏洞数据库中的出色工作,并在信息可用时添加自己的附加评分。

当上一年看起来似乎已经做得足够好了,为什么还要鼓励这种额外的得分呢?

坦率地说,归结为组织对应用程序负责的责任制。在理想的世界中,每个人都将在添加到库存中之前检查产品中使用的组件的分数,在以前认为安全的项目中发现新漏洞时收到警报,并自行实施必要的补丁程序。


也许,如果有一份清单显示出这些漏洞对组织的破坏力是多么严重,那么组织可能会感到更大的压力,以致于无法抓住有风险的组件。至少,他们可能会采取步骤来清点其已拥有的开源库的真实清单。

在Equifax惨败之后,可能有不止一位C级高管竭力确保自己的产品中没有易受攻击的Struts版本。不幸的是,发生了如此大的事件,促使业界认真对待其开源安全性。

希望您的应用程序的开源组件中的漏洞可能产生非常现实的后果的教训将对决策者如何优先考虑安全性,选择正确的工具以确保其产品和客户数据安全的方式产生影响。