Rename markdown files to match current chapter and section names

doc/Makefile

@@ -13,12 +13,12 @@ SHELL=/bin/bash
 # versioning
 # need a better way of automatically updating version numbers
 MAJOR=2
-MINOR=0
+MINOR=1
 # these have the common meanings from semantic versioning
 # major should be incremented with content changes that introduce incompatibilities
 # minor should be incremented for meaningful changes that do not break compatibility
-FIX=5
-# fix version needs to be incremented with every commit
+# fix is based on git commit
+FIX=`git rev-parse --short HEAD`
 
 #versioning across different content is a bit complicated.
 # The PDF major.minor should match any schema, tree, or other supporting document version
@@ -29,6 +29,7 @@ HOME:=$(shell pwd)
 OUTDIR=$(HOME)
 SRC=./md_src_files
 
+
 TITLE:="Prioritizing Vulnerability Response: A Stakeholder-Specific Vulnerability Categorization (SSVC version $(MAJOR).$(MINOR).$(FIX))"
 TITLE_PREFIX:="SSVC"
 COMPILE_DATE:="Compiled `date -u`"
@@ -38,8 +39,8 @@ BIBLIOGRAPHY:=$(SRC)/sources_ssvc.bib
 # TODO decide whether to include FIX level in file name or not
 #PDF_OUT:=$(OUTDIR)/ssvc_v$(MAJOR)-$(MINOR)-$(FIX).pdf
 #HTML_OUT:=$(OUTDIR)/ssvc_v$(MAJOR)-$(MINOR)-$(FIX).html
-PDF_OUT:=$(OUTDIR)/ssvc_v$(MAJOR)-$(MINOR).pdf
-HTML_OUT:=$(OUTDIR)/ssvc_v$(MAJOR)-$(MINOR).html
+PDF_OUT:=$(OUTDIR)/ssvc.pdf
+HTML_OUT:=$(OUTDIR)/ssvc.html
 
 EMOJI_REPLACEMENTS:=$(HOME)/emoji-replacements.sed
 

doc/md_src_files/04_00_vulnerability_management_decisions.md

@@ -0,0 +1,11 @@
+# Vulnerability Management Decisions
+
+This section will define our audience for decision advice and how we are scoping our advice on vulnerability management decisions.
+Viable decision guidance for vulnerability management should (at a minimum) consider the stakeholder groups, their potential decision outcomes, and the data needed for relevant decision points.
+This section covers the first of these three parts, and the following sections address the other parts in turn.
+The “who” is primarily about categories of stakeholders—suppliers, deployers, and coordinators—as well as their individual risk tolerances.
+The “what” is about the scope, both in how the affected system is defined and how much of the world an analyst should consider when estimating effects of a vulnerability.
+
+While we strive to make our examples realistic, we invite the community to engage and conduct empirical assessments to test them.
+The following construction should be treated as an informed hypothesis rather than a conclusion.
+

doc/md_src_files/04_01_enumerating_stakeholders.md

@@ -0,0 +1,33 @@
+## Enumerating Stakeholders
+
+Stakeholders in vulnerability management can be identified within multiple independent axes.
+For example, they can be identified by their responsibility: whether the group *supplies*, *deploys*, or *coordinates* remediation actions.
+Depending what task a team is performing in a supply chain, the team may be considered a supplier, deployer, or a coordinator.
+Therefore, one organization may have teams that take on different roles.
+For example, an organization that develops and uses its own software might delegate the supplier role to its development team and the deployer role to its IT operations team.
+On the other hand, organizations using a DevOps approach to providing services might have a single group responsible for both the supplier and deployer roles.
+Organizations may also be distinguished by the type of industry sector. While it might be useful to enumerate all the sectors of the economy, we propose to draft decision points that include those from multiple important sectors.
+For example, we have safety-related questions in the decision path for all suppliers and deployers.
+The decision will be assessed whether or not the stakeholder is in a safety-critical sector.
+
+The choice not to segregate the decisions by sector is reinforced by the fact that any given software system might be used by different sectors.
+It is less likely that one organization has multiple responsibilities within the vulnerability management process.
+Even if there is overlap within an organization, the two responsibilities are often located in distinct business units with distinct decision-making processes.
+We can treat the responsibilities as non-overlapping, and, therefore, we can build two decision trees—one for each of the “patch supplier” and “patch deployer” responsibilities in the vulnerability management process.
+We leave “coordinating patches” as future work.
+Each of these trees will have different decision points that they take to arrive at a decision about a given unit of work.
+<!-- Consider changing the word patch. There are other responses to a vulnerability (mitigation, isolation, etc.) that are backgrounded by using “patch” here. -->
+
+The next two sections describe the decision space and the relevant decision points that we propose for these two responsibilities within the vulnerability management process.
+
+The target audience for this paper is professional staff responsible for making decisions about information systems.
+This audience encompasses a broad class of professionals,  including suppliers, system maintainers, and administrators of many types.
+It also includes other roles, such as risk managers, technical managers, and incident responders.
+Although every layperson who owns a computing device makes decisions about managing it, they are not the target audience.
+The following decision system may help such laypeople, but we do not intend it to be used by that audience.
+
+While C-level executives and public policy professionals often make, shape, or incentivize decisions about managing information systems, they are not the target audience, either.
+To the extent that decision trees for vulnerability management help higher level policy decisions, we believe the best way to help policy makers is by making technical decisions more transparent and explainable.
+Policy makers may see indirect benefits, but they are not our primary audience and we are not designing an approach for them directly.
+
+

doc/md_src_files/04_02_enumerating_decisions.md

@@ -0,0 +1,13 @@
+## Enumerating Decisions
+
+Stakeholders with different responsibilities in vulnerability management have very different decisions to make.
+This section focuses on the differences among organizations based on their vulnerability management responsibilities.
+Some decision makers may have different responsibilities in relation to different software. For example, an Android app developer is a developer of the app, but is a deployer for any changes to the Android OS API.
+This situation is true for libraries in general.
+A web browser developer makes decisions about applying patches to DNS lookup libraries and transport layer security (TLS) libraries.
+A video game developer makes decisions about applying patches released to the Unreal Engine.
+A medical device developer makes decisions about applying patches to the Linux kernel. The list goes on.
+Alternatively, one might view applying patches as including some development and distribution of the updated product.
+Or one might take the converse view, that development includes updating libraries.
+Either way, in each of these examples (mobile device apps, web browsers, video games, medical devices), we recommend that the professionals making genuine decisions do three things: (1) identify the decisions explicitly, (2) describe how they view their role(s), and (3) identify which software projects their decision relates to.
+If their decisions are explicit, then the decision makers can use the recommendations from this document that are relevant to them.