再保险:候选人编号方案

以利亚说:>唯一我担心candiate数字从来没有让它>工作组外…诅咒这个螺丝我们将使用候选人> >数字在我们的讨论和讨论将公开。我不认为真的有解决这个问题的办法,但候选人数字可能只有接触到那些想要观察的过程。也许我们可以提供一个“免责声明”或警告,他们应该只使用CVE编号。我认为“完全公开”候选人数字有几个目的。对我来说,早期的主要好处是漏洞信息的跟踪。例如,* Bugtraq版主可以使用自己的考号名称空间分配的帖子(让我们避免这种方法一会儿)的可行性。我认为大多数或所有报告应该参考CVE编号在第一个出版,因为报告往往是初选,通用漏洞的信息来源。它有助于获得*有*号报告,首次宣布脆弱性(说,供应商的安全分析团队)。因为我得到的是供应商认为他们有一个竞争优势在宣布新发现的漏洞在他们自己的报告,并可能不愿意放弃它。 If they aren't willing to give away such information (at least to the input forum), then there are 2 workarounds I can think of. Public candidate numbers are the easiest way to address this problem. A different mechanism might be a "secure channel" between MITRE and the advisory team which could result in a "conditional" assignment of a new CVE number. Probably the best way would be for the advisory team to post an initial "pre-advisory" to the Input Forum for a brief and timely discussion, and CVE number assignment. The benefits would be twofold: (a) all vendors would know of the vulnerability and be able to update their tools [which would immediately benefit *all* tool users], and (b) the first fully public advisory would have a CVE number. The greatest risk in having public candidate numbers is in the potential confusion caused by multiple numbering schemes. The CAN- prefix makes it clear to knowledgeable people that the vulnerability is "unreviewed," but the candidate number could become more widely used than the CVE number. We want to minimize this problem as much as possible, IMHO. If we decide to adopt a public candidate numbering scheme, then we need to make it clear to everyone, including the end users, that candidate numbers are in no way "official." - Steve