朝着一个共同的枚举的漏洞

大卫·e·曼史蒂文·m·Christey

manbetx客户端首页

202年伯灵顿路,贝德福德01730 MA

{damann, coley} @mitre.org

1999年1月8日

文摘

在本文中,我们讨论了使用多个漏洞数据库的运作企业安全环境和我们认为的一些障碍我们看到实现之间的互操作性。我们介绍常见的脆弱性的概念枚举(CVE)作为一种机制,我们相信将有助于促进数据共享。我们考虑一些历史的例子分类法在其他领域的发展和与他们当前的努力代表危险和共享信息。我们提出一个简化的表示的一个“漏洞”,讨论如何使用它来减轻我们预期的互操作性问题。我们还描述的一些实际问题,可能参与了CVE的开发和使用。

1介绍

manbetx客户端首页公司是一个独立的冠冕,网路公司在公众利益工作,向政府提供技术支持。本文讨论的工作已经完成横切的内部信息安全委员会。斜方使用多种工具来评估其安全状况,包括一些网络评估工具和入侵检测系统(IDS)从各种各样的供应商。这些工具都代表着一种或另一种形式和流程漏洞。我们正在建设一个系统,可以从不同的来源信息集成和管理漏洞在一个集中的数据库,将与我们的内部企业数据库为目的的支持我们企业安全操作。例如,我们需要立即实现以下功能:

作者希望承认他们的同事,威廉·h·希尔,为本文提供了概念性的灵感。

©1999斜方manbetx客户端首页公司。保留所有权利。

每一个信息安全工具我们正试图整合有自己的隐式或

明确的漏洞数据库。我们所面临的最紧迫的问题在试图获得这种集成是没有共同的命名约定,没有共同的枚举的漏洞在这些不同的数据库。结果,比较是劳动密集型的评估工具的输出(或IDS工具)来自不同供应商的,与IDS警报与网络评估调查,与其他信息来源和相关的任何工具。

有几个努力试图定义共享模式,普遍的原语和健壮的脆弱性信息分类法。虽然我们仍然感兴趣和支持这些努力,我们注意到这些问题似乎没有共识。我们的问题是,我们现在需要在我们的工具之间实现互操作性。此外,问题阻止我们实现这种集成更基本的定义好的模式,原语或分类法。问题是,没有社区的一致性对于识别漏洞。

在本文的第2部分,我们将讨论一些障碍我们看到实现互操作性。在第三节,我们介绍的一个共同的弱点枚举(CVE)。在第四部分,我们考虑一些历史的例子分类法的发展。在第五节中,我们考虑一个漏洞信息和讨论如何简化表示我们预计使用解决互操作性问题的简化表示。第六节介绍一些实际问题可能参与CVE的开发和使用。我们还讨论我们的方法的缺点。在第七节,我们将讨论未来的工作领域。8节中,我们总结我们的结论。

2路障的互操作性

我们大纲四个单独的我们面临挑战,在试图实现之间的互操作性我们所有的工具和其他漏洞信息来源。

2.1不一致的命名约定

考虑的问题以一致的方式命名的漏洞。例如,一个漏洞发现于1991年允许未经授权的访问NFS文件系统通过可推测的文件句柄。在国际空间站X-Force数据库,这个漏洞是标记nfs-guess[8];2.4在CyberCop扫描仪,它被称为NFS文件句柄猜测检查[10];和相同的漏洞标识(连同其他漏洞)CERT咨询ca - 91.21,这是标题SunOS NFS巨型和fsirand补丁[3]。为了确保相同的漏洞中引用这些资源,我们必须依靠自己的专业知识和手动关联他们通过阅读描述性文本,可以模糊的和/或长篇大论的。

2.2从不同来源管理类似的信息

完成这样的任务中,我们试图与扫描探针与证书报告和其他来源的漏洞信息,为我们提供一个全面的照片特别的脆弱。内部文档CyberCop扫描仪2.4意味着13个独立的调查,与NFS问题[10]。每一个13相同调查列出了6证书报告作为相关信息的源文件。本文的发表时,国际空间站X-Force数据库生成20支安打与NFS[8],虽然类似的搜索INFILSEC数据库的产生只有4支安打[6]。这些漏洞很快就明白有关的问题:有13日6日20日4,或一些组合吗?多少NFS漏洞存在,以及完成这些数据库对“真”的漏洞吗?

2.3管理多个进化观点相同的弱点

每个源的相关信息漏洞强加了一个不同的角度。例如,一个IDS的脆弱性可能与攻击签名;扫描仪的角度可能是密切相关的探针用于识别相同的漏洞;分类法可以分类根据故障导致脆弱的类型;和企业角度可能定义风险根据其网络配置和安全策略。这些不同的观点很难设计模式完全捕捉所有这些信息。更糟糕的是,这些观点可以随时间发生变化,需要修改任何表示,试图统一这些截然不同的概念。我们需要一个方法,尽可能使我们从这些表征的问题。

2.4数据库之间映射的复杂性

每个数据库(或工具)包含脆弱性信息可能有不同的枚举的漏洞。因此,为了实现完全的互操作性在所有的数据库,我们需要确定和维护对于每一对数据库之间的映射条目。没有一个命名约定或其他标准的引用漏洞,映射过程是劳动密集型和容易出错。

3常见漏洞枚举(CVE)

没有协议漏洞和名称列表,我们的集成任务变得更加困难,由于存在大量的我们需要执行映射。为了实现互操作性的安全工具和分享漏洞信息,我们需要一个常见的漏洞枚举(CVE),一个标准化的列表:

一个共同的弱点枚举允许我们评估我们各种信息来源的广泛性。标准名称自动将帮助我们更清楚地与漏洞信息的来源。从多个独立脆弱性视角将有助于CVE保持稳定。最后,CVE必须是公开的,没有分布限制,允许自由数据交换整个社区。

3.1缺乏一个共同的弱点的枚举

在我们看来,目前没有一个枚举所有的漏洞一个好的CVE的特点。

许多商业id和扫描工具已经隐式或显式数据库相关的漏洞,但是他们中没有一个人真正“漏洞数据库”,列举一个漏洞的完整列表。与网络相关的数据库我们看到扫描仪可能更恰当地称为“调查数据库”,因为在很大程度上,条目对应的各种调查评估工具。IDS工具数据库可能是更好的被称为“利用签名数据库”,因为他们的重点主要是利用签名或IDS警报。数据库,横切目前发展供内部使用可能被称为一个“企业数据库”,因为它寻求与特定的信息漏洞,例如主机和网络配置、IDS警报,评估的结果,和安全政策。每个数据库都有一个不同的角度的弱点是什么。

有些数据库可能试图组织漏洞信息基于一些中央理论概念。例如,一个漏洞数据库可能围绕脆弱性的概念是一个软件故障[1]。但是这样的一个数据库最终将很难处理的漏洞与错误配置或硬件故障。另一个漏洞数据库[9]定义了漏洞的未经授权的访问可以获得的过程,这样做,它可能更正确地视为一个开发数据库。虽然许多数据库努力试图列举各种漏洞,他们通常是不完整的总数已知的漏洞。

其他信息来源可能是形成隐含漏洞数据库。例如,CERT的身体报告和Vendor-Initiated公告组成一个隐式的数据库漏洞,也是任何报告的集合。甚至“黑客”利用库形成事实上的漏洞数据库,其中一些是非常全面。

许多描述数据库本质上是不完整的,因为它们只是为了解决一类特定的问题或问题。例如,网络扫描仪和IDS工具主要是只通过网络利用的漏洞;CERT只发布报告漏洞高风险或普遍。

有一些努力尝试列举所有漏洞。一些不公开或分布的限制。其他人则相对不完整。一些最完整的数据库(如国际空间站X-Force数据库)是作者的版权控制并保持,并且不能自由分布[8]。

一些工作可能间接地址命名的问题,如入侵检测IETF工作组。然而,在撰写本文时,似乎关注表示和数据交换,而不是整合。专注于数据类型和不需要定义的实际数据,并可以理解偏向于IDS攻击特征的角度对漏洞[7]。

简而言之,在这个时候,没有数据库,我们意识到满意的候选人为一个共同的弱点枚举用于我们的集成任务。

4其他领域的命名和枚举

当我们考虑采用普通危险枚举(CVE),我们可以收集一些角度考虑过去类似的努力,比如元素周期表的发展和动物的识别。

例1 - 4.1元素

在“周期系统的进化,”Eric Scerri[11]讲述了现代元素周期表的发展由俄国化学家发明,迪米特里门捷列夫。Scerri指出:

发现周期系统的分类元素代表数量的科学发展的顶点,而不是突然头脑风暴的一部分的一个人…在门捷列夫的发现(1869年)之前,其他科学家已经积极发展某种形式的组织系统描述的元素。例如,在1787年,法国化学家安东尼·拉瓦锡,与安东尼Fourcroy合作,盖顿louis bernard de Morveau引Claude-Louis贝托莱,设计了33个已知元素的列表。然而,这样的列表只是一维表示。现代表的力量在于其两或三维显示的所有已知的元素(甚至未被发现的)在一个逻辑系统的命令行和列。

虽然Scerri的文章侧重于组织和分析门捷列夫的元素周期表,同样清楚的是,这样的一个表可以想到之前,首先需要枚举和命名的元素。门捷列夫的元素周期表直到1869年才出现在打印,80多年后,拉瓦锡的简单和不完整的枚举。可以说的简单维列表的元素被普遍接受的工具,允许有效的沟通在科学界,由此产生的互动和信息交换提供门捷列夫的后分类的进步的基础。

对漏洞信息,在我们看来,信息安全社区是点,类似于化学门捷列夫的时间之前。社区可能不同意漏洞的分类方案,但我们可能知道足以开始列举漏洞,独立的分类。借用Scerri的语言,是必要的,在这一点上是一维表示,至少从我们操作视角。使用更复杂的表征可以等到一些共识。不可避免的重新定义我们的第一维枚举是可以接受的,只要我们能解决一些最初的标准作为第一步更直接的互操作性。

4.2示例2 -动物

考虑的情况下灰熊。我们希望让一些观察。第一,一次加州黄金熊,棕色的熊,科迪亚克熊和灰熊都被认为是不同的物种。今天,他们被认为是一个物种(熊属arctos) [4]。我们注意到动物信息的命名和分类是由动物和生物群落的共识。相比之下,没有这样的共识在信息安全社区对脆弱性信息。

第二,命名和分类的过程是一个迭代的过程,一个开放的重新定义是后天习得的。如果命名的物种的历史有什么启示的话,那就是我们作为一个社会必须接受我们第一次在命名的漏洞可能存在缺陷,我们应该致力于改进术语即使我们努力学习更多关于漏洞。此外,我们必须致力于限制重命名工作的背景下,社区内接受。

最后,我们注意到很多我们共同的语言的效用有关动物王国源于我们的能力来确定动物以不同程度的精度或抽象。例如,使用术语更有用的熊,灰熊,科迪亚克熊或熊属arctos吗?答案显然取决于上下文。这最后的观察求下列问题。我们应该到什么程度的抽象定义漏洞?

4.3的抽象层次

假设我们考虑三种不同的枚举所有已知的动物,首先是一个枚举所有已知的家庭,第二个是枚举所有已知物种,第三是枚举所有已知的亚种。我们可能会希望在第一个找到的条目熊,灰熊(物种:熊属arctos)在第二和科迪亚克熊(亚种熊属arctos[4])在第三。相反,如果我们考虑3独立枚举所有已知的漏洞,我们就没有知识的抽象级别的期待完全基于这个词“漏洞”。One enumeration may list vulnerabilities at a high level of abstraction (buffer overflow, etc.). The second may list faults in specific pieces of software as identified by name, version and even sub-version. And the third may fall somewhere in between. Similar ambiguities with regard to differing levels of abstraction are discussed in [2].

如果一个简单的、单维的CVE将执行一个抽象层次,然后在抽象层次CVE应该定义什么?我们相信,一个事实上的标准在这方面已经出现了。根据自己的经验和各种安全漏洞数据库的工具和多个公开漏洞数据库的熟读,我们相信有很多共性的抽象级别,适合反暴力极端主义。这种级别的抽象比“缓冲区溢出”,更具体更普遍比指定个人缺点在个人的软件。例如,大多数IDS和扫描工具的知识漏洞,如公积金,NFS文件句柄猜测,wuftp“网站执行”的问题。因此,我们相信,一个可行的第一次尝试建立CVE及其隐含的决定正确的抽象级别,可以通过基于CVE的现有安全工具和公开的漏洞数据库,尽可能多。

你可能认为,基于新兴的CVE标准的抽象级别将无法使用一些目的。例如,一个自动补丁管理系统可能需要处理安全信息的抽象级别要低得多。我们相信这不会导致问题对CVE(大概在更高层次的抽象定义)除非我们说,补丁管理系统包含一个枚举的“漏洞”。It is only at this point that we make the semantic mistake of using "vulnerability" at 2 different levels of abstraction.

4.4结论

分类方案和分类法努力组织设置的信息。如果动物王国的发展我们共同的语言元素是任何指示,信息安全社区是正确的继续努力一个健壮的脆弱性信息或分类法分类方案。然而,我们建议社区将是错误的等到我们有一个发育完全的分类与相应的语言漏洞允许我们处理漏洞信息在不同的抽象级别。虽然这是一个有趣和重要的研究问题,我们需要满足我们立即和操作目标是一个简单的、非结构化清单已知的漏洞——一维常见的漏洞枚举(CVE)已知的漏洞。CVE将推动我们更接近直接不同的数据库和工具之间的互操作性,它会促进更大程度的工具之间的数据交换和整个社区的隐式定义一个共同的语言弱点。

5定义“脆弱性”

当我们考虑开发一个可分享的漏洞数据库的任务,我们可以获得一些见解通过考虑分享物种数据库可能是什么样子的。物种可以被定义为一群交配繁殖的自然种群与其他类似的组织。[5],而这个定义提供了一些指导动物学家对分类的努力(尽管无性生殖仍然有问题)的定义是模糊的关于识别通用元素的列表,它将有能力定义所有物种。

我们认为任何定义的“漏洞”,包括足够广泛的软件故障和网络配置错误将同样模糊的确定一个原语列表能够捕捉所有已知的漏洞。这样的定义的“脆弱性”会影响CVE至少在两个方面。首先,它应该塑造我们理解一个脆弱的实体将如何与其他实体,我们可能想要模型。其次,它将有一个大型对脆弱性的定义实体本身的影响。

5.1 CVE -一个合乎逻辑的桥梁

我们的愿景的一个常见的漏洞枚举是提供一种机制将vulnerability-related数据库或概念联系在一起,仅此而已。而不是看到这个狭窄的范围限制,我们认为这是一个优势。同意限制使用的CVE逻辑的桥梁的角色,我们就免费(或强制)来定义自己扩展脆弱性的概念根据我们自己的特定操作的需求。参见图1。

考虑一个例子从我们目前的工作。我们有两个单独的数据库:一个接收IDS警报,一个接收评估工具的输出。两个数据库有实体,题为“漏洞”。Given the different operational objectives of the two databases, it is not surprising that the vulnerability entities in each database are comprised of very different lists of attributes. In fact, it would be more appropriate if the two competing Vulnerability entities were called Vulnerability_IDS_View and Vulnerability_Assessment_View instead. Moreover, since our IDS and assessment databases are both works in progress, we expect that the definitions of the Vulnerability_IDS_View and Vulnerability_Assessment_View entities will change over time. By maintaining separate logical extensions to the common, shared entity of Vulnerability, we compartmentalize our data at a conceptual level. This allows us to continue with our development of both databases independently while still preserving interoperability by maintaining links back to our CVE.

5.2最小表示法的CVE漏洞

CVE的需求中描述在第三节,多角度的CVE应该独立存在漏洞。确保CVE的独立的一个方法是定义漏洞只有充分必要的属性是常见的所有漏洞,确保这些属性不依赖于任何进化表示,可以普遍同意的大多数安全社区。

我们从最近的工作现在另一个例子。其中一个目标是将脆弱性信息各个主机的信息。特别是,我们一直有兴趣了解操作系统漏洞适用于由于我们想把这个企业了解哪些主机正在运行的操作系统。一个问题出现关于操作系统的粒度信息我们想跟踪。在一个极端,我们可以选择枚举所有可能的操作系统包括每一个可能的版本和服务包和补丁的所有可能的组合。在另一个极端,我们可以限制粒度的选择,说,四个平台:Unix,微软、苹果和其他。前者的方法显然很有吸引力的完整性,我们发现它是行不通的实用性。一方面,我们找不到明确的信息的适用性不同的漏洞所有平台和我们的结论是,所需的测试和评估这样做将是压倒性的。另一方面,很难进行自动化的软件目录的所有不同的主机。鉴于高度动态主机配置的本质和我们无法知道确切的主机操作系统上运行,我们放弃了,就目前而言,在我们试图处理操作系统信息在一个精确的水平。

我们在引用这个例子,我们怀疑我们能找到协议在社区层面上如何模型这种无关痛痒的事“受影响的操作系统。”Each of us will be driven by our own different concerns when it comes to vulnerabilities, and these differing concerns will lead us to differences in schemas and primitives. We believe we will be much better off by initially agreeing to agree on a minimal set of attributes for the concept of "vulnerability" itself.

我们认为在CVE漏洞不需要任何属性以外的一个唯一的名称和文本描述。只要这个名字是独一无二的,和描述包含足够的信息来区分从其他漏洞CVE漏洞,那么这两个属性都是必要的。通过使用唯一的名称和描述,我们减少共同的脆弱性枚举的复杂性和避免问题的表示和分类——至少从操作的角度来看。扩展这个有限的概念“漏洞”,使用CVE作为逻辑的桥梁,可以团结不同观点的漏洞“真的”是什么。

5.3结论

模式和原始列表试图定义一个漏洞是什么。试图定义一个健壮的模式或一长串的原语可共享的漏洞数据库,我们我们可以创造更多的点或将不同意,因此,我们创建集成更多的障碍。此外,同意推迟甚至消除漏洞的任何其他共享属性决定实体(除了名称和描述),我们每个人都获得一定程度的自由的方法,记录和管理漏洞信息根据我们自己的需要,没有约束建模从其他来源强加给我们。通过这种方式,我们可以努力获得新的见解漏洞从我们自己的角度和操作需求,同时维持与他人整理和合并数据的能力,我们将能够做的事情如果我们都同意CVE链接我们的工作。

6实际问题

在本节中,我们将探讨的一些实际问题涉及使用CVE实现现有系统之间的互操作性问题

6.1政治可共享性

一个很大的区别研究漏洞和物种的研究和化学元素的“所有权”物种的命名法和元素已经进化的一部分我们的语言,我们的文化和我们学术机构的一部分。漏洞信息,另一方面,往往是与商业利益。不清楚的原因,许多安全机构没有明确列举漏洞与自己的工具(除非购买这些工具)。在其他情况下,一个枚举不与任何工具,信息本身是受版权保护和/或限制的分布;或者枚举在很大程度上是不完整的,也许只关注一种类型的脆弱性。

如果我们在定义一个CVE成功,它必须是“政治”分享以及逻辑上可共享的。集体努力,也许一个财团的商业、学术、最成功和其他利益,可能会建立一个受益的CVE社区作为一个整体。然而,最终CVE的定义可能需要一个中立的权威,以解决它们之间的冲突,将会出现多种相互竞争的利益。

6.2降低复杂度的映射

给定两个特定的数据库,它们之间的映射必须指定的条目在一个数据库中相关条目。例如,如果数据库列举一组NFS的漏洞,和B列举了自己,然后为每个漏洞,必须指定的映射在B的漏洞有关。实现完整的所有数据库之间的互操作性,我们需要维护nC2= n (n - 1) / 2不同的映射。

另一种可选择的方法是引入一个额外的数据库(CVE)和使用它作为一个标准,所有其他映射。这种方法有两个优点。第一个也是最明显的是,这减少了映射的数量O (n),而不是O (n ^ 2)。

一个不太明显的优势可能只成为实现CVE变得接受并被社区。现在,如果我们想要建立一个特定数据库之间的直接映射,是认识和理解和其他一些数据库可能不知道或理解,我们必须首先获得一个完整的了解第二个数据库列举和名称的漏洞。然而,如果CVE成为建立和广泛接受的信息安全社区,它可能更容易第一个数据库映射到CVE仅仅因为CVE比第二个数据库更好的认识和理解。通过这种方式,每个单独的数据库映射到CVE限制知识的领域需要将数据库与其他数据库。

6.3精度损失

虽然数据库映射到CVE可能降低整体集成多个数据库的复杂性,它有一个固有的劣势:精密的潜在损失。两个数据库之间的直接映射可能更精确的比通过CVE复合映射。

我们建议这种潜在损失的精度是一个可以接受的折衷,原因有两个。首先,唯一的选择是维护和共享O(n2)单独的映射。我们的经验是,作为一个社区,我们目前不关注这个问题。第二,我们希望越来越多的将采用一个标准的CVE漏洞数据库的内部数据库。最终,这可能会允许更大程度的精度在使用复合映射的CVE,同时提供一个明确的识别数据库之间的根本差异的机制。

6.4结论

在努力实现之间的互操作性单独漏洞数据库,连接所有数据库共享CVE减少数据库之间的映射O(n2)O(n)效率的大幅增加可能被添加到CVE收益在社区接受。因为使用CVE将涉及复合竞争数据库之间的映射,我们可能期望一些损失相比,精度保持独立的直接映射为每一对数据库。然而,我们相信这种潜在的缺点是超出了我们需要联系不同的漏洞数据库以更有效的方式。

7未来的工作

我们当前的工作都集中在识别许多信息来源我们想要融入自己的vulnerability-focused数据库。我们的经历让我们识别反暴力极端主义的必要性。未来的工作将需要创建或获取CVE,然后使用它来帮助我们在我们的集成。

无论我们采用的CVE,我们预计几个挑战,其中大部分是与数据库之间的映射存在的普遍问题。

而反暴力极端主义的目的之一是为了简化漏洞数据库之间的映射,我们预计,从一个数据库映射到CVE很少会一对一,如果(考虑哪一个数据库中的NFS例子列出13漏洞而另一个上市20)。大多数漏洞数据库是狭窄的焦点。例如,许多人只关注network-exploitable漏洞(例如id签名数据库)或当地可利用的漏洞(例如警察)。其他数据库是相当一般,但仍只包括一部分的所有漏洞(例如CERT的隐式数据库报告,只识别最高危和常见的漏洞)。这些数据库,由于他们的目的,将包含一个不同枚举的漏洞,所以不会与任何CVE一对一的关系。

虽然没有可接受的CVE为我们目前,预期缺乏一对一映射从数据库到CVE会出现问题,可能会有缺口或抽象层次的差异。一个映射,只使用一个“=”关系的完整性将是有限的。

更好地阐明一个漏洞数据库的元素之间的关系和反暴力极端主义,我们预计利用以下关系(目前非正式定义)。假设V1是一个漏洞中定义的一个数据库,和V2是另一个数据库中定义一个漏洞(例如CVE)。然后:

V1 = V2如果(V1和V2引用同一个弱点)

V1包容V2如果(V1包括V2和其他漏洞)

V1相交V2如果(V1和V2分享一些,但不是全部,特点)

上面概述的CVE关系可以用来更精确地表达一个漏洞数据库之间的关系和共同的脆弱性枚举不仅仅是一个简单的“平等”关系。十字路口关系实际上意味着两个漏洞之间有一些重叠,但他们是不平等的。

这些CVE关系最好可以表现出使用一个示例的一个子集组成的CVE NFS的漏洞:

名称描述

- - - - - - - - - - - - - - - - - - - - - -

CE1 NFS文件句柄猜测

CE2 NFS pcnfsd

CE3 NFS世界出口

CE4 NFS导出列表> 256字符

我们可以使用的CVE关系映射CERT报告(CA), CyberCop扫描仪探测器(CCS),和X-Force数据库条目(XF)我们CVE漏洞中指定:

CyberCop扫描仪 ISS X-Force CERT CVE
CCS 7009 = CE1 XF 77 = CE1 ca - 91.21贯穿了CE1 CE1
CCS 6004 = CE2 XF 415 = CE2 ca - 96.08 = CE2 CE2
CCS 7002 = CE3 XF 798 = CE3 (没有CERT CE3有关) CE3
CCS 7013 = CE4 XF 503 = CE4 ca - 94.02贯穿了CE4 CE4

7.1使用CVE漏洞数据库之间的映射关系

如果我们定义一个漏洞为一组(任意)定义属性和解释CVE关系因此,然后“=”和“包容”有以下属性:

(V1 = V2)ÞV2 = V1

(V1 = V2和V2 = V3)ÞV1 = V3

(V1包容V2)和(V2包容V3)ÞV1包容V3

不幸的是,传递属性没有交集。但是,它仍然可以被用来确定潜在的数据库之间的交互:

(V1相交V2)和(V2相交V3)ÞV1可能相交V3

这些关系的传递特性可以用来推断如:

(CCS 7002 = CE3)和(XF 798 = CE3)ÞCCS 7002 = 798 XF

(CERT ca - 91.21包含CE1) & (CE1 = XF 77)Þ证书ca - 91.21贯穿了XF77。

7.2测量候选人CVE利用其CVE的质量关系

CVE关系可以用来客观地衡量候选人的质量CVE正在考虑采用,或者比较有可能CVE的竞争。我们可以评估一个枚举E对漏洞数据库D通过测量基数的派生关系,定义适当的指标。一个方法是选择一个CVE最大化“=”关系的数量和减少十字路口的数量(如十字路口意味着模糊关系)。E的特异性可能用“包容”关系的基数从E D和E的普遍性可能测量的基数包容关系从D E .质量指标还包括测量等的数量差距E D,即漏洞在D没有关系任何漏洞在E。

8的结论

我们认为信息安全社会需要构建和采用一个可共享的漏洞数据库捕获一个商定共同的脆弱性枚举。急需一个简单枚举的已知的漏洞为了实现互操作性的安全工具和数据库和信息安全社区促进沟通。此外,我们相信,一个共同的弱点现在这种类型的枚举是可以实现的。我们建议一个好第一次尝试确定正确的抽象级别和适当的枚举的漏洞可以通过检查当前的主要商业和公开的漏洞数据库。因为目前还没有共识的定义对于一个健壮的模式或原语的列表,我们建议一个共享数据库争取不应超过的定义为每个漏洞名称和描述。因为一个共同的脆弱性枚举必须在政治上共享以及逻辑上可共享的,我们提出这样一个枚举的漏洞应该最终派生和维护的一个财团政党或一些商业中立方。

引用

  1. :t . 1995。一个分类Unix操作系统的安全缺陷。硕士论文,普渡大学。
  2. 主教,m和贝利,d . 1996。一个关键漏洞分类分析。技术。众议员cse - 96 - 11,计算机科学系在加州大学戴维斯分校的。9月。
  3. CERT协调中心。1991年。CERT咨询CA-91:21。出版电子在http://www.cert.org/advisories/ca - 1991 - 21. - html。
  4. 美国国际版百科全书。1991年。卷3。熊。Grolier合并。
  5. 美国国际版百科全书。1991年。体积26。分类法。Grolier合并。
  6. INFILSEC系统安全。1997年。在线数据库。
  7. 互联网工程任务组。1998年。入侵检测交换格式合同。电子出版在:http://www.ietf.org/html.charters/idwg-charter.html
  8. 网络安全服务。1999年。在线数据库X-Force。出版电子在http://xforce.iss.net/。
  9. 国家信息安全保障合作伙伴关系。1998年。在线数据库目录的威胁与对策。出版电子在http://www.niap-ccevs.org/
  10. 网络协会注册。1999年。2.4专利漏洞数据库CyberCop扫描仪。
  11. 1998年9月,SCERRI,大肠。周期的演化系统。《科学美国人》。

有关更多信息,请联系CVE开发者。

回到顶部
页面最后更新或审查:2017年8月10日,