[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Proposal: CVE candidate/approved numbering scheme
All: Based on all the emails that were generated discussing the candidate numbering plus my review of other fields, I've come up with an approach that's fairly similar to Russ' last email. Let us know what you think! - Steve Summary ------- - candidate numbers should be public - to avoid multiple naming schemes, candidate numbers are the same as CVE numbers, except they are prefaced by CAN- instead of CVE- - a Candidate Numbering Authority (CNA) is given the privilege to assign candidate numbers (e.g. editorial board members or established OS/application vendors) - candidates are not put in the CVE until they are approved - candidate status/etc. is kept in CMEX - candidate numbers are automatically generated and accessed via a restricted web interface (ultimately) Details ------- Candidate numbers should be public and should be assignable on proposal, not after vetting, to allow tracking of early information and advisory numbering. But we don't want 2 separate naming schemes, because the candidate number could become a de facto standard instead of a CVE number. So the candidate numbers must be as similar as possible to the CVE numbers, if not exactly the same. Numbers should also be simple for (relatively) easy human readability. BUT - we want to have a "stable" way of assigning candidate numbers, some rough guarantee that a candidate number will likely have a one-to-one relationship with the approved CVE vulnerability. Each candidate number should have a good chance of being the same as a CVE number. We define a Candidate Number Authority (CNA), who has the capability to reserve a candidate number. There are more CNA's than editorial board members. E.g., established application/OS vendors would be CNA's, but they probably wouldn't be editorial board members. We can name an entity a CNA if they're accepted by a percentage of editorial board members; they must show continued accuracy or effectiveness in proposing candidates that are later accepted. Any member of the editorial board is automatically a CNA. We can extend CNA privileges to other entities after CVE public release. Only a CNA can assign candidate numbers. This approach forces "casual" vulnerability announcers to go through a CNA (e.g. *Bugtraq) to get a real number. It's possible that an entity will decide to act solely as a CNA, filtering information coming from non-CNA entities. CNA's will present the candidate name/status in a standardized way, and will encourage others to do so. CNA's assign a candidate number, *but* (a) follow established content decisions to determine appropriate level of abstraction, etc.; (b) attach a "pending status" to the candidate number; and (c) state that the number is a candidate ONLY, include a link/reference to MITRE CVE, and update all information sources if/when the candidate is approved. MITRE gives CNA's the ability to reserve a number (or block of numbers, e.g. for *Bugtraq) through limited web site access or another mechanism. Each candidate has 5 CMEX fields associated with it: - name - creation date - id/name of the CNA who proposed it - status - status explanation (formatted text) The name is an encoding of a year and a unique number N for the Nth candidate proposed that year, prefaced by CAN-. Including the year limits how big N would need to be, improving memorability. Example: CAN-1999-0001 (The assumption is that no more than 10,000 candidates would be proposed per year. I think it's dangerous to assume we won't reach 1000 on occasion.) Any CNA can obtain and announce a candidate name. When a candidate is first proposed, its status is PENDING. The CNA obtains the name from MITRE, perhaps through an automatic "name reservation" system. The candidate is added to CMEX. The candidate is *NOT* put in the CVE itself. Anybody searching the CVE will *not* find the candidate number. This, in combination with the CAN- prefix, reinforces the notion of the number as "unofficial." A separate interface (e.g. a different web page) is provided to allow a person to review a candidate's status. After a candidate has been reviewed, its status becomes one of: - APPROVED. Candidate has a 1-to-1 relationship with the approved CVE entry, and is assigned the name of CVE-1999-0001, i.e. the CAN prefix is replaced by CVE. The candidate is added to the CVE. References to the CAN- number (e.g. in advisories) should be modified to reflect the CVE number, where possible. - MODIFIED. The candidate has been substantially modified during review (e.g. it is split or merged). It retains the CAN- name. The status explanation identifies the nature of the modification (e.g. SPLIT into CVE-1999-0012 and CVE-1999-0013). This candidate number is NOT APPROVED and is not included in the CVE; however, other candidates may be added to the CVE as a result, and this should be reflected in the status explanation. References to the CAN- number (e.g. in advisories) should be modified to reflect the CVE number, where possible. - DENIED. The candidate is not a CVE vulnerability, or it is a duplicate, or subsumes/is subsumed by other vulnerabilities. Status explanation identifies the reason for denial. CVE vulnerabilities that result from APPROVED or MODIFIED candidates include back-pointers (i.e. references) to the candidate number(s). Each CNA should prevent MODIFIED or DENIED status as much as possible, by closely following content decision guidelines. In cases where content guidelines are not clear, CNA's should get advice from the editorial board. CNA's that continually produce MODIFIED or DENIED candidates may not retain status of CNA, because they are "muddying the waters" and diluting the effectiveness of the naming. At a later date, an approved CVE vulnerability may become: - OBSOLETE. Content decisions are changed, errors are fixed, etc. Status explanation identifies the reason for obsolescence, and may use either the MODIFIED language (split/merge) or DENIED language (not-a-vulnerability, etc.) The vulnerability remains in the CVE.