diff --git a/data/json/decision_points/public_value_added_1_0_0.json b/data/json/decision_points/public_value_added_1_0_0.json index bfa46554..566b80c4 100644 --- a/data/json/decision_points/public_value_added_1_0_0.json +++ b/data/json/decision_points/public_value_added_1_0_0.json @@ -6,9 +6,9 @@ "description": "How much value would a publication from the coordinator benefit the broader community?", "values": [ { - "key": "P", - "name": "Precedence", - "description": "The publication would be the first publicly available, or be coincident with the first publicly available." + "key": "L", + "name": "Limited", + "description": "Minimal value added to the existing public information because existing information is already high quality and in multiple outlets." }, { "key": "A", @@ -16,9 +16,9 @@ "description": "Amplifies and/or augments the existing public information about the vulnerability, for example, adds additional detail, addresses or corrects errors in other public information, draws further attention to the vulnerability, etc." }, { - "key": "L", - "name": "Limited", - "description": "Minimal value added to the existing public information because existing information is already high quality and in multiple outlets." + "key": "P", + "name": "Precedence", + "description": "The publication would be the first publicly available, or be coincident with the first publicly available." } ] } \ No newline at end of file diff --git a/docs/_generated/decision_points/public_value_added_1_0_0.md b/docs/_generated/decision_points/public_value_added_1_0_0.md index 9f315564..63d302cf 100644 --- a/docs/_generated/decision_points/public_value_added_1_0_0.md +++ b/docs/_generated/decision_points/public_value_added_1_0_0.md @@ -7,9 +7,9 @@ | Value | Definition | |:-----|:-----------| - | Precedence | The publication would be the first publicly available, or be coincident with the first publicly available. | - | Ampliative | Amplifies and/or augments the existing public information about the vulnerability, for example, adds additional detail, addresses or corrects errors in other public information, draws further attention to the vulnerability, etc. | | Limited | Minimal value added to the existing public information because existing information is already high quality and in multiple outlets. | + | Ampliative | Amplifies and/or augments the existing public information about the vulnerability, for example, adds additional detail, addresses or corrects errors in other public information, draws further attention to the vulnerability, etc. | + | Precedence | The publication would be the first publicly available, or be coincident with the first publicly available. | === "JSON" diff --git a/docs/_includes/_tree_notation_tip.md b/docs/_includes/_tree_notation_tip.md new file mode 100644 index 00000000..70843c39 --- /dev/null +++ b/docs/_includes/_tree_notation_tip.md @@ -0,0 +1,11 @@ +!!! tip "Tree Notation" + + Rectangles are decision points, and triangles represent outcomes. + The values for each decision point are different, as described above. + Outcomes are priority decisions (defer, scheduled, out-of-cycle, immediate). + Outcome triangles are color coded: + + - Defer = gray with green outline + - Scheduled = yellow + - Out-of-Cycle = orange + - Immediate = red with black outline diff --git a/docs/howto/bootstrap/prepare.md b/docs/howto/bootstrap/prepare.md index 5e1d5866..7dc1f6c5 100644 --- a/docs/howto/bootstrap/prepare.md +++ b/docs/howto/bootstrap/prepare.md @@ -36,7 +36,7 @@ We will go through each step in detail. - [Patch Supplier Prioritization](../supplier_tree.md) - [Patch Deployer Prioritization](../deployer_tree.md) - - [Coordinator Triage](../coordination_decisions.md) + - [Coordinator Triage](../coordination_triage_decision.md) - [Coordinator Publication](../publication_decision.md) The first step in preparing to use SSVC is to choose a decision to model. @@ -61,7 +61,7 @@ flowchart LR !!! example inline end 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, + _Defer_, _Scheduled_, _Out-of-Cycle_, and _Immediate_. In the [Coordinator Triage](../coordination_triage_decision.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_. diff --git a/docs/howto/coordination_decisions.md b/docs/howto/coordination_decisions.md deleted file mode 100644 index 0e6415d2..00000000 --- a/docs/howto/coordination_decisions.md +++ /dev/null @@ -1,47 +0,0 @@ -# Coordination Triage Decisions - -We take three priority levels in our decision about whether and how to coordinate a vulnerability [@householder2020cvd, 1.1] based on an incoming report: - - - *Decline*—Do not act on the report. May take different forms, including ignoring the report as well as an acknowledgement to the reporter that we will not act and suggest the reporter to go to vendor or publish if unresponsive. - - *Track*—Receive information about the vulnerability and monitor for status changes but do not take any overt actions. - - *Coordinate*—Take action on the report. “Action” may include any one or more of: technical analysis, reproduction, notifying vendors, lead coordination (notify, communicate, and publish), publish only (amplify public message), advise only, secondary coordinator (assist another lead coordinator). See [@csirtservices_v2] for additional vulnerability management services a coordinator may provide. - - -## 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](../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. - -- [Report Public](../reference/decision_points/report_public.md) -- [Supplier Contacted](../reference/decision_points/supplier_contacted.md) -- [Report Credibility](../reference/decision_points/report_credibility.md) -- [Supplier Cardinality](../reference/decision_points/supplier_cardinality.md) -- [Supplier Engagement](../reference/decision_points/supplier_engagement.md) - -## Coordination Triage Decision Process - -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*](../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) - -## 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/coordination_intro.md b/docs/howto/coordination_intro.md index 2824c122..ebcb0a90 100644 --- a/docs/howto/coordination_intro.md +++ b/docs/howto/coordination_intro.md @@ -1,23 +1,33 @@ -# Decisions During Vulnerability Coordination +# Vulnerability Coordination Decisions Coordinators are facilitators within the vulnerability management ecosystem. -Since coordinators neither supply nor deploy the vulnerable component in question, their decisions are different from suppliers' or deployers' decisions. +Since coordinators neither supply nor deploy the vulnerable component in question, their decisions are different from +[suppliers'](supplier_tree.md) or [deployers'](deployer_tree.md) decisions. This section provides a window into CERT/CC's decisions as an example of how a coordinator might use SSVC to make its own decisions. + Coordinators vary quite a lot, and their use of SSVC may likewise vary. A coordinator may want to gather and publish information about SSVC decision points that it does not use internally in order to assist its constituents. Furthermore, a coordinator may only publish some of the information it uses to make decisions. Consistent with other stakeholder perspectives (supplier and deployer), SSVC provides the priority with which a coordinator should take some defined action, but not how to do that action. -For more information about types of coordinators and their facilitation actions within vulnerability management, see [@householder2020cvd]. +For more information about types of coordinators and their facilitation actions within vulnerability management, see +[The CERT Guide to Coordinated Vulnerability Disclosure](https://vuls.cert.org/confluence/display/CVD/3.5.+Coordinator) + +The two decisions that CERT/CC makes as a coordinator that we will discuss in terms of SSVC are + +1. [Coordination Triage](coordination_triage_decision.md) - The initial triage of vulnerability reports. This initial coordination decision is a prioritization decision, but it + does not have the same values as prioritization by a [deployer](deployer_tree.md) or [supplier](supplier_tree.md). +2. [Publication](publication_decision.md) - Whether a publication about a vulnerability is warranted. The publication decision for us is a binary yes/no. -The two decisions that CERT/CC makes as a coordinator that we will discuss in terms of SSVC are the initial triage of vulnerability reports and whether a publication about a vulnerability is warranted. -The initial coordination decision is a prioritization decision, but it does not have the same values as prioritization by a deployer or supplier. -The publication decision for us is a binary yes/no. These two decisions are not the entirety of vulnerability coordination, but we leave further details of the process for future work. +!!! tip inline end "CISA and SSVC" + + For another example of how a coordinator is using SSVC, see the [CISA SSVC](https://www.cisa.gov/ssvc) website. + + Different coordinators have different scopes and constituencies. -See [@householder2020cvd, 3.5] for a listing of different coordinator types. +See [The CERT Guide to Coordinated Vulnerability Disclosure](https://vuls.cert.org/confluence/display/CVD/3.5.+Coordinator) for a listing of different coordinator types. If a coordinator receives a report that is outside its own work scope or constituency, it should make an effort to route the report to a more suitable coordinator. -The decisions in this section assume the report or vulnerability in question is in the work scope or constituency for the coordinator. - +The decisions in this section assume the report or vulnerability in question is within the work scope or constituency for the coordinator. diff --git a/docs/howto/coordination_triage_decision.md b/docs/howto/coordination_triage_decision.md new file mode 100644 index 00000000..4519411c --- /dev/null +++ b/docs/howto/coordination_triage_decision.md @@ -0,0 +1,113 @@ +# Prioritizing Vulnerability Coordination + +In coordinated vulnerability disclosure (CVD), there are two available decisions modelled in SSVC. +The first is whether or not to coordinate a vulnerability report. +This decision is also known as triage. + +!!! info "Coordination Triage Priority" + + As noted in [Enumerating Decisions](../topics/enumerating_decisions.md), the root of a decision model's identity is + the combination of the stakeholder and the decision being modeled. + In this case, the stakeholder is the **Coordinator** and the decision is + the **priority of coordinating a vulnerability report**. + + +## Coordinator Triage Units of Work + +!!! info inline end "Coordinator Unit of Work" + + The unit of work for a Coordinator is usually a single report to be coordinated. + +Coordinator units of work tend to coincide with whatever arrives in a single report, which spans the range from a single +vulnerability affecting a specific version of an individual product from one Supplier all the way to fundamental design +flaws in system specifications that could affect every Supplier and product that uses or implements the flawed specification. +Coordinators may need to reorganize reports (e.g., merge, split, expand, or contract) according to their workflow demands. +SSVC can be applied to either the initial report or to the results of such refinement. + + +## Coordinator Triage Decision Outcomes + +We take three priority levels in our decision about whether and how to [coordinate](https://vuls.cert.org/confluence/display/CVD/1.1.+Coordinated+Vulnerability+Disclosure+is+a+Process%2C+Not+an+Event) +a vulnerability based on an incoming report: + +!!! info "Coordinator Triage Priority" + + | Triage Priority | Description | + | :--- | :---------- | + | Decline | Do not act on the report. | + | Track | Receive information about the vulnerability and monitor for status changes but do not take any overt actions. | + | Coordinate | Take action on the report. “Action” may include any one or more of: technical analysis, reproduction, notifying vendors, publication, and assist another party. | + + + - *Decline* — Do not act on the report. May take different forms, including ignoring the report as well as an + acknowledgement to the reporter that we will not act and suggest the reporter to go to vendor or publish if unresponsive. + - *Track* — Receive information about the vulnerability and monitor for status changes but do not take any overt actions. + - *Coordinate* — Take action on the report. “Action” may include any one or more of: technical analysis, reproduction, + notifying vendors, lead coordination (notify, communicate, and publish), publish only (amplify public message), + advise only, secondary coordinator (assist another lead coordinator). + See the [FIRST CSIRT Services Framework](https://www.first.org/standards/frameworks/csirts/csirt_services_framework_v2.1#7-Service-Area-Vulnerability-Management) + for additional vulnerability management services a coordinator may provide. + + +## Coordinator Triage Decision Points + +!!! tip inline end "Prior CERT/CC Work on Prioritizing Coordination Decisions" + + [Vulnerability Response Decision Assistance](https://insights.sei.cmu.edu/library/vulnerability-response-decision-assistance-vrda/) + (VRDA) provides a starting point for a decision model for this situation. + VRDA is likely [adequate](https://insights.sei.cmu.edu/library/effectiveness-of-the-vulnerability-response-decision-assistance-vrda-framework/) + for national-level CSIRTs that do general CVD, but other CSIRT types may have different needs. + The [*CERT Guide to Coordinated Vulnerability Disclosure*](https://vuls.cert.org/confluence/display/CVD/6.10+Troubleshooting+Coordinated+Vulnerability+Disclosure+Table) + provides something similar for those who are deciding how to report and disclose vulnerabilities they have discovered. + +The coordination and publication decisions for CERT/CC are about the social and collaborative state of vulnerability management. +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 common to [Suppliers](supplier_tree.md) and [Deployers](deployer_tree.md) +([Utility](../reference/decision_points/utility.md) and [Public Safety Impact](../reference/decision_points/public_safety_impact.md)), we have added five new decision points for the coordination decision model. + +The first two function as gating questions: + +- [Report Public](../reference/decision_points/report_public.md): 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). +- [Supplier Contacted](../reference/decision_points/supplier_contacted.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 this 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 decision model below shows. + +The remaining five decision points are: + +- [Report Credibility](../reference/decision_points/report_credibility.md): If the report is not credible, then CERT/CC will decline the case. +- [Supplier Cardinality](../reference/decision_points/supplier_cardinality.md): Cases involving multiple suppliers can get complicated very quickly, so we are more likely to get involved in those cases. +- [Supplier Engagement](../reference/decision_points/supplier_engagement.md): If the suppliers are already engaged in a case, there is usually less for a coordinator to do, making it less likely that we will coordinate a case. +- [Utility](../reference/decision_points/utility.md): If the vulnerability has high utility, then CERT/CC is more likely to coordinate the case. +- [Public Safety Impact](../reference/decision_points/public_safety_impact.md): If the vulnerability has significant + public safety impact, then CERT/CC is more likely to coordinate the case. + +More detail about each of these decision points is provided at the links above, here we provide a brief summary of each. + +{% include-markdown "../_generated/decision_points/report_public.md" %} +{% include-markdown "../_generated/decision_points/supplier_contacted.md" %} +{% include-markdown "../_generated/decision_points/report_credibility.md" %} +{% include-markdown "../_generated/decision_points/supplier_cardinality.md" %} +{% include-markdown "../_generated/decision_points/supplier_engagement.md" %} +{% include-markdown "../_generated/decision_points/utility.md" %} +{% include-markdown "../_generated/decision_points/public_safety_impact.md" %} + +## Coordinator Triage Decision Model + +The following example decision model is a policy that closely follows our own decision model at the CERT/CC. +Other coordinators should consider customizing the tree to their needs, as described in [Tree Construction and Customization Guidance](tree_customization.md). + +!!! tip "SSVC Customization in Action: CISA" + + CISA has customized an SSVC decision model to suit their coordination needs. + It is available at [https://www.cisa.gov/ssvc](https://www.cisa.gov/ssvc). + + + +### Table of Values + + +{{ read_csv('coord-triage-options.csv') }} diff --git a/docs/howto/deployer_tree.md b/docs/howto/deployer_tree.md index b5443224..f53b9522 100644 --- a/docs/howto/deployer_tree.md +++ b/docs/howto/deployer_tree.md @@ -1,14 +1,144 @@ -# Deployer Tree +# Prioritizing Patch Deployment -The example deployer tree [PDF](../pdf/ssvc_2_deployer_SeEUMss.pdf) is depicted below. +Here we describe an example decision model for a Deployer deciding the priority of deploying a patch for a vulnerability +in their infrastructure. +!!! info "Deployer Patch Deployment Priority" + + As noted in [Enumerating Decisions](../topics/enumerating_decisions.md), the root of a decision model's identity is + the combination of the stakeholder and the decision being modeled. In this case, the stakeholder is the **Deployer** and the + decision is the **priority of deploying a patch**. + +## Deployer Units of Work + +!!! info inline end "Deployer Unit of Work" + + The unit of work for a Deployer is usually a single deployable patch or patch bundle such as a service pack. + +Deployers are usually in the position of receiving remediations or mitigations from their [Suppliers](supplier_tree.md) +for products they have deployed. +They must then decide whether to deploy the remediation or mitigation to a particular instance (or not). +Whether they have the option of deploying only part of a remediation such as a fix bundle depends on whether the +Supplier has engineered their release process to permit that degree of flexibility. +For example, if service packs are fix bundles, the Supplier might choose to release individually deployable fixes as well. + +The vulnerability management process for deployers has at its core the collation of data including + +!!! tip inline end "Relationship to asset management" + + The relationship between SSVC and asset management is discussed further in [SSVC and Asset Management](../topics/asset_management.md). + +- an inventory of deployed instances of product versions +- a mapping of vulnerabilities to remediations or mitigations +- a mapping of remediations and/or mitigations to product versions + +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**. + + +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 model described below considers the mission and safety risks inherent to the category of systems to which those +deployed instances belong. +For this reason, we recommend that the pairing of remediation or mitigation to a product version instance constitutes +the unit of work most appropriate for the Deployer. + +## Deployer Decision Outcomes + +A deployer's decision centers on with what priority to deploy a given remediation or mitigation to their infrastructure. +Similar to the [Supplier](supplier_tree.md) case, we consider four categories of priority, as outlined in the table below. +While we've used the same priority names, the meaning of the priority may have different implications for the deployer than for the supplier. + +!!! note "Patch Deployer Priority" + + | Deployer Priority | Description | + | :--- | :---------- | + | Defer | Do not act at present. | + | Scheduled | Act during regularly scheduled maintenance time. | + | Out-of-cycle | Act more quickly than usual to apply the mitigation or remediation out-of-cycle, during the next available opportunity, working overtime if necessary. | + | Immediate | Act immediately; focus all resources on applying the fix as quickly as possible, including, if necessary, pausing regular organization operations. | + + +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. +A mitigation that successfully changes the value of a decision point may shift the priority of further action to a +reduced state. +If applying a mitigation reduces the priority to *defer*, the deployer may not need to apply a remediation if it later +becomes available. + +!!! example "Mitigation Examples" + + - An effective firewall or IDS rule coupled with an adequate change control process for rules may change + [*System Exposure*](../reference/decision_points/system_exposure.md) from open to controlled. This could be enough + to reduce the priority where no further action is necessary. + - In the area of Financial [*Safety Impact*](../reference/decision_points/safety_impact.md), a better insurance policy may be purchased, providing necessary fraud insurance. + - Physical [*Safety Impact*](../reference/decision_points/safety_impact.md) may be reduced by testing the + physical barriers designed to restrict a robot's ability to interact with humans. + - [*Mission Impact*](../reference/decision_points/mission_impact.md) could be reduced by correcting the problems identified in a disaster recover test-run of the alternate business flow. + +However, mitigation techniques will not always be adequate to address the risk posed by the vulnerability. + +!!! example "Examples of Inadequate Mitigation" + + - 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*](../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. + +As opposed to mitigation, applying a remediation finishes an SSVC analysis of a deployed system. + +!!! warning "Remediation is not a final state" + + While specific vulnerabilities in specific systems can be remediated, the vulnerability cannot be 'disposed of' or + eliminated from future consideration within an IT environment. + Since software and systems are dynamic, a single vulnerability can be re-introduced after initial remediation + through updates, software rollbacks, or other systemic actions that change the operating conditions within an environment. + It is therefore important to continually monitor remediated environments for vulnerabilities reintroduced by + either rollbacks or new deployments of outdated software. + +## Deployer Decision Points + +The Deployer Patch Deployment Priority decision model uses the following decision points: + +- [*Exploitation*](../reference/decision_points/exploitation.md) - A vulnerability with known exploitation is more likely to be given a higher priority. +- [*System Exposure*](../reference/decision_points/system_exposure.md) - The more exposed a system is, the more likely it is to be given a higher priority. +- [*Utility*](../reference/decision_points/utility.md) - The more useful a vulnerability is to an attacker, the more likely it is to be given a higher priority. +- [*Human Impact*](../reference/decision_points/human_impact.md) - The more severe the human (safety, mission) impact of a vulnerability, the more likely it is to be given a higher priority. + +More detail about each of these decision points is provided at the links above, here we provide a brief summary of each. + +{% include-markdown "../_generated/decision_points/exploitation.md" %} +{% include-markdown "../_generated/decision_points/system_exposure.md" %} +{% include-markdown "../_generated/decision_points/utility.md" %} +{% include-markdown "../_generated/decision_points/human_impact.md" %} + +## Deployer Decision Model + +Below we provide an example deployer prioritization policy that maps the decision points just listed to the outcomes described above. + +!!! tip "Notes on the Deployer Decision Model Example Policy" + + In the example policy shown below: + + - 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. + + +{% include-markdown "../_includes/_tree_notation_tip.md" %} -## Table of Values +### Table of Values {{ read_csv('deployer-options.csv') }} \ No newline at end of file diff --git a/docs/howto/publication_decision.md b/docs/howto/publication_decision.md index 3b7c4afc..c9320a7e 100644 --- a/docs/howto/publication_decision.md +++ b/docs/howto/publication_decision.md @@ -1,9 +1,102 @@ # Coordinator Publication Decision -A coordinator often has to decide when or whether to publish information about a vulnerability. -A supplier also makes a decision about publicity—releasing information about a remediation or mitigation could be viewed as a kind of publication decision. -While the context of publication is different for coordinators, a supplier may find some use in a publication decision if they need to decide whether to publish before a mitigation or remediation is available. -However, that is not the intended use case; this section describes how a coordinator might decide to publish information about a vulnerability. +Coordinators have to make two decisions about publication of information about a vulnerability. +The first is whether to coordinate the vulnerability, which we discuss in [Coordination Triage](coordination_triage_decision.md). +The second decision is whether to publish information about a vulnerability. +While other stakeholders may also have to make a publication decision, here we focus on the coordinator's decision. + +!!! info "Coordinator Publication Decision" + + As noted in [Enumerating Decisions](../topics/enumerating_decisions.md), the root of a decision model's identity is + the combination of the stakeholder and the decision being modeled. In this case, the stakeholder is the + **Coordinator** and the decision is **whether to publish an advisory about the vulnerability**. + + +## Policy Constraints and Publication Decisions + +!!! tip inline end "Other Stakeholders' Publication Decisions" + + Other stakeholders may also have to make a publication decision. + For example, a supplier may have to decide whether to publish information about a vulnerability in their product. + A deployer may have to decide whether to publish information about a vulnerability in their infrastructure. + A vulnerability finder may have to decide whether to publish information about a vulnerability they have discovered. + Each of these decisions is likely to be different from the coordinator's decision. + +The decision to publish information about a vulnerability is a policy choice, and is likely to differ from organization +to organization. +Two points where CERT/CC policy clearly influences the publication decision are embargo periods and scope. + +### Publication and Embargo Periods + +As a matter of policy, CERT/CC will support an embargo from the public of information about a vulnerability through its +choice not to publish that information while a number of conditions hold: + + - A negotiated embargo timer has not expired. The CERT/CC default embargo period is [45 days](https://vuls.cert.org/confluence/display/Wiki/Vulnerability+Disclosure+Policy). + - 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. + +### Triage Decisions and Publication + +The second point is related to the [Coordination Triage Decision](coordination_triage_decision.md) and the status of the vulnerability. +CERT/CC only expects to publish about vulnerabilities with a [*coordinate*](coordination_triage_decision.md) status. +While an issue that is tracked or declined may be reevaluated at a later date and status changed to [*coordinate*](coordination_triage_decision.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 Decision](coordination_triage_decision.md) in their publication decision. + + + +## Coordinator Publication Units of Work + +!!! info inline end "Coordinator Publication Unit of Work" + + The unit of work for the coordinator publication decision a single publication. + For CERT/CC, this corresponds to a CERT Vulnerability Note. + +In the CERT/CC's vulnerability coordination practice, a single report leads to a single coordination case which leads to a +single publication. Therefore the unit of work for the publication decision is often the same as the unit of work for the +[coordination triage decision](coordination_triage_decision.md). + +That is sometimes not the case, however. For example, there could be multiple reports of multiple vulnerabilities and +the coordinator might choose to publish a single advisory covering all of them if the vulnerabilities are variations on +a central theme and have a common set of affected products. + +!!! example "Multiple Reports, Single Advisory" + + There are numerous examples of multiple reported vulnerabilities being consolidated into a single publication + in the CERT/CC's history. A few recent cases include: + + - [VU#132380](https://kb.cert.org/vuls/id/132380) _Vulnerabilities in EDK2 NetworkPkg IP stack implementation._ + - [VU#434994](https://kb.cert.org/vuls/id/434994) _Multiple race conditions due to TOCTOU flaws in various UEFI Implementations_ + - [VU#811862](https://kb.cert.org/vuls/id/811862) _Image files in UEFI can be abused to modify boot behavior_ + +Another possibility is that a single report could lead to multiple advisories, for example if +the product is a library that is used in multiple other products, and the coordinator chooses to publish separate advisories +based on some other criteria. + +!!! example "Single Report, Multiple Advisories" + + Occasionally, a single report leads to multiple advisories. For example + + - [VU#854306](https://kb.cert.org/vuls/id/854306) _Multiple vulnerabilities in SNMPv1 request handling_ + - [VU#107186](https://kb.cert.org/vuls/id/107186) _Multiple vulnerabilities in SNMPv1 trap handling_ + + arrived as a single report and were published as separate vulnerability notes + because they affected different aspects of the libraries in question. Although this example pre-dates SSVC by + many years, it is illustrative of the situation where a single report leads to multiple advisories. + +## Coordinator Publication Decision Outcomes + +For the CERT/CC, the publication decision is binary: publish or do not publish. + +!!! note "Coordinator Publish Priority" + + | Publish Priority | Description | + | :--- | :---------- | + | Do not publish | Do not publish information about the vulnerability. | + | Publish | Publish information about the vulnerability. | !!! tip "The Publication Decision is Time Sensitive" @@ -15,37 +108,57 @@ However, that is not the intended use case; this section describes how a coordin One benefit of encoding the decision process in SSVC is the analysts can all agree on what new information would change the decision and prioritize maintaining awarenss of just those decision points. -This section is based on CERT/CC policy choices. -Two points where this clearly influences the publication decision are embargo periods and scope. -As a matter of policy, CERT/CC will support an embargo from the public of information about a vulnerability through its choice not to publish that information while a number of conditions hold: - - - A negotiated embargo timer has not expired. The CERT/CC default embargo period is [45 days](https://vuls.cert.org/confluence/display/Wiki/Vulnerability+Disclosure+Policy). - - Other exceptions have not been met, including active exploitation of the vulnerability in the wild or other public discussion of the vulnerability details. +!!! example "CERT/CC Publication Decision Outcomes Over Time" -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_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. + The CERT/CC has a [long history](https://vuls.cert.org/confluence/display/historical/CERT+Advisory+CA-1988-01+ftpd+Vulnerability) + of publishing information about vulnerabilities. + In the past, the CERT/CC had multiple publication vehicles, including + [Vulnerability Notes](https://www.kb.cert.org/vuls), + [CERT Advisories](https://vuls.cert.org/confluence/display/historical/CERT+Advisories), and + [Current Activity](https://web.archive.org/web/20040411195130/http://www.cert.org/current/archive/2003/12/29/archive.html) + entries. + Each of these had different publication criteria. Had we been using SSVC at the time, we might + have modeled the publication decision differently for each of these vehicles. Or we might have modeled the decision as + a single decision with multiple outcomes, each of which would lead to a different publication vehicle. This is an example + of how SSVC can be customized to the needs of the organization using it. -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) +## Coordinator Publication Decision Points -## Coordinator Publication Decision Tree +The publication decision reuses the [*Exploitation*](../reference/decision_points/exploitation.md) decision point +and adds two new ones ([*Supplier Involvement*](../reference/decision_points/supplier_involvement.md) and +[*Public Value Added*](../reference/decision_points/public_value_added.md)). -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. +- [*Supplier Involvement*](../reference/decision_points/supplier_involvement.md) - If the supplier is involved and likely to publish already, there is less need for the CERT/CC to publish. +- [*Exploitation*](../reference/decision_points/exploitation.md) - If the vulnerability is being actively exploited, the CERT/CC is more likely to publish. +- [*Public Value Added*](../reference/decision_points/public_value_added.md) - If there is already significant public discussion of the vulnerability, there might not be + much for the CERT/CC to add, making us less likely to publish. + +More detail about each of these decision points is provided at the links above, here we provide a brief summary of each. + +{% include-markdown "../_generated/decision_points/supplier_involvement.md" %} +{% include-markdown "../_generated/decision_points/exploitation.md" %} +{% include-markdown "../_generated/decision_points/public_value_added.md" %} + + +## Coordinator Publication Decision Model + +An example coordinator publication decision model is shown below. The policy described by the model is based on CERT/CC +publication decisions. Other organizations may have different publication criteria and may want to include other decision points +in their publication decision model. - +|precedence| p25 va9 -->|ampliative| p26 va9 -->|limited| p27 - - - - - - ``` +--> ### Table of Values diff --git a/docs/howto/supplier_tree.md b/docs/howto/supplier_tree.md index 9c0bde6b..380a1177 100644 --- a/docs/howto/supplier_tree.md +++ b/docs/howto/supplier_tree.md @@ -1,18 +1,100 @@ -# Supplier Tree +# Prioritizing Patch Creation -The example supplier tree [PDF](../pdf/ssvc_2_supplier.pdf) shows the proposed prioritization decision tree for the supplier. Both supplier and deployer trees use the above decision point definitions. Each tree is a compact way of expressing assertions or hypotheses about the relative priority of different situations. Each tree organizes how we propose a stakeholder should treat these situations. Rectangles are decision points, and triangles represent outcomes. The values for each decision point are different, as described above. Outcomes are priority decisions (defer, scheduled, out-of-cycle, immediate); outcome triangles are color coded: +Here we describe an example decision model for a Supplier deciding the priority of creating a patch for a +vulnerability in their software. + +!!! info "Supplier Patch Creation Priority" + + As noted in [Enumerating Decisions](../topics/enumerating_decisions.md), + the root of a decision model's identity is the combination of the stakeholder and the decision being modeled. + In this case, the stakeholder is the **Supplier** and the decision is the **priority of creating a patch**. + +## Supplier Units of Work + +On the input side of the Supplier process, Suppliers typically receive reports of vulnerabilities in one or more versions of their product. +Part of the Supplier's task on initial report intake is to resolve the initial report into a set of products and versions that are affected by the reported vulnerability. + +!!! info inline end "Supplier Unit of Work" + + For the purposes of SSVC, we consider the unit of work for a Supplier to be combination of the vulnerability with each affected product. + +Our working assumption is that for SSVC purposes, the supplier's unit of work is the combination of the vulnerability with each affected product. +This implies the need for Suppliers to be able to resolve whatever they receive to that level of granularity in order to make best use of SSVC. + +Products will often need to be addressed individually because they may have diverse development processes or usage scenarios. +There are a variety of ways a Supplier might need to resolve the set of affected products. For example, they might + +!!! tip inline end "Independently Fixable Vulnerabilities" + + Without belaboring the point, these methods are similar to how [CVE Numbering Authorities](https://www.cve.org/ResourcesSupport/AllResources/CNARules#section_7_assignment_rules) discern “independently fixable vulnerabilities”. + + We also note that [Software Bill of Materials](https://www.cisa.gov/sbom) (SBOM) seems well-placed to aid in that resolution process for the third-party library scenarios. + +- recognize, on further investigation of the initial report, that additional versions of the product are affected +- discover that other products are affected due to code sharing or programmer error consistent across products +- receive reports of vulnerabilities in third party libraries they utilize in one or more of their products +- receive fix bundles for third party libraries used in one or more of their products (where a fix bundle might resolve multiple vulnerabilities or add new features) + +In the end, Suppliers provide remediations and/or mitigations for affected products. +A supplier-provided remediation is usually a software update which contains fixes for multiple vulnerabilities and, often, new or improved features. +Supplier output is relevant because it will become input to [Deployers](deployer_tree.md). +SSVC focuses only on the remediation in this case; a set of remediations for multiple vulnerabilities is a fix bundle. +Suppliers may also produce mitigations, such as recommended configuration changes, to limit the impact of a vulnerability. + +## Supplier Decision Outcomes + +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 the table below. + +!!! note "Patch Supplier Priority" + + | Supplier Priority | Description | + | :--- | :---------- | + | Defer | Do not work on the patch at present. | + | Scheduled | Develop a fix within regularly scheduled maintenance using supplier resources as normal. | + | Out-of-Cycle | Develop mitigation or remediation out-of-cycle, taking resources away from other projects and releasing the fix as a security patch when it is ready. | + | Immediate | Develop and release a fix as quickly as possible, drawing on all available resources, potentially including drawing on or coordinating resources from other parts of the organization. | + +## Supplier Decision Points + +The decision to create a patch is based on the following decision points: + +- [*Exploitation*](../reference/decision_points/exploitation.md) - A vulnerabilty with known exploitation is more likely to be given a higher priority. +- [*Utility*](../reference/decision_points/utility.md) - The more useful a vulnerability is to an attacker, the more likely it is to be given a higher priority. +- [*Technical Impact*](../reference/decision_points/technical_impact.md) - The more severe the technical impact of a vulnerability, the more likely it is to be given a higher priority. +- [*Public Safety Impact*](../reference/decision_points/public_safety_impact.md) - The more severe the public safety impact of a vulnerability, the more likely it is to be given a higher priority. + +More detail about each of these decision points is provided at the links above, here we provide a brief summary of each. + +{% include-markdown "../_generated/decision_points/exploitation.md" %} +{% include-markdown "../_generated/decision_points/utility.md" %} +{% include-markdown "../_generated/decision_points/technical_impact.md" %} +{% include-markdown "../_generated/decision_points/public_safety_impact.md" %} + +!!! tip "Public Safety Impact is a notational convenience" + + The [Public Safety Impact](../reference/decision_points/public_safety_impact.md) decision point is a + simplification of the more detailed [Safety Impact](../reference/decision_points/safety_impact.md) decision point. + +## Supplier Decision Model + +The example supplier decision model below shows a prioritization policy for the supplier. +We display the decision model as a decision tree, which provides a compact representation of the policy, +showing the relative priority of different situations. + +{% include-markdown "../_includes/_tree_notation_tip.md" %} - - Defer = gray with green outline - - Scheduled = yellow - - Out-of-Cycle = orange - - Immediate = red with black outline - -## Table of Values +### Table of Values -{{ read_csv('supplier-options.csv') }} \ No newline at end of file +{{ read_csv('supplier-options.csv') }} diff --git a/docs/howto/tree_customization.md b/docs/howto/tree_customization.md index f028a7b5..35016ecd 100644 --- a/docs/howto/tree_customization.md +++ b/docs/howto/tree_customization.md @@ -34,9 +34,9 @@ For example, a vulnerability with and [efficient](../reference/decision_points/utility.md) [Utility](../reference/decision_points/utility.md) might be handled with -[*scheduled*](../topics/enumerating_actions.md) +[*scheduled*](../howto/deployer_tree.md) priority by one team and -[*out-of-cycle*](../topics/enumerating_actions.md) +[*out-of-cycle*](../howto/deployer_tree.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. diff --git a/docs/topics/enumerating_actions.md b/docs/topics/enumerating_actions.md deleted file mode 100644 index a7e00044..00000000 --- a/docs/topics/enumerating_actions.md +++ /dev/null @@ -1,91 +0,0 @@ -# Enumerating Action Priority - -SSVC models the decision of -“With what priority should the organization take action on a given vulnerability management work unit?” -to be agnostic to whether or not a patch is available. -We explain what we mean by a “work unit” in the previous section. -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 the table below. - -!!! note "Patch Supplier Priority" - - | Supplier Priority | Description | - | :--- | :---------- | - | Defer | Do not work on the patch at present. | - | Scheduled | Develop a fix within regularly scheduled maintenance using supplier resources as normal. | - | Out-of-Cycle | Develop mitigation or remediation out-of-cycle, taking resources away from other projects and releasing the fix as a security patch when it is ready. | - | Immediate | Develop and release a fix as quickly as possible, drawing on all available resources, potentially including drawing on or coordinating resources from other parts of the organization. | - -## 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. 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*](../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*](../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*](../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. - -A mitigation that successfully changes the value of a decision point may shift the priority of further action to a reduced state. -If applying a mitigation reduces the priority to *defer*, the deployer may not need to apply a remediation, if later, it becomes available. -{== 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*](../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. - -!!! warning "Remediation is not a final state" - - While specific vulnerabilities in specific systems can be remediated, the vulnerability cannot be 'disposed of' or eliminated from future consideration within an IT environment. - Since software and systems are dynamic, a single vulnerability can be re-introduced after initial remediation through updates, software rollbacks, or other systemic actions that change the operating conditions within an environment. - It is therefore important to continually monitor remediated environments for vulnerabilities reintroduced by either rollbacks or new deployments of outdated software. - -!!! note "Patch Deployer Priority" - - | Deployer Priority | Description | - | :--- | :---------- | - | Defer | Do not act at present. | - | Scheduled | Act during regularly scheduled maintenance time. | - | Out-of-cycle | Act more quickly than usual to apply the mitigation or remediation out-of-cycle, during the next available opportunity, working overtime if necessary. | - | Immediate | Act immediately; focus all resources on applying the fix as quickly as possible, including, if necessary, pausing regular organization operations. | - -## Coordinating Patches -In coordinated vulnerability disclosure (CVD), there are two available decisions modelled in version 2 of SSVC. -The first is whether or not to coordinate a vulnerability report. -This decision is also known as triage. -Vulnerability Response Decision Assistance (VRDA) provides a starting point for a decision tree for this situation. -VRDA is likely adequate for national-level CSIRTs that do general CVD, but other CSIRT types may have different needs. -The *CERT guide to Coordinated Vulnerability Disclosure* provides something similar for those who are deciding how to report and disclose vulnerabilities they have discovered [@householder2020cvd, section 6.10]. - -!!! note "Coordinator Triage Priority" - - | Triage Priority | Description | - | :--- | :---------- | - | Decline | Do not act on the report. | - | Track | Receive information about the vulnerability and monitor for status changes but do not take any overt actions. | - | Coordinate | Take action on the report. “Action” may include any one or more of: technical analysis, reproduction, notifying vendors, publication, and assist another party. | - -The second decision is whether to publish information about a vulnerability. - -!!! note "Coordinator Publish Priority" - - | Publish Priority | Description | - | :--- | :---------- | - | Do not publish | Do not publish information about the vulnerability. | - | Publish | Publish information about the vulnerability. | diff --git a/docs/topics/enumerating_decisions.md b/docs/topics/enumerating_decisions.md index d0395def..9ce6de99 100644 --- a/docs/topics/enumerating_decisions.md +++ b/docs/topics/enumerating_decisions.md @@ -12,16 +12,131 @@ Some decision makers may have different responsibilities in relation to differen - A web browser developer makes decisions about applying patches to DNS lookup libraries and transport layer security (TLS) libraries. - A video game developer makes decisions about applying patches released to the Unreal Engine. - A medical device developer makes decisions about applying patches to the Linux kernel. - - The list goes on. + + -Alternatively, one might view applying patches as including some development and distribution of the updated product. +One might view applying patches as including some development and distribution of the updated product. Or one might take the converse view, that development includes updating libraries. Either way, in each of these examples (mobile device apps, web browsers, video games, medical devices), we recommend that the professionals making genuine decisions do three things: +!!! example inline end "Bootstrapping SSVC" + + We provide a more detailed process for SSVC adoption in [Bootstrapping SSVC](../howto/bootstrap/index.md). + 1. identify the decisions explicitly 2. describe how they view their role(s) 3. identify which software projects their decision relates to +SSVC models the decision of +“With what priority should the organization take action on a given vulnerability management work unit?” +to be agnostic to whether or not a patch is available. If their decisions are explicit, then the decision makers can use the recommendations from this documentation that are relevant to them. + + +!!! tip "The Stakeholder Role / Decision Identity" + + As we have continued to develop SSVC and received feedback from SSVC implementers, we've found that similar + stakeholders making similar decisions can often use the same set of decision points to model their decisions. + Organizations might use the same structure of decision points but have different priority levels they need to map to + their decisions. For example, one organization might need to map their decisions to three priority levels, while another + might need to map their decisions to five priority levels. + + Variation can also arise from different organization goals or risk tolerance that alters the policy mapping the + decision points to priority outcomes. The decision points themselves are often the same for the + stakeholder-decision pairing, but the policy that maps the decision points to priority outcomes is different. + + The salient information required to make a specific kind of decision in a specific context is often the same across + organizations. + For this reason, we have found it useful to think of the identity of a decision model as the combination of the + _stakeholder role_ and the _decision_ being modeled. We've provided a few examples of different stakeholders' decision models + in the [_SSVC How-To_](../howto/index.md) section: + + - [Supplier deciding whether to create a patch](../howto/supplier_tree.md) + - [Deployer deciding whether to deploy a patch](../howto/deployer_tree.md) + - [Coordinator deciding whether to coordinate a case](../howto/coordination_triage_decision.md) + - [Coordinator deciding whether to publish about a case](../howto/publication_decision.md) + + +## Enumerating Vulnerability Management Units of Work + +!!! example inline end "Stakeholder Units of Work" + + We provide a few examples of different stakeholders' units of work in the [_SSVC How-To_](../howto/index.md) section. + See the _Units of Work_ section of each stakeholder's decision model for more information. + + - [Supplier](../howto/supplier_tree.md) + - [Deployer](../howto/deployer_tree.md) + - [Coordinator Triage](../howto/coordination_triage_decision.md) + - [Coordinator Publication](../howto/publication_decision.md) + +A unit of work means either remediating the vulnerability—such as applying a patch—or deploying a mitigation. +Both remediation and mitigations often address multiple identified vulnerabilities. +The unit of work may be different for different stakeholders: a supplier might be selecting individual vulnerabilities to fix, +while a deployer is choosing whether or not to deploy a patch bundle that fixes multiple vulnerabilities. + +The units of work can also change as the vulnerability response progresses through a stakeholder's process. +Coordinators might make triage decisions on individual reports, but then make publication decisions on a set of related cases at once. + +### Aggregation of SSVC Across Units of Work + +SSVC users should answer the suggested questions for whatever discrete unit of work they are considering. +There is not necessarily a reliable function to aggregate a recommendation about remediation out of its constituent +vulnerabilities. +For the sake of simplicity of examples, we treat the remediation as a patch of one vulnerability, and comment on any +difficulty in generalizing our advice to a more complex patch where appropriate. + +!!! info "Remediation and Mitigation" + + To further clarify terms, we use the definitions from + [DoD Instruction 8530.01](https://www.esd.whs.mil/Portals/54/Documents/DD/issuances/dodi/853001p.pdf) + _Cybersecurity Activities Support to DoD Information Network Operations_ (DODI 8530.01). + + - **Remediation** occurs when the vulnerability is eliminated or removed. + - **Mitigation** occurs when the impact of the vulnerability is decreased without reducing or eliminating the vulnerability + + Examples of remediation include applying patches, fixes and upgrades; or removing the vulnerable software or system from operation. + Mitigating actions may include software configuration changes, adding firewall ACLs, or otherwise limiting the system's + exposure to reduce the risk of the impact of the vulnerability; or accepting the risk. + + + +## Enumerating Action Priority + +!!! example inline end "Decision Outcomes and Action Priority" + + We provide examples of different stakeholders' action priorities in the [_SSVC How-To_](../howto/index.md) section. + See the _Decision Outcomes_ section of each stakeholder's decision model for more information. + + - [Supplier](../howto/supplier_tree.md) + - [Deployer](../howto/deployer_tree.md) + - [Coordinator Triage](../howto/coordination_triage_decision.md) + - [Coordinator Publication](../howto/publication_decision.md) + +Structuring decisions about vulnerability management action priority is a core concept of SSVC. +However, we also recognize that each stakeholder has different responsibilities and therefore different decisions to make. +Furthermore, even when stakeholders are making similar decisions, they may have different goals and constraints, which +lead to different priorities. + +For example, some suppliers might need to map their vulnerability response decisions onto a specific set of service +level expectations (SLEs) set by their contractual obligations to their customers. Similarly, deployers might need to integrate +their decisions into a broader risk management framework or +[IT Service Management](https://en.wikipedia.org/wiki/IT_service_management) (ITSM) process. + + +!!! example "SSVC, Vulnerability Response, and Risk Management Processes" + + A few examples from the US Government of organizational process requirements that can affect the decision + modeling process in SSVC adoption include: + + - [CISA Binding Operational Directive (BOD) 22-01](https://www.cisa.gov/news-events/directives/bod-22-01-reducing-significant-risk-known-exploited-vulnerabilities), + _Reducing the Significant Risk of Known Exploited Vulnerabilities_, sets service level expectations for federal agencies to remediate vulnerabilities based on the exploitation status of the vulnerability. + - [DoDI 8510.01](https://www.esd.whs.mil/Portals/54/Documents/DD/issuances/dodi/851001p.pdf), _Risk Management Framework for DoD Systems_, + includes multiple steps involving prioritization of impact levels (Task P-6), stakeholder assets (Task P-10), and + security requirements (Task P-15). + + SSVC implementers in organizations subject to requirements like these may need to adapt their decision models to + ensure that they are consistent with the requirements of the organization's broader risk management and ITSM processes. + + + diff --git a/docs/topics/units_of_work.md b/docs/topics/units_of_work.md deleted file mode 100644 index bab83d5c..00000000 --- a/docs/topics/units_of_work.md +++ /dev/null @@ -1,99 +0,0 @@ -# Enumerating Vulnerability Management Units of Work - -SSVC models the decision of -“With what priority should the organization take action on a given vulnerability management work unit?” -to be agnostic to whether or not a patch is available. -In this page, we explain what we mean by a “work unit”. -In the next page, we explain what we mean by “priority”. - - -!!! note "Units of Work" - - A unit of work means either remediating the vulnerability—such as applying a patch—or deploying a mitigation. - Both remediation and mitigations often address multiple identified vulnerabilities. - The unit of work may be different for different stakeholders. - The units of work can also change as the vulnerability response progresses through a stakeholder's process. - -We elucidate these ideas with the following examples. - -## Supplier Units of Work - -On the input side of the Supplier process, Suppliers typically receive reports of vulnerabilities in one or more versions of their product. -Part of the Supplier's task on initial report intake is to resolve the initial report into a set of products and versions that are affected by the reported vulnerability. - -!!! info inline end "Supplier Unit of Work" - - For the purposes of SSVC, we consider the unit of work for a Supplier to be combination of the vulnerability with each affected product. - -Our working assumption is that for SSVC purposes, the supplier's unit of work is the combination of the vulnerability with each affected product. -This implies the need for Suppliers to be able to resolve whatever they receive to that level of granularity in order to make best use of SSVC. - -Products will often need to be addressed individually because they may have diverse development processes or usage scenarios. -There are a variety of ways a Supplier might need to resolve the set of affected products. For example, they might - -!!! tip inline end "Independently Fixable Vulnerabilities" - - Without belaboring the point, these methods are similar to how CVE Numbering Authorities discern “independently fixable vulnerabilities” [@mitre2020cna]. - - We also note that SBOM[@manion2019sbom] seems well-placed to aid in that resolution process for the third-party library scenarios. - -- recognize, on further investigation of the initial report, that additional versions of the product are affected -- discover that other products are affected due to code sharing or programmer error consistent across products -- receive reports of vulnerabilities in third party libraries they utilize in one or more of their products -- receive fix bundles for third party libraries used in one or more of their products (where a fix bundle might resolve multiple vulnerabilities or add new features) - - - -In the end, Suppliers provide remediations and/or mitigations for affected products. -A supplier-provided remediation is usually a software update which contains fixes for multiple vulnerabilities and, often, new or improved features. -Supplier output is relevant because it will become input to Deployers. -SSVC focuses only on the remediation in this case; a set of remediations for multiple vulnerabilities is a fix bundle. -Suppliers may also produce mitigations, such as recommended configuration changes, to limit the impact of a vulnerability. - - -## Deployer Units of Work - -!!! info inline end "Deployer Unit of Work" - - The unit of work for a Deployer is usually a single deployable patch or patch bundle such as a service pack. - -Deployers are usually in the position of receiving remediations or mitigations from their Suppliers for products they have deployed. -They must then decide whether to deploy the remediation or mitigation to a particular instance (or not). -Whether they have the option of deploying only part of a remediation such as a fix bundle depends on whether the Supplier has engineered their release process to permit that degree of flexibility. -For example, if service packs are fix bundles, the Supplier might choose to release individually deployable fixes as well. - -The vulnerability management process for deployers has at its core the collation of data including - -- an inventory of deployed instances of product versions -- a mapping of vulnerabilities to remediations or mitigations -- a mapping of remediations and/or mitigations to product versions - -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**. - -!!! 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. -For this reason, we recommend that the pairing of remediation or mitigation to a product version instance constitutes the unit of work most appropriate for the SSVC. - -## Coordinator Units of Work - -!!! info inline end "Coordinator Unit of Work" - - The unit of work for a Coordinator is usually a single report to be coordinated. - -Coordinator units of work tend to coincide with whatever arrives in a single report, which spans the range from a single -vulnerability affecting a specific version of an individual product from one Supplier all the way to fundamental design -flaws in system specifications that could affect every Supplier and product that uses or implements the flawed specification. -Coordinators may need to reorganize reports (e.g., merge, split, expand, or contract) according to their workflow demands. -SSVC can be applied to either the initial report or to the results of such refinement. - -## Aggregation of SSVC across units of work - -SSVC users should answer the suggested questions for whatever discrete unit of work they are considering. There is not necessarily a reliable function to aggregate a recommendation about remediation out of its constituent vulnerabilities. For the sake of simplicity of examples, we treat the remediation as a patch of one vulnerability, and comment on any difficulty in generalizing our advice to a more complex patch where appropriate. - -To further clarify terms, “Remediation occurs when the vulnerability is eliminated or removed. Mitigation occurs when the impact of the vulnerability is decreased without reducing or eliminating the vulnerability” [@dodi_8531_2020, section 3.5]. Examples of remediation include applying patches, fixes and upgrades; or removing the vulnerable software or system from operation. Mitigating actions may include software configuration changes, adding firewall ACLs, or otherwise limiting the system's exposure to reduce the risk of the impact of the vulnerability; or accepting the risk. - diff --git a/mkdocs.yml b/mkdocs.yml index e217cfe1..efffdafe 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -16,8 +16,6 @@ nav: - Intro: 'topics/vulnerability_management_decisions.md' - Stakeholders: 'topics/enumerating_stakeholders.md' - Decisions: 'topics/enumerating_decisions.md' - - Units of Work: 'topics/units_of_work.md' - - Action Priority: 'topics/enumerating_actions.md' - Items With Same Priority: 'topics/items_with_same_priority.md' - Risk Tolerance and Priority: 'topics/risk_tolerance_and_priority.md' - Scope: 'topics/scope.md' @@ -42,7 +40,7 @@ nav: - Deployer Decision Model: 'howto/deployer_tree.md' - Coordinator Decision Models: - About Coordination: 'howto/coordination_intro.md' - - Coordination Decision: 'howto/coordination_decisions.md' + - Coordination Triage: 'howto/coordination_triage_decision.md' - Publication Decision: 'howto/publication_decision.md' - Customizing SSVC: 'howto/tree_customization.md' - Acuity Ramp: 'howto/acuity_ramp.md' diff --git a/src/ssvc/decision_points/public_value_added.py b/src/ssvc/decision_points/public_value_added.py index 31385d57..6f8158de 100644 --- a/src/ssvc/decision_points/public_value_added.py +++ b/src/ssvc/decision_points/public_value_added.py @@ -1,11 +1,23 @@ #!/usr/bin/env python """ -file: public_value_added -author: adh -created_at: 9/21/23 11:27 AM +This module provides the Public Value Added decision point for the Stakeholder Specific Vulnerability Categorization (SSVC) framework. """ +# Copyright (c) 2024 Carnegie Mellon University and Contributors. +# - see Contributors.md for a full list of Contributors +# - see ContributionInstructions.md for information on how you can Contribute to this project +# Stakeholder Specific Vulnerability Categorization (SSVC) is +# licensed under a MIT (SEI)-style license, please see LICENSE.md distributed +# with this Software or contact permission@sei.cmu.edu for full terms. +# Created, in part, with funding and support from the United States Government +# (see Acknowledgments file). This program may include and/or can make use of +# certain third party source code, object code, documentation and other files +# (“Third Party Software”). See LICENSE.md for more details. +# Carnegie Mellon®, CERT® and CERT Coordination Center® are registered in the +# U.S. Patent and Trademark Office by Carnegie Mellon University + from ssvc.decision_points.base import SsvcDecisionPoint, SsvcDecisionPointValue +from ssvc.decision_points.helpers import print_versions_and_diffs LIMITED = SsvcDecisionPointValue( name="Limited", @@ -30,12 +42,14 @@ description="How much value would a publication from the coordinator benefit the broader community?", key="PVA", version="1.0.0", - values=(PRECEDENCE, AMPLIATIVE, LIMITED), + values=(LIMITED, AMPLIATIVE, PRECEDENCE), ) def main(): - print(PUBLIC_VALUE_ADDED_1.to_json(indent=2)) + versions = (PUBLIC_VALUE_ADDED_1,) + + print_versions_and_diffs(versions) if __name__ == "__main__":