[TECH] Diligence Levels for Candidate Assignment

["Steven M. Christey" <coley@linus.mitre.org>]

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.