[CD] CD Proposal: VOTE (Voting Requirements)

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

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.