[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.

- 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
>
Page Last Updated or Reviewed: May 22, 2007