Transcript ISSA CVE Talk - Basic Slides

1
CVE Behind the Scenes:
The Complexity of Being Simple
Steve Christey
The MITRE Corporation
July 11, 2001
© 2001 The MITRE Corporation
MITRE
2
Common Vulnerabilities and Exposures (CVE)
0
0
0
0
0
0
0
0
0
0
CVE at a glance
Criteria for a good CVE
CVE submission stage
Content decisions
CVE candidate stage
Reserving candidate numbers
CVE entry stage
Comments on CVE names
Top 10 vulnerability types
Managing diverse perspectives
MITRE
3
CVE at a Glance
Organization Name
CERT
CyberSafe
ISS
AXENT
Bugtraq
BindView
Cisco
IBM ERS
CERIAS
NAI
CA-96.06.cgi_example_code
Network: HTTP ‘phf’ Attack
CVE-1999-0067
http-cgi-phf
phf CGI Description:
allows remote command execution
CGI– Fun
phfandprogram
allows
remote
PHF Attacks
games for the
whole family
command
execution through shell metacharacters.
#107 – cgi-phf
#3200 – WWW phf attack
References:
Vulnerability
in NCSA/Apache Example Code
CERT:CA-96.06.cgi_example_code
http_escshellcmd
XF:http-cgi-phf
#10004 -BID:629
WWW phf check
http://cve.mitre.org
MITRE
4
CVE Enables Detailed Product Comparisons
0 CVE can normalize how vulnerabilities are counted
0 But how should it normalize them?
CVE
Name
CVE-XXXX-0001
Tool
A
X
Tool
B
X
DB
1
CVE-XXXX-0002
X
X
X
CVE-XXXX-0003
CVE-XXXX-0004
X
X
DB
2
X
Hacker
Attacks
X
X
X
X
MITRE
5
Using CVE in the Enterprise
My scanner can’t find CVE-3,
and I need patches for CVE-1
I need to fix these
vulnerabilities
Vulnerability
Scanner
CVE-1
CVE-2
CVE-3
Security
Bulletins
CVE-1
CVE-2
CVE-3
Attack CVE-3
CVE-1
Attack CVE-2
CVE-1 is on
my network
Attack CVE-1
Attacks
•CVE-1: that system is not
vulnerable, so don’t send
an alert
•CVE-2: my scanner must
work well
•CVE-3: my IDS must
work well
CVE-1
CVE-3
Web
Sites
IDS
My IDS can’t detect attacks on CVE-2
MITRE
6
Criteria for a Good CVE
0 From “Towards a Common Enumeration of Vulnerabilities”
(Mann/Christey, 2nd Workshop on Research with Security
Vulnerability Databases, Purdue, January 21-22, 1999)
1. Enumerate and discriminate between all known vulnerabilities
2. Assign a standard, unique name to each vulnerability
3. Be publicly "open" and shareable without distribution restrictions
4. Exist independently of the multiple perspectives of what a vulnerability is
0 Evolving design considerations
– Be as simple as possible
=
Minimize workload and overlap with databases
– Support the lookup of CVE names
– Involve diverse players across the security community
MITRE
7
CVE Editorial Board Members
(As of June 4, 2001)
Response Teams
Ken Armstrong - CanCERT
Bill Fithen - CERT/CC
Shawn Hernan - CERT/CC
Scott Lawler - DOD-CERT
John Rhodes - DOE-CIAC
Tool Vendors
Andy Balinsky - Cisco
Scott Blake - BindView
Tim Collins - NFR
Renaud Deraison - Nessus
John Flowers - nCircle
Andre Frech - ISS
Kent Landfield - infoAssure
Jim Magdych - NAI
David Mann - BindView
Craig Ozancin - AXENT
Paul Proctor - CyberSafe
Mike Prosser - Symantec
Marcus Ranum - NFR
Tom Stracener - nCircle
Bill Wall - Harris
Kevin Ziese - Cisco
Academic/Educational
Matt Bishop - UC Davis Computer Security Lab
Eric Cole - SANS
Pascal Meunier - Purdue University CERIAS
Alan Paller - SANS Institute
Gene Spafford - Purdue University CERIAS
OS Vendors
Troy Bollinger - IBM
Casper Dik - Sun
David LeBlanc - Microsoft
MITRE
Dave Baker, Steve Christey, Bill Hill
Information Providers
Russ Cooper - NTBugtraq
Elias Levy - Bugtraq, Security Focus
Peter Mell - NIST
Ron Nguyen - Ernst and Young
Ken Williams - eSecurityOnline.com
Other Security Experts
Kelly Cooper - GTE Internetworking
Steve Northcutt - SANS
Larry Oliver - IBM
Adam Shostack - Zero-Knowledge Systems
Stuart Staniford - Silicon Defense
http://cve.mitre.org/board/
MITRE
8
Criterion #1:
Enumerate and discriminate
between all known
vulnerabilities
MITRE
9
Issue: What is a Vulnerability?
0 CVE was originally called “Common Vulnerability Enumeration”
0 Security tools included many “non-vulnerabilities”
0 “Terminological warfare” by Editorial Board in August 1999
– 2 main debates
=
=
What is a vulnerability?
Should CVE include things that aren’t vulnerabilities?
– Primary example: running finger (CVE-1999-0612)
=
“Stepping stone” but not directly exploitable
– Various alternate terms were debated
– “Exposure” wasn’t being used that often back then, and there
was a strong need to keep the CVE acronym, so...
0 See:
– http://cve.mitre.org/about/terminology.html
– http://cve.mitre.org/board/archives/1999-08/threads.html
Vulnerability definitions vary widely!
Criterion #1: Enumerate and discriminate between all known vulnerabilities
MITRE
10
Issue: What is a Real Vulnerability?
0 ~50% of all issues are not publicly acknowledged by the vendor
0
0
0
0
– http://cve.mitre.org/board/archives/2000-09/msg00038.html
Many vulnerabilities are found in obscure software by unknown
researchers without independent confirmation
Resource-intensive to verify every report
Many sources focus on comprehensiveness and timeliness
If it’s reported but it may not be real, should it be added to CVE?
– It will at least be reviewed
– How much verification is necessary?
0 Extreme example
CAN-1999-0205
Denial of service in Sendmail 8.6.11 and 8.6.12
– Could not be replicated by vendor
– Checked by multiple tools (which may only compare banners)
Criterion #1: Enumerate and discriminate between all known vulnerabilities
MITRE
11
Issue: What is a Known Vulnerability?
0 Only include “publicly known” vulnerabilities
0 Rely on data sources to provide MITRE with vulnerability lists
– 10 sources for legacy issues (1999 and earlier)
=
8500 total items provided
– 4 periodic vulnerability summaries used for new issues
– See http://cve.mitre.org/cve/datasources.html for details
0 Some vulnerabilities are not announced through normal public
sources that allow peer review
Criterion #1: Enumerate and discriminate between all known vulnerabilities
MITRE
12
Identifying Known Vulnerabilities:
The CVE Submission Stage
0 Sources provide MITRE with their lists of all known vulnerabilities
0 MITRE’s CVE Content Team processes submissions
Conversion
• Convert items in database/tool to submission format
• Assign temporary ID’s to each submission
Matching
• Find most similar submissions, candidates, and entries
based on keywords
Refinement
• Combine all matched submissions into groups
• Use each group to create candidates
Criterion #1: Enumerate and discriminate between all known vulnerabilities
MITRE
13
Submission Conversion
• Data format is often unique to the sources
• Specialized scripts convert a source to standard submission format
• Extract description, references, source’s own unique identifiers
Source A
Source B
• Well-formatted text
• Uses symbolic ID’s
A:1
A:2
iis-dos
ftp-pasv
B:1 B:2
A:3
A:4
sendmail-headers
cgi-overflow
A:5
• Excel spreadsheet
• Uses numeric ID’s
(row number)
17
179
B:4 B:3
29
524
Source C
• Web page
• Uses
numeric ID’s
C:1 C:2
19
23
C:4 C:3
21
46
cde-privilege-drop
Criterion #1: Enumerate and discriminate between all known vulnerabilities
MITRE
14
Normalizing Keywords
• Convert description, short name,
references into keywords
• Periods, hyphens, etc. are NOT treated
as word separators
• Standardize keywords using thesaurus
Raw
Submission
CVE
Thesaurus
buffer overflow buffer overrun
pfdispaly
Normalizer
Normalized
Submission
pfdisplay
wuftp
wuftpd
wu-ftp
wu-ftpd
internet_explorer
IE
MSIE
IE4
• Maps similar terms to a single,
standard term
• Reduce chance of missing a
match
• Example: “pfdisplay”
•A common mistake since the misspelled
word is the actual name of the program!
Criterion #1: Enumerate and discriminate between all known vulnerabilities
MITRE
15
Submission Matching
• Each submission is matched against all submissions, candidates, and entries
•Information retrieval techniques provide list of 10 closest matches
• Metric favors rare keywords over common ones
•Tends to favor application names and version numbers
•Can overly favor “incidentally rare” terms
• Human marks which matches are correct
Match: A:1
iis-dos
Match:
B:1
17
Match:
C:1
19
C:4
C:2
C:2
B:3
B:1
A:1
21
23
23
524
17
iis-dos
B:3
B:2
A:2
A:3
524
179
ftp-pasv
sendmail-headers
CAN-1999-1234
CAN-1999-1234
CVE-1999-1547
Criterion #1: Enumerate and discriminate between all known vulnerabilities
MITRE
16
Submission Refinement
• Determine submission groups by inferring match relationships
• B:1 = A:2
C:1 = B:1
(A:2, B:1, C:1)
• Ensure that submissions all describe same problem
• Matching can be inaccurate
• Deep analysis is a bottleneck
CAN-1999-1234
B:3
A:1
524
iis-dos
B:1
C:1
17
19
A:2
ftp-pasv
• Verify that submissions
are duplicates of the
candidate (or entry)
• Collect references
• Write description
• Apply content decisions
Submissions with CVE names could reduce much of this effort!
Criterion #1: Enumerate and discriminate between all known vulnerabilities
MITRE
17
Some Challenges in Refinement
0 Identifying duplicate issues
– Can be difficult to trace a problem in multiple software packages
back to a common codebase
– Differences in reporting between researcher and vendor
– Lack of sufficient details in advisories
=
=
=
=
0
0
0
0
Even credits to a particular person aren’t always sufficient!
A problem when similar issues are discovered at the same time
Change logs can be vague
Diffs (when available) may not provide sufficient context
– Delays between initial discovery and advisory
– Rediscoveries of previously reported problems
Understanding unique, application-specific vulnerabilities
Managing the volume of information
Writing a good description (compact but with the right keywords)
Writing and following good consistency rules
Criterion #1: Enumerate and discriminate between all known vulnerabilities
MITRE
18
Content Decisions
0 Explicit guidelines for content of CVE entries
– Ensure and publicize consistency within CVE
– Provide “lessons learned” for researchers
– Document differences between vulnerability “views”
0 Three basic types
– Inclusion: What goes into CVE? What doesn’t, and why?
– Level of Abstraction: One or many entries for similar issues?
– Format: How are CVE entries formatted?
0 Difficult to document
– “[It’s] like trying to grasp wet corn starch” (Board member)
Incomplete information is the bane of consistency - and content decisions!
Criterion #1: Enumerate and discriminate between all known vulnerabilities
MITRE
19
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.
0 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
0 Affected by amount of available information
– Especially source code and exploit details
0 For all candidates affected by SF-LOC, see:
– http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=CD:SF-LOC
Criterion #1: Enumerate and discriminate between all known vulnerabilities
MITRE
20
SF-LOC Examples
CAN-2000-0686
Auction Weaver CGI script 1.03 and earlier allows remote attackers to
read arbitrary files via a .. (dot dot) attack in the fromfile parameter.
2 failure
points
CAN-2000-0687
Auction Weaver CGI script 1.03 and earlier allows remote attackers to
read arbitrary files via a .. (dot dot) attack in the catdir parameter.
CAN-2000-0971
Avirt Mail 4.0 and 4.2 allows remote attackers to cause a denial of service and possibly
execute arbitrary commands via a long "RCPT TO" or "MAIL FROM" command.
2 failure points
CAN-2001-0019
Arrowpoint (aka Cisco Content Services, or CSS) allows local users to cause a
denial of service via a long argument to the “show script,” “clear script,” “show
archive,” “clear archive,” “show log,” or “clear log” commands.
CAN-2001-0020
Directory traversal vulnerability in Arrowpoint (aka Cisco Content Services, or
CSS) allows local unprivileged users to read arbitrary files via a .. (dot dot) attack
6 failure
points
0 CAN-2001-0019 is clearly different than CAN-2001-0020
– But a single patch fixes both problems
0 CAN-2001-0019 could be 1, 2, or 6 vulnerabilities
Criterion #1: Enumerate and discriminate between all known vulnerabilities
MITRE
21
Why CAN-2001-0019 Could Identify 1, 2, or 6
Vulnerabilities
0 3 different source code scenarios
0 Without actual source, can’t be sure
which scenario is true
0 Even with source, there are different
ways of counting
0 Multiple format string problems are
especially difficult to distinguish
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); }
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); } }
Criterion #1: Enumerate and discriminate between all known vulnerabilities
MITRE
22
Example Content Decision: SF-EXEC
(Software Flaws in Multiple Executables)
If the same flaws appear in multiple executables in the same
package at the same time, then combine them into a single entry.
0 Could be a cut-and-paste error, or use of library code
0 Example
CVE-1999-0068
CGI PHP mylog script allows an attacker to read any file on the target server
CVE-1999-0346
CGI PHP mlog script allows an attacker to read any file on the target server
0 Both scripts had a vulnerable “<include>” command that didn’t
filter out bad characters
– Should “include” have filtered the characters in the file name?
– Or should they have been filtered before the include was called?
0 For all candidates affected by SF-EXEC, see:
– http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=CD:SF-EXEC
Criterion #1: Enumerate and discriminate between all known vulnerabilities
MITRE
23
Other Example Abstraction CD’s
0 CF-PASS
– Should there be one large entry for all default passwords?
=
=
What about undocumented or back door passwords?
What about guessable passwords?
0 Other unnamed examples
– Should separate entries be created for DDoS tools, Trojan
Horses, worms, and viruses?
– How to handle insecure auditing settings, access permissions,
or privilege assignments? How to define “insecure”?
– Is it the software application’s responsibility to restrict memory
usage, or is it the responsibility of the admin to use OS-specific
parameters?
Abstraction content decisions directly impact CVE-based metrics,
especially for configuration problems and malicious code.
Criterion #1: Enumerate and discriminate between all known vulnerabilities
MITRE
24
Example Inclusion CD’s
0 EX-BETA: “Exclude problems in beta products, unless the product
is in permanent beta, or it has received wide distribution.”
CAN-2000-0096
Buffer overflow in qpopper 3.0 beta versions allows local users to gain
privileges via a long LIST command.
CAN-2000-0046
Buffer overflow in ICQ 99b 1.1.1.1 client allows remote attackers to
execute commands via a malformed URL within an ICQ message.
0 EX-DOS-CLIENT: “Exclude denial of service problems in clients
unless the DoS extends beyond the client itself.”
CAN-2000-0190
AOL Instant Messenger (AIM) client allows remote attackers to cause
a denial of service via a message with a malformed ASCII value.
– But what if a buffer overflow causes the DoS?
CAN-2000-0756
Microsoft Outlook 2000 does not properly process long or malformed fields
in vCard (.vcf) files, which allows attackers to cause a denial of service.
CAN-2001-0145
Buffer overflow in VCard handler in Outlook 2000 and 98, and Outlook
Express 5.x, allows an attacker to execute arbitrary commands via a
malformed vCard birthday field.
Criterion #1: Enumerate and discriminate between all known vulnerabilities
MITRE
25
Criterion #2:
Assign a standard, unique
name to each vulnerability
MITRE
26
Candidate Stage: Assignment
CAN-YYYY-NNNN
B:1
C:1
17
19
• Assign new number (CAN-YYYY-NNNN)
• YYYY is the year in which the number was
assigned; NNNN is a counter for that year
To Source A
ftp-pasv = CAN-YYYY-NNNN
iis-dos = CAN-1999-1234
A:2
ftp-pasv
Backmap
CAN-1999-1234
To Source B
17 = CAN-YYYY-NNNN
524 = CAN-1999-1234
To Source C
19 = CAN-YYYY-NNNN
B:3
A:1
524
iis-dos
• Backmap: internal ID’s mapped to
candidate names, sent back to provider
• Submissions removed
Criterion #2: Assign a standard, unique name to each vulnerability
MITRE
27
Candidate Stage: Reservation
0 Candidate numbers can be reserved for inclusion in initial public
announcements of vulnerabilities
– Number is immediately available to all parties
– Simplifies correlation and cross-referencing
– Available to all researchers, vendors, and third parties
0 Current participants include well-known researchers, security
vendors, and software vendors
– ~150 candidates reserved since April 2000
0 Outreach being conducted to other vendors and researchers
0 Candidate Numbering Authorities (CNA’s) are authorized to reserve
pools of candidate numbers from MITRE for other parties
– Vendors or third parties
The candidate reservation process must be designed to minimize
the impact on responsible vulnerability disclosure practices.
Criterion #2: Assign a standard, unique name to each vulnerability
MITRE
28
Candidate Reservation Process
Request Candidate
Researcher
CAN-YYYY-NNNN
• Request candidate from CNA
• Provide candidate number to
vendor and other parties
• Include candidate number in
initial public announcement
• Notify MITRE of announcement
• Perform due diligence to avoid
duplicate or incorrect candidates
• Should work with affected vendor
to increase confidence in
correctness of the candidate
Candidate
Numbering
Authority
CAN
POOL
• Obtain pool of candidate
numbers from MITRE
• Define requirements for
researchers to obtain a candidate
• Assign correct number of
candidate numbers
• Ensure candidate is shared across
all parties
• Do not use candidates in
“competitive” fashion
MITRE
• Primary CNA
• Accessible to
researchers via
[email protected]
• Educate CNA about
content decisions
• Update CVE web site
when candidate is
publicly announced
• Track potential abuses
Criterion #2: Assign a standard, unique name to each vulnerability
MITRE
29
Know something?
Gonna tell everyone?
Get a CAN!
[email protected]
Criterion #2: Assign a standard, unique name to each vulnerability
MITRE
30
Candidate Stage: Proposal Through Final Decision
CAN-YYYY-NNNN
Proposal
Modification
• Clustering (date of discovery, OS, service type, etc.)
• Published on CVE web site
• Editorial Board members vote on candidate
•ACCEPT, MODIFY, REVIEWING, NOOP (No Opinion),
RECAST (change level of abstraction), REJECT
• Add references, change description
• Change level of abstraction
• Significant changes may require another round of voting
Interim
Decision
• ACCEPT or REJECT (Requires sufficient votes)
• At least 2 weeks after initial proposal
• 4 days for last-minute feedback
Final
Decision
• ACCEPT or REJECT
• Convert CAN-YYYY-NNNN to CVE-YYYY-NNNN
• Report final voting record
• Create new CVE version
Criterion #2: Assign a standard, unique name to each vulnerability
MITRE
31
Entry Stage
CVE-YYYY-NNNN
Publication
• Publish new CVE version and difference report
Modification
• Minor modifications
• Add references
• Change description
Reassessment
• New information may force a re-examination of the entry
• Level of abstraction may need to be changed
• May be a duplicate
• May not be a problem after all
Deprecation
• May need to “delete” an existing entry (e.g. duplicate entries)
• But, some products may still use this number
• Register the “deletion” but keep entry available for review
Criterion #2: Assign a standard, unique name to each vulnerability
MITRE
32
CVE Growth
Candidates
CVE Entries
2500
2000
Status
(as of May 28, 2001)
• 1510 entries
1500
1000
• 1120 candidates
Criterion #2: Assign a standard, unique name to each vulnerability
May-01
Mar-01
Jan-01
Nov-00
Sep-00
Jul-00
May-00
Mar-00
Jan-00
Nov-99
0
Sep-99
500
MITRE
33
What’s in a Name?
0 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
0 Some issues
– Year segment can be misunderstood as year of discovery
– Name is not atomic in most search engines, thus difficult to find
– Changing a CAN to a CVE can incur maintenance costs
– Maximum 10,000 candidates per year (CAN-10K problem)
0 Once public, names must not disappear without explanation
– Deprecated entries, rejected candidates
Any change to the CVE naming scheme will impact many users.
Criterion #2: Assign a standard, unique name to each vulnerability
MITRE
34
Criterion #3:
Be publicly open and
shareable, without
distribution restrictions
MITRE
35
What’s Open
0
0
0
0
0
Editorial Board mailing list archives and meeting summaries
Candidate votes and comments from Board members
Mailing lists available for CVE news and data updates
Various download formats
Reference maps from common sources to CVE names
– CERT/CC advisories, *Bugtraq posts, vendor bulletins, etc.
0 Challenges
– Minimize potential “competition” with other information sources
=
Can’t include confidence levels, OS, risk levels, etc.
– Challenges by vendors
– Documenting evolving approaches (e.g. content decisions)
– Changing reference names or lack of clear advisory names
=
Examples: Cisco, OpenBSD, SuSE, Debian
– Translations into other languages
– Managing expectations
Criterion #3: Be publicly open and shareable, without distribution restrictions
MITRE
36
Top Ten Vulnerability Types in CVE
(Issues publicized between Jan 2000 and April 2001)
383
Buffer Overflow
115
Dir. Traversal/Dot Dot
79
Malformed Input DoS
Unprotected Privileged Op's
71
Shell Metachars/Quoting
71
66
Symlink Following
Format String
50
Insecure Permissions
45
Weak Encryption
45
Trusted CGI Form Fields
1540 total CVE entries and
candidates analyzed
(yes, that’s 100 per month)
37
CVE content decisions directly affect these statistics.
Criterion #3: Be publicly open and shareable, without distribution restrictions
MITRE
37
Education of a Vulnerability Analyst
(In 3 Acts)
0 The early days: Insufficient details to discriminate between similar
vulnerabilities
CVE-1999-0032
Buffer overflow in BSD-based lpr package allows local users to gain root privileges.
CVE-1999-0077
Predictable TCP sequence numbers allow spoofing.
0 The middle days: Dealing with emerging terminology
CVE-2000-0039
AltaVista search engine allows remote attackers to read files above the document
root via a .. (dot dot) in the query.cgi CGI program.
CVE-2000-0573
The lreply function in wu-ftpd 2.6.0 and earlier does not properly
cleanse an untrusted format string, which allows remote attackers to
execute arbitrary commands via the SITE EXEC command.
0 Today: Include uncertainty, more details, support abstraction
CAN-2001-0443
Buffer overflow in QPC QVT/Net Popd 4.20 in QVT/Net 5.0 allows
remote attackers to cause a denial of service, and possibly execute
arbitrary commands, via (1) a long username, or (2) a long password.
Criterion #3: Be publicly open and shareable, without distribution restrictions
MITRE
38
Criterion #4:
Exist independently of the
multiple perspectives of what
a vulnerability is
MITRE
39
Some Perspectives
Perfectionist
New First
Catch up on
older problems
before focusing
on new ones
Fast and furious,
Give me CAN’s
and fix things
for new issues
later Slow and steady,
ASAP
get it right the
first time
Include
Include
Wireless
Telecom
Speed
Demon
One CVE
per patch
Give me
And nothing
One CVE
everything ILegacyI don’t
First Focus
per bug
on CVE
want
Compatibility
Use strong
Based Academic
on my
theoretical
needs
Miscellaneous principlesown Researcher
Include
Fix info
Sysadmin
Everyone
Include
And
ConfidenceChange theRisk
XML
LevelsNaming Scheme
Levels
Format
Focus on
CVE
Compatibility
Or at the
latest, nowSecurity
Manager
Traditionalist
AntiExclude
insecure
Admin
Only include
software flaws
configurations
Include
Viruses
Exploits
Attacks
Signatures
Yesterday
Include whatever
may conflict with
security policy
IDS
Scanner
Criterion #4: Exist independently of the multiple perspectives of what a vulnerability is
MITRE
40
Managing Perspectives
Consult the
Editorial
Board
Grow a
thick
skin
Listen to
the users
CVE
Please everyone
some of the time
Re-prioritize
when
possible
Maximize
utility
Document and
educate when
you can
Criterion #4: Exist independently of the multiple perspectives of what a vulnerability is
MITRE
41
For More Information
http://cve.mitre.org
MITRE