Skip to content

Commit

Permalink
Merge pull request #143 from j---/copyedits
Browse files Browse the repository at this point in the history
Copyedits
  • Loading branch information
j--- authored May 7, 2021
2 parents c1aca71 + 5b26a14 commit 7844a53
Show file tree
Hide file tree
Showing 20 changed files with 508 additions and 345 deletions.
33 changes: 27 additions & 6 deletions README.md
Original file line number Diff line number Diff line change
@@ -1,23 +1,31 @@
# SSVC
Stakeholder-Specific Vulnerability Categorization

The Stakeholder-specific Vulnerability Categorization (SSVC) is a system for prioritizing actions during vulnerability management.
SSVC aims to avoid one-size-fits-all solutions in favor of a modular decision-making system with clearly defined and tested parts that vulnerability managers can select and use as appropriate to their context.

# What's here

SSVC is mostly conceptual tools for vulnerability management.
These conceptual tools (how to make decisions, what should go into a decision, how to document and communicate decisions clearly, etc.) are described here.

`doc/*`

Draft and final versions of reports. See [`doc/README.md`](doc/README.md) for
more info.

`doc/pdfs/*.pdf`

Final versions of both reports referenced below can be found in this directory.
Static versions of issued reports are stored in this directory.

`data/*.csv`

Also included in are the two lookup tables as csv files which `ssvc.py`
reads in. These are just one row per possible path through the trees as
described in the paper. Changing the "outcome" column in this table will
change what the module above recommends.
The data folder contains detailed data files that define suggested prioritization results based on each combination of information on a vulnerability work item.
Also included in data are the lookup tables as csv files which `ssvc.py`
reads in.
These files define one row per possible path through the trees as
described in the paper.
The tools in the `src` folder provide an interface to work with these data files.
Customizing the "outcome" column in this csv is the primary recommended way that stakehodlers might adapt SSVC to their environment.


`src/ssvc.py`
Expand All @@ -34,6 +42,19 @@ but it worked well enough for what was needed at the time.
Directory with SSVC calculator using D3 graph.
See [`ssvc-calc/README.md`](ssvc-calc/README.md) for more info.

## Citing SSVC

To reference SSVC in an academic publication, please refer to the version presented at the 2020 Workshop on Economics of Information Security (WEIS):

@inproceedings{spring2020ssvc,
title={Prioritizing vulnerability response: {A} stakeholder-specific vulnerability categorization},
author={Jonathan M Spring and Eric Hatleback and Allen D. Householder and Art Manion and Deana Shick},
address={Brussels, Belgium},
year={2020},
month = dec,
booktitle = {Workshop on the Economics of Information Security}
}

## References

1. Spring, J., Hatleback, E., Householder, A., Manion, A., and Shick, D. "Prioritizing Vulnerability Response: A Stakeholder-Specific Vulnerability Categorization." White Paper, Software Engineering Institute, Carnegie Mellon University (2019). https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=636379
Expand Down
33 changes: 19 additions & 14 deletions doc/md_src_files/010_introduction.md
Original file line number Diff line number Diff line change
Expand Up @@ -3,11 +3,12 @@
# Introduction

This document defines a testable Stakeholder-Specific Vulnerability Categorization (SSVC) for prioritizing actions during vulnerability management.
The stakeholders in vulnerability management are diverse, and that diversity must be accommodated in the main functionality, rather than squeezed into hard-to-use optional features.
Given this, as much as it is practical, we aim to avoid one-size-fits-all solutions.
The stakeholders in vulnerability management are diverse.
This diversity must be accommodated in the main functionality, rather than squeezed into hard-to-use optional features.
Given this, we aim to avoid one-size-fits-all solutions as much as it is practical.

We will improve vulnerability management by framing decisions better.
The modeling framework determines what output types are possible, identifies the inputs, determines the aspects of vulnerability management that are in scope, defines the aspects of context that are incorporated, describes how the model handles context and different roles, and determines what those roles should be.
We will improve vulnerability management by framing decisions better.
The modeling framework determines what output types are possible, identifies the inputs, determines the aspects of vulnerability management that are in scope, defines the aspects of context that are incorporated, identifies how to handle changes over time, describes how the model handles context and different roles, and determines what those roles should be.
As such, the modeling framework is important but difficult to pin down.
We approach this problem as a satisficing process.
We do not seek optimal formalisms, but an adequate formalism.
Expand All @@ -20,14 +21,18 @@ We suggest that specific vulnerability management stakeholder communities use de
These suggestions are hypotheses for viable replacements for CVSS in those communities, but the hypotheses require empirical testing before they can be justifiably considered fit for use.
We propose a methodology for such testing.

This document describes version 2 of SSVC.
The main improvements from version 1 are the addition of the coordinator stakeholder perspective, improvements to terminology, integration of feedback on decision point definitions, and tools to support practical use.
These changes are described in more detail in [Version 2 Changelog](#version-2-changelog).

The document is organized as follows.
[Current State of Practice](#current-state-of-practice) summarizes the current state of vulnerability management.
[Representing Information for Decisions About Vulnerabilities](#representing-information-for-decisions-about-vulnerabilities) describes our design goals for an improved prioritization method.
[Vulnerability Management Decisions](#vulnerability-management-decisions) defines who the decision makers are and what options they are deciding among.
[Likely Decision Points and Relevant Data](#likely-decision-points-and-relevant-data) proposes a definition of decision points that a stakeholder might use during vulnerability management.
[Prioritization](#prioritization) combines these decision points into example decision trees that can be used to prioritize action on a work item.
[Evaluation of the Draft Trees](#evaluation-of-the-draft-trees) describes an early test of this method against the design goals, as much to show an adequate usability test methodology as for the results.
[Worked example](#worked-example) provides examples of applying the methodology to sample vulnerabilities and discusses the relationship between SSVC and other vulnerability management prioritization systems.
[Future Work](#future-work) identifies ideas we haven't had time to incorporate yet.
[Limitations](#limitations) identifies limitations in the design.
[Conclusion](#conclusion) concludes with some final thoughts.
- [Current State of Practice](#current-state-of-practice) summarizes the current state of vulnerability management.
- [Representing Information for Decisions About Vulnerabilities](#representing-information-for-decisions-about-vulnerabilities) describes our design goals for an improved prioritization method.
- [Vulnerability Management Decisions](#vulnerability-management-decisions) defines who the decision makers are and what options they are deciding among.
- [Likely Decision Points and Relevant Data](#likely-decision-points-and-relevant-data) proposes a definition of decision points that a stakeholder might use during vulnerability management.
- [Prioritization](#prioritization) combines these decision points into example decision trees that can be used to prioritize action on a work item.
- [Evaluation of the Draft Trees](#evaluation-of-the-draft-trees) describes an early test of this method against the design goals, as much to show an adequate usability test methodology as for the results.
- [Worked example](#worked-example) provides examples of applying the methodology to sample vulnerabilities and discusses the relationship between SSVC and other vulnerability management prioritization systems.
- [Future Work](#future-work) identifies ideas we haven't had time to incorporate yet.
- [Limitations](#limitations) identifies limitations in the design.
- [Conclusion](#conclusion) provides some final thoughts.
19 changes: 11 additions & 8 deletions doc/md_src_files/020_stateOfPractice.md
Original file line number Diff line number Diff line change
Expand Up @@ -11,21 +11,24 @@ CVSS avoids discussing decisions and, instead, takes **technical severity** as i
However, the standard does not provide clear advice about how CVSS scores might inform decisions [@cvss_sig].
SSVC instead considers technical severity as one decision point in vulnerability management.
Severity should only be a part of vulnerability response prioritization [See, e.g., @farris2018vulcon].
Vulnerability managers make decisions at a particular time in a specific context.
CVSS base scores are static; we will make SSVC from modular parts that are easier to compose in each manager's temporal and operational context.

Any re-adaptation of the basic CVSS mindset inherits its deeper issues.
As one example, the CVSS scoring algorithm has not been argued for transparently, and the standardization group has not justified the use of the formula either formally or empirically [@spring2018cvss].
One complaint is that a high CVSS score is not predictive of which vulnerabilities will be commonly exploited or have exploits publicly released [@allodi2012preliminary].
Studies of CVSS scoring consistency indicate that analysts do not consistently interpret the elements of a CVSSv3.0 score [@allodi2018effect], and as many adaptations of CVSS simply add additional metrics we expect they inherit such inconsistency.
For example, arguments for the CVSS scoring algorithm have not been transparent and the standardization group has not justified the use of the formula either formally or empirically [@spring2018cvss].
One complaint is that a high CVSS score does not predict which vulnerabilities will be commonly exploited or have exploits publicly released [@allodi2012preliminary].
Studies of consistency in CVSS scoring indicate that analysts do not consistently interpret the elements of a CVSS version 3.0 score [@allodi2018effect].
Because many adaptations of CVSS simply add additional metrics, we expect they will inherit such inconsistency.
Analyst usability has so far been an afterthought, but we know from other areas of information security that usability is not well-served as an afterthought [@garfinkel2014usable].
SSVC aims to learn from and improve upon these issues.

Surveys of security metrics [@pendleton2016survey] and information sharing in cybersecurity [@laube2017survey] do not indicate any major efforts to conduct a wholesale rethinking of vulnerability prioritization.
The surveys indicate some options a prioritization method might consider, such as exploit availability or system attack surface.
[Representing Information for Decisions About Vulnerabilities](#representing-information-for-decisions-about-vulnerabilities) describes our design goals for a pragmatic prioritization methodology that can improve and build on the state of current practice.
The surveys indicate some options a prioritization method might consider, such as exploit availability or system attack surface.
[Representing Information for Decisions About Vulnerabilities](#representing-information-for-decisions-about-vulnerabilities) describes our design goals for a pragmatic prioritization methodology that can improve and build on the state of current practice.

The target audience for SSVC is vulnerability managers of any kind.
SSVC assumes that the vulnerability manager has identified that there is a vulnerability.
We take our definition of **vulnerability** from [@householder2020cvd]: "a set of conditions or behaviors that allows the violation of an explicit or implicit security policy."
There are a variety of problems or issues with computer systems that are important that are not vulnerabilities.
SSVC assumes that the vulnerability manager has identified that there is a vulnerability.
We take our definition of **vulnerability** from [@householder2020cvd]: a set of conditions or behaviors that allows the violation of an explicit or implicit security policy.
A variety of problems or issues with computer systems are important but are not vulnerabilities.
SSVC presents a risk prioritization method that might be useful or at least allied to other risk management methods for these other kinds of issues.
However, for this work we focus on decisions in the situation where there is a vulnerability and the vulnerability management team wants to decide what to do about it.
Loading

0 comments on commit 7844a53

Please sign in to comment.