Re: CVE Use Cases

["Landfield, Kent B" <kent.b.landfield@intel.com>]

5.
Description:
Software provider would like to organize vulnerability information into 
classes to create software development tools that check for common 
mistakes occurring during the software development lifecycle.

Implied Requirements:
Historical list of identifiers issued with enough information to be 
able to categorize them into similar classes of vulnerabilities

---
Kent Landfield
+1.817.637.8026

From: 
<owner-cve-editorial-board-list@lists.mitre.org<mailto:owner-cve-editorial-board-list@lists.mitre.org>>
 on behalf of "Booth, Harold (Fed)" 
<harold.booth@nist.gov<mailto:harold.booth@nist.gov>>
Date: Wednesday, April 13, 2016 at 2:05 PM
To: 
"cve-editorial-board-list@lists.mitre.org<mailto:cve-editorial-board-list@lists.mitre.org>"
 
<cve-editorial-board-list@lists.mitre.org<mailto:cve-editorial-board-list@lists.mitre.org>>
Subject: CVE Use Cases

During the last board call there was a discussion of use cases, and we 
had agreed that it was the homework of the board. I would like to start 
this thread to collect and identify the various use cases that exist 
surrounding the use of a vulnerability identifier. I also took a swing 
at identifying some requirements that these use cases create. I tried 
to capture use cases that I have heard others voice in addition to 
those that I am familiar with, and hopefully they can respond, update, 
and correct them where I went astray. I found some of the information 
at [1] useful while developing this list. I’m not sure if this is 
enough, or the right level of detail for this activity, but wanted to 
start with something relatively simple and go from there.

In the absence of any sort of glossary:
Software Provider: someone who creates, distributes, hosts, or 
maintains products which can contain vulnerabilities for End Users
End User: someone who is the final user of products which can contain 
vulnerabilities
Security Researcher: someone who investigates the security of products, 
i.e. discover vulnerabilities
Vulnerability Coordinator: someone who as acts as a coordinator during 
the vulnerability disclosure lifecycle

Each use case description is in the format of: <actor(s)> would like to 
<perform some action/activity> in order to <satisfy some 
objective/need>.

In no particular order:

1.
Description:
Software Provider, Security Researcher, and Vulnerability Coordinators 
would like to be able to identify vulnerabilities throughout the 
discovery, fix, and advisory publication lifecycle in order to track 
and share information across disparate groups.

Implied Requirements:
Either same identifier used throughout the process or when different 
identifiers are used a mechanism is needed to relate them.

2.
Description:
End users would like to know what vulnerabilities exist in order to 
track through the assessment, prioritization, and remediation lifecycle 
for any vulnerabilities that exist within their environment

Implied Requirements:
All vulnerabilities are identified and listed to the end user
Enough actionable information is associated with the identifier to 
allow an end user to perform necessary activities

3.
Description:
End users would like to have a common identifier for vulnerabilities in 
order refer to vulnerabilities using the same methodology while using 
different/multiple tools as part of their vulnerability management 
lifecycle.

Implied Requirements:
Interoperable identifier used by a broad cross-section of 
tools/information providers (absent that, some methodology to relate 
vulnerabilities will be needed)

4.
Description:
Information providers would like to provide information about 
vulnerabilities in order to assist users throughout the vulnerability 
management lifecycle.

Implied Requirements:
All vulnerabilities have an associated identifier and are listed with 
enough information to identify the issue


[1] 
https://insights.sei.cmu.edu/cert/2014/12/vulnerability-coordination-and-concurrency-modeling.html