MEETING NOTES -- CVE TASK FORCE -- Baltimore

[Rob Kolstad <kolstad@ace.delos.com>]

Here are the minutes/notes of the discussion on CVE held on Sunday, May
9, from 13:00 to 18:00 EDT at the Hyatt Inner Harbor Hotel in Baltimore,
MD.

Please send corrections to <kolstad@delos.com>

RK

Welcome -- Alan Paller, SANS Institute Director of Research
Hello -- Rob Kolstad, SANS Institute Program Manager
    * About meetings
    * What we'll get from this meeting
	* Buy-in, success, validation, enhancement, Good Works
	* Notes distributed to all who participate 
	* About the amenities
	  * T-shirts
	  * 3:00 or so -- afternoon snack
	  * 5:40 or so -- break for dinner prep
	  * 6:00 dinner
    * How we'll conduct the meeting
	* Alternating presentations with discussions
	* Notes on screen -- please correct in real-time
		sent to: cve-review@linus.mitre.org
    * Roundtable introductions
	* Name, organization, short goal statement
	* Please put a little name card in front of you so
	  notes can reflect your name!

Matt Bishop -- Univ. California Davis -- available for consulting
	not available for meeting  bishop@cs.ucdavis.edu

Today's participants:

Steve Christey -- Mitre -- CVE designer  coley@mitre.org
Hugh McLean -- NIPC@FBI WashDC -- hmclean@fbi.gov 202-324-0318
	head of InfraGard
Russ Cooper -- Mr. NtBugtraq -- has a numbering organization
	for vulnerabilities  russ.cooper@rc.on.ca
Jeff Sebring -- Mitre -- jsebring@mitre.org 
Craig Ozancin -- Axent Tech. -- craoza@axent.com
Stephen Moore -- Mitre -- CVE User -- sjmoore@mitre.org
Andre Frech -- ISS -- Content validator for their security
	research database -- afrech@iss.net
Adam Shostack -- Bindview -- adam@netect.com
Elias Levy -- Mr. Bugtraq -- Security Focus --
	aleph1@underground.org
Dave Mann -- Mitre -- Meeting Organizer -- damann@mitre.org

==================================================================

About Mitre -- Jeff Sebring
	* Not for profit -- ``working in the public interest''
	* Incorporated 1957
	* Serves government (R&D) plus external customers
	* Both responding in a reactive way and pushing
	  new ideas in a proactive way
	* Debug, build, install, support systems
	* Also focus on integrating complex systems
	* No manufacturing arm
	* Operates three centers
	* 4,200 people; 300 people in computer security!
	* CVE: Outgrowth of internal security for Mitre networks
	* CVE Goal: achieve interoperability among security tools
	  from variety of vendors

About CVE -- Dave Mann
	* Big question: Does this make sense?  Is it reasonable?
	* CVE is a "dictionary" of vulnerabilities
	* Dictionaries should be authoritative and settle disputes;
	  they should capture consensus
	* We need your input; we will tell you what we are thinking
	* We are also consulting others who were unable to attend this
	  meeting
	* Working on technical front outside of Mitre in addition to
	  Mitre internal
	* CVE:
	     Enumerates and distinguishes all known vulnerabilities
	     Assigns standard unique name to each vulnerability
	     Exists independently of multiple perspectives
	     Publicly open and shareable, no restrictions on dist.
	     Simple numbers as names -- NOT a taxonomy
	     Entries are simple dictionary descriptions, not detailed
		database-oriented explications
	* Mitre is constructing and releasing the initial CVE
	* Mitre will maintain CVE for the foreseeable future
	  -- one year, at any rate
	* Mitre solicits feedback
	* Mitre publishes CVE on web site w/regular updates
	* Might draft "short lists" for product evals
	* Security community:
	    * Has provided feedback on content (and hopefully
	      will continue to do so)
	    * May include CVE as tool output, marketing lit,
	      educational materials, etc.
	    * Two levels of involvement: consultants; compliant
	      sites, databases, tools

Input Process for CVE ----------------------------------------

	* Mitre will establish electronic CVE input forum
	  to discuss CVE content
	* Does this list need to be "secure" or "open"?

Russ: We don't want to be like CARO is today.  Members
	discuss new viruses... promulgation is not a priority.
	Others outside the organization now do a better job.
	Let's try and incorporate the good parts of them.
Dave: Yes.  Market is more mature now.  Money counts now.
	Mitre wants CVE to be stable, with mature data (i.e., not
	necessarily hottest latest up-to-minute vulnerabilities)
Russ: CARO was easy to join (join if two members nominate).  I like
        that idea.  What about secure vs. open?
	[discussion evolves to individuals vs. corporate members]
Adam: I like models that include individuals.  But, organizational
	interests sometimes end up being pushed a bit too hard in
	results [like a white paper cited during the discussion].
Russ: I like an exclusionary black-ball-like mechanism
	[discussion of personalities]
Russ: I like (smart) (security) vendors represented in some of
	my world.
Steve: I'm not sure I want a *moderated* mailing list as the forum.
Russ: I think the egos can make moderation required.
Elias: I like non-moderated with people stepping in "as necessary."
Andre: [proposes a notion of two classes of contributors -- one
	is moderated; one not]
Adam: I see two questions.  What is the purpose of the people in
	this room plus the additional contributors?  what is the
	role of organizations vs. individuals?
Dave: Group's focus is to determine what goes into the CVE.
Russ: And a second form for administrative CVE issues?
Dave: Org vs. individual is a harder question.  I can't answer
	that right now.
Adam: Knee jerk is we want individuals to participate.  We
	those who have history of useful contributions to field,
	mailing lists, conferences, etc.  We should attempt to
	maintain distinction that individuals represent themselves,
	not their org (i.e., when they change jobs).  I suggest
	open archive of the mailing list.
Russ: Vendors will be more apt to adopt the CVE system if they
	can get quick answers to their questions.
Craig: I'm here both representing my company and as an individual
	representing my interests in security.  I think [CVE] should
	be open in terms of sharing ideas.
Andre: We won't be discussing competitive or sensitive issues.
Dave: Right, the data is mature.  We won't be going into proprietary
	secrets.
	[Revelation that CVE entries include "credit" to discoverer.]
Russ: What if there's 5000 people on the mailing list and a
	large group (e.g., 1000) respond to a submitted form?
Dave: We don't know the answer to that yet.
Adam: [proposes a one week "comment period" for people to check if
	CVE candidates are similar to previous entries]
Steve: ... Lots of issues on whether an entry goes into the CVE,
	including levels abstraction and validation/confirmation.
Dave: I'm leaning toward a smaller number of people on the mailing
	list.
	[The mailing list is *NOT* supposed to duplicate *bugtraq.]
	[discussion on how to add/remove from mailing list and
	 who the target audience is.]
Summarize: Limited membership, limited participation, archives
	open -- general agreement in group
Craig: Don't open it too far!
Stephen: Smaller groups are more nimble.  Want timeliness.
	[expect 250-350 new vulnerabilities per year]
---
Dave: Mitre makes decision when forum group doesn't quickly
	come to (near-)consensus.

Roles of Consultants -----------------------------------------

Dave: Consultants: actively contribute, silence means assent,
	access to pre-release info, get recognition.
	[discussion of protecting discussion data, pre-release
	data in context of fast public disclosure]
Adam: One of my long-term goals is to use this group for
	sharing.
[how often is CVE released?]
Steve: monthly isn't frequent enough
	[more than weekly is too often]
	[simple editing is easy to get out in a hurry]
Russ:  Advocate real-time updates.
Steve: We don't know how the CVE will be used. Daily updates
	from an end-user perspective is probably too frequent.
Elias: It takes 1-2 weeks to flush out vulnerabilities, anyway.
---
Dave: [re: Recognition] 
Adam: Individuals? Orgs?
	[Hackers finding more vulnerabilities to there's
	more CVE entries.]
Stephen: CVE should reference expert locations, not be an
	end-all for definitive information (a pointer)
[several: agreement]
Dave: Mitre is taking on risk (liability).  "You're saying
	bad things about [us]" is basis for potential lawsuit.

Compliance Defined -------------------------------------------

Dave:  [Vendors'] literature, web sites, databases, etc. can
	be compliant.  It's binary.  Vendors will refer to CVE
	numbers for vulnerabilities (or provide mappings from vendor
	terms to CVE numbers).

	[Many: What are the metrics?]

Dave: We won't be *verifying* mappings.
Dave: Websites should link back to Mitre site.  Mitre will
	provide return links.
	[Consultant? Advisory board? Editorial board?]
	[Compliance seems to be a harsh word]

Publishing Mechanisms ----------------------------------------

* Flat format electronic text available
* Copyrighted so changes not allowed though copying is
* Notifications to the usual places

Projected Release Schedule -----------------------------------

* 26 May -- consultants comments due
* 2 June -- CVE final draft
* 2 June -- CVE input forum established to discuss new vuln's
* 2-23 June -- trial run for input process
* 23 June -- web site release
* Entries, search for keyword
* Only some "informal names" like "smurf attack" -- but not
  vendor-specific names
* Links to vendors are to "homepage"-like places, not
  vulnerability-by-vulnerability links

Tool Evaluation Issues ---------------------------------------

* Complete CVE not intended for tool evaluation
     * No measure of relative importance of vulnerabilities
     * Not a "wildlist" (i.e., no rankings here)
* Some organizations might make subset lists for their own use
* Mitre discussion with NIAP the generation of short lists
  for domestic and international evaluations
* What issues should be considered for tool evaluation?
	[long discussion of what can be used vs. not]

==============================================================
Hugh departs meeting.
==============================================================

Issues from the group that need addressing this afternoon:

Dave: Wants feedback
Russ: I want an early number so people can refer to it
	early during discussions
Russ: The CVE Maintenance Extensions is becoming a bit complex
Russ: All CVE entry versions should remain in the database forever
Jeff: Let's get some closure on the controversial discussions
Craig: I want to discuss CVE decision-making -- the levels/
	abstraction
Craig: I like the idea of date of discovery
Stephen: Don't want to have CVE become "bloated" -- proponent
	of minimalist CVE, with applications on top of the framework;
	want closure on issues.  I want good timeliness but I want
	to make sure we "get it right".
Andre: I want to exchange trusted messages with Mitre to see if
	I can get a CVE number.  Exchanges can become public later.
Adam: Details: "what is a vulnerability", use of certain keywords,
	numbering scheme issues
Elias: Distribution mechanisms/frequency
Steve: Content decisions, content meta-decisions, how do we
	maintain/update/modifications for CVE entries?

==============================================================

Steve Christey -------- Content Decisions and Data Management

Review of CVE and CMEX ---------------------------------------
["completeness"]

* Entry includes name and description (only)
* Broad def'n of vulnerability to accommodate diverse security
  policies
* 681 vulnerabilities so far (CVE Version 199904290013)
  (showed in five categories for CMEX, which is the pure CVE
  with added impurities with a new name)
Elias: CMEX externally available?
Dave: No.
Steve: Well, yeah, but it's searchable (???)
* CVE is the name/description list
* search data includes the thesaurus -- and can point to a
  CVE item (or items)
* CMEX data is visible to a few people but not end-users
---> TOPIC OF DISCUSSION
* CMEX data includes: categories, date created, date modified,
  references, keywords, keyword index, thesaurus terms, bad terms
* CVE is currently unix-centric, network-centric, neo-centric,
  high risk-centric
* CVE is not so complete for: NT, local vuln's, config probs,
  older vuln's, client-only denial-of-service
* between now and public release
  * Older vulnerabilities still going in based on feedback
  * New vulnerabilities going in
* After release
  * new vulnerabilities
  * old vulnerabilities that are somehow interesting
* Mapping vulnerabilities into old vulnerabilities

CVE Vulnerability Definition ---------------------------------

"A CVE Vulnerability is a state in a computing system (or set
thereof) that can help an entity to conduct unauthorized activities
on the system(s)."

* Broad -- encompasses "diverse but typical" policies
* Includes:
   * Software faults (all the usual suspects)
   * Denial of service
   * Information hiding (limits tracking abilities)
   * Information gathering
   * Point of entry (is a primary point of entry for crackers)
* N O T   I N C L U D E D
   * Viruses (lots of them)
   * Inherent flaws
   * Exploits (i.e., Back Orifice is not included cuz it's
     put in after some initial vulnerability)
   * Unexploitable problems
   * Some "information policy" problems (e.g., exporting
     wrong filesystem)
	[These are guidelines, not mathematical rules]
Elias: Vis a vis "finger", common sense prevails.  Of
	*course* it tells you who's logged on, that's its
	job.

Content Decisions --------------------------------------------

* CVE includes just a bit of info -- a dictionary entry,
  not an encyclopedia
* Avoid controversy
* Minimizing encoding info within CVE/CMEX
* End user (sysadmin) perspective
* "Consensus" driven approach
* Version number YYYYMMDDHHMM (GMT)
  * cited when relevant
* High cardinality vulnerabilities grouped
* Level of abstraction depends on category
* Software faults -- distinguish between bugs in different lines
  of source code, among OSes as appropriate
* [more ...]
* Vulnerability descriptions do change as understandings change
* Mitre doesn't want to keep track of "sublists" of the big list
* "Counting vulnerabilities" is a game that must be played carefully
  by those doing comparisons
* Potential problems
  * CVE should be "stable" and "current" -- must address errors
  * Duplicates, insufficient detail, Level-of-abstraction changes,
    deprecating/deleting entries, missing entries for older vuln's
  * References

Mappings -----------------------------------------------------

* Trying to find a way to map, e.g., vendor databases to/from
  CVE entries.  Might be equal, subsumed, subsetted, or intersected
  (which is most bad and should be avoided as much as possible)
* Vendors can use "GENERIC" comments for matches that are:
  unmatched, not applicable, insufficient info, "other";
  different level of abstraction
* Search utilities exist that aid mechanical mapping
* Hackers can use missing-coverage tables to hack sites (*sigh*)

CVE Modification & Input process -----------------------------

* Additions [already discussed at length]
  * Issues include: source, discussion, trust, abstraction,
    uniqueness, "new"-ness
  * Exclusion for: duplicate, not CVE-applicable, subsumed
    by others
  * Voting? Moderator final decision? Record reasons?
* Deletion -- 
* Merging -- 
* Splitting -- 
   --> all these need to be hammered out

----------------------------------------------------------------------
* Discussion on number-assignment
Russ: If I get a number instantly I can use it for discussion.
   We can put it into the CVE database at our leisure -- or it
   is abandoned.
	[discussion:  lots]
	[discussion:  nonconsecutive numbers is OK]

[Discussion adjourned for dinner.  Resumed at the local
micro-brewery].

Questions on the floor:
---> Please tell us what that means "release to public"?
---> Numbering system -- when?


   ====================================================================
         /\      Rob Kolstad              www.delos.com
      /\/  \     kolstad@delos.com        15235 Roller Coaster Road
     /  \   \    +1 719-481-6542          Colorado Springs, CO  80921
   ====================================================================