A Progress Report on the CVE Initiative

1
A Progress Reporton theCVE Initiative

• Robert Martin
• Steven Christey
• David Baker
• The MITRE Corporation
• June 27, 2002

2
Outline for A Progress Report on the CVE
Initiative

• Motivation
• Implementing CVE
• The CVE List
• Candidates
• Content Decisions
• The Editorial Board and Advisory Council
• CVE Compatibility
• Challenges and Opportunities

3
Many Motivations for Getting on top of
Vulnerabilities
4
Vulnerabilities Have Been Found in Almost Every
Type of Commercial Software There Is
Sample of Vulnerabilities Announced in 1999 2000
5
Difficult to Integrate Information on
Vulnerabilities and Exposures
6
Finding and sharing vulnerability information has
been difficult The Same Problem, Different
Names
The adoption of CVE Names by the Security
Community is starting to address this problem
Along with the new rule, Whoever finds it, gets
a CVE name for it
Which has been caused by the rule, Whoever finds
it, names it
7
The CVE List provides a path for integrating
information on Vulnerabilities and Exposures
CVE-1999-0067
8
FBI/SANS Institute 2001 Top Twenty uses CVE names
yet another step down
the policy road
http//www.sans.org/top20.htm
9
CVE is Even Being Used to to Compare and
Contrast products
10
Outline for A Progress Report on the CVE
Initiative

• Motivation
• Implementing CVE
• The CVE List
• Candidates
• Content Decisions
• The Editorial Board and Advisory Council
• CVE Compatibility
• Challenges and Opportunities

11
The Common Vulnerabilities and Exposures (CVE)
Initiative

• An international security community activity led
  by MITRE focused on developing a list that
  provides common names for publicly known
  information security vulnerabilities and
  exposures.
• Key tenets
• One name for one vulnerability or exposure
• One standardized description for each
  vulnerability or exposure
• Existence as a dictionary rather than a database
• Publicly accessible for review or download from
  the Internet
• Industry participation in open forum (editorial
  board)
• The CVE list and information about the CVE effort
  are available on the CVE web site at
  cve.mitre.org

2223 approved entries, 2419 being voted on, 4500
under analysis, 100-150 new/month
12
The CVE Strategy
Commercial S/W Products Update and Fix Sites
Update Mechanisms
Unreviewed Bugtraqs, Mailing lists, Hacker
sites
Discovery
Policy
time
Security Products
Reviewed Advisories CERT, CIAC, Vendor
advisories
Methodologies Purchasing Requirements Education
Scanners, Intrusion Detection, Vulnerability
Databases
13
Example CVE helping to make Detailed Product
Comparisons
Network Computing Article Vulnerability
Assessment Scanners (1/8/2001)
14
CVE email Lists have an International readership
Representing 2200 registered email subscribers
15
Outline for A Progress Report on the CVE
Initiative

• Motivation
• Implementing CVE
• The CVE List
• Candidates
• Content Decisions
• The Editorial Board and Advisory Council
• CVE Compatibility
• Challenges and Opportunities

16
Where the CVE List comes from
? 2,500 3,900 1,100 900
info
study
17
CVE Growth
Status (as of June 26, 2002)

• 2223 entries
• 2419 candidates

18
Outline for A Progress Report on the CVE
Initiative

• Motivation
• Implementing CVE
• The CVE List
• Candidates
• Content Decisions
• The Editorial Board and Advisory Council
• CVE Compatibility
• Challenges and Opportunities

19
Identifying Known VulnerabilitiesThe CVE
Submission Stage

• Sources provide MITRE with their lists of all
  known vulnerabilities
• MITREs CVE Content Team processes submissions

20
Candidate Stage Assignment

• Assign new number (CAN-YYYY-NNNN)
• YYYY is the year in which the number was
  assigned NNNN is a counter for that year

CAN-YYYY-NNNN

• Backmap internal IDs mapped to candidate names,
  sent back to provider
• Submissions removed

21
Candidate Reservation Process
400 CANs reserved
Reserving and coordinating CANs requires a
process change for all parties.
22
Many organizations are reserving CVE names and
using them in their alerts and advisories
To-date, CVE names have been included in initial
advisories from ISS X-Force IBM Rain
Forest Puppy _at_stake BindView HP
CERT/CC SGI COMPAQ Microsoft Ernst
Young eEye CISCO Rapid 7 NSFOCUS
Sanctum SecurityFocus Red Hat VIGILANTe
Apache Apple
http//www.redhat.com/support/errata/RHSA-2001-150
.html
23
Candidate Stage Proposal Through Final Decision
24
Entry Stage
25
Outline for A Progress Report on the CVE
Initiative

• Motivation
• Implementing CVE
• The CVE List
• Candidates
• Content Decisions
• The Editorial Board and Advisory Council
• CVE Compatibility
• Challenges and Opportunities

26
Content Decisions

• Explicit guidelines for content of CVE entries
• Ensure and publicize consistency within CVE
• Provide lessons learned for researchers
• Document differences between vulnerability
  views
• Three basic types
• Inclusion What goes into CVE? What doesnt, and
  why?
• Level of Abstraction One or many entries for
  similar issues?
• Format How are CVE entries formatted?
• Difficult to document
• Its like trying to grasp wet corn starch
  (Board member)

Incomplete information is the bane of consistency
- and content decisions!
27
Example Content Decision SF-LOC(Software
Flaws/Lines of Code)
Create separate entries for problems in the same
program that are of different types, or that
appear in different software versions.

• Older versions of this CD distinguished between
  problems of the same type
• Split-by-default approach generated too many
  candidates
• Also unfair to vendors with source code or
  detailed reports
• Once produced 8 candidates where other tools and
  databases would have created only 1 vulnerability
  record
• Affected by amount of available information
• Especially source code and exploit details
• For all candidates affected by SF-LOC, see
• http//cve.mitre.org/cgi-bin/cvekey.cgi?keywordCD
  SF-LOC

28
SF-LOC Examples
6 failure points

• CAN-2001-0019 is clearly different than
  CAN-2001-0020
• But a single patch fixes both problems
• CAN-2001-0019 could be 1, 2, or 6 vulnerabilities

29
Why CAN-2001-0019 Could Identify 1, 2, or 6
Vulnerabilities

• 3 different source code scenarios
• Without actual source, cant be sure which
  scenario is true
• Even with source, there are different ways of
  counting
• Multiple format string problems are especially
  difficult to distinguish

if (strcmp(cmd, "show") 0) if
(strcmp(arg1, "script") 0) strcpy(str,
long_input) show_script(str) elsif
(strcmp(arg1, "archive") 0)
strcpy(str, long_input) show_archive(str)
elsif (strcmp(arg1, "log") 0)
strcpy(str, long_input) show_log(str)
elsif (strcmp(cmd, "clear") 0) if
(strcmp(arg1, "script") 0) strcpy(str,
long_input) show_script(str) elsif
(strcmp(arg1, "archive") 0) strcpy(str,
long_input) show_archive(str) elsif
(strcmp(arg1, "log") 0) strcpy(str,
long_input) show_log(str)
strcpy(arg, long_input) if (strcmp(cmd, "show")
0) process_show_command(arg) elsif
(strcmp(cmd, "clear") 0)
process_show_command(arg)
if (strcmp(cmd, "show") 0) strcpy(str,
long_input) process_show_command(str) elsif
(strcmp(cmd, "clear") 0) strcpy(str,
long_input) process_clear_command(str)
30
Outline for A Progress Report on the CVE
Initiative

• Motivation
• Implementing CVE
• The CVE List
• Candidates
• Content Decisions
• The Editorial Board and Advisory Council
• CVE Compatibility
• Challenges and Opportunities

31
CVE Editorial Board

• Includes mostly technical representatives from 35
  different organizations including researchers,
  tool vendors, response teams, and end users
• Reviews and approves CVE entries
• Discusses issues related to CVE maintenance
• Holds monthly meetings (face-to-face or phone)
• Maintains publicly viewable mailing list archives
  cve.mitre.org/board/archives

cve.mitre.org/board/boardmembers.html
32
Editorial Board Roles, Tasks, and Qualifications

• Minimum Expectations
• Tasks for All Members
• Technical Member Tasks
• Liaison Tasks
• Advocate Tasks
• Emeritus Tasks
• Recognition of Former Members
• Roles for MITRE

cve.mitre.org/board/edroles.html
33
CVE Senior Advisory Council Objectives and Roles

• ...The CVE Council is established to ensure
  that the CVE program receives the sponsorship,
  including funding and guidance, required to
  maximize the effectiveness of this program ...

Council Roles

• Act as a catalyst for CVE and related activities.
• Assure funding for the core CVE activity over the
  long term including outreach to Government
  organizations and agencies.
• Discuss community needs and possible new CVE
  services.
• Promote the adoption of CVE at the strategic
  level.
• Business planning prioritization.
• Discuss CVE and related security policy
  implications for the Federal Government.
• Identify CVE related materials resources for
  use by Government CIOs and senior managers.

34
CVE Senior Advisory Council Members

• Co-Chairs
• John Gilligan, CIO of the USAF, and Co-chair of
  the Architecture/Interoperability Committee of
  the CIO Council
• Sallie McDonald, GSA Assistant Commissioner
  Office of Info Assurance and Critical
  Infrastructure Protection
• Participating Organizations
• Department of the Treasury
• Department of Energy
• Department of Labor
• Department of Health and Human Services
• Internal Revenue Service
• National Institute of Standards and Technology
• Critical Infrastructure Assurance Office
• National Infrastructure Protection Center
• Office of Management and Budget

• GSA
• ASD/C3I
• DISA
• Air Force
• NSA
• Intelligence Community
• NASA

35
Outline for A Progress Report on the CVE
Initiative

• Motivation
• Implementing CVE
• The CVE List
• Candidates
• Content Decisions
• The Editorial Board and Advisory Council
• CVE Compatibility
• Challenges and Opportunities

36
What does CVE-compatible mean?

• CVE-compatible means that a tool, database, web
  site, or security service can speak CVE and
  correlate data with other CVE-compatible items
• CVE-compatible means it meets the following
  requirements
• Can find items by CVE name (CVE searchable)
• Includes CVE name in output for
  each item (CVE output)
• Explain the CVE functionality in
  their items documentation
  (CVE documentation)
• Provided MITRE with vulnerability
  item mappings to validate the
  accuracy of the product or services CVE
  entries
• Makes a good faith effort to keep mappings
  accurate

cve.mitre.org/compatible/requirements.html
37
New CVE Compatibility Procedure (as of 18 June
2002)

• Consists of two parts (phase 1 and phase 2)
• Phase 1 - Compliance Declaration
• Item listed on Compatibility page and quote
  posted if given
• Phase 2 - Compliance Questionnaire
• Submitted response is evaluated by MITRE
• Upon concurrence with Questionnaire
• Questionnaire response put on CVE site mapping
  accuracy evaluated
• Upon completion of mapping accuracy evaluation
• Use of the CVE-Compatible logo granted
• Vendor free to refer to product or service as
  CVE-Compatible
• Status
• Draft questionnaire developed/tested (takes 3
  days to do)
• sample questionnaire using CVE Web site created
  as example
• alpha- beta-tests conducted with
  MITRE/Editorial Board
• Also discussed at length with 30 organizations
  w/positive responses
• Revised Compatibility pages to support new
  processes

38
Examples of CVE-compatible itemsThe ICAT
Metabase
CVE-names
http//icat.nist.gov
39
Where CVE-compatible Items Have Come From
and Where the New Ones Are Coming From
(as of 25 June 2002)
40
Timeline of CVE Compatibility Declarations
(as of 18 June 2002)
41
Several Parts of the Federal Government Have
Called for the Use of CVE and CVE-Compatible
products
Furthermore, preference should be given to
products that are Compatible with the Common
Vulnerabilities and Exposures (CVE) list.
.
Federal departments and agencies should 1. give
substantial consideration to ...
CVE-compatible products and services. 2.
periodically monitor their systems for
applicable vulnerabilities listed in ... CVE 3.
use CVE in their descriptions and
communications of vulnerabilities
http//www.acq.osd.mil/dsb/tfreports.htm http//cs
rc.nist.gov/publications/drafts/Use_of_the_CVE.PDF
42
Outline for A Progress Report on the CVE
Initiative

• Motivation
• Implementing CVE
• The CVE List
• Candidates
• Content Decisions
• The Editorial Board and Advisory Council
• CVE Compatibility
• Challenges and Opportunities

43
Challenge Improving the Naming Scheme

• Some benefits with the current naming scheme
• Compact
• Candidate/entry status encoded within the name
• Most CAN-YYYY-NNNN will become CVE-YYYY-NNNN
• Removes debate about what a good name is
• Some issues
• Changing a CAN to a CVE incurs maintenance costs
• Differences not obvious to casual users
• Year segment can be misunderstood as year of
  discovery
• Name is not atomic in most search engines, thus
  difficult to find
• Maximum 10,000 candidates per year (CAN-10K
  problem)
• Once public, names must not disappear without
  explanation
• Deprecated entries, rejected candidates... even
  typos
• Mappings from old to new names

Any change to the CVE naming scheme will impact
many users.
44
Managing the Scope of the CVE List

• What issues should be included?
• Exposures (CDDEFINITION)
• e.g., running finger
• Highly controversial topic before CVE was even
  public
• Beta software (CDEX-BETA)
• Online services / ASPs (CDEX-ONLINE-SVC)
• Client-side DoS (CDEX-CLIENT-DOS)
• Vague vendor advisories (CDVAGUE)
• Malicious code (viruses, Trojans)
• Configuration problems
• Challenges in abstraction
• Default passwords 1 CVE, or hundreds?
• Blurry lines between policy, security, and
  environment
• Large-scale analyses, e.g. PROTOS
• Voting how much confidence is needed for
  official CVE entries?
• Timeliness Fast and noisy or slow and stable?
• Intrusion events that do not map to
  vulnerabilities

45
Applicability of CVE to IDS
CVE IDSes

• Vulnerabilities and exposures
• System states
• Atomic entities
• Easier to classify
• Tools less varied
• Similar levels of granularity
• Easier to match across tools
• Many public databases
• Known and provable vulnerabilities

• Exploits, detects, decodes, anomalies,
  reconnaissance, probes, scans, malware...
• Events
• Hybrid entities
• Harder to classify
• Tools more varied
• Multiple levels of granularity
• Harder to match across tools
• One public database
• Bad cut-and-paste between signatures, scans for
  incorrect vulnerability reports

46
CIEL (Common Intrusion Event List)

• Standardize names for IDS events
• Use lessons learned from CVE
• Handle multiple levels of abstraction
• Ease of use
• Independent of the methods used to detect the
  event
• Past Activities (2001)
• Draft CIEL with almost 40 high-level entries
  created by MITRE
• Effectively a draft taxonomy
• Too complex
• Did not achieve exhaustiveness and mutual
  exclusiveness
• CIEL Working Group
• First meeting in March 2001
• Part of the CVE Editorial Board
• Structure, membership, and process TBD
• Current CIEL
• Names formed from attributes

47
CVE in Incident Handling

• Current Activity Summaries
• Which vulnerabilities are being actively
  exploited?
• Incident Reports
• CVE clarifies which vulnerability was exploited
• Simplifies data collection from multiple sources
• Share incident data across teams
• Share data across language barriers

48
Responsible Disclosure and CVE A Case Study

• CVE analysis includes distinguishing between
  similar issues
• Reporters who reserve CVE candidates must follow
  good disclosure practices to minimize errors
• When reporter and vendor do not work closely
  together
• Multiple CVEs assigned to the same issue
• reporter describes symptom, vendor describes the
  problem
• Inaccurate, incomplete, or unverified reports
• When vendors do not acknowledge the vulnerability
• Less likely that the Editorial Board will accept
  a candidate
• Too resource-intensive to verify every report
• When vendors do not include sufficient details in
  advisories
• Can be difficult to tell which vulnerability was
  fixed
• Change logs can be vague
• Even credits arent always enough!
• Source diffs (when available) may be insufficient

49
The CVE Strategy
(as of 18 June 2002)
Where are we?

• Adding CVE names broached with 13 groups.

Commercial S/W Products Update and Fix Sites
Update Mechanisms
Unreviewed Bugtraqs, Mailing lists, Hacker
sites
Discovery
Policy
time
Security Products
Reviewed Advisories CERT, CIAC, Vendor
advisories
Methodologies Purchasing Requirements Education
Scanners, Intrusion Detection, Vulnerability
Databases
CVE names have been included in initial
advisories from ISS X-Force, Rain Forest Puppy,
IBM, _at_stake, BindView, CERT/CC, HP, SGI, COMPAQ,
Microsoft, Ernst Young, eEye, CISCO, Rapid 7,
NSFOCUS, Sanctum, SecurityFocus, VIGILANTe, Red
Hat, Apache, and Apple.

• SANS / FBI Top 20 uses CVE names
• Network Computing IDS Scanner Comparisons
  included CVE
• Draft NIST Rec. calls for use of CVE
• DSB Report calls for CVE compatibility
• Network World IDS Comparison included CVE coverage

• 2223 CVE Entries -- 2419 Candidates.

• 92 CVE-compatible products from 61 groups.
• 54 more from 27 others in the works.

50
Progress in a Nutshell
400 CANs Reserved
Broached w/ 13 vendors
SANS Top 20
Scanner Comparisons
CIEL
Cassandra
FIRST
ICAT
51
For More Information
CVE web site
http//cve.mitre.org
52
(No Transcript)