MEETING NOTES -- CVE TASK FORCE -- Baltimore
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,
Please send corrections to <email@example.com>
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
* 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: firstname.lastname@example.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 email@example.com
Steve Christey -- Mitre -- CVE designer firstname.lastname@example.org
Hugh McLean -- NIPC@FBI WashDC -- email@example.com 202-324-0318
head of InfraGard
Russ Cooper -- Mr. NtBugtraq -- has a numbering organization
for vulnerabilities firstname.lastname@example.org
Jeff Sebring -- Mitre -- email@example.com
Craig Ozancin -- Axent Tech. -- firstname.lastname@example.org
Stephen Moore -- Mitre -- CVE User -- email@example.com
Andre Frech -- ISS -- Content validator for their security
research database -- firstname.lastname@example.org
Adam Shostack -- Bindview -- email@example.com
Elias Levy -- Mr. Bugtraq -- Security Focus --
Dave Mann -- Mitre -- Meeting Organizer -- firstname.lastname@example.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
* Working on technical front outside of Mitre in addition to
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
* 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
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
[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
[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
[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)
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
* Links to vendors are to "homepage"-like places, not
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/
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 ---------------------------------------
* Entry includes name and description (only)
* Broad def'n of vulnerability to accommodate diverse security
* 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?
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,
* 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
* 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
[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
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
* 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,
* Exclusion for: duplicate, not CVE-applicable, subsumed
* 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
[discussion: nonconsecutive numbers is OK]
[Discussion adjourned for dinner. Resumed at the local
Questions on the floor:
---> Please tell us what that means "release to public"?
---> Numbering system -- when?
/\ Rob Kolstad www.delos.com
/\/ \ email@example.com 15235 Roller Coaster Road
/ \ \ +1 719-481-6542 Colorado Springs, CO 80921