|
|
|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [CD] CD Proposal: VOTE (Voting Requirements)
As promised many times over the past few months, here is the first new content decision for discussion and approval. The following content decision (CD) is related to requirements for voting on candidates. While we've been voting all along, a number of issues came up during the last Editorial Board meeting which are addressed here. Feedback is requested. Modified CD's will be posted until the voting period begins. For a refresher on the content decision adoption process, see http://cve.mitre.org/Board_Sponsors/archives/msg00848.html CD Proposal Date: 6/12/2000 Voting Period: 7/10/2000 Final Decision: 7/24/2000 Background notes ---------------- VOTE.1, VOTE.3, VOTE.4, VOTE.5, and VOTE.9 all formalize much of my existing approach to vote processing. VOTE.2 implicitly allows MITRE Board members to cast a vote. This is different than the original voting requirements agreed to by the Board in September 1999; as discussed at AXENT and in subsequent summaries posted to the Board list, a vote by a MITRE Board member (besides me) should count as a valid vote. The rate that the Board has been adding entries is only slightly faster than the rate at which new problems are announced, which doesn't bode well for legacy candidates. So it makes sense for the other MITRE Board members to be able to help out, provided their voting activities remain independent of me. VOTE.2 also says that the discoverer's own vote does not count. This came out of the AXENT meeting. VOTE.6 effectively states that other MITRE Board members may cast votes. VOTE.7 addresses another concern that was raised at the AXENT meeting, related to individuals voting on problems in competitor products. I believe that if one organization acknowledges a security problem, then it should be OK for a competing organization to vote on it. VOTE.8 formalizes the "one organization, one vote" principle, which becomes more important as the number of multiple-member organizations grows. VOTE.10 does 2 things. First, it formalizes my current approach of allowing at least 2 weeks after initial proposal before moving to Interim Decision. Second, it explicitly allows for "emergency" cases in which people may want to vote and approve a CVE number as soon as possible. The voter guidance reflects the discussions at AXENT. It assumes that approved content decisions are well-documented and available to Board members, so some of that guidance will not apply until CD's have been approved and made easily available on the web site. ************************************************************************ CD:VOTE (Voting Requirements) ************************************************************************ Type: PERVASIVE Version: 1.0 Proposed: N/A Approved: N/A Short Description ----------------- A candidate must satisfy minimum voting standards before it can become an official CVE entry. Definitions ----------- All definitions are informal. The "Candidate Numbering Authority" (CNA) is the entity that is responsible for assigning candidate numbers to security problems, and ensuring that candidates satisfy all approved content decisions. As of June 3, 2000, MITRE is the only CNA. The "CVE Editor" is the individual(s) who makes Interim and Final Decisions to ACCEPT or REJECT candidates. As of June 3, 2000, the CVE Editor is Steve Christey. A "voting member" is any member of the Editorial Board who votes on a candidate, not including the CVE Editor. A "Quorum" is the minimum number of votes that must be cast in order to move the candidate to the Interim and Final Decision phases. Application ----------- A candidate must satisfy all of the following voting requirements before an Interim or Final Decision can be made: 1) The candidate must not be affected by any content decisions (CD's) that have not been adopted by the Editorial Board. If it is, then it must not be moved to Interim or Final Decision until the associated content decisions have been reviewed and approved by the Board. 2) To be ACCEPTed, a candidate must garner enough votes to establish a Quorum. A Quorum is established if any of the following occur: - At least 3 voting members ACCEPT the candidate, not including the original discoverer of the problem - *Or*, at least 2 voting members ACCEPT the candidate, and the vendor has publicly acknowledged that the problem exists 3) There must be more ACCEPT votes than REJECT votes for the candidate. The Editor should work with disagreeing voters to establish consensus, if possible. If consensus cannot be achieved in a timely fashion, then the Editor may make the decision based on approved content decisions and voter feedback. 4) The Candidate Numbering Authority (CNA) and the Editor are responsible for interpreting whether a REJECT vote is contradictory to approved content decisions, and must make the voter aware of the contradiction. 5) If a voting member casts a REVIEWING vote, then the Editor may delay an Interim or Final Decision for at least 2 weeks after the vote was cast. After the 2 week time period, the Editor may extend the delay, or disregard the REVIEWING vote and move the candidate to Interim Decision. 6) Members who belong to the CVE Editor's organization may vote. The Editor may only "vote" as part of the Interim or Final Decision. 7) If a voting member votes on a candidate for a security problem found in a product owned by a competing organization, then that member's vote cannot be counted towards the Quorum, unless the competing organization has publicly acknowledged the problem. 8) If multiple individuals from the same organization vote on the same candidate, only one of those votes may be counted towards the Quorum. 9) The CVE Editor must determine that further discussion of the candidate will not affect the decision with respect to the candidate, *or* it is in the best interests of CVE to make a decision. 10) After its initial proposal, the candidate must not be moved to Interim Decision for at least 2 weeks, unless it receives unanimous approval by at least 6 voting members. Guidance -------- 1) A voting member should only ACCEPT a candidate if: - they believe that the related problem really exists - they believe that the problem is not a duplicate of existing candidates or entries 2) A voting member is encouraged, but not required, to review the candidate with respect to approved content decisions. 3) A voting member should vote on candidates according to approved content decisions, instead of their own personal preferences. Informally, a voting member should not REJECT a candidate if all of the following apply: - the candidate is not a duplicate of other candidates/entries - it satisfies all approved content decisions (CD's) - it satisfies CVE's vulnerability/exposure definition Examples: if a voter doesn't believe a candidate should be included in CVE because they wouldn't include it in their own database, but an approved inclusion CD specifically allows it, then the voter should not vote to REJECT. Or, if the voter prefers to use a level of abstraction that is contrary to approved abstraction CD's, the voter should not vote to REJECT or RECAST. A voter may use an ABSTAIN or NOOP vote instead. 4) A voting member should not vote for a candidate that is related to a security problem in a competitor's product, unless the competitor has acknowledged that the problem exists. Dissenting Opinions ------------------- Upon approval of this CD, this section will include a summary of any dissenting opinions.
|
||||
