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

RE: [CVEPRI] CVE candidate issues - handling new candidates



Just a few initial thoughts,


1)  I think that as the CVE initiative becomes more well-known, i.e., tools
reflect CVE mappings, Security Sites begin to reflect CVEs, as Securityfocus
is doing (search works well by the way!), users will have more knowledge
through exposure.
I would think a brief concise statement along with the CAN # would help,
such as "CVE# pending research and validation" would keep the confusion to a
minimum.

Perhaps each site that reflects CVE-compatability needs to have a blurb on
the CAN/CVE process with a "for more details" link to the MITRE CVE site.

4) Add the CAN# as soon as possible after the public announcement or
possibly implement a procedure where somewhere between the coordination with
the vulnerable software vendor and public announcement, a CAN# is applied.

Still lots of discussion to do and agreement to reach, hopefully some will
come out of next week's telecon.

-mike

-----Original Message-----
From: Steven M. Christey [mailto:coley@LINUS.MITRE.ORG]
Sent: Wednesday, October 27, 1999 9:06 PM
To: cve-editorial-board-list@lists.mitre.org
Subject: [CVEPRI] CVE candidate issues - handling new candidates


All:

Now that CVE is public, we need to address some issues related to CVE
candidates.


--------------snip---------8<---------8<----------------

*** AN APPROACH ***

Here's what I suggest as an approach for dealing with new
vulnerability information at this time.  It allows us to move forward
on some issues that can be acted upon now, while taking the proper
time to resolve longer-term issues.

0) We treat backlog issues independently of the issues related to new
   information.




1) We take steps to educate the public about candidates now.
   Education could take the form of (a) web pages on the CVE web site
   describing the differences between candidates and CVE entries, (b)
   short statements in any forum where candidate numbers are used
   (e.g. advisories or mail messages), and (c) additional
   clarifications by Board members in various forums where the subject
   comes up.



2) With me continuing to act as sole CNA, I could interact with Board
   members who have a desire to obtain candidate numbers for new
   information.

   - Submissions would be limited to new vulnerabilities ONLY (for
     now)

   - The submission MUST be ready for public dissemination (or already
     publicly known)

   - Submitters should only do submissions for vulnerabilities which
     they are the first to announce or publicize (this reduces "noise"
     of many Board members sending me the same submission).  An
     alternate approach would be to have different submitters with
     different expertise (e.g. Windows NT vs. Unix) to focus on a set
     of problems

   - The submission includes a short description and references,
     i.e. looks very much like a candidate proposal

   - I then give them a candidate number (or numbers) to use

   - The candidates are packaged up and proposed to the Board list on
     a weekly basis (to reduce traffic on the list)

   - Interested Board members can request to be emailed directly when
     new candidates arise, instead of waiting for the weekly posting

   This allows for some consistency across candidates while reducing
   duplication and other problems.  Restricting the request for
   candidates to new information, *and* to the original source of the
   information, reduces the effort required in this first step.

   This also allows me to continue to "schedule" and cluster content
   decision debates accordingly so that we avoid discussing too many
   technical issues at the same time.  As various issues are resolved
   (e.g. database design, content decisions, etc.) these experiences
   could be used to begin a "training manual" for other CNA's.

   By having the candidate submitters send information to me in a
   "near-candidate" format, it allows prospective CNA's to begin to
   identify and address their own issues.

3) We provide a candidate status page on the CVE web site, including
   the capability to download candidate information in various formats
   (e.g. text, HTML, CSV).  The status information should be detailed
   enough to allow Board members to view which candidates they've
   voted on.

4) We delay creating a forum for the Board to discuss non-public
   information until some of these other issues have been sufficiently
   addressed.  But with the public being educated, most first-time
   advisories could at least include candidate numbers.


What do you think about this approach?

 
Page Last Updated: May 22, 2007