diff --git a/.github/workflows/link_checker.yml b/.github/workflows/link_checker.yml new file mode 100644 index 00000000..cbceedfb --- /dev/null +++ b/.github/workflows/link_checker.yml @@ -0,0 +1,41 @@ +name: Link Checker +on: + pull_request: + paths: + # run on any PR that modifies a markdown file + - '**/*.md' + # run on any PR that changes this workflow + - .github/workflows/linkchecker.yml + # let us trigger it manually + workflow_dispatch: + +jobs: + linkcheck: + runs-on: ubuntu-latest + steps: + - name: Checkout + uses: actions/checkout@v4 + + - name: Set up Python + uses: actions/setup-python@v5 + with: + python-version: '3.10' + + - name: Install dependencies + run: | + python -m pip install --upgrade pip + python -m pip install -r requirements.txt + python -m pip install linkchecker + + - name: Install our python stuff + run: | + python -m pip install -e src + + - name: Build Site + run: | + mkdocs build --verbose --clean --config-file mkdocs.yml + + - name: Check links + run: | + linkchecker site/index.html + diff --git a/README.md b/README.md index 0e3d8c06..6838e477 100644 --- a/README.md +++ b/README.md @@ -1,4 +1,4 @@ -[![pandoc_html_pdf](https://github.com/CERTCC/SSVC/actions/workflows/pandoc_html_pdf.yaml/badge.svg)](https://github.com/CERTCC/SSVC/actions/workflows/pandoc_html_pdf.yaml) +[![Link Checker](https://github.com/CERTCC/SSVC/actions/workflows/link_checker.yml/badge.svg?branch=main)](https://github.com/CERTCC/SSVC/actions/workflows/link_checker.yml) # SSVC diff --git a/docs/adr/0005-ssvc-decision-point-group-versioning.md b/docs/adr/0005-ssvc-decision-point-group-versioning.md index 24b9a49f..f515f1d0 100644 --- a/docs/adr/0005-ssvc-decision-point-group-versioning.md +++ b/docs/adr/0005-ssvc-decision-point-group-versioning.md @@ -8,13 +8,13 @@ deciders: adh, jspring, vssarvepalli, cgyarbrough, latyzenhaus, ehatleback ## Context and Problem Statement -[ADR 004](./0004-ssvc-decision-point-groups-are-versioned.md) established that Decision Point Groups should be versioned. +[ADR 004](0004-ssvc-decision-point-groups-are-versioned.md) established that Decision Point Groups should be versioned. This ADR establishes the rules for versioning Decision Point Groups. ## Decision Drivers -(See [ADR 004](./0004-ssvc-decision-point-groups-are-versioned.md) for additional context.) +(See [ADR 004](0004-ssvc-decision-point-groups-are-versioned.md) for additional context.) - Decision Points change over time - The composition of decision point groups change over time @@ -103,7 +103,7 @@ In row 4, DP C undergoes a major version increment, which triggers a major versi - Because we don't anticipate frequent changes to decision point groups, the burden of maintaining version numbers should be minimal. - We are deliberately avoiding using the _name_ of the Decision Point Group as part of the versioning scheme, as in the motivating example in -[ADR 0004](/0004-ssvc-decision-point-groups-are-versioned.md) we shifted the +[ADR 0004](0004-ssvc-decision-point-groups-are-versioned.md) we shifted the group name from _Patch Applier_ to _Deployer_, but since the group is still intended to represent the same _stakeholder role_ and _decision_, we want to be able to treat name changes as aliases rather than versioning events. diff --git a/docs/howto/bootstrap/steps_table.md b/docs/howto/bootstrap/_steps_table.md similarity index 85% rename from docs/howto/bootstrap/steps_table.md rename to docs/howto/bootstrap/_steps_table.md index baf712d4..6182ac67 100644 --- a/docs/howto/bootstrap/steps_table.md +++ b/docs/howto/bootstrap/_steps_table.md @@ -3,4 +3,4 @@ | [**Prepare**](prepare.md) | Define the decision you want to make, the outcomes you care about, the decision points you will use to make the decision, the decision policy, and the data you need to inform the decision points. | | [**Collect**](collect.md) | Collect the data you need to make informed decisions. | | [**Use SSVC**](use.md) | Use SSVC to make decisions about how to respond to vulnerabilities. | -| [**Respond**](use.md#respond-to-vulnerabilities) | Respond to vulnerabilities according to the prioritization. | +| [**Respond**](use.md) | Respond to vulnerabilities according to the prioritization. | diff --git a/docs/howto/bootstrap/collect.md b/docs/howto/bootstrap/collect.md index 2521eadb..9bb57d9b 100644 --- a/docs/howto/bootstrap/collect.md +++ b/docs/howto/bootstrap/collect.md @@ -10,7 +10,7 @@ While the actual collection of operational data is outside the scope of SSVC, it is an important part of any implementation of the process. SSVC is designed to be flexible enough to accommodate a variety of data collection methods. -The [Data Mapping](prepare.md#data-mapping) step defines the data that is needed to assign a value to each decision point. +The [Data Mapping](prepare.md) step defines the data that is needed to assign a value to each decision point. The Data Operations process collects that data so that it can be used to assign values to decision points in the [Use SSVC](use.md) step. @@ -43,4 +43,87 @@ flowchart LR They also write a script that parses the data from the threat feeds and applies the data map to assign a value to the _Exploitation_ decision point. -{% include-markdown '../evidence_gathering.md' heading-offset=1 %} +## Guidance for Evidence Gathering + +To answer each of these decision points, a stakeholder should, as much as possible, have a repeatable evidence +collection and evaluation process. +However, we are proposing decisions for humans to make, so evidence collection and evaluation is not totally automatable. +That caveat notwithstanding, some automation is possible. + +!!! example "Evidence of Exploitation" + + For example, whether exploitation modules are available in ExploitDB, Metasploit, or other sources is straightforward. + We hypothesize that searching Github and Pastebin for exploit code can be captured in a script. + A supplier or deployer could then define [*Exploitation*](../../reference/decision_points/exploitation.md) to take the value of [*PoC*](../../reference/decision_points/exploitation.md) if + there are positive search results for a set of inputs derived from the CVE entry in at least one of these venues. + At least, for those vulnerabilities that are not “automatically” PoC-ready, such as on-path attackers for TLS or network + replays. + +Some of the decision points require a substantial upfront analysis effort to gather risk assessment or organizational +data. +However, once gathered, this information can be efficiently reused across many vulnerabilities and only refreshed +occasionally. + +!!! example "Evidence of Mission Impact" + + An obvious example of this is the mission impact decision point. + To answer this, a deployer must analyze their essential functions, how they interrelate, and how they are supported. + +!!! example "Evidence of Exposure" + + Exposure is similar; answering that decision point requires an asset inventory, adequate understanding of the network + topology, and a view of the enforced security controls. + Independently operated scans, such as Shodan or Shadowserver, may play a role in evaluating exposure, but the entire + exposure question cannot be reduced to a binary question of whether an organization’s assets appear in such databases. + +Once the deployer has the situational awareness to understand MEFs or exposure, selecting the answer for each individual +vulnerability is usually straightforward. + +Stakeholders who use the prioritization method should consider releasing the priority with which they handled the +vulnerability. +This disclosure has various benefits. +For example, if the supplier publishes a priority ranking, then deployers could consider that in their decision-making +process. +One reasonable way to include it is to break ties for the deployer. +If a deployer has three “scheduled” vulnerabilities to remediate, they may address them in any order. +If two vulnerabilities were produced by the supplier as “scheduled” patches, and one was “out-of-cycle,” then the +deployer may want to use that information to favor the latter. + +### Suggested Default Values + +In the case where no information is available or the organization has not yet matured its initial situational analysis, +we can suggest something like defaults for some decision points. + +!!! tip "Default Exposure Values" + + If the deployer does not know their exposure, that + means they do not know where the devices are or how they are controlled, so they should assume + [*System Exposure*](../../reference/decision_points/system_exposure.md) is [*open*](../../reference/decision_points/system_exposure.md). + +!!! tip "Default Safety Values" + + If the decision maker knows nothing about the environment in which the device is used, we suggest assuming a + [*major*](../../reference/decision_points/safety_impact.md) [*Safety Impact*](../../reference/decision_points/safety_impact.md). + This position is conservative, but software is thoroughly embedded in daily life now, so we suggest that the decision + maker provide evidence that no one’s well-being will suffer. + +The reach of software exploits is no longer limited to a research network. + +!!! tip "Default Mission Impact Values" + + Similarly, with [*Mission Impact*](../../reference/decision_points/mission_impact.md), the deployer should assume that the software is in use at the + organization for a reason, and that it supports essential functions unless they have evidence otherwise. + With a total lack of information, assume [*support crippled*](../../reference/decision_points/mission_impact.md) as a default. + [*Exploitation*](../../reference/decision_points/exploitation.md) needs no special default; if adequate searches are made for exploit code and none is + found, the answer is [*none*](../../reference/decision_points/exploitation.md). + + +!!! tip "Default Automatable Values" + + If nothing is known about [*Automatable*](../../reference/decision_points/automatable.md), the safer answer to assume is [*yes*](../../reference/decision_points/automatable.md). + [*Value Density*](../../reference/decision_points/value_density.md) should always be answerable; if the product is uncommon, it is probably + [*diffuse*](../../reference/decision_points/value_density.md). + +The resulting decision set `{none, open, yes, medium}` results in a scheduled patch application in our recommended +deployer tree. + diff --git a/docs/howto/bootstrap/index.md b/docs/howto/bootstrap/index.md index b31ab0b8..95042e6c 100644 --- a/docs/howto/bootstrap/index.md +++ b/docs/howto/bootstrap/index.md @@ -18,7 +18,7 @@ Using SSVC to prioritize vulnerability response requires a few steps. The steps r --> dataops ``` -{% include-markdown "howto/bootstrap/steps_table.md" %} +{% include-markdown "howto/bootstrap/_steps_table.md" %} We cover each of these in the following sections, starting with [Prepare to Use SSVC](prepare.md). If you want to skip ahead to the full process, see [Bootstrapping SSVC Summary](summary.md). \ No newline at end of file diff --git a/docs/howto/bootstrap/prepare.md b/docs/howto/bootstrap/prepare.md index e5ada635..5e1d5866 100644 --- a/docs/howto/bootstrap/prepare.md +++ b/docs/howto/bootstrap/prepare.md @@ -34,10 +34,10 @@ We will go through each step in detail. Decisions we have modeled with SSVC include: - - [Patch Supplier Prioritization](supplier_tree.md) - - [Patch Deployer Prioritization](deployer_tree.md) - - [Coordinator Triage](coordinator_trees.md) - - [Coordinator Publication](coordinator_publish_tree.md) + - [Patch Supplier Prioritization](../supplier_tree.md) + - [Patch Deployer Prioritization](../deployer_tree.md) + - [Coordinator Triage](../coordination_decisions.md) + - [Coordinator Publication](../publication_decision.md) The first step in preparing to use SSVC is to choose a decision to model. SSVC is designed to help you make decisions about how to respond to a vulnerability. @@ -60,9 +60,9 @@ flowchart LR !!! example inline end - In the [Patch Supplier](supplier_tree.md) and [Patch Deployer](deployer_tree) prioritization examples, the outcomes are: - _Defer_, _Scheduled_, _Out-of-Cycle_, and _Immediate_. In the [Coordinator Triage](coordinator_trees.md) example, - the outcomes are _Coordinate_, _Track_, and _Decline_. In the [Coordinator Publication](coordinator_publish_tree.md) example, + In the [Patch Supplier](../supplier_tree.md) and [Patch Deployer](../deployer_tree.md) prioritization examples, the outcomes are: + _Defer_, _Scheduled_, _Out-of-Cycle_, and _Immediate_. In the [Coordinator Triage](../coordination_decisions.md) example, + the outcomes are _Coordinate_, _Track_, and _Decline_. In the [Coordinator Publication](../publication_decision.md) example, the outcomes are _Publish_ and _Do Not Publish_. Once you have chosen a decision to model, you need to define the outcomes for that decision. @@ -109,7 +109,7 @@ Once you know what decision you want to make and what the possible outcomes are, A decision usually requires more than one piece of information. SSVC organizes this information into decision points. A single decision point enumerates a set of options for a particular aspect of the decision. -We have defined a number of decision points in the [SSVC documentation](../reference/decision_points/index.md). +We have defined a number of decision points in the [SSVC documentation](../../reference/decision_points/index.md). You can choose from these decision points, or you can define your own decision points to meet your needs. Whether you choose from the existing decision points or define your own, the set of decision points you use to make a @@ -159,7 +159,7 @@ Now, you need to define the policy you want to use to make that decision. A policy is a function that takes a set of decision point values as input and returns an outcome as output. While we often choose to represent policies as decision trees, they can be represented in other ways as well. In fact, we find that it is often useful to represent policies in tabular form, for example as a CSV file. -We have provided a number of example policies in the [SSVC documentation](../prioritization.md), but you can define your own policy to meet your needs. +We have provided a number of example policies in the [SSVC documentation](../index.md), but you can define your own policy to meet your needs. ```mermaid flowchart LR @@ -181,11 +181,11 @@ flowchart LR !!! example A small bank has a policy that they must deploy patches within 48 hours of release if the vulnerability affects systems - that could lead to customer data being exposed. They examine the example [Deployer Prioritization](supplier_tree.md) + that could lead to customer data being exposed. They examine the example [Deployer Prioritization](../supplier_tree.md) decision model and decide that both the outcome set and the decision point set that define the structure of the decision model are appropriate for their needs. They map the 48 hour requirement to the _Immediate_ outcome, because it essentially represents their highest priority response. - However, they notice that the specific policy given in the [Deployer Prioritization](supplier_tree.md) + However, they notice that the specific policy given in the [Deployer Prioritization](../supplier_tree.md) example—that is, the mapping from decision point values to outcomes—is not appropriate for their needs because it has too few _Immediate_ outcomes to suit their policy. Therefore, the bank decides to reuse the same decision point set and outcome set but define their own policy. @@ -220,7 +220,7 @@ flowchart LR !!! example A Software-as-a-Service Provider differentiates its service levels into three categories: silver, gold, and platinum. - In the [Define Inputs](#define-inputs) step, they defined a custom decision point called _Service Level_ with the values + In the Define Inputs step, they defined a custom decision point called _Service Level_ with the values _Silver_, _Gold_, and _Platinum_. Now, they need to define a data map that will assign a value to the _Service Level_ decision point. The data they need to assign a value to the _Service Level_ decision point originates in the service level diff --git a/docs/howto/bootstrap/summary.md b/docs/howto/bootstrap/summary.md index 48b26486..0f1f2f21 100644 --- a/docs/howto/bootstrap/summary.md +++ b/docs/howto/bootstrap/summary.md @@ -2,7 +2,7 @@ Using SSVC to prioritize vulnerability response requires a few steps. The steps are: -{% include-markdown "howto/bootstrap/steps_table.md" %} +{% include-markdown "howto/bootstrap/_steps_table.md" %} We covered each of these in the previous sections, see the links in the table above for more information. diff --git a/docs/howto/bootstrap/use.md b/docs/howto/bootstrap/use.md index 99392cc6..fc1de0e2 100644 --- a/docs/howto/bootstrap/use.md +++ b/docs/howto/bootstrap/use.md @@ -1,7 +1,7 @@ # Use SSVC The [preparation](prepare.md) is complete, data is being [collected](collect.md), and now it is time to use -SSVC to make decisions about how to [respond to vulnerabilities](#respond-to-vulnerabilities). +SSVC to make decisions about how to respond to vulnerabilities. ```mermaid flowchart LR @@ -83,4 +83,154 @@ flowchart LR SSVC does not prescribe any particular response process, but it does provide a structured way to make decisions within the response process. -{% include-markdown '../communicating_results.md' heading-offset=1 %} \ No newline at end of file +## Guidance on Communicating Results + +There are many aspects of SSVC that two parties might want to communicate. +Not every stakeholder will use the decision points to make comparable decisions. +Suppliers and deployers make interdependent decisions, but the actions of one group are not strictly dependent on the other. +Recall that one reason for this is that SSVC is about prioritizing a vulnerability response action in general, not specifically applying a patch that a supplier produced. +Coordinators are particularly interested in facilitating communication because that is their core function. +This section handles three aspects of this challenge: formats for communicating SSVC, how to handle partial or incomplete information, and how to handle information that may change over time. + +This section is about communicating SSVC information about a specific vulnerability. +Any stakeholder making a decision on allocating effort should have a decision tree with its decision points and possible values specified already. +[Representation choices](../../topics/decision_trees.md) and [Tree Construction and Customization Guidance](../tree_customization.md) discussed how SSVC uses a text file as the canonical form of a decision tree; the example trees can be found in [SSVC/data](https://github.com/CERTCC/SSVC/tree/main/data). +This section discusses the situation where one stakeholder, usually a supplier or coordinator, wants to communicate some information about a specific vulnerability to other stakeholders or constituents. + +### Communication Formats + +We recommend two structured communication formats, abbreviated and full. +The goal of the abbreviated format is to fill a need for providing identifying information about a vulnerability or decision in charts, graphs, and tables. Therefore, the abbreviated format is not designed to stand alone. +The goal of the full format is to capture all the context and details about a decision or work item in a clear and machine-readable way. + +#### Abbreviated Format + +SSVC abbreviated form borrows directly from the CVSS “vector string” notation. +Since the purpose of the abbreviated form is to provide labels for charts and graphics, it does not stand alone. +The basic format for SSVC is: +``` +SSVC/(version)/(decision point):(value)[/decision point:value[/decision point:value[...]]][/time]/ +``` +Where `version` is `v2` if it is based on this current version of the SSVC. +The term `decision point` is one or two letters derived from the name of the decision point as follows: + - Start with the decision point name as given in [Likely Decision Points and Relevant Data](../../reference/decision_points/index.md). + - Remove any text in parentheses (and the parentheses themselves). + - Remove the word “Impact” if it is part of the name. + - Create an initialism from remaining title-case words (ignore “of,” etc.), taking only the first two words. + - The first letter of the initialism is upper case; if there is a second letter, then it is lower case. + - Verify that the initialism is unique among decision points in the version of SSVC. If two initialisms collide, sort their source names equivalent to `LC_ALL=C sort`. The name that sorts first keeps the initialism for which there is a collision. Set the second letter of the initialism to the first character in the name that resolves the collision. If the names were `Threat` and `Threshold`, `T` would be `Threat` and `Ts` would be `Threshold`. We make an effort to design SSVC without such collisions. + +For example, [*Technical Impact*](../../reference/decision_points/technical_impact.md) becomes `T` and [*Public Safety Impact*](../../reference/decision_points/public_safety_impact.md) becomes `Ps`. + +The term `value` is a statement of the value or possible values of the decision point that precedes it and to which it is connected by a colon (`:`). +Similar to `decision point`, `value` should be made up of one or two letters derived from the name of the decision value in the section for its associated decision point. +For example [MEF support crippled](../../reference/decision_points/mission_impact.md) becomes `Ms` and [efficient](../../reference/decision_points/utility.md) becomes `E`. +The process is the same as above except that labels for a `value` do not need to be unique to the SSVC version, just unique to the associated `decision point`. + +The character `/` separates decision-point:value pairs. +As many pairs should be provided in the abbreviated form as are required to communicate the desired information about the vulnerability or work item. +A vector must contain at least one decision-point:value pair. +The ordering of the pairs should be sorted alphabetically from A to Z by the ASCII characters representing the decision points. +A trailing `/` is used to close the string. + +The vector is not tied to a specific decision tree. +It is meant to communicate information in a condensed form. +If priority labels (*defer*, etc.) are connected to a vector, then the decision tree used to reach those decisions should generally be noted. +However, for complex communication, machine-to-machine communication, or long-term storage of SSVC data, the JSON format and schema should be used. + +The optional parameter `time` is the date and time of the SSVCv2 record creation as represented in [RFC 3339, section 5.6](https://datatracker.ietf.org/doc/html/rfc3339). This is a subset of the date format also commonly known as ISO8601 format. + +Based on this, an example string could be: +``` +SSVCv2/Ps:M/T:T/U:E/2018-11-13T20:20:00Z/ +``` +For a vulnerability with [minimal](../../reference/decision_points/public_safety_impact.md) [*Public Safety Impact*](../../reference/decision_points/public_safety_impact.md), [total](../../reference/decision_points/technical_impact.md) [*Technical Impact*](../../reference/decision_points/technical_impact.md), and [efficient](../../reference/decision_points/utility.md) [Utility](../../reference/decision_points/utility.md), which was evaluated on Nov 13,2018 at 8:20 PM UTC. + +While these abbreviated format vectors can be uniquely produced based on a properly formatted JSON object, going from abbreviated form to JSON is not supported. +Therefore, JSON is the preferred storage and transmission method. + +#### Full JSON format + +For a more robust, self-contained, machine-readable, we provide JSON schemas. +The [provision schema](https://github.com/CERTCC/SSVC/blob/main/data/schema/SSVC_Provision.schema.json) is equivalent to a decision tree and documents the full set of logical statements that a stakeholder uses to make decisions. +The [computed schema](https://github.com/CERTCC/SSVC/blob/main/data/schema/SSVC_Computed.schema.json) expresses a set of information about a work item or vulnerability at a point in time. +A computed schema should identify the provision schema used, so the options from which the information was computed are specified. + +Each element of `choices` should be an object that is a key-value pair of `decision point`:`value`, where the term `decision point` is a string derived from the name of the decision point as follows: + - Start with the decision point name as given in [Likely Decision Points and Relevant Data](../../reference/decision_points/index.md). + - Remove any text in parentheses (and the parentheses themselves). + - Remove colon characters, if any (`:`). + - Convert the string to [lower camel case](https://en.wikipedia.org/wiki/Camel_case) by lowercasing the string, capitalizing any letter after a space, and removing all spaces. + +The `value` term is derived the same way as `decision point` except start with the value name as given in the relevant decision point subsection of [Likely Decision Points and Relevant Data](../../reference/decision_points/index.md). + +### Partial or Incomplete Information + +What an analyst knows about a vulnerability may not be complete. +However, the vulnerability management community may still benefit from partial information. +In particular, suppliers and coordinators who might not know everything a deployer knows can still provide benefit to deployers by sharing what partial information they do know. +A second benefit to providing methods for communicating partial information is the reduction of bottlenecks or barriers to information exchange. +A timely partial warning is better than a complete warning that is too late. + +The basic guidance is that the analyst should communicate all of the vulnerability's possible states, to the best of the analyst's knowledge. +If the analyst knows nothing, all states are possible. +For example, [Utility](../../reference/decision_points/utility.md) may be [laborious](../../reference/decision_points/utility.md), [efficient](../../reference/decision_points/utility.md), or [super effective](../../reference/decision_points/system_exposure.md). +In abbreviated form, write this as `U:LESe`. +Since a capital letter always indicates a new value, this is unambiguous. + +The reason a stakeholder might publish something like `U:LESe` is that it expresses that the analyst thought about [Utility](../../reference/decision_points/utility.md) but does not have anything to communicate. +A stakeholder might have information to communicate about some decision points but not others. +If SSVC uses this format to list the values that are in play for a particular vulnerability, there is no need for a special “I don't know” marker. + +The merit in this “list all values” approach emerges when the stakeholder knows that the value for a decision point may be A or B, but not C. +For example, say the analyst knows that [*Value Density*](../../reference/decision_points/value_density.md) is [diffuse](../../reference/decision_points/value_density.md) but does not know the value for [Automatability](../../reference/decision_points/automatable.md). +Then the analyst can usefully restrict [Utility](../../reference/decision_points/utility.md) to one of [laborious](../../reference/decision_points/utility.md) or [efficient](../../reference/decision_points/utility.md). +In abbreviated form, write this as `U:LE`. +As discussed below, information can change over time. +Partial information may be, but is not required to be, sharpened over time into a precise value for the decision point. + +### Information Changes Over Time + +Vulnerability management decisions are dynamic, and may change over time as the available information changes. +Information changes are one reason why SSVC decisions should always be timestamped. +SSVC decision points have different temporal properties. +Some, such as [Utility](../../reference/decision_points/utility.md), are mostly static. +For [Utility](../../reference/decision_points/utility.md) to change, the market penetration or deployment norms of a vulnerable component would have to meaningfully change. +Some, such as [Exploitation](../../reference/decision_points/exploitation.md), may change quickly but only in one direction. + +Both of these examples are out of the direct control of the vulnerability manager. +Some, such as [System Exposure](../../reference/decision_points/system_exposure.md), change mostly due to actions taken by the organization managing the vulnerable component. +If the actor who can usually trigger a relevant change is the organization using SSVC, then it is relatively straightforward to know when to update the SSVC decision. +That is, the organization should reevaluate the decision when they make a relevant change. +For those decision points that are about topics outside the control of the organization using SSVC, then the organization should occasionally poll their information sources for changes. +The cadence or rate of polls is different for each decision point, based on the expected rate of change. + +We expect that updating information over time will be most useful where the evidence-gathering process can be automated. +Organizations that have mature asset management systems will also find this update process more efficient than those that do not. +For an organization without a mature asset management system, we would recommend putting organizational resources into maturing that function before putting effort into regular updates to vulnerability prioritization decision points. + +The following decision points are usually out of the control of the organization running SSVC. +As an initial heuristic, we suggest the associated polling frequency for each. +These frequencies can be customized, as the update frequency is directly related to the organization's tolerance for the risk that the information is out of date. +As discussed in [Tree Construction and Customization Guidance](../tree_customization.md), risk tolerance is unique to each organization. +Risk tolerance and risk appetite are primarily reflected in the priority labels (that is, decisions) encoded in the SSVC decision tree, but information polling frequency is also a risk tolerance decision and each organization may choose different time values. + +| Decision Point | Suggested Polling Frequency | +|--------------------------------------------------------------------------------|-----------------------------| +| [*Exploitation*](../../reference/decision_points/exploitation.md) | every 1 day | +| [*Technical Impact*](../../reference/decision_points/technical_impact.md) | never (should be static per vulnerability) | +| [*Utility*](../../reference/decision_points/utility.md) | every 6 months | +| [*Public Safety Impact*](../../reference/decision_points/public_safety_impact.md) | every 1 year | + + +The following decision points are usually in the control of the organization running SSVC and should be reevaluated when a relevant change is made or during annual reviews of assets. + + - [*Situated Safety Impact*](../../reference/decision_points/safety_impact.md) + - [*Mission Impact*](../../reference/decision_points/mission_impact.md) + - [*System Exposure*](../../reference/decision_points/system_exposure.md) + +If SSVC information is all timestamped appropriately (as discussed earlier in this section), then an analyst can compare the timestamp to the current date and determine whether information is considered stale. +The above rates are heuristic suggestions, and organizations may choose different ones. +Any public repository of vulnerability information should keep a change log of when values change for each decision point, for each vulnerability. +Vulnerability response analysts should keep such change logs as well. +Similar to logging practices recommended for incident response [@nist800-61r2], such practices make the process less error-prone and facilitate after-action reviews. diff --git a/docs/howto/communicating_results.md b/docs/howto/communicating_results.md deleted file mode 100644 index 5941090e..00000000 --- a/docs/howto/communicating_results.md +++ /dev/null @@ -1,98 +0,0 @@ -# Guidance on Communicating Results - -There are many aspects of SSVC that two parties might want to communicate. -Not every stakeholder will use the decision points to make comparable decisions. -Suppliers and deployers make interdependent decisions, but the actions of one group are not strictly dependent on the other. -Recall that one reason for this is that SSVC is about prioritizing a vulnerability response action in general, not specifically applying a patch that a supplier produced. -Coordinators are particularly interested in facilitating communication because that is their core function. -This section handles three aspects of this challenge: formats for communicating SSVC, how to handle partial or incomplete information, and how to handle information that may change over time. - -This section is about communicating SSVC information about a specific vulnerability. -Any stakeholder making a decision on allocating effort should have a decision tree with its decision points and possible values specified already. -[Representation choices](#representation-choices) and [Tree Construction and Customization Guidance](#tree-construction-and-customization-guidance) discussed how SSVC uses a text file as the canonical form of a decision tree; the example trees can be found in [SSVC/data](https://github.com/CERTCC/SSVC/tree/main/data). -This section discusses the situation where one stakeholder, usually a supplier or coordinator, wants to communicate some information about a specific vulnerability to other stakeholders or constituents. - -## Communication Formats - -We recommend a JSON format for communicating SSVC information about a specific vulnerability. -The goal of this format is to capture all the context and details about a decision or work item in a clear and machine-readable way. - -The [provision schema](https://github.com/CERTCC/SSVC/blob/main/data/schema/SSVC_Provision.schema.json) is equivalent to a decision tree and documents the full set of logical statements that a stakeholder uses to make decisions. -The [computed schema](https://github.com/CERTCC/SSVC/blob/main/data/schema/SSVC_Computed.schema.json) expresses a set of information about a work item or vulnerability at a point in time. -A computed schema should identify the provision schema used, so the options from which the information was computed are specified. - -Each element of `choices` should be an object that is a key-value pair of `decision point`:`value`, where the term `decision point` is a string derived from the name of the decision point as follows: - - Start with the decision point name as given in [Likely Decision Points and Relevant Data](#likely-decision-points-and-relevant-data). - - Remove any text in parentheses (and the parentheses themselves). - - Remove colon characters, if any (`:`). - - Convert the string to [lower camel case](https://en.wikipedia.org/wiki/Camel_case) by lowercasing the string, capitalizing any letter after a space, and removing all spaces. - -The `value` term is derived the same way as `decision point` except start with the value name as given in the relevant decision point subsection of [Likely Decision Points and Relevant Data](#likely-decision-points-and-relevant-data). - -## Partial or Incomplete Information - -What an analyst knows about a vulnerability may not be complete. -However, the vulnerability management community may still benefit from partial information. -In particular, suppliers and coordinators who might not know everything a deployer knows can still provide benefit to deployers by sharing what partial information they do know. -A second benefit to providing methods for communicating partial information is the reduction of bottlenecks or barriers to information exchange. -A timely partial warning is better than a complete warning that is too late. - -The basic guidance is that the analyst should communicate all of the vulnerability's possible states, to the best of the analyst's knowledge. -If the analyst knows nothing, all states are possible. -For example, [*Utility*](#utility) may be [laborious](#utility), [efficient](#utility), or [super effective](#utility). - -The reason a stakeholder might publish a decision point with all its possible values is that doing so expresses that the analyst thought about [*Utility*](#utility) but does not have anything to communicate. -A stakeholder might have information to communicate about some decision points but not others. -If SSVC uses this format to list the values that are in play for a particular vulnerability, there is no need for a special “I don't know” marker. - -The merit in this “list all values” approach emerges when the stakeholder knows that the value for a decision point may be A or B, but not C. -For example, say the analyst knows that [*Value Density*](#value-density) is [diffuse](#value-density) but does not know the value for [*Automatability*](#automatability). -Then the analyst can usefully restrict [*Utility*](#utility) to one of [laborious](#utility) or [efficient](#utility). -As discussed below, information can change over time. -Partial information may be, but is not required to be, sharpened over time into a precise value for the decision point. - -## Information Changes Over Time - -Vulnerability management decisions are dynamic, and may change over time as the available information changes. -Information changes are one reason why SSVC decisions should always be timestamped. -SSVC decision points have different temporal properties. -Some, such as [*Utility*](#utility), are mostly static. -For [*Utility*](#utility) to change, the market penetration or deployment norms of a vulnerable component would have to meaningfully change. -Some, such as [*State of Exploitation*](#state-of-exploitation), may change quickly but only in one direction. - -Both of these examples are out of the direct control of the vulnerability manager. -Some, such as [*Exposure*](#exposure), change mostly due to actions taken by the organization managing the vulnerable component. -If the actor who can usually trigger a relevant change is the organization using SSVC, then it is relatively straightforward to know when to update the SSVC decision. -That is, the organization should reevaluate the decision when they make a relevant change. -For those decision points that are about topics outside the control of the organization using SSVC, then the organization should occasionally poll their information sources for changes. -The cadence or rate of polls is different for each decision point, based on the expected rate of change. - -We expect that updating information over time will be most useful where the evidence-gathering process can be automated. -Organizations that have mature asset management systems will also find this update process more efficient than those that do not. -For an organization without a mature asset management system, we would recommend putting organizational resources into maturing that function before putting effort into regular updates to vulnerability prioritization decision points. - -The following decision points are usually out of the control of the organization running SSVC. -As an initial heuristic, we suggest the associated polling frequency for each. -These frequencies can be customized, as the update frequency is directly related to the organization's tolerance for the risk that the information is out of date. -As discussed in [Tree Construction and Customization Guidance](#tree-construction-and-customization-guidance), risk tolerance is unique to each organization. -Risk tolerance and risk appetite are primarily reflected in the priority labels (that is, decisions) encoded in the SSVC decision tree, but information polling frequency is also a risk tolerance decision and each organization may choose different time values. - -| Decision Point | Suggested Polling Frequency | -|--------------------------------------------------------------------------------|-----------------------------| -| [*Exploitation*](../reference/decision_points/exploitation.md) | every 1 day | -| [*Technical Impact*](../reference/decision_points/technical_impact.md) | never (should be static per vulnerability) | -| [*Utility*](../reference/decision_points/utility.md) | every 6 months | -| [*Public Safety Impact*](../reference/decision_points/public_safety_impact.md) | every 1 year | - - -The following decision points are usually in the control of the organization running SSVC and should be reevaluated when a relevant change is made or during annual reviews of assets. - - - [*Situated Safety Impact*](../reference/decision_points/safety_impact.md) - - [*Mission Impact*](../reference/decision_points/mission_impact.md) - - [*System Exposure*](../reference/decision_points/system_exposure.md) - -If SSVC information is all timestamped appropriately (as discussed earlier in this section), then an analyst can compare the timestamp to the current date and determine whether information is considered stale. -The above rates are heuristic suggestions, and organizations may choose different ones. -Any public repository of vulnerability information should keep a change log of when values change for each decision point, for each vulnerability. -Vulnerability response analysts should keep such change logs as well. -Similar to logging practices recommended for incident response [@nist800-61r2], such practices make the process less error-prone and facilitate after-action reviews. diff --git a/docs/howto/coordination_decisions.md b/docs/howto/coordination_decisions.md index 0221bb4f..0e6415d2 100644 --- a/docs/howto/coordination_decisions.md +++ b/docs/howto/coordination_decisions.md @@ -10,7 +10,7 @@ We take three priority levels in our decision about whether and how to coordinat ## Coordinator Decision Points Our goal with the coordination decision is to base it on information that is available to the analyst when CERT/CC receives a vulnerability report. -In addition to using some of the decision points in [Likely Decision Points](#likely-decision-points-and-relevant-data); coordination makes use of [Utility](#utility) and [Public Safety Impact](#public-safety-impact) decision points. +In addition to using some of the decision points in [Likely Decision Points](../reference/decision_points/index.md); coordination makes use of [Utility](../reference/decision_points/utility.md) and [Public Safety Impact](../reference/decision_points/public_safety_impact.md) decision points. The coordination and publication decisions for CERT/CC are about the social and collaborative state of vulnerability management. To assess this, the decision involves five new decision points. @@ -22,14 +22,26 @@ To assess this, the decision involves five new decision points. ## Coordination Triage Decision Process -The decision tree for reaching a [Decision](#coordination-triage-decisions) involves seven decision points. +The decision tree for reaching a [Decision](coordination_decisions.md) involves seven decision points. The first two function as gating questions: - - If a report is already public, then CERT/CC will decline the case unless there are multiple suppliers, [*super effective*](#utility) [*Utility*](#utility), and [*significant*](#public-safety-impact) [Public Safety Impact](#public-safety-impact). - - If no suppliers have been contacted, then CERT/CC will decline the case unless there are multiple suppliers, [*super effective*](#utility) [*Utility*](#utility), and [*significant*](#public-safety-impact) [Public Safety Impact](#public-safety-impact). + - If a report is already public, then CERT/CC will decline the case unless there are multiple suppliers, [*super effective*](../reference/decision_points/system_exposure.md) [Utility](../reference/decision_points/utility.md), and [*significant*](../reference/decision_points/public_safety_impact.md) [Public Safety Impact](../reference/decision_points/public_safety_impact.md). + - If no suppliers have been contacted, then CERT/CC will decline the case unless there are multiple suppliers, [*super effective*](../reference/decision_points/system_exposure.md) [Utility](../reference/decision_points/utility.md), and [*significant*](../reference/decision_points/public_safety_impact.md) [Public Safety Impact](../reference/decision_points/public_safety_impact.md). In the second case, CERT/CC may encourage the reporter to contact the supplier and submit a new case request if the supplier is unresponsive. These two sets of exceptional circumstances mean that the seven decision points involved in the coordination triage tree can be compressed slightly, as the tree shows. This tree's information is available as either a [CSV](https://github.com/CERTCC/SSVC/blob/main/data/ssvc_2_coord-triage.csv) or [PDF](https://github.com/CERTCC/SSVC/blob/main/doc/graphics/ssvc_2_coord-triage.pdf) -{% include-markdown './coordinator_trees.md' heading-offset=1 %} +## Triage Decision Tree + + + +This tree is a suggestion in that CERT/CC believes it works for us. +Other coordinators should consider customizing the tree to their needs, as described in [Tree Construction and Customization Guidance](tree_customization.md). + +### Table of Values + + +{{ read_csv('coord-triage-options.csv') }} diff --git a/docs/howto/coordinator_publish_tree.md b/docs/howto/coordinator_publish_tree.md deleted file mode 100644 index dc1d167b..00000000 --- a/docs/howto/coordinator_publish_tree.md +++ /dev/null @@ -1,124 +0,0 @@ -# Coordinator Publication Decision Tree - -Suggested decision values for this decision are available in [CSV](../../data/csvs/ssvc_2_coord-publish.csv) and [PDF](../pdf/ssvc_2_coord-publish.pdf) formats. - - - -```mermaid ---- -title: Coordinator Publication Tree ---- -flowchart LR - si[Supplier
Involvement] - e1[Exploitation] - e2[Exploitation] - e3[Exploitation] - si -->|fix ready| e1 - si -->|cooperative| e2 - si -->|uncooperative/
unresponsive| e3 - va1[Value
Added] - va2[Value
Added] - va3[Value
Added] - e1 -->|none| va1 - e1 -->|PoC| va2 - e1 -->|active| va3 - va4[Value
Added] - va5[Value
Added] - va6[Value
Added] - e2 -->|none| va4 - e2 -->|PoC| va5 - e2 -->|active| va6 - va7[Value
Added] - va8[Value
Added] - va9[Value
Added] - e3 -->|none| va7 - e3 -->|PoC| va8 - e3 -->|active| va9 - - p1[Publish] - p2[Don't Publish] - p3[Don't Publish] - - p4[Publish] - p5[Don't Publish] - p6[Don't Publish] - - p7[Publish] - p8[Publish] - p9[Don't Publish] - - p10[Publish] - p11[Don't Publish] - p12[Don't Publish] - - p13[Publish] - p14[Don't Publish] - p15[Don't Publish] - - p16[Publish] - p17[Publish] - p18[Don't Publish] - - p19[Publish] - p20[Don't Publish] - p21[Don't Publish] - - p22[Publish] - p23[Publish] - p24[Don't Publish] - - p25[Publish] - p26[Publish] - p27[Don't Publish] - - va1 -->|precedence| p1 - va1 -->|ampliative| p2 - va1 -->|limited| p3 - - va2 -->|precedence| p4 - va2 -->|ampliative| p5 - va2 -->|limited| p6 - - va3 -->|precedence| p7 - va3 -->|ampliative| p8 - va3 -->|limited| p9 - - va4 -->|precedence| p10 - va4 -->|ampliative| p11 - va4 -->|limited| p12 - - va5 -->|precedence| p13 - va5 -->|ampliative| p14 - va5 -->|limited| p15 - - va6 -->|precedence| p16 - va6 -->|ampliative| p17 - va6 -->|limited| p18 - - va7 -->|precedence| p19 - va7 -->|ampliative| p20 - va7 -->|limited| p21 - - va8 -->|precedence| p22 - va8 -->|ampliative| p23 - va8 -->|limited| p24 - - va9 -->|precedence| p25 - va9 -->|ampliative| p26 - va9 -->|limited| p27 - - - - - - -``` - -## Table of Values - -{{ read_csv('../../data/csvs/coord-publish-options.csv') }} - diff --git a/docs/howto/coordinator_trees.md b/docs/howto/coordinator_trees.md deleted file mode 100644 index 90640a33..00000000 --- a/docs/howto/coordinator_trees.md +++ /dev/null @@ -1,13 +0,0 @@ -# Triage Decision Tree - - - -This tree is a suggestion in that CERT/CC believes it works for us. -Other coordinators should consider customizing the tree to their needs, as described in [Tree Construction and Customization Guidance](#tree-construction-and-customization-guidance). - -## Table of Values - -{{ read_csv('../../data/csvs/coord-triage-options.csv') }} - diff --git a/docs/howto/deployer_tree.md b/docs/howto/deployer_tree.md index 23e8a10b..b5443224 100644 --- a/docs/howto/deployer_tree.md +++ b/docs/howto/deployer_tree.md @@ -10,4 +10,5 @@ The example deployer tree [PDF](../pdf/ssvc_2_deployer_SeEUMss.pdf) is depicted ## Table of Values -{{ read_csv('data/csvs/deployer-options.csv') }} \ No newline at end of file + +{{ read_csv('deployer-options.csv') }} \ No newline at end of file diff --git a/docs/howto/evidence_gathering.md b/docs/howto/evidence_gathering.md deleted file mode 100644 index fd4a67a6..00000000 --- a/docs/howto/evidence_gathering.md +++ /dev/null @@ -1,84 +0,0 @@ -# Guidance for Evidence Gathering - -To answer each of these decision points, a stakeholder should, as much as possible, have a repeatable evidence -collection and evaluation process. -However, we are proposing decisions for humans to make, so evidence collection and evaluation is not totally automatable. -That caveat notwithstanding, some automation is possible. - -!!! example "Evidence of Exploitation" - - For example, whether exploitation modules are available in ExploitDB, Metasploit, or other sources is straightforward. - We hypothesize that searching Github and Pastebin for exploit code can be captured in a script. - A supplier or deployer could then define [*Exploitation*](#exploitation) to take the value of [*PoC*](#exploitation) if - there are positive search results for a set of inputs derived from the CVE entry in at least one of these venues. - At least, for those vulnerabilities that are not “automatically” PoC-ready, such as on-path attackers for TLS or network - replays. - -Some of the decision points require a substantial upfront analysis effort to gather risk assessment or organizational -data. -However, once gathered, this information can be efficiently reused across many vulnerabilities and only refreshed -occasionally. - -!!! example "Evidence of Mission Impact" - - An obvious example of this is the mission impact decision point. - To answer this, a deployer must analyze their essential functions, how they interrelate, and how they are supported. - -!!! example "Evidence of Exposure" - - Exposure is similar; answering that decision point requires an asset inventory, adequate understanding of the network - topology, and a view of the enforced security controls. - Independently operated scans, such as Shodan or Shadowserver, may play a role in evaluating exposure, but the entire - exposure question cannot be reduced to a binary question of whether an organization’s assets appear in such databases. - -Once the deployer has the situational awareness to understand MEFs or exposure, selecting the answer for each individual -vulnerability is usually straightforward. - -Stakeholders who use the prioritization method should consider releasing the priority with which they handled the -vulnerability. -This disclosure has various benefits. -For example, if the supplier publishes a priority ranking, then deployers could consider that in their decision-making -process. -One reasonable way to include it is to break ties for the deployer. -If a deployer has three “scheduled” vulnerabilities to remediate, they may address them in any order. -If two vulnerabilities were produced by the supplier as “scheduled” patches, and one was “out-of-cycle,” then the -deployer may want to use that information to favor the latter. - -## Suggested Default Values - -In the case where no information is available or the organization has not yet matured its initial situational analysis, -we can suggest something like defaults for some decision points. - -!!! tip "Default Exposure Values" - - If the deployer does not know their exposure, that - means they do not know where the devices are or how they are controlled, so they should assume - [*System Exposure*](#system-exposure) is [*open*](#system-exposure). - -!!! tip "Default Safety Values" - - If the decision maker knows nothing about the environment in which the device is used, we suggest assuming a - [*major*](#safety-impact) [*Safety Impact*](#safety-impact). - This position is conservative, but software is thoroughly embedded in daily life now, so we suggest that the decision - maker provide evidence that no one’s well-being will suffer. - -The reach of software exploits is no longer limited to a research network. - -!!! tip "Default Mission Impact Values" - - Similarly, with [*Mission Impact*](#mission-impact), the deployer should assume that the software is in use at the - organization for a reason, and that it supports essential functions unless they have evidence otherwise. - With a total lack of information, assume [*support crippled*](#mission-impact) as a default. - [*Exploitation*](#exploitation) needs no special default; if adequate searches are made for exploit code and none is - found, the answer is [*none*](#exploitation). - - -!!! tip "Default Automatable Values" - - If nothing is known about [*Automatable*](#automatable), the safer answer to assume is [*yes*](#automatable). - [*Value Density*](#value-density) should always be answerable; if the product is uncommon, it is probably - [*diffuse*](#value-density). - -The resulting decision set `{none, open, yes, medium}` results in a scheduled patch application in our recommended -deployer tree. - diff --git a/docs/howto/index.md b/docs/howto/index.md index ec2d797a..bf6b5090 100644 --- a/docs/howto/index.md +++ b/docs/howto/index.md @@ -23,4 +23,23 @@ - how to integrate SSVC into existing processes - how to integrate data sources into SSVC decision points -{% include-markdown './prioritization.md' heading-offset=1 %} \ No newline at end of file +## Prioritization + +Given a specific stakeholder decision and set of useful decision points, we are now in a position to combine them into a comprehensive set of decisions about the priority with which to act. +The definition of choices can take a logical form, such as: + + - IF + - ([*Exploitation*](../reference/decision_points/exploitation.md) IS [PoC](../reference/decision_points/exploitation.md)) AND + - ([Exposure](../reference/decision_points/system_exposure.md) IS [controlled](../reference/decision_points/exploitation.md)) AND + - ([*Automatable*](../reference/decision_points/automatable.md) IS [no](../reference/decision_points/automatable.md)) AND + - ([*Human Impact*](../reference/decision_points/human_impact.md) IS [medium](../reference/decision_points/human_impact.md)) + - THEN priority is *scheduled*. + +This example logical statement is captured in (line 35 of the deployer `.csv` file)[https://github.com/CERTCC/SSVC/blob/main/data/csvs/deployer-options.csv#L35]. + +There are different formats for capturing these prioritization decisions depending on how and where they are going to be used. +In this paper, we primarily represent a full set of guidance on how one stakeholder will make a decision as a **decision tree**. +This section presents example trees for each stakeholder: supplier, deployer, and coordinator. +This section also provides some guidance on how to [construct and customize a decision tree](tree_customization.md) and [gather evidence](bootstrap/collect.md) to make decisions. +How this decision information might be stored or communicated is the topic of subsections on [Asset Management](../topics/asset_management.md) and [Communication](bootstrap/use.md). + diff --git a/docs/howto/prioritization.md b/docs/howto/prioritization.md deleted file mode 100644 index 64d04299..00000000 --- a/docs/howto/prioritization.md +++ /dev/null @@ -1,19 +0,0 @@ -# Prioritization - -Given a specific stakeholder decision and set of useful decision points, we are now in a position to combine them into a comprehensive set of decisions about the priority with which to act. -The definition of choices can take a logical form, such as: - - IF - - ([*Exploitation*](#exploitation) IS [PoC](#exploitation)) AND - - ([*Exposure*](#exposure) IS [controlled](#exploitation)) AND - - ([*Automatable*](#automatable) IS [no](#automatable)) AND - - ([*Human Impact*](#human-impact) IS [medium](#human-impact)) - - THEN priority is *scheduled*. - -This example logical statement is captured in (line 35 of the deployer `.csv` file)[https://github.com/CERTCC/SSVC/blob/main/data/csvs/deployer-options.csv#L35]. - -There are different formats for capturing these prioritization decisions depending on how and where they are going to be used. -In this paper, we primarily represent a full set of guidance on how one stakeholder will make a decision as a **decision tree**. -This section presents example trees for each stakeholder: supplier, deployer, and coordinator. -This section also provides some guidance on how to [construct and customize a decision tree](#tree-construction-and-customization-guidance) and [gather evidence](#evidence-gathering-guidance) to make decisions. -How this decision information might be stored or communicated is the topic of subsections on [Asset Management](#relationship-to-asset-management) and [Communication](#guidance-on-communicating-results). - diff --git a/docs/howto/publication_decision.md b/docs/howto/publication_decision.md index 64400f54..3b7c4afc 100644 --- a/docs/howto/publication_decision.md +++ b/docs/howto/publication_decision.md @@ -8,7 +8,7 @@ However, that is not the intended use case; this section describes how a coordin !!! tip "The Publication Decision is Time Sensitive" The publication decision is always a decision at a point in time. - As discussed in [Guidance on Communicating Results](#guidance-on-communicating-results), a SSVC decision may change over time as the inputs to that decision change. + As discussed in [Guidance on Communicating Results](bootstrap/use.md), a SSVC decision may change over time as the inputs to that decision change. A decision to publish cannot be revoked, since the publication is likely to be archived or at least remembered. However, a decision to not publish is a decision not to publish at the time the decision was made. It is not a decision never to publish in the future. @@ -23,14 +23,141 @@ As a matter of policy, CERT/CC will support an embargo from the public of inform - Other exceptions have not been met, including active exploitation of the vulnerability in the wild or other public discussion of the vulnerability details. Regardless, the decision described in this section assumes the embargo period is over, one way or another. -The second point is related to the [Coordination Triage Decisions](#coordination-triage-decisions) and the status of the vulnerability. -CERT/CC only expects to publish about vulnerabilities with a [*coordinate*](#coordination-triage-decisions) status. -While an issue that is tracked or declined may be reevaluated at a later date and status changed to [*coordinate*](#coordination-triage-decisions), unless that happens we would not publish about the vulnerability. -Other organizations, such as [NVD](https://nvd.nist.gov/), would have different publication criteria and may want to include decision points or the decision itself from the [Coordination Triage Decisions](#coordination-triage-decisions) in their publication decision. +The second point is related to the [Coordination Triage Decisions](coordination_decisions.md) and the status of the vulnerability. +CERT/CC only expects to publish about vulnerabilities with a [*coordinate*](coordination_decisions.md) status. +While an issue that is tracked or declined may be reevaluated at a later date and status changed to [*coordinate*](coordination_decisions.md), unless that happens we would not publish about the vulnerability. +Other organizations, such as [NVD](https://nvd.nist.gov/), would have different publication criteria and may want to include decision points or the decision itself from the [Coordination Triage Decisions](coordination_decisions.md) in their publication decision. -In addition to the two decision points defined in this section, the publication decision uses the [*Exploitation*](#exploitation) decision point. +In addition to the two decision points defined in this section, the publication decision uses the [*Exploitation*](../reference/decision_points/exploitation.md) decision point. - [Public Value Added](../reference/decision_points/public_value_added.md) - [Supplier Involvement](../reference/decision_points/supplier_involvement.md) -{% include-markdown "./coordinator_publish_tree.md" heading-offset=1 %} \ No newline at end of file +## Coordinator Publication Decision Tree + +Suggested decision values for this decision are available in +[CSV](https://github.com/CERTCC/SSVC/blob/main/data/csvs/coord-publish-options.csv) +and +[PDF](../pdf/ssvc_2_coord-publish.pdf) formats. + + + +```mermaid +--- +title: Coordinator Publication Tree +--- +flowchart LR + si[Supplier
Involvement] + e1[Exploitation] + e2[Exploitation] + e3[Exploitation] + si -->|fix ready| e1 + si -->|cooperative| e2 + si -->|uncooperative/
unresponsive| e3 + va1[Value
Added] + va2[Value
Added] + va3[Value
Added] + e1 -->|none| va1 + e1 -->|PoC| va2 + e1 -->|active| va3 + va4[Value
Added] + va5[Value
Added] + va6[Value
Added] + e2 -->|none| va4 + e2 -->|PoC| va5 + e2 -->|active| va6 + va7[Value
Added] + va8[Value
Added] + va9[Value
Added] + e3 -->|none| va7 + e3 -->|PoC| va8 + e3 -->|active| va9 + + p1[Publish] + p2[Don't Publish] + p3[Don't Publish] + + p4[Publish] + p5[Don't Publish] + p6[Don't Publish] + + p7[Publish] + p8[Publish] + p9[Don't Publish] + + p10[Publish] + p11[Don't Publish] + p12[Don't Publish] + + p13[Publish] + p14[Don't Publish] + p15[Don't Publish] + + p16[Publish] + p17[Publish] + p18[Don't Publish] + + p19[Publish] + p20[Don't Publish] + p21[Don't Publish] + + p22[Publish] + p23[Publish] + p24[Don't Publish] + + p25[Publish] + p26[Publish] + p27[Don't Publish] + + va1 -->|precedence| p1 + va1 -->|ampliative| p2 + va1 -->|limited| p3 + + va2 -->|precedence| p4 + va2 -->|ampliative| p5 + va2 -->|limited| p6 + + va3 -->|precedence| p7 + va3 -->|ampliative| p8 + va3 -->|limited| p9 + + va4 -->|precedence| p10 + va4 -->|ampliative| p11 + va4 -->|limited| p12 + + va5 -->|precedence| p13 + va5 -->|ampliative| p14 + va5 -->|limited| p15 + + va6 -->|precedence| p16 + va6 -->|ampliative| p17 + va6 -->|limited| p18 + + va7 -->|precedence| p19 + va7 -->|ampliative| p20 + va7 -->|limited| p21 + + va8 -->|precedence| p22 + va8 -->|ampliative| p23 + va8 -->|limited| p24 + + va9 -->|precedence| p25 + va9 -->|ampliative| p26 + va9 -->|limited| p27 + + + + + + +``` + +### Table of Values + + +{{ read_csv('coord-publish-options.csv') }} + diff --git a/docs/howto/supplier_tree.md b/docs/howto/supplier_tree.md index deb6c3b2..9c0bde6b 100644 --- a/docs/howto/supplier_tree.md +++ b/docs/howto/supplier_tree.md @@ -14,4 +14,5 @@ height = "700" /> ## Table of Values -{{ read_csv('data/csvs/supplier-options.csv') }} \ No newline at end of file + +{{ read_csv('supplier-options.csv') }} \ No newline at end of file diff --git a/docs/howto/tree_customization.md b/docs/howto/tree_customization.md index 66241324..f028a7b5 100644 --- a/docs/howto/tree_customization.md +++ b/docs/howto/tree_customization.md @@ -8,7 +8,7 @@ In this section, we'll cover what a stakeholder should leave static, what we ima ## Use Existing Decision Points Where Possible We suggest that the decision points, their definitions, and the decision values should not be customized. -Different vulnerability management teams inevitably think of topics such as [*Utility*](#utility) to the adversary in slightly different ways. +Different vulnerability management teams inevitably think of topics such as [Utility](../reference/decision_points/utility.md) to the adversary in slightly different ways. However, a key contribution of SSVC is enabling different teams to communicate about their decision process. In order to clearly communicate differences in the process, the decision points that factor into the process need to be the same between different teams. A stakeholder community may come together and, if there is broad consensus, add or change decision points. @@ -26,7 +26,18 @@ The other aspect of risk management that SSVC allows a team to customize is its ### Customizing for Risk Appetite A team's risk appetite is reflected directly by the priority labels for each combination of decision values. -For example, a vulnerability with [no or minor](#public-safety-impact) [*Public Safety Impact*](#public-safety-impact), [total](#technical-impact) [*Technical Impact*](#technical-impact), and [efficient](#utility) [*Utility*](#utility) might be handled with [*scheduled*](#supplier-decisions) priority by one team and [*out-of-cycle*](#supplier-decisions) priority by another. +For example, a vulnerability with +[no or minor](../reference/decision_points/public_safety_impact.md) +[*Public Safety Impact*](../reference/decision_points/public_safety_impact.md), +[total](../reference/decision_points/technical_impact.md) +[*Technical Impact*](../reference/decision_points/technical_impact.md), +and [efficient](../reference/decision_points/utility.md) +[Utility](../reference/decision_points/utility.md) +might be handled with +[*scheduled*](../topics/enumerating_actions.md) +priority by one team and +[*out-of-cycle*](../topics/enumerating_actions.md) +priority by another. As long as each team has documented this choice and is consistent in its own application of its own choice, the two teams can legitimately have different appetites for vulnerability risk. SSVC enables teams with such different risk appetites to discuss and communicate precisely the circumstances where they differ. @@ -133,22 +144,22 @@ One might think of them as global facts that form the background context in whic Nearly all stakeholders should agree on the assignment of specific values to these decision points. - **Stakeholder-specific decision points** are expected to be contextual to some set of stakeholders. Information about a stakeholder-specific decision point can still be inherited by other stakeholders using the same tree. -For example in the corporate CSIRT scenario above, the [*System Exposure*](#system-exposure) value might be consistent across all subsidiaries for a centrally managed service. +For example in the corporate CSIRT scenario above, the [*System Exposure*](../reference/decision_points/system_exposure.md) value might be consistent across all subsidiaries for a centrally managed service. We generally consider the following decision points to be *stakeholder-agnostic*: -- [*Exploitation*](#exploitation) -- [*Technical Impact*](#technical-impact) -- [*Automatable*](#automatable) +- [*Exploitation*](../reference/decision_points/exploitation.md) +- [*Technical Impact*](../reference/decision_points/technical_impact.md) +- [*Automatable*](../reference/decision_points/automatable.md) On the contrary, we consider the following decision points to be *stakeholder-specific*: -- [*Value Density*](#value-density) -- [*Utility*](#utility) -- [*Safety Impact*](#safety-impact) -- [*Public Safety Impact*](#public-safety-impact) -- [*Situated Safety Impact*](#situated-safety-impact) -- [*Mission Impact*](#mission-impact) -- [*Human Impact*](#human-impact) -- [*System Exposure*](#system-exposure) +- [*Value Density*](../reference/decision_points/value_density.md) +- [Utility](../reference/decision_points/utility.md) +- [*Safety Impact*](../reference/decision_points/safety_impact.md) +- [*Public Safety Impact*](../reference/decision_points/public_safety_impact.md) +- [*Situated Safety Impact*](../reference/decision_points/safety_impact.md) +- [*Mission Impact*](../reference/decision_points/mission_impact.md) +- [*Human Impact*](../reference/decision_points/human_impact.md) +- [*System Exposure*](../reference/decision_points/system_exposure.md) We anticipate that most custom decision points created by stakeholders for themselves or a constituency will be of the *stakeholder-specific* variety. Examples of these sorts of custom decision points include diff --git a/docs/index.md b/docs/index.md index 0002a49a..3aa6fd88 100644 --- a/docs/index.md +++ b/docs/index.md @@ -26,7 +26,7 @@ We have organized the SSVC documentation into four main sections: Get started learning about SSVC and how it can help you prioritize vulnerabilities. This section is intended for people who are new to SSVC. - [:octicons-arrow-right-24: Learning SSVC](tutorials) + [:octicons-arrow-right-24: Learning SSVC](tutorials/index.md) - :fontawesome-solid-book:{ .lg .middle } __Learn More about SSVC__ @@ -35,7 +35,7 @@ We have organized the SSVC documentation into four main sections: Dig deeper to understand the SSVC methodology and how it works. This section is intended for people who are already familiar with SSVC and want to learn more. - [:octicons-arrow-right-24: Understanding SSVC](topics) + [:octicons-arrow-right-24: Understanding SSVC](topics/index.md) - :material-clipboard-check:{ .lg .middle } __SSVC How To__ @@ -44,7 +44,7 @@ We have organized the SSVC documentation into four main sections: Start using SSVC in your organization today with step-by-step instructions. This section is intended for people who are already familiar with SSVC and want to start using it. - [:octicons-arrow-right-24: SSVC How To](howto) + [:octicons-arrow-right-24: SSVC How To](howto/index.md) - :material-book-open-page-variant:{ .lg .middle } __SSVC Reference__ @@ -53,6 +53,6 @@ We have organized the SSVC documentation into four main sections: Reference documentation for SSVC. This section is intended for people who are already familiar with SSVC and want to look up specific details. - [:octicons-arrow-right-24: Reference](reference) + [:octicons-arrow-right-24: Reference](reference/index.md) \ No newline at end of file diff --git a/docs/reference/decision_points/automatable.md b/docs/reference/decision_points/automatable.md index 2447a082..9b74a09b 100644 --- a/docs/reference/decision_points/automatable.md +++ b/docs/reference/decision_points/automatable.md @@ -8,7 +8,7 @@ [Utility](./utility.md) -[*Automatable*](#automatable) captures the answer to the question “Can an attacker reliably automate creating exploitation events for this vulnerability?” +*Automatable* captures the answer to the question “Can an attacker reliably automate creating exploitation events for this vulnerability?” !!! question "What are Steps 1-4 of the Kill Chain?" @@ -34,34 +34,34 @@ Due to vulnerability chaining, there is some nuance as to whether reconnaissance !!! example "Vulnerability Chaining" For example, consider a vulnerability A. - If the systems vulnerable to A are usually not openly connected to incoming traffic (that is, [*Exposure*](#exposure) is [small](#exposure) or [controlled](#exposure)), reconnaissance probably cannot be automated (scans would be blocked, etc.). This would make Automatable equal to [no](#automatable) for vulnerability A. - However, suppose that another vulnerability B where Automatable is equal to [yes](#automatiability) can be reliably used to chain to vulnerability A. + If the systems vulnerable to A are usually not openly connected to incoming traffic (that is, [Exposure](system_exposure.md) is [small](system_exposure.md) or [controlled](system_exposure.md)), reconnaissance probably cannot be automated (scans would be blocked, etc.). This would make Automatable equal to [no](automatable.md) for vulnerability A. + However, suppose that another vulnerability B where Automatable is equal to _yes_ can be reliably used to chain to vulnerability A. This automates the _reconnaissance_ of vulnerable systems. In this situation, the analyst should continue to analyze vulnerability A to understand whether the remaining steps in the kill chain can be automated. !!! tip "Gathering Information About Automatable" An analyst should be able to sketch the automation scenario and how it either does or does not satisfy each of the four kill chain steps. - Once one step is not satisfied, the analyst can stop and select [*no*](#automatable). + Once one step is not satisfied, the analyst can stop and select [*no*](automatable.md). Code that demonstrably automates all four kill chain steps certainly satisfies as a sketch. - We say sketch to indicate that plausible arguments, such as convincing psuedocode of an automation pathway for each step, are also adequate evidence in favor of a [*yes*](#automatable) to [*Automatable*](#automatable). + We say sketch to indicate that plausible arguments, such as convincing psuedocode of an automation pathway for each step, are also adequate evidence in favor of a [*yes*](automatable.md) to *Automatable*. - Like all SSVC decision points, [*Automatable*](#automatable) should capture the analyst's best understanding of plausible scenarios at the time of the analysis. + Like all SSVC decision points, *Automatable* should capture the analyst's best understanding of plausible scenarios at the time of the analysis. An answer of *no* does not mean that it is absolutely inconceivable to automate exploitation in any scenario. It means the analyst is not able to sketch a plausible path through all four kill chain steps. “Plausible” sketches should account for widely deployed network and host-based defenses. Liveness of Internet-connected services means quite a few overlapping things [@bano2018scanning]. For most vulnerabilities, an open port does not automatically mean that reconnaissance, weaponization, and delivery are automatable. Furthermore, discovery of a vulnerable service is not automatable in a situation where only two hosts are misconfigured to expose the service out of 2 million hosts that are properly configured. - As discussed in in [Reasoning Steps Forward](#reasoning-steps-forward), the analyst should consider *credible* effects based on *known* use cases of the software system to be pragmatic about scope and providing values to decision points. + As discussed in in [Reasoning Steps Forward](../../topics/scope.md), the analyst should consider *credible* effects based on *known* use cases of the software system to be pragmatic about scope and providing values to decision points. ## Prior Versions {% include-markdown "../../_generated/decision_points/virulence_1_0_0.md" %} -!!! warning "Virulence is Superseded by Automatable" +!!! warning "*Virulence* is Superseded by *Automatable*" - Virulence is superseded by Automatable, which clarified the concept we + *Virulence* is superseded by *Automatable*, which clarified the concept we we were attempting to capture. \ No newline at end of file diff --git a/docs/reference/decision_points/exploitation.md b/docs/reference/decision_points/exploitation.md index 1f014488..4b99c7ec 100644 --- a/docs/reference/decision_points/exploitation.md +++ b/docs/reference/decision_points/exploitation.md @@ -7,39 +7,40 @@ The intent of this measure is the present state of exploitation of the vulnerabi !!! tip "Gathering Information About Exploitation" [@householder2020historical] presents a method for searching the GitHub repositories of open-source exploit databases. - This method could be employed to gather information about whether [PoC](#exploitation) is true. - However, part (3) of [PoC](#exploitation) would not be represented in such a search, so more information gathering would be needed. + This method could be employed to gather information about whether *PoC* is true. + However, part (3) of *PoC* would not be represented in such a search, so more information gathering would be needed. For part (3), one approach is to construct a mapping of CWE-IDs which always represent vulnerabilities with well-known methods of exploitation. We provide a list of possible CWE-IDs for this purpose below. - Gathering information for [active](#exploitation) is a bit harder. + Gathering information for *active* is a bit harder. If the vulnerability has a name or public identifier (such as a CVE-ID), a search of news websites, Twitter, the vendor's vulnerability description, and public vulnerability databases for mentions of exploitation is generally adequate. - However, if the organization has the ability to detect exploitation attempts—for instance, through reliable and precise IDS signatures based on a public PoC—then detection of exploitation attempts also signals that [active](#exploitation) is the right choice. + However, if the organization has the ability to detect exploitation attempts—for instance, through reliable and precise IDS signatures based on a public *PoC*—then detection of exploitation attempts also signals that *active* is the right choice. Determining which vulnerability a novel piece of malware uses may be time consuming, requiring reverse engineering and a lot of trial and error. Additionally, capable incident detection and analysis capabilities are required to make reverse engineering possible. Because most organizations do not conduct these processes fully for most incidents, information about which vulnerabilities are being actively exploited generally comes from public reporting by organizations that do conduct these processes. As long as those organizations also share detection methods and signatures, the results are usually quickly corroborated by the community. - For these reasons, we assess public reporting by established security community members to be a good information source for [active](#exploitation); however, one should not assume it is complete. + For these reasons, we assess public reporting by established security community members to be a good information source for *active*; however, one should not assume it is complete. - The description for [none](#exploitation) says that there is no **evidence** of active exploitation. + The description for *none* says that there is no **evidence** of *active* exploitation. This framing admits that an analyst may not be able to detect or know about every attack. - An analyst should feel comfortable selecting [none](#exploitation) if they (or their search scripts) have performed searches in the appropriate places for public PoCs and active exploitation (as described above) and found none. - Acknowledging that [*Exploitation*](#exploitation) values can change relatively quickly, we recommend conducting these searches frequently: if they can be automated to the organization's satisfaction, perhaps once a day (see also [Guidance on Communicating Results](#guidance-on-communicating-results)). + Acknowledging that *Exploitation* values can change relatively quickly, we recommend conducting these searches frequently: if they can be automated to the organization's satisfaction, perhaps once a day (see also [Guidance on Communicating Results](../../howto/bootstrap/use.md)). + An analyst should feel comfortable selecting *none* if they (or their search scripts) have performed searches in the appropriate places for public *PoC*s and *active* exploitation (as described above) and found *none*. + Acknowledging that *Exploitation*. -## CWE-IDs for PoC +## CWE-IDs for *PoC* -The table below lists CWE-IDs that could be used to mark a vulnerability as [PoC](#exploitation) if the vulnerability is described by the CWE-ID. +The table below lists CWE-IDs that could be used to mark a vulnerability as *PoC* if the vulnerability is described by the CWE-ID. !!! example "CWE-295" For example, CWE-295, [Improper Certificate Validation ](https://cwe.mitre.org/data/definitions/295.html), and its child CWEs, describe improper validation of TLS certificates. These CWE-IDs could - always be marked as [PoC](#exploitation) since that meets condition (3) in + always be marked as *PoC* since that meets condition (3) in the definition. - -{{ read_csv('../../../data/csvs/cwe/possible-cwe-with-poc-examples.csv') }} + +{{ read_csv('cwe/possible-cwe-with-poc-examples.csv') }} --- \ No newline at end of file diff --git a/docs/reference/decision_points/human_impact.md b/docs/reference/decision_points/human_impact.md index 911c8244..e5eb7c95 100644 --- a/docs/reference/decision_points/human_impact.md +++ b/docs/reference/decision_points/human_impact.md @@ -4,15 +4,15 @@ !!! tip "See also" - Human Impact is a combination of [Safety Impact](./safety_impact.md) and + *Human Impact* is a combination of [Safety Impact](./safety_impact.md) and [Mission Impact](./mission_impact.md) This is a compound decision point, therefore it is a notational convenience. In pilot implementations of SSVC, we received feedback that organizations tend to think of mission and safety impacts as if they were combined into a single factor: in other words, the priority increases regardless which of the two impact factors was increased. -We therefore combine [Safety Impact](../safety_impact.md) and -[Mission Impact](../mission_impact.md) for deployers into a single _Human Impact_ factor +We therefore combine [Safety Impact](safety_impact.md) and +[Mission Impact](mission_impact.md) for deployers into a single _Human Impact_ factor as a dimension reduction step as follows. We observe that the day-to-day operations of an organization often have already built in a degree of tolerance to small-scale variance in mission impacts. Thus in our opinion we need only concern ourselves with discriminating well at the upper end of the scale. @@ -35,7 +35,7 @@ Therefore, vulnerability information providers—that is, vulnerability data Information Sharing and Analysis Organizations (ISAOs), or Information Sharing and Analysis Centers (ISACs)—may provide SSVC information tailored as appropriate to their constituency's safety and mission concerns. For considerations on how organizations might communicate SSVC information to their constituents, -see [Guidance on Communicating Results](../../../howto/communicating_results.md). +see [Guidance on Communicating Results](../../howto/bootstrap/use.md). ## Prior Versions diff --git a/docs/reference/decision_points/mission_impact.md b/docs/reference/decision_points/mission_impact.md index 68619f8b..ca2a05c7 100644 --- a/docs/reference/decision_points/mission_impact.md +++ b/docs/reference/decision_points/mission_impact.md @@ -35,8 +35,8 @@ There are various sources of guidance on how to gather this information; see for This is part of risk management more broadly. It should require the vulnerability management team to interact with more senior management to understand mission priorities and other aspects of risk mitigation. -As a heuristic, [*Utility*](#utility) might constrain [*Mission Impact*](#mission-impact) if both are not used in the same decision tree. -For example, if the [*Utility*](#utility) is [*super effective*](#utility), then [*Mission Impact*](#mission-impact) is at least [*MEF support crippled*](#mission-impact). +As a heuristic, [Utility](utility.md) might constrain [*Mission Impact*](mission_impact.md) if both are not used in the same decision tree. +For example, if the [Utility](utility.md) is [*super effective*](utility.md), then [*Mission Impact*](mission_impact.md) is at least [*MEF support crippled*](mission_impact.md). ## Prior Versions diff --git a/docs/reference/decision_points/public_safety_impact.md b/docs/reference/decision_points/public_safety_impact.md index 1da132b5..1f26a47d 100644 --- a/docs/reference/decision_points/public_safety_impact.md +++ b/docs/reference/decision_points/public_safety_impact.md @@ -8,11 +8,11 @@ This is a compound decision point, therefore it is a notational convenience. -Suppliers necessarily have a rather coarse-grained perspective on the broadly defined [Safety Impact](../safety_impact.md) Decision Point. +Suppliers necessarily have a rather coarse-grained perspective on the broadly defined [Safety Impact](safety_impact.md) Decision Point. Therefore we simplify the above into a binary categorization: - _Significant_ is when any impact meets the criteria for an impact of Marginal, Critical, or Catastrophic in the - [Safety Impact](../safety_impact.md) table. + [Safety Impact](safety_impact.md) table. - _Minimal_ is when none do. ## Prior Versions diff --git a/docs/reference/decision_points/public_value_added.md b/docs/reference/decision_points/public_value_added.md index 1266c626..03507837 100644 --- a/docs/reference/decision_points/public_value_added.md +++ b/docs/reference/decision_points/public_value_added.md @@ -2,9 +2,11 @@ {% include-markdown "../../_generated/decision_points/public_value_added.md" %} -The intent of the definition is that one rarely if ever transitions from limited to ampliative or ampliative to precedence. -A vulnerability could transition from precedence to ampliative and ampliative to limited. -That is, [*Public Value Added*](#public-value-added) should only be downgraded through future iterations or re-evaluations. -This directionality is because once other organizations make something public, they cannot effectively un-publish it (it'll be recorded and people will know about it, even if they take down a webpage). -The rare case where [*Public Value Added*](#public-value-added) increases would be if an organization published viable information, but then published additional misleading or obscuring information at a later time. -Then one might go from [*limited*](#public-value-added) to [*ampliative*](#public-alue-added) in the interest of pointing to the better information. +The intent of the definition is that one rarely if ever transitions from _limited_ to _ampliative_ or _ampliative_ to _precedence_. +A vulnerability could transition from _precedence_ to _ampliative_ and _ampliative_ to _limited_. +That is, *Public Value Added* should only be downgraded through future iterations or re-evaluations. +This directionality is because once other organizations make something public, they cannot effectively un-publish it +(it'll be recorded and people will know about it, even if they take down a webpage). +The rare case where *Public Value Added* increases would be if an organization published viable information, but +then published additional misleading or obscuring information at a later time. +Then one might go from *limited* to *ampliative* in the interest of pointing to the better information. diff --git a/docs/reference/decision_points/safety_impact.md b/docs/reference/decision_points/safety_impact.md index ccc4c5c7..41cd2eb4 100644 --- a/docs/reference/decision_points/safety_impact.md +++ b/docs/reference/decision_points/safety_impact.md @@ -9,7 +9,7 @@ - [Public Safety Impact](./public_safety_impact.md) provides a simplified version of this decision point. -We take an expansive view of safety, in which a safety violation is a violation of what the United States [Centers for Disease Control (CDC)](https://www.cdc.gov/hrqol/wellbeing.htm#three) calls **well-being**. Physical well-being violations are common safety violations, but we also consider economic, social, emotional, and psychological well-being to be important. Weighing fine differences among these categories is probably not possible, so we will not try. Each decision option lists examples of the effects that qualify for that value/answer in the various types of violations of well-being. These examples should not be considered comprehensive or exhaustive, but rather as suggestive. +We take an expansive view of safety, in which a safety violation is a violation of what the United States [Centers for Disease Control (CDC)](https://www.cdc.gov/hrqol/wellbeing.htm) calls **well-being**. Physical well-being violations are common safety violations, but we also consider economic, social, emotional, and psychological well-being to be important. Weighing fine differences among these categories is probably not possible, so we will not try. Each decision option lists examples of the effects that qualify for that value/answer in the various types of violations of well-being. These examples should not be considered comprehensive or exhaustive, but rather as suggestive. @@ -208,8 +208,8 @@ resiliency ### Situated Safety Impact -Deployers are anticipated to have a more fine-grained perspective on the safety impacts broadly defined in [Safety Impact](#table-safety-impact). -We defer this topic for now because we combine it with [*Mission Impact*](#mission-impact) to simplify implementation for deployers. +Deployers are anticipated to have a more fine-grained perspective on the safety impacts broadly defined in *Safety Impact*. +We defer this topic for now because we combine it with [*Mission Impact*](mission_impact.md) to simplify implementation for deployers. ## Prior Versions diff --git a/docs/reference/decision_points/system_exposure.md b/docs/reference/decision_points/system_exposure.md index 5bdae556..9ada4318 100644 --- a/docs/reference/decision_points/system_exposure.md +++ b/docs/reference/decision_points/system_exposure.md @@ -15,24 +15,24 @@ Whether that mitigation allows the deployer to defer further action varies accor ## Gathering Information About System Exposure -[*System Exposure*](#system-exposure) is primarily used by Deployers, so the question is about whether some specific system is in fact exposed, not a hypothetical or aggregate question about systems of that type. +*System Exposure* is primarily used by Deployers, so the question is about whether some specific system is in fact exposed, not a hypothetical or aggregate question about systems of that type. Therefore, it generally has a concrete answer, even though it may vary from vulnerable component to vulnerable component, based on their respective configurations. -[*System Exposure*](#system-exposure) can be readily informed by network scanning techniques. -For example, if the vulnerable component is visible on [Shodan](https://www.shodan.io) or by some other external scanning service, then it is [*open*](#system-exposure). +*System Exposure* can be readily informed by network scanning techniques. +For example, if the vulnerable component is visible on [Shodan](https://www.shodan.io) or by some other external scanning service, then it is *open*. Network policy or diagrams are also useful information sources, especially for services intentionally open to the Internet such as public web servers. -An analyst should also choose [*open*](#system-exposure) for a phone or PC that connects to the web or email without the usual protections (IP and URL blocking, updated firewalls, etc.). +An analyst should also choose *open* for a phone or PC that connects to the web or email without the usual protections (IP and URL blocking, updated firewalls, etc.). -Distinguishing between [*small*](#system-exposure) and [*controlled*](#system-exposure) is more nuanced. -If [*open*](#system-exposure) has been ruled out, some suggested heuristics for differentiating the other two are as follows. +Distinguishing between *small* and *controlled* is more nuanced. +If *open* has been ruled out, some suggested heuristics for differentiating the other two are as follows. Apply these heuristics in order and stop when one of them applies. - - If the system's networking and communication interfaces have been physically removed or disabled, choose [*small*](#system-exposure). - - If [*Automatable*](#automatable) is [*yes*](#automatable), then choose [*controlled*](#system-exposure). The reasoning behind this heuristic is that if reconnaissance through exploitation is automatable, then the usual deployment scenario exposes the system sufficiently that access can be automated, which contradicts the expectations of [*small*](#system-exposure). - - If the vulnerable component is on a network where other hosts can browse the web or receive email, choose [*controlled*](#system-exposure). - - If the vulnerable component is in a third party library that is unreachable because the feature is unused in the surrounding product, choose [*small*](#system-exposure). + - If the system's networking and communication interfaces have been physically removed or disabled, choose *small*. + - If [*Automatable*](automatable.md) is [*yes*](automatable.md), then choose *controlled*. The reasoning behind this heuristic is that if reconnaissance through exploitation is automatable, then the usual deployment scenario exposes the system sufficiently that access can be automated, which contradicts the expectations of *small*. + - If the vulnerable component is on a network where other hosts can browse the web or receive email, choose *controlled*. + - If the vulnerable component is in a third party library that is unreachable because the feature is unused in the surrounding product, choose *small*. The unreachable vulnerable component scenario may be a point of concern for stakeholders like patch suppliers who often find it more cost-effective to simply update the included library to an existing fixed version rather than try to explain to customers why the vulnerable code is unreachable in their own product. -In those cases, we suggest the stakeholder reviews the decision outcomes of the tree to ensure the appropriate action is taken (paying attention to [_defer_](#supplier-tree) vs [_scheduled_](#supplier-tree), for example). +In those cases, we suggest the stakeholder reviews the decision outcomes of the tree to ensure the appropriate action is taken (paying attention to [_defer_](../../howto/supplier_tree.md) vs [_scheduled_](../../howto/supplier_tree.md), for example). If you have suggestions for further heuristics, or potential counterexamples to these, please describe the example and reasoning in an issue on the [SSVC GitHub](https://github.com/CERTCC/SSVC/issues). diff --git a/docs/reference/decision_points/technical_impact.md b/docs/reference/decision_points/technical_impact.md index 816c2e45..b47fe2d3 100644 --- a/docs/reference/decision_points/technical_impact.md +++ b/docs/reference/decision_points/technical_impact.md @@ -2,11 +2,11 @@ {% include-markdown "../../_generated/decision_points/technical_impact.md" %} -When evaluating [*Technical Impact*](#technical-impact), recall the scope definition in the [Scope Section](#scope). +When evaluating [*Technical Impact*](technical_impact.md), recall the scope definition in the [Scope Section](../../topics/scope.md). Total control is relative to the affected component where the vulnerability resides. If a vulnerability discloses authentication or authorization credentials to the system, this information disclosure should also be scored as “total” if those credentials give an adversary total control of the component. -As mentioned in [Current State of Practice](#current-state-of-practice), the scope of SSVC is just those situations in which there is a vulnerability. +As mentioned in [Current State of Practice](../../topics/state_of_practice.md), the scope of SSVC is just those situations in which there is a vulnerability. Our definition of **vulnerability** is based on the determination that some security policy is violated. We consider a security policy violation to be a technical impact—or at least, a security policy violation must have some technical instantiation. Therefore, if there is a vulnerability then there must be some technical impact. @@ -14,7 +14,7 @@ Therefore, if there is a vulnerability then there must be some technical impact. !!! tip "Gathering Information About Technical Impact" - Assessing [*Technical Impact*](#technical-impact) amounts to assessing the degree of control over the vulnerable component the attacker stands to gain by exploiting the vulnerability. + Assessing [*Technical Impact*](technical_impact.md) amounts to assessing the degree of control over the vulnerable component the attacker stands to gain by exploiting the vulnerability. One way to approach this analysis is to ask whether the control gained is *total* or not. If it is not total, it is *partial*. If an answer to one of the following questions is _yes_, then control is *total*. @@ -25,5 +25,5 @@ Therefore, if there is a vulnerability then there must be some technical impact. - does the attacker get an account with full privileges to the vulnerable component (administrator or root user accounts, for example)? This list is an evolving set of heuristics. - If you find a vulnerability that should have [*total*](#technical-impact) [*Technical Impact*](#technical-impact) but that does not answer yes to any of these questions, please describe the example and what question we might add to this list in an issue on the [SSVC GitHub](https://github.com/CERTCC/SSVC/issues). + If you find a vulnerability that should have [*total*](technical_impact.md) [*Technical Impact*](technical_impact.md) but that does not answer yes to any of these questions, please describe the example and what question we might add to this list in an issue on the [SSVC GitHub](https://github.com/CERTCC/SSVC/issues). diff --git a/docs/reference/decision_points/utility.md b/docs/reference/decision_points/utility.md index 8d87e036..d394b7dc 100644 --- a/docs/reference/decision_points/utility.md +++ b/docs/reference/decision_points/utility.md @@ -21,7 +21,7 @@ This framing makes it easier to analytically derive these categories from a desc [*Automatable*](automatable.md) as ([*no*](automatable.md) or [*yes*](automatable.md)) and [*Value Density*](value_density.md) as ([*diffuse*](value_density.md) or [*concentrated*](value_density.md)) define those decision points. Roughly, *Utility* is a combination of two things: (1) the value of each exploitation event and (2) the ease and speed with which the adversary can cause exploitation events. -We define *Utility* as laborious, efficient, or super effective, as described in the [table](#table-utility) above. +We define *Utility* as laborious, efficient, or super effective, as described in the table above. ## Alternative Utility Outputs diff --git a/docs/reference/decision_points/value_density.md b/docs/reference/decision_points/value_density.md index 1a49e85a..934231f6 100644 --- a/docs/reference/decision_points/value_density.md +++ b/docs/reference/decision_points/value_density.md @@ -10,7 +10,7 @@ !!! info "User vs. System Operator" A “user” is anyone whose professional task is something other than the maintenance of the system or component. - As with [*Safety Impact*](#safety-impact), a “system operator” is anyone who is professionally responsible for + As with [*Safety Impact*](safety_impact.md), a “system operator” is anyone who is professionally responsible for the proper operation or maintenance of a system. !!! example "Diffuse" @@ -31,7 +31,7 @@ !!! tip "Gathering Information About Value Density" - The heuristics presented in the [*Value Density*](#value-density) definitions involve whether the system is usually maintained by a dedicated professional, although we have noted some exceptions (such as encrypted mobile messaging applications). + The heuristics presented in the *Value Density* definitions involve whether the system is usually maintained by a dedicated professional, although we have noted some exceptions (such as encrypted mobile messaging applications). If there are additional counterexamples to this heuristic, please describe them and the reasoning why the system should have the alternative decision value in an issue on the [SSVC GitHub](https://github.com/CERTCC/SSVC/issues). An analyst might use market research reports or Internet telemetry data to assess an unfamiliar product. @@ -43,4 +43,4 @@ Such telemetry is most reliable for the supplier of the software, especially if software licenses are purchased and checked. Measuring how many instances of a system are in operation is useful, but having more instances does not mean that the software is a densely valuable target. However, market penetration greater than approximately 75% generally means that the product uniquely serves a particular market segment or purpose. - This line of reasoning is what supports a determination that an ubiquitous encrypted mobile messaging application should be considered to have a [*concentrated*](#value-density) Value Density. + This line of reasoning is what supports a determination that an ubiquitous encrypted mobile messaging application should be considered to have a *concentrated* Value Density. diff --git a/docs/reference/index.md b/docs/reference/index.md index 8fa972a9..af7ff33b 100644 --- a/docs/reference/index.md +++ b/docs/reference/index.md @@ -4,9 +4,9 @@ This section assumes that you are already familiar with SSVC and want to look up specific details. - If you are new to SSVC, you may want to start with the [Learning SSVC](tutorials) section. + If you are new to SSVC, you may want to start with the [Learning SSVC](../tutorials/index.md) section. If you are already familiar with SSVC and want to learn more, you may want to start with either the - [Understanding SSVC](topics) or [SSVC How To](howto) sections. + [Understanding SSVC](../topics/index.md) or [SSVC How To](../howto/index.md) sections. In this section, we provide reference documentation for SSVC. We have organized the reference documentation into two main sections: diff --git a/docs/topics/asset_management.md b/docs/topics/asset_management.md index c156b07e..7ed99ae5 100644 --- a/docs/topics/asset_management.md +++ b/docs/topics/asset_management.md @@ -6,10 +6,14 @@ SSVC depends on asset management to some extent, particularly for context on the !!! tip "Asset Management Informs Decision Points" - Asset management can help automate the collection of the [*Mission Impact*](#mission-impact), [*Situated Safety Impact*](#situated-safety-impact), and [*System Exposure*](#system-exposure) decision points. + Asset management can help automate the collection of the + [*Mission Impact*](../reference/decision_points/mission_impact.md), + [*Situated Safety Impact*](../reference/decision_points/safety_impact.md), and + [*System Exposure*](../reference/decision_points/system_exposure.md) decision points. These decision points tend to apply per asset rather than per vulnerability. Therefore, once each is assessed for each asset, it can be applied to each vulnerability that applies to that asset. - While the asset assessment should be reviewed occasionally for accuracy, storing this data in an asset management system should enable automated scoring of new vulnerabilities on these decision points for those assets. + While the asset assessment should be reviewed occasionally for accuracy, storing this data in an asset management + system should enable automated scoring of new vulnerabilities on these decision points for those assets. Our method is for prioritizing vulnerabilities based on the risk stemming from exploitation. There are other reasonable asset management considerations that may influence remediation timelines. @@ -29,5 +33,8 @@ Asset management and risk management also drive some of the up-front work an org This situation is not new; an asset owner cannot prioritize which fixes to deploy to its assets if it does not have an accurate inventory of its assets. The organization can pick its choice of tools; there are about 200 asset management tools on the market [@captera]. Emerging standards like the Software Bill of Materials (SBOM) [@manion2019sbom] would likely reduce the burden on asset management, and organizations should prefer systems which make such information available. -If an organization does not have an asset management or risk management (see also [Gathering Information About Mission Impact](#gathering-information-about-mission-impact)) plan and process in place, then SSVC provides some guidance as to what information is important to vulnerability management decisions and the organization should start capturing, storing, and managing. +If an organization does not have an asset management or risk management +(see also [Gathering Information About Mission Impact](../reference/decision_points/mission_impact.md)) +plan and process in place, then SSVC provides some guidance as to what information is important to vulnerability +management decisions and the organization should start capturing, storing, and managing. diff --git a/docs/topics/decision_trees.md b/docs/topics/decision_trees.md index 27c5d4ca..e6be7d96 100644 --- a/docs/topics/decision_trees.md +++ b/docs/topics/decision_trees.md @@ -22,12 +22,12 @@ For data input, we elected to keep SSVC simpler than R, and just use a CSV (or o All visualizations of a tree should be built from a canonical CSV that defines the decisions for that stakeholder. Examples are located in [SSVC/data](https://github.com/CERTCC/SSVC/tree/main/data). An interoperable CSV format is also flexible enough to support a variety of uses. -Every situation in SSVC is defined by the values for each decision point and the priority label (outcome) for that situation (as defined in [Likely Decision Points and Relevant Data](#likely-decision-points-and-relevant-data)). +Every situation in SSVC is defined by the values for each decision point and the priority label (outcome) for that situation (as defined in [Likely Decision Points and Relevant Data](../reference/decision_points/index.md)). A CSV will typically be 30-100 rows that each look something like: ``` 2,none,laborious,partial,significant,scheduled ``` -Where “2” is the row number, [*none*](#exploitation) through [*significant*](#public-safety-impact) are values for decision points, and *scheduled* is a priority label or outcome. +Where “2” is the row number, [*none*](../reference/decision_points/exploitation.md) through [*significant*](../reference/decision_points/public_safety_impact.md) are values for decision points, and *scheduled* is a priority label or outcome. Different stakeholders will have different decision points (and so different options for values) and different outcomes, but this is the basic shape of a CSV file to define SSVC stakeholder decisions. ### Visualizing Decision Trees diff --git a/docs/topics/enumerating_actions.md b/docs/topics/enumerating_actions.md index 459ac3c2..a7e00044 100644 --- a/docs/topics/enumerating_actions.md +++ b/docs/topics/enumerating_actions.md @@ -9,7 +9,7 @@ Here we explain what we mean by “priority”. ## Supplying Patches At a basic level, the decision at a software development organization is whether to issue a work order and what resources to expend to remediate a vulnerability in the organization’s software. Prioritization is required because, at least in the current history of software engineering, the effort to patch all known vulnerabilities will exceed available resources. The organization considers several other factors to build the patch; refactoring a large portion of the code base may be necessary for some patches, while others require relatively small changes. -We focus only on the priority of building the patch, and we consider four categories of priority, as outlined in [Table 2](#table-supplier-outcomes). +We focus only on the priority of building the patch, and we consider four categories of priority, as outlined in the table below. !!! note "Patch Supplier Priority" @@ -22,20 +22,20 @@ We focus only on the priority of building the patch, and we consider four catego ## Deploying Patches -A mitigation that successfully changes the value of a decision point may shift the priority of further action to a reduced state. An effective firewall or IDS rule coupled with an adequate change control process for rules may be enough to reduce the priority where no further action is necessary. In the area of Financial impacts, a better insurance policy may be purchased, providing necessary fraud insurance. Physicial well-being impact may be reduced by testing the physicial barriers designed to restrict a robot's ability to interact with humans. Mission impact could be reduced by correcting the problems identified in a disaster recover test-run of the alternate business flow. If applying a mitigation reduces the priority to *defer*, the deployer may not need to apply a remediation if it later becomes available. [Table 3](#table-deployer-outcomes) displays the action priorities for the deployer, which are similar to the supplier case. +A mitigation that successfully changes the value of a decision point may shift the priority of further action to a reduced state. An effective firewall or IDS rule coupled with an adequate change control process for rules may be enough to reduce the priority where no further action is necessary. In the area of Financial impacts, a better insurance policy may be purchased, providing necessary fraud insurance. Physicial well-being impact may be reduced by testing the physicial barriers designed to restrict a robot's ability to interact with humans. Mission impact could be reduced by correcting the problems identified in a disaster recover test-run of the alternate business flow. If applying a mitigation reduces the priority to *defer*, the deployer may not need to apply a remediation if it later becomes available. The table below displays the action priorities for the deployer, which are similar to the supplier case. -When remediation is available, usually the action is to apply it. When remediation is not yet available, the action space is more diverse, but it should involve mitigating the vulnerability (e.g., shutting down services or applying additional security controls) or accepting the risk of not mitigating the vulnerability. Applying mitigations may change the value of decision points. For example, effective firewall and IDS rules may change [*System Exposure*](#system-exposure) from open to controlled. Financial well-being, a [*Safety Impact*](#safety-impact) category, might be reduced with adequate fraud detection and insurance. Physical well-being, also a [*Safety Impact*](#safety-impact) category, might be reduced by physical barriers that restrict a robot's ability to interact with humans. [*Mission Impact*](#mission-impact) might be reduced by introducing back-up business flows that do not use the vulnerable component. In a later section we combine [Mission and Situated Safety Impact](#table-mission-safety-combined) to reduce the complexity of the tree. +When remediation is available, usually the action is to apply it. When remediation is not yet available, the action space is more diverse, but it should involve mitigating the vulnerability (e.g., shutting down services or applying additional security controls) or accepting the risk of not mitigating the vulnerability. Applying mitigations may change the value of decision points. For example, effective firewall and IDS rules may change [*System Exposure*](../reference/decision_points/system_exposure.md) from open to controlled. Financial well-being, a [*Safety Impact*](../reference/decision_points/safety_impact.md) category, might be reduced with adequate fraud detection and insurance. Physical well-being, also a [*Safety Impact*](../reference/decision_points/safety_impact.md) category, might be reduced by physical barriers that restrict a robot's ability to interact with humans. [*Mission Impact*](../reference/decision_points/mission_impact.md) might be reduced by introducing back-up business flows that do not use the vulnerable component. In a later section we combine [Mission and Situated Safety Impact](../reference/decision_points/human_impact.md) to reduce the complexity of the tree. However, these mitigation techniques will not always work. !!! example "Examples of Inadequate Mitigation" - - The implementation of a firewall or IDS rule to mitigate [*System Exposure*](#system-exposure) from + - The implementation of a firewall or IDS rule to mitigate [*System Exposure*](../reference/decision_points/system_exposure.md) from open to controlled is only valid until someone changes the rule. - In the area of Financial impacts, the caps on the insurance may be too low to act as a mitigation. - The Physical impact may be increased by incorrect installation of the physical barriers designed to restrict a robot’s ability to interact with humans. - - The [*Mission Impact*](#mission-impact) could be increased when a disaster recovery test-run identifies problems + - The [*Mission Impact*](../reference/decision_points/mission_impact.md) could be increased when a disaster recovery test-run identifies problems with an alternate business flow. - The mitigating action may not be permanent or work as designed. @@ -44,9 +44,9 @@ If applying a mitigation reduces the priority to *defer*, the deployer may not n {== Table 3 ==} displays the action priorities for the deployer, which are similar to the supplier case. In a later section, the different types of impacts are defined and then implemented in the decision trees as examples of how the various impacts affect the priority. -For now, assume the decision points are ordered as: [*Exploitation*](#exploitation); [*Exposure*](#exposure); [*Utility*](#utility); and [*Human Impact*](#human-impact). -In this order, an [_active_](#exploitation) state of [*Exploitation*](#exploitation) will never result in a *defer* priority. -A [_none_](#exploitation) state of [*Exploitation*](#exploitation) (no evidence of exploitation) will result in either *defer* or *scheduled* priority—unless the state of [*Human Impact*](#human-impact) is [_very high_](#human-impact), resulting in an *out-of-cycle* priority. +For now, assume the decision points are ordered as: [*Exploitation*](../reference/decision_points/exploitation.md); [Exposure](../reference/decision_points/system_exposure.md); [Utility](../reference/decision_points/utility.md); and [*Human Impact*](../reference/decision_points/human_impact.md). +In this order, an [_active_](../reference/decision_points/exploitation.md) state of [*Exploitation*](../reference/decision_points/exploitation.md) will never result in a *defer* priority. +A [_none_](../reference/decision_points/exploitation.md) state of [*Exploitation*](../reference/decision_points/exploitation.md) (no evidence of exploitation) will result in either *defer* or *scheduled* priority—unless the state of [*Human Impact*](../reference/decision_points/human_impact.md) is [_very high_](../reference/decision_points/human_impact.md), resulting in an *out-of-cycle* priority. As opposed to mitigation, applying a remediation finishes an SSVC analysis of a deployed system. diff --git a/docs/topics/evaluation_of_draft_trees.md b/docs/topics/evaluation_of_draft_trees.md index 3bdb5897..0bec4858 100644 --- a/docs/topics/evaluation_of_draft_trees.md +++ b/docs/topics/evaluation_of_draft_trees.md @@ -4,7 +4,7 @@ We conducted a pilot test on the adequacy of the hypothesized decision trees. This section reports results for SSVC version 1. - The method of the pilot test is described in [Pilot Methodogy](#pilot-methodology). The study resulted in several changes to the hypothesized trees; we capture those changes and the reason for each of them in [Pilot Results](#pilot-results). The version 1 supplier and deployer trees included the improvements reported in [Improvement Instigated by the Pilot](#improvements-instigated-by-the-pilot). +The method of the pilot test is described in [Pilot Methodogy](#pilot-methodology). The study resulted in several changes to the hypothesized trees; we capture those changes and the reason for each of them in [Pilot Results](#pilot-results). The version 1 supplier and deployer trees included the improvements reported in [Improvement Instigated by the Pilot](#improvements-instigated-by-the-pilot). ## Pilot Methodology @@ -21,7 +21,7 @@ The pilot study tested inter-rater agreement of decisions reached. Each author p During the pilot, we did not form guidance on how to assess the values of the decision points. However, we did standardize the set of evidence that was taken to be true for the point in time representing the evaluation. -Given this static information sheet, we did not synchronize an evaluation process for how to decide whether [*Exploitation*](#exploitation), for example, should take the value of [*none*](#exploitation), [*PoC*](#exploitation), or [*active*](#exploitation). +Given this static information sheet, we did not synchronize an evaluation process for how to decide whether [*Exploitation*](../reference/decision_points/exploitation.md), for example, should take the value of [*none*](../reference/decision_points/exploitation.md), [*PoC*](../reference/decision_points/exploitation.md), or [*active*](../reference/decision_points/exploitation.md). We agreed on the descriptions of the decision points and the descriptions of their values. The goal of the pilot was to test the adequacy of those descriptions by evaluating whether the analysts agreed. We improved the decision point descriptions based on the results of the pilot; our changes are documented in [Improvement Instigated by the Pilot](#improvements-instigated-by-the-pilot). In the design of the pilot, we held constant the information available about the vulnerability. This strategy restricted the analyst to decisions based on the framework given that information. That is, it controlled for differences in information search procedure among the analysts. The information search procedure should be controlled because this pilot was about the framework content, not how people answer questions based on that content. After the framework is more stable, a separate study should be devised that shows how analysts should answer the questions in the framework. The basis for the assessment that information search will be an important aspect in using the evaluation framework is based on our experience while developing the framework. During informal testing, often disagreements about a result involved a disagreement about what the scenario actually was; different information search methods and prior experiences led to different understandings of the scenario. This pilot methodology holds the information and scenario constant to test agreement about the descriptions themselves. This strategy makes constructing a prioritization system more tractable by separating problems in how people search for information from problems in how people make decisions. This paper focuses only on the structure of decision making. Advice about how to search for information about a vulnerability is a separate project that will be part of future work. In some domains, namely exploit availability, we have started that work in parallel. diff --git a/docs/topics/formalization_options.md b/docs/topics/formalization_options.md index 2bb430d6..b96676bb 100644 --- a/docs/topics/formalization_options.md +++ b/docs/topics/formalization_options.md @@ -1,7 +1,7 @@ # Formalization Options This section briefly surveys the available formalization options against the six design goals described above. -[Table 1](#table-form-options) summarizes the results. +The table below summarizes the results. This survey is opportunistic; it is based on conversations with several experts and our professional experience. The search process leaves open the possibility of missing a better option. However, at the moment, we are searching for a satisfactory formalism, rather than an optimal one. diff --git a/docs/topics/future_work.md b/docs/topics/future_work.md index 4e1cf48d..eae393dc 100644 --- a/docs/topics/future_work.md +++ b/docs/topics/future_work.md @@ -26,12 +26,12 @@ One way to view what SSVC currently provides is that it tells you how urgently a For all but the most dire vulnerabilities, what the stakeholder chooses to do may include accepting the vulnerability risk because the change risk or other costs of mitigation or remediation are too high. Future work should attempt to provide a method for [evaluating change risk or cost](https://github.com/CERTCC/SSVC/issues/35) relative to vulnerability risk. -[Tree Construction and Customization Guidance](#tree-construction-and-customization-guidance) discusses how the prioritization labels in an SSVC tree reflect risk appetite or risk tolerance. +[Tree Construction and Customization Guidance](../howto/tree_customization.md) discusses how the prioritization labels in an SSVC tree reflect risk appetite or risk tolerance. Specifically, these reflect vulnerability risk appetite. Appetite for vulnerability risk may be negatively correlated with change risk; future work could explore this relationship. Furthermore, future work could examine suggested practices for connecting tree customization to risk management. -[Reasoning Steps Forward](#reasoning-steps-forward) states the scope of SSVC analysis is “consider credible effects based on known use cases of the software system as a part of cyber-physical systems.” +[Reasoning Steps Forward](scope.md) states the scope of SSVC analysis is “consider credible effects based on known use cases of the software system as a part of cyber-physical systems.” The unit of prioritization in SSVC should be work items. For deployers, a work item is often applying a patch that addresses multiple vulnerabilities. The “credible effects” to consider are those of all vulnerabilities remediated by the patch. @@ -50,7 +50,7 @@ Internationalization and localization of SSVC will also need to be considered an It is not clear how best to consider translating SSVC decision points, if at all. An actionable item of future work would be to include non-native English speakers in future usability studies. -A different approach to testing the [*Utility*](#utility) decision point could be based on [Alternative Utility Outputs](#alternative-utility-outputs). -Namely, future work could example exploit resale markets and compare the value of exploits to the [*Utility*](#utility) score of the exploited vulnerability. +A different approach to testing the [Utility](../reference/decision_points/utility.md) decision point could be based on the *Alternative Utility Outputs* found in that page. +Namely, future work could example exploit resale markets and compare the value of exploits to the [Utility](../reference/decision_points/utility.md) score of the exploited vulnerability. There are some limitations to this approach, since exploit markets target certain adversary groups (such as those with lots of resources) and may not be representative of all adversary types. -However, such analysis would provide some information as to whether the definition of [*Utility*](#utility) is reasonable. +However, such analysis would provide some information as to whether the definition of [Utility](../reference/decision_points/utility.md) is reasonable. diff --git a/docs/topics/information_sources.md b/docs/topics/information_sources.md index 86c705fc..11719941 100644 --- a/docs/topics/information_sources.md +++ b/docs/topics/information_sources.md @@ -3,10 +3,10 @@ Some SSVC decision points can be informed or answered by currently available information feeds or sources. These include -- [*Exploitation*](#exploitation) -- [*System Exposure*](#system-exposure) -- [*Technical Impact*](#technical-impact) -- [*Public Safety Impact*](#public-safety-impact). +- [*Exploitation*](../reference/decision_points/exploitation.md) +- [*System Exposure*](../reference/decision_points/system_exposure.md) +- [*Technical Impact*](../reference/decision_points/technical_impact.md) +- [*Public Safety Impact*](../reference/decision_points/public_safety_impact.md). This section provides an overview of some options; we cannot claim it is exhaustive. Each decision point has a subsection for `Gathering Information About` it. @@ -16,7 +16,7 @@ However, if there is a category of information source we have not captured, plea ## Exploitation Various vendors provide paid feeds of vulnerabilities that are currently exploited by attacker groups. -Any of these could be used to indicate that [*active*](#exploitation) is true for a vulnerability. +Any of these could be used to indicate that [*active*](../reference/decision_points/exploitation.md) is true for a vulnerability. Although the lists are all different, we expect they are all valid information sources; the difficulty is matching a list's scope and vantage with a compatible scope and vantage of the consumer. We are not aware of a comparative study of the different lists of active exploits; however, we expect they have similar properties to block lists of network touchpoints [@metcalf2015blocklist] and malware [@kuhrer2014paint]. Namely, each list has a different view and vantage on the problem, which makes them appear to be different, but each list accurately represents its particular vantage at a point in time. @@ -24,10 +24,10 @@ Namely, each list has a different view and vantage on the problem, which makes t ## System Exposure -[*System Exposure*](#system-exposure) could be informed by the various scanning platforms such as Shodan and Shadowserver. -A service on a device should be scored as [*open*](#system-exposure) if such a general purpose Internet scan finds that the service responds. -Such scans do not find all [*open*](#system-exposure) systems, but any system they find should be considered [*open*](#system-exposure). -Scanning software, such as the open-source tool Nessus, could be used to scan for connectivity inside an organization to catalogue what devices should be scored [*controlled*](#system-exposure) if, say, the scan finds them on an internal network where devices regularly connect to the Internet. +[*System Exposure*](../reference/decision_points/system_exposure.md) could be informed by the various scanning platforms such as Shodan and Shadowserver. +A service on a device should be scored as [*open*](../reference/decision_points/system_exposure.md) if such a general purpose Internet scan finds that the service responds. +Such scans do not find all [*open*](../reference/decision_points/system_exposure.md) systems, but any system they find should be considered [*open*](../reference/decision_points/system_exposure.md). +Scanning software, such as the open-source tool Nessus, could be used to scan for connectivity inside an organization to catalogue what devices should be scored [*controlled*](../reference/decision_points/system_exposure.md) if, say, the scan finds them on an internal network where devices regularly connect to the Internet. --- ## Adapting other Information Sources @@ -37,34 +37,34 @@ Three prominent examples are CVSS impact base metrics, CWE, and CPE. ### CVSS and Technical Impact -[*Technical Impact*](#technical-impact) is directly related to the CVSS impact metric group. -However, this metric group cannot be directly mapped to [*Technical Impact*](#technical-impact) in CVSS version 3 because of the Scope metric. -[*Technical Impact*](#technical-impact) is only about adversary control of the vulnerable component. +[*Technical Impact*](../reference/decision_points/technical_impact.md) is directly related to the CVSS impact metric group. +However, this metric group cannot be directly mapped to [*Technical Impact*](../reference/decision_points/technical_impact.md) in CVSS version 3 because of the Scope metric. +[*Technical Impact*](../reference/decision_points/technical_impact.md) is only about adversary control of the vulnerable component. If the CVSS version 3 value of “Scope” is “Changed,” then the impact metrics are the maximum of the impact on the vulnerable component and other components in the environment. -If confidentiality, integrity, and availability metrics are all “high” then [*Technical Impact*](#technical-impact) is [*total*](#technical-impact), as long as the impact metrics in CVSS are clearly about just the vulnerable component. -However, the other values of the CVSS version 3 impact metrics cannot be mapped directly to [*partial*](#technical-impact) because of CVSS version 3.1 scoring guidance. +If confidentiality, integrity, and availability metrics are all “high” then [*Technical Impact*](../reference/decision_points/technical_impact.md) is [*total*](../reference/decision_points/technical_impact.md), as long as the impact metrics in CVSS are clearly about just the vulnerable component. +However, the other values of the CVSS version 3 impact metrics cannot be mapped directly to [*partial*](../reference/decision_points/technical_impact.md) because of CVSS version 3.1 scoring guidance. Namely, “only the increase in access, privileges gained, or other negative outcome as a result of successful exploitation should be considered” [@cvss_v3-1]. The example given is that if an attacker already has read access, but gains all other access through the exploit, then read access didn't change and the confidentiality metric score should be “None” . -However, in this case, SSVC would expect the decision point to be evaluated as [*total*](#technical-impact) because as a result of the exploit the attacker gains total control of the device, even though they started with partial control. +However, in this case, SSVC would expect the decision point to be evaluated as [*total*](../reference/decision_points/technical_impact.md) because as a result of the exploit the attacker gains total control of the device, even though they started with partial control. ### CWE and Exploitation -As mentioned in the discussion of [*Exploitation*](#exploitation), [CWE](https://cwe.mitre.org/) could be used to inform one of the conditions that satisfy [*proof of concept*](#exploitation). +As mentioned in the discussion of [*Exploitation*](../reference/decision_points/exploitation.md), [CWE](https://cwe.mitre.org/) could be used to inform one of the conditions that satisfy [*proof of concept*](../reference/decision_points/exploitation.md). For some classes of vulnerabilities, the proof of concept is well known because the method of exploitation is already part of open-source tools. For example, on-path attacker scenarios for intercepting TLS certificates. These scenarios are a cluster of related vulnerabilities. Since CWE classifies clusters of related vulnerabilities, the community could likely curate a list of CWE-IDs for which this condition of well known exploit technique is satisfied. -Once that list were curated, it could be used to automatically populate a CVE-ID as [*proof of concept*](#exploitation) if the CWE-ID of which it is an instance is on the list. -Such a check could not be exhaustive, since there are other conditions that satisfy [*proof of concept*](#exploitation). +Once that list were curated, it could be used to automatically populate a CVE-ID as [*proof of concept*](../reference/decision_points/exploitation.md) if the CWE-ID of which it is an instance is on the list. +Such a check could not be exhaustive, since there are other conditions that satisfy [*proof of concept*](../reference/decision_points/exploitation.md). If paired with automatic searches for exploit code in public repositories, these checks would cover many scenarios. -If paired with active exploitation feeds discussed above, then the value of [*Exploitation*](#exploitation) could be determined almost entirely from available information without direct analyst involvement at each organization. +If paired with active exploitation feeds discussed above, then the value of [*Exploitation*](../reference/decision_points/exploitation.md) could be determined almost entirely from available information without direct analyst involvement at each organization. ### CPE and Safety Impact -[CPE](https://cpe.mitre.org/specification/) could possibly be curated into a list of representative [*Public Safety Impact*](#public-safety-impact) values for each platform or product. -The [*Situated Safety Impact*](#situated-safety-impact) would be too specific for a classification as broad as CPE. -But it might work for [*Public Safety Impact*](#public-safety-impact), since it is concerned with a more general assessment of usual use of a component. -Creating a mapping between CPE and [*Public Safety Impact*](#public-safety-impact) could be a community effort to associate a value with each CPE entry, or an organization might label a fragment of the CPE data with [*Public Safety Impact*](#public-safety-impact) based on the platforms that the supplier needs information about most often. +[CPE](https://cpe.mitre.org/specification/) could possibly be curated into a list of representative [*Public Safety Impact*](../reference/decision_points/public_safety_impact.md) values for each platform or product. +The [*Situated Safety Impact*](../reference/decision_points/safety_impact.md) would be too specific for a classification as broad as CPE. +But it might work for [*Public Safety Impact*](../reference/decision_points/public_safety_impact.md), since it is concerned with a more general assessment of usual use of a component. +Creating a mapping between CPE and [*Public Safety Impact*](../reference/decision_points/public_safety_impact.md) could be a community effort to associate a value with each CPE entry, or an organization might label a fragment of the CPE data with [*Public Safety Impact*](../reference/decision_points/public_safety_impact.md) based on the platforms that the supplier needs information about most often. ## Potential Future Information Feeds @@ -73,19 +73,19 @@ Some sources, such as CWE or existing asset management solutions, would require ### Automatable and Value Density -The SSVC decision point that we have not identified an information source for is [*Utility*](#utility). -[*Utility*](#utility) is composed of [*Automatable*](#automatable) and [*Value Density*](#value-density), so the question is what a sort of feed could support each of those decision points. +The SSVC decision point that we have not identified an information source for is [Utility](../reference/decision_points/utility.md). +[Utility](../reference/decision_points/utility.md) is composed of [*Automatable*](../reference/decision_points/automatable.md) and [*Value Density*](../reference/decision_points/value_density.md), so the question is what a sort of feed could support each of those decision points. A feed is plausible for both of these decision points. -The values for [*Automatable*](#automatable) and [*Value Density*](#value-density) are both about the relationship between a vulnerability, the attacker community, and the aggregate state of systems connected to the Internet. +The values for [*Automatable*](../reference/decision_points/automatable.md) and [*Value Density*](../reference/decision_points/value_density.md) are both about the relationship between a vulnerability, the attacker community, and the aggregate state of systems connected to the Internet. While that is a broad analysis frame, it means that any community that shares a similar set of adversaries and a similar region of the Internet can share the same response to both decision points. -An organization in the People's Republic of China may have a different view than an organization in the United States, but most organizations within each region should should have close enough to the same view to share values for [*Automatable*](#automatable) and [*Value Density*](#value-density). +An organization in the People's Republic of China may have a different view than an organization in the United States, but most organizations within each region should should have close enough to the same view to share values for [*Automatable*](../reference/decision_points/automatable.md) and [*Value Density*](../reference/decision_points/value_density.md). These factors suggest a market for an information feed about these decision points is a viable possibility. -At this point, it is not clear that an algorithm or search process could be designed to automate scoring [*Automatable*](#automatable) and [*Value Density*](#value-density). +At this point, it is not clear that an algorithm or search process could be designed to automate scoring [*Automatable*](../reference/decision_points/automatable.md) and [*Value Density*](../reference/decision_points/value_density.md). It would be a complex natural language processing task. Perhaps a machine learning system could be designed to suggest values. But more likely, if there is a market for this information, a few analysts could be paid to score vulnerabilities on these values for the community. Supporting such analysts with further automation could proceed by small incremental improvements. -For example, perhaps information about whether the Reconnaissance step in the kill chain is [*Automatable*](#automatable) or not could be automatically gathered from Internet scanning firms such as Shodan or Shadowserver. +For example, perhaps information about whether the Reconnaissance step in the kill chain is [*Automatable*](../reference/decision_points/automatable.md) or not could be automatically gathered from Internet scanning firms such as Shodan or Shadowserver. This wouldn't make a determination for an analyst, but would be a step towards automatic assessment of the decision point. diff --git a/docs/topics/limitations.md b/docs/topics/limitations.md index d310da1c..c6b365fd 100644 --- a/docs/topics/limitations.md +++ b/docs/topics/limitations.md @@ -1,7 +1,7 @@ # Limitations SSVC has some inherent limits in its approach, which should be understood as tradeoffs. -There are other limiting aspects of our implementation, but those have been covered as topics that need improvement and are described in [Future Work](#future-work). +There are other limiting aspects of our implementation, but those have been covered as topics that need improvement and are described in [Future Work](future_work.md). We made two important tradeoffs compared to the current state of the practice. Other systems make different tradeoffs, which may be better or worse depending on the context of use. @@ -24,7 +24,7 @@ relabel outcomes as \[2, 5.5, 8, 9.5\] for the midpoints of the current CVSS sev This is not a calculation of any kind, just an assignment of a label which may make adoption more convenient. Of course, these labels are dangerous, as they may be misused as numbers. Therefore, we prefer the use *defer*, *scheduled*, etc., as listed in -[Enumerating Vulnerability Management Actions](#enumerating-vulnerability-management-actions). +[Enumerating Vulnerability Management Actions](../howto/deployer_tree.md). ## Expanded Context diff --git a/docs/topics/related_systems.md b/docs/topics/related_systems.md index fade6b05..c16deaf8 100644 --- a/docs/topics/related_systems.md +++ b/docs/topics/related_systems.md @@ -23,26 +23,26 @@ CVSS scores have a complex relationship with patch deployment in situations wher 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). +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). 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. > Exploitability metrics (Base metric group) The four metrics in this group are Attack Vector, Attack Complexity, Privileges Required, and User Interaction. -This considerations may likely be involved in the [*Automatability*](#automatability) decision point. +This considerations may likely be involved in the [Automatability](../reference/decision_points/automatable.md) decision point. If Attack Vector = Network and Privileges Required = None, then the delivery phase of the kill chain is likely to be automatable. -Attack Vector may also be correlated with the [*Exposure*](#exposure) decision point. -Attack Complexity may influence how long it may take an adversary to craft an automated exploit, but [*Automatability*](#automatability) only asks whether exploitation can be automated, not how difficult it was. +Attack Vector may also be correlated with the [Exposure](../reference/decision_points/system_exposure.md) decision point. +Attack Complexity may influence how long it may take an adversary to craft an automated exploit, but [Automatability](../reference/decision_points/automatable.md) only asks whether exploitation can be automated, not how difficult it was. However, Attack Complexity may influence the weaponization phase of the kill chain. User Interaction does not cleanly map to a decision point. In general, SSVC does not care whether a human is involved in exploitation of the vulnerability or not. Some human interaction is for all intents and purposes automatable by attackers: most people click on links in emails as part of their normal processes. In most such situations, user interaction does not present a firm barrier to automatability; it presents a stochastic barrier. -[*Automatability*](#automatability) is written to just consider firm barriers to automation. +[Automatability](../reference/decision_points/automatable.md) is written to just consider firm barriers to automation. -[*Automatability*](#automatability) includes considerations that are not included in the exploitability metrics. -Most notably the concept of vulnerability chaining is addressed in [*Automatability*](#automatability) but not addressed anywhere in CVSS. -[*Automatability*](#automatability) is also outcomes focused. +[Automatability](../reference/decision_points/automatable.md) includes considerations that are not included in the exploitability metrics. +Most notably the concept of vulnerability chaining is addressed in [Automatability](../reference/decision_points/automatable.md) but not addressed anywhere in CVSS. +[Automatability](../reference/decision_points/automatable.md) is also outcomes focused. A vulnerability is evaluated based on an observable outcome of whether the first four steps of the kill chain can be automated for it. A proof of automation in a relevant environment is an objective evaluation of the score in a way that cannot be provided for some CVSS elements, such as Attack Complexity. @@ -50,21 +50,21 @@ A proof of automation in a relevant environment is an objective evaluation of th The metrics in this group are Confidentiality, Integrity, and Availability. There is also a loosely associated Scope metric. -The CIA impact metrics are directly handled by [*Technical Impact*](#technical-impact). +The CIA impact metrics are directly handled by [*Technical Impact*](../reference/decision_points/technical_impact.md). Scope is a difficult CVSS metric to categorize. The specification describes it as “whether a vulnerability in one vulnerable component impacts resources in components beyond its security scope” [@cvss_v3-1]. This is a fuzzy concept. SSVC better describes this concept by breaking it down into component parts. -The impact of exploitation of the vulnerable component on other components is covered under [*Mission Impact*](#mission-impact), public and situated [*Well-being Impact*](#well-being-impact), and the stakeholder-specific nature where SSVC is tailored to stakeholder concerns. +The impact of exploitation of the vulnerable component on other components is covered under [*Mission Impact*](../reference/decision_points/mission_impact.md), public and situated [*Well-being Impact*](../reference/decision_points/human_impact.md), and the stakeholder-specific nature where SSVC is tailored to stakeholder concerns. CVSS addresses some definitions of the scope of CVSS as a whole under the Scope metric definition. -In SSVC, these definitions are in the [Scope](#scope) section. +In SSVC, these definitions are in the [Scope](scope.md) section. > Temporal metric groups The temporal metric group primarily contains the Exploit Code Maturity metric. -This metric expresses a concept similar to [*Exploitation*](#exploitation). -The main difference is that [*Exploitation*](#exploitation) is not optional in SSVC and that SSVC accounts for the observation that most vulnerabilities with CVE-IDs do not have public exploit code [@householder2020historical] and are not actively exploited [@guido2011exploit,@jacobs2021epss]. +This metric expresses a concept similar to [*Exploitation*](../reference/decision_points/exploitation.md). +The main difference is that [*Exploitation*](../reference/decision_points/exploitation.md) is not optional in SSVC and that SSVC accounts for the observation that most vulnerabilities with CVE-IDs do not have public exploit code [@householder2020historical] and are not actively exploited [@guido2011exploit,@jacobs2021epss]. > Environmental metric group @@ -80,30 +80,30 @@ EPSS is currently based on a machine-learning classifier and proprietary data fr While the group has made an effort to make the ML classifier transparent, ML classifiers are not able to provide an intelligible, human-accessible explanation for their behavior [@spring2019ml]. The use of proprietary training data makes the system less transparent. -EPSS could be used to inform the [*Exploitation*](#exploitation) decision point. -Currently, [*Exploitation*](#exploitation) focuses on the observable state of the world at the time of the SSVC decision. -EPSS is about predicting if a transition will occur from the SSVC state of [*none*](#exploitation) to [*active*](#exploitation). -A sufficiently high EPSS score could therefore be used as an additional criterion for scoring a vulnerability as [*active*](#exploitation) even when there is no observed active exploitation. +EPSS could be used to inform the [*Exploitation*](../reference/decision_points/exploitation.md) decision point. +Currently, [*Exploitation*](../reference/decision_points/exploitation.md) focuses on the observable state of the world at the time of the SSVC decision. +EPSS is about predicting if a transition will occur from the SSVC state of [*none*](../reference/decision_points/exploitation.md) to [*active*](../reference/decision_points/exploitation.md). +A sufficiently high EPSS score could therefore be used as an additional criterion for scoring a vulnerability as [*active*](../reference/decision_points/exploitation.md) even when there is no observed active exploitation. ## VPR VPR is a prioritization product sold by Tenable. VPR determines the severity level of a vulnerability based on “[technical impact and threat](https://www.tenable.com/blog/what-is-vpr-and-how-is-it-different-from-cvss).” -Just as [*Technical Impact*](#technical-impact) in SSVC, technical impact in VPR tracks the CVSS version 3 impact metrics in the base metric group. -The VPR threat component is about recent and future threat activity; it is comparable to [*Exploitation*](#exploitation) if EPSS were added to [*Exploitation*](#exploitation). +Just as [*Technical Impact*](../reference/decision_points/technical_impact.md) in SSVC, technical impact in VPR tracks the CVSS version 3 impact metrics in the base metric group. +The VPR threat component is about recent and future threat activity; it is comparable to [*Exploitation*](../reference/decision_points/exploitation.md) if EPSS were added to [*Exploitation*](../reference/decision_points/exploitation.md). VPR is therefore essentially a subset of SSVC. VPR is stylistically methodologically quite different from SSVC. VPR is based on machine learning models and proprietary data, so the results are totally opaque. There is no ability to coherently and transparently customize the VPR system. -Such customization is a central feature of SSVC, as described in [Tree Construction and Customization Guidance](#tree-construction-and-customization-guidance). +Such customization is a central feature of SSVC, as described in [Tree Construction and Customization Guidance](../howto/tree_customization.md). ## CVSS spin offs Attempts to tailor CVSS to specific stakeholder groups, such as robotics or medical devices, are are perhaps the biggest single reason we created SSVC. CVSS is one-size-fits-all by design. These customization efforts struggle with adapting CVSS because it was not designed to be adaptable to different stakeholder considerations. -The SSVC section [Tree Construction and Customization Guidance](#tree-construction-and-customization-guidance) explains how stakeholders or stakeholder communities can adapt SSVC in a reliable way that still promotes repeatability and communication. +The SSVC section [Tree Construction and Customization Guidance](../howto/tree_customization.md) explains how stakeholders or stakeholder communities can adapt SSVC in a reliable way that still promotes repeatability and communication. ## vPrioritizer @@ -115,6 +115,6 @@ vPrioritizer is an example of a product that is closely associated with vulnerab In that sense, it is compatible with any of methods mentioned above or SSVC. However, SSVC would be better suited to address vPrioritizer's broad spectrum asset management data. For example, vPrioritizer aims to collect data points on topics such as asset significance. -Asset significance could be expressed through the SSVC decision points of [*Mission Impact*](#mission-impact) and situated [*Well-being Impact*](#well-being-impact), but it does not have a ready expression in CVSS, EPSS, or VPR. +Asset significance could be expressed through the SSVC decision points of [*Mission Impact*](../reference/decision_points/mission_impact.md) and situated [*Well-being Impact*](../reference/decision_points/human_impact.md), but it does not have a ready expression in CVSS, EPSS, or VPR. diff --git a/docs/topics/representing_information.md b/docs/topics/representing_information.md index d4a11e59..0d09753f 100644 --- a/docs/topics/representing_information.md +++ b/docs/topics/representing_information.md @@ -53,7 +53,7 @@ The context of the vulnerability, and the systems it impacts, are inextricably l Some information about the context will be relatively static over time, such as the contribution of a system to an organization's mission. Other information can change rapidly as events occur, such as the public release of an exploit or observation of attacks. Temporal and environmental considerations should be primary, not optional as they are in CVSS. -We discuss the temporal aspects further in [Information Changes over Time](../howto/communicating_results.md#information-changes-over-time). +We discuss the temporal aspects further in [Information Changes over Time](../howto/bootstrap/use.md). ## Be Transparent diff --git a/docs/topics/state_of_practice.md b/docs/topics/state_of_practice.md index 907a59e1..e2009777 100644 --- a/docs/topics/state_of_practice.md +++ b/docs/topics/state_of_practice.md @@ -24,7 +24,7 @@ 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. +[Representing Information for Decisions About Vulnerabilities](representing_information.md) 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. diff --git a/docs/topics/units_of_work.md b/docs/topics/units_of_work.md index ecb40323..bab83d5c 100644 --- a/docs/topics/units_of_work.md +++ b/docs/topics/units_of_work.md @@ -70,7 +70,10 @@ The vulnerability management process for deployers has at its core the collation The first must be collected by the Deployer, while the latter two most often originate from the product Supplier. Managing this information is generally called **asset management**. -The relationship between SSVC and asset management is discussed further in [Relationship to asset management](#relationship-to-asset-management). + +!!! tip inline end "Relationship to asset management" + + The relationship between SSVC and asset management is discussed further in [SSVC and Asset Management](asset_management.md). In turn, Deployers must resolve this information into specific actions in which a remediation or mitigation is slated for deployment to replace or modify a particular instance of the product. The Deployer tree in SSVC considers the mission and safety risks inherent to the category of systems to which those deployed instances belong. diff --git a/docs/topics/worked_example.md b/docs/topics/worked_example.md index b681d27b..4ecb95d7 100644 --- a/docs/topics/worked_example.md +++ b/docs/topics/worked_example.md @@ -28,20 +28,20 @@ This considers the (fictional) deployer scenario blurb and the notional deployme These pumps are attached directly to the client. If an update is required, the client is permitted to do that through their own computer or app. However, we have not provided them with documentation on properly using their computer or app to securely access their device. This is done for convenience so that if the user needs to change something quickly, they can. They can also come to us (hospital) for a change in their device’s settings for dosage etc. The doctor’s computer that directly handles interfacing with these devices is only connected to the intranet for the purpose of updating the client’s settings on the device. Doctors authenticate with ID badge and password. -[*System Exposure*](#system-exposure) is less straightforward than *Exploitation*. -The option [*open*](#system-exposure) is clearly ruled out. +[*System Exposure*](../reference/decision_points/system_exposure.md) is less straightforward than *Exploitation*. +The option [*open*](../reference/decision_points/system_exposure.md) is clearly ruled out. However, it is not clear whether the optional Bluetooth connection between the medical device and a phone app represents -[*controlled*](#system-exposure) or [*small*](#system-exposure) exposure. +[*controlled*](../reference/decision_points/system_exposure.md) or [*small*](../reference/decision_points/system_exposure.md) exposure. The description does not explicitly handle the capture/replay aspect of the vulnerability. If the only way to exploit the vulnerability is to be within physical transmission range of the device, then that -physical constraint argues for exposure being [*small*](#system-exposure). +physical constraint argues for exposure being [*small*](../reference/decision_points/system_exposure.md). However, if the client’s phone app could be used to capture and replay attack packets, then unless that app is -particularly well secured, the answer should be [*controlled*](#system-exposure). +particularly well secured, the answer should be [*controlled*](../reference/decision_points/system_exposure.md). Regardless, the answer is not clear from the supplied information. Furthermore, if this fictional app is specific to the insulin pump, then even if it is not compromised, the attack might use its installation to remotely identify targets. However, since most of the hospital’s clients have not installed the app, and for nearly all cases, physical proximity -to the device is necessary; therefore, we select [*small*](#system-exposure) and move on to ask about mission impact. +to the device is necessary; therefore, we select [*small*](../reference/decision_points/system_exposure.md) and move on to ask about mission impact. According to the fictional pilot scenario, “Our mission dictates that the first and foremost priority is to contribute to human welfare and to uphold the Hippocratic oath (do no harm).” The continuity of operations planning for a hospital @@ -54,10 +54,10 @@ description of MEF failure. The question is then whether the whole mission fails, which does not seem to be the case. The recovery of MEF functioning is not affected, and most MEFs (the emergency services, surgery, oncology, administration, etc.) would be unaffected. -Therefore, we select [*MEF failure*](#mission-impact) and move on to ask about safety impact. +Therefore, we select [*MEF failure*](../reference/decision_points/mission_impact.md) and move on to ask about safety impact. This particular pilot study used SSVC version 1. -In the suggested deployer tree for SSVC version 2.1, mission and safety impact would be used to calculate the overall [*Human Impact*](#human-impact), and [*Automatable*](#automatable) would need to be answered as well. +In the suggested deployer tree for SSVC version 2.1, mission and safety impact would be used to calculate the overall [*Human Impact*](../reference/decision_points/human_impact.md), and [*Automatable*](../reference/decision_points/automatable.md) would need to be answered as well. Conducting further studies with the recommended version 2.1 Deployer tree remains an area of future work. In the pilot study, this information is conveyed as follows: @@ -72,15 +72,15 @@ In the pilot study, this information is conveyed as follows: The impacted insulin pumps have a local (on-patient) wireless control, so wires to the pump do not have to be connected to the patient's control of the system, making the system lighter and less prone to be ripped out. -The closest match to “death in a matter of hours” would be [*hazardous*](#safety-impact) because that description reads +The closest match to “death in a matter of hours” would be [*hazardous*](../reference/decision_points/safety_impact.md) because that description reads “serious or fatal injuries, where fatalities are plausibly preventable via emergency services or other measures.” Depending on the details of the hospital’s contingency plans and its monitoring of their patients, the -[*Safety Impact*](#safety-impact) could be [*catastrophic*](#safety-impact). +[*Safety Impact*](../reference/decision_points/safety_impact.md) could be [*catastrophic*](../reference/decision_points/safety_impact.md). If there is no way to tell whether the insulin pumps are misbehaving, for example, then exploitation could go on for -some time, leading to a [*catastrophic*](#safety-impact) [*Safety Impact*](#safety-impact). +some time, leading to a [*catastrophic*](../reference/decision_points/safety_impact.md) [*Safety Impact*](../reference/decision_points/safety_impact.md). The pilot information is inadequate in this regard, which is the likely source of disagreement about -[*Safety Impact*](#safety-impact) in Table 13. +[*Safety Impact*](../reference/decision_points/safety_impact.md) in Table 13. For the purposes of this example, imagine that after gathering that information, the monitoring situation is adequate, -and select [*hazardous*](#safety-impact). +and select [*hazardous*](../reference/decision_points/safety_impact.md). Therefore, mitigate this vulnerability *out-of-cycle*, meaning that it should be addressed quickly, ahead of the usual update and patch cycle. diff --git a/mkdocs.yml b/mkdocs.yml index bffc9486..2d96ab82 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -70,11 +70,11 @@ nav: - Public Safety Impact: 'reference/decision_points/public_safety_impact.md' - Utility: 'reference/decision_points/utility.md' - Code: - Intro: 'reference/code/index.md' - CSV Analyzer: 'reference/code/analyze_csv.md' - Policy Generator: 'reference/code/policy_generator.md' - Outcomes: 'reference/code/outcomes.md' - Doctools: 'reference/code/doctools.md' + - Intro: 'reference/code/index.md' + - CSV Analyzer: 'reference/code/analyze_csv.md' + - Policy Generator: 'reference/code/policy_generator.md' + - Outcomes: 'reference/code/outcomes.md' + - Doctools: 'reference/code/doctools.md' - Calculator: 'ssvc-calc/index.html' - About: - Intro: 'about/index.md' @@ -87,7 +87,8 @@ nav: - Contact: 'about/contact_us.md' - Issue Tracker: 'https://github.com/CERTCC/SSVC/issues' not_in_nav: | - _*.md + _*.md + _*/**/*.md theme: logo: 'assets/cert_seal.svg' name: 'material' @@ -111,7 +112,8 @@ plugins: - include-markdown: comments: false - search - - table-reader + - table-reader: + data_path: 'data/csvs' - bibtex: bib_file: 'doc/md_src_files/sources_ssvc.bib' - mkdocstrings: