RE: Candidate numbering scheme

[Craig Ozancin <cozancin@axent.com>]

> -----Original Message-----
> From:	Andre Frech [SMTP:afrech@iss.net]
> Sent:	Friday, May 14, 1999 4:11 PM
> To:	'Aleph One'; 'Steven M. Christey'; cve-review@linus.mitre.org
> Subject:	RE: Candidate numbering scheme
> 
> Team,
> 
> I've been quiet on the number scheme until now, but I agree with Elias.
> Two
> sets of numbers introduce a lot of overhead in cross referencing and could
> confuse people. Even worse, the candidate numbers may be used in lieu of
> the
> final CVE index.
> 
> There are at least three alternatives:
> 
> - Submit the new vulnerability for review to the cve-review group. If a
> suitable CVE already exists, then you could pass that value to the members
> for consideration. The moderators would return an acknowledgement of the
> existing CVE or the new number within a set time.
> 
> - Submit new vulnerabilities that need new CVEs to the cve-review group.
> This method minimizes gaps due to duplicate or existing requests, but
> introduces human intervention and a necessary delay.
> 
	[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]
> > Sent: Friday, May 14, 1999 4:32 PM
> > To: Steven M. Christey; cve-review@linus.mitre.org
> > Subject: Re: Candidate numbering scheme
> >
> >
> > On Fri, May 14, 1999 at 02:53:37PM -0400, Steven M. Christey wrote:
> > >
> > > Elias said:
> > >
> > > >The only concern I have is that the candiate numbers never make it
> > > >outside the working group...  Of curse this screws the
> > fact we will be
> > > >using candidate numbers during our discussion and the
> > discussions will
> > > >be public.
> > >
> > > I don't think there's really a way around this, but the candidate
> > > numbers might only be exposed to those people who want to
> > observe the
> > > process.  Perhaps we could provide a "disclaimer" or
> > warning that they
> > > should only use the CVE number.
> > >
> > > I think having "fully public" candidate numbers serves several
> > > purposes.  To me, the primary benefit is for early tracking of
> > > vulnerability information.  For example, the *Bugtraq
> > moderators could
> > > use their own candidate number namespace to assign to
> > postings (let's
> > > avoid the feasibility of such an approach for a moment).
> >
> > That is exactly what I *don't* want. 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
> > Fingerprint EE C9 E8 AA CB AF 09 61  8C 39 EA 47 A8 6A B8 01
> >