[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[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.