update the introduction with basic fixes.

doc/compile-citeproc.sh

@@ -1,7 +1,7 @@
 #!/bin/sh
 src="./md_src_files"
 
-pandoc --standalone --from=markdown_github+citations  --to=html \
+pandoc --self-contained --from=markdown_github+citations  --to=html \
   --citeproc \
   --bibliography="$src/sources_ssvc.bib" \
   -M title="Prioritizing vulnerability response: A stakeholder-specific vulnerability categorization (DRAFT version 2.0)" \

doc/md_src_files/010_introduction.md

@@ -2,12 +2,32 @@
 
 # Introduction
 
-Many organizations use the Common Vulnerability Scoring System (CVSS) to prioritize actions during vulnerability management. This paper builds on prior work about prioritizing actions during vulnerability management by presenting a testable Stakeholder-Specific Vulnerability Categorization (SSVC) that avoids some problems with CVSS. SSVC takes the form of decision trees for different vulnerability management communities. We welcome others to test and improve it.
+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.
 
-This paper proposes a functional system to make our proposal concrete as well as preliminary tests of its usefulness. However, our proposal is a detailed hypothesis to test or a conversation starter; it is not a final proposal. 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.
+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.
+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.
 
-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. 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. Others may have different satisfactory models, and that is okay.
+Our decision-making process is based on decision trees.
+A decision tree represents important elements of a decision, possible decision values, and possible outcomes.
+We suggest decision trees as an adequate formalism for practical, widespread advice about vulnerability prioritization.
+We do not claim this approach is the only viable option.
+We suggest that specific vulnerability management stakeholder communities use decision trees.
+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.
 
-The organizing concept of our decision-making procedure is decision trees. A decision tree represents important elements of a decision, possible decision values, and possible outcomes. We suggest decision trees as an adequate formalism for practical, widespread advice about vulnerability prioritization. We do not claim this approach is the only viable option. We also suggest that specific vulnerability management stakeholder communities use decision trees. 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.
-
-The rest of the paper is organized as follows. [Section 2](#current-state-of-practice) summarizes the current state of vulnerability management. [Section 3](#representing-information-for-decisions-about-vulnerabilities) describes our design goals for an improved prioritization method. [Section 4](#decision-trees-for-vulnerability-management) proposes a definition of decision points and decision trees as a prioritization method. [Section 5](#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. [Section 6](#worked-example) provides examples of applying the methodology of Section 4 to sample vulnerabilities. [Section 7](#future-work) identifies future work. [Section 8](#limitations) identifies limitations in the design. [Section 9](#conclusion) concludes with some final thoughts.
+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.

doc/md_src_files/020_stateOfPractice.md

@@ -2,16 +2,26 @@
 
 # Current state of practice
 
-**Vulnerability management** is a term of art for security practitioners, used to include “the discovery, analysis, and handling of new or reported security vulnerabilities in information systems \[and\] the detection of and response to known vulnerabilities in order to prevent them from being exploited” [@csirtservices_v2]. Prioritization of organizational and analyst resources is an important precursor to vulnerability analysis, handling, and response. The general problem is: given limited resources, which vulnerabilities should be processed and which can be ignored for now. We approach this problem from a pragmatic, practitioner-centered angle.
-
-The de facto standard prioritization language is CVSS [@spring2018litrev]. CVSS avoids discussing decisions and, instead, takes **technical severity** as its fundamental concept. We understand severity’s role as informing decision making about vulnerability management. The CVSS standard indicates vulnerability management decisions, and only those decisions, as what they expect CVSS scores to inform -- “CVSS provides a way to capture the principal characteristics of a vulnerability … reflecting its severity … to help organizations  properly assess and prioritize their vulnerability management processes” [@cvss_sig]. However, the standard does not provide clear advice about how CVSS scores might inform decisions.
-
-How CVSS is used matters. Using just the base scores, which are “the intrinsic characteristics of a
-vulnerability that are constant over time and across user environments,” as a stand-alone prioritization method is not recommended [@cvss_v3-1]. However, as two examples, the U.S. government [see @nist800-115, p. 7-4; @nist800-40r3, p. 4; and @bod15-01] and the global payment card industry [@pcidss_v3] both have defined such misuse as expected practice in their vulnerability management requirements. CVSS has struggled to adapt to other stakeholder contexts; various stakeholder groups have expressed dissatisfaction by making new versions of CVSS, such as medical devices [@mitre2019medical], robotics [@vilches2018towards], and industrial systems [@figueroa2020survey]. In these three examples, the modifications tend to add complexity to CVSS by adding metrics. Product vendors have varying degrees of adaptation of CVSS for development prioritization, including but not limited to [Red Hat](https://access.redhat.com/security/updates/classification), [Microsoft](https://www.microsoft.com/en-us/msrc/security-update-severity-rating-system), and [Cisco](https://tools.cisco.com/security/center/resources/security_vulnerability_policy.html#asr). The vendors codify CVSS’s recommended qualitative severity rankings in different ways, and Red Hat and Microsoft make the user interaction base metric more important. The various stakeholder re-adaptations of CVSS suggest a stakeholder-specific prioritization is important.
-
-Unfortunately, all such re-adaptation of the basic CVSS mindset inherit its deeper issues. For 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]. In addition, severity should only be a part of vulnerability response prioritization [See, e.g., @farris2018vulcon]. 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. 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].
-
-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 for available measurements a prioritization method might consider, such as exploit availability or system attack surface.  Section 3 describes our design goals for a pragmatic prioritization methodology that can improve and build on the state of current practice.  
+**Vulnerability management** covers “the discovery, analysis, and handling of new or reported security vulnerabilities in information systems \[and\] the detection of and response to known vulnerabilities in order to prevent them from being exploited” [@csirtservices_v2].
+Prioritization of organizational and analyst resources is an important precursor to vulnerability analysis, handling, and response.
+The general problem is: given limited resources, which vulnerabilities should be processed and which can be ignored for now. We approach this problem from a pragmatic, practitioner-centered perspective.
+
+The de facto standard prioritization language is CVSS [@spring2018litrev].
+CVSS avoids discussing decisions and, instead, takes **technical severity** as its fundamental operating principle.
+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].
+
+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.
+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 target audience for SSVC is vulnerability managers of any kind.
 SSVC assumes that the vulnerability manager has identified that there is a vulnerability.