再保险:候选人编号方案

团队,我一直安静的计划数量直到现在,但是我同意伊莱亚斯。两组数字带来大量开销在交叉引用,可以迷惑人们。更糟糕的是,候选人数字可以用来代替CVE指数。至少有三个选择:提交审查的新漏洞cve-review组。如果一个合适的CVE已经存在,那么你可以考虑将该值传递给成员。版主会返回一个确认现有的CVE或一组时间内新号码。——提交新的漏洞,需要新的cf cve-review组。这种方法最大限度地减少差距由于重复的或现有的请求,但引入了人工干预和必要的延迟。——提交新的漏洞,需要新的cf自动CVE数字生成器。这种方法产生即时响应未经人工干预,但有可能介绍了CVE索引的差距。 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分>:Steven m . Christey;cve-review@linus.mitre.org >主题:Re:候选人编号方案> > >在星期五,5月14日,1999年在02:53:37PM -0400年,史蒂芬·m·Christey写道:> > > > Elias说:> > > > >我唯一的问题是,candiate数字从未让外面> > >工作小组……的诅咒这个螺丝>的事实,我们将> > >使用候选数字在我们的讨论和> > > >将公众的讨论。> > > >我不认为真的有解决这个问题的办法,但候选人> >数字可能只有接触到那些想>观察> >的过程。也许我们可以提供一个“免责声明”或>警告他们> >应该只使用CVE编号。> > > >我想在“完全公开”候选人数字有几个> >目的。对我来说,早期的主要好处是> >漏洞信息的跟踪。例如,* Bugtraq >版主可以> >使用自己的考号名称空间分配>帖子(让我们> >避免这种方法一会儿)的可行性。> >这正是我*不*。第二个我们开始使用这些“候选”名称> * BUGTRAQ你可以忘记任何>使用CVE编号。 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 8 c 39 EA 47 6 A8 B8 01 >