常见的弱点枚举

CWE术语表定义

CWE映射分析
CWE映射分析

文档版本:1.0日期:2008年9月9日

这是一个草案。CWE的打算支持维护,从一个特定的技术教育和征求反馈观众。本文档不反映任何主教法冠公司的官方立场或其赞助商。manbetx客户端首页版权©2008,斜方公司。manbetx客户端首页保留所有权利。许可重新分配这个文件如果没有这段删除。本文档是可以不经通知自行调整。

作者:马克无爱
URL:http://cwe.mitre.org/documents/mapping_analysis/index.html

CWE的演变和发展,CWE团队认为这是非常重要的理解工具和不同类型的知识存储库可以使用CWE的内容,以及如何使用的数量和质量会影响在CWE覆盖。试图测量和理解范围,分析弱点CWE映射的存储库执行的三个来源——两个商业分析工具和安全编程参考。这种分析CWE的内容结构应该帮助确定变化纳入CWE足以支持1.0版本内容的准确和干净的映射在外部存储库的安全弱点信息。

如果CWE条目太含糊不清或一般——或者完全失踪——这表明改进的领域。如果相同的整体问题或条目相关联,这表明需要进一步清晰和深度在CWE,或者太多的深度。这个练习的目的是为了提高CWE的总体质量,以及个人和组织提供的参考点希望地图CWE的内容。这个参考点希望提供一定的指导和建议在映射过程。它还将提供一个开始词汇问题CWE团队CWE创建和映射过程中处理。同样的词汇可以由别人给详细的反馈。

总样本573外部项目从3检查存储库的反复核对CWE 1.0的报道。

在检查每一个项目和它的映射,我们问以下问题:

• CWE条目映射的选择有意义吗?这是准确的吗?
• 如果一个问题不能映射到CWE条目,是一个准确的映射可能吗?
• 有任何条目从CWE失踪,或CWE条目,需要纠正?
• 如果一个问题映射到CWE条目被认为是不正确的,我们能做些什么来纠正它吗?CWE入口太模糊,太一般,还是不太合适?

虽然我们使用供应商提供的CWE映射作为指导,我们执行评估的最合适的映射是什么。在某些情况下,供应商将映射到错误的CWE条目由于错误(虽然这是罕见的),一种误解的条目,或由于过时的映射(即创建一个新条目后最初的映射进行)。

在下表中,映射的573个人物品分为10个不同的类别。类别的名称是自解释的在大多数情况下,但他们将分别讨论如下。

应该注意的是,虽然这三个外部资源有不同的目标和范围,每个映射的适当性或“适合”可以放在其中一个类别。

在上面的表中列出各个类别按字母顺序排列,他们将讨论首先列出最相关的类别。

确切的——意味着有一个精确匹配CWE条目。到目前为止,这是最常见的一种适合我们发现在这个运动。有一些情况下,存储库中有一个错误或缺失的映射,但是因为有CWE条目是概念上的问题库,适合列为确切。当库指定一个错误CWE,我们试图诊断不正确的映射的原因,但它通常落入另一个健身类。

坏的条目——意味着有一个适当的CWE条目,但条目本身的质量问题阻止原映射器使用它。在映射过程中,似乎适合CWE条目;然而,含糊不清、不一致或泛化CWE条目内引起困惑或可能导致不正确的映射。在这个练习,这样的条目被标记为post CWE 1.0编辑和修改。一个很好的例子是cwe - 391,涵盖了几个不同的问题与错误处理不当。在其他情况下,供应商是映射到两个CWE条目,试图掩盖他们视为一个问题。这是经常作为一个指标,需要一个更具体的条目覆盖的问题,而不是试图映射到多个条目。

失踪——意味着这个问题没有一个匹配的CWE,但是这种问题会被CWE覆盖。这个标识CWE内部差距。没有现有的条目,或所需的条目是“不成熟”,扩张完全覆盖问题。例如,有多个日志不足问题,这是得到CWE 1.0除了保护机制下失败支柱(CWE - 693),但显然是安全相关的日志记录。

抽象——意味着被映射的问题更具体或抽象比CWE条目对应。例如,一个在Java库覆盖三个SSL-specific异常。虽然一个映射cwe - 391无节制的错误条件是有意义的,条目写在一个更一般的时尚;然而,供应商检查一个特定的变体相关具体的错误在Java实现。我们没有区分情况下存储库条目时比最接近CWE更抽象的或更具体的,但总的来说,这是更具体。

包容——意味着没有CWE映射存储库问题,同时也可以辩称,CWE不应该覆盖这类型的问题。这些相关问题与安全性的影响(代码质量、环境和构建问题、配置问题)和安全的影响问题位置的引用的结果更多的是一种弱点,而不是根源,如一个通用的项目标记为“拒绝服务”。Sometimes, a repository item is intended to communicate tool information back to the consumer, e.g. if a library file could not be found, or if a scanning module was disabled; this was treated as an inclusion issue. Other subtler issues would arise, however. While CWE has covered some code quality issues with direct links to more serious weaknesses, some of the repository items seemed like a less obvious choice for inclusion. Consider the assignment of a variable in which the value is never read. One cause of this might be when a value is assigned to a variable, but the variable is never used. Another cause might be when a variable is initialized to a value, followed by an explicit assignment using the same value. There is no actual security impact, however many resources – particularly software analysis tool vendors – will cover general code quality issues in addition to explicitly security-related issues, since there is often a close association between the two. It is an open question as to how CWE should cover such issues, if at all.

的角度来看——意味着存储库条目有多个CWE匹配可能取决于映射器的角度,即最意义映射到它们。角度问题取决于角度有哪些CWE条目映射最有意义。不同的映射的选择可能是,而且仍然是正确的根据的人做映射视图。这个区域生成更多的讨论和改变(和再变更)适当CWE比任何其他组的映射。

一些问题陷入看似CWE的不同部分。例如,双解锁软件组件可以属于cwe - 404资源不当关闭或释放(“程序未能释放-或不正确版本的系统资源,然后才能重用。”),cwe - 413资源锁定不足(“产品不充分锁资源”),或cwe - 675对资源重复操作(“产品资源上执行相同的操作两个或两个以上的时候,操作时应只适用于一次。”)。每个映射是站得住脚,取决于个人的角度回顾手头的信息。我们认为这种类型的角度来看问题作为CWE的一个活跃的研究课题。

最后一个例子将是一个情况下,资源的映射是一个元素的链,当另一个元素相同的链可能是适当的。例如,供应商工具可能会覆盖情况下,失败的代码检查空返回值,后来导致一个空指针。该工具可能映射到cwe - 252不返回值或其后果,cwe - 476 NULL指针。

不精确的——意味着资源都有一个明确的问题,但是最好的匹配CWE条目并不是一个确切的对应,通常只有部分匹配。资源映射到CWE与否,是决定没有一个精确的健康。问题可能涉及多个不同的概念或问题可能映射到一个元素在一个链。不精确映射的一个例子发生在映射一个问题签署了相关比较。使用签署涉及的问题比较检查一个值后视为无符号,导致程序读取数据分配的内存的范围之外。这个问题是映射到cwe - 126缓冲通读(“软件读取数据过去目标缓冲区的终结》)这是接近,但具体问题涉及签署比较——“根源”链接在一个链导致cwe - 126。CWE 1.0条目相关签署/无符号转换,但没有签署比较。

需要细节——意味着项目没有提供足够的细节来评估CWE映射(如果有的话)。一些物品在本质上都是极其复杂的,或含有模糊参考安全的重要方面。完全理解的问题需要进一步咨询库所有者来确定项目的初衷。

让人困惑——意味着外部存储库条目的细节,但它不是写清楚,或有一个CWE映射显示比描述意味着不同的解释。像细节需求类别,这些需要输入从存储库所有者确定的映射是正确的,或如果需要新条目或现有条目就足够了。

其他——这是一个“抓”类别映射的这些问题无法分类。原因主要有以下两个项目最终在其他类别。第一个涉及的问题有多个映射,最终将需要进一步研究如何接近他们。第二组是相当具体,它涉及的问题有多个可能的CWE映射,取决于这个问题介绍了在实现/设计或在配置。

当CWE条目映射问题,事情并不总是可能出现尽可能明确。额外的分析到映射内容创建者可以改进和更精确的CWE映射。如果那些做映射分析提供反馈CWE团队或问问题,可以有重大改进CWE本身的形式完全澄清条目或新条目。这种映射分析的模型我们已经概述了最初的设计作为CWE的质量控制运动;然而,我们觉得别人也可以受益于我们问的问题和我们如何分类的映射。

主要关心的是分辨率——我们如何协调的问题不完全一致?决议将CWE条目的形式变更、外部存储库内容变更,或两者的结合。其他方法可能包括允许多个节点映射为一个问题,虽然这并不总是理想。但是这种分析并提供一个共同点讨论潜在的分辨率分,应该帮助各方理解问题映射到CWE的复杂性。