回复：候选编号方案

> -----原始消息----->来自：Andre Frech [smtp：afrech@iss.net]>发送：1999年5月14日，星期五4:11 pm>至：'Aleph One';'史蒂文·克里斯蒂（Steven M. Christey）；cve-review@linus.mitre.org>主题：回复：候选编号方案>>团队，>> >>>>到目前为止，我一直对数字方案保持安静，但我同意Elias。>两个>一组数字在交叉引用中引入了很多开销，并可能使人们感到困惑。更糟糕的是，可以使用候选数字来代替>>最终CVE索引。>>至少有三个替代方法：>>  - 向CVE -REVIEW组提交新漏洞以进行审查。如果>合适的CVE已经存在，则可以将该值传递给成员>以供考虑。主持人将在设定的时间内返回>现有CVE或新号码的确认。>>  -   - 向CVE -REVIEW组提交需要新CVE的新漏洞。>此方法可最大程度地减少由于重复或现有请求而引起的差距，但是>引入了人类干预和必要的延迟。 > [Craig Ozancin] Yes this sounds resonable. > - Submit new vulnerabilities that need new CVEs to an automatic CVE number > generator. This method produces an instant response without prior human > intervention, but potentially introduces gaps in the CVE indexing. > > Respectfully submitted, > > Andre Frech > X-Force Security Research > afrech@iss.net > > Internet Security Systems, Inc. > 678.443.6241 / fax 678.443.6479 > www.iss.net > > Adaptive Network Security for the Enterprise > > > -----Original Message----- > > From: Aleph One [mailto：aleph1@underground.org]>>发送：1999年5月14日，星期五下午4:32>>>>：史蒂文·M·克里斯蒂（Steven M. Christey）；cve -review@linus.mitre.org >>主题：回复：候选编号方案>>>>>>>>>>>>>>>>>>>>>> >>在1999年5月14日，02:53：37 pm -0400，史蒂文·M·克里斯蒂（Steven M. Christey）写道：>>>>>>>>>>>>>>>>>>>>>>>>>>> Elias说：>>>>>>>>>>>>>>我唯一担心的是，Candiate号码永远不会使其在工作组之外...>在我们的讨论期间使用候选号码，>>讨论将>>>>公开。>>>>>>>>>我认为这实际上没有解决方案，但是候选人>>> >>数字可能只会暴露于那些想要观察>>>>过程的人。也许我们可以提供“免责声明”或>>>警告他们>>>>仅应使用CVE号码。>>>>>>>>>我认为拥有“完全公开”的候选号码可以提供多个>>>>。对我来说，主要好处是早期跟踪>>>漏洞信息。例如， *bugtraq >>主持人可以使用自己的候选数字名称空间分配给>>帖子（让我们避免使用这种方法的可行性）。>>>>这正是我 *不想要的。 The second we start using > > these "candidate" names in *BUGTRAQ you can forget about anyone > > using the CVE number. They still continue to use the > > "candidate" number. > > > > > > > > I think that most or all advisories should reference a CVE number in > > > their first publication, since advisories are often a primary, > > > universal source of vulnerability information. It helps to > > get *some* > > > number into advisories that announce a vulnerability for the first > > > time (say, a vendor's security analysis team). The sense that I get > > > is that vendors believe they have a competitive advantage in > > > announcing discovery of new vulnerabilities in their own advisories, > > > and may not be willing to give this up. 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 > > > > > > > -- > > Aleph One / aleph1@underground.org > >http://underground.org/>> keyID 1024/948FD6B5>>指纹EE C9 E8 AA CB AF 09 61 8C 39 EA 47 A8 A8 A8 6A B8 01>>>>>>>>>>>>>