再保险:CNA规则公告

所有,我只是上传新版本的文档,包括最近的评论和反馈。https://github.com/CVEProject/docs/blob/gh-pages/cna/CNA%20Rules%20v1.1.3.docx克里斯棺材CVE团队- - - - - - - - - - -从原始信息:owner-cve-cna-list@lists.mitre.org [mailto: owner-cve-cna-list@lists.mitre.org]代表棺材,克里斯派:周三,10月12日2016年5:04点:Landfield,肯特B < kent.b.landfield@intel.com >;马尼恩艺术< 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条目需要出现。反馈的数量和水平给我留下了深刻的印象,提供了通过这个电子邮件线程。感谢所有人参与,特别是孩子和耶利哥的许多有用的想法和建议。 This is exactly the kind of feedback we were looking for. We will incorporate all of the comments into a marked up version of the CNA Rules document and try to post that to Github or something similar. We'll try to get this done before the next Board meeting. Regards, Chris Coffin The CVE Team -----Original Message----- From: 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需要做出抽象的决定并包含足够的信息来减少重复条目。——艺术