再保险:指望cf

嗨,好久不见…;-)(顺便说一句,失业和兴趣)

问题# 1“脆弱性”的定义,问题# 2是“枚举”这个词的理解,国际海事组织…但是我非常过时了,因为我看到现在“E”代表“曝光”,不是“枚举”…叹息,很难变老。

例如,我看到似乎是用在不同的产品不同的CVE编号为相同的弱点…这拉大cf不必要。漏洞,对于所有意图和目的是一样的前一个漏洞,得到一个新的CVE因为产品想要测试场景和场景B…这同样膨胀不必要的cf。

“一开始”…我们谈到需要1 CVE编号代表整数溢出,或另一个解析不足…显然从未停留。但同样,似乎有些供应商想分配一个CVE每“威胁”,它也应该从未停留。

我不知道>每年10000新漏洞,至少在我认为“新漏洞”。这是一个大量的行代码,但是如果你计数在Android应用程序的漏洞,那么我也可以看到这个数字非常低。也许问题不是与漏洞,而是与曝光? ?

我记得在某个时候申请cf或多或少由保证知道组织,但这是假设的问题进行验证,可以证明不是必需的。缺乏资金,映射(或审查)肯定不是得到它所需要的关注。如果是,也许可以挽救许多cf或召回…但是今天的方式使用它们,要么导致尴尬,或重大投资的人用自己的cf。

有一件事我希望看到一个“评论”功能用于说2(或更多)不同的cf代表“或多或少”一样的…然后文档的方式来解决这个问题在不同的平台/产品/供应商…

我想说更多,但是我真的要熟读到底要“曝光”。

欢呼,

拉斯-以前NTBugtraq编辑…目前饲养鸡和建设一个便宜的房子。

来自:owner-cve-editorial-board-list@lists.mitre.org [mailto: owner-cve-editorial-board-list@lists.mitre.org]代表威廉姆斯,詹姆斯K
发送:周三,2012年3月07日下午3:45的时候
:cve-editorial-board-list@lists.mitre.org
主题:再保险:指望cf

肯特说什么话她都同意。

我希望看到一个重要变化是添加“评论”功能在每个CVE页面:cve.mitre.org。评论功能由编辑委员会成员可以使用(和其他审查个人?)添加信息,如修正,额外的引用,供应商反应等。

感谢和问候,
肯·威廉姆斯,导演

C一个技术产品漏洞响应团队
C一个技术业务单元操作

wilja22@ca.com- 816-914-4225

来自:owner-cve-editorial-board-list@lists.mitre.org[mailto: owner-cve-editorial-board-list@lists.mitre.org]代表Kent_Landfield@McAfee.com
发送:周三,2012年3月07日下午1:53
:cve-editorial-board-list@lists.mitre.org
主题:指望cf

所有人,

我们有问题CVE报告已知问题,但明显更多,可以很容易地破坏CVE识别如果任其发展的有效性。

在ITSAC会议上我们讨论了这个未来的漏洞报告车间和后续软件的漏洞报告天保证事件一个月后。(有行动项目的后者,我没有意识到已经完成…)

我刚刚有一个非常有关讨论cf的有用性来衡量今天的漏洞,其价值的衰退如果这种趋势仍在继续。讨论围绕cf的数量确定的准确性相比报道社区作为一个整体。如果我们看CVE编号,看来漏洞的数量高2008年以来一直在下降。这是一个相当重要的错误。我们都知道,这是不准确的。漏洞没有下降,他们正在增长,而不是下降了30%。

供应商社区,这些趋势,而关于潜在影响。首先,我们使用CVE漏洞研究数据库作为主要参考。CVE Id被权威的过去。它内部使用方式漏洞记录了产品之间的信息交流和研究分析团队之间。由于数量的下降,这意味着我们被迫在全球提供识别和沟通CVE提供过去。更多的专有ids越来越规范。

更严重的问题是它是什么显示的公司高管。

“如果漏洞自2008年以来下降了30%,为什么我需要资金安全人员和努力我吗?我看到斜方是自2008年以来每年报告一个总体下降但是你们一直来我说的威胁是更糟,我们可能在相同的相对情况下当恶意软件飙升几年过去…”

对于那些积极工作在这样的环境下,我们不知道漏洞有自2008年以来下降了30%。恰恰相反,我们的内部数据显示越来越趋势类似于上升了30%。赛门铁克也报告了类似的趋势。

的一个主要问题是,斜方资金不应该是什么。在多个场合我们一直要求目标类的产品漏洞来源被认为是最重要的,哪些应该被监视。视图的目标和监测越来越小,资金水平或降低。

一度努力的目的是为了覆盖所有公布的漏洞,可以以某种方式证实。多年来现实中设置,这是一个资源密集型操作。这样努力的焦点已经减少了报道是什么保证cf可以被指定为类型的产品最重要的编辑委员会的参与者和他们的赞助商。这给了一个人工的数量的现有的漏洞和脆弱性社区外所公认。

另一个问题是CVE格式本身。有一个活跃的讨论格式限制。CVE-YYYY-NNNN CVE格式。这意味着,目前我们不能拥有超过10000 cf报道一年。我们看到内部,我们已经在那里了。

还有CVE过程的局限性。重点是英语只有虽然有些非美国漏洞得到分配。CVE不支持国际社会和软件编写的英语geo-centric地区不包括。虽然这并没有一个关心美国软件供应商,有一个很大的区域软件编写的主要新兴市场。这些由CVE漏洞识别。

考虑到这些限制,似乎是时候找出如何解决问题的创造性的方式。我们知道的约束。有什么我们可以做,以增加斜方人员在某些方面会有帮助吗?我可以看到格式问题是一个相当简单的攻击,但覆盖问题是最相关的。或者我们应该忽略它,慢慢的CVE社区和供应商腐烂…

想法吗?

肯特Landfield
导演内容策略、架构和标准

McAfee |一个英特尔公司
5000年总部博士。
75024年德克萨斯州普莱诺

直接:+ 1.972.963.7096
手机:+ 1.817.637.8026
网络:www.mcafee.com