2010 CWE / SANS -最终稿修改和讨论
变化和讨论项目 日期:2010年12月13日
- 发布前25 - 1.07更新细节符合CWE 1.11的发布,主要与缓解措施和一些名称的变化。
日期:2010年9月27日
- 发布前25 - 1.06更新细节符合CWE 1.10的发布,主要是与移植。
日期:2010年6月29日
- 出版前25 - 1.05的修改官方名称列表,取代“编程”与“软件”
日期:2010年6月21日
- 发布前25 - 1.04更新细节符合CWE 1.9的发布,主要是与移植。
日期:2010年4月5日
- 发布前25 - 1.03更新细节与释放CWE 1.8.1是一致的,主要是通过改进移植和额外CAPEC映射。
- 删除重复项重点概要总结
日期:2010年2月25日,
- 排名前25位的文档,1.02版
- 固定cwe - 306年“绕过安全”的影响;添加指向无应用程序安全性的博客。
日期:2010年2月17日
- 排名前25位的文档,1.01版
- 加入微软SDL的链接
- 添加页码PDF
日期:2010年2月17日
- 首次公开版本的2010排名前25位的文件(1.0)
日期:2010年2月13日 CWE前25——投票结果所有人, 如前所述,很多排名前25位的选民不喜欢4重要性的关键选票的限制,和4为流行广泛的选票。 即使这个限制不存在,似乎对排名前25位的影响最小。 许多选民用选票超过最初提供我这些限制。我把这些选票,他们与其他选民的选票,满足了限制,和生成的投票结果看到发生了什么。 的比较。只有一个条目会掉落前25名。前5项甚至没有改变位置,底部也5原来的41。只有约25%的上涨或下跌幅度都超过了两个地方的条目。 自大约一半的选民选票后提醒关于限制,提供无限制的投票是不完整的数据集。所以,我不认为这是适当的,使一个单独的配置文件使用此数据集提供备用的排名。所以我已经决定放弃它。然而,我不认为这是一个很大的损失,因为比较表明很有可能不会显著的区别。我会将这归咎于不考虑明年的“教训”,并记录相应的方法论部分的文档。 ——史蒂夫 日期:2010年2月3日 CWE的前25位,总结活动所有人, 这是一个总结最近的活动和即将发生的事。
- 提醒一下,前25的公开发布被推迟到星期二,2月16日。
- 选举候选人名单是关闭的。我们收到了来自28个不同的组织!我们激动的反应。
在几天内,我将联系每个选民把选票回他们审查,用自己的分数和排名,以及最后的分数/排名。
- 我已经决定指标将被用于一般的列表。基本上,理由是保持简单。对于每一个选举CWE, sub-score将分配基于:
(重要性X流行)
每一个因素都有一个评级从1到4,即。,没有“额外学分”强制限制广泛和重要的评级。最后的得分是每CWE个人评级的总和。
贝齐·尼科尔斯正在评估数据的质量(如分布和独立因素),但在这一点上,我们有我们所拥有的。
- 许多选民想要使用超过4广泛或关键评级,我们将占在一个单独的“重点概要”(以前称为“技术资料”)。我将会重用我收到人们的原始选票;如果你第一次投票后限制,随时重新提交一个更新的选票分配尽可能多的“广泛”和“关键”评级,你觉得是适当的。
- 以下重点资料可能会进入最终版本。这些将被张贴到讨论列表,和我们想积极参与和审查这些。
- 无限制的广泛/关键评级:之前讨论。
- 教育重点:哪些弱点应该强调在一个教育背景;使用替代指标和3因素。
- 自动与手动分析:哪些弱点被自动化技术和手册。
- 语言和特定于语言的问题:可能包含一个小的每一项流行的主要语言。
- 优先化的重要性:另一个视图的投票数据指标强调的重要性,针对消费者或刚刚开始的安全软件。
- 设计与实现:检查表视图的弱点被固定在设计、实现,或两者兼而有之。
其他因素包括:
- 建立开发者评级:只使用提交的选票从软件供应商参与,创建一个单独的排名——展示供应商建立安全的开发实践关心。
- 基于网络和非托管代码可能被归入着重/语言配置文件。
- 我计划发布前25的第一稿文档周四晚上,2月4日。个人集中配置文件也将发布独立的审查。
对于那些能参加,我们将寻找人们回顾草案(任何您希望的部分),有助于个人集中配置文件,或评估个人的详细那样条目。 再次感谢帮助我们的人! ——史蒂夫和鲍勃 日期:2010年1月26日 CWE最高25 -进度更新和即将到来的活动所有人, 这是一个更新CWE前25名。
- 我们已收到至少15投选票的候选人名单,我们可能会得到20或更多。这是超过我们可以希望,所以我非常感谢你的努力!
投票期限延长两天,周四,1月26日——一个星期之前出版的官方排名前25位。
- 许多选民不喜欢至关重要和普遍流行的限制只允许最多4票。这将是在得分指标占给这些“额外学分”评级,并将明年的教训。
- 现在的数据收集投票几乎是完整的,是时候讨论一些得分的方法使用。这封电子邮件后不久,我将提出各种指标和讨论利弊。我将与贝琪尼科尔斯在接下来的几天内,分析提出了度量的效用以及他们是否通过适当的统计气味测试。
最终决定在度量使用将在周五。这将被用来排名,最可能的选择,官方一般的条目列表。
- 各种评论将被更紧密地回顾和合成到最后的总目录的摘要。最常见的一个主题是,许多不同重要性的评估依赖上下文,如类型的应用程序或环境。我希望其中一些上下文将阐明科技档案。至少,他们成为重要的输入斜接的工作在一个共同的弱点评分系统(水煤浆)。
- 我一直工作在技术档案的概念和一般意义上的资料就好了,包括在第一个公开发布。这些想法将在第二天提出。我认为这种方法将招募参与者个人技术档案,谁可以审查结果和提供任何评论。帕斯卡默已经花费了大量的精力在制定教育档案,完成与另一种定量排名三个不同的因素。
- 最有效的措施之一的初稿已得到改进,但它需要更多的编辑。我将有一个提议在几天之内。
- 我们开始寻求支持报价,以及经验的人使用了2009年排名前25位的列表,并从中受益。如果你有兴趣,联系Bob Martin (ramartin@mitre.org)和史蒂夫Christey (coley@mitre.org)。
- 应对审查个人CWE条目,以及相关的评论,将不迟于星期一开始,2月1日。
- 出版前25的周四,2月4日。
再次感谢大家的继续支持这一努力! 史蒂夫和鲍勃 日期:2010年1月11日, 得分和排名所有人, 我与伊丽莎白·尼科尔斯对不同方法定量等级或分数排名前25位的弱点。虽然有很多的想法,他们中的大多数将耗时太长,容易出错,因为小样本大小,等明年,我希望花更多时间探索的一些想法。 不过,今年,我相信我们已经找到了一个基本方法,会有一些灵活性和提供额外的经验教训来帮助我们提高在未来技术。
- 保持/删除/添加投票,到目前为止,我已经收到了被用来创建一个草案的弱点列表。额外的意见将请求在接下来的几天里。
- “候选人名单”将收集的建议,调整了抽象和一般的反馈。
- 轮询时间将持续一个星期。每个贡献者将调查评估每个弱点基于标准我们选择,如发病率和严重程度,使用固定的选择,离散值(例如,高、中、低)。使用离散值将简化我面临很多问题,因为我使用流行的各种数据。
- 我们可以设计以适当的权重得分函数,然后用所得的分数等级的条目。我打算提出某种类型的得分函数,和伊丽莎白会做一些data-munging魔法,看看她可以推断出适当的重量从提交的数据本身。这将是一个有趣的运动本身,但是如果我们都想出答案大致相当,那么它会被某种验证。
这些项目都包含在我刚刚发送的更新进度。 ——史蒂夫 建议:使用“重要性”而不是“严重程度”得分和排名总清单上的项目,我建议我们使用这两个因素:
考虑到大量的资料和观点的威胁,并讨论这个列表,使用因素的“严重性”带来了一些困难。首先,就是明证cwe - 209讨论,严重性的感知可以相差很大。有几个人说,即使它本身不会造成太多的伤害,深度防护是十分重要的,它还应该包括在名单上。第二,替代视角等教育优先可能不认为严重程度是最重要的因素。也希望量化结果并提出适当的排名。 我建议我们使用一个新的因素,而不是严重:“重要性”。 这将允许个人投票表决一个弱点是多么的重要,使用自己的标准反映了他们的日常工作。排名前25位的贡献者可以有效地编码最重要的是什么——不管是严重程度,利用频率,需要教育,等等——的方式是特定于自己的需要(和他们的客户需求)。 使用某种机制相结合的普遍性和重要性(待定),我们可以将个人分数分配给每个CWE条目,然后根据这些分数排名前25项。 结果将是一个广义的建议,合并不同的观点提出一些接近达成共识。每个单独的技术概要文件仍然可以定义自己的标准,分数和排名。
重要性
为每个潜在CWE前25,我建议使用以下输入的重要性。
| 标准: |
“如果这个弱点出现在软件,你用的是什么优先级时建议你的消费群体?(如修复,减轻教育)”。 |
- 关键——这弱点是更重要的比其他任何弱点,或是在前4。它应该尽快解决,可能需要投入资源,通常会被分配到其他任务。(例如:缓冲区溢出可能会收到一个关键评级在非托管代码,因为代码执行的可能性。)
- 高,这个弱点应该尽快解决,但它没有最关键的重要的弱点。(例如:在某些威胁模型,一个错误消息信息泄漏可能给予高度重视,因为它可以简化很多其他攻击。)
- 中期应该解决这个弱点,但只有在高和临界水平的弱点已经解决。
- 低——这是不紧急解决的弱点,或者并不重要。
患病率
为每一个潜在CWE前25,我建议使用下面的输入为流行。
我欢迎任何建议我选择的比例范围。
| 标准: |
对于每一个“项目”(是否一个软件包,笔测试、教育工作,等等),这一弱点多久发生或造成问题吗? |
- 广泛的- 70%或更多的项目;或者,当发现,经常在同一项目的多个实例的问题
- 高50%到70%的项目
- 中期10%到49%的项目
- 低,不到10%的项目
候选人名单,草案1 1 -草案状态摘要(2010年1月11日)
1 -草案状态
状态:top25(排名前25位的弱点在这个草案) 有17个条目状态。
| cwe - 311 |
(新)未能加密敏感数据 |
|
抽象变化:添加替换其孩子,cwe - 319明文传输;这个父还包括未能加密数据存储。 |
| cwe - 672 |
(新)过期或释放后操作资源 |
|
抽象变化:404年添加为一个更具体的孩子,连同它的兄弟姐妹,cwe - 772失踪后释放资源有效的一生。这包括释放、double-frees等等。 |
| cwe - 772 |
(新)失踪后释放资源的有效寿命 |
|
抽象变化:404年添加为一个更具体的孩子,连同它的兄弟姐妹,cwe - 672,不正确的操作在一个资源过期或释放。cwe - 772是更具体的和可以处理内存泄漏,文件描述符疲惫,等等。 |
| cwe - 754 |
(新)不适当的检查异常情况 |
|
抽象变化:这可能有效地捕获cwe - 252(无节制的返回值),这是在2009年。 |
| cwe - 89 |
卫生处理不当的特殊元素中使用一个SQL命令(SQL注入) |
|
可能删除SQL和OS命令注入和替换为cwe - 77命令注入。 SQL注入是在2008年的超过5%的所有cf - 2009,和2008年的头号问题。 |
| cwe - 79 |
未能保存网页结构(“跨站点脚本编制”) |
|
2008年在5%或更多的cf - 2009。 |
| cwe - 78 |
(讨论)卫生处理不当使用特殊的元素在一个操作系统命令(OS命令注入) |
|
可能删除SQL和OS命令注入和替换为cwe - 77命令注入。 |
| cwe - 73 |
外部控制文件名或路径 |
|
可能被删除在草案1和并入母公司cwe - 642。然而,642年可能是过高水平,这个弱点已经是一个抽象的连续波人提名文件包含、符号链接,和路径遍历。 路径遍历2008年超过5%的所有cf - 2009。 |
| cwe - 352 |
跨站请求伪造(CSRF) |
| cwe - 362 |
(讨论)竞态条件 |
|
有些人知道这个。 |
| cwe - 209 |
(讨论)通过一个错误消息公开的信息 |
|
积极讨论,主要的严重性。 |
| cwe - 665 |
(讨论)不适当的初始化 |
|
有些人知道这个。可能缩小到CWE - 457:使用未初始化的变量,但也许“使用未初始化的数据”实际上是更重要的(一个新的CWE可能需要创建)。 |
| cwe - 285 |
(讨论)不当访问控制(授权) |
|
也许太高级了?但这没有很多好的孩子。 |
| cwe - 327 |
使用损坏或危险的密码算法 |
| cwe - 259 |
(讨论)硬编码的密码 |
|
如果另一个验证问题被接受,那么这应该删除吗?如果一个缓解采用“假设逆向工程可以工作”,这可能是一个好地方。 |
| cwe - 732 |
不正确的权限分配的关键资源 |
| cwe - 330 |
(讨论)使用随机值不足 |
|
这是一种根源的问题。它应该搬到移植吗? |
状态:删除(删除在这个版本的弱点) 这种状态有3项。
| cwe - 404 |
不当关机或释放资源 |
|
这是取代cwe - 772(失踪后释放资源有效寿命)和cwe - 672(过期或释放后使用的资源)。这将覆盖内存泄漏,文件描述符泄漏,use-after-free, double-frees等等。 有些人建议用低级代替这个条目,比如内存泄漏(cwe - 401)。内存泄漏的母公司是cwe - 772失踪后释放资源有效的一生,可以涵盖其他变体,如文件描述符和DB连接的疲劳。然而,一些问题如double-frees会错过;这些可能是开进cwe - 672过期或释放后使用的资源。 |
| cwe - 319 |
明文传输的敏感信息 |
|
替换为其母cwe - 311,失败对敏感数据进行加密,这将覆盖失踪在存储以及传输加密。 |
| cwe - 426 |
不可信的搜索路径 |
|
提出了消除由于有限的患病率。也可以卷起其母cwe - 642下,外部控制临界状态的数据,也在名单上。 |
状态:删除(缺点是考虑删除) 有1项状态。
| cwe - 494 |
(讨论)下载的代码没有完整性检查 |
|
建议删除的人说,大多数软件没有能力自行下载更新,所以cwe的患病率- 494很低。有一些CVE数据,但其发生率也低。 |
状态:添加(被添加在这个版本的弱点) 有4项状态。
| cwe - 311 |
(新)未能加密敏感数据 |
|
抽象变化:添加替换其孩子,cwe - 319明文传输;这个父还包括未能加密数据存储。 |
| cwe - 672 |
(新)过期或释放后操作资源 |
|
抽象变化:404年添加为一个更具体的孩子,连同它的兄弟姐妹,cwe - 772失踪后释放资源有效的一生。这包括释放、double-frees等等。 |
| cwe - 772 |
(新)失踪后释放资源的有效寿命 |
|
抽象变化:404年添加为一个更具体的孩子,连同它的兄弟姐妹,cwe - 672,不正确的操作在一个资源过期或释放。cwe - 772是更具体的和可以处理内存泄漏,文件描述符疲惫,等等。 |
| cwe - 754 |
(新)不适当的检查异常情况 |
|
抽象变化:这可能有效地捕获cwe - 252(无节制的返回值),这是在2009年。 |
状态:加法(除了弱点正在考虑) 有9项状态。
| cwe - 131 |
不正确的缓冲区大小的计算 |
|
可以取代通用母公司,CWE 119。 |
| cwe - 129 |
不当的验证数组索引 |
|
可以取代通用母公司,CWE 119。 |
| cwe - 120 |
缓冲区复制没有检查输入的大小(经典的缓冲区溢出) |
|
最基本的overflow-related错误。可以取代通用母公司,CWE 119。 |
| cwe - 134 |
不受控制的格式字符串 |
|
cwe - 119是可以考虑删除。 |
| cwe - 749 |
暴露危险的方法或函数 |
|
从CVE三级问题(0.4%到1.4%) |
| cwe - 302 |
认证绕过Assumed-Immutable数据 |
|
这是三个主要的孩子cwe - 287:不适当的身份验证,不建议,因为它太一般了。 非常常见的CVE身份验证问题,例如饼干说“管理员= true”。 |
| cwe - 306 |
没有认证的重要功能 |
|
这是三个主要的孩子cwe - 287:不适当的身份验证,不建议,因为它太一般了。 |
| cwe - 307 |
限制过度认证尝试失败 |
|
这是三个主要的孩子cwe - 287:不适当的身份验证,不建议,因为它太一般了。 |
| cwe - 434 |
不受限制的文件上传 |
|
很容易在CVE 2008年的前15名。有重叠cwe - 73和/或cwe - 642,抽象的问题尚未完全解决。 |
状态:抽象(缺点是考虑抽象的变化) 这种状态有5个条目。
| cwe - 119 |
(讨论)未能限制操作的范围内一个内存缓冲区 |
|
与一些额外的房间列表,它可能是更好的使用低级连续波而不是这一个。 这覆盖了超过5%的cf 2008 - 2009。“内存泄露”,一个单独的类别在CVE, 2008年1.5至4.9%的cf - 2009。 这可能是由cwe - 120(经典溢出)和cwe - 131(不正确的计算缓冲区大小)。 |
| cwe - 682 |
错误的计算 |
|
如果cwe - 131“不正确的计算缓冲区大小”被接受的更通用的父母cwe - 119,那么这是neeeded吗?还有其他地区,除了内存管理,这个弱点特别关键在哪里?(也许金融计算) 交替,可以取代2低级条目-整数溢出和cwe - 681:不正确的数值类型之间的转换。 |
| cwe - 77 |
卫生处理不当的特殊元素中使用一个命令(“命令注入”) |
|
SQL注入可以被认为是一个command-injection问题。如果采用cwe - 77,那么我们可以删除SQL注入和操作系统命令注入,以及cwe - 94“代码注入”,就用这个。 我们仍然需要处理XSS。 |
| cwe - 642 |
(讨论)外部控制临界状态的数据 |
|
cwe - 73(外部控制路径名)是一个孩子,目前也在评选名单之列。自cwe - 73年覆盖路径遍历,符号链接,射频识别,等等,删除73代替642可能过于抽象。然而,cwe - 642也适用于其他类型的问题(如cookie操作和其他web-heavy问题),所以这里不确定要做什么。 |
| cwe - 94 |
(讨论)未能控制生成的代码(代码注入) |
|
很多人把这个弱点当作高层家长SQL注入,XSS, OS命令注入,所以这里有一些重叠。然而,这个条目的一般目的是内部生成的代码内部执行,*不*代码或命令发送到下游组件。也许这应该完全删除由于混淆,但放在列入cw像95年和96年增长受欢迎。 |
状态:缓解(已经搬到移植的缺点) 有4项状态。
| cwe - 116 |
(讨论)不当的编码或逃避的输出 |
|
搬到气候变化部分。 |
| CWE-20 |
(讨论)不正确的输入验证 |
|
搬到气候变化部分。 |
| cwe - 602 |
(讨论)客户端执行服务器端安全 |
|
搬到气候变化部分。 |
| cwe - 250 |
(讨论)执行与不必要的特权 |
|
搬到气候变化部分。 |
状态:成员(成员的弱点当前列表和之前的草案) 有13个条目状态。
| cwe - 89 |
卫生处理不当的特殊元素中使用一个SQL命令(SQL注入) |
|
可能删除SQL和OS命令注入和替换为cwe - 77命令注入。 SQL注入是在2008年的超过5%的所有cf - 2009,和2008年的头号问题。 |
| cwe - 79 |
未能保存网页结构(“跨站点脚本编制”) |
|
2008年在5%或更多的cf - 2009。 |
| cwe - 78 |
(讨论)卫生处理不当使用特殊的元素在一个操作系统命令(OS命令注入) |
|
可能删除SQL和OS命令注入和替换为cwe - 77命令注入。 |
| cwe - 73 |
外部控制文件名或路径 |
|
可能被删除在草案1和并入母公司cwe - 642。然而,642年可能是过高水平,这个弱点已经是一个抽象的连续波人提名文件包含、符号链接,和路径遍历。 路径遍历2008年超过5%的所有cf - 2009。 |
| cwe - 352 |
跨站请求伪造(CSRF) |
| cwe - 362 |
(讨论)竞态条件 |
|
有些人知道这个。 |
| cwe - 209 |
(讨论)通过一个错误消息公开的信息 |
|
积极讨论,主要的严重性。 |
| cwe - 665 |
(讨论)不适当的初始化 |
|
有些人知道这个。可能缩小到CWE - 457:使用未初始化的变量,但也许“使用未初始化的数据”实际上是更重要的(一个新的CWE可能需要创建)。 |
| cwe - 285 |
(讨论)不当访问控制(授权) |
|
也许太高级了?但这没有很多好的孩子。 |
| cwe - 327 |
使用损坏或危险的密码算法 |
| cwe - 259 |
(讨论)硬编码的密码 |
|
如果另一个验证问题被接受,那么这应该删除吗?如果一个缓解采用“假设逆向工程可以工作”,这可能是一个好地方。 |
| cwe - 732 |
不正确的权限分配的关键资源 |
| cwe - 330 |
(讨论)使用随机值不足 |
|
这是一种根源的问题。它应该搬到移植吗? |
总结最近的前25名的讨论 日期:2010年1月5日 这是一个高级的总结讨论和反馈,到目前为止我们已经收到。我很抱歉我们的反馈我们已经收到。
- 技术资料
- 排名前25位的文档的结构
- 威胁模型
- 重叠/条目之间的抽象问题
- 优先级和排名
- 部分最有效的措施之一
- 建议增加/删除
技术资料意见使用技术资料主要是积极的。 推荐了几个新的配置文件——名单上和私下——包括:
- 教育
- 客户端软件和服务器端软件)
- 托管代码
- 移动设备
有一些担心最初提议概要文件:基于网络的,非托管和嵌入。这些概要文件之间有重叠;例如,嵌入代码可能提供基于网络的功能是用非托管代码写的。 目前还不清楚这种类型的重叠是有问题的。 可能的过程:
- 确定一个小数量的重要技术资料准备释放在最后的文档(2月初)。
- 每个概要文件定义了优先项目和使用自己的标准。
- 其他资料可以被添加到前25名,或单独发表,在最初版本之后。
下一个步骤:
- 斜方更新示例文档,以反映这些概要文件的使用。
- 斜方和前25名贡献者确定重叠是可以接受的,如果是这样,(如果有的话)需要采取什么行动来减少或澄清的重叠
- 排名前25位的贡献者可以请求(或由斜方请求)进一步专注于炼油一个或多个配置文件,包括优先级标准。本总结(后来部分将讨论一些细节。)
排名前25位的文档的结构假设使用的技术资料,没有支持25项分配给每个概要文件,然后将它们创建一个主列表中,最有可能由超过25项。 有坚实的支持建立一个单一的主列表- 25项然后提供单独的附件技术文件。每个概要文件可以使用特殊概要文件从主列表中排名的物品,和补充组处于(观察名单)条目可以被用来识别问题的关键,技术档案,即使他们并不重要足以让主列表。 下一个步骤:
威胁模型2009年排名前25位的假设一个简单的威胁模型:一个熟练并确定攻击者来说,完整性和机密性比拒绝服务更重要。 自2010年排名前25位的将使用多个配置文件,它可能更有意义,让每个概要文件来识别自己的威胁模型,假设这个概要文件的优先级标准要考虑模型的一种威胁。(例如,一个教育档案可以选择优先考虑基于学生易懂性的弱点,而不考虑这些弱点带来的现实威胁)。 鉴于今年多个概要文件的使用,以及去年的威胁模型并不总是适用,追求更详细的威胁模型可能会放弃了今年,可能除了主列表。 下一个步骤:
重叠/条目之间的抽象问题2009条目如CWE-20(输入验证不当)有大量的重叠与其他物品列表,XSS和SQL注入等。一些条目是一个非常高的水平,如不适当的授权,而其他人则在较低的水平。在某些情况下,前25将包括一个低级及其母公司(比如文件名的条目相关的外部控制和关键数据)。 这样的条目,可以通过一个或多个下列:
- 使用低级CWE条目(可能创建它们)
- 解决/规范情况下一个条目和其父母或祖父母都包括在2009年的列表。
- 暂缓条目相关的“根本原因”,可能改变他们尖端/监控名单的角色。
- 移动一些条目,如CWE-20,一个单独的部分,识别最重要的措施之一。
下一个步骤:
优先级和排名虽然主题不明确,似乎支持优先项目在今年的名单。 没有任何反对继续去年的强调流行的发生和严重程度判断包含在前25名。有些人提倡使用第三个因素,抓住了现实世界的攻击频率,利用问题。 也坚定支持使用定量方法排列物品,也最终确定哪些项目在前25名的列表。 斜方已经收到了几个提交,私下讨论列表,包含真实的弱点或脆弱性数据可能很难结合。例如,一些提交使用低级的连续波,和其他人使用高级的。CVE漏洞数据也可以;2008/2009的摘要结果发布。然而,它已被指出,CVE受到不可预测的波动,比如符号链接的问题在2008年因一个研究人员的努力。 如前所述,有可能每个技术概要文件可以使用自己的优先级方案。 下一个步骤:
- 在1月的第一个星期,横切将与伊丽莎白尼科尔斯PlexLogic来确定是否有合适的方法数据收集或投票支持定量分析。
- 主教法冠将调查使用攻击频率排名的另一个因素。
- 个人档案的支持者可以开始讨论标准特殊概要文件的排名。
部分最有效的措施之一有坚实的支持创建一个单独的部分覆盖重要措施之一——或“安全操作”——可以消除或减少的严重程度的许多项目在前25名。这样的气候变化可能包括低权限运行,输入验证,使用严格的审查安全特性而不是发明新技术,等等。 这种方法的一个好处是减少许多问题明显重叠在2009前25名。 这被非正式地称为“十大措施之一”,但没有一个明确的需要限制(或扩大)10项列表。 下一个步骤:
- 主教法冠将确定条目从2009年前25,可能更有意义搬迁缓解部分
- 主教法冠将创建一个示例部分包含样例移植,并征求输入这些建议。
- 排名前25位的贡献者可以提名最有效的措施之一
建议增加/删除贡献者有去年的2009名单,并要求该项目是否应该保留或删除。贡献者也从去年的“尖端”列表,以及其他的建议,然后问是否这些条目应该补充道。 最具争议的项目已经cwe - 209(错误消息信息泄漏),这是在2009年的前25位。支持者状态,即使它不是严重的,它通常是现实世界的攻击的一个重要组成部分,因此它应该被考虑。持异议者承认参与袭击但相信排名前25位的应该更注重cwe的关键性的弱点- 209是一个中间步骤。 有一些建议用于错误处理和/或错误检查,这其中有许多项提名。 添加/删除演化的讨论,很明显,2009年排名前25位的不适当阐明它的主要目的是什么,这将会影响哪些项目应该被添加或删除。 下一个步骤:
- 主教法冠将处理和总结的具体反馈已经收到
- 斜方和前25名贡献者将澄清前25位的目的(例如,一般教育/认知工具,或一个实用程序来帮助集中开发的软件保证需求)。
- 前25名贡献者将继续提供他们的反馈/建议更多的添加和删除
更多的信息是可用的,请编辑自定义过滤器或选择一个不同的过滤器。
|
