Re: [CVEPRI] Increasing numbers and timeliness of candidates
I was at that very first meeting too and I clearly remember that
timelineness -- as described by Pascal and not repeated here -- was an
I don't want to come off as attacking anything, but I do think we need to
keep a focus on timeliness, otherwise why are we really here? What we're
doing helps raise the bar for security because it begins the first real
effort to articulate all the vulnerabilities in a cogent forum. For it to
be of true value it must have an attribute of timeliness. It would not be
helpful if the best use of the CVE is as a sidebar to read up on how your
enterprise was last invaded/infested.
Until we have timeliness, we can never address Day 0 vulnerabilities which,
in many cases, are, retrospectively, the way many enterprise, and critical,
computing environments are compromised. Thus, from a critical
infrastructures standpoint the CVE is limited in its ability to serve as a
true reference because its lack of timeliness prevents it from being one.
Agreed that we can't try to be everything to everyone -- but without timely
entries we are of limited use to anyone. Even from a statiscal analysis
and/or data mining standpoint the lack of timeley info would skew any
potentially useful analysis. We have to drive a stake in the sand on what
the CVE will be now that it's growing up...
Kevin J. Ziese, Security Scientist
Global Defence & Space Group
Cisco Systems, Inc.
----- Original Message -----
From: "Pascal Meunier" <firstname.lastname@example.org>
To: "Steven M. Christey" <coley@LINUS.MITRE.ORG>;
Sent: Thursday, May 02, 2002 9:19 AM
Subject: Re: [CVEPRI] Increasing numbers and timeliness of candidates
> At 2:41 AM -0400 5/2/02, Steven M. Christey wrote:
> >Pascal Meunier said:
> >>References are nice, but the main goal of the CVE was to give a number
> >>to an issue so the issue could be discussed.
> >Only recently has the topic moved to "how quickly the issue could be
> >discussed." CVE was originally intended to deal with tools, which
> >have a much longer development cycle than vulnerability databases and
> >notification services.
> Then I've been under the wrong impression for several years, since
> the workshop on research with *vulnerability databases* where the CVE
> was first discussed. Timeliness was not an issue as long as you were
> dealing with legacy candidates (>6 months old). Now it is, and when
> discussing NIST's CVE recommendation you agreed with the statement
> that to consider "CVE as a timely and comprehensive service seems
> like a reasonable expectation". Moreover, you have a chicken-egg
> problem with regards to reserved candidates. People will reserve
> candidates only if the CVE is perceived as a timely point of
> reference and having a CVE number in initial references is desirable.
> If the CVE is to be something that identifies soldiers after the
> battle has long been over and when counting the dead, it's not nearly
> as useful as I was hoping it would be. Which is it going to be?
> (with apologies to Steve and the CVE content team who are working
> very hard already -- I sound ungrateful for their Herculean work, but
> I need to have this cleared out, and I need to know what I can
> reasonably expect from the CVE. I also wanted to provide public
> justification for Steve's efforts to make the CVE more timely, but I
> guess it has come out awkwardly more as an attack than the
> justification I wanted to provide)
> >As you and I also discussed in private, I
> >would like to get candidates out at least once a month. That means a
> >few days of editing, once a month. (As I said, I'm doing more
> >refinement now, too.) The 6 week delay for this last batch is
> >disappointing because it's 2 weeks overdue, but as you may recall from
> >the private emails, there were many reasons for those delays.
> What I recall from emails is that you were trying to release them
> every two weeks (it's been 3 times the expected delay). That much
> should be possible without "detriment to the broader work that MITRE
> is doing with CVE"?
> Pascal Meunier, Ph.D., M.Sc.
> Assistant Research Scientist,
> Purdue University