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

RE: [TECH] Diligence Levels for Candidate Assignment

Steve,

A good first draft, but for some 'je ne sais quoi' reason, this document
left me wanting. :-)

- What are suggested procedures for reviewing the existing candidate and CVE
lists to determine if a similar issue already exists? Perhaps a checklist
would be helpful.

- Which candidates or entries are prone to encompass larger issues? For
example, our recent advisory on the mstream DDoS was clustered into a DDoS
candidate, and a search on mstream wouldn't have cut it. Perhaps a short
list of the virus, DDoS, backdoor, etc. entries that may not come up during
a search would be appropriate.

- When in doubt, is there an impartial and trusted source available for
verifying decisions or resolving questions?

Thanks for your help. Keep up the good work.
Andre

> -----Original Message-----
> From: Steven M. Christey [mailto:coley@LINUS.MITRE.ORG]
> Sent: Monday, May 22, 2000 8:37 PM
> To: cve-editorial-board-list@lists.mitre.org
> Subject: [TECH] Diligence Levels for Candidate Assignment
>
>
> All,
>
> The following document is a first draft.  It defines 4 "diligence
> levels" for people who request candidates for their initial public
> announcements of new vulnerabilities.  The idea is to give extra
> leeway to "trusted" and/or "reliable" sources while giving any
> interested party a chance to request a number if they wish.  Feedback
> is requested.  Note that Russ, Bill, and Elias did not contribute to
> this draft, so any glaring errors are entirely mine.
>
> So far, each requester has established themselves as having Diligence
> Level 2, and they are likely to achieve Level 3 if they continue to
> request candidate numbers.  Some entities regularly publicize new
> vulnerabilities but may be unreliable; if they request candidates,
> they might start at Level 1 and possibly drop to Level 0 if they do
> not practice due diligence.
>
> - Steve
>
>
>
> Diligence Levels for Candidate Assignment for New Security Problems
> -------------------------------------------------------------------
> Last updated: May 22, 2000
>
> Each candidate requester is assigned a particular *diligence level*
> which identifies how many unpublished candidates they may request, and
> a maximum number of insufficiently verified, active candidates that
> they are allowed to have at any one time.
>
>
> Definitions
> -----------
>
> The *DISCOVERER* of a security problem is the person who either (a)
> first publicizes the problem to an established public forum, or (b) is
> credited for discovery of the problem by the affected vendor.  The
> publication is referred to as an *ANNOUNCEMENT*.  The *REQUESTER* is
> either the discoverer or the vendor who is requesting a new candidate.
>
> An established public forum provides some feedback mechanism, whether
> moderated or unmoderated.  Such public forums include mailing lists
> such as Bugtraq or NTBugtraq, Usenet newsgroups, or product-specific
> mailing lists.  A web page or FTP site is not considered a public
> forum itself.
>
> A requester performs an action *CONSISTENTLY* if they perform it at
> least 3 times, and perform it properly at least 60% of the time.
>
> An *UNKNOWN* requester has not published an announcement, or can not
> prove that they have published an announcement.
>
> A *RELIABLE* requester consistently announces security problems that
> are (a) acknowledged by the software vendor, or (b) pass the CVE
> review process and become official CVE entries.
>
> An *ACCURATE* requester consistently announces candidates that (a) are
> not duplicates of existing candidates or entries, (b) satisfy the CVE
> vulnerability or exposure definition, and (c) are presented at the
> correct CVE level of abstraction (based on published content
> decisions).  If the request is accurate for the initial report, but
> subsequent analysis reveals new information that forces a change in
> the level of abstraction, then the initial request is still considered
> accurate.
>
> *UNPUBLISHED* candidates have not been announced yet (and/or MITRE has
> not been notified of the announcement).
>
> A candidate is *UNVERIFIED* if (a) it has been announced, (b) the
> vendor has not acknowledged the problem, (c) the original requester
> can not provide at least 2 independent sources that confirm the
> problem, and (d) the candidate has not received at least 3 ACCEPT
> votes by the Editorial Board.
>
>
>
> Diligence Level 0
> -----------------
> Max. unpublished candidates: 0
> Max. unverified candidates: 0
>
> If a requester is consistently unreliable or inaccurate, then they may
> be denied future requests for candidates until they re-establish
> reliability and accuracy.  A requester remains at Level 0 for 3 months
> or twice the average frequency of their announcements, whichever is
> greater.
>
> Level 0 only applies to requesters who have announced 3 or more new
> security problems.
>
>
> Diligence Level 1
> -----------------
> Max. unpublished candidates: 1
> Max. unverified candidates: 1
>
> This is the default level for unknown requesters, or those for whom
> reliability and accuracy can not be established yet.
>
> If the requester has announced 3 or more new security problems in the
> past, but they have not requested a candidate before, then they can
> request a higher diligence level and provide evidence of it
> (e.g. links to previous announcements and vendor acknowledgements, and
> associated CVE names if available).
>
>
> Diligence Level 2
> -----------------
> Max. unpublished candidates: 2
> Max. unverified candidates: 3
>
> The requester must satisfy these requirements:
>
>   - they have announced at least 3 new security problems
>
>   - they consistently follow all steps of the Candidate Request
>     Process
>
>   - they are consistently reliable
>
>   - either:
>     - they are consistently accurate, or
>     - they have included candidate numbers in fewer than 3
>       announcements
>
> More than 2 unpublished candidates may be assigned if (a) they occur
> in the same software package, (b) the requester has demonstrated a
> basic understanding of CVE content decisions, and (c) the content
> decisions dictate that a lower level of abstraction is necessary.
>
>
> Diligence Level 3
> -----------------
> Max. unpublished candidates: 3
> Max. unverified candidates: 5
>
> The requester must satisfy these requirements:
>
>   - they have included candidate numbers in at least 3 initial
>     announcements of new security problems
>
>   - they consistently follow all steps of the Candidate Request
>     Process
>
>   - they are consistently reliable
>
>   - they are consistently accurate
>
> More than 3 unpublished candidates may be assigned if (a) they occur
> in the same software package, and (b) CVE content decisions dictate
> that a lower level of abstraction is necessary.
>
Page Last Updated or Reviewed: May 22, 2007