再保险:CNA规则公告

我完全同意艺术和肯特在说什么。在我看来,CVE的角色应该专注于命名的漏洞,让谈话开始。其他程序(例如,NVD)可以基于CVE条目需要出现。反馈的数量和水平给我留下了深刻的印象,提供了通过这个电子邮件线程。感谢所有人参与,特别是孩子和耶利哥的许多有用的想法和建议。这就是我们正在寻找的反馈。我们将把所有的评论融入CNA规则文档的标记版本,发布到Github或类似的东西。我们会尽量在下次董事会会议前完成这项工作。问候,克里斯棺材CVE团队- - - - - - - - - - -从原始信息:owner-cve-editorial-board-list@lists.mitre.org [mailto: owner-cve-editorial-board-list@lists.mitre.org)代表Landfield肯特B发送:周一,10月10日10:00 AM 2016:艺术·马尼恩< amanion@cert.org >;帕默< pmeunier@cerias.purdue.edu >;耶利哥< jericho@attrition.org >;的孩子叫Nandakumaraiah < cbn@juniper.net > Cc: cve-cna-list < cve-cna-list@lists.mitre.org >;cve-editorial-board-list < cve-editorial-board-list@lists.mitre.org >主题:Re: CNA规则宣布艺术,你写道:在我看来,CVE的作用是识别/名称漏洞,并没有进一步。NVD一样,其他下游用户可以基于CVE。当然CVE需要做出抽象的决定并包含足够的信息来减少重复条目。我十分同意CVE的力量在于,它是一个简单的方法命名的漏洞。其他人应该建立在它作为他们的用例。 --- Kent Landfield +1.817.637.8026 On 10/10/16, 9:28 AM, "owner-cve-cna-list@lists.mitre.org on behalf of Art Manion"  wrote: On 2016-10-10 05:32, Pascal Meunier wrote: > I agree with Brian, it makes sense to have one ID for a flaw in the > specification of a protocol, and multiple IDs for vendor implementations > with different code bases, even if they happen to have made similar > mistakes. I think Kurt's suggestion to cross-reference them "(this is > related to the following CVEs: Z/X/Y)" would be helpful although not > necessary. Noting the disagreement about level of abstraction, I suspect that beyond individual opinion, different vulnerability analysis/management use cases prefer different abstractions. VRDX-SIG at FIRST has a proposed answer for this, which is basically a protocol (working title: vxref) for relationships between vulnerability IDs.https://www.first.org/resources/papers/conf2015/first_2015_-_manion-_uchiyama-_terada_-_vrdx-sig_20150619.pdf所以可以说CVE-X CVE-Y的子集。或类似的。如果一家使用协议,用户可以建立一个图表的id。vxref不仅限于CVE id。的世界里,最低,每年14 k公开的漏洞,来处理不同的抽象或跨一家不仅仅是有用的,它是必要的,除非一个人一家将覆盖整个世界的使用。在我看来,CVE的作用是识别/名称漏洞,并没有进一步。NVD一样,其他下游用户可以基于CVE。当然CVE需要做出抽象的决定并包含足够的信息来减少重复条目。——艺术