|
|
|
[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. >
|
||||
