CVE Use Cases

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

CVE Use Cases

Booth, Harold (Fed)

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

Reply | Threaded
Open this post in threaded view
|

Re: CVE Use Cases

Landfield, Kent B
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: <[hidden email]<mailto:[hidden email]>> on behalf of "Booth, Harold (Fed)" <[hidden email]<mailto:[hidden email]>>
Date: Wednesday, April 13, 2016 at 2:05 PM
To: "[hidden email]<mailto:[hidden email]>" <[hidden email]<mailto:[hidden email]>>
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